METODOLOGIA ÁGIL, SCRUM COMO IMPLEMENTAR COM SUCESSO

Prévia do material em texto

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA 
 
 
MONIELLE CRISTINA MATEO 
15 AOJ 
 
 
 
 
 
 
MET ODOLOGIA ÁGIL , SCRUM – COMO 
IMPLEMENTAR COM SUCESSO 
 
 
 
 
 
 
 
 
 
São Paulo 
2012 
 
 
 
MONIELLE CRISTINA MATEO 
15 AOJ 
 
 
 
 
 
 
 
 
MET ODOLOGIA ÁGIL , SCRUM – COMO 
IMPLEMENTAR COM SUCESSO 
 
 
 
 
Trabalho de Conclusão de Curso apresentado 
à Faculdade de Informática e Administração 
Paulista, como um dos requisitos para 
conclusão do Curso de Pós-Graduação em 
Engenharia de Software Orientada a SOA. 
 
Orientador: Prof. Ms. Eduardo Endo 
 
 
 
São Paulo 
2012 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dedicatória: Dedico esse trabalho para todos 
aqueles que me acompanharam e apoiaram 
nesse momento da minha vida. Agradeço em 
especial a Deus, minha família, colegas do 
curso e alguns amigos essenciais para o 
desenvolvimento dessa monografia: Anderson, 
Antônio, Fabrizio, Graziella, Ivan, Michelle e 
Nathália. 
 
 
 
 
AGRADECIMENTOS 
 
 
 
 
 
 
 
 
 
 
 
Agradeço ao meu orientador MS. Eduardo 
Endo por me ensinar e auxiliar no 
desenvolvimento dessa monografia. Agradeço 
ao Instituto de Tecnologia que me permitiu 
acompanhar o uso de SCRUM em uma equipe, 
e portanto, escrever o meu Estudo de Caso. 
 
 
 
 
RESUMO 
 
O SCRUM é uma metodologia ágil que está crescendo no mercado de trabalhado e 
ganhando novos adeptos que procuram agilidade e satisfação do cliente em projetos 
de desenvolvimento de software. Hoje, o ramo de Tecnologia da Informação está 
muito competitivo, onde ganha o cliente a empresa que entregar em menor prazo, 
com melhor custo e qualidade. A agilidade ajuda a trazer a expectativa do cliente 
para o cotidiano do projeto, mostrando ao cliente o resultado, com freqüência, 
daquilo que ele espera. O SCRUM compromete todos do time, desde a equipe 
técnica, analistas, testes até o cliente. A implementação da metodologia gera 
mudanças produtivas e que elevam a eficiência do acompanhamento e 
desenvolvimento do projeto.Trazer o cliente para perto do time, auxilia na motivação 
da equipe em criar um software sem defeitos e que agregue valor para o cliente. 
 
 
Palavras-chave: Método ágil. SCRUM. Projetos com agilidade. 
 
 
 
LISTA DE ILUSTRAÇÕES 
 
FIGURAS 
Figura 1 – Os valores do Manifesto Ágil .................................................................... 15 
Figura 2 – Ciclo de vida do eXtreme Programming ................................................... 17 
Figura 3 – Ciclo de vida do FDD ............................................................................... 19 
Figura 4 – Ciclo de vida do Crystal ............................................................................ 22 
Figura 5 – Princípios do Lean.................................................................................... 23 
Figura 6 – SCRUM não resolve tudo ......................................................................... 27 
Figura 7 – Papéis do SCRUM ................................................................................... 31 
Figura 8 – Kanban de uma sprint .............................................................................. 37 
Figure 9 – Exemplo de gráfico de Burndown............................................................. 38 
Figura 10 – Ciclo de vida SCRUM ............................................................................. 39 
Figura 11 – Exemplo de Planning Poker ................................................................... 42 
 
 
 
 
SUMÁRIO 
 
INTRODUÇÃO ........................................................................................ 9 
INTRODUÇÃO AOS MÉTODOS ÁGEIS ............................................... 13 
MÉTODOS ÁGEIS ....................................................................................................... 13 
XP (EXTREME PROGRAMMING) ................................................................................... 16 
FDD (FEATURE DRIVEN DEVELOPMENT) ..................................................................... 18 
CRYSTAL ................................................................................................................... 21 
LEAN SOFTWARE DEVELOPMENT ................................................................................ 23 
IMPLEMENTANDO O SCRUM.............................................................. 26 
SCRUM EM 100 PALAVRAS ....................................................................................... 26 
ENTENDENDO O SCRUM ........................................................................................... 26 
PORQUE MUDAR É PRECISO (E DÍFICIL) ......................................................................... 29 
ESCOLHENDO UM PROJETO PILOTO ............................................................................. 29 
PAPÉIS E RESPONSABILIDADES ................................................................................... 31 
ARTEFATOS ............................................................................................................... 34 
TIME BOX .................................................................................................................. 39 
SPRINT ...................................................................................................................... 39 
PLANNING MEETING .................................................................................................... 41 
DAILY SCRUM ............................................................................................................ 43 
SPRINT REVIEW ......................................................................................................... 43 
RETROSPECTIVA ........................................................................................................ 44 
QUALIDADE ............................................................................................................... 45 
ESTUDO DE CASO .............................................................................. 47 
 
 
 
CMMI (CAPABILITY MATURITY MODEL INTEGRATION) .................................................. 48 
DIFICULDADES NO SCRUM ........................................................................................ 51 
Imaturidade da equipe ........................................................................................ 51 
Gerente de projetos “sem autoridade” ............................................................. 52 
Escolha do SCRUMMaster ................................................................................. 53 
Prazos .................................................................................................................. 53 
Cliente não respeitar a metodologia ................................................................. 54 
SCRUM na organização ...................................................................................... 54 
CMMI x SCRUM ................................................................................................... 56 
 
9 
 
 
INTRODUÇÃO 
A presente pesquisa se configura como Trabalho de Conclusão de Curso de pós-
graduação em Engenharia de Software Orientada a SOA da Faculdade de 
Informática e Administração Paulista e apresenta suas justificativas para a escolha 
do tema, bem como a sua delimitação. Com a finalidade de contribuir para a 
produção científica e atingir certo grau de aprofundamento acadêmico, a pesquisa 
foi realizada pelo(a) aluno(a) Monielle Cristina Mateo do curso de 15 AOJ. Alguma 
pesquisa prévia se fez para a sua elaboração pelo(a) estudante empenhado(a) na 
pesquisa. Grande parte do projeto inspira-se, no entanto, numa tentativa de avaliar e 
propor melhorias para a área em que atua o(a) pesquisador(a). 
DELIMITAÇÃO DO TEMA 
Para analisar a implementação do SCRUM com sucesso, circunscrito à área de 
Gerenciamento de projeto,a presente pesquisa se organizou em torno de 3 
capítulos. O primeiro capítulo apresenta as Metodologias Ágeis, fazendo uma breve 
descrição dos principais métodos ágeis no mercado. Em segundo lugar, é feita uma 
análise do SCRUM, onde é explicado a metodologia, o que fazer em cada caso, os 
papéis e responsabilidades e como segui-la. Num terceiro momento, é apresentado 
o Estudo de caso, onde é acompanhado a implementação do SCRUM em um 
Instituto de Tecnologia que utilizava outra metodologia. A análise mostra os 
obstáculos enfrentados ao seguir o SCRUM. Os dados foram levantados a partir de 
pesquisas desde o início do curso até o período atual. 
JUSTIFICATIVAS PARA A PESQUISA 
Afora o interesse pessoal dos pesquisadores, o tema se impõe pela recorrência das 
discussões sobre métodos ágeis. No Brasil é assunto obrigatório em todos os 
círculos, neste começo da primeira década do século XXI, pela contribuição que uma 
pesquisa desta natureza pode emprestar à compreensão do real papel do curso 
numa sociedade marcadamente composta de pessoas carentes de formação 
acadêmica e profissional, além de um crescente número de desempregados. 
10 
 
 
Diante da metodologia ágil SCRUM, a equipe e respectivamente a empresa, tende a 
prosperar em inúmeros sentidos. A equipe ganha agilidade através de maturidade 
dos processos, o cliente fica mais satisfeito com prévias do sistema solicitado e os 
integrantes da equipe sentirão a liberdade e responsabilidade resultante do SCRUM. 
Por outro lado, a relevância social da pesquisa se mostra pelo fato de que o estudo 
permitirá ajudar na resposta a uma pergunta básica: metodologia ágil funciona em 
desenvolvimento de softwares? Ao mesmo tempo, a pesquisa poderá ajudar a 
compreender como é o desenvolvimento de software gerenciado através de métodos 
ágeis. Crendo na sua real importância, a pesquisa visa analisar os benefícios de 
utilizar metodologias ágil para, de alguma forma, ajudar a sociedade em sua busca 
de cidadania plena, a partir do que é oferecido à população, especificamente na 
cidade de São Paulo. 
A despeito de a pesquisa roçar quase sempre o pioneirismo, pela quase inexistência 
de estudos na área (especialmente no Brasil), o tema se mostra de execução viável, 
primeiro, pela existência de fontes a serem consultadas; segundo, pelo apoio que os 
pesquisadores receberam da instituição e pelos estudos teóricos já desenvolvidos 
nesta área. 
REFERENCIAL TEÓRICO 
Não apenas são aqui apontados os textos existentes até o momento, mas são 
analisados os progressos, resultados, conclusões e limitações que ora se 
apresentam. Segue, portanto, uma relação do que se tem pesquisado com vistas à 
elaboração do TCC, tanto no aspecto da apresentação do estado atual da questão, 
como propriamente o referencial teórico empregado na pesquisa (marco teórico). 
Foi de grande utilidade para a pesquisa o livro Desenvolvimento de Software Com 
Scrum: Aplicando Métodos Ágeis de Mike Cohn que apresenta um guia prático para 
implementação imediata do desenvolvimento ágil com Scrum em qualquer empresa, 
apresentando recomendações detalhadas, dicas importantes e estudos de caso 
reais. O livro mostra como superar grandes desafios de implementação do Scrum e 
a transformar toda a empresa de desenvolvimento. 
11 
 
 
O texto do Manifesto para Desenvolvimento Ágil de software, do(s) e autor(es) Kent 
Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, 
Martin Fowler, al. , é fruto de um encontro de amigos, em torno do tema 
desenvolvimento de software ágil. São dados enfoques, no texto, de grande 
interesse sobre agilidade, os quais os autores eram representantes de Extreme 
Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-
Driven Development, Pragmatic Programming, entre outros métodos, forneceram 
pistas e abriram os horizontes para o tema deste TCC. 
PROBLEMA 
Como implementar com sucesso a metodologia ágil SCRUM em equipes que 
utilizam outras metodologias? 
 
