PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ · daniel aiub nunes marco aurÉlio de figueiredo locks rafael hayashi verificar a adequaÇÃo do uso da metodologia Ágil scrum para

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ

PROGRAMA DE PÓS-GRADUAÇÃO – ESPECIALIZAÇÃO

MBA EM GESTÃO DE PROJETOS DE SOFTWARE

DANIEL AIUB NUNES

MARCO AURÉLIO DE FIGUEIREDO LOCKS

RAFAEL HAYASHI

VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SC RUM PARA

ATENDIMENTO DO NÍVEL G DO MPS.BR

CURITIBA

2011

DANIEL AIUB NUNES


RAFAEL HAYASHI



Monografia apresentada ao Curso de MBA em Gestão de Projetos de Software, da Pontifícia Universidade Católica do Paraná, como requisito à obtenção do título de Especialista. Orientadora: Prof. Msc. Cristina Ângela Filipak Machado

CURITIBA

2011

FICHA CATALOGRÁFICA

Aiub Nunes, Daniel Hayashi, Rafael Locks, Marco Aurélio de Figueiredo VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SCRUM PARA ATENDIMENTO DO NÍVEL G DO MPS.BR – Curitiba, 2011. Área de concentração: Tecnologia da Informação Monografia (especialização) – Pós-Graduação da Pontifícia Universidade Católica do Paraná, Curitiba, PR. Orientadora: Prof. Msc. Cristina Ângela Filipak Machado. 1. Metodologias ágeis; 2. Metodologias clássicas; 3. Scrum; 4. MPS.BR; 5. Qualidade; 6. Certificação

DANIEL AIUB NUNES


RAFAEL HAYASHI



Monografia apresentada ao Curso de MBA em Gestão e Projetos de Software, da

Pontifícia Universidade Católica do Paraná, como requisito à obtenção do título de

Especialista.

COMISSÃO EXAMINADORA

______________________________

Prof. Msc

Pontifícia Universidade Católica do Paraná

______________________________

Prof. Msc


______________________________

Prof. Msc


Curitiba, _____ de ____________ de 2011.

A todos os nossos familiares e amigos pelo apoio e compreensão em nossos

momentos de ausência em função deste trabalho...

Dedico

AGRADECIMENTOS

Agradecemos a princípio a Deus, que nos permitiu a inteligência.

À nossa orientadora, Prof. Msc. Cristina Ângela Filipak Machado, pela

dedicação nas correções e orientações neste período de aprendizado.

“Para aprender é preciso passar por situações emocionantes. Para isso é preciso

tirar as pessoas de suas rotinas físicas e mentais. Não aprendemos nada dentro de

nossas ‘zonas de conforto’, sentados todos os dias, no mesmo lugar, na mesma

mesa, fazendo a mesma coisa, onde tudo é previsível. Na ‘zona de aprendizado’ há

uma dose de desconforto e as emoções são intensificadas.”

Ernest Shackleton

LISTA DE ILUSTRAÇÕES

Figura 1 - Camadas da Engenharia de Software....................................................20

Figura 2 - Áreas de abrangência do gerenciamento de sistemas...........................21

Figura 3 - Componentes do Modelo MPS...............................................................27

Figura 4 - Estrutura de Níveis de Maturidade .........................................................28

Figura 5 - Visão geral do Scrum .............................................................................53

Figura 6 - Papéis, responsabilidades e eventos do Scrum.....................................54

Figura 7 - Burndown Chart em horas .....................................................................58

Figura 8 - Burndown Chart de tarefas.....................................................................59

Figura 9 - Exemplo de Product Vision Box .............................................................66

Figura 10 - Organização de uma FBS ......................................................................69

Figura 11 - Plano de release ....................................................................................72

Figura 12 - Planning Poker .......................................................................................75

Figura 13 - Quadro Kanban ......................................................................................77

Figura 14 - Agile System Development Life Cycle....................................................80

Figura 15 - Agile System Development Life Cycle (detailed)....................................82

Figura 16 - Scrum Board ..........................................................................................84

Figura 17 - Resumo do mapeamento entre o processo GPR do MPS.BR e

Scrum .....................................................................................................99

Figura 18 - Resumo do mapeamento entre o processo GRE do MPS.BR e

Scrum ...................................................................................................103

Quadro 1 - Níveis de maturidade e processos do MPS.BR......................................29

Quadro 2 - Exemplo de Product Backlog .................................................................57

Quadro 3 - Resultados retrospectiva ........................................................................64

Quadro 4 - Estrutura de uma Elevator Statement ....................................................67

Quadro 5 - Exemplo de Elevator Statement .............................................................68

Quadro 6 - Project Data Sheet .................................................................................71

Quadro 7 - Estrutura de uma User Story ..................................................................73

Quadro 8 - Exemplo da composição de uma feature ...............................................74

Quadro 9 - Modelo simplificado de matriz de rastreabilidade...................................78

LISTA DE ABREVIATURAS E SIGLAS

AP – Atributos de Processo

CMMI – Capability Maturity Model Integration

DOD – Definition of Done

EAP – Estrutura Analítica do Projeto

FBS – Feature Breakdown Struture

GPR – Gerência de Projetos

GRE – Gerência de Requisitos

MA – Metodologias Ágeis

MA-MPS – Método de Avaliação de Melhoria de Processo de Software

MN-MPS – Modelo de Negócio de Melhoria de Processo de Software

MR-MPS – Modelo de Referência de Melhoria de Processo de Software

MPS.BR – Melhoria do Processo de Software Brasileiro

PDS – Project Data Sheet

PMBOK – Project Management Body of Knowledge

RAP – Resultados de Atributos de Processo

ROI – Return Of Investment

RUP – Rational Unified Process

SEI – Software Engineering Institute

TI – Tecnologia da informação

TOC – Theory Of Constraints

XP – Extreme Programming

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................16

1.1 DESENVOLVIMENTO DE SOFTWARE ..........................................................16

1.2 OBJETIVO........................................................................................................23

1.3 ESTRUTURA ...................................................................................................24

2 REVISÃO DE LITERATURA .............................. ................................................25

2.1 MPS.BR............................................................................................................25

2.1.1 Introdução.......................................................................................................25

2.1.2 Estrutura .........................................................................................................26

2.1.3 Descrição........................................................................................................27

2.1.4 Descrições dos processos ..............................................................................29

2.1.4.1 Nível G .......................................................................................................29

2.1.4.1.1 Gerência de projetos...............................................................................30

2.1.4.1.2 Gerência de requisitos ............................................................................35

2.1.4.2 Nível F........................................................................................................36

2.1.4.2.1 Aquisição.................................................................................................37

2.1.4.2.2 Gerência de configuração .......................................................................37

2.1.4.2.3 Garantia da qualidade.............................................................................38

2.1.4.2.4 Gerência de Portfólio de Projetos ...........................................................38

2.1.4.2.5 Medição...................................................................................................39

2.1.4.3 Nível E........................................................................................................39

2.1.4.3.1 Avaliação e Melhoria do Processo Organizacional .................................40

2.1.4.3.2 Definição do processo organizacional.....................................................40

2.1.4.3.3 Gerência de recursos humanos ..............................................................41

2.1.4.3.4 Gerência de reutilização..........................................................................42

2.1.4.3.5 Gerência de projetos (evolução) .............................................................42

2.1.4.4 Nível D .......................................................................................................43

2.1.4.4.1 Desenvolvimento de requisitos ...............................................................43

2.1.4.4.2 Integração do produto .............................................................................44

2.1.4.4.3 Projeto e construção do produto .............................................................44

2.1.4.4.4 Validação ................................................................................................45

2.1.4.4.5 Verificação ..............................................................................................46

2.1.4.5 Nível C .......................................................................................................46

2.1.4.5.1 Desenvolvimento para reutilização .........................................................46

2.1.4.5.2 Gerência de decisões..............................................................................47

2.1.4.5.3 Gerência de riscos ..................................................................................48

2.1.4.6 Nível B........................................................................................................48

2.1.4.6.1 Gerência de projetos (evolução) .............................................................49

2.1.4.7 Nível A........................................................................................................50

2.2 METODOLOGIAS ÁGEIS ................................................................................50

2.2.1 Scrum .............................................................................................................52

2.2.1.1 Papéis e responsabilidades .......................................................................54

2.2.1.1.1 Product Owner ........................................................................................54

2.2.1.1.2 O Scrum Master ......................................................................................55

2.2.1.1.3 O Time ....................................................................................................56

2.2.1.2 Artefatos.....................................................................................................56

2.2.1.2.1 Product Backlog ......................................................................................56

2.2.1.2.2 Sprint Backlog .........................................................................................57

2.2.1.2.3 Burndown Chart ......................................................................................58

2.2.1.3 Eventos ......................................................................................................60

2.2.1.3.1 Sprint Planning Meeting ..........................................................................60

2.2.1.3.2 Daily Standup Meeting ............................................................................61

2.2.1.3.3 Sprint Review Meeting ............................................................................62

2.2.1.3.4 Sprint Retrospective Meeting ..................................................................63

2.2.1.4 Boas práticas utilizadas no Scrum .............................................................65

2.2.1.4.1 Product Vision Box..................................................................................65

2.2.1.4.2 Elevator Statement..................................................................................67

2.2.1.4.3 Feature Breakdown Structure .................................................................69

2.2.1.4.4 Project Data Sheet ..................................................................................70

2.2.1.4.5 Plano de Release....................................................................................72

2.2.1.4.6 User Stories ............................................................................................73

2.2.1.4.7 Planning Poker........................................................................................75

2.2.1.4.8 Quadro Kanban.......................................................................................76

2.2.1.4.9 Matriz de Rastreabilidade........................................................................78

2.2.1.5 Iniciando o Scrum.......................................................................................79

3 ANÁLISE E MAPEAMENTO DO SCRUM NO NÍVEL G DO MPS.BR . ..............86

3.1 ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE PROJETOS DO NÍVEL G DO MPS.BR......................................................86

3.1.1 GPR1 – O Escopo do trabalho para o projeto é definido................................86

3.1.2 GPR2 – As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados ......................................................................87

3.1.3 GPR3 – O Modelo e as fases do ciclo de vida do projeto são definidos.........88

3.1.4 GPR4 – (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas........................................................................................89

3.1.5 GPR5 – O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos..........................90

3.1.6 GPR6 – Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados ................................................................................................90

3.1.7 GPR7 – Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo ..................................91

3.1.8 GPR8 – Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados....................................................................................92

3.1.9 GPR9 – Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.................................................................................93

3.1.10 GPR10 – Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos....................................................................94

3.1.11 GPR11 – A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados .......................................................................................................94

3.1.12 GPR12 – O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido .......................................................................95

3.1.13 GPR13 – O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados ...................95

3.1.14 GPR14 – O envolvimento das partes interessadas no projeto é gerenciado.96

3.1.15 GPR15 – Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento ........................................................................97

3.1.16 GPR16 – Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas ..............................................................97

3.1.17 GPR17 – Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão ..................................98

3.1.18 Resumo do mapeamento entre o processo GPR do MPS.BR e Scrum.........98

3.2 ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE REQUISITOS DO NÍVEL G DO MPS.BR.................................................100

3.2.1 GRE1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos..............................100

3.2.2 GRE2 – O comprometimento da equipe técnica com os requisitos aprovados é obtido .......................................................................................100

3.2.3 GRE3 – A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida ................................................................101

3.2.4 GRE4 – Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos ......................................................................................................101

3.2.5 GRE5 – Mudanças nos requisitos são gerenciadas ao longo do projeto......102

3.2.6 Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum .......102

4 CONCLUSÕES .................................................................................................104

REFERÊNCIAS.......................................................................................................112

RESUMO

Esta monografia tem como objetivo principal propor uma maneira de cumprir

as exigências do Modelo de Maturidade MPS.BR nível G utilizando a Metodologia

Ágil Scrum e identificar a necessidade de adaptar o seu modo de trabalho, caso

necessário. A proposta do trabalho, busca agregar princípios e valores de novas

metodologias e boas práticas, que ganham mais espaço diante do mercado atual de

software, às orientações do Modelo de Maturidade MPS.BR, embasado em diversas

boas práticas utilizadas no desenvolvimento de software. O estudo também se

propõe em mapear o ciclo de vida proposto pelo Scrum dentro do primeiro nível do

MPS.BR e evidenciar o potencial das Metodologias Ágeis no gerenciamento de um

projeto. Como resultado desse gerenciamento híbrido, Metodologia Ágil regida por

modelo de maturidade, empresas que desenvolvem software podem melhorar seus

processos e poderão obter uma certificação que as tornará mais competitivas.

Embora esse resultado seja o mais previsível, outros benefícios estão agregados ao

desenvolvimento que segue bases rígidas de gerenciamento, o produto final terá

qualidade a partir de processos maduros que garantem um desenvolvimento que

privilegia a qualidade. Vale ressaltar que o MPS.BR possui outros níveis de

maturidade, portanto os benefícios que a conjugação do MPS.BR e do Scrum não

ficam restritos ao âmbito deste trabalho. Outros trabalhos que abordarem este tema,

a análise que o estudo apresentado descreve, pode servir de apoio a investigações

de como cumprir as exigências dos níveis seguintes do MPS.BR, uma vez que os

níveis são cumulativos. Considerando que as Metodologias Ágeis são flexíveis e é

possível propor inúmeras maneiras de utilizá-las, os estudos nessa temática

apontam que é possível a combinação entre Scrum e MPS.BR, porém uma

organização que deseje adotá-los, deve estar primeiramente disposta a enfrentar

uma constante mudança cultural, exigida na adoção de qualquer nova boa prática.

Palavras-chave: Metodologias ágeis. Metodologias tradicionais. Scrum. MPS.BR. Qualidade. Certificação.

ABSTRACT

The main objective of this work is to suggest a way to achieve the goals of the

G level of the MPS.BR Maturity Model using the Scrum Agile Methodology and to

identify the need to adapt its work structure, if necessary. This work purposes a way

to join the principles and values of new methodologies that are becoming commonly

used by the current software market to the good practices used by the orientation of

the MPS.BR Maturity Model. Another purpose of this work is to map the Scrum

lifecycle on the first level of MPS.BR and puts on evidence the potential of Agile

Methodologies on the management of a project. As a result of this hybrid way of

manage projects (Agile Methodology guided by an maturity model) companies can

use it to acquire better process and could achieve an certification that will make them

more competitive on the software development market. While this is the most

predictable result, there are other benefits that a development process based on

solid management practcies brings to the organization. The result is a product with

better quality that comes from a better development process focused on quality. It is

noteworthy that MPS.BR has other levels of maturity to be achieved, so the benefits

are not restricted to the scope of this work. Future works that wil explores the next

levels of MPS.BR can use this work as a starting point, since the levels are

cumulative. Considering that Agile Methodologies are flexible and its practices able

to be used in many ways, studies that approaches this theme points that it is possible

to combine Scrum and MPS.BR but an organization that intents to use it must be

prepared to face constant cultural change, required by the adoption of any other

good practice on software development.

Keywords: Scrum, Agile Methodologies, MPS.BR, Maturity Model, Quality,

Certification, Traditional Methodologies.

16

1 INTRODUÇÃO

1.1 DESENVOLVIMENTO DE SOFTWARE

A Tecnologia da Informação (TI) dentro das empresas assumiu um papel de

ativo fundamental no novo padrão de competitividade que impera atualmente. A TI é

vista como necessidade de negócio, se a TI parar, o negócio da empresa também

pára. Conforme Pressman (2002, p. 3):

O software de computadores tornou-se uma força motora. É o motor que dirige a tomada de decisão nos negócios. Serve de base à moderna investigação científica e às soluções de problemas de engenharia. É um fator chave que diferencia os produtos e serviços modernos. Está embutido em sistemas de todas as naturezas: de transportes, médicos, de telecomunicações, militares, de processos industriais, de produtos de escritório..., a lista é quase sem fim. O software é virtualmente inevitável no mundo moderno (...) irá se tornar um motor para novos avanços em tudo, da educação elementar à engenharia genética.

Atualmente a competitividade depende da criação e renovação de vantagens

competitivas relacionadas ao aprendizado, a qualidade dos recursos humanos e a

capacitação produtiva da empresa. Baseia-se principalmente na construção de um

modelo que permita adquirir conhecimento e inovação. A eficiência interna, a

capacidade de operação, a habilidade em oferecer produtos e serviços, a agilidade e

a flexibilidade, assim como outras vantagens competitivas são fortemente

influenciadas pelos sistemas de TI.

O desenvolvimento de sistemas de TI, denominados softwares, está cada vez

mais presente entre as prioridades das organizações. Os projetos de

desenvolvimento de software são similares ao desenvolvimento de um novo produto,

são gerenciadas na forma de projetos e os resultados exercem influência direta no

sucesso das organizações.

É utilizado durante o desenvolvimento do software práticas e princípios da

engenharia, o que ficou conhecido como Engenharia de Software, de acordo com

Bauer (apud PRESSMAN, 2002, p. 18) “engenharia de software é a criação e a

utilização de sólidos princípios de engenharia a fim de obter software de maneira

econômica, que seja confiável e que trabalhe eficientemente em máquinas reais”.

Por esse motivo é possível reconhecer que desenvolver um produto, nesse contexto,

17

está relacionado em seguir certos passos e muitas vezes basear-se nas melhores

maneiras de realizar certas tarefas de acordo com procedimentos adotados por

outros.

Esse modo de trabalho faz com que a empresa ganhe tempo, não

“reinventando a roda” e sim a aperfeiçoando. O objetivo é estabelecer um modelo,

que concentre os passos para desenvolver um bom projeto, para que seja

conseguida através da aplicação desse modelo a alta qualidade do software. Por

isso, na engenharia de software temos modelos que segundo o Dicionário Aurélio

(1995, p. 337), são definidos por:

[...] coisa cuja imagem serve para ser reproduzida [...] aquilo que serve de exemplo ou norma; molde [...] aquele que se pretende imitar nas ações, no procedimento, nas maneiras [...] ato que por sua importância ou perfeição é digno de servir de exemplo […] conjunto de hipóteses sobre a estrutura ou o comportamento de um sistema físico pelo qual se procuram explicar ou prever, dentro de uma teoria cientifica, as propriedades do sistema.

Os modelos na engenharia de software são uma representação genérica, que

visa ilustrar em um gráfico o ciclo de vida do software, definidos por determinada

metodologia para melhor descrever e explicar o encadeamento de seus processos.

Segundo Thomsett (2002 apud DIAS, 2005, p. 9):

Os projetos de desenvolvimento de software têm duas vertentes, uma técnica e outra gerencial [...] muita atenção foi dada ao aprimoramento dos modelos de desenvolvimento de software (ênfase técnica), ficando o componente gerencial relegado a segundo plano.

A melhoria de âmbito gerencial ocorreu com a publicação dos modelos de

maturidade criados pelo SEI – Software Engineering Institute, para promover o

amadurecimento das organizações no processo de desenvolvimento de software.

Modelos estes bastante alinhados ao gerenciamento clássico de software. Fato que

animou as empresas em investir na adoção das práticas de gerenciamento de

projetos visando a uma melhoria no desempenho de seus projetos.

Apesar do crescimento acelerado do desenvolvimento de software muitas

empresas especializadas em desenvolvimento encontram dificuldades em seus

projetos para alcançar níveis satisfatórios de lucratividade e de vendas, também

reportam problemas quanto à qualidade dos produtos, ao cumprimento de prazos e

dos custos dos projetos de desenvolvimento de software. Organizações que não tem

o desenvolvimento de software como atividade principal também passam pelos

mesmos problemas.

18

Em vista dos resultados abaixo do esperado obtidos com o uso dos métodos

tradicionais de desenvolvimento, gerenciados de acordo com os princípios do

gerenciamento clássico de projetos, uma nova abordagem foi criada para o

desenvolvimento de software. Primeiramente a resposta para um melhor

desempenho dos projetos veio no âmbito técnico propondo alternativas aos métodos

convencionais de desenvolvimento de software utilizados, os chamados Métodos

Ágeis de desenvolvimento, que têm como foco o atendimento das expectativas e

das necessidades do cliente, a entrega rápida e uma forte absorção da mudança.

Faz parte dos métodos ágeis o Scrum, que é objeto de estudo nesse trabalho.

Na vertente gerencial temos o Gerenciamento Ágil de Projetos, que possui

valores como priorizar a entrega de produto à entrega da documentação, a

colaboração ao invés da negociação de contratos, maior valor ao indivíduo e suas

interações aos processos e ferramentas. Contudo o produto deve ser entregue

dentro do prazo, custo e qualidade.

Segundo Brasil (2005a apud DIAS, 2005, p. 14) “no Brasil o segmento de

software ainda é visto com especial atenção pelo governo, por seu grande potencial

de geração de empregos e por sua capacidade de absorção de mão-de-obra jovem,

recém-saída das universidades”.

Porém, concorrer no mercado de software interno não é tão simples. O

desenvolvimento das Fábricas de Software aqui no Brasil precisa adquirir um padrão

de competitividade que seja relacionado a uma imagem de desenvolvimento

sustentado pela maturidade de processos alcançada através de certificação.

Conforme Dias (2005), a Índia conseguiu vincular a imagem de maturidade a seus

softwares e por isso foi bem sucedida nacional e internacionalmente mesmo sendo

um país emergente.

Uma visão de sucesso nesse contexto seria utilizar Métodos Ágeis de

desenvolvimento. A agilidade pode ser tomada como um diferencial, porque torna a

Fábrica de Software atual para o mercado. A agilidade contribui no gerenciamento

de um projeto oferecendo aos desenvolvedores de software uma forma de melhor

atender a expectativa dos clientes durante o gerenciamento do projeto. Como os

princípios da agilidade estão voltados para a absorção da mudança, a fábrica que

utiliza processos ágeis acompanhará da melhor forma o mercado, que possui alta

incerteza em relação a sua necessidade por soluções de TI e consequentemente se

apresenta em constante mudança.

19

Uma ousadia, não tão incomum, é utilizar princípios dos Métodos Ágeis em

conformidade com um Modelo de Maturidade que segue o Método Clássico de

desenvolvimento. Nesse cenário está o MPS.BR – Melhoria do Processo de

Software Brasileiro, desenvolvido pelo SOFTEX, e compatível com a realidade do

mercado nacional de software.

É possível encontrar na internet casos de sucesso de empresas que atingiram

maturidade para uma certificação do MPS.BR. Essa monografia limita-se a estudar o

nível G em razão de ser o nível de maior aderência das empresas relacionadas pela

SOFTEX, hoje existem 121 empresas certificadas no nível G.

Como nível inicial do MPS.BR, o estudo do nível G presente neste trabalho

demonstra que a sua adoção e implementação é mais fácil do que pensam muitos

empreendedores, e os benefícios de processos maduros já no nível G podem

desencadear em uma Fábrica de Software o interesse para a implementação dos

demais níveis do MPS.BR.

Seguindo essa mesma ideologia encontram-se inúmeras publicações em que

os autores apresentam conjugadas à utilização das práticas do gerenciamento ágil

de projetos no desenvolvimento de software conduzido segundo os Métodos

Clássicos.

Dessa forma será abordado o método de maturidade MPS.BR no decorrer do

trabalho, que foi baseado em Métodos Clássicos visando a melhoria do processo de

software brasileiro, como o acrônimo já diz. O MPS.BR reúne atributos que

aconselham como conduzir o gerenciamento de um projeto de modo que o produto

final apresente qualidade que foi agregada através de melhores práticas que

determinarão um padrão para o planejamento da qualidade em uma empresa de

desenvolvimento de software.

A qualidade do software depende principalmente do correto emprego de

metodologias. De acordo com Pressman, metodologia está vinculada com processo,

que é o fundamento da engenharia de software. O processo é o que relaciona o

método com a qualidade, porque define uma estrutura para áreas principais do

projeto. Ao obter as áreas principais visualiza-se o controle gerencial de projetos. A

partir desse passo é possível estabelecer o contexto no qual os métodos são

aplicados, os produtos de trabalho como os modelos, documentos, dados, relatórios

e formulários são produzidos, marcos são estabelecidos, qualidade é assegurada e

modificações são geridas. Na figura abaixo temos a figuração das ferramentas, o

20

que auxilia nas tarefas dos métodos. Durante o projeto o desenvolvimento ou

adoção de ferramentas auxilia na automatização de tarefas, o que diminui a carga

de trabalho de pessoas e faz com que a tarefa produza sempre o mesmo resultado

contribuindo na qualidade final.

Figura 1 - Camadas da Engenharia de Software

Fonte: Adaptado de Pressman (2002, p. 19).

Pressman (2002, p. 21) define o que pode ser compreendido como a estrutura

de um processo:

[...] uma estrutura comum de processo é estabelecida definindo um pequeno número de atividades dessa estrutura, que são aplicáveis a todos os projetos de software, independentemente de seu tamanho ou complexidade. Um certo número de conjuntos de tarefas – […] marcos de projeto, produtos do trabalho e pontos de garantia de qualidade – permite que as atividades da estrutura sejam adaptadas às características do projeto de software e as necessidade da equipe de projeto.

Segundo a Figura 1, a camada que dá apoio a engenharia de software é um

enfoque na Qualidade. Para Pressman é importante definir o que quer dizer

“qualidade de software”, é possível definir esse termo começando pela criação de

um conjunto de atividades que ajudarão a garantir que todo o produto de trabalho de

engenharia de software exiba alta qualidade, como realizar atividade de garantia da

qualidade em todo o projeto de software e usar métricas para desenvolver

estratégias para aperfeiçoar os processos de software e, como consequência, obter

a qualidade do produto final. Um exemplo de modelo de maturidade que fornece

uma abordagem aos conceitos de qualidade para a Engenharia de Software é citado

o MPS.BR durante essa monografia.

A Figura 2 ilustra a delimitação dos assuntos que estão presentes nessa

monografia e permite esclarecer em que parte do gerenciamento de sistemas os

assuntos que serão abordados estão presentes. Este trabalho trata de assuntos

21

relacionados ao desenvolvimento de software em uma fábrica de software, portanto

o Scrum e o MPS.BR estão presentes nas elipses.

Figura 2 - Áreas de abrangência do gerenciamento de sistemas

Fonte: Adaptado de WG 7 Strategy - Starting Point and Discussion (2010, s. 8).

O MPS.BR apresenta 7 níveis de maturidade progressivos, que começa pelo

nível G e encerra no nível A. Os níveis de maturidade são alcançados após uma

avaliação de alguns projetos desenvolvidos, os quais a empresa julga estarem de

acordo com os propósitos e a todos os resultados esperados de um determinado

processo e também aos níveis de capacidade do processo. Ao final da

implementação de cada nível de maturidade é possível adquirir um certificado para

uma empresa do tipo Fábrica de Software, ou seja, uma empresa totalmente voltada

ao desenvolvimento de software.

Os detalhes a respeito do nível G, como os processos e seus resultados

esperados serão descritos no decorrer da monografia. Entretanto, não será discutido

detalhes da avaliação para se obter a certificação, como os níveis de capacidade

dos processos, que são os Atributos de Processo (AP) e seus respectivos

Resultados de Atributos de Processo (RAP), assuntos de extrema importância

quando a empresa se sujeita à uma avaliação. Essa limitação da monografia em não

aprofundar a avaliação dos resultados esperados por meio dos AP foi proposta

porque esse trabalho visa o principal benefício que o MPS.BR traz a empresa, que

22

não é o papel dizendo que a empresa é certificada, mas sim a adoção de processos

maduros e a execução de atividades ágeis visando sempre a melhoria contínua do

modo de trabalho da Fábrica de Software.

Apesar de não apresentar os meios para atingir seus Níveis de Maturidade,

os documentos do MPS.BR provêem um guia de trabalho para uma instituição que

deseje atingir os resultados propostos em cada nível do MPS.BR. Visto que cada

empresa, equipe ou profissional pode propor uma ação de gestão peculiar diante da

sua realidade em um projeto, o que permite afirmar que existe uma variabilidade

infinita de meios para atingir os níveis do MPS.BR. Conforme o guia esclarece “[...]

as atividades e tarefas demandadas para atender ao propósito e aos resultados

esperados devem ficar sobre a incumbência dos usuários do MR-MPS (Modelo de

Referência do MPS.BR), por essa razão não estão presentes em nenhum guia”

(SOFTEX, 2009).

Durante este trabalho foi investigado o modo de trabalho de equipes que

utilizam o Scrum, e percebido que além do Scrum, são utilizadas diversas boas

práticas que complementam principalmente as etapas de visão do produto, definição

de escopo, bem como o levantamento e a análise dos requisitos, conforme

apresentadas no Capítulo 2.

Visto que o Scrum pode ser adaptado à realidade de uma empresa, será

investigado a possibilidade de estabelecer dentro dos princípios do Scrum uma

abordagem que permita cumprir a exigência do nível G do MPS.BR. Os frameworks

por si também não dizem como fazer ou como agir em determinada situação, por

isso cada equipe trabalha de diferentes maneiras diante das circunstâncias do

projeto. Entretanto, frameworks como o Scrum visam adaptar-se à mudança e a

melhoria contínua do processo de trabalho, o que favorece o surgimento de novas

idéias à equipe de como as Metodologias Ágeis (MA) poderiam ser mais bem

aplicadas a contextos específicos. É um aprendizado constante.

Segundo os princípios das MA percebe-se com maior nitidez que agilidade

não é ausência de processos e ferramentas, e seu uso deve ser equilibrado e

apropriado em cada situação. É notado também que isso ocorre principalmente ao

entender como outras equipes aplicam as MA no processo de desenvolvimento de

software, ou seja, reconhecer uma boa prática e em qual situação ela foi aplicada

para se tornar bem sucedida.

23

A harmonia entre o modo de trabalho do Scrum e do modelo MPS.BR trará

como benefício a aquisição de processos disciplinados com tendência a

amadurecerem e se moldarem às preferências do modo de trabalho de uma

organização a longo prazo. A versatilidade do Scrum em ser adaptado às

necessidades do projeto traduz-se em agilidade e eficiência para absorver as

mudanças que surgirem, bem como imprevistos durante o projeto. Além da

certificação do processo de desenvolvimento guiado pelo modelo de maturidade,

tornando a empresa de desenvolvimento mais alinhada aos padrões nacionais e

internacionais, refletindo em um fator vital para o crescimento da empresa.

1.2 OBJETIVO

Os objetivos primários desse trabalho são:

a) descrever o modelo de maturidade MPS.BR nível G;

