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
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
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
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
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
Pontifícia Universidade Católica do Paraná
______________________________
Prof. Msc
Pontifícia Universidade Católica do Paraná
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estã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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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.
Conforme SOFTEX (2009), entre os resultados esperados pela execução
deste processo estão:
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:
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:
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.
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: 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.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
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: 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.
Artefatos relacionados: Product Backlog.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Papéis relacionados: Product Owner, Scrum Master e Time.
Eventos relacionados: Sprint Planning Meeting.
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.
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: 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.
Papéis relacionados: Product Owner, Scrum Master e Time.
Eventos relacionados: Sprint Planning Meeting.
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.
Artefatos relacionados: Product Backlog.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Artefatos relacionados: Product Backlog e Sprint Backlog.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Artefatos relacionados: Product Backlog.
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.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
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: 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.
Artefatos relacionados: Product Backlog e Sprint Backlog.
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.
Artefatos relacionados: Product Backlog e Sprint Backlog.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Artefatos relacionados: Product Backlog.
Papéis relacionados: Product Owner, Scrum Master e Time.
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.
Top Related