HIPÓTESE 
Por meio do conhecimento das vantagens que o SCRUM pode trazer, capacitação 
da equipe, motivação da equipe e do cliente em experimentar uma metodologia nova 
e investimento da empresa, será possível garantir o sucesso da implementação do 
SCRUM. 
OBJETIVOS 
Realizar um estudo de caso sobre a implementação da metodologia SCRUM em 
uma equipe que nunca utilizou antes, mostrando os passos para obter sucesso da 
implementação. 
 
PROCEDIMENTOS METODOLÓGICOS 
A pesquisa seguiu etapas próprias, a partir da hipótese norteadora. Para a coleta de 
dados foram necessários instrumentos adequados, bem como foram empregadas 
técnicas aprendidas durante o curso para a efetiva análise dos dados coletados. 
Foram, portanto, adotados os seguintes procedimentos 
12 
 
 
a) Leitura de textos de orientação teórico-metodológica; 
b) Estudo de caso em um Instituto de Tecnologia; 
c) Análise geral dos resultados. 
LIMITAÇÕES 
Em seu trabalho, o pesquisador corre vários riscos. O primeiro deles é o de trabalhar 
no domínio, às vezes, fluido da interdisciplinaridade, colocando-se logo sob o fogo 
cruzado dos estudiosos de cada uma destas áreas. Mais difícil, no entanto, pela 
natureza da pesquisa, é a obtenção de respostas satisfatórias, o que só será 
superado com uma empática relação com os examinadores da banca. Mesmo 
consciente destas dificuldades, os pesquisadores realizaram a pesquisa, sabedores 
de que as lacunas poderão, depois de percebidas, ser devidamente preenchidas por 
pesquisas posteriores. 
13 
 
 
 
Capítulo 1 
INTRODUÇÃO AOS MÉTODOS ÁGEIS 
Métodos Ágeis 
 
“Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado 
financeiro do projeto em um turbulento ambiente de negócios. Agilidade é a 
habilidade de balancear a flexibilidade com estabilidade”. (HIGHSMITH, 2002). 
 
Segundo NETO(2002) 
 
Nos dias 11 a 13 de fevereiro de 2001, na estação de ski 
chamada The Lodge at Snowbird nas montanhas Wasatch de Utah, 
17 pessoas se encontraram para conversar, esquiar, relaxar, e tentar 
encontrar um lugar comum e claro, para comer. O que emergiu foi o 
Manifesto para Desenvolvimento Ágil de Software. Representantes 
da Extremme Programming, SCRUM, DSDM, Adaptive Software 
Development, Crystal, Feature-Driven Development, Pragmatic 
Programming, e outros simpatizaram com a necessidade de uma 
alternativa aos pesados processos de desenvolvimento de software 
orientados a documentação. 
Agora, uma grande reunião de anarquistas organizacionais seria 
difícil de encontrar, portanto o que saiu desta reunião foi o simbólico 
Manifesto para Desenvolvimento Ágil de Software, assinado por 
todos os participantes. 
 
A metodologia ágil é associada a projetos em ambientes de requisitos instáveis, 
pouco definidos ou sujeitos a mudanças. Essa ligação foi criada pois ao invés de 
definir completamente o projeto no início como em outras metodologias, as 
definições são feitas durante o desenvolvimento do projeto junto do time de 
desenvolvimento de software. 
Segundo SOARES (2004) 
 O “Manifesto Ágil” não rejeita os processos e ferramentas, a 
documentação, a negociação de contratos ou o planejamento, mas 
simplesmente mostra que eles têm importância secundária quando 
comparado com os indivíduos e interações, com o software estar 
executável, com a colaboração do cliente e as respostas rápidas a 
mudanças e alterações. Esses conceitos aproximam-se melhor com 
14 
 
 
a forma que pequenas e médias organizações trabalham e 
respondem a mudanças. 
 
Segundo MANIFESTO ÁGIL(2001) 
 
1. Nossa maior prioridade é satisfazer o cliente através da 
entrega contínua e adiantada do software com valor 
agregado. 
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente 
no desenvolvimento. Processos ágeis tiram vantagem das 
mudanças visando vantagem competitiva para o cliente. 
3. Entregar frequentemente software funcionando, de poucas 
semanas apoucos meses, com preferência à menor escala 
de tempo. 
4. Pessoas de negócio e desenvolvedores devem trabalhar 
diariamente em conjunto por todo o projeto. 
5. Construa projetos em torno de indivíduos motivados. Dê a eles 
o ambiente e o suporte necessário e confie neles para fazer o 
trabalho. 
6. O método mais eficiente e eficaz de transmitir informações para 
e enetre uma equipe de desenvolvimento é através de 
conversa face a face. 
7. Software funcionando é a medida primária de progresso. 
8. Os processos ágeis promovem desenvolvimento sustentável. 
Os patrocinadores, desenvolvedores e usuários devem ser 
capazer de manter um ritmo constante indefinidamente. 
9. Contínua atenção à excelência técnica e bom design aumente 
a agilidade. 
10. Simplicidade, a arte de maximizar a quantidade de trabalho 
não realizado, é essencial. 
11. As melores arquiteturas, requisitos e designs emergem de 
equipes auto-organizáveis. 
12. Em intervalos regulares, a equipe reflete sobre como se 
tornar mais eficaz e então refina e ajusta seu comportamento 
de acordo. 
 
15 
 
 
 
Figura 1 – Os valores do Manifesto Ágil 
 
Segundo VICENTE(2011) 
 
[...] a capacidade de reação a mudanças constantes, a colaboração 
com o cliente, processos eficientes para gerar produtos de qualidade 
(que atendem ao cronograma, possuem menos defeitos e que 
resultam em usuários mais satisfeitos), aprendizagem e melhoria 
contínua do projeto. Nesse contexto, estudos com o cliente relataram 
sua satisfação com oportunidades de feedback constante.” 
 
Muitos métodos ágeis começaram a ser utilizados. Como exemplos, os mais 
conhecidos são: 
 
 XP (eXtreme Programming) 
 Scrum 
 Crystal 
 FDD (Feature Driven Development ) 
 Lean Software Development 
 
16 
 
 
XP (eXtreme Programming) 
 
Segundo WELLS (1999) 
 
Extreme Programming é bem sucedida porque enfatiza a 
satisfação do cliente. Ao invés de entregar tudo que o cliente 
pode desejar em alguma data em um futuro distante esse 
processo entrega o software que o cliente precisa e como ele 
precisa. Extreme Programming capacita os desenvolvedores 
para confiantemente responder às necessidades do cliente, 
mesmo no final do ciclo de vida do projeto. 
 
Extreme Programming enfatiza o trabalho em equipe. 
Gerentes, clientes e desenvolvedores são todos parceiros em 
um time colaborativo. Extreme programming implementa um 
ambiente simples, porém efeciente, possibilitando que o time 
torne-se altamente produtivo. O time se auto organiza em torno 
de um problema para resolver da forma mais eficiente possível. 
Extreme Programming melhora o projeto de software em cinco 
formas essenciais: comunicação, simplicidade, feedback, 
respeito e coragem. Extreme programmers constantemente se 
comunicam com seus cliente e colegas programadores. Eles 
mantém o código simples e limpo. Eles recebem feedback 
todos os dias dos testes de software. Eles entregam o software 
para o cliente o mais cedo possível e implementa as mudanças 
como sugerido. Cada pequeno sucesso aprofunda o respeito 
das contribuições únicas de cada membro e de todo o time. 
 
As regras do eXtreme Programming são: 
 
Planejamento (Planning) 
 
 Estórias do usuário (user stories) são escritas. 
 Planejamento de entrega (release planning) cria o cronograma 
das entregas (release schedule). 
 Frequentemente fazer pequenas entregas (small releases). 
 O projeto é dividindo em iterações (iterations) 
 Planejamento da iteração (iteration planning) inicia a cada 
iteração. 
 
Gerenciamento (Managing) 
 
 Manter um ritmo sustentável. 
 Dar ao time um espaço de trabalho dedicado. 
 O dia começa com uma reunião em pé. 
 A velodidade do projeto (project velocity) é medida. 
 Mover as pessoas ao redor. 
 Consertar XP quando quebrar. 
17 
 
 
 
Criação (Designing) 
 
 Simplicidade. 
 Usar cartões CRC para sessões de criação. 
 Criar solução de pico (spike solutions) para reduzir o risco. 
 Nenhuma funcionalidade é adicionada antecipadamente. 
 Refatorar quando e onde for possível. 
 
Codificação (Coding) 
 
 O cliente está sempre disponível. 
 Código deve ser escrito de acordo com os padrões. 
 A codificação é feita em pares. 
 Apenas uma pessoa integra o código de cada vez. 
 Integrar frequentemente. 
 Manter um computador de integração dedicado. 
 Usar propriedade coletiva. 
 
Teste (Testing) 
 
 Todo o código deve ter teste unitário. 
 Todo código deve passar pode teste unitário antes de ser 
entregue. 
 Quando um problema (bug) for encontrado testes são criados. 
 Testes de aceitação são rodados frequentemente e os 
resultados são publicados. 
 
 
Figura 2 – Ciclo de vida do eXtreme Programming 
 
 
18 
 
 
FDD (Feature Driven Development) 
 
Segundo HEPTAGON (2012) 
 
Combina as melhores práticas do gerenciamento ágil de 
projetos com uma abordagem completa para Engenharia de 
Software orientada por objetos, conquistando os três principais 
públicos de um projeto de software: clientes, gerentes e 
desenvolvedores. 
Seus princípios e práticas proporcionam um equilíbrio entre as 
filosofias tradicionais e as mais extremas, proporcionando uma 
transição mais suave para organizações mais conservadoras, e 
a retomada da responsabilidade para as organizações que se 
desiludiram com as propostas mais radicais. 
 
A FDD chama a atenção por algumas características 
peculiares: 
 
 Resultados úteis a cada duas semanas ou menos 
 Blocos bem pequenos de funcionalidade valorizada pelo 