b) descrever os princípios do Scrum;

c) mapear o momento em que o ciclo de vida do Scrum e as práticas ágeis

atendem a determinada exigência do nível G;

d) identificar a necessidade do Scrum ser modificado ou complementado para

atender a determinada exigência do nível G.

Como objetivos secundários da pesquisa, podem ser citados:

a) investigar os mitos em relação a MA, e mostrar que é um método que têm

muito potencial no mercado atual de software;

b) evidenciar as vantagens que a agilidade agrega ao Gerenciamento de

Projetos;

c) incentivar aos alunos de graduação e demais interessados, ou seja,

potenciais empreendedores, a utilizarem o Scrum e familiarizá-los com o

MPS.BR, desmistificando os modelos de maturidade como superfluos e

inalcançáveis para uma empresa de software.

24

1.3 ESTRUTURA

Em relação à estrutura, essa monografia está dividida nas seguintes partes:

a) Introdução , que contém a contextualização, apresenta conceitos básicos

de qualidade e do assunto geral a ser tratado, expõe a abordagem dos

assuntos e a limitação do tema, diz sobre a importância de um padrão de

qualidade e o significado de uma certificação para o mercado de software;

b) Revisão de Literatura , esse capítulo concentra o que foi julgado como a

mais relevante e completa abordagem dos assuntos principais da literatura

condizentes ao estudo;

c) Análise e Mapeamento , em que a monografia expõe o foco do trabalho

de pesquisa e a abordagem do assunto proposto é discutida;

d) Conclusões , que contém um fechamento levando em consideração o

motivo que impulsionou esse trabalho e a forma como o objetivo proposto

no início foi esclarecido e considerações finais desta monografia.

Tendo em mente o contexto apresentado nesse capítulo, os conceitos

explicados e os objetivos que impulsionaram a pesquisa desse projeto de

monografia parte-se para a revisão bibliográfica que contemplará a teoria que

sustenta o tema do trabalho.

25

2 REVISÃO DE LITERATURA

Este capítulo concentra o que foi julgado como a mais relevante e completa

abordagem dos assuntos na literatura condizente ao estudo. São abordados: o

MPS.BR, em uma visão geral e em detalhes no nível G, uma breve explicação sobre

Metodologias Ágeis, os princípios do Scrum e algumas boas práticas adotadas por

equipes que utilizam Scrum. Este conjunto de conhecimento extraído de vários

autores busca consolidar as opiniões técnicas expostas durante o trabalho.

2.1 MPS.BR

MPS.BR é a sigla de Melhoria de Processos do Software Brasileiro, criado por

pesquisadores brasileiros para a melhoria do processo de desenvolvimento de

software em empresas brasileiras, em especial as micro, pequenas e médias

empresas.

2.1.1 Introdução

O MPS.BR começou a ser desenvolvido em dezembro de 2003, pelas

instituições SOFTEX, Riosoft, COPPE/UFRJ, CESAR, CenPRA e CELEPAR. O

MPS.BR é um modelo de melhoria de processos baseado nas normas ISO/IEC

12207 e ISO/IEC 15504, e no modelo CMMI.

Diferente do CMMI, que prevê o amadurecimento dos processos em apenas

cinco níveis, o MPS.BR possui sete níveis de maturidade, que vão do G ao A,

funcionando de forma mais gradual e adequada a realidade das empresas

brasileiras. Possui um custo mais acessível, avaliação das empresas a cada 3 anos,

uma forte interação Universidade-Empresa e compatibilidade plena com CMMI e

com a norma ISO/EIC 15504.

A descrição do MPS.BR baseia-se em três guias:

26

a) Guia de aquisição: descreve um processo de aquisição de software e

serviços correlatos, baseado na norma internacional ISO/IEC 12207:2008;

b) Guia de avaliação: descreve o processo e o método de avaliação MA-

MPS, baseado na Norma Internacional ISO/IEC 15504;

c) Guia geral: contém a descrição geral do modelo MPS e detalha o modelo

de referência (MR-MPS) e as definições comuns necessárias para seu

entendimento e aplicação.

2.1.2 Estrutura

A base técnica utilizada na construção do MPS.BR é composta pelas normas

ISO/IEC 12207 [ISO/IEC, 2008] e ISO/IEC 15504-2 [ISO/IEC, 2003].

O modelo MPS está dividido em três componentes (Figura 3): Modelo de

Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-

MPS). Cada componente do modelo foi descrito por meio de guias e documentos do

projeto:

a) MR-MPS - o Modelo de Referência de Melhoria de Processo de Software

(MR-MPS) contém os requisitos que as organizações devem atender para

estar em conformidade com o MR-MPS. Ele contém as definições dos

níveis de maturidade, processos e atributos do processo. O MR-MPS está

em conformidade com os requisitos de modelos de referência de processo

da Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003]. O Guia de

Aquisição é um documento complementar para organizações que

pretendam adquirir software e serviços correlatos. Por fim, o Guia de

Implementação com as formas de implementar cada um dos níveis do MR-

MPS e formas de como uma unidade organizacional que faz aquisição de

produtos pode implementar o MR-MPS.

b) MA-MPS - o Método de Avaliação (MA-MPS) contém o processo de

avaliação, os requisitos para os avaliadores e os requisitos para

averiguação da conformidade ao modelo MR-MPS. Ele está descrito de

forma detalhada no Guia de Avaliação e foi baseado no documento

ISO/IEC 15504.

27

c) MN-MPS - o Modelo de Negócio (MN-MPS) descrever as regras para a

implementação do MR-MPS pelas empresas de consultoria, de software e

de avaliação.

Figura 3 - Componentes do Modelo MPS

Fonte: MPS.BR - Guia Geral (2009, p. 13).

2.1.3 Descrição

O Modelo de Referência MR-MPS define níveis de maturidade que são uma

combinação entre processos e sua capacidade (Figura 4).

Modelo MPS

ISO/IEC

12207

CMMI-DEV ISO/IEC

15504

Modelo de Referência

(MR-MPS)

Modelo de Avaliação

(MA-MPS)

Modelo de Negócio

(MN-MPS)

Guia Geral Guia de Aquisição Guia de Avaliação Documentos do Programa

Guia de Implementação

28

Figura 4 - Estrutura de Níveis de Maturidade

Fonte: Qualidade de Software (2007, p. 145).

O nível de maturidade em que se encontra uma organização permite prever

seu desempenho futuro. O MPS.BR está distribuído em sete níveis de maturidade

(Quadro 1), de A (melhor) a G (inicial). Os sete níveis de maturidade do MPS.BR

permitem uma implantação mais gradual do que o CMMI, facilitando a implantação

em pequenas empresas. Cada nível possui um perfil de processo e um perfil de

capacitação de processos.

A Em otimização

B Gerenciado quantitativamente Gerência de projetos (evolução)

Gerência de riscos

Gerência de decisões C Definido

Desenvolvimento para reutilização

Verificação

Validação

Projeto e construção do produto

Integração do produto

D Largamente definido

Desenvolvimento de requisitos

Gerência de projetos (evolução)

Gerência de reutilização

Gerência de recursos humanos

Definição do processo organizacional

E Parcialmente definido

Avaliação e melhoria do processo organizacional

Medição

Gerência de portfólio de projetos

Garantia da qualidade

Gerência de configuração

F Gerenciado

Aquisição

G Parcialmente gerenciado Gerência de requisitos

Níveis de Maturidade

Processo Capacitação

Propósito

Resultado

Atributo

Resultado

29

Gerência de projeto

Quadro 1 - Níveis de maturidade e processos do MPS.BR

Fonte: SOFTEX, 2009.

2.1.4 Descrições dos processos

Todos os processos relativos aos sete níveis do MPS.BR estão descritos de

forma resumida a seguir, ordenados pela ordem de aparição no modelo e

respeitando a sequência dos níveis de maturidade. Os principais resultados obtidos

pela execução de cada processo também são apresentados.

2.1.4.1 Nível G

Conforme o guia do MPS.BR, ao implantar o nível G a empresa deve estar

preparada para uma mudança de cultura organizacional e ter uma definição bem

clara do conceito de “projeto”. Algumas adaptações podem ocorrer, e refletirão em

alterações de processos, atividades, ferramentas, técnicas, procedimentos, padrões,

medidas, entre outros. Isto é necessário para adequar a forma de trabalho da

organização, que passa a trabalhar orientada a projetos, ou seja, redefinir algumas

operações que a empresa executava rotineiramente.

O nível G inicia-se pelo processo de Gerência de Projetos (GPR) e é seguido

pelo processo de Gerência de Requisitos (GRE). Quando aplicados a gestão de um

projeto serão avaliados quanto ao cumprimento dos atributos de processo AP 1.1 e

AP 2.1, apresentados a seguir:

AP 1.1 – O processo é executado: Este atributo é uma medida de quanto o

processo atinge o seu propósito.

RAP 1 – O processo atinge seus resultados definidos.

AP 2.1 – O processo é gerenciado: Este atributo é uma medida do quanto a

execução do processo é gerenciada.

30

RAP 2 – Existe uma política organizacional estabelecida e mantida para o

processo.

RAP 3 – A execução do processo é planejada.

RAP 4 – (Para o nível G) A execução do processo é monitorada e ajustes são

realizados.

RAP 5 – As informações e os recursos necessários para a execução do

processo são identificados e disponibilizados.

RAP 6 – (Até o nível F) As responsabilidades e a autoridade para executar o

processo são definidas, atribuídas e comunicadas.

RAP 7 – (Até o nível F) As pessoas que executam o processo são

competentes em termos de formação, treinamento e experiência.

RAP 8 – A comunicação entre as partes interessadas no processo é

gerenciada de forma a garantir o seu envolvimento.

RAP 9 – (Até o nível F) Os resultados do processo são revistos com a

gerência de alto nível para fornecer visibilidade sobre a situação na organização.

RAP 10 – (Para o nível G) O processo planejado para o projeto é executado.

Segundo o guia (SOFTEX, 2009b):

No que se refere aos atributos de processo, para atingir o nível G do MR-MPS, uma organização deve atender aos resultados esperados RAP 1 a RAP 10. Numa avaliação, segundo o MA-MPS (SOFTEX, 2009b), é exigido, para se considerar um processo ‘SATISFEITO’ no nível G, que o atributo de processo AP 1.1 seja caracterizado como T (Totalmente implementado) e que o atributo de processo AP 2.1 seja caracterizado como T (Totalmente implementado) ou L (Largamente implementado).

2.1.4.1.1 Gerência de projetos

O propósito do processo Gerência de Projetos é identificar, estabelecer,

coordenar e monitorar as atividades, recursos e responsabilidades do projeto, além

de fornecer informações sobre o andamento do projeto, permitindo que correções

sejam realizadas quando houver algum desvio significativo no desempenho do

projeto.

31

À medida que uma organização cresce em maturidade, o propósito do

processo Gerência de Projetos evolui. Assim, alguns resultados evoluem e outros

são incorporados.

O processo GPR tem 24 resultados esperados, para atingir o nível G é

preciso satisfazer 17 resultados, conforme abaixo, adaptado segundo a SOFTEX

(2009):

GPR1 - O escopo do trabalho para o projeto é defin ido - O Escopo do

projeto diz quais funções e características, como os objetivos do projeto, suas

limitações e restrições, os artefatos a entregar, ou seja, o que o projeto deve ter para

satisfazer o cliente. Geralmente representado pela EAP (Estrutura Analítica do

Projeto) e as informações levantadas são descritas em um documento de visão.

GPR2 - As tarefas e os produtos de trabalho do pro jeto são

dimensionados utilizando métodos apropriados - O tamanho das tarefas devem

representar uma parte suficiente do projeto para que seja possível estimar o esforço,

o tamanho, o cronograma e as responsabilidades.

GPR3 - O modelo e as fases do ciclo de vida do pro jeto são definidos - O

modelo descreve a estrutura de organização das atividades do processo em fases e

define como essas fases estão relacionadas. O ciclo de vida define um conjunto de

fases e atividades que visam cumprir o escopo dos requisitos, as estimativas para os

recursos e a natureza do projeto, para que seja possível conseguir um maior

controle gerencial. As fases do projeto permitem incluindo marcos importantes para

o controle e revisões.

GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e

