Documente Academic
Documente Profesional
Documente Cultură
do Scrum
Rio de Janeiro
Escola Superior de Redes
2016
Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simões
Edição
Lincoln da Mata
Versão
1.0.0
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Sumário
1. Introdução
A importância da informação e a crise do software 1
Crise do software 2
Exercício de fixação – Como você entende que o Scrum pode melhorar a produtividade na
sua organização? 7
Processo Scrum 8
Papéis do Scrum 9
Exercício de fixação – Na sua organização, que papéis atuais poderiam ocupar os papéis do
Scrum em uma eventual transição para Scrum? 9
Fluxo do Scrum 9
Visão Scrum 13
Transparência 14
Inspeção 14
Adaptação 14
Exercício de fixação – O que você acha que precisa mudar na mentalidade da sua organiza-
ção para adotar um processo de gestão de projetos ágil como o Scrum? 15
Desenvolvedores 16
Scrum Escalável 17
Atividades práticas – Cenário para escolha sobre um processo a ser adotado 18
iii
2. O Scrum
Fase de especificação 19
Fase de projeto 20
Fase de implementação 20
Fase de teste 20
Fase de manutenção 21
Vantagens e desvantagens 22
Velocidade e qualidade 26
Vantagens e desvantagens 26
Exercício de fixação – Você acredita que a sua organização e os seus clientes se beneficia-
riam da adoção de uma metodologia como o Scrum? 27
Histórico do Scrum 27
Exercício de fixação – Você acredita ser possível ter uma equipe auto-organizável na sua
organização? Qual o contexto para possibilitar tal auto-organização? 29
Origem do nome 29
O processo 31
Empírico 31
Iterativo e incremental 32
Fases do Scrum 32
Tamanho de projetos 33
3. A metodologia
Papéis 36
Product Owner 36
Scrum Master 36
Equipe de desenvolvimento 37
Cerimônias 38
iv
Reunião de planejamento da Sprint (Planning Meeting) 38
Artefatos 43
Planning Poker 45
Product Backlog 51
Sprint Backlog 53
Release Burndown 54
Gráfico de Burndown 55
Task Board 57
Release 57
Atividades práticas 58
4. Scrum e a organização
Scrum e o ciclo PDCA 59
Infraestrutura 61
Staging 61
Equipes distribuídas 62
Daily Scrum 64
Szcrum of Scrums 66
Dicas gerenciais 66
Governança 68
Conformidade a padrões 69
Atividades 72
v
vi
1
Introdução
objetivos
Entender a crise do Software. Por que se tornar ágil vale a pena? Introdução
ao processo scrum. Realizando a transição de um processo peso-pesado para um ágil.
conceitos
Crise do Software. Processos ágeis e Motivação. Processos peso-pesado e transição
É por essa razão que gestores necessitam ter cautela nesse processo, bem como contar
com ferramentas que habilitem uma decisão que seja tomada estrategicamente, orientada
de maneira a não prejudicar a organização, levando em consideração as oportunidades de
negócio e garantindo a prosperidade das empresas, e o prejuízo que pode incorrer caso
decisões sejam tomadas incorretamente.
As organizações hoje consideram a informação como o seu principal ativo – é através dela
que os gestores decidem os caminhos a serem traçados. A informação tem o poder de dar
suporte e orientar decisões de negócios.
1
A existência de um universo rico com uma quantidade imensa de informação tem deixado
pessoas e empresas um pouco perdidas, e o tomador de decisão pode, por vezes, ficar
confuso. Ter muita informação não significa que a empresa está bem informada.
É nesse contexto que surge a ciência da gestão da informação que, para Siqueira q
Marcelo Costa, autor do livro “Gestão Estratégica da Informação”, significa “a ação
sistêmica de procurar entender as necessidades informacionais de uma organização e
disponibilizá-las para a solução de problemas organizacionais, de forma estruturada
e clara, com conhecimento pleno de todos os procedimentos e processos da solução
encontrada, garantindo assim que ele seja eficaz e repetível”.
Como se pode imaginar, ter a informação certa na hora certa e não é uma tarefa fácil.
As informações devem ser exatas, relevantes e estar disponíveis em tempo hábil.
A gestão da informação, portanto, busca resolver o problema de buscar uma forma eficiente
de coletar e processar apenas as informações essenciais e indispensáveis, uma vez que é
humanamente impossível digerir a imensa quantidade de informações colocadas à disposição.
Crise do software
Paralelamente a essa necessidade pela produção de software relevante, que existe até os dias q
de hoje, um termo acerca de sua produção foi firmado nos primeiros dias da ciência da com-
putação e diz respeito à dificuldade de escrever programas de computador realmente úteis e
eficientes dentro do tempo necessário para as partes interessadas: “crise do software”.
A crise do software se deu por causa das melhorias rápidas nas capacidades dos compu-
tadores, e levando em consideração as complexidades dos problemas que conseguiriam
resolver. Com o aumento da complexidade dos softwares, muitos problemas dessa
natureza surgiram porque os métodos existentes não se mostraram suficientes.
2
As causas da crise do software estão ligadas à complexidade geral do hardware e o pro- q
cesso de desenvolvimento de software. A crise manifesta-se de várias maneiras:
A ideia principal por trás da crise é que as melhorias no poder de computação sobre-
pujaram a capacidade dos programadores de utilizarem eficazmente esses recursos.
Vários processos e metodologias foram desenvolvidos ao longo das últimas décadas
para melhorar a gestão da qualidade de software, tais como programação processual
e programação orientada a objetos. No entanto, projetos de software que são grandes,
complicados, mal especificados e que principalmente envolvem aspectos desconhecidos
ainda são vulneráveis a problemas grandes demais, imprevistos.
As organizações que se tornam ágeis adotando um processo como o Scrum têm expe-
rimentado benefícios significativos, incluindo ganhos dramáticos de produtividade com
diminuições correspondentes em custo. Elas são capazes de levar produtos ao mercado
muito mais rapidamente e com maior grau de satisfação do cliente, além de experi-
mentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibi-
lidade de resultados.
Uma das primeiras organizações a entender esses benefícios a adotar o Scrum foi a
Salesforce.com. Fundada em 1999 em um apartamento de San Francisco, a Salesforce.
com é uma das histórias de sucesso duradouras da época das pontocom. Em 2006, com
uma receita de mais de US$ 450 milhões e 2 mil funcionários, a Salesforce.com notou que
a frequência das suas releases tinha diminuído de quatro por ano para apenas uma. Os
clientes estavam recebendo menos entregas e esperando mais tempo para obtê-las, e algo
precisava ser feito. A empresa decidiu a transição para Scrum. Durante o primeiro ano de
mudança, a Salesforce.com:
11 E mais de 500% mais valor aos seus clientes em relação ao ano anterior.
Nos dois anos seguintes, a receita mais que dobrou, para mais de US$ 1 bilhão. Com
Capítulo 1 - Introdução
resultados como esses, não é surpreendente que tantas organizações fizessem a tran-
sição para Scrum. Ou pelo menos tentassem.
A transição para Scrum e outros métodos ágeis é difícil: muito mais difícil do que muitas
empresas antecipam. As alterações necessárias para colher todos os frutos que se tornar
ágil pode trazer são de longo prazo. Tais mudanças exigem grande quantidade de esforço
não só por parte dos desenvolvedores, mas de toda a organização. Não se trata apenas de
3
uma mudança das práticas, é necessário mudar a mentalidade e a forma de trabalho esta-
belecida. O objetivo deste curso, portanto, não é apenas mostrar como fazer essa transição
adequadamente, mas também como obter sucesso no longo prazo.
Toda mudança é difícil. Mudanças maiores podem ser ainda mais difíceis. No entanto, q
existem ainda certas características de transição para Scrum que o tornam mais difícil
do que a maioria das outras mudanças.
Uma mudança, para ser considerada de sucesso, não depende exclusivamente de ser
de cima para baixo ou de baixo para cima (ou seja, há múltiplos fatores que determinam
o sucesso da mudança): em uma mudança top down (de cima para baixo), um líder
influente compartilha uma visão do futuro e a organização segue o líder em direção a
essa visão.
Imagine um líder carismático, respeitado e poderoso como Steve Jobs dizendo a seus
funcionários da Apple que eles são se movendo “para além de hardware e software de
computador para dominar a música digital”. A sua reputação e estilo poderia ter apontado
a empresa em uma nova direção, mas isso por si só não teria sido suficiente para realizar
uma proeza tão improvável. Da mesma forma, sem compromisso operacional, as pessoas
l
O estado final é
resistem à cadeia de comando. Assim, a participação bottom-up (de baixo para cima) será imprevisível: uma
necessária, pois será o indivíduo, ou seja, os membros da equipe que trabalham com as transição para Scrum
não pode ser tal que
questões que vão descobrir como Scrum vai funcionar melhor dentro de sua organização.
“articula e define o todo
Assim, a chave para qualquer sucesso na adoção de Scrum será a combinação elementos de o processo de mudança
bottom-up e mudança top-down. necessária para
preencher a lacuna
Criar esse plano exigiria saltar dois obstáculos impossíveis: em primeiro lugar, saber exata- entre ‘como’ e ‘ser’ e
cria planos táticos”,
mente onde nós queremos acabar e, em segundo, saber exatamente os passos para chegar
como em um de
lá. Como não podemos superar essas impossibilidades, o melhor que se pode fazer é adotar gerenciamento de
uma abordagem de “provocar e observar” (Avery De, 2005), em que se pode tentar algo, ver mudanças tradicional,
segundo Carr, Duro, e
se ele nos move mais perto de um objetivo intermediário, verificar se o estado melhorou e, Trahant.
em caso afirmativo, fazer mais do mesmo. Esses processos da organização não são aleató-
rios, são cuidadosamente selecionados com base na experiência, conhecimento e intuição,
para dirigir uma transição para o Scrum.
l
Apresentar a revisão de prontidão operacional quase certamente vai impactar as finanças, Scrum é generalizada:
vendas ou outros departamentos. Portanto, cada um desses departamentos pode ser se tornar ágil terá
implicações para a
afetado pela Scrum. Dessa maneira, grupos financeiros terão de conciliar as políticas da organização que vão
empresa na capitalização com a maneira de como projetos Scrum se comportam quando muito além do
departamento de
estão em execução. As vendas e o marketing podem querer alterar como comunicam os
desenvolvimento de
seus prazos e o escopo, e podem mudar a forma como estruturam contratos. Com mais software.
grupos afetados por uma mudança para o Scrum, há mais chance para aumentar a resis-
tência e certamente mais chance de problemas, o que pode tornar a transição para Scrum
ainda mais difícil.
l
Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho é testar Scrum é dramatica-
para conformidade com uma especificação de requisitos. Por sua vez, os programadores mente “diferente”: as
mudanças criadas
Fundamentos do Scrum
foram treinados para analisar um problema em profundidade e para conceber uma solução através da adoção do
perfeita antes que qualquer codificação comece. Em um projeto Scrum, testadores e progra- Scrum se permeiam ao
longo do desenvolvi-
madores precisam desaprender esses comportamentos. Testadores passam a entender que
mento, e muitas dessas
o teste é também entender que o sistema precisa estar em conformidade com as necessi- mudanças vão de
dades do usuário. Já os programadores entendem que um design nem sempre é necessário encontro à formação
passada da maior parte
(e às vezes nem mesmo desejável) antes que a codificação comece.
dos funcionários.
4
Como a transição para Scrum inclui pedir às pessoas para trabalhar de uma forma diferente
daquela que estão familiarizadas, ou seja, de uma forma que contradiz aquela da sua for-
mação e experiência, os funcionários muitas vezes se apresentam muitas vezes resistentes
à mudança.
Para alguns tipos de trabalho, a coleta e reutilização de melhores práticas é uma tremenda
ajuda para o esforço de mudança. Por exemplo, uma organização que está vendendo um
produto para um novo tipo de cliente pode capturar as melhores práticas para superar
objeções por parte dos prospectos. Ao fazer a transição para Scrum, no entanto, a coleta
de melhores práticas pode ser arriscada, pois elas tentam fazer a equipe “relaxar e parar o
esforço de melhoria contínua”, que é essencial ao Scrum.
Embora os membros da equipe devam sempre pesquisar para compartilhar uns com os
outros as suas recém-descobertas acerca das melhores formas de trabalhar, eles devem
resistir ao impulso de codificá-las em um conjunto de melhores práticas.
Apesar de todas as razões pelas quais a transição para Scrum pode ser particularmente
difícil, partes interessadas nas organizações que a realizaram têm o tempo para o mercado
de seus produtos reduzido e se mostram satisfeitos depois de implementar um processo
ágil como Scrum.
Esse tempo de colocação no mercado mais rápido é possibilitado pela maior produtividade
das equipes ágeis, o que por sua vez é o resultado da maior qualidade de projetos nessa
disposição. Como os funcionários podem realizar trabalhos de alta qualidade e como eles
passam a ver o seu trabalho entregue mais cedo nas mãos dos usuários, a satisfação com o
trabalho sobe. Com maior satisfação dos funcionários, nota-se maior envolvimento, o que
leva a ganhos de produtividade, iniciando um ciclo virtuoso de melhoria contínua.
Podemos listar as seguintes razões porque uma transição para um processo ágil como q
Scrum é importante:
Nesse sentido, a QSMA calcula sua produtividade por meio de um sistema que considera q
esforço, cronograma, dificuldade técnica das atividades e alguns outros fatores em uma
tentativa de realizar comparações entre equipes mais significativas.
5
Em sua comparação entre projetos tradicionais e ágeis, Mah (2008) entende que projetos
ágeis são 16% mais produtivos em qualquer situação. A figura 1.1 mostra a comparação de
projetos ágeis (pontos) comparado com a produtividade média de o desvio padrão na base
de dados da QSMA.
Como se pode ver, a maioria dos pontos encontra-se acima da média da indústria, com q
uma boa parte dos projetos mais de um desvio padrão acima de um nível de produtivi-
dade dessa média.
Alto
+/- 1 Desvio padrão
Produtividade
Média
Figura 1.1
Equipes ágeis são
significativamente
Projetos ágeis
mais produtivos
Baixo que a média da
Menor Maior indústria.
Tamanho do projeto
Os resultados da QSMA são corroborados por outras pesquisas, tais como as da DDJ e
VersionOne. De acordo com a primeira, 82% dos participantes sentiram que a produtividade
foi um pouco ou muito mais elevada do que antes, quando se utiliza métodos ágeis como o
Scrum. De acordo com a VersionOne, 73% acreditava que ser ágil tinham significativamente
melhorado (23%) ou melhorado (50%) a produtividade.
Ora, é razoável entender que, se os funcionários em uma organização são mais produtivos,
os custos serão menores. Embora encorajadores, esses números contam apenas parte
da história. Uma das críticas dos processos tradicionais é que eles são tão onerosos. Que,
muitas vezes, quando o software é entregue, algumas funcionalidades – ou o aplicativo
inteiro – não são mais necessárias. Um benefício significativo de ser ágil é que equipes ágeis
possuem a tendência de produzir apenas funcionalidades necessárias. Graças ao feedback
constante e à habilidade de priorizar novamente a cada Sprint, uma equipe Scrum é capaz
de trabalhar apenas naquelas funcionalidades que os usuários realmente precisam. Se isso
for incluído no nosso requisito de produtividade, provavelmente veríamos resultados ainda
mais dramáticos.
De acordo com o levantamento de Rico, com base em estudos de caso de equipes ágeis q
publicados até 2016, mostrada na tabela 1.1, há um aumento médio de produtividade de
88% e economias de 26% de custos quando se transiciona para ágil. Esses indicam uma
evidência sólida de que equipes ágeis são mais produtivas, o que leva à redução de
custos para os seus projetos.
Fundamentos do Scrum
6
Exercício de fixação e
Como você entende que o Scrum pode melhorar a produtividade na
sua organização?
O envolvimento dos funcionários melhora também a satisfação no trabalho
Um fator que contribui para a maior produtividade e menores custos em projetos ágeis
é: os trabalhadores passam a gostar mais do que fazem. Quinze meses após a adoção do
Scrum, a Salesforce.com realizou uma pesquisa junto a seus funcionários e constatou que
Alto
Projetos ágeis
+/- 1 Desvio padrão
Time to market
Média
Uma das razões pelas quais as partes interessadas ficam mais satisfeitas com processos ágeis
é porque as suas práticas são mais amigáveis com relação às mudanças de prioridades, o que
é uma necessidade na vida das organizações de ritmo acelerado e competitivo de hoje.
7
Além disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as
partes interessadas em projetos ágeis aprendem a gerenciar o impacto da mudança. Outras
razões incluem a melhoria na visibilidade dos projetos, a melhoria do alinhamento da TI e
objetivos de negócio, e a redução de riscos de projeto.
q
Scrum, se mostrarem
interesse na transição.
Assim, ao adotar o Scrum, é interessante identificar continuamente os benefícios
Isso pode diminuir a
obtidos até determinado ponto, selecionar fatores de interesse da organização e fazer resistência da
com que tais fatores sejam uma linha de base contra a qual se possa comparar mais organização como um
todo.
tarde – uma boa dica é qualidade, moral da equipe e satisfação das partes interessadas.
Processo Scrum
Todas as práticas do Scrum estão cravadas em um esqueleto de processo incremental. q
Esse esqueleto é mostrado na figura 1.3. O círculo de baixo representa uma iteração de
atividades de desenvolvimento que ocorrem uma após a outra, e a saída de cada uma
delas é um incremento no produto. Já o círculo superior representa uma espécie de
inspeção diária que ocorre durante a iteração citada anteriormente, durante a qual cada
membro da equipe se reúne para acompanhar as atividades umas dos outros e realizar
adaptações adequadas. O que guia as interações são uma lista de requisitos e o ciclo se
repete enquanto houver orçamento disponível para o projeto.
Reunião de
24 h
Scrum Diária
2 – 4 semanas
q
Fundamentos do Scrum
11 Product Owner: o Product Owner deve ser a pessoa com visão, autoridade e dispo- q
nibilidade. O Product Owner é responsável por se comunicar continuamente com o
time de desenvolvimento sobre a visão do projeto e as prioridades.
Muitas vezes, é difícil para os Product Owners atingir o ponto ideal de envolvimento. Como
Scrum valoriza auto-organização entre equipes, um Product Owner deve lutar a necessi-
dade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponíveis para
responder questões da equipe;
11 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e q
para a equipe. O Scrum Master não gerencia a equipe. O Scrum Master trabalha para
remover quaisquer impedimentos ou barreiras que porventura venham atrapalhar a
equipe para atingir os objetivos da Sprint.
Isso ajuda a equipe a se manter criativa e produtiva ao mesmo tempo em que garante que seus
sucessos estão visíveis ao Product Owner. O Scrum Master também trabalha para auxiliar o
Product Owner em como maximizar o ROI (retorno sobre investimento) para a equipe;
Para projetos de software, uma equipe típica inclui uma mistura de engenheiros de sof-
tware, arquitetos, programadores, analistas, especialistas em qualidade, testadores e desig-
ners de interface gráfica. A cada Sprint, a equipe é responsável por determinar como vai
conseguir finalizar o trabalho. A equipe possui a autonomia e responsabilidade para atingir
os objetivos da Sprint.
Exercício de fixação e
Na sua organização, que papéis atuais poderiam ocupar os papéis do Scrum
em uma eventual transição para Scrum?
Capítulo 1 - Introdução
Fluxo do Scrum
Um projeto Scrum começa com uma visão do sistema a ser desenvolvido. A visão pode q
ser vaga no início, talvez expressa em termos de mercado, em vez de requisitos de
sistema, mas ela se tornará mais clara à medida que o projeto avança.
9
O Product Owner é responsável por garantir o financiamento do projeto e por entregar a q
visão de uma forma que maximiza o retorno do investimento. O Product Owner também
formula um plano para fazê-lo, que inclui um Product Backlog. O Product Backlog é uma
lista de requisitos funcionais e não funcionais que, quando transformado em funciona-
lidade, vai entregar essa visão. O Product Backlog é priorizado para que os itens com
maior probabilidade de gerar valor sejam prioridade e estejam divididos em lança-
mentos propostos.
Todo o trabalho é feito em Sprints. Cada Sprint é uma iteração de 30 ou 15 dias conse-
cutivos e é iniciada com uma reunião de planejamento, onde o proprietário do produto
e equipe se juntam para colaborar sobre o que será feito para a próxima Sprint. A ideia
é que o Product Owner selecione o item de mais alta prioridade no Product Backlog, e
que a equipe explique ao mesmo o quanto do que é desejado ela acredita que pode ser
transformado em funcionalidade ao longo da próxima Sprint. Reuniões de planejamento
da Sprint não podem ser muito demoradas, não devendo durar mais do que oito horas,
evitando muita angústia sobre o que é possível. O objetivo é começar a trabalhar, não
pensar em planejar o trabalho.
Todos os dias, a equipe se reúne para uma reunião de 15 minutos chamada Daily Scrum.
No final da Sprint, uma reunião de revisão da Sprint é realizada. Essa é uma reunião de
quatro horas em que a equipe apresenta o que foi desenvolvido durante a Sprint para o
Product Owner e quaisquer outros interessados que queiram participar. Trata-se de uma
reunião informal em que a funcionalidade é apresentada e destina-se a reunir as pessoas
e ajudá-los de forma colaborativa, determinando o que a equipe deve fazer a seguir.
10
A cada
24 horas
Scrum diário
Sprint
Nova funcionalidade
Backlog da Sprint demonstrada ao final
da Sprint
Artefatos
q
Figura 1.4
Visão geral do Scrum introduz alguns novos artefatos. Estes são utilizados em todo o processo de
processo do Scrum.
scrum e são descritos a seguir.
Product Backlog
Os requisitos para o sistema ou produto que está sendo desenvolvido pelo projeto estão q
listados no Product Backlog. O Product Owner é responsável pelo conteúdo, priorização
e a disponibilidade do Product Backlog. O Product Backlog nunca está completo,
finalizado, ou seja, o Product Backlog utilizado no plano de projeto é apenas uma
estimativa inicial das necessidades e evolui à medida que o produto e o ambiente em
que será usado evolui. Em outras palavras, o Product Backlog é dinâmico e a gestão
muda constantemente tal documento para identificar o que o produto necessita para
Tabela 1.2 que seja adequado, competitivo e útil. Enquanto o produto existir, o Product Backlog
Product Backlog. existe. Um exemplo pode ser encontrado na tabela 1.2:
Product Backlog
11
Sprint Backlog
O Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os q
itens do Product Backlog que ele escolheu para o Sprint), de maneira a transformá-lo em um
incremento de funcionalidade do produto potencialmente utilizável. Somente o time pode
mudar o Sprint Backlog. O Sprint Backlog deve ser altamente visível, e deve ser um quadro
que demonstra em tempo real o trabalho que a equipe planeja efetuar durante a Sprint.
Sprint Backlog
Responsável
Atividade
Origem
Status
1 2 3 4 5 6 7 8 9 10 11 12
q
Fundamentos do Scrum
Sprint Backlog.
Scrum exige que os times desenvolvam um incremento de funcionalidade do produto a
cada Sprint. Esse incremento deve ser potencialmente utilizável, porque o Product
Owner pode optar por implementar a funcionalidade imediatamente.
12
l Isso requer que os incrementos precisem ser exaustivamente testados e bem estruturados,
Essa é a definição
de um incremento que o código seja construído em um arquivo executável e que a funcionalidade implemen-
“pronto”. tada para operação do usuário seja escrita em um código bem documentado e disponibili-
zada em arquivos de ajuda ou em outra documentação de usuário acordada.
Visão Scrum
Scrum é uma ferramenta para desenvolver e manter produtos complexos. A ciência do q
Scrum está por trás do desenvolvimento de software complexo.
Obviamente tal fato não é muito surpreendente, porque o universo é cheio de complexi-
dades. A maioria delas são desconhecidas para a maioria das pessoas. Algumas – como
o processo através do qual a pressão transforma carvão em diamantes, por exemplo, é
irrelevante para a maioria das pessoas por ser natural e cuidar de si mesma. Outras, como o
deslocamento para o trabalho diariamente, podem tolerar alguma imprecisão.
Dessa forma, Scrum se propõe a ser visto como um quadro no qual as pessoas podem q
resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de
forma produtiva e fornecem, de maneira criativa, produtos de maior valor possível. Scrum é:
11 Leve (Lightweight);
11 Simples de entender;
11 Difícil de dominar.
Scrum é uma estrutura de processo que tem sido utilizada para gerenciar o desenvolvimento
de produtos complexos desde o início da década de 1990. Scrum não é um processo ou
uma técnica para a construção de produtos; ao contrário, é um quadro no qual você pode
empregar vários processos e técnicas.
Scrum torna clara a eficácia relativa das suas práticas de gestão e desenvolvimento de pro-
dutos para que você possa melhorar. O framework Scrum consiste em equipes Scrum e seus
papéis associados, eventos, artefatos e regras. Cada componente no quadro serve a um
propósito específico e é essencial para o sucesso e uso do Scrum.
As regras do Scrum unir os eventos, papéis e artefatos, que rege as relações e interações q
entre eles. As regras de Scrum são descritas ao longo desse documento. Táticas espe-
cíficas para o uso do framework Scrum variam. Scrum é fundada na teoria de controle
Capítulo 1 - Introdução
São três os pilares que sustentam qualquer implementação de controle de processos empí-
ricos: a transparência, a inspeção e a adaptação.
13
Transparência
Aspectos significativos do processo devem ser visíveis para os responsáveis pelo resul- q
tado. A transparência exige que esses aspectos sejam definidos por um padrão comum
de modo que observadores compartilhem um entendimento comum sobre o que está
sendo visto. Por exemplo:
11 Uma linguagem comum referindo-se ao processo deve ser partilhada por todos
os participantes;
Inspeção
Usuários de um projeto do Scrum devem frequentemente inspecionar artefatos pro- q
duzidos pelo projeto e progredir em direção a uma meta de uma Sprint para detectar
variações indesejáveis. Obviamente, a inspeção não deve ser tão frequente de maneira a
tornar a inspeção uma barreira ao trabalho.
As inspeções são mais benéficas quando a diligência é realizada por inspetores qualifi-
cados no trabalho.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo se desvia dos q
limites aceitáveis e que o produto resultante será inaceitável, o processo ou o material a
ser processado tem de ser ajustado. Um ajuste deve ser feito o mais rapidamente pos-
sível para impedir desvios futuros.
11 Planejamento da Sprint;
11 Scrum diária;
11 Revisão da Sprint.
11 Retrospectiva da Sprint
Scrum é parte do movimento ágil. Esse é uma resposta à falha da maioria dos para-
Fundamentos do Scrum
14
Extreme Programming, Desenvolvimento Orientado a Funções, Scrum e outros. Tipica-
mente, uma solução que possui definições simples como o Scrum habilita a equipe com a
autonomia necessária para realizar o melhor trabalho enquanto auxilia a alta gestão (cujos
membros podem se tornar Product Owner) a obter os resultados de negócio que desejam.
Scrum é capaz de abrir portas para outras abordagens ágeis úteis como desenvolvimento
orientado a testes. Uma organização realmente ágil dificilmente possui um lado “técnico” e
um lado “de negócios”, mas possui equipes trabalhando diretamente que desejam entregar
valor de negócios. Ora, os melhores resultados de negócios são entregues quando o negócio
inteiro está envolvido no processo.
Dessa forma, podemos ver Scrum como um conjunto simples de papéis, responsabilidades
e reuniões que nunca mudam. Ao remover toda imprevisibilidade não necessária, é possível
se adaptar à necessária imprevisibilidade da descoberta e aprendizagem típica dos projetos.
Assim, as regras e práticas para Scrum – um processo simples para gerenciar projetos
complexos – são poucas, diretas e fáceis de aprender. No entanto, a simplicidade do Scrum
em si e sua falta de prescrição podem ser tão sensibilizantes que novos praticantes acabam
em situações em que aos poucos revertem para velhos hábitos e ferramentas de gestão de
projetos, produzindo resultados menos satisfatórios.
Assim, para entender a base na teoria e prática do Scrum, é necessária uma mentalidade q
que possibilite:
11 Construir e lançar produtos em ciclos de 30 dias para que os clientes obtenham resul-
tados mais cedo;
Exercício de fixação e
O que você acha que precisa mudar na mentalidade da sua organização para
adotar um processo de gestão de projetos ágil como o Scrum?
15
Introduzindo um processo ágil em uma organização
O Manifesto Agil estabelece uma base comum para esses processos: valorizar mais q
os indivíduos e as interações que os processos e as ferramentas, trabalhar mais no
software do que no detalhamento da documentação, colaborar mais com o cliente na
negociação do contrato e responder mais rapidamente às mudanças do que seguir um
plano à risca. As metodologias ágeis mais conhecidas são Extreme Programming (XP),
Lean Development, Crystal e Scrum.
O Scrum é, portanto, ideal para projetos que possuem requisitos que ou mudam cons-
tantemente ou são desconhecidos no começo do projeto e que possuam a tendência de
surgir rapidamente, como projetos para web e para desenvolvimento de produtos em
novos mercados.
Desenvolvedores
A maioria dos desenvolvedores respondem à introdução de um processo ágil com uma q
combinação de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores,
no entanto, tendem a resistir à mudança ou simplesmente iniciar o projeto sem preme-
ditação. É importante ressaltar que ambas as reações podem causar problemas.
Em geral, processos ágeis valorizam mais a produção de código do que processos orientados
a planejamento. Em um processo assim, os desenvolvedores tratam a UML e outros itens
que não são código como artefatos de primeira classe. Em um processo ágil, no entanto,
esses itens só existem para suportar a atividade de codificação.
Em tais situações, o melhor é não intervir. Outros membros da equipe avaliarão a efetivi-
dade e o valor dessas atividades, e não as adotarão se estas não ajudarem o esforço de
desenvolvimento geral da equipe.
16
Programadores que têm essa visão percebem as interações com seus gerentes de projeto
como sendo sobre datas de entrega e prazos perdidos. Para impedir esse problema, os
líderes devem constantemente demonstrar seu desejo de remover obstáculos assim que
possível e evitar reclamar se uma atividade demorar mais do que o previsto. Gestores
podem se surpreender, mas não devem se mostrar excessivamente críticos ao serem infor-
mados de que uma tarefa vai demorar mais do que se pensava originalmente.
A transição gradual de um processo mais pesado para um processo ágil pode tornar a q
mudança mais fácil para a equipe de desenvolvimento. Algumas equipes, em seu pri-
meiro contato com o Scrum, ficam estagnados com a falta de ação gerada pela liberdade
de não possuir um cronograma diário direcionando seu trabalho. A ideia é ajudar esses
times ao definir tipos de sprint:
11 Prototipação;
11 Captura de requisitos;
11 Análise e design;
11 Implementação;
11 Estabilização.
Scrum Escalável
Quando muitas equipes trabalham no mesmo produto, eles normalmente usam um q
mesmo Product Owner (que realmente toma decisões de negócio) e um único Backlog
de Produto com requisitos orientados ao cliente. Cada equipe do Scrum deve buscar
se tornar uma equipe de funcionalidades, capaz de desenvolver uma fatia completa
de produto que pode ser entregue ao cliente. Quando interdependências aparecem,
equipes de funcionalidade devem aprender a usar princípios da auto-organização para
coordenar com outras equipes.
Infelizmente, a maioria dos times não estão inicialmente acostumados com esse nível de
responsabilidade, e hábitos pré-existentes de gestão e hierarquias apresentam impedi-
mentos organizacionais.
A ideia do Scrum é eliminar papéis de coordenação como gestor de projetos e PMO, pois q
entende que eles interferem na auto-organização da equipe. O Scrum também elimina
papéis ditatoriais como “arquitetos”, pois entende que as decisões técnicas devem ser
tomadas por times colaborativos.
enfraquecida do Scrum ao mesmo tempo em que se utiliza uma gestão hierárquica tradi-
cional. Recomenda-se que organizações maiores que estão comprometidas com valores
e princípios do Manifesto Ágil aprendam sobre LeSS (Large Scale Scrum).
17
Atividades práticas e
Cenário para escolha sobre um processo a ser adotado
Tutorial para uso de uma ferramenta Scrum (sugestão: Tuleap)
Fundamentos do Scrum
18
2
O Scrum
objetivos
conceitos
O Scrum. Metodologias de desenvolvimento de software. Filosofia do Scrum.
Processo de software
Em uma visão geral do processo/projeto de desenvolvimento de software, podemos q
subdividi-lo em cinco fases genéricas que independem da área de aplicação, tamanho ou
complexidade do projeto:
11 Especificação;
11 Projeto;
11 Implementação;
11 Validação;
11 Manutenção.
Para cada uma delas, existe uma série de atividades que são executadas.
O processo de software pode ser visto como um gerador de produtos, sendo o software
em si o produto final – no entanto, é importante perceber que existem subprodutos
gerados em cada fase. Por exemplo, no final da fase de especificação, é comum se pro-
duzir e entregar um ou mais documentos em que se detalham os requisitos do sistema.
A seguir, detalharemos um pouco essas fases e suas atividades associadas.
Fase de especificação
É uma das etapas iniciais do projeto, pois é onde procuram-se identificar funcionali- q
Capítulo 2 - O Scrum
Deve haver interação com o cliente para validar todas as informações por ele passadas e
com ele coletadas, a fim de que todos os requisitos sejam atendidos de maneira correta no
decorrer da implementação do produto.
19
É composta por três atividades principais, que são executadas, independentemente dos q
métodos utilizados, porém podem variar de acordo com o paradigma usado. As suas
tarefas são:
Fase de projeto
O projeto é finalizado quando seus objetivos propostos são alcançados e quando se q
encontra estruturado, em termos de arquitetura, interface e técnicas. Suas atividades são:
11 Projeto de interface: onde cada módulo tem sua interface de comunicação estudada e
definida. Pode resultar em um protótipo;
Fase de implementação
Também chamada de fase de desenvolvimento ou codificação. É a fase que define como q
os dados serão estruturados e implementados tecnicamente. Em outras palavras, é
quando o projeto, que antes estava documentado em papel, passa a ser transformado
para entrar em operação de fato. Linguagens de programação, técnicas e métodos – que
podem variar de projeto para projeto –, contudo, atividades comuns a todas metodolo-
gias precisam ser realizadas, tais como:
Fase de teste
Nesta fase, encontram-se as não conformidades com o que foi especificado durante a q
fase de especificação, com o objetivo de aumentar a qualidade do produto. Suas ativi-
dades são:
20
Fase de manutenção
Considerada a fase final, onde se analisa todo o produto. Tem como foco principal as q
modificações, como correções de erros, adaptações necessárias e melhorias (novas
funcionalidades não planejadas inicialmente) para evolução do software.
Nessa fase, o software em geral entra em um ciclo interativo que abrange as fases anteriores.
Como ocorrem alterações, a fase de manutenção abrange características das fases anteriores,
porém seu enfoque é um software já existente.
Assim, é impossível conceber um modelo uniforme que possa descrever com precisão o que
de fato acontece durante todas as fases de produção de um software – os procedimentos
utilizados são variados e as necessidades organizacionais diferem substancialmente.
O que se pode dizer é que todo modelo de software deve levar em consideração as fases q
descritas anteriormente; no entanto, cada organização organiza as fases do seu Modelo
de Processo de Software de acordo com sua filosofia.
21
De acordo com Sommerville, metodologia de desenvolvimento é o “conjunto de práticas q
recomendadas para o desenvolvimento de softwares, sendo que essas práticas geral-
mente passam por passos ou fases, que são subdivisões do processo para ordená-lo
e melhor gerenciá-lo”. As metodologias consideradas tradicionais, também chamadas
de “pesadas”, têm como característica marcante a sua divisão em etapas e fases bem
definidas, como Análise, Modelagem, Desenvolvimento e Testes. A conclusão de cada
fase gera um marco, que tipicamente refere-se um documento, protótipo do software ou
versão do sistema.
Vantagens e desvantagens
As vantagens principais das metodologias de desenvolvimento tradicionais são: redução q
de riscos envolvendo custos a um único incremento e aceleração do tempo de desenvol-
vimento do projeto como um todo, visto que os desenvolvedores trabalham de maneira
mais eficiente quando buscam resultados objetivos.
Quando se segue uma metodologia moderna como o Rational Unified Process (RUP), as
metodologias tradicionais incorporam uma série de outros benefícios, tais como:
desenvolvimento iterativamente;
22
11 Gerenciamento de riscos: a cada iteração, é possível analisar pontos críticos e pla- q
nejar estratégias para não perder tempo durante o desenvolvimento;
11 Testes: são realizados no fim de cada módulo, permitindo que erros e não conformi-
dades possam ser tratados ainda dentro do mesmo ciclo.
Exercício de fixação e
Que metodologias de desenvolvimento são utilizadas na sua organização?
Você enxerga vantagens e desvantagens no seu uso? Quais?
Arquitetura /
Projeto
Levantamento
Prototipação
Requisitos
Validação
Implantação
do cliente
Figura 2.1
Fases de uma
metodologia Testes Desenvolvimento
tradicional.
Capítulo 2 - O Scrum
23
O novo advento ágil iniciou com alguns especialistas da indústria do desenvolvimento de q
software, que se uniram para encontrar valores e princípios relacionados ao desenvolvi-
mento, que escreveram o Manifesto Ágil. Esse manifesto destacava quatro valores:
Documentações e papéis não contam como entregas, pois não satisfazem a necessidade do
cliente. O cliente escolhe se vai implantar o sistema incompleto, se vai apenas testá-lo para
definir novas funcionalidades ou se vai apenas testá-lo para encontrar não conformidades
com aquilo que deseja.
24
Indivíduos e iterações em vez de somente processos e ferramentas
A experiência e capacitação dos profissionais no desenvolvimento do projeto afetam q
diretamente na qualidade do produto e no bom desempenho da equipe do projeto. Ter
excelentes profissionais, no entanto, não é uma garantia de sucesso, pois eles dependem
diretamente do processo.
Além da combinação do processo adequado com bons profissionais, é preciso que toda q
a equipe possa interagir perfeitamente entre si. Comunicação é mais importante que
simples talento para programação. Um desenvolvedor que consegue se relacionar bem
e trabalha bem em equipe tipicamente é mais produtivo que um excelente programador
que só consegue trabalhar sozinho. Comunicação é o principal valor dos Processos Ágeis
e é a maneira mais rápida de se obter informações.
Além disso, as responsabilidades e decisões são compartilhadas por toda a equipe, mos-
trando que todos estão envolvidos no processo e trabalhando em grupo. Assim, para a
seleção dos funcionários envolvidos, deve-se levar em consideração o perfil, a competência,
o comportamento individual e em equipe, e o profissional deve ser comunicativo. Obviamente,
uma organização em transição deve ser capaz de treinar os seus profissionais – no entanto,
é fundamental que todos estejam motivados, seja com o apoio de outros membros da
equipe ou com o material e equipamento.
Outra característica é a iteração. Após cada iteração, deve ser possível apresentar um pro-
tótipo para o cliente e coletar o seu retorno. Como já dito anteriormente, nas metodologias
ágeis, é criada uma lista de prioridades de funcionalidades de acordo com o que o cliente
julga como prioritário para ele. Tal lista é atualizada constantemente a cada iteração, permi-
tindo acrescentar novos requisitos e mudanças, ajustando as prioridades. Dessa maneira,
o gerente de projeto pode garantir que a equipe de desenvolvimento esteja trabalhando de
acordo com os aspectos que o cliente considera mais significativo.
25
Acerca da existência de planos, o Manifesto Ágil não é contra. Ele defende que planos sejam
esboçados, mas que, como não é possível prever o futuro, as visões desses não devem ir
muito longe.
O planejamento, portanto, deve ser de curto prazo, em virtude das alterações que q
invariavelmente vão aparecer. Na verdade, é muito difícil seguir planos de longo prazo
à risca, então faz pouco sentido concentrar muito esforço nisso. Uma dica importante
quando se identifica que o projeto será muito extenso é dividi-lo em fases, tornando
mais fácil gerenciá-lo e executá-lo.
Velocidade e qualidade
Ora, para garantir um desenvolvimento rápido, é necessário um software limpo e mais q
robusto possível. Isso porque as equipes de projetos ágeis são orientadas a desenvolver
códigos com qualidade.
Assim, o que deve ser mantido nos Processos Ageis é a velocidade do desenvolvimento.
De nada adianta iniciar um projeto desenvolvendo-o rapidamente se essa velocidade
declinar com o tempo, pois isso pode iludir o cliente, causando a ele uma impressão de falsa
velocidade, além de estressar os desenvolvedores e diminuir a qualidade final do produto,
quebrando os principais valores dos Processos Ágeis.
Vantagens e desvantagens
As vantagens da Metodologia de Desenvolvimento Ágil são: q
11 Receptividade às mudanças;
11 Versões úteis;
11 Uma versão poderá ser entregue ao cliente em um tempo menor do que uma versão
desenvolvida com a metodologia pesada;
No entanto, a grande limitação das metodologias ágeis é a maneira como elas manipulam
Fundamentos do Scrum
26
Como a prioridade máxima das metodologias ágeis é satisfazer o cliente, fornecendo o mais q
rapidamente possível e continuamente novas funcionalidades para o seu software, em
grandes sistemas essa filosofia pode resultar em retrabalho por falta de escala em sua arqui-
tetura. Tradicionalmente, os objetos da metodologia pesada como previsibilidade, repetição
e otimização são características de um desenvolvimento seguro. Portanto, seria displicente a
aplicação da modelagem ágil em sistemas críticos de manutenção vital, por exemplo.
Exercício de fixação e
Você acredita que a sua organização e os seus clientes se beneficiariam da
adoção de uma metodologia como o Scrum?
Histórico do Scrum
O Scrum foi a princípio concebido como um estilo de gerenciamento de projetos em q
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka,
no artigo “The New Product Development Game” (Harvard Business Review, janeiro-feve-
reiro 1986). Nesse artigo, eles comparavam equipes de alto desempenho e multifuncionais
com um jogo de rugby e concluíram que equipes são formadas de menores e equipes tra-
balhando com sucesso em direção a um objetivo comum. Os autores notaram que projetos
usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores
resultados, e associaram essas equipes altamente eficazes à formação Scrum do Rugby (utili-
zada para reinício do jogo em certos casos).
Apesar de a metodologia ter sido iniciada pelos autores supracitados, no ano de 1995, a
documentação da metodologia foi publicada por Ken Schwaber com a ajuda de Jeff, que se
empenharam para sintetizar o que tinham aprendido através dos anos e criaram uma nova
metodologia, a qual chamaram de Scrum. Em 1995, Ken Schwaber formalizou a definição de
O primeiro artigo
d Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.
O objetivo de Ken Schwaber durante todo esse período era auxiliar sua empresa, a Advanced
sobre o tema foi
“Scrum and the Perfect Development Methods, Inc. a aprimorar seu processo de desenvolvimento de software
Storm”, publicado na com o objetivo de melhorar a produtividade de sua equipe. Após uma extensa análise
revista OOPSLA pela
de como fornecedores de softwares bem-sucedidos e independentes produziram seus
Object Management
Group (OMG). produtos, ele concluiu que os processos de desenvolvimento desses fornecedores
eram bastante análogos, os quais requeriam constantes verificações e adequações.
Como a maioria dos termos do Scrum estão presentes nos processos da Toyota, essa
empresa, sem intenção, acabou contribuindo para o desenvolvimento da metodologia.
A própria missão da organização reflete um dos valores principais do Scrum: “Contribuir
com o crescimento da economia das comunidades dos Estados Unidos e para estabilidade e
bem-estar dos membros da equipe.” O ponto principal parece ser trazer benefícios para as
pessoas, uma proposta distinta da maioria das empresas americanas.
27
Conforme já explicamos anteriormente, o foco do Scrum está nas pessoas. A metodologia
trabalha para melhorar a vida de todos os envolvidos no projeto – principalmente os desen-
volvedores de software. Um segundo foco é adicionar valor aos clientes, já que o Scrum é
um processo de adição de valor, com foco no cliente.
Normalmente, tem-se uma tendência em abrir mão da variável custo para obter qua- q
lidade, ou abrir mão da qualidade para se obter o objetivo do projeto em um tempo
menor. É isso que se chama de restrição tripla de projetos, composto pelas pontas:
“custo, qualidade e prazos”, conforme mostrado na figura 2.2. Essa decisão ainda é um
paradigma forte nas principais e na mente dos desenvolvedores: a tendência de desprio-
rizar um vértice para conseguir otimizar o outro.
Qualidade
Figura 2.2
Restrição tripla em
Custo Prazo
projetos.
Porém, a filosofia da Toyota vai de encontro a isso. A empresa trabalhou para quebrar q
a restrição tripla como um triângulo de ferro e uniu todas essas pontas, buscando
qualidade, entrega rápida, variedade de produtos e preço baixo. É nesse sentido que a
Toyota e o Scrum caminham juntos – o sistema da Toyota é baseado na quebra da res-
trição tripla, buscando maximizar todas as variáveis da restrição tripla ao mesmo tempo,
reduzindo custos, tempo e barreiras funcionais através de um processo interativo que
inspeciona, junto com o cliente, cada passo do processo, para alcançar um resultado
final com qualidade.
Exercício de fixação e
Como eliminar a restrição tripla na sua organização?
Enfrentar e alinhar a gestão e o controle da estrutura do cliente são as partes mais q
difíceis do Scrum. A equipe deve ser auto-organizada, e isso é mais fácil de conseguir
em organizações emergentes, pois estas têm uma facilidade maior de se auto-organizar
através da ação local. Caso se pare para reparar as pessoas na linha de frente, geral-
mente são as que estão no campo, e, portanto, detêm mais conhecimento do negócio.
Fundamentos do Scrum
Na Toyota, isso ocorre entre vendedores de carros ou nas linhas de montagem. É lá que
as coisas acontecem e surgem, e assim permitem a distribuição do conhecimento e das
ações para desenvolver os projetos. Da mesma forma, no contexto do Scrum, a equipe deve
ser formada de maneira a permitir que se auto-organize também. E esse é o segredo do
Scrum. Um projeto que utiliza a metodologia tem de ser capaz de formar um time que se
auto-organize.
28
Takeuchi e Nonaka argumentam que há alguns sinais que podem ser identificados para q
dizer se uma equipe está se auto-organizando:
22 A equipe é independente?
2. Verifique se há senso comum, ou seja, se cada membro da equipe está com foco no
sucesso da equipe, ao invés do seu próprio avanço pessoal na empresa. Caso isso
não ocorra, a equipe não se auto-organizará.
Exercício de fixação e
Você acredita ser possível ter uma equipe auto-organizável na sua organização?
Qual o contexto para possibilitar tal auto-organização?
Em alguns casos, o trabalho de remover a gestão é árduo – no entanto, tornar os partici- q
pantes independentes e com liberdade colabora para que o projeto tenha um resultado
de sucesso.
Mesmo sendo o engenheiro o mais experiente do grupo, ele precisava deixar que o projeto
se desenvolvesse a partir daquela equipe diversificada – uma característica típica do Scrum.
No Scrum, todos são parte do processo, a equipe tem uma estrutura vertical e, portanto,
todos estão no mesmo patamar, trabalhando juntos: gerentes, clientes, pessoal da insta-
lação, suporte, entre outros.
Origem do nome
O nome Scrum foi inspirado em uma jogada do Rugby – a figura 2.3 mostra como é um q
Scrum no Rugby. Essa analogia feita entre uma jogada de Rugby e o Scrum tem dois fun-
Capítulo 2 - O Scrum
29
Senso de equipe Figura 2.3
q
Exemplo de Scrum.
O Scrum no Rugby consiste em uma equipe de oito jogadores abraçados, que realizam
uma força, onde o objetivo é empurrar o outro time. Essa jogada só é eficaz quando
todos os jogadores fazem força ao mesmo tempo e na mesma direção, fazendo com que
a soma das forças individuais sejam maiores que as do time adversário, e consigam
assim pegar a bola.
Essa corrida em estilo holístico, onde a equipe busca, como em um jogo de Rugby,
de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais
necessidades competitivas.
Reuniões constantes
No jogo de Rugby, os jogadores se organizam em círculo para planejar a próxima jogada. q
É uma forma de mostrar que o projeto deve ser conduzido em pequenos círculos, mas
com uma visão de longo prazo, que é ganhar o jogo. O mesmo ocorre na metodologia
Scrum: cada interação é uma forma de recomeçar a partida reunindo todos os jogadores
após um incidente ou quando a bola sair de campo. A ideia básica é reunir os desenvol-
Fundamentos do Scrum
30
O processo
Ken Schawber defende que Scrum não é uma metodologia em si, mas um framework. q
Scrum não vai dizer exatamente o que fazer, mas dar um conjunto de diretrizes que
podem ser seguidas e adaptadas para uma realidade específica do projeto.
Para Martins, “Scrum é um processo bastante leve para gerenciar e controlar projetos de
desenvolvimento de software e para criação de projetos de produtos. O Scrum segue a filo-
sofia iterativa e incremental, se concentrando no que é realmente importante: gerenciar o
projeto e criar um produto que acrescenta valor para o negócio. O valor decorre da funcio-
nalidade propriamente dita, do prazo em que ela é necessária, do custo e da qualidade”.
Empírico
Segundo Cruz, existem dois tipos de processos: definidos e empíricos. Processos defi- q
nidos determinam o que deve ser feito, quando e como. Para um mesmo conjunto de
variáveis de entrada, podemos esperar o mesmo resultado sempre. Um exemplo bem
conhecido de processo definido é a metodologia RUP. De acordo com Highsmith (2004),
um processo de desenvolvimento de software extremamente bem definido tem uma
probabilidade de sucesso drasticamente reduzida quando utilizado no desenvolvimento
de um produto.
O Scrum utiliza uma implantação de um controle descentralizado que lida de forma efi-
ciente com situações menos previsíveis, o que aparece como uma possível solução para
atacar esse problema.
Nesse sentido, os processos empíricos devem ser utilizados sempre que os processos
definidos não forem adequados devido à complexidade do projeto, ou seja, sempre que não
Capítulo 2 - O Scrum
se conheçam todas as variáveis de entrada para que se possa estabelecer um processo que
pode ser repetido(com a mesma saída sempre), o Scrum é um exemplo deste.
Iterativo e incremental
Em virtude da complexidade, tamanho, mudanças de requisitos, urgência e necessidade q
de demonstrar valor mais rápido para o cliente, fica quase inconcebível desenvolver
software utilizando o modelo cascata, ou seja, desenvolver software de uma única vez.
A metodologia considera um modelo iterativo e incremental por uma questão de estra-
tégia de planejamento. O modelo segue uma filosofia: dividir para conquistar, onde o
projeto é divido em blocos, em ciclos, onde a cada iteração é feito um novo incremento
(parte do software funcional) até completar o software.
Plano de iteração
Figura 2.4
Incremental
e iterativo –
diferenças.
Fases do Scrum
Basicamente, a metodologia Scrum é dividida em três fases simples, que se repetem a q
cada ciclo: planejamento, desenvolvimento e encerramento.
Fundamentos do Scrum
22 Teste unitário;
22 Teste integrado;
22 Treinamento.
Tamanho de projetos
Scrum é uma metodologia que se aplica a projetos de qualquer tamanho, realizando uma
avaliação correta do ambiente em evolução. Adapta constantemente o “caos” de interesses
e necessidades, e é indicado e utilizado para o desenvolvimento de software em ambientes
complexos, onde os requisitos mudam com certa frequência, sendo o caminho utilizado
para aumentar a produtividade nesses tipos de sistemas.
Atividades práticas e
Cenários para levantamento de requisitos
A partir de requisitos, escrever User stories. Cenários (Sprint previamente finalizada)
para cálculo de Burndown a partir do Tuleap. Cenários (idem) para cálculo de Velocidade.
É importante o instrutor explicar a diferença e importância dessas métricas.
Capítulo 2 - O Scrum
33
34
Fundamentos do Scrum
3
A metodologia
objetivos
conceitos
Scrum Master, Product Owner; Daily Scrums, Reuniões de Planejamento e Reuniões
de Revisão; Product Backlog, Sprint Backlog e Gráfico de Burndown
11 Papéis:
22 Scrum Master;
22 Equipe de Desenvolvimento;
22 Cliente.
11 Cerimônias:
11 Artefatos:
22 Planning Poker;
22 Sprint;
Capítulo 3 - A metodologia
22 Product Backlog;
22 Sprint Backlog;
22 Burndown Chart.
35
Papéis
Como já mencionado anteriormente, a metodologia define como a equipe deve trabalhar. q
O primeiro passo para o desenvolvimento baseado no Scrum é definir quem vai fazer o
quê. A metodologia define dois tipos de papéis básicos:
11 Principais;
11 Auxiliares.
Papéis principais são os profissionais que fazem parte da equipe do fornecedor – ou seja,
são aquelas pessoas comprometidas com o projeto no processo do Scrum. Produzem o
produto em si, o objetivo final do projeto.
Já os papéis auxiliares são aqueles sem papel formal e nenhum envolvimento frequente
no processo Scrum, mas que ainda precisam ser levados em conta.
Product Owner
Podemos dizer que o Product Owner é um analista de negócio e um profissional com q
conhecimento nas duas pontas: no negócio do cliente e na tecnologia. Tem como
principal objetivo representar os interesses do cliente com a equipe técnica. Funciona,
l
portanto, como uma interface entre o cliente e a equipe de desenvolvedores, e deve
estar sempre em contato com o cliente para saber o que precisa ser feito no projeto para
satisfazer o negócio. Veremos esse termo
em detalhes no tópico
Juntamente com os outros envolvidos, ele é o responsável por listar as prioridades e os de Artefatos.
requisitos, além de revisar e aprovar as entregar no final de cada Sprint.
Scrum Master
É o líder da equipe de desenvolvimento, geralmente o programador ou analista de sistemas q
mais experiente da equipe. É responsável por garantir a aplicação das práticas do Scrum,
assim como repassar os ensinamentos da metodologia para os outros membros do
projeto. Gerencia e delega as atividades que foram definidas durante o planejamento
pelo Product Owner.
11 Revisar atividades, tendo conhecimento das que foram concluídas e das que
foram iniciadas;
36
11 Identificar novas tarefas, priorizá-las e alterar qualquer estimativa que possa ter q
mudado. Isso permite a ele atualizar sempre o Burndown Chart (veremos esse termo
em detalhes no tópico de Artefatos);
11 Tomar ações para tarefas em aberto e computar quantas tarefas estão em aberto com
o objetivo de minimizá-las o máximo possível para garantir um trabalho eficiente;
Equipe de desenvolvimento
Também conhecida como Scrum Team, correspondem aos membros encarregados por q
realizar as atividades de projeto. Ou seja, são aqueles que vão efetivamente colocar a
mão na massa para que o projeto se concretize.
Suas principais atividades são organizar e gerenciar suas próprias atividades. e geral-
mente estão integralmente dedicados ao projeto. Dependendo da complexidade do sof-
tware, um projeto pode ter mais do que uma equipe de desenvolvimento. No entanto, a
troca de equipe só deve ocorrer na mudança de ciclo.
11 Multifuncional e auto-organizável;
11 Definem metas a cada Sprint, junto com o Scrum Master, e especificam seus resul-
tados de trabalho;
Como já falamos, por ser multifuncional, a equipe de desenvolvimento Scrum deve ser
Capítulo 3 - A metodologia
composta por profissionais dos mais variados perfis, incluindo, mas não se limitando a:
11 Programadores;
11 Testadores;
11 Analistas;
11 Desenvolvedores de interfaces;
37
Na prática, a diferença entre uma equipe não multifuncional é que na primeira, como q
podemos visualizar na figura 3.1, o projeto anda mais rápido, pois profissionais de dife-
rentes especialidades trabalham juntos para cumprir uma tarefa. O sentido de equipe é
exatamente esse – os membros compensam entre si as competências e as carências, em
um aprendizado mútuo e contínuo.
Time Multifuncional
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Figura 3.1
Código Código Código Diferença de
velocidade entre
equipes não
Testa Testa Testa multifuncionais e
multifuncionais.
Cerimônias
A equipe também tem a responsabilidade de participar das cerimônias. Essas são q
reuniões que ocorrem em diversos momentos durante o projeto. O método é dividido
sucintamente em basicamente três cerimônias principais, a saber:
Esses três tipos de evento caracterizam bem o ciclo de vida de cada Sprint, que possui
início, meio e fim.
11 Scrum Master;
11 Equipe de desenvolvimento.
38
Também chamada de Scrum Planning Meeting, a reunião de planejamento é a primeira q
reunião do projeto, e seu objetivo é realizar o planejamento da Sprint, definindo escopo,
estimativa e importância.
Segundo Cockburn (2001), essa reunião é crítica para o sucesso do projeto, pois se não for
devidamente planejada e bem realizada, pode ocasionar problemas com atrasos, estimativas
mal realizadas e outros problemas típicos.
Na segunda etapa, o Scrum Master trabalha junto com o Product Owner e a Equipe de
Desenvolvimento para determinar como as tarefas devem ser executadas e o tempo
que cada funcionalidade do Product Backlog demandará para ser concluída. Isso ajuda o
Product Owner a definir prazos reais para o projeto e permite acompanhar o andamento
do projeto durante todo o período de desenvolvimento.
Assim, a reunião de planejamento da Sprint tem duas partes. As primeiras quatro horas
são gastas com o Product Owner apresentando a maior prioridade do Product Backlog
para a equipe, incluindo questionamentos da equipe sobre o conteúdo, propósito, signi-
ficado e as intenções do Product Backlog. Quando a equipe sabe o suficiente, mas dentro
dessas primeiras quatro horas, a equipe seleciona tanto do Product Backlog quanto
acredita que pode se transformar em um incremento completo de funcionalidade do
produto potencialmente utilizável até o final do Sprint.
Essa reunião dura até 8 horas, e é ela que define o Sprint Backlog. Para validar se todos
os pontos que devem ser abordados em reunião foram concluídos, é interessante fazer
um checklist da reunião respondendo às seguintes questões:
39
11 Os itens do Product Backlog que serão entregues na próxima Sprint foram selecionados? q
11 Os níveis de prioridade dos itens do Product Backlog foram definidos?
11 A meta da Sprint (ou seja, o que deve ser entregue) foi estabelecida?
Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsáveis
e prazos, o processo de desenvolvimento começa.
11 Equipe de desenvolvimento.
11 Têm uma duração de no máximo 15 minutos, para evitar perder o foco do que está
sendo desenvolvido e divergências de assuntos.
A reunião diária de Scrum é uma maneira eficiente de manter os membros cientes dos
objetivos e forçar que os profissionais não percam o foco. Elas não representam uma
forma de cobrança vinda de um gerente de projetos, mas uma maneira de sincronizar a
equipe às tarefas e relatar os impedimentos que possam estar interferindo no anda-
mento da Sprint. Uma reunião diária de Scrum típica pode ser encontrada na figura 3.2.
Fundamentos do Scrum
Figura 3.2
Reunião diária de
Scrum
(Daily Scrum).
40
Na Daily Scrum, cada membro da equipe responde a três perguntas: q
11 O que você fez nesse projeto desde a última reunião diária do Scrum?
11 O que você planeja fazer nesse projeto entre agora e a próxima reunião diária do Scrum?
Como se pode imaginar, o Scrum Master tem um papel muito importante nessas
reuniões, pois é o responsável por identificar todos os problemas ou novas tarefas que
surgirem e replanejar o plano da Sprint atual, remanejando o Task Board e o gráfico de
Burndown, artefatos que estudaremos na próxima sessão.
11 Product Owner;
11 Equipe de Desenvolvimento;
11 Scrum Master;
Segundo Martins (2006), a reunião de revisão da Sprint é uma reunião informal de quatro
horas de duração, na qual a equipe de desenvolvimento, juntamente do Scrum Master, se
reúne com o Product Owner e convidados para apresentar o resultado da Sprint – ou seja,
tudo o que foi desenvolvido durante o ciclo de desenvolvimento da Sprint atual.
Depois que essa reunião é finalizada, uma nova Sprint pode começar até que todo o q
Capítulo 3 - A metodologia
41
11 Quais foram os pontos fracos e fortes da equipe durante o Sprint? q
11 Alguém teve alguma dificuldade?
Dica: para a primeira retrospectiva da Sprint, todos na equipe scrum precisam considerar as
três perguntas antes da reunião iniciar. Assim, é bom o Scrum Master enviar as perguntas
antecipadamente, para que todos na equipe de Scrum façam algumas notas de antemão
ou até mesmo tomem notas durante toda a Sprint. Uma boa estratégia é anotar os impe-
dimentos encontrados durante as reuniões diárias e tentar encontrar possíveis pontos de
melhoria a partir destes. A partir da segunda reunião de retrospectiva da Sprint, podemos
comparar a Sprint atual com anteriores.
Fundamentos do Scrum
42
11 Pessoas: discuta o alinhamento e a composição da equipe; q
11 Relacionamentos: discuta sobre comunicação, colaboração e trabalho em pares;
Para algumas equipes Scrum, pode ser difícil se abrir no início. O Scrum Master pode precisar
fazer perguntas específicas para iniciar discussões. Participar em retrospectivas requer
prática. O que importa é para incentivar a equipe Scrum a assumir a responsabilidade: para
realmente abraçar a característica de autogestão.
A retrospectiva da Sprint é uma das melhores oportunidades que a equipe Scrum tem de
colocar as ideias de inspeção e adaptação em ação. É importante que a equipe possua a
capacidade de identificar desafios e soluções durante a retrospectiva e não deixe essas
soluções para após a reunião. Assim, a reunião de retrospectiva é ser orientada a ações, tais
como inspeção e adaptação da equipe, que podem ser gravados, inclusive, informalmente:
o importante é garantir visibilidade de ações sobre os itens listados após a reunião.
Artefatos
Os artefatos do Scrum são as ferramentas básicas para se trabalhar com esse modelo q
de desenvolvimento. Esses artefatos servem como guias e indicadores para suportar o
processo e são divididos em seis. Podemos citar:
11 Planning Poker;
11 Sprint;
l 11 Product Backlog;
Nesta sessão, 11 Sprint Backlog;
estudaremos cada um
deles em detalhes. 11 Burndown Chart.
43
Uma dica para escrever uma boa história é conversar sobre ela, entre os desenvolvedores e os
clientes, de forma a detalhar os itens e esclarecer todas as dúvidas sobre o que deve ser feito.
Antes de se reunir com o cliente, o proprietário do produto e a equipe de desenvolvimento devem
preparar um questionário com perguntas que auxiliam o cliente a lembrar de fatos que podem
passar despercebidos, mas que podem ter sido importantes para o desenvolvimento do produto.
Seria difícil dar início ao desenvolvimento baseado apenas nesse pequeno texto.
Baseado nesse exemplo, seguem os tipos de questões que a equipe pode aplicar para
extrair mais informações úteis para o projeto:
É comum que os detalhes sejam expressos em histórias futuras. É melhor ter muitas histó-
rias menores do que ter poucas histórias grandes. É também importante lembrarmos que a
comunicação “cara a cara” é um dos princípios da filosofia ágil e, por isso, em vez de escrever
todos os detalhes na user story, o melhor a fazer é reunir a equipe de desenvolvimento e o
cliente e garantir uma discussão sobre os detalhes, já definindo as funcionalidades.
22 Consultar cliente.
11 Manter serviço:
22 Cadastrar serviço;
22 Excluir serviço;
22 Consultar serviço.
11 Manter orçamento:
Fundamentos do Scrum
22 Criar orçamento;
22 Calcular orçamento;
22 Enviar orçamento;
22 Excluir orçamento;
22 Consultar orçamento;
22 Autorizar orçamento.
44
É interessante que o proprietário do produto faça uma espécie de estágio no cliente para
vivenciar a atividade no negócio e assim consiga ser mais sensível às necessidades.
Um princípio-chave no Scrum é o reconhecimento de que, durante um projeto, os clientes
podem mudar de ideia sobre o que eles querem e precisam (muitas vezes, chamados de
“requirements churn” – do inglês “requisitos agitados”), e que os desafios imprevisíveis não
podem ser facilmente tratados de uma maneira preditiva ou planejada. Como tal, o Scrum
adota uma abordagem empírica, aceitando que o problema não pode ser totalmente enten-
dido ou definido, focando na maximização da habilidade da equipe para entregar rapida-
mente e responder as necessidades emergentes.
As user stories devem ser compreensíveis por todos os envolvidos: usuários, cliente q
e equipe de desenvolvimento. Portanto, existem alguns critérios importantes com os
quais se preocupar quando se descreve histórias de usuário. Elas precisam ser:
11 Negociáveis: uma user story não é um processo jurídico e, portanto, não necessita
ter excesso de informações. A ausência dessas informações estimulará que a equipe
esteja sempre negociando os detalhes em futuras conversas com o cliente;
11 Pequena: uma user story deve ser pequena o suficiente para que possa ser imple-
mentada e implantada, mas grande o suficiente para traga valor para o negócio;
11 Testável: as user stories precisam ser testáveis; caso contrário, não será possível a
equipe saber se o desenvolvimento foi validado ou não.
Planning Poker
O Planning Poker é basicamente a atribuição de pontos às user stories. É uma prática q
que ajuda na estimativa de uma história ou de uma tarefa. Tais pontos representam um
grau de dificuldade de uma funcionalidade perante o projeto.
Planning Poker no Scrum reúne várias opiniões de especialistas para a estimativa ágil de
um projeto. Nesse tipo de planejamento, que deve incluir todos, desde programadores,
testadores e engenheiros de banco de dados com analistas e designers de interação
do usuário. Como esses membros da equipe representam todas as disciplinas de um
projeto de software, eles são adequados para a tarefa de estimativa.
Em segundo lugar, devem-se definir valores de referências. Como, por exemplo: identificar
Capítulo 3 - A metodologia
uma user story à qual pode ser atribuída o menor valor (10 pontos), outra que representa
um valor mediano (50 pontas) e outra à qual representa o valor máximo (130 pontos). Dessa
forma, essas histórias serão utilizadas como referências para pontuação de demais user
stories que apareçam durante o processo de estimativa nas reuniões de planejamento.
45
No início do exercício de planejamento ágil, a cada estimador é dado um baralho de q
cartões de Planning Poker. Cada cartão tem uma das estimativas válidas sobre ela,
como as recém-descritas. Para cada história de usuário ou tema a ser estimado, um
moderador (geralmente o Product Owner ou o Scrum Master) lê a descrição. Haverá
alguma discussão, onde o moderador responde a quaisquer perguntas dos avaliadores.
Mas o objetivo de Planning Poker no Scrum não é para derivar uma estimativa de que vai
resistir a qualquer controle futuro. Em vez disso, a ideia é obter uma estimativa valiosa
que pode ser alcançada de forma barata.
Após a discussão, uma nova rodada de estimativa deve acontecer e uma nova seleção
de cartão pode ocorrer. Muitas vezes, as estimativas vão convergir na segunda rodada.
Senão, repita o processo até que a equipe concorde com uma única estimativa a ser
usada para a user story. Raramente será necessário mais do que três rodadas de discus-
sões na estimativa para se alcançar a meta Sprint.
Por outro lado, o desenvolvimento iterativo é o que Cockburn refere-se como um “retra-
balho estratégia de programação”. Um processo de desenvolvimento iterativo reconhece a
impossibilidade – ou, pelo menos, improbabilidade – de se conseguir acertar o desenvolvi-
Fundamentos do Scrum
46
Assim, em um processo incremental, desenvolvemos totalmente uma funcionalidade e, em
seguida, segue-se para a próxima. Em um processo iterativo, se constrói todo o sistema, mas
isso é feito de forma imperfeita em primeiro lugar, usando passos subsequentes através
de todo o sistema para melhoria. As fraquezas inerentes de ser apenas iterativo ou apenas
incrementais desaparecem quando eles são combinados, e essa é a forma como eles estão
dispostos em Scrum.
Ao final da Sprint, a equipe do projeto deverá produzir uma entrega de valor para o cliente –
que se trata de um software funcional. A entrega de valor é, portanto, a meta da Sprint, que
deverá estar bem definida e combinada com o cliente antes do começo de sua execução.
Durante cada Sprint, a equipe cria um incremento de produto “entregável”, ou seja, as
funcionalidades testadas e prontas para uso. O conjunto de funcionalidades que entram em
uma Sprint vem do Product Backlog.
Um software funcional é aquele que está potencialmente completo e pronto para uso.
Aprender como entregar um software dessa natureza é um dos maiores desafios que uma
equipe nova nos processos Scrum pode passar. No entanto, isso é fundamental para se
tornar ágil. Na verdade, é tão importante que um dos quatro valores indicados no Manifesto
Ágil afirma que se valoriza “software funcional mais que documentação abrangente” (Beck
et al., 2001).
11 Software funcional auxilia a equipe avaliar seu processo: um dos maiores riscos
em um projeto não é saber o quanto ainda resta a ser feito. Quando se permite
muito de um sistema em estado inacabado, é extremamente difícil saber o quanto de
esforço ainda resta para trazer o sistema para um estado potencialmente de entrega;
Regras da Sprint:
47
Entregue algo de valor a cada Sprint
Mesmo que se certificar que no fim de cada Sprint haja um software funcional não seja q
um desafio muito grande, as equipes Scrum também devem entregar algo valioso para
os usuários ou clientes ao fim de cada Sprint em termos de sistema. A definição do que
é valioso para usuários ou clientes pode ser estipulado muito facilmente e de forma
quase maliciosa.
Por exemplo, uma equipe pode argumentar que atualizar os desktops dos desen-
volvedores para a versão mais recente de seu Sistema Operacional preferido lhes
permite desenvolver mais rapidamente para que os novos recursos se tornem dispo-
nível aos clientes de maneira mais eficientemente. Embora isso possa muito bem ser
verdade, a intenção é que, a cada Sprint, se deve entregar algo de valor imediato para
os usuários ou clientes que eles possam enxergar.
Já sabemos que uma equipe não deve puxar uma user story ou outro item do Product
Backlog em uma Sprint se é claramente muito grande para ser concluído. Uma história de
usuário épica que levará meses para completar deve ser decomposta em pedaços menores,
de modo que cada uma possa ser concluída dentro de uma Sprint. Este é verdadeiro para
user stories que são demasiadamente vagas. Se uma história não pode ser concluída em
uma Sprint, ela não deve ser trazida para a Sprint. Em vez disso, a equipe precisa para
passar por algum esforço para aprender sobre a estória pela primeira vez.
No entanto, perceba que uma user story não precisa estar completamente compreendida
para entrar em uma Sprint. Uma história de usuário no Product Backlog não precisa ser
totalmente pensada, com todos os detalhes trabalhados, antes de ser puxada para uma
Sprint. O Product Owner e outros membros da equipe ainda vão colaborar com a história
durante a Sprint. No entanto, cada história de usuário puxada para a Sprint deve ser enten-
dida em detalhes o suficiente para que, quando discutida e argumentada durante a Sprint,
possa ser detalhada e concluída.
Há algumas coisas que a equipe Scrum deve fazer para garantir esse pensamento q
proativo nas Sprints:
11 Nas suas próximas Sprints Reviews, discuta se cada item no Product Backlog possui deta-
Fundamentos do Scrum
lhes suficientes incluídos detalhes suficientes e se ele foi adicionado apenas no tempo;
48
Mantenha os períodos de tempo regulares e estritos
Manter os períodos de tempo estritos para as Sprints reforça a ideia que o projeto se move
continuamente adiante. A equipe deve entregar um novo incremento de produto potencial-
mente utilizável constantemente. Caso contrário, ou seja, se os períodos variarem (“Vamos
executar uma Sprint de seis semanas agora porque nós estamos trabalhando em elementos
arquiteturais”) ou se estes são ocasionalmente estendidos (“Nós só precisamos de mais três
dias”), essa disciplina valiosa será perdida ao longo do tempo.
11 Planejar a Sprint se torna mais fácil: tanto o planejamento da Sprint, quanto o pla-
nejamento do release, são simplificados quando as equipes ficam com uma duração
da Sprint constante. O planejamento da Sprint é mais fácil, porque depois de normal-
mente duas a cinco Sprints a equipe aprende facilmente quantas horas de trabalho
podem ser planejadas em uma Sprint;
11 Planejar a release se torna mais fácil: equipes Scrum derivam seus planos de lan-
çamento empiricamente (sempre que possível). Eles estimam o tamanho do trabalho
a ser feito em um projeto e, em seguida, medem a quantidade concluída por Sprint.
Se a quantidade de horas na Sprint varia, medir a velocidade de uma equipe se torna
mais difícil, pois não há nenhuma garantia de que uma Sprint de quatro semanas vai
entregar o dobro que uma Sprint de duas semanas. Normalizar a velocidade como
“velocidade por semana” funciona um pouco, mas é um trabalho extra desnecessário
quando as Sprints são mantidas sob o mesmo período de tempo.
Para deixar claro que os prazos da Sprint precisam ser cumpridos rigorosamente, é óbvio
que as equipes vão ocasionalmente precisar deixar de fazer algum trabalho que tinham ini-
cialmente planejado durante alguma Sprint. Essa situação não é desejada, mas é realista, e
espera-se que estes possam compensá-la acrescentando ocasionalmente mais trabalho em
uma Sprint futura. Desde que o trabalho seja realizado em ordem de prioridade, isso não é o
fim do mundo. Assim, invariavelmente, termine as Sprints no tempo correto. Não chegue na
data planejada e decida que precisa de mais um ou dois dias para finalizar o trabalho.
Durante uma Sprint, nenhum integrante da equipe, nem mesmo o Product Owner, pode q
alterar o Sprint Backlog. Ou seja, a cada Sprint, os requisitos são congelados. O desen-
volvimento de cada Sprint deve terminar no tempo predefinido em reunião. Caso os
requisitos não sejam finalizados por qualquer motivo, eles são deixados de fora e voltam
para o Product Backlog.
Capítulo 3 - A metodologia
A postura de Scrum de ser contra as alterações meio do Sprint pode parecer prejudicial para
o sucesso do projeto. Afinal, às vezes as mudanças são tão importantes que precisam ser
feitas. E outras vezes novas informações podem tornar inútil o trabalho no qual a equipe
está atualmente envolvida. No entanto, existem algumas exceções.
Primeiro vamos considerar o caso de o Product Owner descobrir algum novo requisito
importante que precisa ser feito prioritariamente em vez do trabalho que a equipe está
49
trabalhando. Antes de mais nada, o Scrum Master deve garantir que os objetivos da Sprint
atual sejam visíveis e conhecidos por toda a organização. Mas, quando isso acontecer, a
direção do Scrum é anunciar uma finalização anormal na Sprint, seguida imediatamente
pelo planejamento de uma nova Sprint para incluir a funcionalidade recém-descoberta de
mais alta importância.
No caso, quando novas informações são aprendidas sobre o trabalho que está sendo reali-
zado (que pode fazer o trabalho planejado menos desejável), pode ser que a equipe aprenda
algo que significa que ele deve parar de trabalhar em alguma parte de uma Sprint. Por
exemplo, um objetivo da Sprint atual pode ser a de adicionar uma funcionalidade especial
especificamente para ajudar a fazer uma venda a um grande cliente. No meio da Sprint,
o cliente lhe diz que sua empresa tem tido um congelamento do orçamento e não pode
comprar o seu produto, mesmo que tenha a nova funcionalidade, ou que ele foi adquirido e
será forçado a usar o produto do seu concorrente, ou qualquer das situações semelhantes.
Nesses casos, pode fazer sentido parar de trabalhar nessa funcionalidade específica, depen-
dendo da conveniência geral para outros clientes e de quanto tempo o trabalho pode requerer.
No entanto, situações como essas acontecem com menos frequência do que a maioria das
pessoas que são novas para Scrum pensam. Uma situação muito mais comum é a de ter um
negócio orientado a interrupções, mudanças, em que mudanças simplesmente continuam a
aparecer e que, por causa disso, os desenvolvedores e o resto da equipe também precisam ser.
Cada Sprint pode ser vista como um experimento. O proprietário do produto e da equipe q
se encontram no início da Sprint para identificar a experiência mais valiosa que eles
podem executar. O experimento envolve a criação de uma certa quantidade de novas
funcionalidades na forma de software funcional.
50
Grande parte da aprendizagem será sobre o produto: o que os usuários gostam? O que eles
não gostam? O que eles acham confuso? O que eles querem seguir? Quais são as caracte-
rísticas do novo incremento que pode ajudá-los pensar acerca de coisas sobre as quais eles
não tinham pensado antes?
Talvez parte do aprendizado será sobre o uso da equipe sobre o próprio Scrum: quanto
trabalho que podemos fazer em um sprint? O que fica no nosso caminho? O que poderia nos
ajudar a ir mais rápido? Estamos obtendo “feito” software a cada Sprint?
Product Backlog
Uma equipe Scrum renuncia a uma longa fase de requisitos em favor de uma abordagem
l
just-in-time. Assim, descrições de funcionalidades podem ser recolhidas em alto nível
no início, mas elas devem ser progressivamente refinadas no decorrer do projeto. Elas
Na reunião de
Planejamento, o são documentadas em um Product Backlog, que é uma lista de todas as funcionalidades
Product Owner prepara desejadas que ainda não estão no produto. Ele é mantido pelo Product Owner e possui uma
uma lista de funcionali-
ordem de prioridade, o que o faz ser conhecido muitas vezes como lista de funcionalidades
dades desenvolvida
em conjunto o cliente, priorizadas. Ao contrário de um documento de requisitos tradicional, um Product Backlog é
que é organizada por altamente dinâmico: itens são adicionados, removidos e priorizados novamente a cada Sprint,
prioridade de entrega.
à medida que se aprende mais sobre o produto, os usuários, a equipe e assim por diante.
Esse é o Product
Backlog.
O Product Backlog é uma lista em nível de negócio. Dessa forma, não está escrito em nível
de negócio e estão em uma linguagem do cliente. Já vimos que o Product Backlog não é final,
e que a equipe de desenvolvimento também contribui para a sua manutenção. Essa contri-
buição se dá por meio das estimativas de custos das funcionalidades.
11 Documentos escritos podem fazer você suspender o julgamento: quando algo está
escrito, parece oficial, formal e finalizado, especialmente quando uma formatação
organizacional foi aplicada;
de uma unidade de propósito. Uma pessoa (ou grupo) define o produto; outro grupo
constrói. A comunicação bidirecional é desencorajada;
51
11 Não deixar o bebê sozinho sem documentação: tais deficiências na comunicação q
escrita não significam que devemos abandonar completamente os documentos de
requisitos. Em vez disso, devemos usar documentos onde for apropriado. Como o
Manifesto Ágil diz ser a favor de “software funcional em vez de documentação abran-
gente”, ágil tem sido mal interpretada como sendo totalmente contra documentação.
O objetivo no desenvolvimento ágil é encontrar o equilíbrio certo entre a documen-
tação e discussão;
11 Use User Stories para o Product Backlog: histórias de usuários são a melhor maneira
de mudar o foco de escrever sobre funcionalidades para falar sobre eles mesmos.
A user story é uma breve descrição, simples de uma funcionalidade, contada a partir
da perspectiva da pessoa que deseja uma nova função, geralmente um usuário ou
cliente do sistema. Elas são muitas vezes escritas em cartões de índice ou notas,
armazenadas e dispostos em paredes ou mesas para facilitar o planejamento e dis-
cussão. Como tal, as histórias de usuário mudam fortemente o foco de escrever sobre
os recursos para discuti-las. Uma user story frequentemente tem o formato:
Observe a tabela 3.1. Um exemplo de sub-tarefa são as funcionalidades Cancelar Vinculo Tabela 3.1
e Vincular Caixa de Picking List. Product Backlog.
Product Backlog
52
Sprint Backlog
Assim que a equipe Scrum escolher e definir a lista de requisitos e a prioridade de seus q
itens no Product Backlog, dá-se início a um novo ciclo, chamado Sprint. Cada um desses
itens agora será dividido em partes menores para o Sprint Backlog. Um documento
especificando o detalhe de cada funcionalidade do sistema, com informações técnicas
adicionais que auxiliarão no desenvolvimento.
Sprint Backlog
Tabela 3.2 A equipe compila uma lista inicial dessas tarefas na segunda parte da reunião de planeja-
Sprint Backlog da mento do Sprint. As tarefas devem ser divididas de modo que cada um leva cerca de 4 a
Funcionalidade
Consultar Caixa. 16 horas para terminar. Tarefas que durariam mais de 4 a 16 horas são considerados meros
espaços reservados para as tarefas que ainda não foram adequadamente definidas.
Logo após o Sprint Backlog estar concluído, é preenchido o campo “Horas Trab” com a q
quantidade de horas que a funcionalidade demandou para ser concluída. Sendo assim, é
possível comparar o total de horas trabalhadas com a estimativa pré-definida na reunião
de planejamento, dando oportunidade de melhorar futuras estimativas. Caso haja uma
diferença significativa, a equipe Scrum deve negociar novamente com o cliente uma
nova data de entrega.
recomendado, para que os membros da equipe possam podendo incluir itens conforme
concluam suas atividades, como um quadro de cartões ou post-its ou um software que
simule essa interface, como mostrado na figura 3.3. Dessa forma, o responsável pelo
Sprint Backlog pode, ao fim do dia, atualizar o arquivo.
53
Mais Importante Menos Importante
Figura 3.3
Lista de prioridades
simulando quadro
de cartões post-its.
11 Fica mais fácil priorizar novamente as atividades – basta trocar a posição dos cartões;
11 Após a reunião, os cartões podem ser levados para a sala da equipe e colocado no
quadro de tarefas (Task Board) para que todos visualizem melhor.
Release Burndown
É considerado o principal gráfico de controle do Scrum e representa o trabalho restante q
dentro da Sprint de uma versão do sistema que será entregue. No exemplo mostrado a
seguir, na figura 3.4, o eixo horizontal do gráfico exibe as iterações e o eixo vertical exibe
a quantidade de trabalho restante.
250
245
200
202
Horas Restantes
150 159
140
100 113
68
50
28 Figura 3.4
0 Gráfico de
Release 5\ Release 5\ Release 5\ Release 5\ Release 5\ Release 5\ Release 6\ Burndown em
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 1 Planejamento.
De acordo com Mountain (2011), esse tipo de gráfico funciona em muitas situações e com
diversas equipes. Porém, em projetos com muitas mudanças de requisitos, talvez o gráfico
Fundamentos do Scrum
não seja adequado, já que a quantidade de horas não vai refletir a ideia de um projeto que
se consome.
Segundo Highsmith (2004), uma das principais ferramentas de equipe para acompanhar o
projeto no Scrum é o release burndown chart, que mostra o andamento diário da equipe
por horas, de acordo com a soma das tarefas listadas no Sprint Backlog. A equipe também
possui uma task board onde as funcionalidades são colocadas separadas por estados.
54
Gráfico de Burndown
É uma das principais ferramentas para o gerenciamento do processo de desenvolvimento, q
pois permite mostrar as partes do trabalho que faltam para uma Sprint acabar, dia por dia.
Sua atualização deve ser diária para que assim a tomada de decisão seja realizada com
base em dados atualizados, melhorando a produtividade da equipe e habilitando a
previsibilidade de riscos. Durante as Scrums diárias, o Scrum Master acompanha os
membros da equipe para perceber o que foi concluído até aquele momento. Assim, dia a
dia, ele ajusta o gráfico de Burndown e, a qualquer momento, todo o time pode ter uma
ideia do andamento do processo. O mesmo gráfico pode ser mostrado para o Product
Owner visualizar a trajetória do projeto: atrasado, adiantado ou dentro do cronograma.
Na figura 3,5, podemos perceber a linha real do andamento do projeto com muitos
pontos estimados, mas poucos pontos realizados ao longo dos dias, com relação àqueles
estimados inicialmente para a Sprint. Recomenda-se nesse caso a remoção de funciona-
lidades do Sprint Backlog, diminuindo o escopo da Sprint.
250
200
150
Pontos
100
50
0
Capítulo 3 - A metodologia
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figura 3.5
Dias
Gráfico de
Burndown Estimado
para Sprint Realizado
Superestimada.
55
Se, em caso contrário, a linha real do andamento do projeto estiver muito acima da linha q
estimada, deve-se aumentar o escopo da Sprint. A seguir, na figura 3.6, segue um exemplo
de projeto para a gestão de uma imobiliária em que o projeto foi sendo realizado antes do
estimado – ou seja, muitos pontos foram sendo desenvolvidos antes do tempo pré-deter-
minado. Nesse caso, é possível aumentar o escopo.
160
140
120
100
80
Pontos
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figura 3.6
Dias Gráfico de
Burndown
Estimado
para Sprint
Realizado Subestimada.
O ideal em situações assim é retirar tarefas de alta prioridade da próxima Sprint. Caso a q
meta da próxima Sprint seja muito baixa, podemos até mesmo optar pelo cancelamento
da Sprint, juntando as tarefas restantes a Sprint seguinte.
Finalmente, na figura 3.7, podemos ver um projeto para gestão de construtora sendo
realizado mais ou menos conforme estimado – ou seja, muitos pontos estão sendo
desenvolvidos no tempo determinado. Esse é um exemplo de um projeto ideal.
160
140
120
100
80
Pontos
60
40
Fundamentos do Scrum
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
56
Task Board
Consiste em um grande painel, que possibilita colocar as diversas informações rele- q
vantes para o acompanhamento da Sprint, tais como o Product Backlog, e as atividades
da Sprint juntamente com o seu status (“Pendente”, “Em desenvolvimento”, “A verificar”
e “Concluída”). A ideia do Task Board é tornar essas informações sempre visíveis para
todos os interessados no desenvolvimento do projeto. Geralmente, o painel é dese-
nhado e colocado em uma parede, e as atividades são descritas em cartões de post-its,
como na figura 3.8:
Cadastro de
categorias de
apartamentos
Cadastro de
apartamentos
Problemas
no servidor
de teste
SCRUM Master
Figura 3.8 Cadastro de deverá resolver
Task Board com clientes (remover) este
Impedimento. impedimento
Release
Como não é criado um Product Backlog para cada produto, Scrum recomenda a criação q
de um plano de Release, que divide os itens do Product Backlog em Sprints. Cada Sprint
gera um “entregável”, que são funcionalidades desenvolvidas naquela Sprint. Conforme
pode ser visualizado na figura 3.9, a junção dos entregáveis de algumas Sprints gera um
release – ou seja, uma Sprint é parte de um release.
O release se trata de um produto pronto para ser testado e utilizado pelo usuário. Os
entregáveis de cada Sprint não são liberados para os usuários conforme são concluídos,
mas são liberados quando a junção de cada entrega forma um produto que faça sentido
e adicione valor para o cliente.
57
Sprint #1
Manter Entrega 1
Manter Caixa Pick List
Sprint #2
Sprint #3
Entrega 3
Cancelar Vínculo
Figura 3.9
Funcionalidades,
Sprints, Entregas e
Produto Releases formando
o Produto.
Atividades práticas
Cenários para realização de uma Planning, incluindo: análise de backlog, análise de user
stories, quebra de stories em atividades, scrum poker e finalização da Sprint.
58
4
Scrum e a organização
objetivos
Entender como Ciclo PDCA e Scrum se complementam; Dicas gerenciais para Scrum;
Scrum e Governança
conceitos
Ciclo PDCA; Equipes distribuídas; Recursos humanos, instalações e PMO
Plan Do
(Planejar) (Fazer)
Act Check
(Agir) (Checar)
Figura 4.1
Ciclo PDCA.
q
Capítulo 4 - Scrum e a organização
Em resumo, o ciclo tem quatro fases, que significam passos no processo de adminis-
tração. Quando aplicadas ao Scrum, elas podem ser perfeitamente correlacionadas às
ações de uma Sprint, conforme analogia a seguir:
11 Plan: essa é a primeira fase do processo. Durante essa etapa, a equipe discute os obje-
tivos, o processo e as condições claras de finalização da Sprint (condições de aceitação).
Essa etapa define os objetivos mensuráveis e realizáveis para a equipe;
11 Do: a equipe trabalha em conjunto para atingir o objetivo fixado na fase de planeja-
mento. A equipe trabalha com o conjunto de processos acordados;
59
11 Check: uma vez que a entrega foi realizada, a equipe se reúne e verifica a saída, q
comparando-a com as condições acordadas de aceitação, decididas durante a fase de
planejamento. Os desvios, se existirem, são anotados. É importante notar que essa
verificação se dá não somente com relação ao produto entregue, mas também com
relação aos processos realizados;
11 Act: se qualquer desvio em tarefas planejadas foi observado durante a fase de veri-
ficação, a análise de causa raiz deve ser conduzida. Brainstorms juntamente com a
equipe serão realizados para identificação das alterações necessárias para evitar tais
desvios no futuro. A equipe também realiza brainstorms para entender mudanças
de ideias no processo, incluindo as mudanças de escopo e métricas de medição que
podem resultar em um melhor processo ou produto no próximo ciclo ou iteração.
O processo começa com um conjunto claro de metas e critérios de aceitação. Não pode
haver mal-entendidos, o que ajuda a minimizar o desperdício. O grupo sabe o que fazer
e ter orientação adequada para alcançá-lo. A verificação das tarefas planejadas também
acontece em relação aos critérios de aceitação conhecidos. O processo ajuda a equipe a
fazer pequenas mudanças, obter feedback e seguir em frente. A inspeção e adaptação ajuda
a equipe a crescer. O cliente final provavelmente encontra-se satisfeito, porque pode ver a
saída rapidamente e pode fazer as mudanças com base nas condições de mercado.
Cada projeto escalado tem suas próprias complexidades, cada um dos quais normalmente
exige sua própria solução única e individual. Scrum escala do mesmo modo como qualquer
outro processo de desenvolvimento, utilizando praticamente os mesmos mecanismos de
escala, mantendo todas as práticas empíricas que formam o seu núcleo.
O núcleo em torno do qual a escala ocorre é a equipe Scrum. Um projeto com 800 q
pessoas será composto por 100 equipes de 8 pessoas, então a dificuldade encontra-se
Fundamentos do Scrum
60
Infraestrutura
Antes de escalar qualquer projeto, uma infraestrutura adequada deve ser colocada em q
prática. Se um projeto vai empregar várias equipes co-instaladas, um mecanismo para
sincronizar com frequência o seu trabalho deve ser concebido e implementado. Além
disso, um produto mais detalhado e a arquitetura técnica devem ser construídos de modo
que o trabalho possa ser dividido entre as equipes. Se essas equipes estão distribuídas
geograficamente, tecnologia de compartilhamento de código-fonte, sincronizado constrói
e comunicações alternativas, tais como mensagens instantâneas, devem ser empregados.
l
Tudo o que suporta o esforço da escala deve ser concebido e implementado antes do esca-
lonamento do projeto; todo esse trabalho é feito em Sprints. Scrum exige que cada Sprint
Demonstrar funcionali-
dade de negócios produza um incremento de funcionalidade do produto potencialmente utilizável, e esse
permite a produção do requisito pode ser cumprido se meses são necessários para conceber e implementar uma
tipo de resultados que
infraestrutura para escalar o projeto.
o Product Owner e as
partes interessadas
Na verdade, embora menos funcionalidade de negócio seja criada durante as Sprints iniciais
tanto prezam desde o
início, e ajudam o seu nas quais a infraestrutura será criada, ainda é necessário demonstrar algumas funcio-
engajamento e nalidades de negócios no final. Na verdade, é ainda mais importante fazê-lo, porque isso
envolvimento no
permite que a infraestrutura seja testada com o trabalho de desenvolvimento de funcionali-
projeto.
dade à medida que a mesma evolui.
Os requisitos não funcionais para construir a infraestrutura de escala são uma priori- q
dade elevada no Product Backlog, porque devem ser concluídos antes de escala em si.
Como a funcionalidade de negócios deve ser demonstrada no final de cada Sprint, esses
requisitos não funcionais são misturados com a funcionalidade de negócios de mais alta
prioridade. Se um pedaço de funcionalidade de negócios depende de um requisito não
funcional, o requisito não funcional deve ser priorizado no Product Backlog para ser
desenvolvido antes ou em paralelo com a funcionalidade de negócios.
Staging
O processo de definição e priorização dos requisitos não funcionais para escala é chamado q
de Staging. Staging ocorre antes do início do primeiro Sprint e leva apenas um dia, durante
o qual os requisitos de escala para o projeto são determinados e colocados no Product
Backlog. Por exemplo, se você está escalando o projeto para usar várias equipes, os
seguintes requisitos não funcionais devem ser adicionados ao backlog do produto:
Após esses requisitos não funcionais para dimensionamento serem colocados no Product
Backlog, as Sprints podem começar. No entanto, apenas uma equipe pode iniciar seus traba-
lhos até a infraestrutura de escala estar no lugar, como não é claro haverá mecanismo para
coordenar o trabalho de várias equipes no mesmo período.
Veja a figura 4.2 para uma representação do Product Backlog inicial com todos os requi- q
sitos não funcionais adequados para o tipo de Staging imaginado.
61
Equipe única Figura 4.2
Sprints de Escala.
Backlog do produto inicial
Requisitos funcionais
Requisitos não funcionais
Staged scalability requirements
The rest of the functional and
non-functional requirements
Várias equipes
Backlog do produto
Requisitos funcionais
Requisitos não funcionais
Equipes distribuídas
Há alguns anos, as equipes co-instaladas eram a norma: se tornou difícil encontrar uma q
equipe distribuída geograficamente. Agora, o inverso parece ser verdadeiro: é uma sur-
presa quando uma organização tem toda a equipe trabalhando no mesmo edifício. Com
a prevalência de equipes espalhadas por todo o mundo, ou pelo menos através de fusos
horários distintos, é importante considerar quão bem Scrum funciona quando uma
equipe está geograficamente distribuída.
Um equívoco comum é que Scrum não é uma boa metodologia para uma equipe geogra-
ficamente dispersa. O argumento do Scrum pela preferência por uma comunicação face
a face faz com que muitos pensem que escolher equipes distribuídas seja má escolha.
Felizmente, esse argumento é falso. Embora seja verdade que uma equipe local sempre
Fundamentos do Scrum
vai superar a equipe distribuída equivalente (Ramasubbu e Balan 2007), Scrum pode
realmente ajudar as equipes geograficamente distribuídas.
62
Existem algumas regras do Scrum para equipes distribuídas que veremos a seguir, e q
dizem respeito basicamente à forma com que as cerimônias devem acontecer e como
a equipe deve ser disposta. A razão para isso é que uma diferença de fuso horário
tem muito impacto sobre a forma como uma equipe trabalha. Na verdade, possui um
impacto muito maior do que a distância geográfica em si.
Teleconferência longa
É a abordagem padrão seguida pela maioria das equipes, e consiste em ligar para um q
número de teleconferência e conduzir a reunião de planejamento normalmente,
simulando o formato de reunião pessoal. Todo o trabalho de uma reunião de planeja-
Tabela 4.1
A teleconferência mento de Sprint regular é realizado nessa reunião. Quando ela se encerra, a Sprint deve
longa. estar completamente planejada como se a equipe fosse local.
Vantagens Desvantagens
Pode levar a boas discussões se todos se Participantes podem se distrair em uma ligação tão longa
mantiverem engajados
O planejamento da Sprint pode se encerrar Só funciona quando há muitas horas em comuns no dia de
em um dia trabalho na equipe geograficamente dispersa
É consistente com a abordagem utiliza em Pode significar estender o dia de trabalho em uma ou mais
equipes co-localizadas localidades
Duas teleconferências
Para algumas equipes, é simplesmente impraticável planejar a reunião de planejamento q
da Sprint em uma teleconferência: a separação de fusos horários é muito grande para
proporcionar sobreposição suficiente nos dias de trabalho. A próxima abordagem de pla-
nejamento do Sprint, duas chamadas, divide a reunião através de dois telefonemas reali-
zados em dias consecutivos. Substituir a sessão inicial de oito horas por duas sessões de
quatro horas separadas, realizadas em dias consecutivos, é mais prático.
Tabela 4.2 mais altas do Product Owner. Durante a segunda sessão, cada membro da equipe define as
Duas atividades e fornece estimativas para cada tarefa que ele aceite. Seu foco é sincronizar os
Capítulo 4 - Scrum e a organização
Vantagens Desvantagens
Pode ser uma forma mais eficiente de se Esse senso de utilidade pode variar grandemente,
usar o tempo dependendo de como a equipe está distribuída
Pode ser usada mesmo quando há Como muitas discussões acontecem entre as equipes, nem
poucas horas em comum nos dias de todo o conhecimento é compartilhado com a equipe global,
trabalho na equipe o que pode levar a mal-entendidos
63
Daily Scrum
A Scrum diária introduz um conjunto de novos desafios em relação à reunião de pla- q
nejamento da Sprint em equipes geograficamente dispersas. Como o Scrum diário é
uma reunião diária de 15 minutos, a sua realização não representa um problema para
equipes com dias de trabalho que se sobrepõem, mas são um problema, no entanto,
para equipes amplamente distribuídas sem sobreposição em horas de trabalho. Realizar
chamadas diárias em uma hora em que você normalmente não está trabalhando não é
sustentável a longo prazo. Existem basicamente três métodos que podem ser usados
para as Scrums diárias nessas situações: uma conferência única, reunião escrita e
reunião regional. Veremos as vantagens e desvantagens de cada uma delas a seguir.
Teleconferência única
Talvez a abordagem mais comum e aquela que é inicialmente tentada pela maioria das q
equipes é fazer com que todos os participantes da equipe entrem juntos em um único
telefonema. Para as equipes coincidindo em fusos horário uns dos outros, essa é uma
excelente abordagem. Infelizmente, a abordagem se deteriora rapidamente quando o
número de fusos horários aumenta. Eventualmente, as equipes mais amplamente
Tabela 4.3
distribuídas rapidamente entendem ser necessária uma estratégia diferente para as Teleconferência
suas Scrum diárias. única.
Vantagens Desvantagens
Similar à abordagem usada em equipes locais, Pode ser inconveniente para membros da
então nada novo precisa ser mudado equipe
Reunião escrita
Para minimizar o trabalho de horas de telefonemas para alguns locais, algumas equipes q
abandonam reuniões diárias completamente. No entanto, sem querer desistir do valor
da comunicação diária inteiramente, tais equipes normalmente substituem reuniões
diárias por uma versão escrita da reunião.
quando a maioria da equipe está localizada apenas com alguns membros remotos.
Normalmente, essa abordagem não é indicada como técnica primária, mas pode ser
usada para completar chamadas diárias, se a equipe decide que elas estão acontecendo
demasiadamente, estão prejudicando a equipe que está trabalhando fora da sua hora de
trabalho normal e, por isso, precisa reduzir a sua frequência.
64
Há características importantes de uma Scrum diária que são perdidas quando a q
chamada é transformada em uma atualização diária escrita. Por exemplo, o compro-
misso assumido parece mais forte quando um membro da equipe diz: “Eu vou fazer isso
hoje”, do que quando as mesmas palavras são escritas. Talvez isso seja porque a
Tabela 4.4 mensagem falada é um compromisso assumido na frente dos próprios colegas de
Reunião escrita. trabalho, enquanto a mensagem escrita é um compromisso feito em privado.
Vantagens Desvantagens
Sustentável a longo prazo Problemas não são discutidos e podem ficar “adormecidos”
por dias
Ajuda a resolver problemas de linguagem, Não há realmente garantias de que as atualizações escritas vão
incluindo sotaques ser lidas
Reuniões regionais
A terceira e última abordagem para a reunião de Scrum diária é ter um conjunto de reu- q
niões regionais seguidas por algum esforço para compartilhar a questões-chave de cada
uma dessas reuniões. Se uma equipe é dividida em duas cidades muito distantes, por
exemplo, cada cidade pode ter sua própria reunião diária.
Esse seria o caso, por exemplo, para uma equipe com membros em escritórios da
empresa em São Francisco, nos EUA, e Londres, na Inglaterra, que possuem intervalos
de horas de diferença.
Às vezes, uma equipe distribuída tem alguns escritórios com sobreposição de horas de
trabalho, além de um escritório mais remoto – nesses casos, os locais com horários sobre-
postos podem ter um Scrum diário, já a localização mais remota teria sua própria reunião.
As reuniões regionais, se todo mundo está presente em um escritório, ou de discagem em
uma chamada entre as diversas cidades, são, então, geralmente seguidas por uma comuni-
cação adicional, de modo que cada equipe está consciente do trabalho das outras equipes.
Tabela 4.5 Uma maneira de realizar essa comunicação é um telefonema com pelo menos um q
Reuniões regionais. representante de cada equipe.
Vantagens Desvantagens
Reduz grandemente o estresse de trabalho Informação de uma reunião para outra pode estar incorreta
em horas extras ou incompleta, nem compartilhada na hora necessária
Permite o compartilhamento de informação Pode levar para um sentimento de “nós” e “eles” entre
chave em equipes locais equipes diferentes
Capítulo 4 - Scrum e a organização
65
Szcrum of Scrums
O Scrum dos Scrums é usado por várias equipes para coordenar seu trabalho. Envolve q
um representante de cada equipe, e acontece geralmente duas ou três vezes por
semana. A frequência reduzida dessa reunião a torna menos problemática para uma
equipe distribuída. Essa reunião dura quase sempre uma hora ou menos; portanto, uma
equipe distribuída com qualquer sobreposição de horas em sua jornada de trabalho será
capaz de facilmente programá-la.
Isso é mais fácil de fazer do que é para o Scrum diário por duas razões: primeiro, a q
maioria dos Scrum dos Scrums não são diárias e, em segundo lugar, a maioria das
equipes, ocasionalmente, mudam quem participa dessas reuniões.
No entanto, assim como as daily Scrums, revisões de Sprint e retrospectivas são um pouco l
mais fáceis de planejar, porque elas são mais curtas do que uma reunião de planejamento do Se tanto a revisão e a
Sprint. Isso faz com que a tarefa de encontrar um momento certo adequado para a reunião retrospectiva foram
curtas, alguns membros
seja relativamente fácil, já que equipes com sobreposição de horas de trabalho agendam essas da equipe podem
reuniões durante a parte sobreposta de seus horários. Equipes cujas horas de trabalho quase preferir agendá-las uma
logo após a outra.
se sobrepõem normalmente agendarão essas reuniões no final de um dia de trabalho para
Outras equipes podem
uns e no início para outros. preferir agendá-las um
dia logo após o outro.
Dicas gerenciais
Alguns pontos finais a considerar em equipes virtualmente discretas são os que seguem: q
11 Decida como distribuir as equipes: uma equipe colaborativa em uma localidade ou
equipes deliberadamente distribuídas;
66
Coexistindo com outras abordagens
Uma coisa é olhar para o desenvolvimento ágil de software em um tubo de ensaio; outra q
é experimentá-lo no mundo real. No tubo de ensaio, metodologias ágeis como o Scrum
são facilmente adotadas por todos os membros, e as realidades da política corporativa,
economia, e não podem intrometer. No mundo real, contudo, todas essas questões
desagradáveis não existem. Raramente é simples tomar a decisão de utilizar Scrum e,
em seguida, ser capaz de fazê-lo sem outras restrições.
Por exemplo, um projeto pode tentar Scrum desde que isso não interfira na certificação
CMMI Nível 3 da organização. Outro projeto pode tentar experimentá-lo enquanto ele
está na revisão preliminar de arquitetura e, em seguida, tem uma reunião para aprovar
o design.
Pode haver razões válidas para uma organização para colocar essas restrições sobre os
projetos. Nesta sessão, estudaremos como um projeto Scrum é afetado quando se cruza
com um processo sequencial. A seguir, consideramos o impacto da governança do projeto
e como projetos Scrum podem coexistir com sucesso com abordagens de governança não
ágeis. Finalmente, vamos explorar maneiras projetos Scrum podem cumprir com normas
como a ISO 9001 ou CMMI.
67
11 Sequencial no meio: a maneira mais complicada em que Scrum tem de interagir com q
o desenvolvimento sequencial é esta. Um exemplo comum disso é quando duas ou
mais equipes devem trabalhar juntas para criar um único produto e pelo menos uma
equipe delas está usando Scrum, e a outra está usando uma abordagem sequencial.
A coordenação do trabalho e a comunicação frequente são geralmente as principais
fontes de problemas quando essa disposição existe. A equipe sequencial prefere se
comunicar por meio de reuniões e documentos que bloqueiam a interface, enquanto
a equipe Scrum vai preferir deixar interfaces mais vagas e eleger uma comunicação
informal, com interfaces e compromissos definidos de forma progressiva. A equipe
Scrum que se encontra nessa situação geralmente acha útil atrair os gestores dos
projetos sequenciais para participar de reuniões de planejamento do Sprint e para as
reuniões diárias.
Governança
Uma das razões pelas quais muitas organizações adotam uma abordagem sequencial q
para o desenvolvimento de software é o encaixe natural entre uma sequência definida,
as fases de desenvolvimento e a necessidade de supervisão do projeto. O objetivo da
supervisão do projeto, comumente chamado de governança, é certificar-se de que um
projeto não vai se extraviar. Governança eficaz do projeto pode, por exemplo, identificar
um projeto que vai exceder seu orçamento, levando a conversas sobre se o projeto deve
ser cancelado.
Governança também pode identificar um produto que está à deriva muito longe de seus
objetivos originais, um projeto que está a se desviar de um padrão arquitetural ou qualquer
número de considerações de alto nível similares importantes para a organização.
11 Uma revisão quando o aplicativo está pronto para o sistema ou teste de aceitação
do cliente;
11 Uma revisão quando o produto pode ser entregue a uma organização de apoio;
e assim por diante.
Esses postos de controle muitas vezes podem causar estragos no desejo de uma equipe de
software de usar Scrum, pois eles não são adequados para o trabalho feito de forma iterativa.
68
Passos para rodar o projeto Scrum com governança não ágil: q
1. Negocie e deixe claro quais são as expectativas desde o princípio.
Conformidade a padrões
Nem todas as equipes ou mesmo departamentos de desenvolvimento de software têm q
o luxo de ter o controle completo sobre seu processo de desenvolvimento. Por exemplo,
clientes terceirizados durante o desenvolvimento do contrato muitas vezes requerem
que fornecedores sejam certificados CMMI Nível 5, o que requer que os desenvolvedores
de software sigam algumas das melhores práticas estabelecidas.
Além disso, alguns produtos de software são entregues em setores regulados e cumprem
com normas como a ISO 9001.
Nenhum desses padrões prescreve um ciclo de vida que é contraditório como o Scrum.
Como cumprir normas na organização raramente é opcional, equipes Scrum devem preo-
cupar-se com a melhor forma de cumpri-las, começando em alguns casos com a questão de
saber se isso vai ser possível com um processo Scrum. Nesta sessão, vamos estudar como
equipes de Scrum podem ficar em conformidade com ISO 9001 e CMMI, dois dos padrões
mais comuns com que Scrum precisa coexistir. A partir deles, podemos generalizar algumas
estratégias de enfrentamento em outras situações de conformidade.
ISO 9001
A Organização Internacional de Normalização (ISO) mantém o padrão 9001, que normal- q
mente é designado em sua inteireza como ISO 9001:2000 ou ISO 9001:2008, ambos os
quais indicam o ano de uma versão específica do padrão. A certificação ISO 9001 não se
destina a garantir que os produtos de uma organização atinjam um nível de qualidade
específico. Em vez disso, a certificação indica que a organização segue um conjunto de
práticas formais no desenvolvimento de seus produtos. Uma grande parte do esforço
em conformidade com a ISO 9001 é a criação de um sistema de gestão da qualidade, que
geralmente é um longo documento ou conjunto de páginas da web que descrevem as
práticas de qualidade seguidas pela organização.
já tinha experiência substancial com práticas ágeis no momento em que iniciou o seu
esforço ISO 9001.
Em tal ambiente, seria natural para os funcionários se preocuparem com a perda de agili-
dade com a introdução de ISO 9001. Bill McMichael, da Primavera, e Marc Lombardi, um
consultor com experiência em ISO 9001, trabalharam juntos por iniciativa e chegaram
à conclusão de que a documentação não diminuiu a sua agilidade. O mantra foi prover
apenas documentação suficiente e referências que fossem realmente úteis para ajudar
com a garantia do processo que já existisse.
69
CMMI
Desde que o primeiro projeto ágil surgiu do lodo primordial, as empresas têm se pergun- q
tado se as metodologias ágeis são compatíveis com o Capability Maturity do Instituto de
Engenharia de Software Model Integration (CMMI). Como medida de algumas maneiras
de quanto processo de uma organização tem (ou pelo menos como muito do que tem
sido definida), o CMMI e seu antecessor, o Capability Maturity Model Software (SW-
CMM), são muitas vezes vistos como formas de pesos pesados de desenvolvimento de
software e a antítese do desenvolvimento ágil.
Conseguindo conformidade
De maneira geral, conseguimos estabelecer que Scrum é compatível com ISO 9001 e q
CMMI, tanto teoricamente quanto empiricamente. Para tornar Scrum conforme a sua
organização, um passo a passo pode ser seguido:
7. Trabalhe com seu auditor no processo ao qual você deseja ficar conforme.
70
11 Recursos humanos: equipes Scrum começam a fazer muito bem até que chega o q
tempo de revisão anual. De repente, todo mundo percebe que eles serão novamente
avaliados e a receber aumentos, com base exclusivamente no desempenho indivi-
dual. A revisão anual pode ter um campo para avaliar se um indivíduo se dá bem com
os outros, mas no final do dia contribuições e o heroísmo individual é o que é impor-
tante em termos de aumentos e promoções. É impossível pensar em adotar um pro-
cesso fundado sobre uma preferência por “indivíduos e interações sobre processos
e ferramentas” sem envolver o departamento de recursos humanos. Na organização
típica, esse grupo pode ter ainda mais influência sobre como as pessoas percebem
seus trabalhos e atuar neles do que os gerentes funcionais desses indivíduos;
11 Instalações: é muito mais fácil ser ágil quando toda a equipe está no mesmo local.
Mas quando um grupo de instalações torna tão tudo mais difícil, ou quando se
impede que as equipes Scrum usem o espaço da parede para os gráficos de manejo
e outros dados importantes do projeto, as equipes se tornam desmoralizadas.
Torna-se mais difícil manter o impulso de se tornar melhor em Scrum quando
parece que todo mundo está contra. O ambiente físico em que trabalhamos tem
uma influência direta sobre nós. Considere as mensagens conflitantes enviadas
quando uma empresa proclama “as pessoas são nosso maior patrimônio”, enquanto
o conjunto de instalações proíbe pendurar gráficos de burndown nas paredes. A
verdadeira mensagem é alta e clara:
“As paredes são um bem maior.”;
11 PMO: sem pensar em como seu projeto se refere a um PMO existente, uma equipe
Scrum inicia com uma atitude de “dane-se a papelada e processo”. Isso cria um
inimigo no PMO, um grupo que já estava inquieto sobre os experimentos iniciais
da organização com Scrum. O PMO responde convencendo gerência do departa-
mento que não tem problemas com Scrum, desde que ele seja complementado por
um conjunto de documentos e práticas. O PMO muitas vezes tem um enorme peso
político e experiência do projeto. Ao conseguir que essa parte da organização esteja
de acordo com Scrum, não só se evita uma possível fonte de resistência, mas também
se beneficia da sua experiência. Os membros do PMO podem se tornar guardiões de
auto-organização, melhoria contínua, propriedade, comunicação, experimentação,
colaboração e outros valores.
Quando Scrum é erroneamente encarado apenas como uma mudança dentro do grupo
de desenvolvimento, a gravidade organizacional criada pelos departamentos de fora da
TI pode puxar o grupo de desenvolvimento de volta para onde tudo começou. É possível
ignorar as implicações do Scrum sobre esses grupos e ser bem-sucedido, por algum
tempo. Eventualmente; porém, será necessário envolver com eles para criar uma tran-
sição bem-sucedida, a longo prazo.
como obstáculos a serem superados. Uma abordagem mais produtiva é ver cada um
como um aliado para ser inscrito. Embora uma relação conflituosa possa funcionar por um
tempo, o sucesso a longo prazo requer o apoio de toda a organização. O caminho para se
tornar ágil pode ser longo; quando for possível, é melhor fazer amigos, em vez de inimigos.
71
Atividades
Cada Sprint é um bloco de iteração que segue um ciclo PDCA e entrega um incremento de
funcionalidades prontas para serem incorporadas no software. Um ciclo PDCA, também
conhecido como o círculo de Deming, é um método de gerenciamento iterativo de quatro
passos usado em gestão para o controle e melhoria contínua de processos e produtos.
Fundamentos do Scrum
72
Rodrigo Alves Costa atualmente é
professor efetivo do curso de Ciências
da Computação da Universidade Esta-
dual da Paraíba e doutorando em Ciên-
cias da Computação na Universidade
Federal de Pernambuco (UFPE). Possui
mestrado em Ciências da Computação
pela UFPE (2010), MBA em Gerenciamento de Projetos pela
Fundação Getúlio Vargas (2007) e graduação em Ciências da
Computação pela UFPE (2005). É certificado Project Manage-
ment Professional (PMP) pelo Project Management Institute
(PMI) (2006). Tem vasta atuação profissional, destacando-se
em funções como executivo de projetos, analista de siste-
mas, engenheiro de sistemas, de segurança e de software
em empresas como IBM, Siemens, Motorola e C.E.S.A.R.
Também é autor de livros na área de administração organi-
zacional com foco em projetos, entre os quais Gerencia-
mento de Projetos de TI, e colaborador de cursos de gestão
empresarial em tecnologias da informação e comunicação
em diversas organizações e instituições de ensino, sendo
um dos idealizadores do currículo de governança da Rede
Nacional de Pesquisa, vinculado à ESR/RNP/CNPQ. Foi bol-
sista CNPQ durante o mestrado e a graduação (PIBIC), e atu-
almente está vinculado aos diretórios de pesquisa da
entidade, no grupo de estudos em Segurança Computacio-
nal da UFPE. Pesquisador na área de Ciência da Computa-
ção, com ênfase em segurança computacional e teoria da
computação, e na área de Gerenciamento de Projetos, com
ênfase em gerenciamento de projetos virtuais e planeja-
mento estratégico orientado por TIC. É membro entusiasta
do PMI, membro da Association for Computing Machinery
(ACM) e da Sociedade Brasileira de Computação (SBC).
O curso aborda os principais conceitos do Scrum, apre-
LIVRO DE APOIO AO CURSO
entregas acontecem.