cliente, chamados "Features" 
 Planejamento detalhado e guia para medição 
 Rastreabilidade e relatórios com incrível precisão 
 Monitoramento detalhado dentro do projeto, com resumos de 
alto nível para clientes e gerentes, tudo em termos de negócio 
 Fornece uma forma de saber, dentro dos primeiros 10% de um 
projeto, se o plano e a estimativa são sólidos 
 
A FDD é uma metodologia muito objetiva. Possui apenas duas 
fases: 
 
1. Concepção & Planejamento: Pensar um pouco antes de fazer 
(tipicamente de 1 a 2 semanas) 
2. Construção: Fazer de forma iterativa (tipicamente em iterações 
de 2 semanas) 
 
 
Os cinco processos são bem definidos e integrados: 
 
 DMA (Desenvolver um Modelo Abrangente): Análise Orientada 
por Objetos 
 CLF (Construir a Lista de Funcionalidades): Decomposição 
Funcional 
 PPF (Planejar por Funcionalidade): Planejamento Incremental 
 DPF (Detalhar por Funcionalidade): Desenho (Projeto) 
Orientado por Objetos 
 CPF (Construir por Funcionalidade): Programação e Teste 
Orientados por Objetos 
19 
 
 
 
 
Figura 3 – Ciclo de vida do FDD 
 
A definição dos processos segundo o INSTITUTO DE INFORMÁTICA UFG (2006) 
DMA - Desenvolver um Modelo Abrangente 
 
É a atividade inicial desenvolvida por uma equipe formada por 
membros do domínio do negócio e por desenvolvedores, sob 
orientação de um modelador de objetos experiente, que 
executará o papel de arquiteto-chefe. 
A primeira atividade desse processo é definir o escopo do 
sistema e seu contexto. A partir da definição desses dados 
serão realizados estudos detalhados sobre o domínio do 
negócio de cada área que será modelada. 
O estudo de cada área é realizado por sub-grupos, formados 
por membros do domínio do negócio que está sendo estudado 
e por desenvolvedores. A partir das informações extraídas 
dessa pesquisa, os desenvolvedores elaboram modelos que 
atendam ao domínio estudado. 
Após a conclusão do estudo de cada grupo, é feita uma 
apresentação dos modelos produzidos. O objetivo é definir o 
modelo que será adotado para a área que está sendo 
modelada. 
 
CLF - Construir uma Lista de Features 
 
Nesse processo são identificadas as funcionalidades que 
devem satisfazer às necessidades dos clientes, expressas na 
forma de requisitos. 
20 
 
 
Para isso é formada uma outra equipe, dessa vez composta 
pelos programadores-chefes. Após identificação das 
funcionalidades, esse grupo deve realizar a decomposição 
funcional (áreas, atividades e passos) de cadaatividade do 
negócio. Com isso, é gerada uma lista categorizada para as 
funcionalidades identificadas. 
 
PPF - Planejar por Funcionalidade 
 
É o conjunto de atividades necessárias para elaborar o Plano 
de Desenvolvimento. 
Nessa estapa do processo, uma equipe planeja a ordem na 
qual as funcionalidades serão implementadas. Como 
complemento, são definidas as classes prioritárias e quem são 
os seus desenvolvedores responsáveis, ou proprietários do 
código - outra particularidade da FDD. 
 
DPF – Detalhar por Funcionalidade 
 
É constituído por um conjunto de atividades que visam a 
elaboração do 
Pacote de Projeto de cada funcionalidade. 
Nessa etapa, o programador-chefe forma as equipes de 
funcionalidades. Com isso automaticamente são identificados 
os desenvolvedores proprietários das classes que estão 
envolvidas no desenvolvimento das funcionalidades 
selecionadas. 
Cada equipe deve produzir um ou mais diagramas de 
seqüência para as funcionalidades sob a sua atribuição. De 
posse dessa documentação, caberá ao programador-chefe 
realizar o refinamento do modelo de objetos. 
Ainda dentro dessa etapa, os desenvolvedores devem 
escrevem os prefácios das classes e dos métodos. 
Concluídas as atividades desse processo, será realizada uma 
inspeção no projeto. 
 
CPF - Construir por Funcionalidade 
 
No processo 5 estão agrupadas as atividades que devem ser 
executadas para a codificação das funcionalidades. 
O código desenvolvido passa por uma bateria de testes e por 
outro processo de inspeção. 
Se o código passar com sucesso pela inspeção, ele é 
promovido a build (versão atual). 
 
21 
 
 
Crystal 
 
Segundo SIQUEIRA (2003) 
 
Crystal é o nome de uma família de métodos que devem ser 
ajustados para melhor se adaptarem a uma determinada 
equipe e projeto. Cada método é moldado para ter a 
quantidade exatamente suficiente de processo, capaz de 
atender os projetos a partir da análise de três fatores: a carga 
de comunicação (representada pelo número de pessoas), a 
criticidade do sistema e a prioridade do projeto. 
 
[...] Conforme as cores dos membros da família Crystal se 
tornam mais escuras, tem-se um maior peso dos métodos, o 
que é necessário devido à complexidade dos projetos. Esse 
peso é representado pela quantidade de artefatos e a rigidez 
da gerência, itens que são absorvidos entre os 13 elementos 
definidos para cada método: papéis, habilidades, times, 
técnicas, atividades, processos, artefatos, produtos de trabalho, 
padrões, ferramentas, personalidades, qualidade e valores da 
equipe. 
 
[...] Apesar das diferenças entre as complexidades dos projetos 
abordados pelos métodos da família Crystal, eles apresentam 
em comum valores, princípios e a capacidade de serem 
ajustados durante o uso (on-the-fly). Os valores denotam a 
visão do desenvolvimento de software como um “jogo 
cooperativo de invenção e comunicação, com o objetivo 
primário de entregar algo útil e, em segundo, preparar para o 
próximo jogo”. Dessa forma, os valores pregam que os 
métodos são centrados nas pessoas e na comunicação, além 
de serem altamente tolerantes a modificações – considerando 
as diferenças entre as pessoas. Isso permite que sejam 
utilizadas partes de outros métodos, como práticas e princípios 
do XP e o arcabouço do SCRUM. No entanto, existem duas 
regras que devem ser seguidas, limitando essas modificações: 
o desenvolvimento deve ser incremental, com incrementos de 
até 4 meses, e devem ser realizados workshops de reflexão 
antes e depois de cada incremento. 
 
Em relação aos princípios, eles são os seguintes: 
 
 Comunicação iterativa, face-a-face é o canal mais barato e 
rápido para o intercâmbio de informações. 
 O excesso de peso do método é custoso. 
 Times maiores precisam de métodos mais pesados. 
 A maior cerimônia é apropriada para projetos com maior 
criticidade. 
22 
 
 
 Aumentando a retro-alimentação (feedback) e comunicação é 
reduzida a necessidade de itens intermediários entregues. 
 Disciplina, habilidade e entendimento contra processo, 
formalidade e documentação. 
 Pode-se perder eficiência em atividades que não são o gargalo 
do processo. 
 
 
Figura 4 – Ciclo de vida do Crystal 
 
23 
 
 
Lean Software Development 
 
Segundo GOMES (2012) 
 
Lean é uma metodologia que foi originalmente desenvolvida 
pela Toyota para guiar processos industriais de linha de 
montagem. Ela foca na eliminação de desperdícios, aumento 
da velocidade de processos e na excelência em qualidade. 
Implementar Lean permite que uma organização diminua seus 
estoques, maximize o uso de trabalhadores generalistas (ou 
seja, que possuem muitas habilidades) e produza de acordo 
com a demanda. 
 
Princípios Lean aplicados ao software: 
 
 Elimine Desperdícios 
 Inclua a Qualidade no Processo 
 Crie Conhecimento 
 Adie Decisões e Comprometimentos 
 Entregue o quanto antes 
 Respeite as Pessoas e "Empower" a equipe 
 Otimize o Todo 
 
 
Figura 5 – Princípios do Lean 
 
Segundo STEFFEN (2011) 
 
Eliminar desperdícios 
 
Desperdícios: tudo aquilo que não agrega valor para cliente final e 
que não são percebidos pelo cliente. Exemplo: passos extras, 
processo pesado e rígido, burocracia, documentação que nunca vai 
24 
 
 
ser lida, que está na prateleira juntando poeira - não necessária, 
etc. Outro tipo de desperdício são trabalhos parcialmente prontos, 
tudo que começa e não termina, funcionalidades extras que não 
serão utilizadas, etc. 
Enfim, software útil e de funcionando (de qualidade) é o que vai 
trazer valor ao cliente. Os sete desperdícios de software: 
 
 Inventory = Requirements / Partially done work (Requisitos) 
 Extra Processing Steps = Extra processes, steps (Processos, 
passos a mais) 
 Overproduction = Extra features (Funcionalidades a mais) 
 Transportation = Handoffs, tasks switching (Troca de tarefas) 
 Waiting = Waiting (Atrasos) 
 Defects = Defects (Defeitos) 
 Motion = Finding Information (Movimento) 
 
Qualidade embutida 
 
Qualidade é inegociável. Entregue qualidade intrínseca e explícita 
aos seus clientes, se eles perceberem isso, significa que foi uma 
entrega de qualidade. Mary e Tom Poppendieck em seu livro 
identificaram duas dimensões de integridade: integridade percebida e 
integridade conceitual. A integridade percebida significa que a 
totalidade do produto alcança um equilíbrio entre as funções, 
usabilidade, confiabilidade, economia e isso encanta o cliente. A 
integridade conceitual significa que os conceitos centrais do sistema 
de trabalho em conjunto são facilitados e coesos. Essa última é fator 
crítico de sucesso para a integridade percebida. 
Um produto possui integridade percebida quando o cliente o 
experimenta e diz: Isso! Era exatamente isso que eu queria! Software 
com integridade possui boas arquiteturas, possuem um alto nível de 
usabilidade e facilidade de uso, são fáceis de dar manutenção, de 
adaptar e de estender. 
 
Criar conhecimentos 
 