dos produtos de trabalho são estimados com base em dados históricos ou

referências técnicas - As empresas que implementam o nível G geralmente não

possuem dados históricos, como tempo, esforço e custo. No início da

implementação do nível G é necessário que a empresa construa sua base de dados,

pois nesse nível é que será iniciado a coleta de dados para alimentar a base.

Posteriormente serão utilizados para dar maior precisão as estimativas.

GPR5 - O orçamento e o cronograma do projeto, incl uindo a definição de

marcos e pontos de controle, são estabelecidos e ma ntidos - O cronograma e o

orçamento são ferramentas de acompanhamento do dia-a-dia do projeto e sempre

devem ser revistos e atualizados. Deve-se ter cuidado para manter a coerência entre

o ciclo de vida, as estimativas, a EAP e o Cronograma.

32

GPR6 - Os riscos do projeto são identificados e o seu impacto,

probabilidade de ocorrência e prioridade de tratame nto são determinados e

documentados - É recomendável elaborar uma lista de riscos mais comuns e

analisar quais podem acontecer no projeto em questão, juntamente com a

probabilidade de ocorrência de cada risco e também o impacto gerado em

decorrência da realização do risco. Dessa forma é possível priorizar os riscos do

projeto. Esse resultado significa que os riscos são acompanhados para verificar

como afetam o projeto e para se tomar ações, mesmo que ainda sem um

gerenciamento completo no nível G.

GPR7 - Os recursos humanos para o projeto são plan ejados

considerando o perfil e o conhecimento necessários para executá-lo - É

interessante que haja um registro de informações de como e quando o recurso será

envolvido no projeto, critérios para sua liberação, competência necessária para a

execução das atividades, mapa de competências da equipe e identificação de

necessidades de treinamento. Como medida para minimizar riscos com recursos

menos capacitados alocados em projetos pode-se delegar ações de treinamento e

mentoring para supervisionar o trabalho da pessoa por um membro melhor

capacitado.

GPR8 - Os recursos e o ambiente de trabalho necess ários para executar

o projeto são planejados - Equipamentos, ferramentas, serviços, componentes,

viagens e requisitos de processo, nesse caso são processos especiais para o

projeto. Esses itens devem estar registrados no plano do projeto. Mesmo que não

haja necessidade de se adquirir nenhum recurso, deve-se registrar o fato de que a

questão foi examinada. Existe a questão de que recursos especiais precisam de

orçamento e planejamento de sua aquisição, pois em alguns projetos este detalhe

pode se tornar crítico caso ocorra no meio do projeto.

GPR9 - Os dados relevantes do projeto são identifi cados e planejados

quanto à forma de coleta, armazenamento e distribui ção. Um mecanismo é

estabelecido para acessá-los, incluindo, se pertine nte, questões de

privacidade e segurança - Os dados do projeto são as documentações exigidas

para sua execução, como: relatórios; dados informais; estudos e análises; atas de

reuniões; documentação; lições aprendidas; artefatos gerados; itens de ação; e

indicadores. Podem estar em qualquer formato, alguns podem ser repassados aos

clientes e outros não necessariamente serão, podem ser distribuídos inclusive por

33

meio eletrônico. Deve ser planejada a identificação, coleta, armazenamento e

distribuição. Procura-se garantir com isso a integridade e o controle do acesso da

informação. Deve-se planejar também quando e como será feita a coleta de dados

após a identificação do que é relevante para o projeto, pois esse processo implica

em custo. Recomenda-se que o nível de confidencialidade dos dados seja

explicitado, como exemplo, pode ser registrado os critérios de execução dessa

atividade no plano do projeto.

GPR10 - Um plano geral para a execução do projeto é estabelecido com

a integração de planos específicos - A integração entre os planos, como

cronograma de atividades, o planejamento de recursos humanos, custos, riscos,

dados, entre outros, pode ser interessante. Essa atividade permite alinhar o que foi

estimado, o que está sendo planejado e o que foi estimado. Para facilitar o

gerenciamento nota-se que é necessário uma mesma referência que propicia maior

visibilidade do projeto. Também facilita o registro para um histórico, o que

beneficiará a organização futuramente em etapas de melhorias.

GPR11 - A viabilidade de atingir as metas do proje to, considerando as

restrições e os recursos disponíveis, é avaliada. S e necessário, ajustes são

realizados - No inicio do projeto é realizado uma avaliação baseada em uma visão

geral dos aspectos técnicos, financeiros e humanos, como também restrições

impostas pelo cliente, condições para o desenvolvimento, ambiente interno e

externo. Ao decorrer do andamento do projeto é necessário que seja realizada uma

reavaliação da viabilidade da continuidade do projeto, que pode ser realizada nos

marcos do projeto.

GPR12 - O Plano do Projeto é revisado com todos os intere ssados e o

compromisso com ele é obtido - O compromisso é conseguido através da

interação entre todos os interessados, e é fundamental para o sucesso do projeto.

Devem existir negociações para tratar as variáveis do projeto como requisitos,

escopo, custos e prazo. As negociações sempre devem visar ganhar a confiança de

todos os interessados de que o trabalho pode ser executado dentro das restrições

acordadas entre as partes, ou seja, significa que houve um conciliamento entre as

diferenças existentes entre o que foi estimado e o que poderá ser realizado para

atingir a meta definida. Como exemplo, a negociação pode refletir na redução do

escopo para que as metas de prazos e custos sejam cumpridas.

34

GPR13 - O projeto é gerenciado utilizando-se o Pla no do Projeto e outros

planos que afetam o projeto e os resultados são doc umentados - É o

acompanhamento do dia a dia do projeto. Entende-se como uma atividade essencial

do gerenciamento acompanhar o que foi planejado, detectar problemas e corrigi-los,

em um ciclo contínuo durante todo o projeto. Qualquer tipo de acompanhamento

deve ser registrado, o acompanhamento pode ser a análise de critérios de conclusão

de tarefas, cumprimento do cronograma, uso adequado de recursos, entre outros, e

pode ser realizado por meio de ferramentas ou reuniões. Com base nos resultados

decisões devem ser tomadas.

GPR14 - O envolvimento das partes interessadas no projeto é

gerenciado - Esse resultado esperado mantém o projeto em um andamento junto

aos clientes e reduz desvios em relação às reais necessidades que o projeto deverá

atender. É necessário verificar se os compromissos assumidos pelas partes

interessadas estão sendo cumpridos ou negociados, visando identificar aqueles que

não foram satisfeitos ou que possuem um grande risco de não serem satisfeitos. É

recomendável que um plano de comunicação seja estabelecido para o

gerenciamento desse resultado esperado.

GPR15 - Revisões são realizadas em marcos do proje to e conforme

estabelecido no planejamento - Revisões em marcos ajudam a verificar de forma

mais ampla o andamento de todo o projeto, e proporciona questões sobre a

viabilidade do projeto. Os marcos do projeto precisam ser previamente definidos ao

se realizar o planejamento do projeto.

GPR16 - Registros de problemas identificados e o r esultado da análise

de questões pertinentes, incluindo dependências crí ticas, são estabelecidos e

tratados com as partes interessadas - De acordo com o guia do MPS.BR, as

atividades de revisão em marcos, analisadas no GPR15, e de monitoramento, vista

no GPR13, do projeto possibilitam a identificação de problemas que estejam

ocorrendo no projeto. Estes problemas devem ser analisados e registrados, por

exemplo, por meio de ferramentas específicas, planilhas ou outros tipos de

mecanismos de gerenciamento de problemas. Para completar o trabalho de

monitoramento do projeto, os problemas precisam ser corrigidos e gerenciados até a

sua resolução, com base em planos de ações, estabelecidos especificamente para

resolver os problemas levantados e registrados, conforme o GPR17. Caso não se

35

consiga resolver os problemas neste nível, deve-se escalonar a resolução das ações

a níveis superiores de gerência.

GPR17 - Ações para corrigir desvios em relação ao planejado e para

prevenir a repetição dos problemas identificados sã o estabelecidas,

implementadas e acompanhadas até a sua conclusão - Ações corretivas devem

ser estabelecidas para resolver problemas que possam impedir o projeto de atingir

seus objetivos se não forem resolvidos de forma adequada. As ações corretivas

definidas devem ser gerenciadas até serem concluídas. O controle dos problemas

levantados, as ações tomadas, e os responsáveis pelas ações e os resultados

devem ser registrados.

2.1.4.1.2 Gerência de requisitos

O propósito do processo Gerência de Requisitos é gerenciar os requisitos do

produto e dos componentes do produto do projeto e identificar inconsistências entre

os requisitos, os planos do projeto e os produtos de trabalho do projeto. Com a

Gerência de Requisitos, as alterações de requisitos são mais bem administradas,

diminuindo os impactos que estas possam causar aos custos, prazos e qualidade do

projeto.

Foi considerado que o processo GRE tem 5 resultados esperados, conforme

abaixo adaptado segundo a SOFTEX (2009):

GRE1 - Os requisitos são entendidos, avaliados e ac eitos junto aos

fornecedores de requisitos, utilizando critérios ob jetivos - Deve-se ter um

documento que comprove o entendimento dos requisitos, como: uma lista de

requisitos, especificação de casos de uso, ou conforme critério da organização. A

cada mudança nos requisitos deve ser realizado a aprovação da mudança com

posterior aprovação dos requisitos do projeto por todos os envolvidos do projeto,

como também obter o comprometimento dos mesmos.

GRE2 - O comprometimento da equipe técnica com os requisitos

aprovados é obtido - É necessário que exista uma forma de comprovar que houve

o comprometimento da equipe técnica com os requisitos. Após alguma mudança um

novo comprometimento da equipe técnica deve ser obtido e registrado.

36

GRE3 - A rastreabilidade bidirecional entre os req uisitos e os produtos

de trabalho é estabelecida e mantida - Servirá para avaliar o impacto das

mudanças de requisitos e em que essas mudanças irão implicar, como: nas

estimativas de escopo, nos produtos de trabalho ou nas tarefas do projeto descritas

no cronograma. Deve existir um mecanismo que permita rastrear os requisitos aos

demais produtos de trabalho.

GRE4 - Revisões em planos e produtos de trabalho d o projeto são

realizadas visando a identificar e corrigir inconsi stências em relação aos

requisitos - Deve-se realizar revisões que identifique inconsistências entre os

requisitos e os planos, atividades e produtos de trabalho do projeto. As

inconsistências devem ser registradas e ações corretivas devem ser tomadas e

acompanhadas até que sejam resolvidas as inconsistências.

GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto -

Requisitos adicionais podem ser incorporados no projeto, requisitos podem ser

retirados do projeto e/ou mudanças podem ser feitas nos requisitos já existentes. É

indicado que a organização adote uma Gerência de Mudança mais formal, pois

algumas vezes uma mudança pode atingir outros artefatos. É necessário o registro

das mudanças e a justificativa da aprovação de determinada mudança, após a

avaliação de análise de impacto que a mudança reflete no projeto (cronograma,

riscos e custo). A rastreabilidade bidirecional facilita a análise de impacto.

2.1.4.2 Nível F

O nível de maturidade F é composto pelos processos do nível de maturidade

anterior (G) acrescidos dos processos Aquisição, Gerência de Configuração,

Garantia da Qualidade, Gerência de Portfólio de Projetos e Medição.

37

2.1.4.2.1 Aquisição

O propósito do processo Aquisição é gerenciar a aquisição de produtos e

serviços que satisfaçam às necessidades do adquirente.

Conforme SOFTEX (2009), entre os resultados esperados pela execução

deste processo estão:

a) as necessidades de aquisição, as metas, os critérios de aceitação do

produto ou serviço e as estratégias de aquisição são definidos;

b) os fornecedores são identificados e selecionados com base na avaliação

das propostas e dos critérios estabelecidos;

c) é negociado e estabelecido um acordo formal entre cliente e fornecedor,

que expresse claramente as expectativas, responsabilidades e obrigações

de ambas as partes;

d) a aquisição é monitorada de forma que as condições especificadas, como

custo, cronograma e qualidade sejam atendidas. Se necessário, ações

corretivas são conduzidas;

e) o produto adquirido é incorporado ao projeto, assegurando-se que os

acordos relativos a treinamento, suporte e distribuição do produto sejam

cumpridos.

2.1.4.2.2 Gerência de configuração

O propósito do processo de Gerência de Configuração é estabelecer e manter

a integridade de todos os artefatos resultantes de um processo e disponibilizá-los a

todos os envolvidos.



a) um sistema de gerência de configuração é estabelecido e mantido;

b) os itens de configuração são identificados com base em critérios

estabelecidos e, quando sujeitos a um controle formal, são colocados sob

baseline;

38

c) as modificações em itens de configurações, assim como o

armazenamento, manuseio e a liberação de itens de configuração e

baselines são controlados;

d) auditorias são realizadas para assegurar que os itens de configuração e as

baselines estejam íntegros, completos e consistentes.

2.1.4.2.3 Garantia da qualidade

O propósito do processo Garantia da Qualidade é garantir que os produtos de

trabalho e processos estão em conformidade com os planos e recursos predefinidos.



a) a aderência dos produtos de trabalho aos padrões, procedimentos e

requisitos é avaliada ao longo do ciclo de vida do projeto e antes dos

produtos serem entregues aos clientes. Nestas avaliações são

identificadas as não conformidades aos padrões estabelecidos e os

problemas;

b) os problemas e as não conformidades são identificados, registrados e

comunicados. Ações corretivas são estabelecidas e acompanhadas até as

suas efetivas conclusões.

2.1.4.2.4 Gerência de Portfólio de Projetos

O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter

projetos que justifiquem os investimentos, de forma a atender os objetivos

estratégicos da organização.



a) as oportunidades de negócio, necessidades e os investimentos são

identificados, qualificados, priorizados e selecionados;

39

b) os recursos e orçamentos para cada projeto são identificados e alocados;

c) são estabelecidas as responsabilidades e autoridade pelo gerenciamento

dos projetos;

d) conflitos sobre recursos entre projetos são tratados e resolvidos;

e) os projetos que atendem aos acordos e requisitos são mantidos.

2.1.4.2.5 Medição

O propósito do processo Medição é coletar, analisar e armazenar os dados

relativos aos produtos desenvolvidos e aos processos implementados na

organização, de forma a apoiar os objetivos organizacionais. Esses dados são

usados constantemente para apoiar decisões e fornecer uma base objetiva de

comunicação com stakehorlders.



a) objetivos de medição são estabelecidos e mantidos a partir dos objetivos

de negócio da organização e das necessidades de informação de

processos técnicos e gerenciais;

b) um conjunto adequado de medidas é identificado ou desenvolvido,

documentado, revisado e atualizado quando necessário;

c) os procedimentos para a coleta, armazenamento e análise das medidas

são especificados;

d) os dados requeridos são coletados e analisados. Os dados e os resultados

das análises são armazenados e comunicados aos interessados.

2.1.4.3 Nível E

O nível de maturidade E é composto pelos processos dos níveis de

maturidade anteriores (G e F), acrescidos dos processos Avaliação e Melhoria do

Processo Organizacional, Definição do Processo Organizacional, Gerência de

40

Recursos Humanos e Gerência de Reutilização. No Nível E o processo Gerência de

Projetos sofre sua primeira evolução.

2.1.4.3.1 Avaliação e Melhoria do Processo Organizacional

O propósito do processo Avaliação e Melhoria do Processo Organizacional é

determinar quanto os processos padrão da organização contribuem para alcançar os

objetivos de negócio. Essa avaliação permitirá planejar e implementar melhorias

contínuas nos processos, com base no entendimento de seus pontos fortes e fracos.



a) são estabelecidos revisões dos processos padrão da organização,

realizadas em intervalos adequados para assegurar sua adequação e

efetividade, identificar seus pontos fortes, pontos fracos e oportunidades

de melhoria;

b) os objetivos de melhoria são identificados e priorizados. As mudanças nos

processos são planejados e implementados de forma controlada e com

resultados previsíveis;

c) ativos de processo organizacional são implantados na organização. As

experiências relacionadas aos processos são incorporadas aos ativos de

processo organizacional.

2.1.4.3.2 Definição do processo organizacional

O propósito do processo Definição do Processo Organizacional é definir e

manter um conjunto de ativos de processo organizacional e padrões do ambiente de

trabalho, com a indicação da aplicabilidade de cada processo.



41

a) um conjunto definido de processos padrão, com indicação de

aplicabilidade de cada processo, é estabelecido e mantido;

b) as tarefas, atividades e produtos de trabalho associados aos processos

padrão são identificados e detalhados, com as características de

desempenho esperadas do processo;

c) uma estratégia para adaptação do processo padrão é desenvolvida

considerando as necessidades dos projetos;

d) são estabelecidas e mantidas as descrições dos modelos de ciclo de vida

que serão utilizadas nos projetos, assim como o repositório de medidas e

os ambientes padrões de trabalho da organização.

2.1.4.3.3 Gerência de recursos humanos

O propósito do processo Gerência de Recursos Humanos é prover a

organização e os projetos com os recursos humanos necessários e manter suas

competências adequadas às necessidades do negócio.



a) uma revisão das necessidades estratégicas da organização e dos projetos

é realizada para identificar recursos, conhecimentos e habilidades

requeridos. De acordo com a necessidade, são desenvolvidos e indivíduos

com as habilidades e competências requeridas são identificados e

recrutados;

b) as necessidades de treinamento são identificadas, assim como uma

estratégia e um plano tático de treinamento é definido, com o objetivo de

atender as necessidades dos projetos e da organização;

c) os treinamentos de responsabilidade da organização são conduzidos e

registrados, e sua efetividade é avaliada;

d) são definidos critérios para avaliar o desempenho de grupos e indivíduos.

É realizado o monitoramento para obter informações sobre seus

desempenhos visando melhorar;

42

e) uma estratégia de gerência de conhecimento é planejada, estabelecida e

mantida para compartilhar informações na organização. É estabelecida

uma rede de especialistas, com o apoio de um mecanismo de troca de

informações entre os especialistas e os projetos, disponibilizando e

compartilhando o conhecimento na organização.

2.1.4.3.4 Gerência de reutilização

O propósito do processo Gerência de Reutilização é gerenciar o ciclo de vida

dos ativos reutilizáveis.



a) uma estratégia de gerenciamento de ativos reutilizáveis é documentada,

assim como os critérios para aceitação, certificação, classificação,

descontinuidade e avaliação desses ativos;

b) um mecanismo de armazenamento e recuperação de ativos reutilizáveis é

implantado e os dados de utilização são registrados;

c) os ativos reutilizáveis são periodicamente mantidos e suas modificações

são controladas ao longo do seu ciclo de vida. Os usuários desses ativos

são notificados sobre problemas detectados, modificações, novas versões

e descontinuidade de ativos.

2.1.4.3.5 Gerência de projetos (evolução)

O processo Gerência de Projetos sofre sua primeira evolução, retratando seu

novo propósito: gerenciar o projeto com base no processo definido para o projeto e

nos planos integrados.

Entre os resultados esperados, além de todos os resultados esperados do

processo Gerência de Projetos já implementados nos níveis anteriores, no nível E

estão:

43

a) o planejamento e as estimativas das atividades do projeto são realizados

com base no repositório de estimativas e no conjunto de ativos de

processo organizacional;

b) um processo definido para o projeto é estabelecido de acordo com a

estratégia para adaptação do processo da organização;

c) as medidas, produtos de trabalho e experiências documentadas

contribuem para os ativos de processo organizacional.

2.1.4.4 Nível D

O nível de maturidade D é composto pelos processos dos níveis de

maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de

Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação, e

Verificação.

2.1.4.4.1 Desenvolvimento de requisitos

O propósito do processo Desenvolvimento de Requisitos é definir os

requisitos do cliente, do produto e dos componentes do produto.



a) as necessidades, expectativas, restrições e objetivos do cliente são

coletados e especificados como requisitos do produto;

b) um conjunto de requisitos funcionais e não funcionais são definidos a partir

dos requisitos do cliente. Esses requisitos são refinados, validados,

elaborados e alocados;

c) são definidas as interfaces internas e externas do produto e de cada

componente. Conceitos operacionais e cenários são desenvolvidos;

d) os requisitos são analisados, usando critérios definidos, para balancear as

necessidades dos interessados com as restrições existentes.

44

2.1.4.4.2 Integração do produto

O propósito do processo Integração do Produto é reunir os componentes do

produto de maneira consistente com o projeto, demonstrando que os requisitos

funcionais e não-funcionais são satisfeitos no ambiente alvo.



a) uma estratégia de integração para os componentes do produto é

desenvolvida, assim como um ambiente para integração é estabelecido e

mantido;

b) a compatibilidade das interfaces internas e externas dos componentes do

produto é assegurada. As definições, o projeto e as mudanças nas

interfaces internas e externas são gerenciados para o produto e para os

componentes do produto;

c) cada componente do produto é verificado para confirmar que estão prontos

para a integração. Os componentes são integrados de acordo com a

sequência determinada e seguindo os procedimentos e critérios de

integração, após a qual o novo produto é validado para verificar se os

resultados obtidos estão satisfatórios;

d) uma estratégia de teste de regressão é desenvolvida e aplicada para uma

nova verificação do produto, caso ocorra uma mudança nos componentes

do produto;

e) o produto e a documentação relacionada são preparados e entregues ao

cliente.

2.1.4.4.3 Projeto e construção do produto