Desenvolvimento é um exercício de descoberta, enquanto produção 
é um exercício de reduzir a variação. Desenvolvimento é como fazer 
uma nova receita, enquanto produção é como fazer um prato. 
Receitas são formuladas por chefes de cozinha experientes que de 
certa forma desenvolveram habilidades e capacidade de combinar os 
ingredientes disponíveis para produzir o prato desejado. Desenvolver 
uma receita é um processo de descoberta, até os chefes mais 
experientes produzem diversas variações de um novo prato, fazem 
iterações, experimentações, até encontrar a melhor combinação de 
ingredientes que resulte em um prato rápido e sabor agradável. Não 
se espera que os chefes obtenham uma receita perfeita de primeira; 
espera-se produzir diversas variações como parte do processo de 
aprendizagem. Desenvolvimento de software é melhor concebido se 
este fizer parte de um processo de aprendizado similar ao de criar 
uma nova receita. A melhor abordagem para melhorar o ambiente de 
desenvolvimento de software é pela expansão do conhecimento.Práticas sugeridas para promover o conhecimento: 
25 
 
 
 
 Ciclos de feedback e inspeções e adaptações; 
 Desenvolvimento iterativo; 
 Equipes pequenas e cross-functional; 
 Treinamentos e Mentoring; 
 Criação e utilização de standards, guidelines e qualquer outro 
artefato; 
 Code Reviews; 
 Meios de compartilhamento de informações como um Blog ou 
Wiki; 
 
 
Adiar decisões / compromissos 
 
O principal conceito deste princípio é diminuir as incertezas 
retardando as decisões até que possam serem feitas com base em 
acontecimentos mais firmes, previsíveis e conhecidos. Decisões 
tardias tendem a ser mais acertadas porque as melhores decisões 
são feitas baseadas em fatos, e não em suposições ou 
especulações. Uma estratégia chave para adiar 
decisões/comprometimentos quando desenvolvendo um sistema 
complexo e com muitas incertas é usar a capacidade e práticas que 
permitam abraçar as mudanças tardiamente. 
 
Entregar rápido 
 
Sem entregas rápidas não é possível colher feedback. Sem entregas 
rápidas não é possível aprender com erros. Velocidade na entrega 
garante que o cliente receberá o que ele precisa hoje e não o que ele 
precisava ontem. 
 
Respeitar as pessoas 
 
Envolver os desenvolvedores nos detalhes das decisões técnicas é 
fundamental para o atingimento da exelência. 
O Software produzido é como um espelho da equipe de 
desenvolvimento. 
Para que as pessoas possam assumir responsabilidades, se sentir 
motivados e atuar como uma equipe eles precisam de confiança e de 
respeito. 
 
Otimizar o todo 
 
Otimizar desde o começo até o final: 
 
 Utilize Métricas 
 Diminua o número de métricas de desempenho individual mas 
valorize o desempenho da equipe. 
 Meça para cima: 
 Tempo de ciclo +Mapa de Fluxo de Valor 
 ROI + Modelo de Lucros e Perdas 
 Satisfação do Cliente + Entendimento das suas necessidades 
26 
 
 
 
Capítulo 2 
IMPLEMENTANDO O SCRUM 
 
SCRUM em 100 palavras 
 
Segundo COHN(2002) 
 Scrum é um processo ágil que permite manter o foco na 
entrega do maior valor de negócio, no menor tempo possível. 
 Isto permite a rápida e contínua inspeção do software em 
produção (em intervalos de duas a quatro semanas). 
 As necessidades do negócio é que determinam as prioridades 
do desenvolvimento de um sistema. As equipes se auto-
organizam para definir a melhor maneira de entregar as 
funcionalidades de maior prioridade. 
 Entre cada duas a quatro semanas todos podem ver o real 
software em produção, decidindo se o mesmo deve ser 
liberado ou continuar a ser aprimorado por mais um “Sprint”. 
Entendendo o SCRUM 
 
O SCRUM nasceu em um estilo de gerenciamento de projetos em empresa de 
fabricação de automóveis e produtos de consumo (TAKEUCHI & NONAKA, 1986). 
Eles perceberam que ao usar equipes pequenas e multidisciplinares, os resultados 
obtidos eram melhores. Nome SCRUM foi escolhido pela semelhança com o jogo de 
Rugby, pois ambos são adaptativos, rápidos e promovem a auto-organização. 
 
O SCRUM não ensina o que fazer em cada circunstância, mas sim a usar o senso 
comum para resolver as dificuldades encontradas. Senso comum é a combinação de 
experiência, treinamento, humildade e inteligência. 
 
O Scrum não vai dizer exatamente o que fazer, não irá resolver todos os seus 
problemas, mas com certeza os problemas serão mais facilmente identificados 
(PAULO PEREIRA, 2008). 
 
27 
 
 
 
Figura 6 – SCRUM não resolve tudo 
 
As características do SCRUM segundo STEFEEN (2011) 
 
 Trabalha de forma iterativa e incremental 
 As equipes são mutli-funcionais (cross-functional) e auto-
organizadas (self-organizing) 
 Foca em prioridade: equipe sabe por onde começar e o que é 
mais prioritário para o cliente 
 Objetividade: metas menores (por sprints) atingíveis e claras. 
 Visibilidade: clara visibilidade do que está completo e as 
pendências o que reduz os riscos e as incertezas associadas 
ao projeto 
 Aumento do ROI: entregando funcionalidades antes para a 
validação do cliente. 
 Maior flexibilidade a agilidade: permite rever o planejamento, 
mudar de direção ou fazer adaptações para as próximas 
iterações. 
 Não há prática de engenharia prescrita (o Scrum adequa-se a 
todas) 
 
Algumas vantagens do SCRUM segundo RAMOS(2010) 
 
 Processo bem definido e com time boxing; 
 Formação de profissionais auto-gerenciáveis; 
 Maior envolvimento do cliente; 
 Entregas freqüentes; 
 Desenvolvimento da equipe (liderança e auto-organização); 
 Foco no cliente: O time entende que sua tarefa é uma parte em 
um Sprint e vêem valor agregado no que estão fazendo; 
 O cliente torna-se responsável nas alterações de escopo; 
 
 
Empresas que utilizam o SCRUM: 
 Microsoft 
 Yahoo 
 Google 
 Electronic Arts 
28 
 
 
 High Moon Studios 
 Lockheed Martin 
 Philips 
 Siemens 
 Nokia 
 Capital One 
 BBC 
 Intuit 
 Nielsen Media 
 First American Real Estate 
 BMC Software 
 Ipswitch 
 John Deere 
 Lexis Nexis 
 Sabre 
 Salesforce.com 
 Time Warner 
 Turner Broadcasting 
 Oce 
 
Segundo COHN(2002), o SCRUM tem sido usado para 
 
 Software comercial 
 Desenvolvimento interno 
 Desenvolvimento contratado (terceirização) 
 Projetos de preço fixo 
 Aplicações Financeiras 
 Aplicações certificadas pela isso 9001 
 Sistemas embarcados 
 Sistemas disponíveis 24x7 
 Desenvolvimento por hackers solitaries 
 Video games 
 Sistemas para suporte à vida 
 Sistemas para controle de satélites 
 Websites 
 Software para handhelds 
 Telefones celulares 
 Aplicações para redes 
 Aplicações de ISV (Independent Software Vendors) 
 Algumas das maiores aplicações em produção 
 
 
29 
 
 
Porque mudar é preciso (e díficil) 
 
Em um mundo cada vez mais competitivo, ganha aquele que fornece o produto mais 
rápido, mais barato e com mais qualidade. As empresas começaram a perceber que 
precisavam mudar seu jeito de lidar com projetos para que se tornassem 
competitivas no mercado de trabalho. Apesar de identificar a necessidade de mudar, 
nem sempre é fácil fazê-la. 
 
 “A capacidade de mudança humana e, portanto, organizacional é limitada – 
peça que as pessoas mudem muitas coisas de uma só vez e elas se perdem; o 
estresse e a desorientação pertubadores do choque do futuro se instalam." (MIKE 
COHN, 2011, p. 31) 
 
A metodologia ágil cria a sensação de desenvolvimento mais rápido, e na verdade é, 
pois as entregas são feitas com mais freqüência, aproximando mais os stakeholders 
de seu produto. Além disso, com pequenas entregas, os defeitos e necessidades 
são encontrados antes e portanto, corrigidos antes. Esse processo custa menos 
para empresa e satisfaz mais o cliente. 
 
Escolhendo um projeto piloto 
 
Escolher um projeto para implementar o SCRUM é a tarefa mais desafiadora, pois 
nem todo projeto é adequado para ser o primeiro. 
 
A combinação de 4 pilares levam ao projeto certo, segundo COHN(2011, p. 104-105) 
 
1. Duração 
Se o projeto for muito curto, pessoas alegarão que o SCRUM 
só funciona em projetos pequenos. Caso o projeto seja longo, 
é dificil perceber o sucesso antes do fim. O ideal é projetos 
medianos, de 3 a 4 meses, onde seja possível o 
desenvolvimento do SCRUM, a adaptação das sprints e o 
sucesso do projeto. 
 
2. Tamanho 
 
O tamanho da equipe deve estar de acordo com o tamanho 
do projeto. Liderar muitas equipes de uma vez só pode não 
30 
 
 
ser uma experiência fácil. Começar com poucas equipes, no 
máximo 5, ajuda no aprendizado do SCRUM. 
 
3. Importância 
 
Apesar do projeto “sem muita importância” fazer mais sentido 
para iniciar o SCRUM, esse não deve ser escolhido. Projetos 
importantes desafiará mais a equipe, que portanto, irá se 
esforçar mais para o projeto obter sucesso. 
 
4. Engajamento do patrocinador do projeto 
 
Um patrocinador que apoie a utilização do SCRUM, pode 
ajudar em processos relacionados a departamento ou 
pessoas resistentes. 
 
Além dos quatro pilares citados acima, há o fator mais importantena escolha do 
primeiro projeto: as pessoas. Escolher as pessoas que irão compor a equipe do 
projeto piloto é uma tarefa dificil, pois envolve personalidade, profissionalismo, 
histórico dentro da empresa, capacidade de lidar em equipe e muitas outras 
características que juntas formam a essência de cada funcionário. 
 
31 
 
 
Papéis e responsabilidades 
 
O SCRUM possue três principais papéis: Product Owner, Scrum Master e Scrum 
team. 
 
 
Figura 7 – Papéis do SCRUM 
 
A definição de cada papel, segundo MARÇAL (2007) 
 
 O Product Owner ou dono do produto, basicamente o cliente, 
responsável por definir o que é o produto, quais as suas 
características, como e quais serão as funcionalidades do 
produto, suas prioridades e aprova ou não o resultado do 
trabalho desenvolvido. Como todo cliente possui a 
preocupação em obter a lucro com o produto desenvolvido. 
Defini a data de entrega e quando necessário redefini as 
prioridades e as características do produto. 
 
 O ScrumMaster trabalha próximo ao Product Owner, tem a 
responsabilidade da aplicação do método, ele deve garantir 
que a equipe seja funcional e produtiva e acompanhar o que 
está sendo realizado, ajudar a equipe removendo todo e 
qualquer impedimento que possa ocorrer no desenvolvimento 
dos Sprints, e também proteger a equipe de riscos e 
interferências externas e também o excesso de otimismo. 
32 
 
 
 A Scrum Team, também chamada de Equipe, é o conjunto de 
pessoas que possui a responsabilidade de desenvolver e 
entregar os Sprints realizados. Deve ter como características: 
ser disciplinada e auto-gerenciada, com atributos 
multifuncional e comprometidos com um objetivo comum. 
Geralmente são formados em pequenas quantidades. 
 
Os atributos de um bom ScrumMaster, segundo COHN(2011, p. 140-142) 
 
Responsável 
 
Um bom ScrumMaster pode e quer assumir 
responsabilidades. [...] No entanto, o ScrumMaster é 
responsável por maximizar o rendimento da equipe e ajudar 
seus membros a adotar e usar o Scrum. [...] um bom 
ScrumMaster triunfa ao assumir responsabilidades – o tipo 
especial de responsabilidade que não envolve poder. 
 
Humilde 
 
[...] Em vez de colocar suas necessidaes em primeiro lugar, o 
ScrumMaster humilde quer fazer o que for necessário para 
ajudar a equipe a atingir seu objetivo. Os ScrumMasters 
humildes reconhecem valor em todos os membros da equipe 
e pelo exemplo levam os outros a ter a mesma opinião. 
 
Colaborativo 
 
Um bom ScrumMaster trabalha para que exista uma cultura 
colaborativa dentro da equipe. [...] O ScrumMaster certo ajuda 
a criar uma atmosfera colaborativa para a equipe com 
palavras e ações. Quando surgem conflitos, os ScrumMasters 
colaborativos encorajam a equipe a pensar em termos de 
vencedores e perdedores. 
 
Comprometido 
 
[...] um bom ScrumMaster nã deixa muitos dias se passarem 
com obstáculos não resolvidos. [...] Uma maneira de um 
ScrumMaster demonstrar comprometimento é permanecendo 
nesse papel durante todo o tempo do projeto. A mudança do 
ScrumMaster no meio do projeto deestrutura a equipe. 
 
Influente 
 
Um ScrumMater bem-sucedido influencia os outros, tanto na 
equipe quanto fora dela. [...] O ScrumMaster deve saber 
como exercer influência sem recorrer a um estilo ditatorial do 
tipo “porque eu disse que é assim”. 
 
Informado 
 
Além de ter conhecimento sólido em Scrum e experiência no 
assunto, os melhores ScrumMaster também têm o 
conhecimento técnico de mercado [...] Embora os 
33 
 
 
ScrumMasters não precisem necessariamene ser gurus do 
marketing ou especialistas em programação, devem saber 
bastante sobre ambos para serem eficientes na liderança da 
equipe. 
 
Os atributos de um bom Product Owner, segundo COHN(2011, p. 152-153) 
 
Disponível 
 
[...] Ao estar disponível para a equipe, o dono do projeto 
demonstra comprometimento com o projeto. Os melhores 
donos do produto demonstam seu compromentimento fazedn 
o o que quer que seja para construir o melhor produto 
possível. 
 
Especialista no negócio 
 
É essencial que o dono do produto conheça o negócio. Como 
toomador de decisões relacionadas ao que vai ou não entrar 
no produto, o dono do produto deve ter um profundo 
conhecimento do negócio, das condições de mercado, dos 
clientes e dos usuários. 
 
Comunicativo 
 
Um bom dono do produto também deve escutar os usuários, 
clientes e talvez o mais importante, a equipe. [...] Além disso, 
todas as equipes terão muito a dizer para o dono do produto 
sobre riscos e desafios técnicos do projeto. Embora seja 
verdade qiue o dono do produto é quem prioriza todo o 
trabalho para equipe, um dono do produto inteligente dará 
ouvidos à sua equipe quando ela recomendar alguns ajustes 
nessas prioridades com base em fatores técnicos. 
 
Resoluto 
 
[...] reclamação comum que as equpes fazem sobre seus 
donos do produto é a falta de determinação. Quando os 
membros da equipe vão até o dono do produto com um 
problema, eles querem uma solução. [...] Tão ruim quanto um 
dono do prodtuo que não toma uma decisão, é aquele que 
resolve o mesmo problema várias vezes, mas com respostas 
diferentes. 
 
Autorizado 
 
Um bom dono do produto deve ser alguém imbuído de 
autoridade para tomar decisões e deve ser responsabilizado 
por elas.O dono do produto deve ser suficientemente 
graduado na empresa para receber esse nível de 
responsabilidade. 
 
 
 
34 
 
 
Artefatos 
 
Os principais artefatos do SCRUM são: Product Backlog, Sprint Backlog e Release 
Burndown. 
 
A definição de cada artefato, segundo SABBAGH (2010) são 
 
Product Backlog 
 
O product backlog é uma lista incompleta e dinâmica dos 
requisitos do produto, ordenados pela prioridade que eles têm 
em serem colocados em desenvolvimento. Assim, os itens do 
alto da lista, que serão implementados primeiro, devem ser de 
menor granularidade e devem possuir mais detalhes, como 
uma melhor descrição e podem possuir algum tipo de 
estimativa de esforço de desenvolvimento. Essa prioridade é 
dada, para um determinado momento, pelo valor que irá gerar 
para o cliente ou pelo risco que a sua não implementação 
representa. O product backlog nunca está completo, pois 
deve evoluir à medida que o produto e seu ambiente 
evoluem. Essa lista pode conter funcionalidades, correções 
de problemas, tecnologias e melhorias que constituem a 
mudança que deverá ser implementada no produto. 
 
Sprint Burndown 
 
O sprint burndown é um gráfico utilizado para acompanhar o 
progresso do desenvolvimento em direção ao final de uma 
sprint. Esse gráfico é criado na reunião de planejamento da 
sprint e deve ser atualizado diariamente. Ele mostra a soma 
dos tempos estimados restantes (ou outra unidade de medida 
de trabalho restante em uso) das tarefas que fazem parte do 
sprint backlog pelo tempo, representado pelos dias de 
desenvolvimento da sprint. 
 
Sprint Backlog 
 
O sprint backlog é composto por uma lista dos itens que 
serão desenvolvidos durante a sprint, suas tarefas 
correspondentes, o andamento do desenvolvimento dessas 
tarefas e suas estimativas de tempo de desenvolvimento, (se 
a equipe optar por utilizar estimativas). Seus itens são 
selecionados do product backlog na reunião de planejamento 
da sprint, onde cada um dos itens selecionados é quebrado 
em tarefas. O sprint backlog é modificado ao longo da sprint, 
de forma que suas estimativas, quando utilizadas, são 
atualizadas e tarefas podem surgir para os itens já existentes. 
A equipe de desenvolvimento é responsável pelo sprint 
backlog e deve garantir que ele tenha alta visibilidade e que 
se mantenha atualizado. Uma representação comum do sprint 
backlog é um quadro afixado na parede da sala de trabalho 
35 
 
 
dividido em colunas, contendo cartões ou papéis adesivos 
que indicam, dependendo de sua coluna, cada item que faz 
parte da sprint e as cada uma das tarefas correspondente a 
cada um dos itens (alinhadas horizontalmente a eles), 
divididas geralmente em três colunas que indicam o 
progresso do desenvolvimentoda tarefa: “a fazer”, “em 
desenvolvimento” (ou “em progresso”) e “pronto”. 
 
 
 
Dicas para criar um Sprint Backlog segundo FÉLIX (2008) 
 
1. Envolva toda a equipe no processo – Nunca é demais 
repetir, o envolvimento de toda a equipe no processo 
de descoberta do Sprint Backlog é importantíssimo. 
Numa equipe multidisciplinar todos poderão contribuir 
com atividades sob as diversas perspectivas que cada 
um tem sobre item a ser desenvolvido, gerando um 
Sprint Backlog muito mais rico do que se apenas os 
programadores participassem, ou apenas o guru 
técnico, etc. 
 
2. Discuta como o item será implementado - A lista de 
tarefas é apenas um dos outputs da segunda parte do 
Sprint Planning, antes de escrever as tarefas em post-
its é necessário que a equipe discuta de verdade 
como cada item será definido. A maior parte da 
reunião dever ser dedicada ao entendimento de como 
a equipe irá atacar o problema, definir um design 
básico da solução, verificar o código existente, discutir 
possibilidades de arquitetura, etc. Esse entendimento 
geral do problema e da possível solução farão com 
que as tarefas identificadas expressem realmente o 
trabalho que será feito. 
 
3. Tenha uma Definição de Pronto - Ter a “Definição de 
Pronto” disponível e visível a todos é muito, muito 
importante, essa definição servirá como um guia para 
o que deve ser feito, lembrando a todo mundo quais 
são os critérios de aceitação gerais para todos os 
itens do Product Backlog. 
 
4. Identifique todo o tipo de tarefa - Muitas equipes se 
concentram muito em tarefas de codificação, mas só 
codificar não é suficiente para entregar software 
funcionando de verdade. Todos os tipos de tarefas 
devem ser contemplados no Sprint Backlog, atividades 
de modelagem, codificação, aprendizado, tarefas de 
banco de dados, todos os tipos de teste possíveis, etc. 
A “Definição de Pronto” ajudará a equipe a pensar nos 
vários aspectos do trabalho. Trabalhando desse forma 
a equipe entenderá muito melhor qual a real carga da 
sprint. 
 
36 
 
 
5. Reveja o compromisso para a sprint – Após a 
identificação das tarefas, a equipe terá um 
entendimento melhor sobre o real esforço necessário, 
nesse momento o compromisso para a sprint deve ser 
reanalisado. OSelected Product Backlog realmente 
cabe na Sprint ? caso não, existem algumas 
alternativas. O item de menor prioridade pode ser 
removido ou quebrado em itens menores, estudar as 
técnicas de divisão deUser Stories são muito úteis 
nesse caso. O importante é que agora a equipe possa 
se comprometer de fato com o escopo da sprint. 
 