O propósito do processo Projeto e Construção do Produto é projetar,

desenvolver e implementar soluções para atender aos requisitos.



45

a) alternativas de solução são desenvolvidas para atender aos requisitos do

produto. Com base em cenários definidos e em critérios identificados,

soluções para o produto são selecionadas;

b) o produto, componentes de produto e interfaces entre componentes do

produto são projetados e documentados;

c) uma análise dos componentes do produto é realizada para decidir sobre

sua construção, compra ou reutilização. Os componentes do produto são

implementados e verificados de acordo com o que foi projetado;

d) a documentação é identificada, desenvolvida, disponibilizada e mantida de

acordo com critérios e padrões definidos.

2.1.4.4.4 Validação

O propósito do processo Validação é confirmar que um produto ou

componente do produto atende ao uso específico pretendido, quando instalado no

ambiente para o qual foi desenvolvido.



a) são identificados os produtos de trabalho a serem validados e uma

estratégia de validação é desenvolvida e implementada, estabelecendo

cronograma, participantes, métodos e material a ser utilizado na validação;

b) os critérios e procedimentos para validação dos produtos de trabalho são

identificados e um ambiente para validação é estabelecido;

c) atividades de validação são executadas. Os problemas são identificados,

registrados e os resultados da validação são analisados e disponibilizados

aos interessados;

d) a partir dos resultados da avaliação é identificado se os produtos estão

prontos para uso ou se é preciso fazer correções.

46

2.1.4.4.5 Verificação

O propósito do processo Verificação é confirmar que cada serviço e produto

de trabalho do processo ou do projeto atende aos requisitos especificados.



a) são identificados os produtos de trabalho a serem verificados e uma

estratégia de verificação é desenvolvida e implementada, estabelecendo

cronograma, revisores, métodos e material a ser utilizado na verificação;

b) os critérios e procedimentos para verificação dos produtos de trabalho são

identificados e um ambiente para verificação é estabelecido;

c) atividades de verificação são executadas. Os problemas são identificados,

registrados e os resultados da verificação são analisados e

disponibilizados aos interessados;

d) os defeitos e não conformidades são identificadas e registradas, assim

como as ações corretivas.

2.1.4.5 Nível C

O nível de maturidade C é composto pelos processos dos níveis de

maturidade anteriores (G ao D), acrescidos dos processos Desenvolvimento para

Reutilização, Gerência de Decisões e Gerência de Riscos.

2.1.4.5.1 Desenvolvimento para reutilização

O propósito do processo Desenvolvimento para Reutilização é identificar

oportunidades de reutilização sistemática de ativos na organização e, se possível,

estabelecer um programa de reutilização para desenvolver ativos a partir de

engenharia de domínios de aplicação.

47



a) são identificados os domínios de aplicação em que serão verificadas

oportunidades de reutilização de ativos, ou em que se pretende praticar

reutilização, detectando os respectivos potencias de reutilização;

b) a capacidade de reutilização sistemática da organização é avaliada e um

programa de reutilização é planejado e implantado com a finalidade de

atender às necessidades de reutilização de domínios;

c) propostas de reutilização são avaliadas para garantir que o resultado seja

apropriado para a aplicação alvo;

d) são selecionadas formas de representação para modelos de domínios e

arquiteturas;

e) um modelo de domínio e uma arquitetura de domínio são desenvolvidos e

mantidos;

f) ativos do domínio são especificados, adquiridos ou desenvolvidos, e

mantidos por todo o seu ciclo de vida.

2.1.4.5.2 Gerência de decisões

O propósito do processo Gerência de Decisões é analisar possíveis decisões

críticas usando um processo formal, com critérios estabelecidos, para avaliação das

alternativas identificadas.



a) guias organizacionais para a gerência de decisões são estabelecidos e

mantidos;

b) critérios para avaliação das alternativas de solução são estabelecidos e

mantidos em ordem de importância, e são selecionados de acordo com

sua viabilidade de aplicação;

c) o problema ou questão a ser objeto de um processo formal de tomada de

decisão é definido e alternativas de solução aceitáveis são identificadas;

48

d) decisões são tomadas com base na avaliação das alternativas utilizando

os critérios de avaliação estabelecidos.

2.1.4.5.3 Gerência de riscos

O propósito do processo Gerência de Riscos é identificar, analisar, tratar,

monitorar e reduzir continuamente os riscos em nível organizacional, como mudança

nas hierarquias superiores da empresa, e de projeto, como atrasos no cronograma.



a) é determinado o escopo da gerência de riscos;

b) as origens e as categorias de riscos são determinadas. São definidos os

parâmetros usados para analisar riscos, categorizá-los e controlar o

esforço da gerência;

c) estratégias apropriadas para a gerência de riscos são definidas e

implementadas. Os riscos do projeto são identificados e documentados;

d) os riscos são priorizados, estimados e classificados de acordo com as

categorias e os parâmetros definidos;

e) são desenvolvidos planos para a redução de riscos. A situação de cada

risco é periodicamente monitorada e o plano de redução de riscos é

implementado;

f) ações apropriadas são executadas para corrigir ou evitar o impacto do

risco.

2.1.4.6 Nível B

Este nível de maturidade é composto pelos processos dos níveis de

maturidade anteriores (G ao C). Neste nível o processo de Gerência de Projetos

sofre sua segunda evolução, sendo acrescentados novos resultados para atender

49

aos objetivos de gerenciamento quantitativo. Este nível não possui processos

específicos.

2.1.4.6.1 Gerência de projetos (evolução)

O propósito do processo Gerência de Projetos evolui à medida que a

organização cresce em maturidade. No nível B, a gerência de projetos passa a ter

um enfoque quantitativo, refletindo a alta maturidade que se espera da organização.

Alguns resultados evoluem e outros são incorporados. Entre os resultados

esperados, além de todos os resultados esperados do processo Gerência de

Projetos já implementados nos níveis anteriores, no nível B estão:

a) os subprocessos mais adequados para compor o processo definido para o

projeto são selecionados com base na estabilidade histórica, em dados de

capacidade e em outros critérios previamente estabelecidos;

b) são estabelecidos e mantidos os objetivos para a qualidade do produto e

para o desempenho do processo definido para o projeto;

c) são escolhidos os subprocessos do processo definido para o projeto e que

serão gerenciados estatisticamente. São identificados os atributos por

meio dos quais cada subprocesso será gerenciado estatisticamente;

d) o projeto é monitorado para garantir que a qualidade e o desempenho do

processo serão atingidos, e se necessários, ações corretivas são

identificadas;

e) utilizando medidas e técnicas de análise estatística previamente

selecionadas, é estabelecido e mantido o entendimento da variação dos

subprocessos escolhidos para gerência quantitativa;

f) é monitorado o desempenho dos subprocessos para determinar a sua

capacidade de satisfazer os seus objetivos para qualidade e desempenho.

Quando necessário, ações são identificadas para tratar deficiências dos

subprocessos;

g) os dados estatísticos e de gerência da qualidade são incorporados ao

repositório de medidas da organização.

50

2.1.4.7 Nível A

Este nível de maturidade é composto pelos processos dos níveis de

maturidade anteriores (G ao B) e não possui processos específicos.

No nível A o conjunto de processos padrão da organização deve ser

otimizado por meio de alterações e adaptações incrementais e inovadoras para

atender aos objetivos de negócio atuais e projetados.

A efetividade e eficiência dos processos são melhoradas por meio de um

esforço planejado e intencional. Para identificar mudanças no processo é

implementada uma abordagem planejada e ordenada, a fim de introduzi-las de

forma adequada minimizando as interrupções não desejadas na operação do

software. A efetividade dessas mudanças é avaliada com base nos resultados atuais

e, quando necessário, ajustes são realizados para alcançar os objetivos de

qualidade e de desempenho do processo.

No nível A ações devem ser executadas para remover causas comuns de

variação nos processos da organização. As causas comuns de variação se referem

à variação de processo que existe devido à interação normal e esperada entre os

componentes de um processo.

São selecionadas e implementadas melhorias de processos e de tecnologias

nos processos selecionados para controle estatístico, contribuindo para o alcance de

objetivos de melhoria de processo da organização.

2.2 METODOLOGIAS ÁGEIS

Em meados dos anos 90, integrantes da comunidade de desenvolvimento de

software, começaram a questionar os processos tradicionais de desenvolvimento,

julgando-os pouco efetivos e, muitas vezes, impossíveis de serem colocados em

prática (Higsmith apud Dias, 2005).

Produtos eram desenvolvidos a altos custos e ainda levavam muito tempo

para chegar ao mercado, gerando enormes perdas de receita quando ainda não

eram abandonados durante a sua execução.

51

Diante deste problema, representantes de diversas metodologias de

desenvolvimento de software reuniram-se em Fevereiro de 2001 com o objetivo de

buscar alternativas para o pesado processo de desenvolvimento orientado à

documentação (Highsmith, 2001).

Beck et al. apud Dias (2005, p. 72) lembra que estes especialistas foram

enfáticos em dizer que não eram contra métodos, processos ou metodologias, sendo

que muitos até mencionaram o desejo de resgatar o significado e a credibilidade

destas palavras. Defendiam a modelagem e a documentação, mas não em excesso.

Planejavam, mas reconheciam os limites do planejamento e da previsibilidade em

um ambiente turbulento.

Os participantes, apesar de não concordarem em muitas coisas, encontraram

consenso em quatro valores, descritos a seguir por Highsmith (2010, p. 16) como o

manifesto ágil:

Nós estamos descobrindo melhores formas de desenvolver (produtos) fazendo e auxiliando outros a faze-los. Através deste trabalho nós temos tido que valorizar:

- Indivíduos e interações mais que processos e ferramentas;

- Software funcionando mais que documentação compreensível;

- Colaboração do cliente mais que negociação de contratos;

- Responder à mudança mais que seguir um plano.

Isto é, enquanto há valores nos itens à direita, nós valorizamos mais os itens da esquerda.

Existem diversas metodologias de desenvolvimento de software disponíveis,

como Scrum, Extreme Programming, Lean Software Development, Crystal, DSDM,

FDD, entre outras.

Todas elas partilham muito da mesma filosofia, bem como possuem

características e práticas semelhantes, mas do ponto de vista de implementação,

cada qual possui a sua própria abordagem de práticas, terminologias e táticas

(Version One, 2010).

Um dos objetos deste estudo é o Scrum, que será abordado em mais

detalhes no item 2.2.1.

52

2.2.1 Scrum

O Scrum é uma das metodologias ágeis mais conhecidas. Jeff Shuterland, e

Ken Schwaber, seus idealizadores, o descrevem como um simples framework usado

para organizar times e garantir a entrega de trabalho com produtividade e alta

qualidade. Tem o seu nome baseado em um estudo de Takeuchi e Nonaka

publicado pela Harvard Business Review em 1986 onde sugerem que projetos com

equipes menores e times multidisciplinares possuem historicamente melhores

resultados. Eles descrevem também que estes times se assemelham à formação

“Scrum” do jogo de rugby, daí o nome dado à metodologia (Shuterland; Schwaber,

2007, p. 14).

A seguir, uma breve descrição de todo o ciclo do Scrum feita por Deemer, et

al. (2010 p. 5):

O Scrum é um framework incremental para o desenvolvimento de projetos e produtos ou aplicações iterativo. Ele estrutura o desenvolvimento em ciclos de trabalho chamados Sprints. Essas iterações têm não mais do que um mês de duração, e seguem uma após outra sem pausas. As Sprints possuem uma determinada duração – elas terminam em uma data específica com o trabalho completo ou não e nunca são estendidas. No início de cada Sprint, um time multidisciplinar seleciona itens (requisitos de cliente) de uma lista priorizada. Durante a Sprint, os itens escolhidos não mudam. A cada dia o time se reúne brevemente para inspecionar o progresso e ajusta os próximos passos para completar o trabalho restante. No fim de cada Sprint, o time revisa a Sprint com os stakeholders e demonstra o que foi construído. As pessoas obtêm feedback que pode ser incorporado nas próximas Sprints. O Scrum enfatiza que o produto a ser construído estará realmente ‘finalizado’ ao final da Sprint; no caso de software, isso significa que o código estará integrado, totalmente testado e potencialmente pronto para ser entregue.

Esta é uma abordagem que permite o desenvolvimento de produtos com

maior rapidez e de forma flexível, alem de estimular novas formas de aprendizagem

e pensamento em diversos níveis e funções da organização.

A seguir (Figura 5) uma visão geral do Scrum:

53

Figura 5 - Visão geral do Scrum

Fonte: Schwaber, 2004.

Os principais papéis, artefatos e eventos são resumidos na Figura 6.

54

Figura 6 - Papéis, responsabilidades e eventos do Scrum

Fonte: EMC Consulting Blogs.

2.2.1.1 Papéis e responsabilidades

O Scrum possui três papéis principais: o Product Owner, o Scrum Master e o

Time, que juntos formam o Scrum Team. A seguir serão apresentadas as

responsabilidades de cada um.

2.2.1.1.1 Product Owner

O Product Owner é o membro responsável por maximizar o retorno sobre o

investimento (ROI) a partir da identificação das características do produto e

traduzindo-as em uma lista de requisitos priorizada, decidindo o que deve ficar no

topo da lista para a próxima Sprint, além de repriorizar e refinar os requisitos do

produto. O Product Owner também possui a responsabilidade pelo sucesso e pelo

55

fracasso do produto, assumindo-o como um produto comercial. No caso de uma

aplicação interna, ele não é responsável pelo ROI, em seu sentido comercial, mas

ainda responsável por maximizá-lo no sentido de escolhas – a cada Sprint – os itens

com maior valor ao negócio que possuam menor custo de desenvolvimento

(Deemer, et al., 2010, p. 5).

Shuterland; Schwaber (2007, p. 14) descrevem como responsabilidades do

Product Owner:

1 definir as características do produto;

2 decidir a data das entregas e o seu conteúdo;

3 ser responsável pelos ganhos com o produto (ROI);

4 priorizar as atividades de acordo com o seu valor para o mercado;

5 ajustar os requisitos e priorizá-los a cada 30 dias, ou quando necessário;

6 aceitar ou rejeitar os resultados do trabalho realizado.

2.2.1.1.2 O Scrum Master

De acordo com Shuterland; Schwaber (2007, p. 14), o Scrum Master é um

líder de equipes facilitador que trabalha próximo ao Product Owner. Ele deve:

1 assegurar que o time está sendo totalmente funcional e produtivo;

2 fazer com que exista uma cooperação mútua entre os papéis e funções;

3 remover impedimentos;

4 blindar o time de influências externas;

5 garantir que o processo está sendo seguido, inclusive fazendo convites

para as reuniões Daily Scrum, Sprint Review e Sprint Planning.

O Scrum Master se certifica que todos (incluindo o Product Owner e a

gerência) entendam e sigam as práticas do Scrum e ajuda a guiar a organização

para a difícil mudança, para alcançar sucesso com o desenvolvimento ágil (Deemer,

et al, 2010, p. 6).

56

2.2.1.1.3 O Time

O time é responsável pela construção do produto que o Product Owner

especificou. O time no Scrum é multidisciplinar, isto é, possui toda a expertise

necessária para entregar o produto finalizado e pronto para entrar em produção ao

final de cada Sprint. É também “auto-organizável” (auto-gerenciável), com alto grau

de autonomia e poder de decisão (Deemer, et. al, 2010 p. 6).

Shuterland; Schwaber (2007, p. 15) descrevem as responsabilidades do time:

1 times de no mínimo 2 e no máximo 7 membros;

2 seleciona o objetivo da Sprint e especifica os resultados do trabalho;

3 tem o direito de fazer tudo o que for necessário, considerando limites do

projeto, para alcançar o objetivo da Sprint;

4 organiza a si mesmo e o seu trabalho;

5 apresenta o produto final ao Product Owner.

2.2.1.2 Artefatos

No Scrum há basicamente três artefatos, o Product Backlog, o Sprint Backlog

e o Burndown Chart. Alguns autores ainda citam o Release Burndown Chart, o

Product Burndown Chart, entre outros. A seguir será apresentada a descrição dos

principais artefatos do Scrum.

2.2.1.2.1 Product Backlog

O Product Backlog é uma lista priorizada de requisitos gerenciada pelo

Product Owner. Nesta lista, os requisitos são ordenados pela sua prioridade, além

disto, cada item é composto basicamente de um código, a descrição do requisito e a

sua estimativa grosseira de esforço.

57

Esta lista possui uma atualização constante, onde o Product Owner deve

reorganizar os itens de forma que os itens selecionados para uma Sprint sejam

aqueles que mais agreguem valor ao produto com o menor esforço consumido.

A seguir um exemplo de um Product Backlog:

Product Backlog

ID Nome da

estória Importância Estimativa Como Demonstrar Notas

1 Depósito 30 5 Logar-se; abrir pg de

deposito; depositar R$

100,00; ir para pg do

saldo e verificar se

aumentou R$ 100,00.

Precisa de um

diagrama UML e

sequencia. Não é

necessário

criptografia por

enquanto.

2 Verificar seu

próprio

histórico de

transações

10 8 Logar-se; clicar em

“transações”; Fazer

um depósito; Voltar

para transações e

verificar se o novo

depósito é listado.

Usar paginação

para evitar

consultas muito

grandes ao banco

de dados. Projetar

de forma similar à

página de

visualização de

usuários.

Quadro 2 - Exemplo de Product Backlog

Fonte: Kniberg (2009, p. 20).

É comum a utilização de boas práticas na construção de requisitos no Scrum,

como abordados a seguir nos itens User Stories e Story Cards.

2.2.1.2.2 Sprint Backlog

O Sprint Backlog é composto de todas as atividades geradas a partir dos itens

selecionados no Product Backlog durante a Sprint Planning, porém dividido em

tarefas pelo próprio time e tendo todas as tarefas estimadas.

58

Alguns autores, como Schwaber (2004), Highsmith (2010) e Kniberg (2007)

divergem em relação à unidade de tempo ou esforço das estimativas. Alguns

trabalham com pontos por User Story, outros trabalham com o número de User

Stories, ou ainda o número de horas para cada tarefa, isto dependerá muito do

desempenho de cada time e como preferem acompanhar o seu desempenho no

Burndown Chart.

2.2.1.2.3 Burndown Chart

O Burndown Chart é um gráfico que permite acompanhar o andamento da

Sprint, de diversas Sprints ou ainda do projeto todo, de acordo com a necessidade.

O gráfico é composto de um eixo horizontal representando o tempo decorrido,

número de User Stories ou ainda Story Points, de acordo com a preferência da

organização e um eixo vertical representando o trabalho restante para a conclusão

dos requisitos restantes, como apresentado na figura a seguir (Figura 7):

Figura 7 - Burndown Chart em horas

Fonte: Shuterland; Schwaber (2007, p. 28).

59

Conforme Conforto (2009, p.100), o autor concorda que o modelo do gráfico

de Burndown para monitoramento e controle das entregas do projeto em relação às

iterações é muito utilizado nas aplicações dos princípios do gerenciamento ágil de

projetos, principalmente na área de desenvolvimento de software. É mais indicado

quando se têm definidas as iterações do projeto e uma visão sobre a quantidade de

entregas do projeto por iteração, mesmo que esta visão não esteja refinada.

Cohn (2005 apud CONFORTO, 2009 p.102):

O Burndown é uma forma simplificada e visual para monitoramento, avaliação e apresentação do progresso do projeto utilizando duas variáveis de entregas (escopo) e iterações (tempo) […] contribui como um guia para a equipe de projeto saber se está indo na direção correta das metas e objetivos do projeto, e mostra uma visão do backlog restante para a conclusão do projeto.

Na figura a seguir (Figura 8) um exemplo de Burndown Chart de tarefas:

Figura 8 - Burndown Chart de tarefas

Fonte: Highsmith, 2010.

60

2.2.1.3 Eventos

No Scrum há eventos formais durante a execução do seu processo, o Sprint

Planning, o Daily Standup Meeting, Sprint Review e a Sprint Retrospective. A seguir

a descrição de cada um.

2.2.1.3.1 Sprint Planning Meeting

O Sprint Planning Meeting é a reunião onde são selecionados os itens para a

execução de uma Sprint de acordo com a sua prioridade, defendida e revisada

previamente pelo Product Owner. Nesta reunião devem estar presentes o time, o

Scrum Master e o Product Owner.

Para cada item selecionado no Product Backlog, o time tira as suas dúvidas

quanto ao seu contexto de desenvolvimento e o quebra em atividades menores.

Para cada atividade o time também faz a estimativa de execução em horas.

É importante que cada participante tenha em mente a definição de seu papel

na reunião, o Product Owner é o único que pode reavaliar o escopo e modificar a

escala de importância da User Story, enquanto o time é o único que pode estimar o

tempo para realizar uma única User Story.

O Product Owner influencia quais estórias estarão na reunião de

planejamento da Sprint, uma vez que é ele quem pode reordenar a priorização das

estórias, modificar o escopo até que o time acredite que a User Story caberá na

Sprint, além de poder dividir uma User Story em User Stories menores.

Na Sprint Planning também é definido o tamanho da Sprint, e serão

selecionados itens no Product Backlog até que a capacidade de produção do time

seja preenchida.

Quanto à duração das Sprints, Kniberg (2007, p.30) aponta que se deve