6. Não use tempo demais - Respeite o time-box. Estipule 
o tempo da reunião e não ultrapasse, faça a equipe se 
concentrar e trabalhar intensamente na discussão dos 
itens , assim as tarefas serão descobertas mais 
facilmente. Nem sempre a equipe conseguirá 
identificar tudo o que será realizado durante a sprint, 
mas isso não é um problema, o entendimento geral é 
mais importante. 
 
7. Evolua o sprint backlog durante a sprint - No dia-a-
dia da sprint a equipe terá um entendimento ainda 
melhor sobre cada item sendo desenvolvido, novas 
idéias podem aparecer, idéias antigas podem ser 
descartadas, o Sprint Backlog deve acompanhar essa 
mudanças. O Daily Scrum é um momento excelente 
para criar novas tarefas e descartar tarefas que se 
mostraram desnecessárias. 
 
37 
 
 
 
Figura 8 – Kanban de uma sprint 
 
Segundo HAZRATI(2010) 
 
O burndown revela dados importantes sobre o time como: o 
seu andamento e o que pode ser melhorado. Algumas 
empresas o utilizam para acompanhar a produtividade ou 
como ferramenta de coleta de dados para as retrospectivas, e 
principalmente indica como o time está evoluindo, através do 
seu acompanhamento a cada iteração. 
 
[...] Kane Mar separou o burndown em sete categorias: 
 
Fakey- Fakey: O andamento do gráfico é igual a linha ideal. 
A maioria dos sistemas possui alguma complexidade, 
portanto, deve existir alguma descoberta durante a execução. 
Esses gráficos são comuns em times que trabalham em um 
ambiente com comando e controle. 
 
Late-Learner: Esse gráfico possui uma linha crescente e uma 
curva decrescente no final do sprint. É comum para times 
novos de Scrum que estão aprendendo a metodologia e como 
se comunicar de forma efetiva. Geralmente a curva indica a 
percepção tardia que o teste é uma parte importante da 
entrega do software. 
 
Middle-Learner: A curva decrescente é apresentanda no 
meio do sprint, demonstrando mais maturidade do time, 
38 
 
 
especialmente na definição antecipada do que deve ser 
testado. 
 
Early-Learner: Times que apresentam progresso, possuem a 
curva decrescente no inicio do sprint, seguida de uma linha 
decrescente gradual. Nesse caso, o time aprendeu a 
importância de descobertas antecipadas, permitindo que 
trabalhem de forma mais eficaz. 
 
Plateau: Times que possuem uma fase inicial de progresso e 
não conseguem mantê-lo durante o sprint, possuem um curva 
decrescente seguida de um linha reta. 
 
Never-Never: Times que trabalham bem até um evento 
inesperado ocorrer no final do sprint, apresentam uma linha 
decrescente estável e no final do sprint uma curva crescente. 
A curva pode ocorrer porque o time esclareceu algo muito 
tarde ou o Product Onwer mudou o escopo, dificultando ou 
impossibilitando atingir as metas. Essas mudanças tardias 
devem ser levantadas e resolvidas na retrospectiva. 
 
Scope-increase: Esse gráfico possui um pico repentino na 
linha de trabalho restante, sendo comum em times que não 
analisam o escopo do trabalho necessário corretamente. 
Existem várias abordagem para esse tipo de problema, como 
negociar com o product owner ou até mesmo interromper o 
sprint. 
 
 
 
Figure 9 – Exemplo de gráfico de Burndown 
 
39 
 
 
Time Box 
 
[...] É ter o tempo, para fazer um trabalho, limitado, executando da melhor 
forma que puder nessa janela de tempo. É uma técnica simples usada no 
desenvolvimento de software para rastrear o progresso e para, simplesmente, ter o 
trabalho feito.” (LIMA, 2011). 
 
No SCRUM, os projetos são divididos em ciclos (tipicamente mensais) 
chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto 
de atividades deve ser executado. Metodologias ágeis de desenvolvimento de 
software são iterativas, ou seja, o trabalho é dividido em iterações, que são 
chamadas de Sprints no caso do SCRUM. 
 
 
Figura 10 – Ciclo de vida SCRUM 
 
Os principais time box do SCRUM são: Sprint , Planning meeting, Daily Scrum, 
Sprint Review e Retrospectiva. 
 
Sprint 
 
Segundo a IMPROVE IT (2007) 
 
40 
 
 
No Scrum, os projetos são dividos em ciclos (tipicamente 
mensais) chamados de Sprints. O Sprint representa um Time 
Box dentro do qual um conjunto de atividades deve ser 
executado. Metodologias ágeis de desenvolvimento de 
software são iterativas, ou seja, o trabalho é dividido em 
iterações, que são chamadas de Sprints no caso do Scrum. 
 
Mudanças na sprint segundo a LOCAWEB (2008) 
 
[...] vale lembrar que o Scrum é totalmente flexível para 
mudanças fora do sprint (ou seja, o backlog de histórias pode 
ser atualizado a qualquer hora), mas durante o período do 
sprint, as histórias que entram em um sprint não devem ser 
alteradas. Contudo, sabemos que exceções acontecem, 
desde atrasos ou adiantamentos que requerem uma mudança 
de planejamento, até histórias que têm de ser re-priorizadas 
ou retiradas do sprint. Na prática, o ideal é a equipe e o PO 
analisarem cada caso para tomarem a decisão correta. Se 
existe algo urgente a ser feito, pode valer mais a pena a 
equipe desenvolver essa história e deixar de entregar outra 
do que seguir o plano inicial e deixar a história urgente para o 
sprint seguinte. Cada caso é um caso. 
 
Mudança de Prioridade 
 
[...] A equipe está trabalhando no sprint, mas um problema 
urgente surge e deve ser resolvido ainda durante o mesmo 
sprint. 
 
O que deve ser feito: 
- Conversar, sempre. A situação é tão urgente que nãopode 
esperar 15 dias? A metodologia defende a idéia de que o 
sprint deve ser cancelado, já que o seu escopo está sendo 
alterado. Contudo, pode valer uma adaptação da 
metodologia: Fazendo uma renegociação, com a história 
urgente entrando no sprint, ao mesmo tempo em que outras 
histórias ainda não iniciadas saem, pode ser mais ágil do que 
propriamente cancelar o sprint e fazer um novo planejamento. 
- Tratar a atividade como impedimento, e discutí-la na revisão 
de sprint: Esse problema poderia ter sido previsto e/ou 
evitado? Pode acontecer novamente no futuro? 
 
O que não deve ser feito: 
- PO insistir na história urgente sem negociar: “É rápido e 
vocês resolvem fácil…” 
- Tratar a situação fora do sprint: Toda atividade realizada 
fora do sprint não aparece como resultado da equipe, e é 
importante saber se essa situação é frequente ou somente 
uma exceção. 
 
41 
 
 
Planning meeting 
 
Segundo a IMPROVE IT (2007) 
 
O Sprint Planning Meeting é uma reunião na qual estão 
presentes o Product Owner, o Scrum Master e todo o Scrum 
Team, bem como qualquer pessoa interessada que esteja 
representando a gerência ou o cliente. 
Durante o Sprint Planning Meeting, o Product 
Owner descreve as funcionalidades de maior prioridade para 
a equipe. A equipe faz perguntas durante a reunião de modo 
que seja capaz de quebrar as funcionalidades em tarefas 
técnicas, após a reunião. Essas tarefas irão dar origem 
ao Sprint Backlog. 
[..] 
Coletivamente, o Scrum Team e o Product Owner definem um 
objetivo para o Sprint, que é uma breve descrição daquilo que 
se tentará alcançar no Sprint. O sucesso do Sprint será 
avaliado mais adiante no Sprint Review Meeting em relação 
ao objetivo traçado para o Sprint. 
Depois do Sprint Planning Meeting, a equipe Scrum se 
encontra separadamente para conversar sobre o que eles 
escutaram e decidir quanto eles podem se comprometer a 
fazer no Sprint que será iniciado. Em alguns casos, haverá 
negociação com o Product Owner, mas será sempre 
responsabilidade da equipe determinar o quanto ela será 
capaz de se comprometer a fazer. 
 
 
Durante o Panning Meeting, as funcionalidades que serão desenvolvidas são 
chamadas de estórias. Essas estórias precisam ser estimadas para saber quantas 
são possíveis de fazer dentro da sprint. Essa estimativa leva em consideração o 
tamanho da equipe e o tempo da sprint. Para estimativa, é utilizado o Planning 
Poker. 
 
O Planning Poker segundo DURÃES(2011) 
 
[...] é uma técnica estimativa bastante utilizada em projetos 
ágeis que usam o framework do Scrum. [...] A ideia principal 
por traz do Planning Poker é permitir que todos os membros 
do time de desenvolvimento que estão comprometidos na 
implementação do Sprint participem colocando a sua visão de 
complexidade para que juntos possam chegar a um indicador 
de complexidade comum para o time. 
 
42 
 
 
[...] A escala de complexidade é baseada na sequência de 
Fibonacci (0, 1, 2, 3, 5, 8, 13) e cada participante do time que 
estiver comprometido recebe um conjunto de cartas sendo 
cada uma com o número de complexidade. O grupe se reúne 
geralmente na reunião Sprint Planning e esclarece as estórias 
com o PO (Product Owner) para depois estimar uma a uma. 
Seguindo a ordem de sequencia das às estórias já priorizadas 
pelo PO. Então o time conta até três e cada um apresenta 
uma das cartas ao mesmo tempo. Esse é um momento 
importante, pois nenhum membro pode influenciar o outro na 
hora de mostrar as cartas. 
 
Após apresentada as cartas confere-se os números das 
mesmas para ver se deu tudo igual ou ocorreu divergências. 
Em caso de divergência cada membro pode argumentar o 
que o levou a pensar diferente dos demais e nesse momento 
pode usar os argumentos que justifique aquele item ser mais 
complexo ou mais simples. 
 [...] Após a apresentação dos argumentos cada pessoa que 
ficou na dúvida pode propor uma nova votação e mudar o seu 
voto para mais ou para menos conforme o novo entendimento 
da questão. Por isso um item que estava complexo pode ser 
finalizado com mais simples ou vice-versa prevalecendo o 
entendimento do time sobre a questão. 
 