experimentar o tamanho ideal, pois enquanto Product Owners gostam de Sprints

curtas, desenvolvedores preferem Sprints longas.

Segundo (Kniberg, 2007, p. 30):

61

Bem, Sprints curtos são bons. Eles permitem que a equipe seja ‘ágil’, isto é, mude de direção freqüentemente. Sprints curtos = ciclo curto de feedback = entregas mais freqüentes = feedback mais freqüente do cliente = menos tempo perdido, indo na direção errada = aprender e melhorar rápido, etc.

Entretanto, Sprints longos são bons também. A equipe tem mais tempo para ganhar ritmo, ela tem mais espaço para se recuperar dos problemas, e conseguir atingir o objetivo do Sprint, você tem menos overhead em termos de reuniões de planejamento, apresentações, etc.

Deemer, et. al (2010, p. 14) complementa que a capacidade produtiva de uma

equipe ainda deve considerar a quantidade de horas disponíveis de cada um dos

membros do time, desconsiderando o seu tempo gasto com outras atividades, como

manutenção de outros projetos, reuniões diversas, leitura e edição de emails, etc.

2.2.1.3.2 Daily Standup Meeting

A Daily Standup Meeting ou Daily Scrum Meeting é uma reunião realizada

diariamente com todos os integrantes do time e o Scrum Master, em pé e com

duração máxima de 15 minutos e serve para que o time acompanhe o andamento da

Sprint, para isso, cada membro do time descreve rapidamente aos demais membros

do time três coisas:

a) o que foi realizado no dia anterior;

b) o que será feito no dia atual;

c) relata algo que esteja ou venha a impedir o andamento das suas

atividades.

Podem ainda haver outros participantes, como o Product Owner, gerentes e

demais interessados quando necessário para a resolução de eventuais dúvidas.

Durante a reunião, o Scrum Master toma nota daquilo que possa impedir os

objetivos da Sprint e responsabiliza-se por resolvê-lo, deixando o time focado na

realização das atividades.

Os participantes devem estar cientes que não deve haver discussões mais

aprofundadas sobre os temas abordados caso existam, estes devem ser discutidos

após a Daily Standup Meeting.

Após a reunião todos os membros do time atualizam os status das suas

tarefas para que o Sprint Burndown Chart possa ser atualizado.

62

2.2.1.3.3 Sprint Review Meeting

Ao final da Sprint, o time reúne-se com o Scrum Master e o Product Owner e

demais interessados, caso necessário, para que o novo produto seja apresentado. O

Product Owner, neste momento pode decidir se os objetivos da Sprint foram

atendidos ou não.

Caso seja encontrado algum problema, este será adicionado ao Product

Backlog e repriorizado conforme o Product Owner achar necessário.

Para Deemer, et. al (2010, p. 14) ainda é necessário que o Scrum Master

certifique-se que todos os membros do time tenham o conceito de “Definition of

Done” (DoD) bem definido, para que durante a Sprint Review não ocorram

equívocos quanto à qualidade do produto que deveria ter sido entregue.

O time tem a responsabilidade de manter a qualidade do sistema sob todas

as circunstâncias e isso não é negociável com o Product Owner. Para um sistema de

software é necessário distinguir entre qualidade externa e qualidade interna.

A qualidade externa refere-se a interface e usabilidade, alguns autores

consideram que o produto até pode ser lançado em um release com baixa qualidade

externa contanto que haja o intuito de melhorá-la posteriormente, por isso pode ser

tratada como escopo pelo Product Owner.

A qualidade interna, que refere-se a questões que normalmente não são

visíveis ao usuário, como consistência do projeto do sistema, cobertura dos testes,

facilidade de leitura do código e refactoring, mas que têm profundos efeitos na

manutenibilidade do sistema não são negociáveis porque comprometem a qualidade

final do produto. Dificilmente se recupera a perda da qualidade interna conforme

concorda Kniberg (2007, p. 28).

Para Kniberg (2007, p. 61) uma apresentação do Sprint bem feita tem efeitos

profundos:

a) a equipe ganha crédito pelo que fez e se sente bem com isso;

b) outros aprendem o que a equipe está fazendo;

c) a apresentação atrai o feedback dos stakeholders;

d) apresentações devem ser eventos sociais em que equipes diferentes

podem interagir umas com as outras e podem discutir seu trabalho;

63

e) a apresentação força a equipe a terminar as coisas e liberá-las, impedindo

que coisas parcialmente prontas poluam o próximo Sprint.

Kniberg (2007, p 62) ainda propõe um Checklist para as apresentações de

Sprint conforme abaixo:

a) apresentar claramente o objetivo da Sprint, e descrever o produto

rapidamente;

b) focar em demonstrar o código funcionando e não em enfeitar uma

apresentação;

c) manter um ritmo para que a apresentação seja rápida ao invés de bonita;

d) deixar de fora detalhes técnicos e focar no que foi feito, não no como foi

feito;

e) se for possível deixar a audiência testar o produto;

f) mencionar correções e bugs, mas não os demonstrar para não tomar

muito tempo e desviar a atenção do foco principal.

2.2.1.3.4 Sprint Retrospective Meeting

Após a Sprint Review, alguns times continuam reunidos para que seja

realizada a Sprint Retrospective. Esta reunião serve para que sejam discutidas

questões percebidas pelo time durante a execução da Sprint. Para isto devem ser

levantadas as seguintes questões:

a) o que deu certo durante a execução da Sprint;

b) o que não deu certo durante a execução da Sprint;

c) o que poderia ser melhorado.

De acordo com o que for levantado ou sugerido, podem ser aplicadas

correções ao processo e avaliadas ao final da próxima Sprint.

Neste momento, o time terá a oportunidade de analisar o resultado e a forma

como a Sprint foi realizada. De acordo com o que for levantado ou sugerido, serão

geradas melhorias para adaptar a forma de trabalho a fim de melhorar o resultado

das próximas Sprints. Esta atitude de analisar e adaptar estimula a melhoria

contínua em um projeto de desenvolvimento de produto. Ao final da próxima Sprint

64

as correções aplicadas aos processos serão novamente avaliadas para o time se

certificar do efeito da melhoria no processo.

Para Kniberg (2007, p. 64) sem a reunião de retrospectiva percebe-se que as

equipes cometem os mesmos erros sempre. Esse autor propõe uma forma de

realizar a retrospectiva:

a) aloca-se de 1 a 3 horas;

b) participam o Product Owner, Scrum Master e a equipe toda;

c) deve ocorrer em um local como uma sala fechada, sem interrupções;

d) distante do espaço de trabalho para não perder a atenção;

e) alguém é designado como secretário;

f) o Scrum Master mostra o Sprint Backlog e com a ajuda da equipe, resume

a Sprint, eventos e decisões importantes;

g) há “rodadas”. Cada membro pode dizer, sem ser interrompido, o que acha

que foi bom, o que acha que poderia ser melhor, o que gostariam de fazer

diferente na próxima Sprint;

h) compara-se a velocidade estimada com a realizada. Se houver grande

diferença analisa-se o motivo;

i) quando o tempo está acabando o Scrum Master resume o que de concreto

pode ser feito melhor para o próximo Sprint.

Pode-se fazer também um quadro de retrospectiva, conforme apresentado

abaixo, que reunirá as opiniões de melhoria.

Bom Poderia ter sido melhor Melhorias

“se pudéssemos refazer o

mesmo Sprint novamente,

faríamos as coisas do

mesmo modo?”;

“se pudéssemos refazer o

mesmo Sprint novamente,

faríamos as coisas de uma

maneira diferente?”;

idéias concretas sobre como

podemos melhorar no futuro;

Quadro 3 - Resultados retrospectiva

Fonte: Kniberg (2007 p. 65).

65

2.2.1.4 Boas práticas utilizadas no Scrum

A seguir são abordadas algumas boas práticas comumente utilizadas no

Scrum.

2.2.1.4.1 Product Vision Box

A finalidade principal de uma Product Vision Box é proporcionar ao time uma

visão única em relação ao produto a ser desenvolvido, forçando os participantes a

pensar no produto de uma forma mais lúdica.

Highsmith (2010) recomenda que, após a identificação de uma oportunidade

de negócio formulada pelo Product Owner, deve-se reunir o time inteiro e outros

interessados, e formar grupos de 4 a 6 membros, cuja tarefa é construir a caixa do

produto, frente e verso.

A construção da caixa deve envolver a definição dos seguintes itens:

a) o nome do produto;

b) uma ilustração do produto;

c) três ou quatro características importantes na frente da caixa;

d) a descrição detalhada das funcionalidades no verso da caixa;

e) os requisitos operacionais do produto.

A seguir um exemplo de uma Product Vision Box:

66

Figura 9 - Exemplo de Product Vision Box

Fonte: Highsmith (2010, p. 97).

Normalmente a criação de uma Product Vision Box estimula discussões sobre

as features e o verdadeiro público-alvo do produto.

Após a construção das caixas, cada grupo apresenta o seu “produto” e então

os diferentes pontos de vista são postos à prova, ficando somente os pontos em que

todos concordam (Highsmith, 2010 p.97).

Juntamente com a Product Vision Box, normalmente é também criada a

Elevator Statement, apresentada no item a seguir.

67

2.2.1.4.2 Elevator Statement

A Elevator Statement é uma importante etapa para a construção de um novo

produto. Apesar de ser uma curta frase, é um exercício interessante para a

apresentação da verdadeira finalidade do produto, bem como para a exploração dos

seus diferenciais em relação aos produtos similares no mercado.

A Elevator Statement também ajudará a equipe a se manter focada nos

aspectos críticos do produto durante a etapa de construção mesmo quando os

detalhes mudarem, pois se perde facilmente a visão do todo quando o time estiver

trabalhando problemas menores, durante as iterações (Sprints).

A idéia principal da Elevator Statement é permitir que alguém faça uma breve

apresentação de um produto ou idéia durante uma conversa de elevador, ou seja,

em pouco mais de um minuto.

Highsmith (2010) sugere que esta técnica seja desenvolvida juntamente com

a Product Vision Box durante a etapa de Visão (envisioning), a fim de descrever o

público alvo, o benefício principal e a vantagem competitiva do produto a ser

desenvolvido.

Largamente utilizada em outras áreas que não o desenvolvimento de

software, é um dos itens necessários para a construção do artefato de visão da

metodologia clássica de desenvolvimento de software, Rational Unified Process

(RUP), chamado de Sentença de Posição do Produto.

Uma Elevator Statement possui a seguinte estrutura:

Para [cliente-alvo]

Quem [indique a necessidade ou oportunidade]

O (nome do produto) é um(a) [categoria do produto]

Que [indique o principal benefício; ou seja, a

razão convincente que motiva a compra]

Diferente de [principal alternativa da concorrência]

Nosso produto [indique a principal diferença]

Quadro 4 - Estrutura de uma Elevator Statement

Fonte: RUP, 2001.

A seguir um exemplo:

68

Para Este produto está destinado ao

treinamento de pilotos da aeronave

ERJ145 da Embraer.

Quem Piloto civil e/ou militar.

O STI É um sistema para o treinamento de

pilotos que é composto de um simulador

da cabine da aeronave do tipo ERJ145

em escala 1:1 e de um Sistema Tutor

inteligente composto de instruções e

simulações necessárias para o

treinamento de pilotos desta aeronave.

Que É uma solução encontrada para auxiliar

um professor na tarefa de treinamento

de pilotos num ambiente gráfico e

interativo com simulações que retratam a

realidade de cada sistema e testes que

avaliam o aprendizado do aprendiz

assim como a oportunidade em oferecer

a esses aprendizes o treinamento em

um simulador da cabine do ERJ145 em

escala 1:1.

Diferente das Simulações convencionais, pois retrata

todos os procedimentos desta aeronave

de forma concisa e fiel, abordando todos

os sistemas e componentes que a

compõem.

Nosso produto Possui a capacidade de oferecer ao

aprendiz um ambiente simulado que

retrata todos os sistemas e

procedimentos a serem tomados na

aeronave ERJ145 da Embraer.

Quadro 5 - Exemplo de Elevator Statement

Fonte: UNIFEI - Programa de Parceria em Inovação Tecnológica com Empresas, 2003.

69

2.2.1.4.3 Feature Breakdown Structure

FBS, ou Feature Breakdown Struture, é uma lista de funcionalidades do

sistema, organizada por áreas, sendo muito útil na construção do Backlog.

Highmith (2010) aponta que uma FBS pode ser usada para descrever o

modelo de arquitetura tanto para projetos de hardware e software.

A idéia principal da FBS é a utilização de funcionalidades, as Features, sendo

que cada uma poderá representar um ou mais itens do Product Backlog.

As principais características de uma Feature são:

a) deve ser importante para o cliente e deve agregar valor;

b) pode ser um passo de um caso de uso ou mesmo o próprio caso de uso;

c) deve mapear os passos em uma atividade de negócio.

Como representado na figura abaixo, a FBS pode agrupar um conjunto de

funcionalidades de uma aplicação por áreas e atividades de negócio.

Figura 10 - Organização de uma FBS

Fonte: Revista Visão Ágil (edição 5).

A FBS também torna-se importante quando se faz necessário orçar o esforço

para a construção de determinada área do produto, já que permitirá explorar uma

feature/questão em um nível mais detalhado.

70

2.2.1.4.4 Project Data Sheet

Um Project Data Sheet (PDS) é um resumo de uma página do projeto a ser

executado.

Enquanto a Product Vision Box tenta explorar as capacidades do produto, a

PDS limita o projeto considerando seus objetivos e restrições.

Highsmith (2010, p. 105) define a PDS como:

[...] um resumo de uma pagina contendo os principais objetivos de negócio e qualidade, capacidades do produto e informações sobre o gerenciamento do projeto. É um documento simples e de grande impacto em toda a comunidade do projeto cujo formato reduzido permite relembrá-los constantemente dos aspectos estratégicos do projeto.

A seguir um exemplo de uma Project Data Sheet:

71

Project Name: Desenvolvimento de CRM Líder do projeto: Braxton Quivera

Gerente de produto: Roger Jones

Patrocinador executivo: Adrian Poledra

Objetivos de qualidade

Defeitos: 25% abaixo da média da indústria

Todos os defeitos com severidade 1 e 2

corrigidos

Testes automatizdos completamente

implementados

Complexidade ciclomática média > 10

Avaliação da qualidade > 4 (confiabilidade

e adaptabilidade)

Orientações de performance:

Call Center com volume de 3500 ligações/dia

Acesso web de abrangência mundial

Treinamento exigido < 1/2 dia

Orientações da arquitetura:

Integrar efetivamente com sistema ERP

Maximizar a reutilização de componentes

Fixo Flexível Aceito Alvo

Escopo X 12,500 PF

Prazo X =/- 6 semanas

Custo +/- $0.5 milhão

Marcos principais do projeto:

Marketing exceto Call center 30/9/09

Call Center 15/1/10

Gerenciamento de vendas 30/3/10

Gerenciamento de pedidos 30/6/10

Questões e riscos:

Custos de desenvolvimento são difíceis de

calcular

Pessoal de vendas relutante em usar o novo

sistema

Entendimento dos requisitos entre todos os

grupos parece ser difícil

Gerir Acompanhamento

Colocação de propaganda

Serviço de call center

Capacidade:

Gerenciamento de vendas

Análise de venda

Prospecção

Gerenciamento por território

Marketing

Gerir oportunidades de negócios

Processamento de pedidos mais preciso

ROI médio > 14%

Matriz de equilíbrio:

Custo por atraso no projeto/mês: $50.000

Fator de exploração: 8

O sistema precisa estar operando em

30/9/09 e custar menos de $2.5 milhões

Objetivos de negócio:

Melhorar o serviço ao cliente

Reduzir material impresso

Declaração de objetivo do projeto:

O objetivo é construir uma aplicação CRM

em ambiente Web que inclua busca por

vendas, gerenciamento de pedidos,

gerenciamento de vendas e marketing.

Project Data Sheet

Data de início do projeto: 1/3/2009

Clientes:

Marketing

Call Center

Vendas

Contabilidade

Quadro 6 - Project Data Sheet

Fonte: Highsmith (2010, p. 106).

72

2.2.1.4.5 Plano de Release

O Plano de Release é desenvolvido durante a Release Planning Meeting e

serve para estabelecer as metas de uma release. Durante essa reunião são

selecionados os itens com as maiores prioridades do Product Backlog, que deverão

ser desenvolvidos e entregues. São estabelecidas também uma data de entrega,

esforço e custos estimados. A data de entrega deve ser planejada de forma que o

produto tenha um número suficiente de incrementos, gerando assim valor para o

cliente. Durante as Sprints os itens do Plano de Release poderão ser inspecionados

e modificados.

Figura 11 - Plano de release

Fonte: Highsmith (2010, p.192).

73

2.2.1.4.6 User Stories

Uma User Story ou estória é basicamente uma forma de declarar um

requisito, utilizada principalmente por equipes ágeis para representar algo que trará

valor aos usuários do sistema.

As User Stories foram criadas como uma alternativa aos Use Cases para a

definição de requisitos, que tendem a exigir a elaboração de documentos mais

extensos, além de facilitar o processo de estimativa.

COHN (2004) comenta que as User Stories foram introduzidas pela

metodologia ágil Extreme Programming (XP), e as descreve como curtas descrições

de funcionalidades contadas através da perspectiva dos usuários ou consumidores

do sistema.

A seguir a estrutura mais comum de uma User Story:

Como <papel do usuário> quero <objetivo> para que <razão>

Quadro 7 - Estrutura de uma User Story

Fonte: COHN, 2009.

As User Stories são largamente utilizadas na construção e na manutenção de

Product Backlogs em empresas que utilizam Scrum para o desenvolvimento de

software.

Ao contrário de um recurso (feature), uma User Story é descrita por uma

pequena parte de uma funcionalidade, mas não necessariamente representa uma

função completa. Isto quer dizer que uma feature pode levar várias semanas para

ser desenvolvida, enquanto uma User Story representa o esforço da ordem de 2 a

10 dias no planejamento de uma iteração (HIGHSMITH, 2010, p. 134).

Assim pode-se observar no exemplo a seguir que uma feature pode possuir

várias User Stories:

Feature: Como analista de crédito, preciso da capacidade de checar classificação

de crédito de um cliente.

Story 1 – Como analista de crédito, preciso da capacidade de checar o

histórico de pagamentos de um determinado cliente;

Story 2 – Como analista de crédito, preciso da capacidade de checar o status

74

administrativo de um determinado cliente;

Story 3 – Como analista de crédito, preciso da capacidade de calcular a

nossa classificação interna de crédito baseada em histórico e relatório de crédito.

Quadro 8 - Exemplo da composição de uma feature

Fonte: HIGHSMITH (2010, p.135).

WAKE (2003) cita que para se obter uma boa User Story deve-se usar o

acrônimo INVEST, descrito a seguir:

a) Independent: É mais fácil de trabalhar com User Stories se elas forem

independentes, isto é, se permitirem o seu desenvolvimento

independentemente das demais User Stories;

b) Negotiable: Uma User Story não é um contrato explícito de

funcionalidades. Preferivelmente, os detalhes serão criados em conjunto

pelo programador e pelo cliente durante a fase de desenvolvimento. Uma

boa User Story captura a essência, não os detalhes;

c) Valuable: Uma User Story precisa agregar valor ao cliente, ou seja, ela

deve ser escrita de forma que transmita ao desenvolvedor a sua

importância;

d) Estimable: Uma boa User Story deve ser estimável. Isto se faz necessário

quando há User Stories muito complexas, que necessitem ser negociadas

ou ainda exploradas mais a fundo para que se tenha um maior

conhecimento do problema;

e) Small: User Stories menores tendem a ter melhores estimativas;

f) Testable: Quando uma User Story for escrita, deve permitir o seu

entendimento para que a equipe saiba quando o objetivo for alcançado. Se

um cliente não sabe como testá-la, pode significar que ele ainda não tenha

uma visão clara do que agregue valor ao seu negócio.

75

2.2.1.4.7 Planning Poker

Dentre os vários meios para se definir o tempo estimado para uma

determinada User Story temos o Planning Poker, conforme a Figura 12 que ilustra o

baralho utilizado pela equipe de Kniberg.

Esta técnica permite definir o tempo médio estimado pelo time, em pontos por

história, e revela discrepâncias na compreensão da estória entre membros do

mesmo time.

Para definir o tempo de uma estória é necessário que cada membro da

equipe saiba a correta definição de cada estória, quando alguém faz uma estimativa

muito discrepante, significa que a estória deve ser melhor discutida. Após a

compreensão de todos é feita uma nova rodada para a estória até que as

estimativas sejam aproximadas.

A distribuição dos valores das cartas não é proporcional justamente para que

seja evitada sensação de precisão, principalmente na comparação entre estórias

maiores.

Há também duas cartas especiais, onde a carta com um ponto de

interrogação é uma forma direta de o colaborador dizer que não entendeu a estória,

e a carta com uma xícara de café, que é apresentada quando o colaborador está

cansado demais e sugere uma pausa para um café.

No baralho ainda existe a carta 0 utilizada quando a estória é tão pequena

que exige pouco esforço para realizá-la.

Figura 12 - Planning Poker

Fonte: Kniberg, 2007.

76

Para executar o Planning Poker, cada membro do time deve ter um jogo com

as 13 cartas. Ao estimar uma estória, cada integrante do time escolhe a carta que

mais representa o seu grau de dificuldade. Quando todos tiverem feito sua

estimativa, as cartas são apresentadas simultaneamente.

Kniberg (2007, p.35) indica que “dessa forma, cada membro da equipe é

forçado a pensar por si próprio ao invés de basear-se na estimativa de outra

pessoa”.

Este ainda ressalta a importância de esclarecer ao time que se deve estimar a

quantidade total de esforço envolvido na estória, e não somente a sua parte do

trabalho, assim como o testador não deve somente estimar a quantidade de esforço

para os testes, mas considerar na sua estimativa todo o tempo do projeto que a

estória requer, bem como a sua estimativa de duração do teste.

Para estimativas mais detalhadas ainda é sugerido quebrar a estória em

estórias menores e estimá-las.

2.2.1.4.8 Quadro Kanban

Uma das principais ferramentas para promover a visibilidade das atividades é

o Quadro de Tarefas ou Kanban. Essa ferramenta estimula psicologicamente

atitudes auto-organizadas nos colaboradores para puxar itens para o seu

desenvolvimento e tornar visível seu progresso ou qualquer impedimento durante o

trabalho.

77

Figura 13 - Quadro Kanban

Fonte: Pasassia, 2009.

As pessoas podem alterar o status dos post-its antes da reunião, outras vezes

o Scrum Master pergunta a cada um e ele atualiza o post-it, ou seja, atualizar e

alterar status subentende-se que o post-it muda de posição e a estimativa de prazo.

Após a reunião diária alguém totaliza as estimativas de prazo e marca um novo

ponto no Sprint Burndown Chart.

Outra ferramenta utilizada juntamente com o quadro Kanban na imagem

acima é o gráfico de Burndown, já apresentado no item 2.2.1.2.3, que mostra quanto

de valor de negócio, tamanho ou esforço já foram queimados (entregues) durante a

Sprint ou no projeto inteiro. A ideia de qualquer gráfico no Scrum é mostrar o avanço

da equipe em relação a entregas feitas de software pronto para o Product Owner.

Outra leitura possível do gráfico Burndown é o quanto de desejos falta empregar em

software para atingir a meta da Sprint ou do Projeto.

Durante a reunião o Scrum Master toma nota daquilo que possa impedir os

objetivos da Sprint e responsabiliza-se por resolvê-lo, deixando o time focado na

78

realização das tarefas. Entende-se que problemas funcionam como impedimentos,

ou seja, são obstáculos para que o trabalho iniciado não vá adiante. São

considerados como problemas as questões técnicas como configuração de

hardware, configuração de ambientes, acesso a servidores, entre outros. Esses

impedimentos também podem ser de natureza administrativa como ausência de

pessoal, rotatividade de pessoal, a disponibilidade de o Product Owner estar

presente em determinado evento, entre outros.

Esses problemas estarão visíveis no Quadro de tarefas. Como comentado

anteriormente o Scrum Master é o responsável por remover esses impedimentos,

mas isso não quer dizer que ele sempre possuirá a habilidade técnica necessária

para remover o impedimento, entretanto buscará meios para remoção dos mesmos.

2.2.1.4.9 Matriz de Rastreabilidade

A matriz de rastreabilidade é um artefato responsável por estabelecer uma

relação bidirecional entre os requisitos e os componentes do produto final. Ela deve

ligar os requisitos às suas origens, permitindo o rastreamento durante todo o ciclo de

vida do projeto. O uso de uma matriz de rastreabilidade também fornece uma

estrutura de gerenciamento de mudanças do escopo do produto, auxiliando a

identificação de impactos.

A implementação de uma matriz de rastreabilidade pode ser feita através de

ferramentas específicas, ou mesmo com um editor de texto ou planilha eletrônica. O

Quadro 9 apresenta um exemplo adaptado de uma matriz de rastreabilidade.

Projeto <nome_projeto> - Matriz de Rastreabilidade

Requisito Descrição Documento Componente Caso de teste

<ID do requisito> <descrição> <artefato> <artefato> <artefato>

Quadro 9 - Modelo simplificado de matriz de rastreabilidade

Fonte: Os autores.

79

2.2.1.5 Iniciando o Scrum

O planejamento do Scrum começa com o Product Owner, que a partir das

expectativas dos diversos interessados no projeto cria o Product Backlog.

Segundo Shuterland; Schwaber (2007, p. 16) o Product Owner precisa de

uma visão que enquadre o produto em seu propósito mais atual, um plano de

negócios que mostre quais as oportunidades de retorno podem ser antecipadas pelo

produto em um espaço de tempo definido, e de um roadmap que apresente os

diversos releases com as características e funcionalidades ordenadas pela sua

maior contribuição ao retorno do investimento (ROI).

Schwaber (2004) ainda complementa que o processo de planejamento no

Scrum envolve a resolução de três perguntas:

a) O que os patrocinadores do projeto esperam ter ao final do projeto?

b) Que progresso deve ter ocorrido ao final de cada Sprint?

c) Porque aqueles que patrocinarão o projeto acreditam ser um bom

investimento, e porque acreditam que aqueles que propõem o projeto

conseguirão entregar os benefícios previstos?

Porém diversos autores de publicações sobre metodologias ágeis, como Jim

Highsmith e Scott Ambler indicam que deve haver algumas etapas anteriores e

posteriores à aplicação do Scrum, pois não há em nenhum artefato, evento ou papel

do framework questões como, o estudo de viabilidade do projeto, orçamentação, a

formação da equipe, a definição dos ambientes de trabalho e de desenvolvimento,

entre outras.

Em virtude disto estes autores recomendam a adoção de um ciclo de vida ágil

de desenvolvimento, apresentados a seguir:

80

Figura 14 - Agile System Development Life Cycle

Fonte: Ambler (2010).

81

Além de outras questões não abordadas neste trabalho. Pode-se destacar

algumas como importantes para que se consiga atender as exigências do MPS.BR

nível G:

a) desenvolver a visão inicial;

b) considerar a viabilidade do projeto;

c) obtenção de financiamento e apoio;

d) formação do time;

e) visão inicial dos requisitos;

f) visão inicial da arquitetura;

g) configuração do ambiente.

Ambler ainda apresenta, em um nível mais detalhado a aplicação do Scrum

em um projeto considerando não só a etapa de construção, mas também a etapa de

iniciação:

82

Figura 15 - Agile System Development Life Cycle (detailed)

Fonte: Ambler, 2010.

83

Diante deste cenário, podemos adotar três ferramentas que permitiriam a

construção de um Product Backlog mais embasado - a Elevator Statement, a

Product Vision Box e a Feature Breakdown Structure (FBS).

As duas primeiras tem a finalidade de explorar as funcionalidades do sistema,

enquanto a FBS visa definir uma arquitetura inicial para o sistema. Com a visão do

projeto explorada e a FBS criada, é então o momento de clarificar o que o projeto irá

realmente entregar, ou seja, definir os seus objetivos e restrições.

Através da Project Data Sheet será possível definir o que será realmente

entregue, considerando as prioridades dos envolvidos, restrições de orçamento e

datas de controle, além dos seus responsáveis. Este documento será um guia para

toda a execução do projeto.

A partir da contrução da Project Data Sheet, podem ser construídos o Product

Backlog e o Plano de Release, que permitirá ao Product Owner a projeção das

entregas de diversas iterações.

Além destas atividades, deve-se ter em mente que a organização deverá

considerar também a formação da equipe, a configuração do ambiente de

desenvolvimento e a definição do ambiente de trabalho antes de iniciar qualquer

Sprint.

Experiências anteriores confirmam que o Scrum é mais eficiente quando o

trabalho é realizado com equipes pequenas, geralmente entre cinco e dez pessoas.

Uma equipe no Scrum terá membros com especialidades variadas, de acordo com a

necessidade do projeto, é uma equipe multidisciplinar. O Scrum Master é a exceção,

a pessoa que exerce este papel pode estar coordenando mais de uma equipe, ou

membros que executem tarefas acessórias ao time, mas que devem estar

comprometidas com o projeto. Os membros da equipe discutem entre si e se

autogerenciam. Não há níveis hierárquicos dentro de uma equipe. Durante cada

Sprint é aconselhável que os membros não sejam trocados.

Segundo Kniberg (2007, p. 53) a sala da equipe também merece atenção,

uma vez que muitas das mais interessantes e valiosas discussões sobre design

acontecem espontaneamente na frente do quadro de tarefas. Por esta razão a sala é

arrumada levando em consideração que esta área é explicitamente o “canto do

design” (Figura 16).

84

Figura 16 - Scrum Board

Fonte: Bluesoft, 2007.

Conforme Kniberg (2007, p. 53) a “parede do design” é um grande quadro-

branco contendo os rabiscos de design e esboços da documentação de design mais

importante, como gráficos de seqüências, protótipos de Interface com o Usuário,

modelos de domínio, entre outros.

A equipe deve sentar junta. Uma vez que a equipe esteja toda junta, o retorno

será imediato. Depois de somente um Sprint a equipe irá concordar que foi uma boa

idéia sentar junto.

Kniberg (2007, p. 54) esclarece que “junto” significa:

a) Audibilidade: Qualquer um da equipe pode conversar com o outro sem

gritar ou sair da mesa;

b) Visibilidade: Todos da equipe podem ver todos os demais. Cada um da

equipe consegue ver o quadro de tarefas. Não necessariamente perto o

suficiente para lê-lo, mas pelo menos para vê-lo;

c) Isolamento: Se toda equipe de repente levantar e se envolver em uma

espontânea e animada discussão sobre implementação, não haverá

ninguém de fora da equipe perto o suficiente para ser perturbado.

85

Os artefatos gerados no início do planejamento do projeto podem ser feitos

também em planilhas eletrônicas e editores de texto. Estes documentos são

alterados durante as reuniões do Scrum, e ao disponibilizar esses arquivos em

pastas públicas deve gerenciar os níveis de acesso do time para garantir a

integridade das informações desses documentos e controlar o versionamento em

cada modificação.

Existem ferramentas específicas para gerenciar um projeto. Hoje é possível

encontrar softwares específicos para Metodologias Ágeis que auxiliam o

gerenciamento dos artefatos do projeto, tanto em seu planejamento como no

gerenciamento do Product Backlog como também em tarefas, Sprints e

versionamento.

De qualquer forma, independente das ferramentas adotadas para o

gerenciamento do projeto e dos requisitos, com os ambientes de trabalho e de

desenvolvimento preparados, a equipe formada, a visão do produto compreendida

pelos participantes e o Product Backlog criado, iniciam-se as iterações do Scrum.

86

3 ANÁLISE E MAPEAMENTO DO SCRUM NO NÍVEL G DO MPS.BR

Neste capítulo será descrito como o ciclo de vida do Scrum se relaciona com

as exigências do nível G do MPS.BR. Serão destacadas também as boas práticas

levantadas a partir de pesquisas sobre o modo de trabalho de várias equipes que

fazem Scrum e de autores que comentam artefatos e abordagens. Esta

incrementação de boas práticas foi julgada como uma maneira mais completa do

Scrum atender ao nível G do MPS.BR, mas não é necessariamente o único modo de

trabalho, e sim algumas sugestões que podem ser adotadas por uma equipe que

deseja utilizar o Scrum para alinhar seus processos aos resultados esperados da

metodologia de maturidade de processos MPS.BR. Logo após a descrição de como

cada um dos resultados esperados são atendidos, serão apresentados os artefatos,

papéis, eventos e boas práticas relevantes ao mesmo.

Ao final de cada processo avaliado, será apresentado um quadro onde é

descrito se o resultado esperado foi atendido ou não.

3.1 ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE

PROJETOS DO NÍVEL G DO MPS.BR

3.1.1 GPR1 – O Escopo do trabalho para o projeto é definido

O escopo de trabalho é representado pelo Product Backlog e pelo Sprint

Backlog.

O Sprint Backlog é construído a partir da decomposição dos itens

selecionados no Product Backlog, transformados em tarefas após o seu

entendimento junto ao Product Owner na Sprint Planning Meeting.

Para o caso de novos projetos ou projetos de maior porte, muitos autores que

abordam o desenvolvimento ágil de software, sugerem uma etapa anterior ao ciclo

do Scrum, onde é realizada a construção de uma visão para o produto e um

87

planejamento de longo prazo, incluindo a definição de releases. Nestes casos, o

escopo pode ser definido através da utilização de boas práticas como:

a) Product Vision Box e Elevator Statement para a construção de uma visão

compartilhada do produto com as partes interessadas;

b) Feature Breakdown Structure para a definição de uma arquitetura inicial do

produto e para um detalhamento maior do escopo, permitindo inclusive a

exploração dos seus itens para estimativas superficiais, cronogramas e

orçamentação;

c) Project Data Sheet para a definição de objetivos e restrições do projeto,

inclusive a formalização dos papéis dos responsáveis, marcos importantes

para o projeto e inclusive servindo de subsídio para a construção de um

plano de releases;

d) User Stories para a declaração dos requisitos sob a perspectiva dos

clientes e usuários.

Ao final da aplicação destas boas práticas pode-se considerar também que

um projeto estará com o seu escopo definido, sendo que este escopo compreenderá

uma ou mais Sprints para a sua conclusão.

Artefatos relacionados: Product Backlog e Sprint Backlog.

Papéis relacionados: Product Owner, Scrum Master e Time.

Eventos relacionados: Sprint Planning Meeting.

Boas práticas relacionadas: Elevator Statement, Product Vision Box,

Feature Breakdown Structure, Project Data Sheet.

3.1.2 GPR2 – As tarefas e os produtos de trabalho d o projeto são

dimensionados utilizando métodos apropriados

Para a estimativa das atividades, normalmente é considerada a experiência

de cada um dos integrantes do time. Um ponto importante, é que a precisão do time

em relação às estimativas dependerá de quantas Sprints já foram realizadas, bem

como da estabilidade dos integrantes na equipe.

Estimativas são realizadas no Product Backlog, superficialmente, e também

no Sprint Backlog, de forma mais refinada. Os autores que abordam o assunto

88

apresentam opiniões diferentes na forma de realizar as estimativas, inclusive quando

se utiliza User Stories. Dentre as diversas formas de estimativa, pode-se citar o

Planning Poker, que permite a estimativa por pontos por estória, estimativa em

horas, entre outras, porém todas baseadas na experiência dos membros do time.




Boas práticas relacionadas: User Stories, Story Points e Planning Poker.

3.1.3 GPR3 – O Modelo e as fases do ciclo de vida d o projeto são definidos

Se o Scrum for abordado de uma forma mais ampla, apenas o framework não

atenderia o GPR3. Para que esta exigência seja atendida, o ciclo de vida deve ser

complementado com outras fases, principalmente no que se refere ao planejamento

do produto. Como proposto por Ambler e Highsmith no capítulo 2, item 2.2.1.5, pode

ser adotado um ciclo de vida de desenvolvimento ágil mais abrangente. Desta forma

não é necessário interferir no formato do framework, que ficaria voltado à fase de

construção.

Entre diversas boas práticas disponíveis, sugere-se a adoção da Product

Vision Box, a Elevator Statement, a FBS, a Project Data Sheet, e os planos de

releases antes da construção da primeira versão do Product Backlog.

Artefatos relacionados: Product Backlog.


Eventos relacionados: Sprint Planning Meeting, Sprint Review e Sprint

Retrospective.

Boas práticas relacionadas: Product Vision Box, Elevator Statement, FBS,

Project Data Sheet, Planos de Releases.

89

3.1.4 GPR4 – (Até o nível F) O esforço e o custo pa ra a execução das tarefas e

dos produtos de trabalho são estimados com base em dados históricos

ou referências técnicas

A realização de estimativas de esforço no Scrum acontecem durante a Sprint

Planning Meeting, após o entendimento de cada item proposto pelo Product Owner,

o time levanta as tarefas necessárias para realizá-lo e faz a sua estimativa, em

horas, tarefa a tarefa. Uma das características importantes do Scrum é que as

estimativas de esforço são realizadas com base na experiência do time.

O Scrum não aborda todas as perspectivas de um projeto, portanto no que se

refere a custos, seria possível calcular o valor do trabalho de cada um dos membros

do projeto, tendo a duração fixa de uma ou mais Sprints, porém o framework deixa a

desejar em pontos alheios à execução das atividades, como por exemplo, a

contratação de serviços, aquisição de materiais, ou projeções financeiras para a

estimativa de custo, inclusive para a análise de viabilidade do projeto.

Um artefato que auxiliaria nesta questão é o Project Data Sheet. Este artefato

possui seções para estimar o custo total, o custo por atraso, o seu fator de

exploração, a definição de marcos do projeto, entre outros.

Quanto à definição de escopo de trabalho, Highsmith sugere a utilização de

uma FBS, onde poderão ser levantadas todas as Features necessárias para

estimativas de alto nível, bem como as atividades técnicas para a definição da

arquitetura e da construção do sistema.

Highsmith (2010) e Kniberg (2007) apontam ainda a adoção de técnicas que

auxiliariam a efetividade das estimativas de esforço combinando a utilização de User

Stories, e o Planning Poker.




Boas práticas relacionadas: User Stories, FBS e Project Data Sheet.

90

3.1.5 GPR5 – O orçamento e o cronograma do projeto, incluindo a definição de

marcos e pontos de controle, são estabelecidos e ma ntidos

Como citado no item anterior, em projetos gerenciados apenas pelo Scrum,

os pontos de controle são os eventos conseguintes ao planejamento da Sprint, ou

seja, o Daily Standup Meeting, a Sprint Review e a Sprint Retrospective.

Quanto ao controle do cronograma, após a definição da duração da Sprint,

utiliza-se o Burndown Chart, mantido pelo Scrum Master ou pelo próprio time e

atualizado todos os dias, auxiliando o acompanhamento da realização das tarefas.

Uma boa prática que permite o controle do cronograma é a Project Data

Sheet, que permitirá a definição aproximada do custo total do projeto, a definição

dos marcos e principais pontos de controle do projeto e o planejamento de releases.

Um ponto importante do Scrum é a sua característica de facilitar o

gerenciamento da mudança de escopo, tanto pela execução de curtas iterações,

onde é possível avaliar os resultados com mais frequência, como também pelo papel

do Product Owner, responsável por gerenciar as necessidades que trarão mais valor

na percepção do cliente e ao produto e adicioná-las no Product Backlog.



Eventos relacionados: Daily Standup Meeting, Sprint Review e Sprint

Retrospective.

Boas práticas relacionadas: Project Data Sheet e Plano de Releases.

3.1.6 GPR6 – Os riscos do projeto são identificados e o seu impacto,

probabilidade de ocorrência e prioridade de tratame nto são

determinados e documentados

Durante a Sprint Planning, quando uma atividade ainda está difícil de ser

estimada , é possível dividi-la em atividades menores, facilitando a sua compreensão

e minimizando o risco da atividade ser mal estimada ou ainda mal interpretada pelo

time.

91

Os riscos aos objetivos da Sprint são diariamente avaliados na Daily Standup

Meeting, e é de responsabilidade do Scrum Master resolve-los ou ainda negociar a

sua resolução com o Product Owner.

Ao concluir uma Sprint é realizada a Sprint Retrospective em que os

problemas de processo, envolvendo o ciclo do Scrum, identificados durante a Sprint

podem ser corrigidos através de sugestões de melhorias para a execução e

acompanhamento das Sprints futuras.

A Project Data Sheet é também uma boa prática que permite o mapeamento

dos riscos e, a partir da sua revisão constante, inclusive dos marcos e pontos de

controle do projeto, riscos estarão sempre mapeados para tratamento, caso venham

a ocorrer.

Artefatos relacionados: Sprint Backlog e Burndown Chart.


Eventos relacionados: Daily Standup Meeting e Sprint Retrospective.

Boas práticas relacionadas: Project Data Sheet.

3.1.7 GPR7 – Os recursos humanos para o projeto são planejados

considerando o perfil e o conhecimento necessários para executá-lo

Uma das características de organizações que utilizam Scrum é que as suas

equipes são pequenas, e multidisciplinares.

Durante a Sprint Planning Meeting, cada integrante do Scrum Team deve

estar ciente do seu papel para que esse evento chegue ao seu objetivo, no caso, o

Product Owner apresenta as atividades priorizadas, o time estima a duração e o

Scrum Master faz a mediação entre as discussões do time com o Product Owner. Ao

final obtém-se um Sprint Backlog de acordo com a realidade de trabalho do time e o

nível de comprometimento de cada colaborador.

Cada membro do time compartilha o seu conhecimento com os demais,

portanto uma tarefa teoricamente pode ser atribuída a qualquer colaborador. Desta

forma, caso ocorra a mudança de algum membro da equipe, o conhecimento do

novo colaborador tenderá a se equiparar com o dos demais no decorrer das

próximas Sprints.

92

Durante o planejamento de novos produtos, a Project Data Sheet permite a

atribuição dos papéis de cada um dos integrantes e responsáveis pelo projeto.

Artefatos relacionados: Sprint Backlog.



Boas práticas relacionadas: Project Data Sheet.

3.1.8 GPR8 – Os recursos e o ambiente de trabalho n ecessários para executar

o projeto são planejados

O Scrum não aborda nenhuma questão relacionada ao ambiente de trabalho,

porém muitos autores citam algumas características do ambiente de trabalho de

equipes Scrum.

Os integrantes devem estar juntos, porém isolados de demais departamentos,