[...] O grande diferencial é que não tem ninguém de fora 
interferindo, pois só participa quem realmente vai codificar a 
funcionalidade e com isso cada pessoa usa a sua experiência 
pessoal como implementações em projetos anteriores ou 
conhecimento da tecnologia em questão e isso faz com que 
ela se comprometa, pois é ela que está falando o quando é 
complexo aquele item. É uma forma simples de se estimar 
indo direto ao ponto e principalmente provoca uma 
colaboração natural entre os membros do time resultando em 
grandes ganhos para o projeto. 
 
 
 
Figura 11 – Exemplo de Planning Poker 
 
As estimativas ficam mais precisas conforme as sprints vão acontecendo. Para que 
isso aconteça, o ideal é ter sempre o mesmo time e tentar nivelar o conhecimento da 
tecnologia usada no projeto. 
43 
 
 
 
Daily Scrum 
 
Segundo a IMPROVE IT (2007) 
A cada dia do Sprint a equipe faz uma reunião diária, 
chamada Daily Scrum. Ela tem como objetivo disseminar 
conhecimento sobre o que foi feito no dia anterior, identificar 
impedimentos e priorizar o trabalho a ser realizado no dia que 
se inicia. 
Os Daily Scrums normalmente são realizadas no mesmo 
lugar, na mesma hora do dia. Idealmente são realizados na 
parte da manhã, para ajudar a estabelecer as prioridades do 
novo dia de trabalho. 
Todos os membros da equipe devem participar do Daily 
Scrum. Outras pessoas também podem estar presentes, mas 
só poderão escutar. Isso torna os Daily Scrums uma 
excelente forma para uma equipe disseminar informações 
sobre o estado do projeto. 
O Daily Scrum não deve ser usado como uma reunião para 
resolução de problemas. Questões levantadas devem ser 
levadas para fora da reunião e normalmente tratadas por um 
grupo menor de pessoas que tenham a ver diretamente com 
o problema ou possam contribuir para solucioná-lo. Durante o 
Daily Scrum, cada membro da equipe provê respostas para 
cada uma destas três perguntas: 
 
 O que você fez ontem? 
 O que você fará hoje? 
 Há algum impedimento no seu caminho? 
 
Concentrando-se no que cada pessoa fez ontem e no que ela 
irá fazer hoje, a equipe ganha uma excelente compreensão 
sobre que trabalho foi feito e que trabalho ainda precisa ser 
feito. O Daily Scrum não é uma reunião de status report na 
qual um chefe fica coletando informações sobre quem está 
atrasado. Ao invés disso, é uma reunião na qual membros da 
equipe assumem compromissos perante os demais. 
Os impedimentos identificados no Daily Scrum devem ser 
tratados pelo Scrum Mastero mais rapidamente possível. 
 
Sprint Review 
 
Segundo CRUZ (2011) 
 
O objetivo maior desta reunião é a revisão dos itens 
concluídos pelo Product Owner, ou pelo cliente. A melhor 
maneira de fazer isso é justamente realizar 
uma apresentação, ao estilodemonstração, de todos os itens 
44 
 
 
concluídos ao PO. Com isso ele poderá conferir e avalir o que 
está sendo considerado pronto, levando em conta o que está 
sendo entregue versus o quedeveria ser entregue. 
 
[...] Quando o Time começa a melhorar a qualidade de suas 
entregues nas Reviews, a auto-estima melhora, 
aconfiança do Time em si mesmo aumenta, e 
a positividade começa a tomar conta do Time, fazendo com 
que a sua melhoria torne-se cada vez mais contínua. 
 
Retrospectiva 
 
Segundo a SABBAGH (2010) 
No Scrum, as reuniões de retrospectiva têm o objetivo de 
promover melhorias incrementais. Nessa reunião, os 
membros da equipe identificam e priorizam o que consideram 
que foi bem e o que consideram que pode melhorar, traçando 
planos de ação para realizar essas melhorias. 
[...] 
As reuniões de retrospectiva devem ser obrigatoriamente 
realizadas ao final de cada ciclo de desenvolvimento, ou 
sprint. 
 
 
Algumas técnicas para melhorar a retrospectiva segundo MACAUBAS (2008) 
 
1. Deixar os membros da equipe trabalharem - ficar em 
frente da sala e fazertodo o trabalho de escrever 
desencoraja os mebros da equipe de tomarem a 
iniciativa das idéias. Em vez disso faça-os escrevem 
tudo grandes post-it (usando marcadores escuros) – 
isso mantém todos envolvidos e encoraja ainda mais 
as pessoas quietas a participarem. 
2. Anotar fielmente – um facilitador (ou ScrumMaster) 
está aí para capturar idéias do grupo e não filtrar ou 
injetar sua própria idéia. 
3. Usar processamento paralelo – quando houver mais 
que uma ou duas áreas problemáticas para debater, 
quebre o grupo em dois ou três e faça uma análise 
das causas. Além de acelerar as coisas isso reduz a 
influência de uma ou duas vozes barulhentas na 
equipe. 
4. Deixar os membros da equipe tirarem conclusões – 
ocasionalmente os facilitadores (ou ScrumMaster) vão 
olhar para os dados brutos gerados pela equipe e 
dizer quais são suas conclusões sem permitir que a 
equipe faça seu próprio trabalho. Na verdade o 
facilitador está dizendo que não valoriza o feedback 
da equipe. Apesar de que pode levar algum tempo 
para que a equipe analise os dados por si só, eles 
45 
 
 
chegam a melhores conclusões e tomam posse dos 
resultados e das ações a serem executadas. 
5. Teste de entendimento – após um curto período de 
debate é útil testar para ver se a equipe alcançou um 
entendimento comum (nem sempre na decisão final, 
algumas vezes apenas em algum ponto no meio do 
caminho). Uma decisão deve ser proposta e uma vez 
que todos tenham feito perguntas esclarecedoras, nós 
testamos isso usando o “Fist of Five“. Com esta 
técnica o número de dedos indica o grau de apoio: 
Cinco – eu gostaria que essa idéia fosse minha pois 
vou ajudar a mudar; Três – eu posso viver com isso. É 
a vontade da equipe; Um – existem questões que eu 
preciso discutir; Mão fechada – Ausência de voto, eu 
quero impedir o consenso e forçar mais discussão. 
 
Qualidade 
 
“Quanto mais cedo os defeitos nos sistemas forem corrigidos, menor é o custo de 
correção para o Projeto. (GLENFORD, 1979, p. 8) 
 
Segundo COHN(2011, p. 328) 
[...] algumas equipes perceberam que testar a qualidade no 
fim além de ser ineficiente era insuficiente. 
[...] As equipes Scrum tornam o teste uma prática e uma parte 
centrais do processo de desenvolvimento em vez de algo que 
ocorre após os desenvolvedores terem “acabado”. Em vez de 
testarmos a qualidade depois de um produto ter sido 
construído, ela deve ser incorporada ao processo e ao 
produto à medida que ele é desenvolvido. 
[...]Da mesma forma que todos os clientes sofrem quando um 
produto tem baixa qualidade, a equipe inteira sofre quando os 
testes nãosão integrados ao processo ou não são executados 
nos níveis certos. Adquiris novas habilidades de teste, 
aprender como aplicá-las dentro dos timeboxes rigorosos do 
Scrum e saldar a dívida ténica são responsabilidades da 
equipe inteira. Esses não são desafios para serem deixados 
para os testadores. Uma boa equipe Scrum ficará 
constantemente alerta para o estado de suas práticas de 
teste, sempre procurando maneiras de melhorar. 
 
Benef[icios do time de teste no SCRUM, segundo ELIZA E LAGARES(2010) 
 
 Integração do time; 
 Apoio de quem está desenvolvendo código durante a 
execução dos testes; 
46 
 
 
 Apoio de quem está testando código durante a 
codificação; 
Participação mais direta e ativa do profissional que 
está testando o software; 
 Profissionais que estão desenvolvendo código 
interessados em aprender sobre teste; 
 Profissionais que estão testando código interessados 
em aprender sobre programação; 
 Agilidade, interação com testes; 
 Acompanhamento de defeitos pelo profissional que está 
testando o software; 
 Analistas de Teste deixam de ser reativos para serem 
pró-ativos. 
47 
 
 
 
Capítulo 3 
ESTUDO DE CASO 
 
O Instituto de Tecnologia XPTO ingressou no mercado no início do século XXI. A 
empresa é dividida em vários laboratórios, entre eles, um específico para área de 
desenvolvimento de software. No início, não era usado nenhuma metodologia para 
acompanhamento de projetos. Eram utilizado alguns conceitos básicos, como: 
tarefas, cronogramas, documentação do projeto, entre outros. 
 
Conforme os anos se passaram, o instituto começou a amadurecer: a demanda de 
projetos foi aumentando, e consequentemente, a quantidade de colaboadores. 
Cargos mais específicos foram sendo criados na organização para desempenhar os 
papeis certos, tais como: analista, testes e gerente de projetos. Uma framework foi 
construída para desenvolvimento de projetos, na qual envolvia arquitetura e 
padronização de código. A empresa evoluiu em muitos aspectos desde o início, 
porém, ainda não tinha uma metodologia para gerenciamento de projetos, e isso, 
fazia muita falta para o instituto, que ao entregar um projeto, muitas vezes consumia 
mais tempo e verba do que era planejado. Esse mal planejamento começou a ficar 
evidente e com frequencia, portanto, a organização percebeu que devia investir em 
algum método para melhorar o processo de acompanhamento do projeto. 
 
Em 2009, a empresa resolveu investir em uma metodologia, e consequentemente, 
em sua certificação. Com a ajuda do gestor na época, a certificação escolhida foi o 
CMMI. 
 
48 
 
 
CMMI (Capability Maturity Model Integration) 
 
O CMMI é uma metodologia com grande valor no mercado. Muitos clientes procuram 
empresas com o “selo” do CMMI. Acreditam que essa é uma boa referência de 
qualidade de produto, reponsabilidade da organização e competência no mercado 
de trabalho. Esse foi um dos motivos pelo qual a empresa optou por essa 
metodologia. Além disso, o CMMI é reconhecido mundialmente e poucas empresas 
conseguem atingir o nível exigido. O CMMI tem como base a melhoria de processo e 
as seguites definições: 
 
 Coleção de melhores práticas 
 Framework para organizar e priorizar atividades 
 Apoio para coordenação de atividades multi-disciplinares que podem ser 
requeridas para contruir produtos com sucesso. 
 Enfatiza o alinhamento dos objetivos da melhoria do processo com os 
objetivos de negócios da organização. 
 
O CMMI é dividido em 5 níveis de maturidade. Além disso, abrange 22 áreas de 
processos. Esses processos são divididos de acordo com nível de maturidade. 
Quanto maior o nível, mais áreas de processos a empresa precisa atingir. Os níveis 
são divididos da seguinte forma: 
 
Nível Área de processo 
5 Gestão de processo organizacional (OPM) 
Análise causal e resolução (CAR) 
4 Desempenho de processo organizacional 
(OPP) 
Gerenciamento quantitativo de projeto 
(QPM) 
3 Desenvolvimento de requisitos (RD) 
Solução técnica (TS) 
Integração de produto (PI) 
Verificação (VER) 
49 
 
 
Validação (VAL) 
Foco de Processo organizacional (OPF) 
Definição de processo organizacional (OPD) 
Treinamento organizacional (OT) 
Gerenciamento integrado de projeto (IPM) 
Gerenciamento de riscos (RSKM) 
Análise de decisão e resolução (DAR) 
2 Gerenciamento de requisitos (REQM) 
Planejamento de projeto (PP) 
Acompanhamento e controle de projeto 
(PMC) 
Gerenciamento de acordo com o fornecedor 
(SAM) 
Medição e análise (MA) 
Garantia e qualidade de processo e produto 
(PPQA) 
Gerência de configuração (CM) 
1 Nenhum processo é implementado 
 
Para obter o nível de maturidade no CMMI, é necessário implementar as áreas de 
processos correspondente. Uma área de processo é implementada quando o 
objetivo de cada área é atingido. Para isso, cada área é dividido com práticas gerais 
e práticas específicas. Cada prática resulta em artefatos que devem ser 
desenvolvidos pela empresa, como: documentos, e-mail, codificação, entre outros. 
Quando os artefatos são criados da maneira correta, o objetivo da prática é atingido, 
porém, os artefatos devem seguir um padrão e todos os projetos que seguem o 
CMMI devem produzir esses artefatos. 
 
Foram escolhidos 13 colaboradores para fazer a primeira fase do treinamento do 
CMMI. Nesse primeiro momento, foi explicadoos conceitos do CMMI, todas as 
práticas, as metas de cada uma delas, e como alcançar os objetivos de cada prática. 
Após o primeiro treinamento, os integrantes ficaram responsáveis por criar 
processos para cada prática do CMMI. Os processos deviam descrever como a 
organização faria para atingir os objetivos das práticas do CMMI, descrevendo quais 
50 
 
 
artefatos deveriam ser criados e qual padrão os artefatos deveriam seguir. O 
documento era escrito por um integrante e revisado por outro. 
 
Conforme os documentos foram escritos, os colaboradores foram percebendo que 
alguns processos seriam dificeis de serem atingidos, pois exigiam bastante 
documentação, check lists e outros artefatos de exigência do CMMI. Foi decidido 
que apenas alguns projetos seriam selecionados para passar pela avaliação do 
CMMI. 
 
Como parte do processo, um segundo treinamento foi feito. Para a segunda parte, 
apenas 8 colaboradores participaram. Esse segundo treinamento preparava a 
equipe para a pré-avaliação do CMMI. Essa pré-avaliação era bem exigente: eram 
feitas entrevistas com qualquer colaborador da empresa, independentemente se 
tinha feito o treinamnto ou não, para avaliar se o processo estava institucionalizado 
dentro da empresa de forma homogênea. Todos os colaboradores devem saber 
como o processo funciona. 
 
Como a empresa não estava madura o suficiente, o objetivo não foi alcançado. Um 
dos motivos foi que alguns colaboradores não tinham uma função bem definida: 
eram analistas, desenvolvedores, gerente de projetos, ao mesmo tempo, muitas 
vezes no mesmo projeto. Com tantas funções, era impossível praticar todos os 
processos que o CMMI exigia. Além disso, com tantas funções para uma pessoa, 
ficava ainda mais díficil criar todos os artefatos necessários. Após falhar na primeira 
avaliação, o instituto percebeu que não teria como dar continuidade na certificação, 
pois não estavam estruturados naquele momento para atingir a nota mínima. 
 
Porém, a empresa não desistiu de ter um metodologia para acompanhamento de 
projeto: os próprios colaboradores sentiam falta de um método para seguir. A falta 
do método implicava em projetos sendo desenvolvidos de forma diferente, de acordo 
com a vivência de cada gerente de projetos. 
 
Por iniciativa dos próprios colaboradores, eles começaram a pesquisar metodologias 
do mercado. Como o CMMI exigia muitos documentos, eles partiram para 
metodologias que não fossem tão “burocrática” nesse sentido. A idéia não era abolir 
51 
 
 
a documentação, pois ela já existia, funcionava bem e devia ser mantida, mas seguir 
um padrão que não exigisse tantas mudanças organizacionais. Começaram a 
pesquisar no mercado e encontraram as metodologias ágeis. A empresa se 
identificou pois a metodologia possui documentação, se adequeava na estrutura da 
organização e tinha como foco manter o cliente satisfeito. 
 
A metodologia SCRUM foi escolhida sem muitos estudos. Alguns colaboradores 
fizerem um curso e passaram para os demais da empresa. Um projeto piloto foi 
escolhido para implementar a metodologia. Apesar de ser menos exigente que o 
CMMI, isso não significa que a empresa não preciaria fazer grandes mudanças para 
se adequar ao SCRUM e portanto, algumas dificuldades foram encontradas. 
 
Dificuldades no SCRUM 
 
O SCRUM foi bem recebido por alguns colaboradores e criticados por outros. 
Algumas das dificuldades encontradas no SCRUM foram: 
 
 Imaturidade da equipe 
 Gerente de projetos “sem autoridade” 
 Escolha do SCRUM Master 
 Prazos 
 Cliente não respeitar a metodologia 
 
Imaturidade da equipe 
 
Esse problema aconteceu na grande maioria das equipes que utilizam o SCRUM na 
organização. A maturidade é um dos pontos mais importantes na metodologia 
SCRUM, pois, o time é auto-gerenciável e deve assumir os erros quando são 
cometidos ou a responsabilidade de itens quando são prometidos. Quando uma 
sprint falha, é porque a equipe como um todo falhou, e não apenas um integrante. 
 
No SCRUM não existe uma pessoa com dificuldade: se a dificuldade existe para 
pelo menos um, todo o time tem dificuldade. A idéia é que todos trabalhem juntos a 
52 
 
 
fim de conquistar o objetivo da sprint, portanto, o time deve ser integrado e com 
grande habilidade de trabalhar em equipe. 
 
O amadurecimento é conquistado no decorrer das sprints, pois o time vai se 
conhecendo e entendendo a melhor forma de traballhar junto. Quando as tarefas 
surgem, o time deve conversar entre si, para identificar qual a maneira mais 
produtiva de realizar essa tarefa. 
 
Além disso, a retrospectiva ajuda bastante, pois é vista como a reunião de “lavar 
roupa suja”. Apesar de ser vista assim, ela é muito produtiva, pois cada um pode 
expor o que gostou e o que não gostou da sprint que passou. O que for um 
problema, precisa de um plano de ação para melhorar e assim não cometer os 
mesmos problemas nas sprints futuras. Entretanto, o plano de ação deve ser 
executado para resolver o problema. Caso o item seja identificado, criado o plano de 
ação porém não colocado em prática, o item continua na estaca 0. 
 
Gerente de projetos “sem autoridade” 
 
O gerente de projetos está acostumado a saber todas as funcionalidades que serão 
entregues no projeto. É criado um cronograma com todas as tarefas, com seu 
respectivo tempo, e atribuída para o desenvolvedor fazê-la. 
 
No SCRUM, um cronograma inicial pode ser criado, porém, de acordo com a 
necessidade do cliente ele pode ser mudado (dentro do tempo que não prejudique a 
entrega) . Além disso, o gerente não atribui mais tarefas para a equipe: os próprios 
integrantes são livres para escolher o que irão desenvolver. 
 
Essa “falta de controle” assusta o gerente de projetos. Para isso, é necessário criar 
um elo de confiança maior, onde a equipe se compromete a entregar e o gerente de 
projetos a confiar que será entregue. Entretanto, continua sendo responsabilidade 
do gerente de que a entrega vai ser feita, por isso, é preciso trabalhar junto da 
equipe, resolver impedimentos, entender dificuldades e avisar o cliente que não será 
possivel entregar (quando necessário). 
 
53 
 
 
Escolha do SCRUMMaster 
 
Seu papel é ajudar a resolver impedimentos para a equipe, portanto, é preciso 
disponibilidade e autonomia. A disponibilidade é para sempre que necessário os 
integrantes da equipe possam acessá-lo, ou o mais breve possível, e autonomia 
para que seja possível tomar as decisões necessárias e resolver o impedimento. 
Além disso, esse papel ajuda o time a seguir a metodologia, então, é necessário de 
alguém com o conhecimento do SCRUM. 
 
A organização errou ao escolher um SCRUMMaster que nunca tinha estudado ou 
feito um treinamento sobre a metodologia. Obviamente, ele sentiu dificuldade em 
seguir os conceitos, o qual a equipe conhecia mais que ele, e de cobrá-los. Isso 
gerou descontentamento e influenciou no trabalho da equipe. 
O SCRUMMaster deve garantir que o SCRUM seja seguido, portanto, deve ter o 
conhecimento da metodologia. 
 
Prazos 
 
Os prazos são criados no Planning Meeting. É responsabilidade do Product Owner 
dizer o que precisa ser feito e qual é a prioridade das tarefas. A equipe deve se 
reunir e estimar os pontos, até que cheguem nos pontos que a equipe consegue 
produzir por sprint. O prazo pode ser influenciado por vários motivos: subestimar 
uma tarefa, dificuldade na hora de implementar, falta de ambiente, entre outras 
variaveis. Entretanto, é papel do time avisar o quanto antes que não será possível 
alcançar o que foi prometido na sprint e o motivo que ocasionou essa situação. 
 
Em um projeto na organização, o prazo foi um grande problema: o time avisava que 
não seria entregue alguns itens da sprint muito próximo do final e isso, obviamente, 
gerava desconforto do cliente. A transparência é algo muito importante, 
independentemente da metodologia utilizada, porém,