sendo que todos devem conseguir ver uns aos outros e conseguir conversar entre si,

no entanto, sem a necessidade de gritar.

Todas essas características permitem que o time consiga a qualquer

momento se reunir e discutir sobre a resolução das suas tarefas.

Outro ponto importante é que o quadro Kanban e o Burndown Chart devem

estar disponíveis e visíveis ao time, para que todos tenham facilmente acesso ao

progresso da Sprint e suas tarefas.

Artefatos relacionados: Burndown Chart.

Papéis relacionados: Time.

Boas práticas relacionadas: Quadro Kanban.

93

3.1.9 GPR9 – Os dados relevantes do projeto são ide ntificados e planejados

quanto à forma de coleta, armazenamento e distribui ção. Um mecanismo

é estabelecido para acessá-los, incluindo, se perti nente, questões de

privacidade e segurança

Os Principais artefatos relacionados aos dados do projeto são o Product

Backlog e o Sprint Backlog.

O Product Backlog é a entrada de requisitos para o desenvolvimento da Sprint

a cada Sprint Planning Meeting. Tem como responsável o Product Owner, que a

cada ciclo deve atualizar, revisar e repriorizar os itens que mais agreguem valor ao

produto ou ao cliente.

O time pode também influenciar o Product Owner a adicionar atividades no

Product Backlog, mas somente este pode priorizá-las. Quanto a questões de

segurança, todos os participantes do projeto podem ter acesso ao Product Backlog,

porém apenas o Product Owner é quem deve mantê-lo.

O Sprint Backlog também é importante para o projeto, pois são os requisitos

refinados pelo Product Owner e aceitos pelo time, que serão desenvolvidos durante

a Sprint. Recomenda-se que durante a execução da Sprint, nenhuma mudança

ocorra nos requisitos, pois isto pode influenciar negativamente os resultados da

Sprint.

As boas práticas que podem complementar o controle de dados relevantes

para o projeto e que compreenderão a este resultado esperado do MPS. BR,

inclusive com a definição de políticas de acesso e segurança do projeto são o

Project Data Sheet, a FBS, os Planos de Releases e o Quadro Kanban.




Boas práticas relacionadas: Project Data Sheet, FBS, Plano de Releases e

Quadro Kanban.

94

3.1.10 GPR10 – Um plano geral para a execução do pr ojeto é estabelecido

com a integração de planos específicos

O Product Backlog é apenas uma visão de longo prazo do produto e, portanto

não pode ser considerado como um Plano Geral, pois não aborda itens como o

planejamento de recursos humanos, ou financeiro do projeto, como exige o GPR10.

Boas práticas que oferecem um maior suporte às exigências, que não estão

ligadas diretamente a iterações e que auxiliariam o cumprimento deste resultado

esperado são a FBS, o Project Data Sheet e o Plano de Releases.

Artefatos relacionados: Sprint Backlog.



Boas práticas relacionadas: FBS, Project Data Sheet e Plano de Releases.

3.1.11 GPR11 – A viabilidade de atingir as metas do projeto, considerando as

restrições e os recursos disponíveis, é avaliada. S e necessário, ajustes

são realizados

O principal evento que tem a finalidade de atender a este resultado esperado

pelo MPS.BR é o Daily Standup Meeting, pois a cada dia pode ser discutido com os

membros do time se as atividades estão sendo realizadas conforme planejado e

caso algo venha a impedi-las, o Scrum Master pode tomar as ações para que o

problema seja resolvido.

Um artefato que também permite a avaliação do desempenho do time é o

Burndown Chart, pois permite avaliar o tempo estimado e o tempo realizado para a

resolução das tarefas da Sprint.

Caso as boas práticas sugeridas anteriormente sejam adotadas o melhor

cumprimento deste resultado esperado se daria com a revisão periódica da FBS, da

Project Data Sheet e do Plano de Release.

Artefatos relacionados: Burndown Chart.

Papéis relacionados: Scrum Master.

95

Eventos relacionados: Daily Standup Meeting.

Boas práticas relacionadas: FBS, Project Data Sheet e Plano de Release.

3.1.12 GPR12 – O Plano do Projeto é revisado com to dos os interessados e o

compromisso com ele é obtido

A cada Sprint Planning Meeting o Product Backlog é apresentado ao time e

ao Scrum Master. Através da negociação de quais requisitos farão parte da Sprint e

como estes serão desenvolvidos, o compromisso com o cumprimento da Sprint é

aceito.

Durante a Sprint, a cada Daily Standup Meeting o acompanhamento da

realização das atividades é acompanhado, e caso exista algum impedimento, o

Scrum Master responsabiliza-se pela sua solução. Deixando o time focado somente

na realização das tarefas.

Uma boa prática que permite a colaboração de todos na concepção do

produto é a Product Vision Box. Ela permitirá que todos os participantes contribuam

com idéias, envolvendo-os e motivando-os para a realização do projeto.



Eventos relacionados: Sprint Planning Meeting e Daily Standup Meeting.

Boas práticas relacionadas: Product Vision Box.

3.1.13 GPR13 – O projeto é gerenciado utilizando-se o Plano do Projeto e

outros planos que afetam o projeto e os resultados são documentados

O Scrum atende bem este requisito através da execução de todo o seu ciclo,

tanto para o planejamento de uma Sprint, como na execução das tarefas (Daily

Standup Meeting e Burndown Chart) e também na avaliação do produto durante a

Sprint Review, que funciona como uma forma de auditoria sobre o produto

96

construído. Para finalizar, visando a melhoria do processo ainda é aplicada a Sprint

Retrospective, que tem a finalidade de avaliar a execução do processo

Kniberg (2009, p. 66) comenta que sugestões realizadas na Sprint

Retrospective podem ser aplicadas em Sprints futuras, e o seu resultado avaliado

posteriormente, para verificar se a mudança realmente trouxe benefícios.

No entanto, no Scrum não há referência sobre documentação, porém há

diversas ferramentas que podem auxiliar a sua execução para que o gerenciamento

dos requisitos e os resultados de cada reunião sejam armazenados.



Eventos relacionados: Sprint Planning Meeting, Daily Standup Meeting,

Sprint Review e Sprint Retrospective.

Boas práticas relacionadas: Product Vision Box e Project Data Sheet.

3.1.14 GPR14 – O envolvimento das partes interessad as no projeto é

gerenciado

A participação dos envolvidos é um ponto forte das metodologias ágeis, já

que um dos seus princípios prega que indivíduos e interações sejam mais

valorizados que processos e ferramentas.

Evidências da comunicação dos envolvidos podem ser percebidos em todos

os eventos do ciclo, inclusive com a participação direta do cliente (PO), onde a

construção do produto e o desempenho do processo são constantemente avaliados

e corrigidos.

Adotando as boas práticas descritas neste trabalho, o envolvimento dos

interessados começa na formação da visão do produto, com a Product Vision Box, e

posteriormente na formalização dos papéis de cada integrante do projeto na Project

Data Sheet.

Papéis relacionados: Product Owner, Scrum Master e Time

Eventos relacionados: Sprint Planning Meeting, Daily Standup Meeting,

Sprint Review e Sprint Retrospective.

97

3.1.15 GPR15 – Revisões são realizadas em marcos do projeto e conforme

estabelecido no planejamento

É de responsabilidade do Product Owner, no início de cada iteração do

Scrum, priorizar as atividades a serem desenvolvidas, inclusive este tem a

responsabilidade de avaliar a viabilidade da execução de uma Sprint juntamente

com o Scrum Master e o Time durante a Sprint Planning Meeting.

Quanto às boas práticas, alguns artefatos como a FBS e a Project Data Sheet

permitem a definição de marcos para o projeto, e devem ser periodicamente

revisados.


Papéis relacionados: Product Owner.

Boas práticas relacionadas: FBS e Project Data Sheet.

3.1.16 GPR16 – Registros de problemas identificados e o resultado da análise

de questões pertinentes, incluindo dependências crí ticas, são

estabelecidos e tratados com as partes interessadas

Este resultado do MPS.BR é uma das principais responsabilidades do papel

do Scrum Master, que deve deixar o time focado na resolução das tarefas e remover

os eventuais impedimentos que venham a ocorrer durante uma Sprint, inclusive com

a negociação da sua solução com o Product Owner ou demais interessados no

projeto. A identificação dos problemas é avaliada diariamente a cada Daily Standup

Meeting.


Eventos relacionados: Sprint Retrospective.

98

3.1.17 GPR17 – Ações para corrigir desvios em relaç ão ao planejado e para

prevenir a repetição dos problemas identificados sã o estabelecidas,

implementadas e acompanhadas até a sua conclusão

Este resultado esperado é abordado a cada final de Sprint, na Sprint

Retrospective, onde os problemas de processo ocorridos durante uma Sprint podem

refletir em ações que visem a melhoria do processo.


Eventos relacionados: Sprint Retrospective.

3.1.18 Resumo do mapeamento entre o processo GPR do MPS.BR e Scrum

A seguir um gráfico apresentando o resultado da avaliação de cada resultado

esperado para o processo de Gerência de Projetos do MPS.BR:

99

Resultado Esperado Scrum Scrum com boas práticas

GPR1 - O escopo do trabalho para o projeto é definido x x

GPR2 - As tarefas e os produtos de trabalho do projeto são

dimensionados utilizando métodos apropriados x x

GPR3 - O modelo e as fases do ciclo de vida do projeto são

definidos x

GPR4 - (Até o nível F) O esforço e o custo para a execução

das tarefas e dos produtos de trabalho são estimados com

base em dados históricos ou referências técnicas x

GPR5 - O orçamento e o cronograma do projeto, incluindo a

definição de marcos e pontos de controle, são

estabelecidos e mantidos x

GPR6 - Os riscos do projeto são identificados e o seu

impacto, probabilidade de ocorrência e prioridade de

tratamento são determinados e documentados x x

GPR7 - Os recursos humanos para o projeto são planejados

considerando o perfil e o conhecimento necessários para

executá-lo x x

GPR8 - Os recursos e o ambiente de trabalho necessários

para executar o projeto são planejados

GPR9 - Os dados relevantes do projeto são identificados e

planejados quanto à forma de coleta, armazenamento e

distribuição. Um mecanismo é estabelecido para acessá-

los, incluindo, se pertinente, questões de privacidade e

segurança x x

GPR10 - Um plano geral para a execução do projeto é

estabelecido com a integração de planos específicos x

GPR11 - A viabilidade de atingir as metas do projeto,

considerando as restrições e os recursos disponíveis, é

avaliada. Se necessário, ajustes são realizados x x

GPR12 - O Plano do Projeto é revisado com todos os

interessados e o compromisso com ele é obtido x x

GPR13 - O projeto é gerenciado utilizando-se o Plano do

Projeto e outros planos que afetam o projeto e os

resultados são documentados x* x*

GPR14 - O envolvimento das partes interessadas no

projeto é gerenciado x x

GPR15 - Revisões são realizadas em marcos do projeto e

conforme estabelecido no planejamento x x

GPR16 - Registros de problemas identificados e o resultado

da análise de questões pertinentes, incluindo

dependências críticas, são estabelecidos e tratados com as

partes interessadas x x

GPR17 - Ações para corrigir desvios em relação ao

planejado e para prevenir a repetição dos problemas

identificados são estabelecidas, implementadas e

acompanhadas até a sua conclusão x x

* Não foram encontradas referências no scrum sobre a foma de documentação de sprints, porém existem diversas

ferramentas que permitiriam este tipo de controle

Figura 17 - Resumo do mapeamento entre o processo GPR do MPS.BR e Scrum

Fonte: Os autores.

100

3.2 ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE

REQUISITOS DO NÍVEL G DO MPS.BR

3.2.1 GRE1 – Os requisitos são entendidos, avaliado s e aceitos junto aos

fornecedores de requisitos, utilizando critérios ob jetivos

No Scrum o Product Owner é o responsável por identificar os requisitos e os

fornecedores de requisitos, que podem ser clientes internos ou externos. O Product

Owner deve avaliar os requisitos, obtendo como resultado o Product Backlog, uma

lista de requisitos priorizada.

Na reunião de Sprint Planning são selecionados do Product Backlog os itens

para a execução de uma Sprint de acordo com a sua prioridade, definida e revisada

previamente pelo Product Owner. Nessa reunião, o Product Owner, o Scrum Master

e o Time refinam e analisam os requisitos obtendo o Sprint Backlog, composto pelas

atividades geradas a partir dos itens selecionados.

Durante a reunião de Sprint Planning, a aplicação de um Check-List sobre os

itens do Product Backlog caracteriza uma avaliação dos requisitos. Outras boas

práticas também podem ser utilizadas na construção de requisitos no Scrum, como

User Stories e Story Cards.




Boas práticas relacionadas: User Stories e Story Cards.

3.2.2 GRE2 – O comprometimento da equipe técnica co m os requisitos

aprovados é obtido

Durante a reunião de Sprint Planning ocorrem atividades de avaliação,

revisão e refinamento dos itens do Product Backlog, que promovem o entendimento

e comprometimento da equipe com os requisitos.

101

A análise das ações planejadas e impedimentos durante a reunião Daily

Scrum também criam um comprometimento implícito entre todos os integrantes do

Time e o Scrum Master.


Papéis relacionados: Scrum Master e Time.

Eventos relacionados: Sprint Planning Meeting e Daily Scrum Meeting.

Boas práticas relacionadas: User Stories e Story Cards.

3.2.3 GRE3 – A rastreabilidade bidirecional entre o s requisitos e os produtos

de trabalho é estabelecida e mantida

As práticas do Scrum não descrevem rastreabilidade bidirecional dos

requisitos, mas através de ferramentas existentes é possível atingir os níveis

mínimos de rastreabilidade. O uso de ferramentas Case, por exemplo, podem ajudar

na rastreabilidade ligando requisitos a elementos de engenharia.

Outra sugestão é a criação de uma matriz de rastreabilidade, contendo a

identificação dos requisitos e permitindo a rastreabilidade bidirecional,

estabelecendo as dependências entre os requisitos e os componentes do produto.

Boas práticas relacionadas: Matriz de Rastreabilidade.

3.2.4 GRE4 – Revisões em planos e produtos de traba lho do projeto são

realizadas visando identificar e corrigir inconsist ências em relação aos

requisitos

As reuniões Daily Standup e Sprint Review, além do próprio fluxo de

desenvolvimento do Scrum permitem, a partir de constantes revisões dos artefatos,

identificar e corrigir inconsistências nos requisitos ao longo do desenvolvimento do

projeto.

Na reunião Daily Standup o Scrum Master pode identificar junto ao Time

inconsistências em relação aos requisitos e objetivos da Sprint.

102

Ao final de uma Sprint, na reunião Sprint Review, o Product Owner pode

verificar se todos os objetivos da Sprint foram atendidos. Se algum requisito não foi

atendido, este será adicionado novamente ao Product Backlog e desenvolvido em

uma próxima Sprint.



Eventos relacionados: Daily Standup e Sprint Review.

3.2.5 GRE5 – Mudanças nos requisitos são gerenciada s ao longo do projeto

O fluxo de desenvolvimento do Scrum, com as reuniões Daily Standup, Sprint

Review, Sprint Retrospective e as constantes revisões dos artefatos garantem que

as mudanças nos requisitos sejam gerenciadas ao longo de todo o desenvolvimento

do projeto.

A forma de documentar as mudanças pode ficar a critério do Time, através de

estórias de usuário, ou ferramentas existentes, como os mecanismos de “issue

tracker” ou planilhas eletrônicas, por exemplo. A rastreabilidade entre um item de

Backlog alterado e o código fonte pode ser garantida ao associar o número da

“issue” ao código fonte.



Eventos relacionados: Daily Standup, Sprint Review e Sprint Retrospective.

Boas práticas relacionadas: User Stories.

3.2.6 Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum

A seguir um gráfico apresentando o resultado da avaliação de cada resultado

esperado para o processo de Gerência de Requisitos do MPS.BR:

103

Resultado Esperado Scrum Scrum com boas práticas abordadas

GRE1 - Os requisitos são entendidos, avaliados e

aceitos junto aos fornecedores de requisitos,

utilizando critérios objetivos x x

GRE2 - O comprometimento da equipe técnica com os

requisitos aprovados é obtido x x

GRE3 - A rastreabilidade bidirecional entre os

requisitos e os produtos de trabalho é estabelecida e

mantida x

GRE4 - Revisões em planos e produtos de trabalho do

projeto são realizadas visando a identificar e corrigir

inconsistências em relação aos requisitos x x

GRE5 - Mudanças nos requisitos são gerenciadas ao

longo do projeto x x

Figura 18 - Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum

Fonte: Os autores.

104

4 CONCLUSÕES

Esta monografia teve como principal objetivo o estudo do modelo de

maturidade MPS.BR e um aprofundamento no nível de maior índice de

implementação entre as empresas Fábricas de Software, o nível G. O estudo do

Scrum ocorreu junto à filosofia e conceitos das Metodologias Ágeis e do modo como

algumas equipes fazem o Scrum em suas empresas.

No contexto desse trabalho a abordagem e estrutura do capítulo 3 explicam-

se pelo fato de que o Scrum deve ser adaptado às necessidades específicas de

cada ambiente, porque tecer uma discussão de forma genérica sobre o Scrum como

apresenta o Capítulo 2, mais precisamente o tópico 2.2.1, não se mostrou muito

construtiva e também limitada. Em outras palavras o tópico citado descreve apenas

a estrutura inicial do Scrum, sem o suporte comumente exigido em uma

organização, ou seja, algo que não traduz a vida real de uma equipe que utiliza

Scrum. Por esse motivo utilizou-se algumas boas práticas, que são na verdade

atividades complementares ao Scrum e que auxiliam o Scrum tanto no dia-a-dia de

uma organização, bem como no atendimento dos resultados esperados do nível G

do MPS.BR. Considerando que é necessário uma percepção adequada da realidade

em que cada equipe se encontra para lidar corretamente com a responsabilidade de

decisão sobre qual boa prática adotar para determinado projeto, ou durante a

realização deste.

Através do capítulo 3 percebeu-se que o Scrum, juntamente com as boas

práticas abordadas atendem os requisitos do MPS.BR nível G em sua grande

maioria, porém alguns itens, como por exemplo o planejamento dos recursos e do

ambiente de trabalho (GPR8) não estão diretamente relacionados ao Scrum, e sim

com a organização e o projeto como um todo. Apesar de não ter sido levantada uma

boa prática especificamente para este requisito, não há grandes impedimentos para

que este seja facilmente atendido.

Outro ponto que percebeu-se ao longo deste estudo é que as metodologias

Ágeis conflitam diretamente com conceitos tradicionais, os quais estão arraigados na

cultura da Engenharia de Software e que em várias situações do presente da

Tecnologia da Informação aconselham técnicas claramente obsoletas sobre como

abordar os processos de desenvolvimento de software. Para esse movimento,

105

segundo Pressman (2002, p.827), Max Hopper descreveu a situação das

tecnologias em Engenharia de Software há mais de uma década e, entretanto a

citação ainda é atual, conforme concorda o visionário Hopper:

Como as modificações na tecnologia de informação estão se tornando tão rápidas e inclementes, e as consequências de ficar para trás são irreversíveis, ou as empresas dominam a tecnologia ou morrem... Pense nisso como um moinho de tecnologia. As empresas terão que correr mais e mais para ficar no mesmo lugar.

As estratégias dos gestores para posicionar seus colaboradores nos tempos

atuais mostra-se muito mais voltada a adaptação e à comunicação do que ao seguir

padrões fixos e imutáveis, que formavam uma lei a ser obedecida para atingir o

sucesso. Hoje se faz software para quem tem contato próximo com o produto final e

possui conhecimentos das regras de negócio além do analista, pois a informação do

cliente é parte indispensável para o desenvolvimento de um produto, nesse caso o

Software.

Pressman (2002) comenta sobre a informação como um bem, e descreve a

posição do software segundo a ótica da informação da seguinte maneira:

Software […] é um mecanismo para automatizar negócios, indústria e governo, um meio para transferir nova tecnologia, um método de captar conhecimento (expertise) valioso para ser usado por outros, um modo de diferenciar os produtos de uma empresa de seus competidores e uma janela para o conhecimento coletivo de uma corporação […]. Mas de muitos modos, o software também é uma tecnologia oculta [...].

O software é difundido e, no entanto, muitas pessoas em posição de responsabilidade têm pouco ou nenhum conhecimento geral do que realmente é, como é constituído ou o que significa para as instituições que elas (e eles) controlam. Mais importante, elas têm pequena noção dos perigos e oportunidades que o software oferece (PRESSMAN; HERRON, 1991 apud Pressman, 2002, p.828).

Para o desenvolvimento de um software é necessário uma harmonia entre

esses dois papéis, o cliente e o analista de sistemas, para que o software seja feito

na medida em que o cliente necessita e na maioria das vezes descobre necessitar

durante conversas com o analista de sistemas. Dessa forma é possível a

coexistência entre a informação e a tecnologia, porque somente quando houver a

comunhão entre essas duas áreas teremos processos que geram conhecimento e

consequentemente sabedoria para o analista, que projetará um modelo de como

utilizar tecnologia no projeto, e também sabedoria ao cliente sobre seu negócio,

quando este utilizar o software que atende às reais necessidades do seu negócio

com qualidade.

106

O Scrum mostra-se um modelo capaz de atender ao conceito atual do

desenvolvimento de software com qualidade. Qualidade essa alcançada através da

cooperação e liderança mediada por diálogos, que fazem o projeto ser adotado

como de domínio coletivo, pois todos os interessados estão diretamente envolvidos

nas decisões que os afetam.

Pode-se também afirmar que o Scrum é voltado à mudança, porque se

adapta muito bem a novas ideias, permitindo criar novas conexões e significados

sem limite. No Scrum a mudança é bem-vinda, pois contribui para que o projeto

evolua e consequentemente aprimore o modo de trabalho dos envolvidos. Desta

forma o Scrum alia-se ao gerenciamento de software favorecendo uma estratégia

que tem por satisfazer as necessidades do cliente da melhor maneira possível

utilizando TI agregada à qualidade.

Um ponto importante o qual necessita ser evidenciado como benefício à

empresa está a transparência que o Scrum e as boas práticas trarão para os

problemas ocorridos durante o desenvolvimento do software. Esses problemas

provavelmente sempre existiram em momentos anteriores a implantação da MA,

porém nenhuma outra metodologia tinha exposto o problema. Talvez um ponto

crítico das metodologias ágeis seja o fato de que elas mostram claramente as

deficiências da organização. Nesse momento muitas empresas desistem da ideia de

adotar uma MA para gerir projetos de software. Outras abraçam essa exposição

porque encaram essa característica como uma oportunidade para resolver os

problemas de Gestão de Software. Um argumento que valida a transparência é o

fato da MA entregar o software de maneira iterativa e incremental.

No Scrum cada Sprint pode ser vista como um projeto independente dentro

de um projeto maior. Os releases, que são as partes do software entregues no final

de cada Sprint podem ser confundidos com desenvolvimento baseado em

prototipagem, o que deve ser desmistificado. Protótipo pode ser visto como uma

demonstração rústica dos requisitos que serve para ser descartada, ou em alguns

casos o protótipo é a primeira parte da atividade de análise e será continuado

durante interações com o cliente. Nesse último caso entende-se que alguns projetos

exigem muita complexidade de código para que alguma função demonstrável seja

realizada. Em larga escala temos uma previsão do final do projeto, em que o cliente

deve levar em conta que abordou todos os requisitos necessários no devido tempo

107

para ter certeza de que refinou o protótipo o suficiente para que esse protótipo se

transforme no produto que entrará em produção.

A discussão acima é contrária ao que a agilidade propõe e deixa em xeque a

qualidade que o produto final terá. No Scrum trabalha-se com um conceito de time-

box, a duração da Sprint, para que uma parte do software seja construída. A cada

Sprint é gerado um produto finalizado que não será jogado fora, potencialmente

pronto para ser colocado em produção. Após a Sprint há a Sprint Review Meeting,

em que o Product Owner avalia se o release entregue atendeu corretamente cada

estória. Por fim, o Time reúne informações sobre as mudanças sugeridas pelo

Product Owner e parte para a Sprint Retrospective Meeting, que visa avaliar os

pontos fortes e fracos da Sprint anterior para aperfeiçoar o seu modo de trabalho na

próxima Sprint e se aproximar mais da melhoria contínua.

Durante o desenvolvimento de um projeto com o Scrum é possível perceber

alguns princípios básicos de causa e efeito. Analisando o texto de Tôrres (2005) e

de Retamal (2006) fica claro que esses princípios dizem que a maioria dos

fenômenos dentro de uma organização estão interconectados, e a partir do

momento que se entende como esses fenômenos se relacionam descobre-se a

razão pela qual o resultado foi obtido. Se é possível analisar a realidade e chegar a

uma conclusão a respeito da causa de um fenômeno em particular, pode-se agir

modificando a sua causa para intervir no efeito dessa causa, ou seja, se foi

detectado uma falha é possível propor modos para adaptar as ações que a

desencadearam de maneira que a causa não reproduza mais a falha identificada.

Isso se traduz também em Garantia da Qualidade.

Pressman (2002, p.830) concorda com o parágrafo acima quando diz que:

[...] a incerteza domina a maioria dos projetos, que os prazos são quase sempre muito curtos e que a iteração possibilita a liberação de uma solução parcial, mesmo quando não é possível um produto completo dentro do prazo estabelecido. Modelos evolucionários enfatizam a necessidade de produtos de trabalho incremental, análise de risco, planejamento e depois revisão de planos e realimentação por parte do cliente.

É conveniente acrescentar que a revisão constante do processo acontece

também com o Time que trabalha com Scrum, mais precisamente o início dessa

atividade acontece na primeira vez do evento Sprint Retrospective Meeting, em que

ações concretas são levantadas pelo Time, e são consideradas e controladas

durante a próxima Sprint visando uma adaptação do processo na tentativa de

impedir que o Time cometa o mesmo erro. Essa atividade contribui para a melhoria

108

contínua do processo de desenvolvimento de software e para o amadurecimento do

Time ao trabalhar com o Scrum no desenvolvimento de produtos.

No Scrum o fato do Product Owner ter ciência de que pode manipular as

estórias e negociar com o Time a complexidade da estória, levando em conta a sua

própria necessidade, traz o Product Owner para perto do desenvolvimento lançando

em suas mãos decisões que afetam diretamente sua empresa ou o seu negócio. A

possibilidade de o Time negociar com o Product Owner em tempo real, deixa bem

claro que o Time tem, nesse encontro que acontece a cada início de Sprint, a

posição de contrabalancear os desejos do Product Owner fazendo com que o Time

se comprometa com metas reais segundo os padrões adotados para o

desenvolvimento de um produto. Esse momento é perfeito para que o Time deixe

bem claro até onde vai a influência do Product Owner, o que beneficia por exemplo,

uma Fábrica de Software que deve defender um modo de trabalho que privilegie a

qualidade do desenvolvimento.

A característica do Scrum em ter papéis e interações bem definidos

transforma o modo de trabalho em um ambiente propício para seguir um modelo de

Maturidade de Processos. Como foi evidenciado nesse trabalho o Scrum pôde ser

mapeado durante cada resultado esperado pelo nível G do MPS.BR de forma

instintiva. Os próximos níveis, que são cumulativos, poderão ser implementados sem

muito questionamento sobre sua viabilidade se forem visados os benefícios que o

MPS.BR trará a uma organização.

As Metodologias Ágeis tiveram sua gênese nos ideais da Mentalidade Enxuta,

conhecida também como Lean Thinking. Nessa monografia foi apresentado o Scrum

que segue os princípios da MA e foca, no contexto de processos, o fluxo dos

processos. Segundo Retamal (2007) é interessante notar que existem 8 princípios

da Gerência da Qualidade, o foco no cliente, liderança, envolvimento das pessoas,

abordagem por processos, abordagem sistêmica para o gerenciamento, melhoria

contínua, abordagem factual para a tomada de decisão, relação entre fornecedores

e mútuo benefício. Se forem analisados os princípios das MA, serão encontradas

referências à Gerência de Qualidade, citados anteriormente. Talvez essa

semelhança entre os princípios das Metodologias Ágeis e a Gerência de Qualidade,

de alguma forma explique uma grande aderência ao nível G.

Entretanto no mundo real nem tudo instintivamente obedece a Gerência da

Qualidade. Existe uma teoria denominada Teoria das restrições TOC (Theory Of

109

Constraints), em que o gerenciamento ganha aspecto de ciência, porque pretende-

se estudar uma atividade feita por uma pessoa, portanto dependente do dom

individual. Aqui está implícito que a atividade é irreproduzível e quase impossível de

transferir a outros, ou seja, é uma arte. O aspecto de ciência está em transformar

essa atividade em algo estruturado, reproduzível e governado por um conjunto de

leis e regras que outros são capazes de aprender e entender. Para Retamal (2006),

essa teoria pode ser aplicada em contextos diversos e em conjunto com outras

iniciativas de gerenciamento, como o MPS.BR.

O processo de melhoria contínua é um desafio ao senso comum. Temos no

ambiente organizacional algumas restrições, que dependendo de como são

utilizadas servem de trava para o processo de melhoria.

Muitos sistemas de gerenciamento de projetos entram em um tipo de inércia,

uma repetição de processos antigos, que causa uma restrição ao sistema, nesse

instante é estabelecido um círculo vicioso que traz conflitos ao sistema, traduzido por

questões que envolvem uma única resposta, o sim ou o não, como exemplo: permitir

alterações no escopo do projeto? Atualizar a documentação? Entre outros. Assim é

possível concluir que o processo quando apresenta conflito se transforma na

restrição.

Os ambientes do projeto estão sujeitos a duas características: alto grau de

incerteza, o que garante surpresas durante o desenvolvimento; e a necessidade de

satisfazer simultaneamente três ou quatro objetivos diferentes. Essas características

são conflitos gerenciais, e para Retamal e Pressman a adoção de um processo de

desenvolvimento iterativo e incremental é a solução para a restrição que gera o

conflito gerencial.

Quando as restrições dos processos são dissolvidas impera um alto grau de

produtividade e qualidade ao desenvolvimento de software, enquanto os riscos e o

retrabalho ganham menos força durante o projeto.

Esse movimento que a organização faz para melhorar o desenvolvimento do

software e amadurecer seus processos traz benefícios para os envolvidos, visto que

investir na qualidade sempre proporciona mais ganho quando comparado com o

prejuízo impactado pela falta de qualidade. Podem ser citados além de maiores

lucros obtidos pela eficiência no uso dos recursos da organização, a satisfação do

cliente e a fidelização do cliente. Um aspecto gerencial importante é o poder

110

adquirido através da maturidade de processos para rever, desafiar e mudar opiniões

e decisões com o cliente e dentro do modo de trabalho da organização.

É necessário chamar a atenção sobre a importância que existe na força com

que a cultura da empresa influi na aderência da adoção de uma nova metodologia.

No contexto dessa monografia a cultura é uma grande variável, que pode acarretar

em um fracasso na tentativa de implantar o modo de trabalho discutido por todo o

estudo, não é somente a cultura da empresa em si, mas o modo como os

colaboradores aceitarão as novas ideias. Principalmente quando há uma transição

de uma gestão de projetos de acordo com o Gerenciamento Clássico para uma

gestão regida por princípios da Agilidade. Em outras palavras o insucesso da

implantação de uma nova metodologia pode estar na não aceitação dos

colaboradores ou dificuldade em se adaptar a nova cultura da empresa, o que pode

ser entendido como uma restrição e travar o processo de melhoria.

Sempre haverá resistência à mudança e isso não é privilégio da transição de

Metodologia Clássica para Metodologia Ágil. Entretanto nesse caso de transição é

possível descrever o desencadeamento de três fatos, o primeiro é que há implícito

em uma nova metodologia a disseminação de uma nova forma de pensar, o que

resulta em uma posterior mudança de cultura interna da Fábrica de Software, e

como consequência o modo de trabalho ganhará um novo formato.

No caso específico de transição entre metodologias, descrito acima, é válido

dizer que essa resistência à mudança dentro da Engenharia de software foi

embutida pelas antigas metodologias que transformaram a mudança em algo a ser

evitado. Essa ideia antiga sobre a mudança veio da incapacidade das metodologias

clássicas em apresentar uma solução para a gestão de mudanças, que sempre

traziam incômodo ao desenvolvimento de software.

O processo de desenvolvimento de software quando abordado na visão dos

colaboradores está muito ligado a área da psicologia. Apesar dessa área ser pouco

conhecida no “terreno” da Tecnologia da Informação a importância de assuntos que

abordam questões sobre mudança, transição e adaptação validam a idéia de que

estudos multidisciplinares, que amenizem os impasses entre o relacionamento

humano e a gestão na Engenharia de Software, serão muito úteis aos profissionais

da área de Informática, que pouco sabem sobre psicologia. Apesar de terem a

condição de humanos e se relacionarem no ambiente de trabalho com colegas

profissionais da área de TI demonstram pouca desenvoltura na interação

111

interpessoal, assunto que se mostrou de muita relevância na área de gestão e se faz

presente nas Metodologias Ágeis com muita força.

A mensagem do modelo de maturidade é a de que haja ordem em todos os

processos, e que cada decisão em uma organização seja bem analisada baseando-

se em padrões de qualidade. O MPS.BR é um conjunto de resultados esperados

que devem ser satisfeitos de alguma forma, entretanto a execução dessa “alguma

forma” deve ser regida por leis fixas, as quais impeçam que os processos das MA

sejam aplicadas de qualquer maneira e desalinhem do fluxo de um desenvolvimento

que visa a qualidade do produto final.

O conceito que as MA trazem ao projeto é de que não há uma metodologia

final e que a MA não é perfeita, ou como dizem muitos autores, não é a “Silver

Bullet”, a bala de prata que resolverá todos os problemas de gestão. O conceito mais

marcante da agilidade, verificado em seus princípios é de que ela já se mostra um

modelo que necessita de melhorias constantes dentro de um projeto, portanto um

modelo imperfeito, entretanto como o mais próximo aos anseios humanos, por isso

será sempre incompleta. Há a possibilidade de encontrar padrões entre projetos,

mas definir padrões definitivos está fora da capacidade humana. Apenas com

modificações ao plano original é possível adaptar e crescer com o projeto. E por isso

que a MA beneficia o desenvolvimento, essa metodologia dá espaço a criação, à

inventividade humana.

112

REFERÊNCIAS

AGILE ALLIANCE. The Alliance: Mission and Operations. Disponível em: <http://www.agilealliance.org/the-alliance/>. Acesso em: 30 de outubro de 2010.

AMBLER, SCOTT W. The Agile System Development Life Cycle (SDLC). 2010. Disponível em: <http://www.ambysoft.com/essays/agileLifecycle.html#Release>. Acesso em: 16 de março de 2010.

BECK, K. Extreme Programming Explained: Embrace Change. 1. ed. Addison-Wesley, 1999.

BROOKS, F. No Silver Bullet: Essence and Accidents of Software Engineering. Computer Magazine, abr. 1987.

COHN, Mike. Advantages of User Stories for Requirements. 2004. Disponível em: <http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements>. Acesso em: 8 de janeiro de 2011.

COHN, Mike. Introduction to User Stories. 2009. Disponível em: <http://www.mountaingoatsoftware.com/system/presentation/file/119/Cohn-ADP09-Introduction-to-User-Stories.pdf?1267636279>. Acesso em: 8 de janeiro de 2011.

CONFORTO, E. C. Gerenciamento ágil de projetos: proposta e avaliaçã o de método para gestão de escopo e tempo . 2009. 306 f. Dissertação (Mestrado) – Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2009. Disponível em: <http://www.teses.usp.br/teses/disponiveis/18/18140/tde-28072009-090239/publico/EdivandroCarlosConforto.pdf>. Acesso em: 30 de outubro de 2010.

DAVIS, C.; GLOVER, M.; MANZO; J.; OPPERTHAUSER D. An Agile Approach to Achieving CMMI. Disponível em: <http://www.agiletek.com/thoughtleadership/whitepapers>. Acesso em: 14 de dezembro de 2009.

DEEMER, Pete et al. The Scrum Primer. 2010. Versão 1.2 . Disponível em <http://scrumtraininginstitute.com/home/stream_download/scrumprimer>. Acesso em: 30 de outrubro de 2010.

113

DIAS, Marisa Villas Boas. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software . São Paulo, 2005. Dissertação (Mestrado em Administração) – Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo. Disponível em: <http://www.teses.usp.br/teses/disponiveis/12/12139/tde-03012006-122134/pt-br.php>. Acesso em: 30 de outubro de 2010.

DREYER, Charl. Scrum Product Ownership. Disponível em: <http://www.managingagile.com/agile-roles/scrum-product-ownership/>. Acesso em: 8 de janeiro de 2011.

FOWLER, Martin. The New Methodology . Trad. Luciano Passuello, 2005. Disponível em <http://simplus.com.br/artigos/a-nova-metodologia/>. Acesso em: 30 de outubro de 2010.

GALLAGHER. B.; BROWNSWORD, L. The Rational Unified Process and the Capability Maturity Model - Integrated Systems/Software Engineering, RUP/CMMI Tutorial - ESEPG, 2001. Disponível em: <http://www.ing.unp.edu.ar/asignaturas/is/papers/rup.pdf>. Acesso em: 14 de dezembro de 2009.

HIGHSMITH, Jim. Agile Project Management: Creating Innovative Products. 2 ed. Boston: Pearson Education, 2010.

HIGHSMITH, Jim. History: The Agile Manifesto. Fev. 2001. Disponível em <http://www.agilemanifesto.org/history.html>. Acesso em Outubro, 2010.

JEFRIES, Ron. What is Extreme Programming. Disponível em: <http://xprogramming.com/xpmag/whatisxp>. Acesso em: 27 de janeiro de 2010.

KNIBERG, Henrik. Scrum e XP direto das Trincheiras – Como nós faze mos Scrum. Disponível em: <http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches>. Acesso em: 30 de outubro de 2010.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software . 2. ed. São Paulo: Novatec, 2007.

KRUCHTEN, P. An Introduction The Rational Unified Process. 2. ed. Addison-Wesley, 2000.

114

MARTINS, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML . 4. ed. Brasport, 2007.

MULHÃO, Augusto César Brauns; CAMPOS, Adriano Cláudio Costa; KALINOWSKI, Marcos; SPÍNOLA, Rodrigo Oliveira. Apoiando a Implementação do Modelo de Maturidade MPS Nível G. Engenharia de Software Maga zine , p.50-67, Ano 1 - 7ª Edição 2008.

PRESSMAN, Roger S. Engenharia de Software . 5. ed. Rio de Janeiro: McGraw-Hill, 2002.

RATIONAL SOFTWATE CORPORATION RUP - Rational Unified Proccess. 2001. Disponível em: < http://www.wthreex.com/rup/>. Acesso em: 8 de janeiro de 2011.

RAWSTHORNE, Dan. Comparing/Combining RUP, XP and Scrum - Mixing the Process Cocktail. Disponível em: <http://www.netobjectives.com/events/download/rup_xp_scrum_pc_030326_ppt.pdf>. Acesso em: 17 de abril de 2010.

RETAMAL, Adail Muniz. Palestra: Qualidade e Ferramentas . 2007. Disponível em: <http://heptagon.com.br/ppt/Adail-TempoReal-Qualidade%20e%20Ferramentas-2007-04-14.zip>. Acesso em: 8 de janeiro de 2011.

RETAMAL, Adail Muniz. Teoria das Restrições: Um Toque . 2006. Disponível em: <http://www.heptagon.com.br/ppt/Adail-TOC-PMI-SP-2006-10-28.pdf>. Acesso em: 8 de janeiro de 2011.

ROSHAN, V. Uttangi; RIZWAN S. A. A. Rizwan. Fast track to CMMI implementation: Integrating the CMMI and RUP process frameworks. Disponível em: <http://www.ibm.com/developerworks/rational/library/oct07/uttangi_rizwan/index.htm>. Acesso em: 14 de dezembro de 2009.

SCHWABER, K. Agile Project Management with Scrum. Redmond: Microsoft Press, 2004.

SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide, 2009. Disponível em: <http://www.scrum.org/scrumguides>. Acesso em: 17 de fevereiro de 2010.

115

SHUTERLAND, Jeff; SCHWABER, Ken. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. 2007. Disponível em <http://scrumtraininginstitute.com/home/stream_download/scrumpapers>. Acesso em: 30 de outubro de 2010.

SOFTEX (2009), MPS.BR – Melhoria de Processo de Software Brasileir o, Guias . Disponível em http://www.softex.br/mpsbr/_guias/default.asp. Acesso em: 25 de dezembro de 2010.

SOUZA, Paulo V. G. Gross. O Uso de User Stories como itens em uma WBS. (Work Breakdown Structure). Disponível em: <http://www.infoq.com/br/articles/user-stories-com-wbs>. Acesso em: 8 de janeiro de 2011.

SPOLSKY, Joel. Product Vision. Disponível em: <http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html>. Acesso em: 30 de outubro de 2010.

TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The New New Product Development Game. Harvard Business Review. Janeiro/Fevereiro de 1986.

TÔRRES, José Júlio Martins. Teoria da complexidade: uma nova visão de mundo para a estratégia . 2005. Disponível em: <http://www.facape.br/ruth/adm-filosofia/Texto_5_-_Teoria_da_Complexidade_e_Estrat.pdf>. 8 de janeiro de 2011.

UNIFEI - Programa de Parceria em Inovação Tecnológica com Empresas – PITE Documento de visão: Sistema de Treinamento de Pilot os (STP) . 2003. Disponível em: <http://www.ici.unifei.edu.br/ramos/SiteTpit/stp.htm>. Acesso em: 8 de janeiro de 2011.

VERSIONONE. Agile Methodologies. Disponível em <http://www.versionone.com/Agile101/Methodologies.asp>. Acesso em: 30 de outubro de 2010.

WAKE, Bill. INVEST in Good Stories, and SMART Tasks. 2003. Disponível em: < http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/>. Acesso em: 8 de janeiro de 2011.

WELLS, Don. Extreme Programming: A gentle introduction. Disponível em: <http://www.extremeprogramming.org>. Acesso em: 17 de janeiro de 2010.

Documents

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ · daniel aiub nunes marco aurÉlio de figueiredo locks rafael hayashi verificar a adequaÇÃo do uso da metodologia Ágil scrum para