Apostila curso: Formação Total em

Scrum & Agile

Material de referência para certificações ASF™ e PSM I™

1
 Disclaimer
Professional Scrum™, Professional Scrum Master, PSM, PSM I, Professional Scrum Product Owner, PSPO, PSPO I, Scrum Open,
etc. is the protected brand of Scrum.org ( http://scrum.org/ ) . Our course and practice exams are neither endorsed by nor affiliated
with Scrum.org ( http://scrum.org/ ) .

All the content related to Scrum Guide is taken from scrumguides.org (ttp://scrumguides.org/ ) and is under the Attribution
ShareAlike license of Creative Commons. Further information is accessible at http://creativecommons.org/licenses/by-sa/4.0/
legalcode and also described in summary format http://creativecommons.org/licenses/by-sa/4.0/ .

The statements made and opinions expressed herein belong exclusively to ExpertPM and are not shared by or represent the
viewpoint of Scrum.org. This training does not constitute an endorsement of any product, service or point of view. Scrum.org makes
no representations, warranties or assurances of any kind, express or implied, as to the completeness, accuracy, reliability, suitability,
availability or currency of the content contained in this presentation or any material related to this presentation. In no event shall
Scrum.org, its agents, officers, employees, licensees or affiliates be liable for any damages whatsoever (including, without limitation,
damages for loss of profits, business information, loss of information) arising out of the information or statements contained in the
training. Any reliance you place on such content is strictly at your own risk.

Aviso Legal
Professional Scrum ™, Scrum Master Profissional, PSM, PSM I, Profissional Scrum Product Owner, PSPO, PSPO I, Scrum Open,
etc. é a marca protegida do Scrum.org (http://scrum.org/). Nossos exames de curso e prática não são endossados ​​nem afiliados ao
Scrum.org (http://scrum.org/).

Todo o conteúdo relacionado ao Scrum Guide é retirado do scrumguides.org (ttp: //scrumguides.org/) e está sob a licença
Attribution ShareAlike da Creative Commons. Mais informações estão disponíveis em http://creativecommons.org/licenses/by-
sa/4.0/legalcode e também estão descritas no formato de resumo http://creativecommons.org/licenses/by-sa/4.0/.

As declarações feitas e as opiniões aqui expressas pertencem exclusivamente à Expertpm e não são compartilhadas ou
representam o ponto de vista do Scrum.org. Este treinamento não constitui um endosso de qualquer produto, serviço ou ponto de
vista. O Scrum.org não faz representações, garantias ou garantias de qualquer tipo, expressas ou implícitas, quanto à integridade,
precisão, confiabilidade, adequação, disponibilidade ou atualidade do conteúdo contido nesta apresentação ou qualquer material
relacionado a esta apresentação. Em nenhum caso a Scrum.org, seus agentes, executivos, funcionários, licenciados ou afiliados
serão responsáveis por
​​ quaisquer danos (incluindo, sem limitação, danos por lucros cessantes, informações comerciais, perda de
informações) decorrentes das informações ou declarações contidos no treinamento. Qualquer confiança depositada em tal conteúdo
é estritamente por sua conta e risco.

2
 As certificações
Precisamos falar sobre isto
Gerenciar projetos torna-se, a cada dia, um processo mais complexo devido aos ambientes cada vez mais
incertos, agravado por mercados que mudam rapidamente buscando novas tecnologias, novas tendências e
novas necessidades para se manter um negócio.

Vários são os desafios a serem vencidos pelos responsáveis por projetos nas empresas dentre eles
podemos destacar:

• Equipes;

• Metodologias;

• Tempo;

• Motivação;

• Recursos Financeiros

• Qualidade, etc... etc... etc...

A aplicação de modelos ágeis em Gestão de Projetos tem ganhado cada vez mais força, o que apenas
comprova a eficiência desses modelos em relação aos modelos tradicionais.

E dentre todos esses sem dúvida algum o Scrum é o mais conhecido e que possui uma série de certificações
disponíveis.

E por que se certificar em Scrum?

Em um momento em que a demanda por competência, preparo e conhecimento nunca foi tão exigente, é
fundamental que o profissional se mostre capaz de cumprir todas as exigências que seu cargo estabelece. Desta
forma possuir uma certificação é fundamental para atestar a aptidão e a credibilidade que a empresa busca.

Além disso, Profissionais certificados em Scrum possuem média salarial de 30% a mais que um profissional
de mesmo nível sem a certificação ou vivência em Scrum;

Mas a dificuldade é que entre tantas certificações, qual é a apropriada para você? Para as pessoas que já
estão empregando métodos ágeis é muito fácil identificar as certificações mais reconhecidas no mercado,
mas esta não é uma tarefa simples para aqueles que acabaram de chegar ao mundo das metodologias ágeis.

Embora não haja uma resposta direta sobre qual certificação é melhor, pois isso depende das preferências
e possibilidades de cada profissional, há certas informações que podem ser analisadas para que se tome a
melhor decisão para cada situação.

As certificações mais populares no universo Ágil e Scrum são:

• Certified Scrum Master (CSM) da Scrum Alliance

• Professional Scrum Master (PSM™) da Scrum.org

3
 • Agile Certified Practitioner (ACP) do PMI

• Agile Scrum Foundation (ASF) do EXIN

• Scrum Fundamentals Certified (SFC) da ScrumStudy.

• Scrum Developer Certified (SDC) da ScrumStudy

• Scrum Master Certified (SMC) da ScrumStudy

Certified Scrum Master

A certificação Certified Scrum Master (CSM) da Scrum Alliance existe desde 2002. Nos seus primeiros 10
anos não havia nenhum exame ou avaliação – bastava uma pessoa participar de um curso de dois dias e se
formava como Scrum Master.

Sempre foi caro participar de treinamentos CSM porque há um número limitado de instrutores
credenciados e este credenciamento é relativamente caro.

A partir de 2012 a Scrum Alliance introduziu um exame, mas continuou mantendo a obrigatoriedade de
que o aluno tenha que fazer o curso com eles.

Atenção! Embora este curso cubra praticamente todos os tópicos da certificaçâo CSM, você é obrigado a
fazer o curso com um representante oficial para que só então possa fazer a prova de certificação CSM.

PSM I™

Em 2010 os criadores do Scrum e fundadores da Scrum Alliance saíram e criaram um organismo alternativo,
a Scrum.org, que passou a oferecer a avaliação Professional Scrum Master I™ (PSM I)™ via internet.

O exame conta com 80 questões e um percentual de no mínimo 85% de acerto para passar. Entre as
certificações pagas é uma das mais baratas e é apoiada por Jeff Sutherland e Ken Schwaber, criadores do
Scrum, no entanto, até o momento, a prova só está disponível em inglês.

PMI-ACP

Em 2011 o PMI, globalmente conhecido por certificações relacionadas a gerenciamento tradicional de

projetos, criou a certificação Agile Certified Practitioner (PMI -ACP) com um currículo bem mais abrangente,
exigindo uma formação mais completa do profissional além do conhecimento sobre o Scrum.

Uma característica diferenciadora do PMI-ACP em relação às demais certificações citadas aqui é que esta
exige registro de experiência profissional para prestar o exame, ou seja, você precisa comprovar que tem pelo
menos 1500 horas de trabalho em times ágeis além de ter feito um curso de pelo 21 horas de preferência
com alguma empresa registrada, mas isso não é obrigatório. A prova é composta por 120 questões a serem
respondidas em 3 horas, está disponível em português e é uma das mais caras.

ASF

O EXIN, um instituto de exames de TI globalmente conhecido criou em 2014 um programa de certificação

em gerenciamento ágil de projetos contendo duas certificações: Agile Scrum Foundation (ASF) e Agile Scrum
Master (ASM).  

4
 A certificação ASF é paga e não exige um curso especifico. Isso quer dizer que você pode fazer a prova
diretamente após comprar o token de acesso. É composta por 40 questões que devem ser respondidas em 60
minutos e está disponível em português. Seu custo é mediano, não é a mais barata, tb não é a mais cara.

Esta certificação dá credenciais especiais para aqueles profissionais que realizam o exame EXIN ASF e
conseguem obter o aproveitamento mínimo, demonstrando serem conhecedores dos conceitos e práticas do
Scrum e das metodologias ágeis, que compreendem também o Kanban, XP, Crystal, DSDM, TDD e FDD.

Já a certificação ASM obriga o aluno a fazer um curso com um representante oficial, além de entregar
estudos de caso elaborados de forma a comprovar se o aspirante a ScrumMaster possui experiência na área.

SFC , SDC, SMC

No mesmo ano em que a EXIN iniciou sua oferta de certificações em métodos ágeis, a ScrumStudy um braço
da VMEdu também iniciou a oferta de várias certificações em Scrum e correlatos.

O grande diferencial da ScrumStudy é que este instituto se preocupou em montar um Framekwork

detalhado que orienta o passo a passo de se implementar o Scrum com sucesso nas empresas. Esse framework,
o Guia SBOK, é oferecido gratuitamente em várias línguas, inclusive em português;

As certificações mais conhecidas da ScrumStudy são:

• SFC – Scrum Fundamentals Certified: é a certificação de porta de entrada para o mundo Scrum e seus
fundamentos. Trata-se de uma certificação gratuita. Sendo assim, é só você se inscrever, fazer a prova e
(sendo aprovado) já terá a sua primeira certificação em Scrum. A prova é composta por 40 questões a
serem respondidas em 60 minutos, e está disponível em português.

• SDC –  Scrum Developer Certified:  esta certificação é indicada para membros da equipe de
desenvolvimento. Não há obrigatoriedade de comprovar experiência. A prova é composta por 75
questões a serem respondidas em 90 minutos e também está disponível em português. Seu custo é
mediano.

• SMC – Scrum Master Certified: esta certificação é a mais indicada para aqueles que desejam exercer o
papel de Scrum Master em equipes Scrum. Não há obrigatoriedade de comprovar experiência. A prova
é composta por 100 questões a serem respondidas em 2 horas, e está disponível em português. Está
entre as mais caras, no entanto ao estudar com um representante oficial, você poderá conseguir bons
descontos.

Bom...acho que já demos uma boa noção das certificações do mercado. Este curso vai te preparar para as
seguintes certificações:

• SFC

• SDC

• SMC

• PSM I™

• ASF

E poderá ser utilizado como material complementar para as certificações:

5
 • ASM

• CSM

• PMI-ACP

E você é ágil?

O quão ágil você é?

Segundo os dicionários o termo ágil é definido como “que se move com facilidade; ligeiro, veloz”.

Esse mesmo termo ágil tem sido usado para identificar uma nova forma de gerenciar projetos. No entanto,
ser ágil neste caso, não está relacionado com rapidez ou velocidade, ou com usar métodos ágeis ou não , ou
ainda conversar mais com o cliente ou se preocupar em elaborar menos documentação.

Ser ágil é eliminar o desperdício. Muitos acreditam que a agilidade deveria trazer, antes de mais nada,
mais velocidade. Mas o que adianta ser rápido e não saber exatamente o que está sendo feito? Dessa forma o
único que se vai conseguir fazer é entregar algo sem nenhum valor de forma mais rápida...

Em resumo,  ser ágil é realizar um caminho apenas uma vez, ou o menor número de vezes possível. É
realizar entregas com qualidade na primeira tentativa e principalmente evitar o desperdício ao invés de
pensar em fazer rápido.

E para os que acham que agilidade é jogar fora todo o planejamento, má noticia:

Para ser ágil é preciso ser assertivo buscando a qualidade mais do que a velocidade, pensando que mais
vale observar, planejar e caminhar com segurança no caminho da realização do seu projeto, do que ir e voltar
em busca de corrigir erros gerados pela correria do dia a dia.

E então? O quão ágil você quer ser?

O modelo cascata
Os modelos tradicionais de gerenciamento de projetos normalmente seguem este processo:

6
 Obviamente, dependendo do modelo tradicional, uma ou outra fase tem seu nome modificado, ou ainda
fases são acrescentadas ou eliminadas. Mas de qualquer forma, o que todos tem em comum é que uma fase só
se inicia após o término da fase anterior.

Esses modelos são também chamados de Cascata ou Waterfall, porque a fase seguinte sempre estará
depois da anterior, e nunca vai voltar para trás como as águas de uma cachoeira. Estes modelos são altamente
preditivos, ou seja, tem foco em planos detalhados definidos no princípio do projeto, como custo, escopo e um
cronograma bem detalhado. Mudanças são geralmente indesejadas.

O modelo cascata tem sido usado ha séculos na construção civil e sempre com resultados muito
satisfatórios. Na construção da minha casa dos sonhos faríamos assim:

• Fase Análise e definição de requisitos: é uma lista com o que quero que essa casa tenha. Então a minha
casa dos sonhos vai ter: no 2oandar 3 suites com banheiras de hidromassagem. No primeiro andar
quero uma cozinha americana e uma sala com portas de correr que se abram para o espaço da piscina
e churrasqueira...legal, né? (sonhar não custa nada)

• Fase Projeto da casa!: aqui são elaboradas as famosas plantas, com todas as medidas e indicações
necessárias para que a construção seja feita sem que ao seu final ela desabe ou se pareça com um
hospital...

• Fase Implementação: esta é a fase da construção. Tá certo, que dá uma dor de cabeça danada ter
que lidar com os pedreiros, porque sempre estão construindo paredes tortas e fora do lugar. Mas se o
projeto for bem acompanhado por um arquiteto ou mestre de obras, é possível que esta fase termine
sem muitos traumas.

• Fase de Testes: aqui já temos praticamente a casa pronta. O que vamos fazer é ver se a água do chuveiro
está escorrendo para o lado do ralo ou para dentro do quarto. Se ao acionar o interruptor a luz vai acender.
Se a porta está encaixando no batente. Etc etc etc. Caso essas pequenas falhas estejam acontecendo,
pequenas correções são realizadas antes de darmos a casa como pronta e entregue.

• Fase Manutenção: este é o dia a dia de morar em uma casa, vai ter que cortar a grama, lavar os quintais,
desentupir calhas e ralos etc etc etc.

Embora tenham evoluído ao longo dos tempos com novas máquinas e equipamentos, projetos de construção
civil existem há eras na história da humanidade e, em linhas gerais, sua forma de execução se manteve a mesma:
uma longa fase de definições e especificações no início que tem como saída um plano, seguida de sua fase de
execução.

Mas e a construção de software? E de produtos inovadores e desrruptivos? O modelo cascata ainda é

válido?

Vamos responder as essas perguntas na próxima aula. Até lá!

O Modelo ágil
Na aula passada vimos como são os modelos tradicionais de gerenciamento de projetos. Bom, e qual é o
grande problema deste tipo de modelo para projetos de software?

Desde quase o começo da história do desenvolvimento de software, a comparação com a construção civil
foi largamente utilizada para descrever esse tipo de projeto. Mas veja que a natureza dos projetos de construção
civil é totalmente distinta da natureza da construção de software.

7
 Em software, normalmente o cliente chega com um desejo, mas não sabe exatamente expressá-lo. Tem
uma ideia na cabeça mas não consegue coloca-la no papel. Isso acontece porque o software é por definição
intangível, ou como diriam os piadistas: o hardware é a parte que vc chuta e o software é a parte que você xinga.

Assim ao usar o modelo cascata no desenvolvimento de software, o cliente só tem a verdadeira do noção
do que pediu bem ao final do projeto. Seria mais ou menos assim: o cliente queria um hospital e recebeu uma
clínica veterinária...ambos são usados para curar doentes, só que um deles é focado apenas em animais...

Para evitar tais frustrações, podemos usar o seguinte ciclo de vida para um projeto de software:

Cada iteração (ou Sprint) entrega uma parte utilizável do software para o cliente e assim ele vai vendo se o
que ele tinha em mente é exatamente o que está sendo construído. Este modelo é o que chamamos de iterativo
e incremental, ou seja, a cada nova iteração entregamos um novo incremento de software.

Mas veja que isto não é a adoção de mini-cascatas em cada iteração! De forma alguma.

O que se tem na verdade é a divisão dos requisitos em partes menores e a entrega dessas partes sendo
feitas a cada nova iteração. Assim, nos métodos ágeis as iterações não são divididas em fases, por exemplo: não
existe a fase análise de requisitos onde todos os requisitos daquela Sprint são definidos.

O que se faz é selecionar um requisito (ou uma parte menor dele), realizar a análise, projeto, implementação
e teste. Nesse meio tempo, outro requisito pode ter sido escolhido e o ciclo (análise, projeto, implementação e
teste) é executado para ele também. E assim se prossegue até o término da iteração.

É como se construíssemos uma suíte por vez, ou seja, indicamos o que queremos que tenha nessa suíte, aí
é elaborada a planta somente dessa suíte, depois a suite é construída, testada e entregue. Na próxima iteração,
passaremos à construção da segunda suíte e assim por diante.

Aqui já deu para perceber que os métodos ágeis não são a melhor forma de construir casas, não é mesmo?
Mas sem dúvida, é o melhor método para construção de projetos que tenham escopo volátil e complexo de ser
definido logo no início.

Os modelos ágeis ou iterativos vem para resolver 3 falhas importantes dos modelos tradicionais:

Os projetos reais construídos em alguns tipos de indústria (como a de software ou de produtos inovadores)
raramente seguem o fluxo sequencial que o modelo prega.

É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O
modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que
existem no inicio dos projetos.

8
 O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para
ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro
grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um
resultado desastroso, ou seja, o cliente se recusará a aceitar e meses de trabalho podem ter que ser jogados
fora.

E então? Ficou claro em que tipos de projetos o modelo ágil é o ideal?

O manifesto ágil
Em fevereiro de 2001, uma reunião nas montanhas nevadas do estado norte-americano de Utah, marcava
o surgimento e propagação do paradigma de desenvolvimento de softwares ágeis. Infelizmente, muitas das
pessoas que estavam dispostas a ir tiveram que se ausentar. No entanto, dezessete pessoas compareceram e
seriam elas que dariam início sem saber ao manifesto ágil.

A primeira parte da reunião se resumiu a encontrar um nome que expressasse bem o significado daquele
movimento, métodos leves deixaram de ser uma opção válida, pois não explanavam o significado desejado.
Após considerar vários nomes decidiram que a palavra “ágil” melhor captava a abordagem proposta.

A segunda parte da reunião foi dedicada à escrita de um documento que desencadearia o manifesto ágil,
nele estaria contido a declaração das crenças e valores que aquelas dezessete pessoas possuíam. Na última
parte e nos meses seguintes os princípios foram trabalhados. O manifesto ágil se tornou um grito de guerra para
a indústria de software e para aquelas dezessete pessoas. Ele consegue expressar claramente o que defende e
o que opõe, deixando bem claro o que é, e o que não é ágil.

O manifesto ágil é dividido em duas partes: os valores ágeis e os princípios ágeis. Veja que o Manifesto
Ágil não é um método ou metodologia de gerenciamento de projetos, mas sim um guia com os princípios e
valores que todo projeto deve seguir.

Nas próximas aulas veremos em detalhes tanto o que são valores como o que são os princípios ágeis.

Os valores Ágeis
E o manifesto ágil começa assim:

Estamos descobrindo maneiras melhores de desenvolver  software  fazendo-o nós mesmos e ajudando
outros a fazê-lo. Por meio deste trabalho, passamos a valorizar:

• Indivíduos e interações mais que processos e ferramentas

• Software em funcionamento mais que documentação abrangente

• Colaboração com o cliente mais que negociação de contratos

• Responder a mudanças mais que seguir um plano

Vamos ver agora como cada valor se desdobra...

Indivíduos e interações mais que processos e ferramentas

Este valor leva em consideração que, em última instância, quem gera produtos e serviços são os indivíduos,
que possuem características únicas. Ou seja, as pessoas em uma equipe são mais importantes do que seus papéis

9
em diagramas de processos. Assim, embora processos possam ser necessários para se começar o trabalho, as
pessoas envolvidas nos processos não podem ser consideradas como simples peças de uma engrenagem.

Bons processos ajudam a equipe ao invés de ditar como seu trabalho deve ser feito, ou seja, são os
processos que devem se adaptar à equipe, e não o contrário.

Software em funcionamento mais que documentação abrangente

Software em funcionamento é o único indicador de que a equipe de fato construiu algo realmente de valor
para o cliente.

Mas não comece a queimar a documentação do seu projeto, pois software em funcionamento não exclui
a necessidade de documentação. Ela pode ser muito útil para o desenvolvimento do projeto, mas deve-se
produzir somente a documentação necessária e suficiente para a realização do trabalho.

Colaboração com o cliente mais que negociação de contratos

No desenvolvimento Ágil não há “nós” e “eles”, há simplesmente “nós”, e isso inclui o cliente do nosso
lado, colaborando para produzir o software que traga valor para eles mesmo. Essa colaboração envolve
companheirismo, tomada de decisão conjunta e rapidez na comunicação, de forma que muitas vezes pode até
tornar adendos a contratos desnecessários.

Responder a mudanças mais que seguir um plano

Todo projeto deve balancear o planejar com o mudar, dependendo do nível de incerteza inerente a ele. Em
projetos onde há alta incerteza, a rapidez e adaptabilidade à mudança deve predominar. Esse conceito se aplica
ao desenvolvimento de software, já que a incerteza é inerente e inevitável em projetos e processos de software.
Construir um plano é útil, mas seguir o plano só é útil até o momento em que ele ainda está próximo o suficiente
da situação atual. Assim, manter-se preso a um plano ultrapassado não funciona em favor do sucesso.

Então não se esqueça dos valores ágeis:

• Indivíduos e interações mais que processos e ferramentas

• Software em funcionamento mais que documentação abrangente

• Colaboração com o cliente mais que negociação de contratos

• Responder a mudanças mais que seguir um plano

Os princípios ágeis
Os doze princípios Ágeis foram cunhados a partir dos valores ágeis que vimos na aula anterior. Então vamos
ver agora cada um deles.

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

O foco no desenvolvimento do produto está na satisfação dos clientes. Gera-se, desde cedo e frequentemente,
retorno ao investimento dos clientes no projeto a partir da entrega de partes do produto que atendam às suas
necessidades. Esse princípio se opõe à prática de se seguir um plano detalhado, sugerindo que a prioridade está
em se adaptar e buscar, em cada momento, o que de fato trará valor aos clientes, para entregar-lhes o mais cedo
e frequentemente possível.
10
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a
mudanças, para que o cliente possa tirar vantagens competitivas.

Devemos aceitar a mudança como natural no processo de desenvolvimento do produto, para melhor
atender às necessidades dos clientes. Ao se trabalhar em ciclos curtos de feedback, permite-se aos clientes
que seu produto evolua à medida que entendem melhor suas necessidades. Esse princípio se opõe a tratar
o processo de desenvolvimento do produto como previsível, onde mudanças são consideradas indesejadas e
custosas.

Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos
períodos mais curtos.

Entregar a seus clientes e usuários, com frequência, partes prontas do produto. Isso demonstra ao cliente
que seu investimento está tendo retorno logo no início do projeto. Além disso, tem-se feedback sobre o que já
foi construído e caso exista algum desvio pode-se adaptar o produto às necessidades dos clientes bem cedo no
projeto, reduzindo os riscos de se entregar algo que o cliente não vá usar. Esse princípio se opõe a realizar uma
única grande entrega apenas ao final do projeto.

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante

todo o curso do projeto.

Pessoas ligadas ao negócio e desenvolvedores possuem um objetivo comum que é garantir a geração de
valor para os clientes. E para atingir esse objetivo, cooperam continuamente durante todo o projeto, interagindo
com frequência. Esse princípio se opõe ao cenário de antagonismo comum em projetos de desenvolvimento
de software, nos quais as pessoas de negócios — que frequentemente incluem os próprios clientes — e os
desenvolvedores raramente se comunicam e, muitas vezes, estão em lados opostos.

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e
confiar que farão seu trabalho.

O produto é construído por pessoas. O ambiente, o suporte e a confiança necessários para realizar seu
trabalho são fatores fundamentais para sua motivação. Esse princípio se opõe à crença de que o produto se
constrói em torno das melhores ferramentas e processos, e não das pessoas.

O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a cara.

A melhor forma de comunicação entre membros do time de desenvolvimento e o mundo externo é a

comunicação cara a cara, que é direta, síncrona e enriquecida pela entonação de voz, olhar e linguagem corporal,
entre outros fatores. Quando a comunicação presencial não é viável (em um projeto distribuído, por exemplo)
é uma boa prática fazer-se o melhor uso possível da tecnologia disponível para se aproximar da comunicação.
Esse princípio se opõe à utilização de documentos, e-mails, telefone e teleconferência, entre outros, como
formas padrão de comunicação em um projeto.

Software funcional é a medida primária de progresso.

O progresso do projeto ocorre à medida que partes do produto que tragam valor ao cliente são entregues.
Esse princípio se opõe à prática de se gerar artefatos como protótipos e extensos documentos de planos e
especificações e, assim, acreditar que se progrediu no projeto.

Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários,

11
devem ser capazes de manter indefinidamente, passos constantes.

Busca-se promover um ritmo constante e sustentável para o trabalho do time que desenvolve o produto,
o que se torna possível quando esse ritmo é apoiado por toda a cadeia, incluindo usuários e patrocinadores.

Veja que ao se exigir do time um compromisso com mais trabalho do que ele é capaz de produzir, são muitas
vezes adotadas as horas extras, o trabalho em fins de semana e a pressa exagerada para se cumprir o prazo de
entrega. Essas práticas podem levar à insatisfação dos membros do time de desenvolvimento, a uma menor
produtividade e a uma menor qualidade no produto gerado.

Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

O produto projetado com qualidade e produzido com excelência técnica permite que seja facilmente
modificado e, assim, aceite a mudança como natural no processo de seu desenvolvimento. Dessa forma, a alta
qualidade no produto gerado é essencial para se manter a Agilidade. Esse princípio se opõe à crença de que,
para se obter velocidade e flexibilidade no desenvolvimento do produto, a qualidade deveria ser sacrificada.

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Evita-se o desperdício no desenvolvimento do produto ao não se realizar trabalho que não é necessário.
Exemplos comuns de desperdícios incluem desenvolvimento de funcionalidades de que os clientes não precisam
ou de soluções desnecessariamente complexas, planejamento com nível de detalhamento maior do que o
necessário e a geração de artefatos supérfluos.

As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

Equipes com maior autonomia são mais eficientes. Essas equipes auto-organizadas trabalham em direção
a metas acordadas, mas têm a liberdade de decidir qual a melhor forma de realizar esse trabalho e, assim, são
responsáveis e responsabilizadas por seus resultados. Dessa forma, geram um melhor produto.

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu
comportamento de acordo.

Para se tornar cada vez mais efetiva, a equipe regularmente inspeciona suas formas de trabalho, identifica
pontos de melhoria e se adapta de acordo, promovendo a melhoria contínua.

12
 Breve Introdução ao Scrum
De onde surgiu
Em meados dos anos 80, Hirotaka Takeuchi e Nonaka Ikujiro, definiram uma estratégia flexível e completa
para o desenvolvimento de produtos, onde o time de desenvolvimento trabalha como uma unidade, para
alcançar um objetivo comum.

Eles descreveram uma abordagem inovadora para o desenvolvimento de Produtos que chamaram de
abordagem holística ou “rugby”, onde um time tenta percorrer uma determinada distância como uma só
unidade, passando a bola não só para a frente como também para trás.

Para nós brasileiros essa definição pode não ser muito clara, mas é similar a um time de futebol, onde
todos os jogadores devem juntos atingir uma meta passando a bola tanto para a frente quanto para trás
(quando necessário).

O termo Scrum vem de um movimento especifico do rugby, que é a formação de 8 jogadores para
reiniciar o jogo após uma falta.

Takeuchi e Nonaka propõem que o desenvolvimento do produto não deve ser como uma sequência de
corrida de revezamento onde somente um corredor corre por vez, mas sim semelhante ao jogo de rugby em
que o time trabalha em conjunto, passando a bola para frente e para trás movendo- se através do campo
como uma unidade. Eles basearam esta abordagem em estudos de caso de diversas indústrias.

Já na década de 90, Ken Schwaber e Jeff Sutherland desenvolveram o conceito do Scrum e sua
aplicabilidade para o desenvolvimento de software.

Desde então, vários profissionais, especialistas e autores do Scrum continuam a refinar o conceito e a
metodologia do Scrum. Nos últimos anos, o Scrum tem crescido em popularidade e é agora o método de
desenvolvimento de projetos preferido por muitas organizações, no mundo inteiro.

Os Pilares do Scrum
O Scrum controla processos empíricos empregando uma abordagem iterativa e incremental para otimizar
a previsibilidade e o controle de riscos. Para a implementação de qualquer controle de processos empíricos são
necessários os seguintes três pilares de sustentação:

Transparência
Garante que os aspectos do processo que afetam o resultado devem ser visíveis e conhecidos aos que
controlam o resultado, ou seja, quando alguém inspeciona o resultado e dá como pronto, isto deve ser
equivalente à definição de pronto utilizada por quem o construiu, reforçando com isso a necessidade de um
padrão comum compartilhado por todos os observadores.

Inspeção
Os processos devem ser totalmente inspecionados com uma frequência suficiente para que as variações
possam ser detectadas, considerando que o processo pode ser modificado pelo próprio ato de inspecionar.

Um ponto importante que deve ser mencionado é que a inspeção não deve ser tão frequente a ponto de
atrapalhar a própria execução. Ela pode ser mais benéfica se aplicada por inspetores especializados.
13
Adaptação
Se durante a inspeção for determinada uma variação fora dos limites aceitáveis em um ou mais aspectos
do processo e que o resultado será inaceitável, o processo ou o material produzido deverá ser ajustado o mais
rápido possível para que os desvios futuros sejam minimizados.

A primeira sugestão é que qualquer ajuste necessário seja realizado o mais breve possível para minimizar
o impacto dos desvios. Para contribuir com ações de inspeção e adaptação, o Scrum possui quatro eventos
formais, que veremos em detalhes nas próximas aulas:

• Reunião de planejamento da Sprint;

• Reunião diária;

• Reunião de revisão da Sprint;

• Reunião de retrospectiva da Sprint.

O ciclo Scrum
Scrum é um framework para desenvolver e sustentar projetos complexos. É a metodologia Ágil mais popular
de gerenciamento de projetos e de desenvolvimento de produtos.

Um projeto Scrum envolve um esforço de colaboração para criar um novo produto, serviço ou qualquer
outro resultado, conforme definido em um documento chamado Declaração da Visão do Projeto.

Os projetos são afetados pelas restrições de tempo, custo escopo, qualidade, recursos, capacidade de
organização e outras limitações que os tornam difíceis de planejar, executar, gerenciar e, finalmente, de
alcançar o sucesso.

Portanto, é importante que as organizações selecionem e coloquem em prática um framework de

gerenciamento de projetos adequado ao seu negócio. É aí que entra o Scrum.

O Scrum garante a transparência na comunicação e Cria um ambiente de responsabilidade coletiva e

progresso contínuo.

Neste ponto, você deve estar se perguntando: porque o Scrum é a melhor técnica de gerenciamento de
projetos?

Um dos pontos fortes do Scrum está na utilização de times multifuncionais, auto-organizados e

empoderados, que dividem o trabalho em ciclos curtos e concentrados chamados Sprints.

Pense em Sprints como sendo curtos intervalos de tempo em que uma certa quantidade de
trabalho tem de ser feito.

14
 Observe o diagrama que representa o ciclo do Scrum.

O ciclo inicia na fase pré-sprint, onde as partes interessadas se reúnem e criam a Declaração de Visão que
contém as metas e ideias que o projeto a ser desenvolvido deverá entregar.

Em seguida o Roadmap do produto é desenvolvido. O roadmap é uma representação gráfica das entregas
parciais ao longo de uma linha do tempo. O dono do produto normalmente é quem desenvolve este item.

O Roadmap do produto gera o Backlog do produto. Veja que o backlog é composto por várias histórias de
usuário e estas são normalmente escritas pelo Dono do Produto a partir de informações fornecidas pelo cliente
e partes interessadas.

Uma diferença primordial entre o Scrum e os métodos tradicionais é que no Scrum não há necessidade
de todas as histórias estarem 100% definidas. As Sprints podem começar a partir do momento que o backlog
do produto já tiver um nível de maturidade suficiente, ou seja, que parte das histórias de usuário já estejam
definidas. E claro, o backlog do produto é um documento vivo, sendo atualizado durante todo o projeto.

Agora, com o backlog do produto desenvolvido, começa a fase das Sprints

Cada Sprint começa com uma Reunião de Planejamento, durante a qual as Histórias de Usuário de alta
prioridade são escolhidas para serem executadas nessa Sprint. Essas histórias entram então no backlog da Sprint.

O time divide essas histórias em tarefas menores e mais facilmente gerenciáveis. Uma Sprint normalmente
dura entre duas e quatro semanas e envolve o time Scrum trabalhando para criar entregas potencialmente
utilizáveis ou melhorias de produtos.

15
 Durante a Sprint, são realizadas Reuniões Diárias de 15 minutos altamente focadas onde os membros do
time discutem o progresso diário.

Perto do final da Sprint, uma Reunião de Revisão do Sprint é realizada, na qual o Dono do Produto e os
Stakeholders recebem uma demonstração dos entregáveis. O Dono do Produto apenas aceita os entregáveis se
os mesmos cumprirem os Critérios de Aceitação pré-definidos.

O ciclo da Sprint termina com uma Reunião de Retrospectiva da Sprint, onde o time apresenta maneiras
de melhorar os seus processos e o seu desempenho à medida que avançam para a próxima Sprint. E um novo
ciclo se inicia.

Processo de planejamento iterativo

No Scrum os produtos são construídos iterativamente, começando pelo de maior valor e maior risco, de
modo que a cada Sprint se tenha um incremento do produto.

Cada Sprint concluída adiciona incrementos ao produto, e cada incremento é um pedaço potencial para
a entrega do produto completo. Quando são obtidos incrementos suficientes para que o produto tenha valor
e uso para seus investidores, o produto está pronto para a entrega.

O objetivo principal é realizar um planejamento inicial mais breve e, no momento da execução de cada
reunião de revisão e planejamento de Sprint, bem como também durante as reuniões diárias, serem realizados
planejamentos complementares.

Não pense que o Scrum tem pouco planejamento, ou que requer menos esforço que o planejamento
tradicional. Na verdade, normalmente o esforço com planejamento no Scrum é ligeiramente maior do que no
método tradicional. A diferença é que o planejamento também é iterativo e incremental.

Esta é uma característica que diferencia o Scrum do modelo tradicional mais conhecido, que geralmente
realiza todo o planejamento da versão no início do trabalho, e este não é modificado ao longo do tempo.

16
 Papéis e responsabilidades
Time Scrum
Para que o framework Scrum funcione, todos os envolvidos no projeto assumem papéis e responsabilidades
diretamente ligados à sua função no projeto. E é isto o que veremos nesta aula.

Um time Scrum é composto por 3 papeis, nem mais nem menos. Assim ao adotarmos o Scrum estamos
proibidos de inventar novos papeis pois estaremos ferindo a unidade do time além de ser totalmente
incompatível com a filosofia Scrum.

Assim, o time Scrum é composto por:

• Dono do produto: é uma pessoa (isso mesmo, somente um integrante) que pode estar envolvido em
tempo parcial ou integral e é totalmente orientado a negócios. Não é um líder técnico.

• Scrum Master: é uma pessoa (isso mesmo, somente um integrante) que pode estar envolvido em
tempo parcial ou integral e é um especialista nas práticas do Scrum. Não é um líder técnico.

• Time de desenvolvimento: composto por 3 a 9 integrantes, de preferência em tempo integral e que

são especialistas técnicos.

Dessa forma, o tamanho ideal de um Time Scrum é entre 5 a 11 participantes, ou seja, grande o suficiente
para garantir que sejam adquiridos os conjuntos de habilidades adequadas, mas pequeno o suficiente para
facilitar a colaboração.

Entre os principais benefícios de se formar times desse tamanho, estão a comunicação e o gerenciamento,
que ocorrem normalmente de forma simples e requerem esforços mínimos.

Já que o Scrum favorece pequenos grupos, pode-se pensar que este método só pode ser utilizado em
pequenos projetos, mas este não é o caso. O Scrum também pode ser utilizado de forma eficaz em projetos de
grande escala. Quando mais de nove integrantes do time de desenvolvimento são necessários para realizar o
trabalho, vários Times Scrum podem ser formados.

A coordenação e comunicação entre os diversos Times Scrum geralmente ocorre de várias maneiras, no
entanto, a abordagem mais comum é conhecida como Reunião do Scrum de Scrums (SOS) onde representantes
de cada time se reúnem para trocar informações a respeito de seus projetos.

E antes de encerrarmos a aula, fique atento para não confundir o time Scrum com o time de
desenvolvimento!

O time Scrum é composto pelo dono do produto, Scrum master e time de desenvolvimento.

Scrum Master
o Scrum Master é um facilitador e deve garantir ao Time Scrum o fornecimento de um ambiente propício
para concluir o projeto com sucesso. O Scrum Master guia, facilita e ensina as práticas do Scrum para todos os
envolvidos no projeto; remove os impedimentos encontrados pelo time; e, assegura que os processos do Scrum
estejam sendo seguidos.

Vamos a um exemplo.

17
 Considere a empresa ABC. Sua equipe de desenvolvimento de software está enfrentando obstáculos no
desenvolvimento de seu novo sistema ERP. A causa disso, ao que parece, é que eles são incapazes de trabalhar
de acordo com as normas estabelecidas de um projeto de qualidade. Então, qual é a maior dificuldade? É a
falta de conhecimento necessário para o desenvolvimento de um projeto de qualidade. E isso leva a atrasos
e entregas que o cliente se recusa a aceitar.

É aqui que o Scrum Master entra, verificando quais os impedimentos que bloqueiam a equipe de produzir
entregas aceitáveis. Assim, ele vai verificar se há necessidade de contratar novos desenvolvedores com a
experiência necessária ou se deve treinar a equipe já existente.

Em resumo, é dele a responsabilidade de guiar a equipe nas melhores práticas do SCRUM e remover os
impedimentos que essa equipe estiver enfrentando. Mas veja, que NÃO é responsabilidade do Scrum Master
gerenciar a equipe.

Veja que o Scrum defende que durante as Sprints, o Time está sozinho, se auto-organizando e executando
suas tarefas.

Assim, não há um gerente ou um coordenador para controlá-los dentro de campo, mas há um coach, ou
seja, um técnico que é justamente o Scrum Master que pode lá de fora do campo alertar sobre regras não
cumpridas e jogadas mal feitas.

Além disso o Scrum Master pode ajudar das seguintes formas:

• Encontrar técnicas para um melhor gerenciamento do backlog do produto.

• Intermediar uma comunicação entre o Time de desenvolvimento e o Dono do Produto, contribuindo

para um claro entendimento da visão, do objetivo e dos itens do backlog.

• Ensinar o Time de Desenvolvimento a criar itens de backlog de forma clara e concisa.

• Compreender e praticar a agilidade.

• Você sabia que o Scrum Master pode trabalhar servindo a organização de várias maneiras? O Scrum
Master pode:

• Liderar e treinar a organização na adoção do Scrum.

• Planejar implementações de Scrum dentro da organização.

• Ajudar todos os colaboradores a compreender e aplicar o Scrum.

• Provocar mudanças que aumentem a produtividade.

• Trabalhar com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum.

Assim, é possível dizer que o Scrum Master é o papel mais importante do Scrum. A responsabilidade pelo
sucesso na aplicação do Scrum não é exclusiva do Scrum Master. Contudo um Time de Desenvolvimento e
um Dono do Produto inexperientes, aliados a um Scrum Master inexperiente, é fracasso certo – ou no mínimo
as chances de não ter sucesso são enormes.

Já com um Time de Desenvolvimento e um Dono de Produto inexperientes guiados por um Scrum Master
experiente, com boa bagagem prática em projetos ágeis e com vivência real em projetos utilizando o Scrum,
as chances de atingir o sucesso se tornam bem maiores.

18
 Muitas vezes se defende que o Scrum Master deve ser um membro do time de desenvolvimento, e embora
isso não seja proibido, isso pode levar a conflitos quando ele precisar escolher entre realizar uma tarefa para
não perder o prazo ou remover um impedimento de outro membro do time.

O Scrum Master nunca deve ser o Dono do Produto, pois esses papéis são totalmente diferentes e podem
gerar conflitos na realização das tarefas.

Dono do Produto
O Dono do Produto é o Responsável por alcançar o maior valor de negócio para o projeto, e também
responsável pela coordenação das necessidades dos clientes. Ele é responsável por garantir uma comunicação
clara com o Time Scrum, sobre requisitos de funcionalidade do produto ou serviço, definindo os Critérios de
Aceitação, e garantindo o cumprimento desses critérios. Em outras palavras, o Dono do Produto é responsável
por garantir que o Time Scrum entregue valor.

Nenhuma outra pessoa além do Dono do Produto tem a permissão para falar com o Time de
Desenvolvimento sobre mudanças de prioridades, nem mesmo o próprio time de desenvolvimento.

Veja que a qualidade técnica ou funcionamento perfeito de um sistema ou produto de qualquer natureza
é de responsabilidade do Time de Desenvolvimento, mas se este desenvolveu um sistema tecnicamente
perfeito, mas que não atende às necessidades do negócio do cliente, a responsabilidade é do Dono do
Produto.

O Dono do Produto é responsável por:

• Maximizar o valor do produto e do trabalho do time de desenvolvimento, gerenciando o backlog do

produto.

• Expressar claramente os itens do backlog do produto seguindo uma importância para alcançar as
metas esperadas pelo cliente.

• Garantir o valor do trabalho realizado pelo time de desenvolvimento

• Garantir que todo o backlog do produto seja visível, transparente e claro para todos os interessados,
mostrando o que o time Scrum deve buscar.

• Garantir que o time de desenvolvimento entenda os itens do backlog do produto para que este seja
corretamente construído.

Atenção!!!

O Dono do produto pode ser um analista de negócios, um gerente de produto, um usuário final do
cliente ou um membro do time, mas neste último caso poderão acontecer conflitos de papéis em momento
de decisão, priorizac’ão e definição de valor a ser entregue.

E como já dissemos na aula anterior, o Dono do produto e o ScrumMaster não devem ser a mesma pessoa.

Time de desenvolvimento
Já vimos o que faz um Scrum Master e o Dono do Produto. Então, nesta aula veremos o último deles que
é o time de desenvolvimento.

19
 O Time de Desenvolvimento é o responsável pelo desenvolvimento do produto, serviço ou de outro
resultado. Trata-se de um grupo de indivíduos que trabalham nas Histórias de Usuário do Backlog do Sprint
para criar as entregas para o projeto.

Esse time deve ser cross-funcional, ou seja, capaz de ir de A a Z para entregar cada um dos itens do
backlog.

Devem ainda ser auto-organizados sem a necessidade de receber ordens de outros. Eles devem ter uma
visão muito clara das metas do projeto.

Embora uma tarefa seja designada para um membro do time, será o time como um todo o responsável
pela entrega dessa tarefa. Não há trabalho individual. Todos colaboram com o projeto.

É altamente recomendável que os membros do time de desenvolvimento trabalhem em tempo integral

em um único projeto, para se manterem focados e ágeis. A composição do time não deve ser alterada com
muita frequência. Se houver a necessidade de se trocar um membro, ele não deve ser retirado durante uma
Sprint em andamento. E obviamente, uma troca sempre acarreta em queda de produtividade temporária.

O Scrum é mais efetivo quando o time de desenvolvimento tem entre 3 e 9 membros.

Já que o Scrum favorece pequenos grupos, pode-se pensar que este método só pode ser utilizado
em pequenos projetos, e como já vimos, este não é o caso. Vários times Scrum podem ser formados e a
coordenação e comunicação entre os eles geralmente ocorre na Reunião do Scrum de Scrums.

Um fato interessante é que em um time Scrum, deve-se evitar especificar o papel de cada um, tal como:
designer, desenvolvedor, tester, líder etc. O Scrum não recomenda isso. Todos os membros devem ter um
único papel: Membro do time Scrum (mas isso não quer dizer que todos devam exercer exatamente a mesma
função, o tester vai continuar exercendo sua função de tester, ok?)

Você sabia que apenas o Time de Desenvolvimento cria incrementos para o produto?

E onde fica o GP?

Bom...e então, onde o GP se encaixa aqui?

A resposta é bem simples: NÃO existe esse papel no Scrum. E nenhum dos 3 papéis atua como um gerente
de projetos tradicional.

Algumas pessoas consideram que o Scrum Master é o equivalente a um gerente de projetos tradicional,
mas isso não é verdade, porque as responsabilidades são muito diferentes daquelas de um gerente de
projetos tradicional. Scrum Masters não são responsáveis pelo planejamento, por exemplo.

Outros consideram que o Dono do Produto é o equivalente ao gerente de projetos tradicional o que
também não é correto. Mesmo sendo responsáveis por partes do planejamento e monitoramento, por
exemplo, uma parte dessas atividades também são realizadas pelo time de desenvolvimento. Além disso,
o gerenciamento da aplicação do framework que seria uma responsabilidade de um gerente de projetos, é
realizado pelo Scrum Master.

Então, pelo jeito a pergunta deveria ser: o que acontece com o gerenciamento do projeto e não onde fica
o gerente de projetos.

As responsabilidades do gerenciamento do projeto ficam então distribuídas entre esses três papéis e não
há nenhum gerenciamento centralizado de projetos no Scrum.
20
Porcos e Galinhas
Este é um nome bem curioso para uma aula, não é mesmo? Bom, mas vamos lá...

Um ponto muito curioso no Scrum é a divisão de papéis em dois grupos: porcos e galinhas.

Pra quem não conhece, pode parecer meio estranho já que no Brasil esses animais geralmente são
utilizados com uma conotação negativa. Mas o Scrum se baseia neste exemplo, bastante popular nos Estados
Unidos e não há conotação negativa. A questão gira em torno do comprometimento.

Na tirinha, o porco está altamente comprometido com o negócio, com “a própria carne”. Já a galinha está
comprometida apenas em fornecer os ovos.

Os papeis centrais (ou essenciais, ou ainda os porcos) são aqueles obrigatoriamente necessários para
o desenvolvimento do produto ou serviço do projeto. As pessoas a que estes papéis são atribuídos estão
totalmente comprometidas com o projeto e são responsáveis pelo sucesso de cada iteração, e do projeto
como um todo.

Já os papeis não-essenciais, ou galinhas,  são  os  envolvidos, que não estão necessariamente dispostos a
“fazer de tudo” pelo projeto. São todas as demais pessoas que não estão no dia-a-dia do projeto, incluindo
usuários, gerentes, em alguns casos infra, etc.

Há ainda a referência aos pombos, que são aqueles que quando entram em um projeto, só servem para
fazer sujeira e sair voando...mas essa já é outra história...

21
 Artefatos

Dentro do framework Scrum alguns documentos são essenciais para que o trabalho consiga ser realizado
com sucesso. A documentação e outros elementos gráficos utilizados ao longo de um projeto Scrum são
denominados artefatos, e eles são especificamente projetados para maximizar a transparência das informações
chave necessárias para assegurar que o Time Scrum tenha sucesso nas entregas do projeto.

Existem vários artefatos no Scrum:

• Visão do produto

• Backlog do produto

• Backlog da Sprint

• Incremento

• Histórias de usuário

• Definição de pronto

• Quadro de tarefas (Scrum Task Board)

• BurnDown Chart

O Backlog e o incremento são os únicos artefatos considerados oficiais, pois constam do Manual Scrum.
Os demais, embora não-oficiais são adotados por praticamente todos os praticantes do Scrum.

Visão do Produto
A visão do produto descreve de maneira clara e objetiva a meta da fase e suas principais realizações. Cada
fase do projeto deverá ter uma meta que compreende e deve atender completamente ao produto descrito.

Essa visão do produto da fase deve dar ao Dono do Produto as informações necessárias sobre em que
requisitos ele deverá trabalhar ao longo da fase elicitar, definir e fornecer todo o escopo detalhado de que o
Time precisa para completar o produto da fase.

A visão pode ser descrita e entregue diretamente pelo cliente ao Dono do Produto, para que este inicie
os trabalhos da fase, ou o Dono do Produto e o cliente descrevem esta visão juntos, já iniciando a fase do
projeto. Geralmente essa segunda alternativa é mais comum e acaba funcionando bem, pois o Dono do
Produto consegue entender melhor os valores que o cliente espera para o produto.

Com a visão do produto determinada e entendida, o Dono do Produto poderá iniciar os trabalhos no
Backlog do Produto na sua totalidade (para um projeto com apenas uma fase) ou apenas para as partes do
produto que compreendem a fase em questão.

A visão do produto deve fornecer informação suficiente para o time a respeito da meta da fase e o que
será entregue no final das realizações.

Sem a visão do produto determinada e entendida, um time fatalmente investirá esforços em atividades

22
que não são claras e que não levarão ao objetivo esperado pelo cliente e não trará resultados positivos.

Backlog do Produto / Sprint

O backlog é uma origem única dos requisitos do produto que precisam ser entregues, bem como todo o
entendimento necessário para se atender a esses requisitos, produzir funcionalidades e por fim entregar em
produto completo, incluindo mudanças e evoluções em produtos já existentes.

O backlog é uma lista ordenada de itens a fazer, composta por todas as características, funções, tecnologias,
melhorias e correções que constituem a versão futura de um produto.

O Dono do produto é o responsável por manter todo o backlog do produto, principalmente porque este
é um documento vivo e nunca estará completo, evoluindo à medida que o produto e o ambiente em que ele
será utilizado se desenvolvem.

Uma das características mais marcantes do backlog é ser dinâmico. Ele está constantemente mudando
para identificar o que produto precisa para ser apropriado, competitivo e útil. Por isso, é possível afirmar que
enquanto existir um produto, o backlog deste produto também existirá.

Assim, o backlog de um produto raramente está completo. Ao iniciar o desenvolvimento dos primeiros
incrementos do produto, estarão estabelecidos apenas os requisitos inicialmente conhecidos e mais bem
compreendidos.

O único responsável pelo backlog do produto é o Dono do produto, sendo que é possível existir mais de
um Dono do Produto para o mesmo backlog do produto, desde que para partes diferentes deste backlog.

Backlog da Sprint
O Sprint Backlog corresponde à lista de tarefas que o time do projeto define para implementar na Sprint
os requisitos selecionados do Backlog do Produto. Todo o conteúdo do Backlog da Sprint deve estar contido
dentro do Backlog do Produto, e as primeiras Sprints devem conter sempre os itens do Backlog mais prioritários
e críticos para o sucesso do produto.

Incremento
Um incremento é uma parte potencialmente utilizável do produto final. Ou seja, o incremento é a soma
de todos os itens do Backlog do Produto completados durante a sprint somado aos incrementos entregues nas
Sprints anteriores.

A medida que o tempo vai passando, esse incremento vai aumentando, até que ao final do projeto, temos
o produto finalizado. Se formos pensar na forma tradicional de gerenciamento de projetos, um incremento
nada mais é que uma nova versão do produto com novas funcionalidades acrescentadas. Veja que não há
obrigatoriedade de um incremento ser utilizável pelo cliente, pois em alguns casos, a Sprint pode focar em
requisitos não funcionais (tais como segurança e performance) e nesse caso o cliente não teria como utilizar
esse incremento. É por isso que dizemos que um incremento é uma parte potencialmente utilizável...

Histórias de Usuário
Uma história de usuário é uma descrição resumida, porém clara e objetiva, de alguma funcionalidade que
deverá ser fornecida pelo produto a ser entregue, sempre do ponto de vista do usuário final. Uma história
não é uma especificação completa da funcionalidade, mas uma promessa de discutir uma funcionalidade, ou,

23
simplesmente, um lembrete de que a discussão aconteceu.

As histórias devem possuir uma descrição curta e objetiva, para que caibam em um post-it. Um modelo
simples de como escrever uma história seria:

“Como um <tipo de usuário>, eu quero <um objetivo> para que <atenda a uma necessidade>.”

Épicos
Algumas histórias ficam tão abrangentes que costumamos chama-las de épicos. Devemos sempre quebrar
épicos em histórias de maneiras que elas possam ser “digeridas” pelo time que vai implementá-la. Não existe
uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda bastante. Algumas dicas nesse
sentido são:

• Se não cabe em uma Spritn, é um épico;

• Se consigo quebrar em dois ou mais story cards, é um épico;

• Se no Planning Poker gerou muita divergência de pontuações é um épico

Definição de pronto
Uma Definição de Pronto (Definition of Done, no original) é um artefato  Scrum usado para garantir a
qualidade do produto desenvolvido a cada iteração (Sprint). Um documento, um contrato entre os membros
do Time Scrum e demais envolvidos para que todos entendam o que um produto “pronto” (done) significa.

A definição de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das
entregas. Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há
um elemento de software envolvido, lhe cobrando diariamente que cumpra os requisitos.

Os critérios que são usados para considerar um item Pronto geralmente podem incluir:

• Avaliação da funcionalidade por outros membros do time

• Conclusão do teste unitário

• Conclusão de testes de qualidade

• Conclusão de toda a documentação relacionada com a História de Usuário

• Demonstração bem sucedida para os stakeholders e/ou representantes do negócio

Todas as condições da Definição de Pronto devem ser satisfeitas, para que a História de Usuário seja
considerada Pronta.

O Time Scrum deve utilizar um checklist com os Critérios gerais de Pronto para garantir que uma tarefa
foi concluída e que o resultado atende a Definição de Pronto.

Por isso, uma definição clara de Pronto é fundamental, pois ajuda a eliminar a ambiguidade e permite ao
time aderir aos padrões de qualidade exigidos.

Uma História de Usuário é considerada Pronta, após ser demonstrada e aprovada pelo Dono do Produto,
que a julga com base nos Critérios de Pronto e nos Critérios de Aceitação da História de Usuário.

24
 Exemplo de critérios de pronto:

• O design FOI aprovado pelo especialista em usabilidade

• A funcionalidade passou por todos os testes mandatórios

• Os helps foram disponibilizados

Gráfico de Burndown
O gráfico de Burndown representa visualmente a soma das estimativas dos esforços restantes do Backlog,
permitindo também uma comparação com os atuais trabalhos realizados. Pode ser dividido em:

Burndown do produto: registra a soma dos esforços restantes do Backlog do Produto ao longo do tempo.
O esforço estimado pode estar em qualquer unidade de medida que o Time entenda, mas geralmente para o
Burndown do Produto a unidade de medida são Sprints.

Burndown da Sprint: representa a quantidade restante de trabalho do Backlog da Sprint, ao longo dos dias
de duração da Sprint. O esforço estimado pode estar em qualquer unidade de medida que o Time entenda,
mas geralmente para o Burndown da Sprint a unidade de medida são Horas.

Neste gráfico são mostradas duas linhas. A linha reta indica a quantidade de itens que estão previstos
serem entregues na Sprint. Já a linha azul indica o que efetivamente está sendo entregue.

Começamos, então no 1º dia (de um período de 10), com 55 itens a serem entregues e ao final do 10º dia
(segundo a previsão) precisaremos ter entregue tudo.

Em um projeto a linha de entregas efetivas (azul) não casa exatamente com a linha reta (rosa) e isso é
perfeitamente normal e esperado. O que o time deve procurar fazer é chegar ao final do período atingindo a
meta que é entregar o previsto.

Scrum Board ou ScrumTask Board

O ScrumBoard é um quadro onde o Time coloca as tarefas do Backlog, em post-its, de uma forma organizada
e ordenada. O objetivo é para que visualmente se entenda rapidamente e claramente como o trabalho está.

O funcionamento desse quadro é bem simples.

Do lado esquerdo temos as histórias de usuário que compõem o backlog da Sprint que serão trabalhadas na
Sprint. Essas histórias são divididas em tarefas que ficam inicialmente na coluna a fazer.

Assim que um membro pega essa tarefa para trabalhar, ela deve passar da columa A Fazer para Em
andamento. Veja que o membro que pegar a tarefa para executá-la tem a obrigação de movê-la para a coluna
seguinte.

Ao terminar o desenvolvimento, a tarefa é passada então para a coluna em testes. E ao se finalizarem os

testes, a tarefa vai para a coluna Pronto, a espera da sua aceitação pelo dono do produto na cerimônia de
Revisão da Sprint.

25
 Eventos
Time boxing
O time boxing é um conceito essencial nos métodos ágeis, e que ele consiste em uma duração de tempo
pré-determinada. Nesta aula vamos ver as vantagens da sua aplicação em projetos Scrum.

“Time-Box” na tradução literal significa “caixa de tempo”. Ou seja, é ter o tempo limitado para fazer um
determinado trabalho, tentando cumprir o máximo possível dentro dessa janela de tempo.

Todo evento time-box tem uma duração máxima pré-definida, ou seja, nunca devemos estender a
duração de um evento time-box por que não conseguimos finalizar o planejado. Devemos nos adaptar ao
time-box para finalizar tudo dentro do prazo estipulado, e se isso não for possível, devemos abandonar as
atividades de menor importância. Existem dois tipos de time-boxing:

Duração fixa: neste caso, o evento tem uma duração fixa de tempo. Se todo o trabalho previsto foi
finalizado, o evento não é encerrado. O que se faz é adicionar mais trabalho até que o time-box se encerre. As
Sprints são por natureza de Duração fixa como veremos em uma próxima aula.

Duração máxima: neste caso, o evento tem uma duração máxima e se todo o trabalho previsto foi
finalizado o evento é então encerrado. Usualmente as reuniões de planejamento e de revisão são deste tipo
como veremos tb em uma próxima aula.

Algumas das vantagens em se utilizar o conceito de time-box são:

Reuniões mais focadas e objetivas, conforme o assunto a ser trabalhado, ou seja, já que tem hora para
acabar, os participantes não ficam divagando ou comentando como foi o episódio do Big Brother do dia
anterior...

A equipe tem melhor noção da velocidade de trabalho e de quantos itens do backlog serão possíveis de
se entregar em cada Sprint, já que cada Sprint tem uma duração fixa

• Equipe mais focada nos itens a serem entregues, já que existe um prazo bem definido

• Eliminação do desperdício de tempo, pq existe um prazo bem definido

• Valorização do tempo de trabalho da equipe, não se gasta tempo com reuniões intermináveis.

• Dedicação exclusiva para a atividade dentro do time-box, ou seja, o prazo determinado evita que
outras atividades extra-projeto sejam absorvidas pela equipe.

Sala de guerra
Os eventos Scrum são ferramentas de comunicação. E por conta disso é extremamente importante que se
tenha um ambiente adequado para a realização desses eventos. E nesta aula vamos ver como escolher o local
ideal.

No Scrum, é altamente recomendável que o time esteja localizado em um mesmo ambiente de trabalho. O
termo comumente usado para descrever esse lugar é Sala de Guerra ou War Room. Normalmente, esse local é
projetado de tal forma, que os membros do time possam circular livremente, trabalhar e comunicar-se facilmente.

26
 Esta sala muitas vezes é barulhenta devido a conversas do time, porém essas conversas contribuem para o
progresso do projeto e do próprio time. Esse aparente “barulho” é o que chamamos de comunicação osmótica,
pois se temos 2 integrantes do time conversando sobre um determinado problema, outro membro pode ouvir a
conversa e ajudar na solução ou ainda aprender coisas novas só de ouvi-los...ou seja...aprender por osmose, como
se diz popularmente...

Uma boa Sala de Guerra não deve possuir divisórias e deve permitir que o time se sente junto para garantir a
comunicação cara-a-cara.

Embora seja altamente recomendável que os times Scrum estejam trabalhando todos no mesmo local, nem
sempre isso é possível. Em grandes projetos, podemos ter membros e distribuídos em várias cidades e até mesmo
países. Mesmo assim, ainda é possível usar o Scrum. Mas neste caso devemos fazer o melhor uso possível das
ferramentas de comunicação atuais para facilitar a interação entre todos os membros. O uso de ferramentas de
vídeo-chamada tais como Skype, Hangout e outras podem e devem ser utilizadas.

Sprint
Um projeto Scrum é composto por diversas Sprints. Nesta aula veremos esse evento em detalhes.

Um projeto Scrum realiza entregas parciais do produto em uma série de iterações que são chamadas
Sprints. Cada uma dessas Sprints gera um novo incremento para esse produto.

Um incremento é uma parte potencialmente utilizável do produto final. Ou seja, o incremento é a soma
de todos os itens do Backlog do Produto completados durante a sprint somado aos incrementos entregues
nas Sprints anteriores.

Usualmente o cliente solicita alterações ao ver o incremento entregue pela Sprint (durante a reunião de
revisão da Sprint que veremos em breve). E neste caso, essas solicitações devem ir para o Backlog do Produto.

A Sprint é um evento time-boxed iterativo de duração fixa, ou seja, sua duração deve ser estabelecida no
inicio do projeto e dentro do possível não deve ser alterada. Normalmente as Sprints tem duração de até 4
semanas e possuem uma meta estabelecida, ou sejam seu principal objetivo é realizar entregas parciais de
funcionalidades ao cliente.

Numa Sprint o  ScrumMaster  deve garantir que não existam mudanças que possam impactá-la
negativamente, tais como a alterações na composição do Time ou nas metas de qualidade. Já o time deve se
concentrar em atingir os objetivos definidos no Backlog da Sprint.

Se durante a Sprint o Time sentir que se comprometeu com mais do que podia deverá entrar em contato
com o Dono do Produto para que ele remova ou reduza o escopo do Backlog selecionado para aquela Sprint.
Já, se o time verificar que sobrará tempo, juntamente com o Dono do Produto, poderá selecionar mais itens
do Backlog do Produto.

A tal Sprint 0
No planejamento da Sprint, o Time deve delinear em conjunto todos os trabalhos da próxima Sprint.
Entretanto, a etapa 0 (zero) é o momento de preparar o ambiente de trabalho antes de iniciar a reunião de
planejamento da Sprint, com o objetivo de evitar que algo não planejado interfira na sua execução.

Essa etapa 0 do planejamento da Sprint é pequena e rápida, mas tem uma grande importância. Antes de
trabalhar em suas cerimônias é fundamental conhecer alguns conceitos sobre a Sprint.

O primeiro passo desta etapa é deixar tudo pronto para a Sprint ser rodada, ou seja, organizar, mobilizar
27
e preparar tudo que for necessário para que nada interrompa, impeça ou bloqueie a execução normal da
Sprint, como infraestrutura (equipamentos, sala, ferramentas, softwares, materiais, suprimentos) e tudo mais
que for requerido para que o trabalho possa ser completado (inclusive conferir a disponibilidade da equipe
e reuni-la).

Embora muito comum a realização desta etapa, ela não é prevista nos manuais do Scrum.

Uma Sprint pode ser cancelada?

Mesmo que cada Sprint esteja congelada e não mude, o Dono do Produto tem a autoridade para cancelar
uma Sprint. Isso pode acontecer quando o que será entregue por ela torna-se obsoleto, devido à mudanças
no Backlog do Produto, ou em estratégias da empresa, necessidades de mercado e etc. Quando uma Sprint é
cancelada, os itens já finalizados são revisados e aceitos e o restante dos itens que ainda não foram terminados
voltam para o Backlog do Produto para serem executado em algum ponto do futuro.

Reunião de Planejamento da Sprint

A reunião de planejamento da Sprint tem duração de 8 horas para uma Sprint de um mês de duração (ou
seja, 2 horas a cada semana de Sprint). Esta reunião pode ser dividida em duas partes, e geralmente devido a
esta separação a reunião é realizada em duas etapas de 4 horas.

1. Definição do objetivo—Durante a primeira parte da reunião, o Dono do Produto explica para o Time
Scrum, as prioridades máximas das Histórias de Usuário ou os requisitos do Backlog Priorizado do Produto. O
Time Scrum em colaboração com o Dono do Produto então define o objetivo do Sprint.

2. Estimativa de trabalho—Durante a segunda parte da reunião, o Time Scrum decide “como” completar
os itens seleccionados no Backlog Priorizado do Produto, para cumprir a meta do Sprint. E assim se cria o
Backlog da Sprint.

Em resumo, na primeira parte da reunião o Time Scrum trata da questão do “o quê será feito?”. Já na
segunda parte o Time trata do “como será feito?”.

Não há nenhuma regra para documentar e apresentar o Backlog da Sprint. Tanto que o usual é mostrá-lo
em um quadro Kanban – O Scrum Taskboard.

Reuniões Diárias Scrum

Durante a execução das sprints, diariamente o time faz uma reunião de 15 minutos para acompanhar o
progresso do trabalho e agendar outras reuniões necessárias. Na reunião diária (Daily Scrum Meeting), cada
membro do time responde a três perguntas básicas:

• O que eu fiz no projeto desde a última reunião?

• O que irei fazer até a próxima reunião?

• Quais são os impedimentos?

Essa reunião deve, sempre que possível, ser realizada no mesmo horário e mesmo lugar durante toda a
Sprint. Essa é uma reunião que serve somente ao Time Scrum E NÃO deve conter nenhum tema referente ao
status do projeto em andamento.

O time Scrum deve também monitorar o progresso da Sprint dia a dia usando um gráfico de burndown.

28
 Assim, logo após a reunião diária o time atualiza o gráfico de Burndown indicando o que já foi efetivamente
encerrado.

Revisão e Retrospectiva da Sprint

Revisão da Sprint
A duração desta reunião é normalmente de quatro horas para uma Sprint de um mês. Se a Sprint tiver
menor duração, a reunião deve ser proporcionalmente reduzida.

Durante a apresentação das funcionalidades que estão sendo entregues, o Product Owner verifica o que foi
ou não realizado dentro do planejado.

O Time Scrum deve apresentar ao PO os itens que estão 100% finalizados de acordo com os critérios de
aceitação. E o PO vai se certificar se o item que está sendo entregue está realmente atendendo aos critérios
estabelecidos, caso contrário, o item será rejeitado e entrará mais uma vez no Backlog do Produto.

Além disso o Product Owner discute o Backlog do Produto da forma em que está e faz previsões de datas
de futuras entregas de acordo com o andamento atual do projeto.

Retrospectiva
Uma das regras do Scrum é que sempre existem formas de se melhorar. Não importa o quão pequena é
essa melhoria

Após a Revisão da Sprint ocorre uma reunião chamada de Retrospectiva da Sprint. A duração desta reunião
é normalmente de três horas para uma Sprint de um mês.

Sua finalidade é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre
elas, dos processos e das ferramentas.

Nela é avaliado o que funcionou para que possa ser repetido e o que não funcionou para que não aconteça
mais.

Refinamento do Backlog
O refinamento do backlog não é um evento, pois ele deve ser feito a todo momento durante o projeto. E é
isso o que veremos nesta aula.

Este é o processo em que o backlog é continuamente atualizado e mantido. Diferentemente dos demais
eventos Scrum que são time-boxed e possuem datas especificas para acontecerem, o refinamento do backlog
é um processo contínuo de responsabilidade do Dono do Produto. Esta atividade tipicamente envolve
adicionar detalhes, novas estimativas, re-ordenar e re-priorizar itens.

O dono do produto é o responsável por re-priorizar as atividades enquanto é do time Scrum a

responsabilidade por re-estimar atividades.

Fique atento à principal diferença entre esta atividade e os demais eventos do Scrum, pois esta não é um
evento time-boxed enquanto os demais eventos são.

Antes de encerrarmos, que tal repassarmos cada um desses eventos e suas durações?

29
• Sprint - até 4 semanas

• Reunião diária - 15 minutos

• Reunião de planejamento da Sprint - até 8 horas para uma Sprint de 4 semanas

• Reunião de revisão da Sprint - até 4 horas para uma Sprint de 4 semanas

• Reunião de retrospectiva da Sprint - até 3 horas para uma Sprint de 4 semanas

30
 Conceitos ligados ao escopo
Roadmap do produto
Também chamado de Plano de releases, o roadmap de um produto deve apresentar uma visão panorâmica
de todos os lançamentos do produto ao longo da linha do tempo, contendo características importantes e
principais funcionalidades ou conteúdos das versões futuras.

Na figura é possível observar a distribuição das funcionalidades ao longo do ciclo de vida do produto,
podendo corresponder desde a sua criação e lançamentos, passando por correções do produto até a sua
morte, com a retirada do mercado ou o surgimento de outro produto.

A distribuição das funcionalidades na linha do tempo geralmente se dá por importância, prioridade e/ou
obrigatoriedade. As funcionalidades mais mandatórias devem ficar no topo à esquerda. Quanto mais à direita
e para baixo, menos mandatória e importante é a funcionalidade.

Ou seja, as funcionalidades que aparecem no topo da versão 1 são as mais importantes e mandatórias
para que o produto funcione. Já as funcionalidades no final da lista da versão 4 podem ser consideradas menos
mandatórias e importantes, compondo uma lista possivelmente de itens desejáveis ou complementares.

Em outras palavras, as funcionalidades do topo da versão 1 devem ser realizadas antes das outras, e a
versão 1 deve ser finalizada antes de partir da versão 2.

Tipos de itens do Backlog do produto

Normalmente definimos escopo como uma lista de itens a serem desenvolvidos. Em projetos ágeis, essa
lista é chamada de Product Backlog (ou Backlog do Produto) que contém um número de itens, os chamados
itens do backlog do produto. E cada item descreve um bloco de construção da solução final.

De forma geral existem 3 possibilidades de se definir um item do backlog do produto.

• Especificação do requisito: esta é a forma tradicional de se definir o escopo. É composto por termos
técnicos que são claros para o time de desenvolvimento (mas normalmente ininteligíveis para o cliente),
e são baseados na arquitetura do software e nos relacionamentos entre os componentes. Já podemos
adiantar que os métodos ágeis não utilizam esta forma de definir o escopo do produto, pelo fato de ser
muito técnica e ter muitos detalhes de arquitetura que ainda são desconhecidos no inicio do projeto.

• Caso de uso (use case): este é baseado no entendimento do que o usuário precisa em uma linguagem
mais simples e descreve em detalhes um cenário de utilização do software com todas as ações possíveis
que um usuário pode ter bem como os retornos possíveis que o software deve dar a partir de cada das
ações do usuário.

• História de usuário (user story); é similar ao caso de uso, porém não contém todos os detalhes do
comportamento do usuário e foca somente nos objetivos do usuário.

Casos de Uso e histórias de usuário são similares. Ambos são utilizados para organizar requisitos. Porém,
enquanto Casos de Uso descrevem ações de interação segundo uma narrativa impessoal entre o usuário e o
sistema, já as histórias de usuário focam nos objetivos do usuário e como o sistema alcança esses objetivos.

Sendo assim, entre os casos de uso e as histórias de usuário, estas últimas são preferidas por também
serem pequenas e simples e não capturarem muitos detalhes. E exatamente por deixar de fora detalhes de
31
implementação a história de usuário requer pouca manutenção, não se tornando um documento obsoleto
rapidamente ou que exija muito esforço para mantê-lo atualizado.

5 características das Histórias de Usuários que você não sabia

No desenvolvimento ágil de software, uma História de Usuário representa em linguagem natural o que o
usuário faz, do que ele precisa e por que – tudo isso de maneira simples e concisa.

Apesar de ser uma técnica amplamente utilizada no desenvolvimento ágil de software, muitos adeptos não
se atentam a algumas de suas características fundamentais. É necessário ter consciência dessas características
para que se possa fazer melhor uso das Histórias e aumentar sua efetividade.

Histórias de Usuários são incompletas por definição

Uma boa História de Usuário não deve ser completa e com detalhamento suficiente para que os
desenvolvedores não precisem de mais detalhes. Pelo contrário: ela deve encorajar os desenvolvedores a
pedirem mais detalhes ao cliente, enfatizando a comunicação entre eles. Além disso, devem ter o tamanho
certo para o planejamento da sprint para funcionarem bem com o desenvolvimento iterativo e incremental.

Histórias de Usuários podem ser quebradas em outras histórias

Não há problema algum em quebrar uma história em duas ou mais. Isso é natural dentro do processo
iterativo. À medida em que uma história se torna prioritária e se aproxima o momento em que ela vai entrar na
sprint, ela é mais bem entendida e detalhada. Em alguns casos, é normal que a história seja dividida em outras.

As Histórias de Usuários devem ser escritas pensando-se nos diversos perfis de usuários finais

As histórias devem ser escritas pensando-se nas necessidades do usuário final. Existem diversas técnicas
que contribuem para um melhor conhecimento do usuário final. A mais utilizada nos processos ágeis é a criação
de Personas: um arquétipo de usuário que representa um grupo de usuários reais. Essas Personas são utilizadas
como referência para o desenvolvimento das funcionalidades. Além de melhorar o conhecimento sobre o
usuário final, as Personas são úteis para a construção de software com alto grau de usabilidade.

Nem tudo deve virar uma História de Usuário

As Histórias não são a única forma de documentação e entendimento dos requisitos. Pode-se elaborar
outros artefatos – como diagramas, protótipos ou casos de uso – de acordo com a necessidade do projeto e do
cliente. Não existe regra geral e cada caso é um caso. É preciso entender bem qual o propósito de cada artefato
e em qual situação cada um deles será utilizado.

Os elementos de interface com o usuário (UI), sempre que possível, devem ficar de fora das Histórias

Uma História de Usuário representa a especificação de um requisito, ou seja, um problema do cliente que
o time de desenvolvimento deve resolver produzindo um software. É bastante comum que o cliente queira
misturar a especificação do problema com a da solução. Isso deve ser evitado, pois as Histórias devem focar o
máximo no problema. A solução deve ser proposta pelo time de desenvolvimento.

Como escrever uma história de usuário

32
 Como já comentamos uma história de usuário pode ser caracterizada como uma curta e simples descrição da
necessidade do cliente.

Ela normalmente é contada a partir da perspectiva de quem precisa da nova necessidade, sendo geralmente
um usuário, cliente do sistema ou representante de negócios do cliente. Uma história de usuário deve explicar
bem para quem, o que e por que está sendo criada.

Ela é construída da seguinte forma:

Como um <ator/tipo de usuário> eu quero <objetivo/ação> [para que] <atenda a uma necessidade>

• Ator/usuário – O proprietário da história de usuário. Pode tanto ser o usuário ou a persona, ou seja, o
interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator
para ser mais fácil identificar o contexto da história dentro do sistema.

• Objetivo/Ação –  É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo
dentro do sistema. 

• Necessidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar
a ação segundo a ótica do ator. Também pode ser visto como justificativa. Veja que este último não é
obrigatório em uma história de usuário.

Exemplos:

Como usuário do sistema eu quero poder redefinir minha senha.

“Como cliente da loja on-line de roupas esportivas, eu quero poder salvar os itens escolhidos e visualizá-
los mais tarde, para que então eu possa finalizar a compra.”

Ao construir uma história de usuário, devemos levar em conta os seguintes aspectos:

• Ela deve ser escrita em termos não-técnicos: em regra considere que qualquer pessoa (até mesmo a sua
vozinha de 96 anos de idade seja capaz de entender o que foi definido nessa história)

• Uma história de usuário deve ser independente das demais: pois assim ela pode ser desenvolvida a
qualquer momento sem ter que depender de outras.

Normalmente usamos post-its para escrever histórias de usuários e as fixamos em um quadro – o Scrumboard.

Para que uma história seja considerada completa, além de sua descrição é preciso definir os seus critérios
de aceite. Esses critérios representam o que ela precisa fazer para ser considerada válida pelo Dono do Produto
e futuramente pelo cliente.

A maneira mais simples de definir os critérios de aceite de uma história seria lista no verso do post-it os
itens de negócio que expressam a forma de usar a funcionalidade construída, com o objetivo de o Dono do
Produto e o cliente validarem se a história foi completada de maneira solicitada.

A descrição representa de forma resumida o requisito a que a história deverá atender ao seu completada.
Da mesma forma, os critérios de aceite devem ser breves e objetivos, mostrando uma lista simplificada de itens
que ajudarão na validação e conferência da história e que também podem servir de lembretes para regras de
negócio que precisam ser atendidas, tais como:

• O usuário precisa informar o nome parcial ou completo do tipo de roupa que está procurando.

33
 • Uma lista de peças deve ser mostrada com base no nome informado.

• Uma mensagem deverá ser mostrada caso nenhuma peça seja encontada.

Técnica INVEST
Uma boa história de usuário precisa estar bem escrita e que seja de fácil entendimento. Eu mesma já
li histórias de usuário que pareciam telegramas para Deus, porque só ELE conseguiria entende-las de tão
abreviadas. Enquanto outras dariam até para concorrer a algum prêmio literário de tão prolificas que eram.

Neste ponto você já deve ter notado que o custo de elaboração de uma história de usuário não é medido por
palavra. O que importa é que qualquer pessoa (do time e de fora dele, que tenha um mínimo de entendimento
do projeto) consiga entender o que precisa será feito e é por isso que vamos a técnica INVEST.

Esta técnica, muito recomendada inclusive pelos idealizadores do Scrum, é um acrônimo de: Independent
(Independente), Negociable (Negociável), Valuable (Valiosa), Estimable (Estimável), Small (Pequena) e Testable
(Testável).

Assim, o INVEST diz que uma boa user story possui seis características:

• Independent: histórias são mais facilmente trabalhadas quando são independentes, ou seja, quando
podemos implementá-las em qualquer ordem, já que não são intimamente ligadas, gerando uma
cascata (que pode virar gargalo) de implementação. Esta sem dúvida é uma característica muito difícil
de ser alcançada totalmente, porque querendo ou não uma história sempre será dependente de outra,
mas isso não te deve impedir de tentar fazer o melhor.

• Negociable: histórias não são contratos para implementar funcionalidades; boas histórias captam a
essências e não os detalhes. Definida a essência, os detalhes são negociados com o Dono do Produto. E
não definidos por ele.

• Valuable: a premissa básica de uma história é que ela agregue valor ao produto, para o cliente. Muitas
vezes as histórias começam a ser quebradas. Quando começamos a quebrar demais as histórias, temos
que ter o cuidado de não transformá-las em algo que entregue apenas uma parte da funcionalidade.

• Estimable: não precisa ser algo exato; o time não precisa acertar sempre; mas o time precisa ser capaz
de estimar uma história. Da mesma forma que uma história estimável pode ser negociada, ninguém
consegue estimar uma história que não entende.

• Small: boas histórias são pequenas. Elas entram no acordo entre Time e o Dono do Produto sobre o
tamanho máximo de uma história dentro da Sprint. Além disso, quando as histórias são menores, há
chances maiores de ter uma estimativa mais precisa. É o típico caso de quando o Time chuta para cima a
estimativa de uma história “por não entender o que implicaria sua implementação”. Se o time usar essa
frase na durante a reunião de planejamento, significa que a história deve ser revista.

• Testable: é preciso testar! Sempre! Testabilidade sempre foi uma característica de bons requisitos; o
mesmo é plenamente aplicável às histórias de usuário. Se o cliente não sabe como testar algo, significa
que ou a história não está clara o bastante ou que ela não contém algo que acrescente valor aos olhos
do cliente.

Seguir estes pontos é importante para o Dono do Produto na escrita e para o Time na aceitação. É preciso
que todos estejam alinhados com o conceito de cada um destes critérios. Muitas empresas preocupam-se com
a qualidade de seus produtos. Mas, antes de mais nada, é necessário ter a preocupação focada nas histórias

34
que geraram o produto. Histórias de alta qualidade criam produtos de alta qualidade. Por isso invista em suas
histórias como se não houvesse amanhã.

SMART
Depois de investir em boas histórias de usuário, o ScrumMaster deve ajudar o time na divisão de tarefas.
Da mesma forma que aprendemos a usar o INVEST na aula passada para escrever e avaliar estóris, o time pode
usar a técnica SMART para quebrar as histórias em tarefas, de modo a alcançar os objetivos da sprint.

A SMART é frequentemente usado para guiar na construção de objetivos alcançáveis,  mas é totalmente
adaptável para o contexto das tarefas técnicas, que, no final das contas, fazem com que o time atinja os objetivos
da sprint.

Assim como o INVEST, o SMART é também um acrônonimo de Specific, Measurable, Achievable, Relevant,
Time-Based.

Assim, a técnica SMART diz que uma tarefa têm cinco características:

• Specific: tarefas precisam ser específicas para que todos do time entendam como elas se conectam e
como juntas elas contribuem para atingir os critérios de aceitação da user story.

• Measurable: uma tarefa é mensurável quando pode ser marcada como “concluída”, seguindo os critérios
técnicos do time. Por exemplo, com os testes escritos e o código refatorado.

• Achievable: as tarefas devem ser alcançáveis pelos seus responsáveis. Aqui entra a capacidade do
time de identificar pontos fortes, fracos e oportunidades de melhoria dos membros. Neste critério ,
por exemplo, o time pode optar pelo pair programming, para desenvolver habilidades e alcançar seu
objetivo.

• Relevant: todas as tarefas devem ser relevantes. As histórias são quebradas em tarefas para auxiliar o
desenvolvimento, mas o Product Owner ainda espera que todas elas sejam explicáveis e justificáveis.

• Time-based: todas as tarefas precisam ter um tempo definido para serem concluídas. Não é necessário
fazer uma estimativa formal em horas ou dias, mas deve haver uma expectativa de conclusão ou de
quando será necessário pedir ajuda ao time. Quando uma tarefa se torna maior do que esperado, o time
precisa saber o momento certo para tomar uma ação para que seja concluída.

Use estes critérios e esteja pronto para alcançar o objetivo da Sprint.

Priorização - MOSCOW
No Scrum é decisivo definir as prioridades, ou importâncias, dos itens de Backlog que serão implementados,
uma vez que o Scrum defende que se deve investir mais esforço nos itens mais importantes do Backlog, ou seja,
naqueles itens que agregam mais valor ao cliente que utilizará o produto. E é isto o que veremos nesta aula

Mas afinal, porque trabalhar primeiro com os mais importantes? Por que são estes itens que realmente farão
diferença para o cliente na entrega que ele espera receber. Geralmente estes itens são os maiores, ou os mais
complexos, e por consequência são aqueles que sofrerão mais com os riscos e mudanças.

Então, se os maiores riscos geralmente ocorrem nos itens mais importantes, é melhor tratá-los o quanto
antes, pois assim o Time terá tempo para recuperação e adaptação.

35
 Não pense no que é mais importante para você, ou para a sua visão de importância para o projeto. Pense
na visão do cliente, pergunte a ele, converse com os stakeholders e entenda com eles o que é realmente mais
importante para o projeto.

A ferramenta mais usual de priorização em Scrum é a priorização Moscow

Esse nome deriva das primeiras letras das palavras “Must have” (deve ter), “Should have” (deveria ter),
“Could have” (poderia ter), e “Won’t have this time” (não terá agora).

Este método de priorização é geralmente mais eficaz do que outros métodos mais simples que apenas
consideram os itens como vai ter e não vai ter.

No esquema Moscow, os itens avaliados estão em ordem de prioridade decrescente, sendo que “deve ter”
são as Histórias de Usuário que sem as quais o produto não terá valor, e, “não terá agora” como aquelas que
não são necessárias.

Esta é uma ótima técnica para ser exercitada pelo Dono do Produto em conjunto com o cliente, pois facilita
o entendimento do que realmente é importante para o projeto.

Spikes
Imagine se deparar com um projeto que deve ser desenvolvido com uma tecnologia ou arquitetura que
nenhum membro da equipe conhece. Ou, então, a organização resolve desenvolver um produto inovador e
diferente de seus produtos padrão até o momento. Você está diante de um cenário de alto risco e incerteza.

Para cenários onde requisitos, recursos ou tecnologias são desconhecidos ou apresentam muito risco,
utiliza-se a técnica de spike.

Um spike é um curto exercício de prova de conceito onde a equipe investiga um problema ou ricso.

O Spike pode ser uma história de usuário ou mesmo um conjunto de histórias de usuário de uma determinada
iteração. Também pode ser desenvolvido na primeira iteração do projeto para decidir se vale a pena continuar
com o projeto ou não. Esse tipo de iteração investigativa inicial também é conhecido como iteração zero e pode
ser uma iteração para validação e construção de arquiteturas, ou mesmo formação de equipes.

O grande benefício de usar Spikes é identificar falhas ou inviabilidade do projeto logo no início, garantindo
que o orçamento do projeto não seja gasto em fracasso. Esse conceito é conhecido como falha rápida (fast
failure ou fails fast em inglês).

E como fica a manutenção?

Ao se falar em manutenção de software e Scrum devemos nos perguntar:

• Como você faz um planejamento de sprint se não sabe o que precisará ser feito até o final da semana?

• Faço reuniões de estimativa quando? Paro toda a minha equipe quando uma atividade entra?

• Software funcionando somente no final da sprint?

Difícil responder isso, não?

Para manutenção, e mesmo em outros casos, você não deve se preocupar em montar uma sprint, negociar
as atividades das próximas semanas e aguardar semanas para ter seu software rodando em produção. São
36
muitas cerimônias e burocracias enquanto seu usuário está parado esperando por uma solução.

E é aí que entra o Kanban. Heim? Bom, você já viu um quadro Kanban, mas talvez não sabe que sabe como
é um. Um quadro kanban usado no scrum é justamente o Scrum Task Board!

Ah...OK, mas afinal o que é Kanban?

Kanban é um método desenvolvido pelos engenheiros da Toyota na década de 1950. É uma forma visual de
gerenciamento de projetos e funciona de acordo com a demanda.

Assim como no chão de fábrica da Toyota, manutenção de software é feita sob demanda.

Com Kanban é possível ver onde estão os gargalos. Que tipo de problema sua equipe tem gasto mais tempo.
Quantas pessoas precisam ser alocadas para cada tipo de problema. E o mais importante: o que tem sugado
seu dinheiro nessa operação. Afinal, sem essas informações, é bem mais difícil saber que parte da equipe está
com mais trabalho do que aguenta e qual está com menos do que deveria. A alocação de recursos se torna mais
simples.

Então, para a manutenção de software, o que se usa é a ferramenta Kanban e não todo o arcabouço do
Scrum.

Interessado em mais detalhes? Em uma aula futura, vamos mostrar mais sobre esta técnica.

37
 Estimando
Definindo o tamanho das histórias
O Planejamento Poker, também chamado de Poker da Estimativa, ou ainda Planning Poker é uma técnica
de estimativa que usa o consenso para estimar os tamanhos relativos das Histórias de Usuários, ou o esforço
necessário para cria-las.

No Planejamento Poker, a cada membro do time tem um baralho de cartas. Cada carta é numerada em
uma sequência e os números representam a complexidade do problema, em termos de tempo ou esforço,
conforme estimado pelo membro do time.

O Dono do Produto escolhe uma História de Usuário do Backlog Priorizado do Produto e apresenta para
o time. Os membros do Time Scrum avaliam a História de Usuário e tentam compreendê-la melhor antes de
fornecer a sua estimativa com relação ao desenvolvimento.

Em seguida, cada membro escolhe uma carta do baralho que representa a sua estimativa para a História de
Usuário. Se a maioria, ou todos os membros do time, selecionarem a mesma carta, então,

a estimativa indicada nesta carta será a estimativa para a História de Usuário. Se não houver um consenso,
os membros do time discutem as razões pelas quais selecionaram diferentes cartas ou estimativas.

Após essa discussão eles escolhem novamente uma carta. Esta sequência continua até que todas as
suposições sejam compreendidas, mal-entendidos sejam resolvidos e o consenso ou acordo seja alcançado.

Tamanho Relativo/Pontos da História

Além de serem usados para estimar o custo, os pontos da história também podem ser usados para estimar
o tamanho geral de uma História de Usuário.

Essa abordagem atribui um valor de pontos de história baseado em uma avaliação geral do tamanho de
uma determinada História de Usuário, considerando o risco, a quantidade de esforço exigido e o nível de
complexidade.

A partir daí o Time Scrum passa a avaliar outras Histórias de Usuários relacionadas a essa primeira.

Por exemplo, uma história de usuário com um valor de 2 pontos de história, deve ser duas vezes mais difícil
de ser concluída, do que uma história avaliada como 1 ponto; já uma história avaliada como 3 pontos de história
deve ser três vezes mais difícil de ser concluída, do que uma com um valor de ponto da história igual a 1.

Estimativa de Afinidade
A Estimativa de Afinidade é uma técnica utilizada para estimar rapidamente um grande número de Histórias
de Usuário.

Usando post-its, por exemplo, o time deve tentar colocar as Histórias de Usuário em ordem crescente de
dificuldade.

38
 Para isso, cada membro do time começa com um subconjunto de Histórias de Usuário do Backlog Priorizado
do Produto posicionando-as de acordo com o seu tamanho relativo.

Esse posicionamento inicial é feito em silêncio. Depois que todo mundo coloca as suas Histórias de Usuário
na parede, o time as analisa e pode reposicioná-las de acordo com o que achar mais apropriado.

Esta segunda parte do exercício envolve a discussão do porque as histórias de usuários podem ter sido
reposicionadas.

Finalmente, o Dono do Produto vai indicar algumas categorias de dimensionamento na parede.

Essas categorias podem ser pequena, média ou grande, ou podem ser numeradas usando valores de ponto
da história para indicar o seu tamanho relativo.

O time, então, moverá as Histórias de Usuário para essas categorias.

Horas x Pontos de história

Uma maneira bem prática de ter uma ideia de horas ao definir os tamanhos das histórias é montar uma
equivalência simples entre os pontos por história e as horas estimadas de esforço para completar as histórias –
por exemplo, 10 pontos por história equivalem a oito horas de esforço. Veja que essa equivalência não necessita
ser precisa, até porque nesse momento o time ainda não tem informações suficientes para estimar o esforço
em horas, e acertar será muito difícil. Por outro lado, será muito interessante ter um contraponto em horas
de esforço para os tamanhos das histórias, especialmente porque essa informação poderá ser utilizada em
momentos futuros durante os planejamentos e as inspeções do projeto.

Pense em equivalências simples, como, por exemplo, 2 pontos por história equivalem a quatro horas de
esforço; ou 40 pontos por história equivalem a vinte horas de esforço. A única regra para essa equivalência é
de ter uma lógica constante, para que ao final das estimativas haja um total aproximado de horas de esforço.

Como medir a velocidade do time

O tamaho das histórias se dá pelos pontos por história, e geralmente a velocidade do time também. O
time mede a sua velocidade de acordo com a quantidade de pontos por história que consegue completar por
Sprint. As Sprints devem ter o mesmo tamanho do início ao fim do projeto ou fase; caso contrário, a definição
de velocidade perde o seu valor.

Então quando o time determina, ou identifica, que a sua velocidade é e 1000 pontos por história, isso
significa que o time, dentro de uma Sprint, consegue completar um conjunto de histórias que totaliza no máximo
1000 pontos.

Essa velocidade do time é uma definição muito importante porque determinará quantas Sprints o projeto
ou fase terá, e qual será a duração total do projeto ou fase em Sprints.

Por exemplo, vamos considerar que uma fase do projeto possui cinquenta histórias e a soma dos pontos de
história é de 2500 pontos. O time já havia definido que consegue entregar 200 pontos de história para Sprints
de 3 semanas. Assim o time precisará de 13 sprints para completar os 2500 pontos, ou seja, serão necessárias
39 semanas (ou 10 meses) para completar essa fase do projeto.

Veja, por esse exemplo, a importância de se ter a velocidade do time e aplicá-la para encontrar outros
tamanhos e estimativas para o projeto.

39
 Times experientes e que já trabalham juntos há certo tempo geralmente possuem velocidades definidas e
conseguem mantê-las em vários projetos. No entanto, times recém-formados, que nunca trabalharam juntos
ou que não são experientes com o trabalho no formato do Scrum, dificilmente terão velocidades definidas e
não devem criá-las do nada no início do projeto.

Então, como ter uma velocidade quando ela não existe? Quando o time não possui uma velocidade definida,
deve selecionar histórias que acredita poder realizar na próxima Sprint, completa-la e analisar as histórias
finalizadas, ajustando o tamanho do bavklog que consegue completar na Sprint seguinte.

Em outras palavras, se o Time não possui uma velocidade definida, ele deve executar a próxima Sprint
sem uma velocidade estimada, fazendo tudo que for possível na próxima Sprint. A partir dessa primeiras, será
obtida uma velocidade de partida que será ainda ajustada nas Sprints seguintes.

Ao fazer isso durante algumas Sprints, o Time obterá naturalmente a sua velocidade e poderá utilizá-la no
restante do projeto e em outros projetos futuros, partindo do princípio de que o Time continue o mesmo e o
tamanho das Sprints também.

A duração de uma Sprint

O tamanho das Sprints deve ser o mesmo para todo o projeto, pois este é um dos indicadores de desempenho
e melhoria que o Scrum proporciona – e também um dos mais importantes.

Para que o time tire o maior proveito da melhoria contínua, o ideal é que o tamanho das Sprints seja o
mesmo do início ao fim do projeto. Porém, isso não deve ser uma regra imutável; se o Time errou na definição
do tamanho das Sprints, deve assumir isso e alterá-lo ao longo do projeto para obter melhores resultados.

Com o resultado da preparação do ambiente, reunindo a equipe e identificando a velocidade do Time e

os itens do backlog da entrega, é possível determinar e confirmar o tamanho das Sprints de maneira oficial,
e assim também determinar conclusivamente o número de Sprints necessárias para completar o trabalho do
backlog.

Dias ideais e horas ideais

Um dia ideal é aquele no qual uma quantidade de trabalho é realizada sem qualquer interrupção ou
distração. É um dia em que hipoteticamente tudo está perfeito e disponível, nada dá errado e até a inspiração
profissional está alta.

O dia ideal é aquele em que o desenvolvedor trabalhará apenas na sua história, e tudo o que ele precisará
para completar o seu trabalho estará imediatamente à mão.

É importante reforçar que o dia ideal não é real e raramente irá acontecer se não houver uma conspiração
positiva para favorece-lo, portanto é recomendado não utilizar o dia ideal para estimar o tempo, mas sim o
esforço em relação à conclusão de uma história.

Horas ideais
As horas ideias são simplesmente as horas realmente produtivas durante um dia de trabalho.

Muitos ainda insistem em prever oito horas de trabalho para um profissional durante o dia. Para que um
profissional trabalhe e produza realmente oito horas por dia será preciso que ele não levante, não interaja
com ninguém, não tome café, não vá ao banheiro, não atenda o telefone, não leia e-mails ou seja, se isole e
trabalhe freneticamente.
40
 Quem realmente acredita que isso é possível?

Quando se estima pensando que um dia tem oito horas de produção de código e de desenvolvimento de
sistema, já está começando atrasado, pois haverá pelo menos duas horas a menos por dia de produção e ao
final do mês serão 40 horas de atraso por pessoa, ou seja, uma semana atrasada.

É comprovado que as horas ideais de trabalho em um dia giram em torno de quatro a seis horas, afinal é
impossível ficar focado em uma tarefa por oito horas seguidas – além do que todos precisamos nos alimentar,
ir ao banheiro, ligar para clientes, participar de reuniões etc.

Sendo assim, para não errar, considere no máximo seis horas diárias de produção real. Com isso, uma
semana de trabalho de 40 horas produzirá em torno de 30 horas reais, completando em um mês de 120 a 130
horas de produção efetiva.

41
 Monitorando

Radiadores de Informação
Quem já  precisou de informações para tomada de decisão e se viu imerso em um punhado de sistemas,
planilhas, etc..Sem entender de fato o que estava acontecendo? ou então aquele sentimento de falarmos e
combinarmos as coisas, voltarmos para as nossas mesas e ter a sensação de que ninguém se lembrará do que
precisa ser feito? Nesta aula vamos tratar dos radiadores de informação que justamente ajudam a minimizar
esses problemas.

Radiadores de informação é um termo criado por Alistair Cockburn, um dos autores do Manifesto Ágil,
para referenciar elementos visuais que destacam pontos importante do projeto, tornando o ambiente
informativo e permitindo que a análises possam ser conduzidas com facilidade e que visitantes tenham uma
visão panorâmica da situação do projeto.

Radiadores de Informação são artefatos que contribuem muito para a troca de informação a respeito
de acontecimentos, realizações e eventos do projeto. Essa troca se dá do time para o Time e do Time para as
partes interessadas, incluindo gerências, clientes e outros envolvidos externamente com o projeto.

Assim entendemos que radiadores de informação são conjuntos de informações apresentadas de maneira
clara e simples expostas de forma que todos possam receber a informação necessária de forma eficiente.

Normalmente os radiadores são expostos em paredes com o objetivo de obter o máximo de transparência
no projeto.

Os radiadores trazem a “Transparência” necessária para que qualquer pessoa consiga observar o que esta
acontecendo com o projeto.

Eles podem ser:

• Scrum Task Board (ou Quadro Kanban)

• Registro de Riscos

• Gráfico Burndown

• Gráfico de Fluxo Cumulativo

• Métricas de velocidade

• Métricas de defeito

Ou qualquer outra informação que seja necessária para tornar mais efetiva a comunicação do projeto.

Scrum Task Board

Já vimos em uma aula anterior o ScrumTask board, então que tal revisarmos os seus conceitos, já que esse
quadro é um importante radiador de informações?

O Taskboard, ou Quadro de Tarefas ou ainda Quadro Kanban, não aparece originalmente como artefato
42
no Guia do Scrum, de Ken Schwaber, mas é sem dúvida uma ferramenta fundamental ao lado do Backlog e do
gráfico de Burndown. 

O Taskboard nada mais é do que é um quadro, ou uma parede mesmo, onde o Time coloca as tarefas do
Backlog da Sprint, em post its, de uma forma organizada e ordenada. O objetivo é para que visualmente se
entenda rapidamente e claramente como o trabalho está.

Geralmente as divisões são feitas em 4 (quatro) colunas: Histórias, a Fazer, Em andamento e Feito, nesta

mesma ordem.

Na primeira coluna devem estar as Histórias identificadas no Backlog, e nas demais a sua direita, as tarefas
contidas dentro de cada história. As tarefas que não estão sendo trabalhadas devem estar na coluna “Fazer“,
quando alguém estiver trabalhando em uma tarefa, esta deve estar na coluna “Em andamento“, e quando a
mesma tarefa estiver pronta, deverá ir para a coluna “Feito“.

É  super simples não é? É  simples mesmo e muito eficiente.  O  efeito visual gera impactos em todos

que  acompanham o quadro, além de  deixar claro  para todos quais tarefas estão sendo trabalhadas, e até
quantas pessoas estão trabalhando.

Além do modelo mostrado, o Quadro de Tarefas pode conter colunas para testes de qualidade, e tarefas
não previstas. Não se prenda a padrões, experimente e descubra o que é melhor para o seu Time.

Dica: Coloque acima dos títulos das colunas a  capacidade do Time  que está realizando as tarefas do
Taskboard, com isso será possível saber quem está trabalhando e quem está parado só de olhar os post its e
a capacidade do Time.

Dica: Utilize cores diferentes para as histórias, para as tarefas normais, para testes e para as tarefas não
previstas. Isso ajudará muito na identificação de impedimentos ou desvios.

Gráficos Burn-Down
O gráfico de burndown é considerado um dos mais úteis para monitorar o progresso de um time ágil. E
vamos ver este gráfico em detalhes nesta aula.

O gráfico representa a quantidade de trabalho que falta ser feito no eixo vertical (y) versus o tempo no
eixo horizontal (x).

A unidade de tempo do eixo Y pode ser em dias, horas, semana ou até mesmo sprints, mas neste último
caso somente se estivermos usando um gráfico de burndown da Release

A unidade da quantidade do eixo X pode ser em horas de trabalho ou pontos de história.

É importante mencionar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto
ou empresa, visto que cada unidade de medida possui objetivos diferentes. O burndown por pontos de história
indica o valor que foi entregue ao cliente; já o burndown por horas mostra o acompanhamento do ritmo dirário
do time. Qual deles é o correto? Os dois, pois os dois tipos são importantes.

O burndown revela dados importantes sobre como está o andamento do time e como ele pode ser melhorado.
Algumas empresas o utilizam para acompanhar a produtividade ou como ferramenta de coleta de dados para
as retrospectivas, e principalmente indica como o time está evoluindo, através do seu acompanhamento a cada
iteração.

43
 Veja que a partir desse gráfico podemos extrair informações tais como:

• Quão bom é o time no planejamento?

• O time é realmente auto-organizado e está trabalhando como uma equipe?

• Quais melhorias esse time pode fazer?

• O quão bem o time está executando as histórias planejadas na Sprint?

Cada linha do gráfico a seguir representa um time diferente.

• A linha azul nunca atinge o zero, o que indica que o planejamento e execução desse time não estão
bons. Podem existir vários motivos que causam isso: como alteração de prioridade durante a sprint,
planejamento de mais histórias do que a capacidade ou até mesmo uma falta de união no time. Isso
indica que é necessário melhorar o planejamento.

• A linha roxa atingiu a meta, mas esteve longe da linha ideal e no meio observa-se uma curva acentuada
o que pode indicar que ou o time não atualizou suas estimativas corretamente durante a Sprint ou que
ainda histórias que não teriam como ser encerradas foram retiradas da sprint.

• A linha verde indica que o planejamento e execução foram bons. O time é auto-organizado. Ela mostra
que a meta foi atingida e que tudo está acontecendo conforme previsto.

Gráfico Cumulative Flow

Um Diagrama de Fluxo Cumulativo (DFC) é uma ferramenta útil na elaboração de relatórios e acompanhamento
de desempenho do projeto. Nesta aula vamos ver como é o seu funcionamento.

Ele fornece uma representação visual simples do andamento do projeto, em um determinado ponto. É
normalmente usado para fornecer um status de nível superior de todo o projeto, e não de atualizações diárias
para Sprints individuais.

44
Interpretando o CFD
A área que mostra os itens done (prontos) representa a velocidade no decorrer do tempo. A área entre as
linhas done e backlog é o trabalho em progresso (WIP).

Se a distância entre duas linhas na área do trabalho em progresso (WIP) aumentar, isso pode ser um sinal
de gargalos;

Se a linha de backlog estiver mais inclinada que a de done, há sinal claro de que se está adicionando mais
trabalho ao sistema se comparado à sua capacidade atual de entrega;

Projetar onde as linhas que representam os itens de backlog e de done irão se encontrar é a melhor
maneira de estimar a data final de entrega;

O tempo médio de ciclo e quantidade de itens na fila também podem ser extraídos do diagrama.

A área de mostra os itens “done”(prontos) representa a velocidade no decorrer do tempo.

Este tipo de diagrama pode ser uma ótima ferramenta para se identificar obstáculos e gargalos de
processos. Por exemplo, se o diagrama mostra uma coluna que está se tornando mais estreita, enquanto
que a coluna anterior está se tornando mais larga ao longo do tempo, pode haver um gargalo, e mudanças
podem ser necessárias para aumentar a eficiência e/ou melhorar o desempenho do projeto.

45
 Grandes Projetos em Scrum

Como aplicar Scrum em Projetos grandes e complexos

Existe o mito de que o Scrum só é viável para pequenos projetos executados por pequenas equipes. Mas
isso não é verdade. Nesta aula vamos ver como fazer isso.

Uma forma de expandir o Scrum para grandes e complexos projetos é utilizar o Scrum de Scrums. O
objetivo desta prática é dar suporte em situações na qual a equipe é muito grande e necessita ser quebrada
em várias equipes que precisam interagir constantemente em prol do progresso do projeto.

O objetivo é similar ao Daily Meeting, só que numa escala maior. Enquanto o Daily Meeting é mais viável
com equipes pequenas de modo a ser uma reunião diária curta, o Scrum de Scrums visa realizar uma reunião
mais especializada com o objetivo de manter as equipes atualizadas em relação aos acontecimentos desde a
última reunião. Essa reunião ocorre normalmente uma vez por semana e tem a participação do Scrum Master
de cada equipe.

Assim, nela é debatido o que foi discutido no Daily Meeting de cada equipe ao longo da semana, de
modo a sincronizar as atividades do projeto, fornecendo uma melhor visão do progresso.

De forma a melhor organizar essa reunião, essa abordagem sugere a definição de um Scrum Master
(sênior) dentre os Scrums Master, normalmente o SM da localidade central é escolhido, uma vez que ele
possui mais contato com o PO e o cliente. Desse modo, o SM (sênior) fica responsável por interagir com o PO
para esclarecer as dúvidas que ocorram durante as reuniões (Scrum de Scrums) ou até mesmo convocar o PO
para participar das próximas reuniões. Muitas vezes é necessário a presença de outros membros além do PO,
como por exemplo, um representante de cada equipe para discussão dos problemas de dependências entre
elas.

Como essa prática tem um foco na integração entre as equipes não é necessário fazer esta reunião
diariamente, sendo o suficiente ser feito semanalmente. Entretanto, em situações em que a dependência
entre as equipes seja muito grande, a frequência deve aumentar para duas a três vezes por semana. E o Scrum
Master deve criar um quadro com o resumo de todos os fatos importantes que aconteceram em sua equipe
durante a semana para ser discutido na reunião.

Por fim, depois que cada Scrum Master cria sua lista, a reunião do Scrum de Scrums é realizada. Durante
a reunião os participantes devem levantar as soluções para os problemas discutidos e essas soluções devem
ser compartilhadas para todos os membros.

Os diferentes tipos de contratos no Scrum

Enquanto o Manifesto Ágil diz «Colaboração com o Cliente mais que negociação de contratos», contratos
são uma realidade de desenvolvedores e firmas. É por isso que nesta aula vamos ver alguns detalhes sobre os
tipos de contratos que costumam ser usados quando se trata de um projeto Scrum.

Existem diversos tipos diferentes de contratos de desenvolvimento e para saber qual melhor :

• A estrutura geral do contrato

• Como o contrato lida com mudanças no escopo

46
 • Como o risco é distribuído

• Qual tipo de relacionamento ele fomenta entra o cliente e o desenvolvedor.

O tipo mais básico de contrato de desenvolvimento é a abordagem  tempo-e-recurso (ou tempo e

materiais). Ele inclui a maioria dos riscos financeiros na conta do cliente. O desenvolvedor não possui incentivo
para finalizar o projeto previamente ou manter os custos baixos.

A alternativa mais comum é o contrato por preço fixo. Este tipo de contrato tem se tornado muito popular
entre os clientes, pois ele passa o maior risco para o desenvolvedor. Se o projeto atrasa, o desenvolvedor arca
com os custos. Este tipo de acordo não é amigável em casos de mudança de escopo, o que pode em certo
estágio do projeto causar desentendimentos sobre o que está ou não no escopo.

Existe ainda o modelo de  Lucro Fixo. Onde ambas as partes concordam previamente em um valo fixo
para o lucro. Ex.: R$1000,000 que serão pagos para o fornecedor. Independente da duração do projeto, a
consultoria de desenvolvimento recebe o lucro mais os custos incorridos. Se o projeto finalizar antes, tanto o
cliente quanto o fornecedor se beneficiam.

Existe ainda o modelo híbrido que inclui tanto uma quantia fixa quanto uma taxa por hora. O desenvolvedor
faz uma estimativa de quanto tempo o trabalhar irá tomar, por exemplo, 80 horas. O desenvolvedor então
multiplica este tempo pelo seu valor de horas “usuais”, vamos dizer R$200 a hora, para chegar a um custo
esperado pelo trabalho. Neste caso o custo esperado é de R$16.000. Este montante será quebrado em um
montante fixo e uma taxa por hora menor. Por exemplo, a parte fixa poderia ser R$8,000 e a taxa da hora seria
reduzida para R$100 a hora.

Se o projeto tomar mais tempo do que o esperado, então o preço seria: R$8,000 + 80 * R$100 = R$16,000.
Se o projeto está atrasado, o desenvolvedor ganhará apenas R$100 a hora pelo trabalho adicional. Esta
abordagem é uma tentativa de compartilhar o risco de maneira justa entre o desenvolvedor e o cliente.

Recentemente surgiu um modelo de contrato chamado de “money for nothing, changes for free”, ou
(“Dinheiro por nada e mudanças à vontade”) que torna as vantagens do Scrum e processos ágeis de
desenvolvimento em uma vantagem competitiva.

Algumas vantagens do uso desse tipo de contrato são:

• Priorizando e trazendo valor ao negócio incrementalmente, as chances de uma falha total são
reduzidas drasticamente. Esta vantagem é passada para o cliente.

• Além disso, este é um modelo cooperativo, de forma que ele oferece incentivo para ambas as partes
para manter os custos baixos.

• A cláusula de cancelamento prévio remunera a alta produtividade alcançada com times Scrum. Por
outro lado, esta cláusula se parece com um “paraquedas de ouro” que pode não ser politicamente
aceito no ambiente econômico atual.

Devemos sempre lembrar que ter um bom contrato é importante, mas ter um bom relacionamento
colaborativo é mais importante.

47
 Módulo Outros métodos ágeis
Programação Extrema
A Programação Extrema foi criada por Kent Beck e ganhou notoriedade a partir da OOPLSA 2000 (a maior
conferência internacional de Orientação a Objetos). A primeira reação a XP foi bem controversa. Alguns amaram
(normalmente os programadores), outros odiaram. Em XP, o bom programador se sente mais livre para fazer o
que faria se não existissem regras. Ao mesmo tempo, XP obriga o “mau” programador a se comportar de forma
similar ao bom.

A Programação Extrema é baseada em cinco valores, alguns princípios e várias práticas. Ela se destina

a times de até dez programadores, projetos de curto e médio prazo.

Os cinco valores de XP são:

• Comunicação – para um projeto de sucesso é necessária muita interação entre os membros da equipe,
programadores, cliente, treinador. Para desenvolver um produto, o time precisa ter muita qualidade
nos canais de comunicação. Conversas cara-a-cara são sempre melhores do que telefonemas, e-mails,
cartas ou fax.

• Feedback – as respostas às decisões tomadas devem ser rápidas e visíveis. Todos devem ter, o tempo
todo, consciência do que está acontecendo.

• Coragem – alterar um código em produção, sem causar bugs, com agilidade, exige muita coragem e
responsabilidade.

• Simplicidade – para atender rapidamente às necessidades do cliente, quase sempre um dos valores
mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo
que os programadores constróem.

• Respeito – todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso
mantém o trabalho energizado.

Em XP existem quatro papéis principais:

• Programadores – foco central da metodologia, sem hierarquia.

• Treinador (ou coach) – pessoa com mais experiência no time, responsável por lembrar os outros das
regras do jogo (que são as práticas e os valores de XP). O treinador não precisa necessariamente ser o
melhor programador da equipe e sim o que mais entende da metodologia XP.

• Acompanhador  (ou  tracker) – responsável por trazer para o time dados, gráficos, informações que
mostrem o andamento do projeto e ajudem a equipe a tomar decisões de implementação, arquitetura
e design. Algumas vezes o próprio coach faz papel de tracker. Outras o time escolhe sozinho quem
exercerá este papel.

• Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para responder às
dúvidas dos programadores.

Práticas de XP

48
 Esta é a parte principal da metodologia e é composta por:

• Planejamento – assim como no Scrum, existe uma fase de planejamento, quando desenvolvedores e
cliente se encontram para priorizar e estimar histórias.

• Fases Pequenas – cada fase é chamada de iteração (Sprint no Scrum). Elas devem durar no máximo 30
dias, mas o ideal é que seja 15 ou até 7 dias.

• Design Simples – seguindo o valor simplicidade, os projetos devem ser simples e atender a cada passo
somente o que foi pedido. Nada de matar formigas com canhão!

• Testes – todo desenvolvimento inclui testes. Kent Beck diz que código sem teste não existe. Os testes
devem ser escritos de preferência antes do desenvolvimento (TDD – test driven development) e sempre
devem rodar de forma automatizada.

• Refatoração  – é um conjunto de técnicas para modificar o código do sistema sem alterar nenhuma
funcionalidade. O objetivo é simplificar, melhorar o design, limpar, enfim, deixar o código mais fácil de
entender e dar manutenção.

• Programação Pareada – em XP dois programadores sentam juntos no mesmo computador e programam

juntos. Enquanto um programador digita, o outro observa, pensa em melhorias, alternativas. Falaremos
mais sobre a programação em pares e seus benefícios

• Propriedade Coletiva – O código fonte não pertence a um único programador. Todos da equipe são
responsáveis. Todos alteram código de todos (mas sempre rodando os testes para se certificar que
nada foi quebrado)

• Integração Contínua – depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada
entre todos os desenvolvedores. Quanto mais freqüente for essa integração, menores são as chances de
conflitos de arquivos que vários programadores alteram simultaneamente

• Semana de 40 horas  – programar é uma atividade intensa e que não rende se o programador não
estiver descansado e disposto. Por isso, 40 horas de trabalho por semana é essencial para a saúde do
time.

• Cliente Sempre Presente – o cliente não é alguém de fora, mas sim um membro da equipe. Ele deve
estar sempre disponível e pronto para atender às dúvidas dos desenvolvedores.

• Padronizações – se todo o time seguir padrões pré-acordados de codificação, mais fácil será manter
e entender o que já está feito. O uso de padrões é uma das formas de reforçar o valor comunicação.
Muitas dessas práticas são alvos freqüentes de críticas, como a programação em duplas – que seria um
desperdício de pessoal – e o refatoramento – que seria uma forma de retrabalho devido a um projeto
mal feito. No entanto, não é adequado julgar as práticas de forma isolada, já que cada uma delas tem
um papel no processo, ou como Highsmith define, “fortalecendo uma a outra de forma direta e sutil”
[13]. Por esse mesmo motivo, alterar alguma prática necessita um profundo entendimento do XP e da
equipe de trabalho, para não criar um problema sério no processo.

Métodos de Crystal
Crystal é uma família de metodologias de desenvolvimento de software e, como os cristais, possui diferentes
cores e rigidez, referindo-se ao tamanho e ao nível crítico do projeto.

49
 Criada por Alistair Cockburn e Jim Highsmith a fim de conseguir uma abordagem de desenvolvimento de
software que premia a “manobrabilidade” durante o que Cockburn caracteriza como “um jogo cooperativo
de invenções e comunicação de recursos limitados, com o principal objetivo de entregar softwares úteis
funcionando e com o objeto secundário de preparar-se para o jogo seguinte”.

Os métodos Crystal são focados nos talentos e nas habilidades das pessoas, permitindo que o processo
de desenvolvimento seja moldado conforme as características específicas da equipe, mesclando a sua cultura
de trabalho com a proposta de desenvolvimento ágil.

A metodologia Crystal utiliza dois parâmetros para adequar-se a ao projeto de software, sendo a primeira
métrica o número de pessoas envolvidas e a segunda métrica o nível crítico.

Parâmetros conforme o tamanho

Cada método Crystal é caracterizado por uma cor, de acordo com o número de envolvidos.

• Crystal Clear é uma metodologia leve, para equipes de uma a oito pessoas, podendo chegar até doze
em casos especiais;

• Yellow, para equipes por volta de dez a vinte membros;

• Orange e a variante Orange Web são apropriados para equipes de vinte a cinquenta participantes;

• Red para equipes de cinquenta a cem membros. Cada um dos métodos com graus de gerenciamento
e de comunicação ajustados de acordo com o tamanho da equipe.

Além das cores, o Crystal utiliza-se de algumas letras para representar potenciais perdas causados por
uma falha no sistema de desenvolvimento de software.

C de Confort (Conforto), casos em que a falha do sistema ocasiona a perda de credibilidade do usuário
devido ele não atender este conforto, como exemplo temos o serviço de um aparelho celular. Caso este falhe
o usuário devera utilizar-se de um outro ou ate mesmo utilizar-se de outros meios para realizar a comunicação
desejada.

D de Discretionary money (Dinheiro disponível para uso conforme necessário, cujo uso depende de decisão
de alguém com poder de decisão). Casos em que a falha do sistema ocasiona na perda de dinheiro, mas de valor
inexpressivo, tendo como exemplo o sistema de um caixa de um supermercado, tal falha pode impactar em
não cobrar determinados produtos ou cobrar produtos com um valor superior que logo seria descoberto por
clientes gerando a perda de valores, mas que não levará o mercado à falência.

E de Essencial money (Dinheiro essencial – dinheiro indispensável, absolutamente necessário) casos em

que a falha do sistema ocasiona a perda de um quantia indispensável, grandes valores, como exemplo temos o
sistema de reserva de uma companhia aérea, esta não funcionando ocasionará a perda de valores significativos
devidos aos gastos que a mesma acarretaria e assim na qual pode culminar até mesmo na falência da empresa.

L de Life (vida)  casos em que a falha do sistema ocasiona a perda de Vidas, tendo como referência
um software de piloto automático onde sua falha poderia derrubar um avião e matar seus tripulantes.
Grandes projetos geralmente requisitam mais coordenação e metodologias mais rígidas que projetos menores,
ou quanto mais crítico for o software. Tanto que o Crystal Clear, não trata dos aspectos relacionados a projetos
onde o dinheiro é essencial, mas a equipe poderá estender o Crystal Clear para isso.

50
 Características da metodologia Crystal

Independentemente de qual implementação Crystal você escolhe, você encontrará sete princípios-chave
em cada um:

• Entrega freqüente

• Feedback contínuo:  direção esperada e comunicar quaisquer novas descobertas que podem afetar o
projeto.

• Comunicação Constante

• Segurança

• Foco

• Acesso para usuários

• Testes automatizados e integração

Métodos de Desenvolvimento de Sistemas Dinâmicos (MDSD)

O MDSD ou ainda Dynamic Systems Development Method (DSDM) em inglês foca na criação de protótipos
que evoluem para o sistema, utilizando para isso a colaboração muito próxima do cliente.

As idéias principais do MDSD podem ser observadas no conjunto de princípios que foram definidos para
nortear o método:

• O envolvimento ativo do usuário é imperativo.

• O time deve ter o poder para tomar decisões.

• O foco é na entrega freqüente de produtos.

• O encaixe ao propósito do negócio é o critério essencial para a aceitação das entregas.

• O desenvolvimento iterativo e incremental é necessário para convergir com precisão às

• soluções do negócio.

• Todas as mudanças durante o desenvolvimento são reversíveis.

• Requisitos são alinhados em um alto nível.

• O teste é integrado por todo o ciclo de vida.

• Uma abordagem colaborativa e cooperativa entre as partes envolvidas é essencial.

É possível notar com esses princípios que o cliente e o negócio são os pontos essenciais do método,
enquanto que os aspectos técnicos, como a programação, são pouco abordados, o que fica ainda mais
evidente na descrição do processo. Esse enfoque e o fato do MDSD ser visto como um arcabouço faz com que
existam soluções para mesclá-lo a outros métodos, sendo possível a utilização em conjunto, por exemplo,
com o XP ou o RUP, mas ainda mantendo os princípios definidos no MDSD.

51
 Além desses princípios, existem algumas técnicas principais que são usadas durante a execução de um
projeto usando MDSD :

• Time-boxes: definição de um período fixo para a execução do projeto, colocando até datas de entrega.
Com isso, caso haja alguma funcionalidade que não possa ser implementada durante o período
estipulado, ela deve ser feita após o desenvolvimento em si (antes da fase de pós-projeto).

• MoSCoW: regra básica para a priorização de requisitos durante o período de desenvolvimento. A idéia
fundamental é priorizar e implementar os requisitos que sejam considerados principais, deixando os
menos importantes para depois.

• Modelagem: não deve ser uma atividade burocrática, sendo usada para prover um melhor
entendimento do problema e da solução.

• Prototipação: forma de verificar a adequação dos requisitos e facilitar as discussões com o cliente. O
protótipo criado deve evoluir juntamente com o projeto.

• Teste: essa atividade deve ser executada sistematicamente e de forma contínua durante o projeto.

• Gerência de configuração: essencial, visto que os produtos são entregues com uma grande freqüência.

Desenvolvimento Orientado a Funcionalidade (FDD - Feature Driven De-

velopment)
O Feature-Driven Development (FDD) é um método que tem um foco grande na modelagem (diagrama de
classes e seqüência) e utiliza como forma de planejamento e medição as características, ou melhor, “funções
com valor ao cliente” .

Os gerentes reduzem riscos ao entregar “resultados freqüentes, tangíveis e funcionando”, além de poder
usar as características como forma de medição, gerando relatórios com porcentagens. Os clientes recebem
freqüentemente resultados que eles entendem e também podem saber a qualquer momento o andamento
do projeto com precisão. Para que seja possível gerenciar de forma adequada as características, o FDD define
papéis, práticas e um processo de maneira bastante simples.

Em relação aos papéis, apesar de serem definidos diversos como, por exemplo, o gerente e o arquiteto
chefe, existem dois papéis que são principais: o “dono” da classe e o chefe programador. O chefe programador
é um desenvolvedor que cuida da implementação de algumas das características, criando um time para o
desenvolvimento através da verificação de quais são as classes que serão usadas e recrutando seus respectivos
“donos”.

Com isso, podem existir (dependendo do tamanho da equipe) diversos times de desenvolvimento, o
que pode fazer com que os desenvolvedores trabalhem em mais de um time (recomenda-se no máximo
3) durante uma iteração. O interessante é que o chefe programador é também “dono” de algumas classes,
podendo ser recrutado para a participação de um time liderado por outro chefe programador. Em relação
às práticas definidas no FDD, elas não são extremamente rígidas, pregando a adaptação ao ambiente de
desenvolvimento. No entanto, existe um conjunto de práticas que são fundamentais e que definem o FDD:

Modelagem em objetos de domínio: construir um diagrama de classes básico com os objetos de domínio
e suas relações, definindo assim uma arquitetura básica para o modelo do sistema.

• Desenvolvimento por características: a implementação deve ser orientada pelas características.

52
 • Autoria individual: o código é de autoria de um “dono” da classe, o que permite uma maior rapidez na
implementação das tarefas associadas.

• Times da característica: para a implementação de uma determinada característica, o chefe programador

recruta os “donos” das classes que serão usadas. Esse grupo de pessoas é o time da característica.

• Inspeções: a forma de verificação de qualidade do código e do projeto.

• Integração (build) regular: em um determinado período de tempo fixo devem ser integradas as
características já terminadas, permitindo a verificação de erros e também criando uma versão atual
que pode ser demonstrada ao cliente.

• Gerencia da configuração: manter versões de todos os artefatos criados.

• Reportar/visibilidade dos resultados: permitir que se conheça o progresso do projeto.

Desenvolvimento Orientado a Testes (TDD - Test Driven Development)

Test Driven Development, ou em português Desenvolvimento guiado por testes, é definido como uma
técnica de desenvolvimento de software que se baseia em um ciclo curto de repetições.

No TDD você desenvolve os testes do software antes mesmo de desenvolver o software. Para cada “peça”
da aplicação que deverá ser construída, os testes são escritos ANTES com base nas entradas e saídas dos
métodos/funcionalidades do sistema.

A prática,  é simples: escreva um teste que falha, faça-o passar da maneira mais simples possível e, por
fim, refatore o código. Esse ciclo é conhecido como Ciclo Vermelho-Verde-Refatora.

Os princípios fundamentos que devemos ter ao adotar o TDD:

• Escrever o teste da implementação antes de escrever o código a ser implementado inteiro (code core);

• Escrever apenas o código suficiente para o teste, e se contentar com isso (controle sua ansiedade);

• Escrever testes pequenos, testando a menor quantidade possível de código de cada vez;

• Escrever testes rápidos (não é programar rápido e sim testes que executem rápido).

O ciclo de vida do TDD

Criar o teste;

Executar todos os possíveis testes e verificar se ocorre alguma falha na aplicação(barra vermelha no JUnit
por exemplo);

Escrever a aplicação a ser testada;

Executar os testes para ver se todos passarão;

Refatorar;

Executar os testes novamente e garantir que eles continuem passando(princípio de refatoração);

53
Vantagens do Uso do TDD:
• Feedback rápido sobre a nova funcionalidade e sobre as outras funcionalidades existentes no sistema;

• Código mais limpo, já que escrevemos códigos simples para o teste passar;

• Segurança na refatoração pois podemos ver o que estamos ou não afetando no sistema;

• Segurança na correção de bugs;

• Maior produtividade já que o desenvolvedor encontra menos bugs e não desperdiça tempo em
depuração;

• Código da aplicação mais flexível, já que para escrever testes temos que separar em pequenos
“pedaços” o nosso código, para que sejam testáveis, ou seja, nosso código estará menos acoplado;

Kanban
Já vimos em aulas anteriores o quadro Kanban, nesta aula vamos ver mais alguns detalhes sobre esta técnica.

O Kanban é um sistema que visa aumentar a eficiência da produção e otimizar seus sistemas de
movimentação, produção, realização de tarefas e conclusão de demandas. E nesta aula vamos ver como ele
pode ser usado no Scrum.

Também conhecido como método de gestão visual, o Kanban faz parte de uma das técnicas desenvolvidas
pelos japoneses da Toyota há mais de 50 anos dentro do modo de produção Just In Time (JIT), ou seja, o Kanban
não é o JIT, mas sim, parte dele. E o Kanban não é o Scrum, e sim uma ferramenta poderosa de acompanhamento
de projetos que usem esse framework. O Kanban se baseia em cinco pilares:

• Foco na qualidade;

• Redução do trabalho em progresso, permitindo entregas frequentes;

• Redução da variação do fluxo de processo;

• Priorização de demandas;

• Processo Puxado

No Kanban colocam-se murais ou softwares semelhantes em um espaço que possa ser visualizado por
todos os funcionários responsáveis por desempenhar ações naquela linha de produção. Os murais costumam
ser divididos em três seções, originalmente: To do (por fazer), Doing (fazendo/em execução) e Done (feito/
concluído). Mais seções ainda são possíveis, de acordo com a especificidade de cada atividade organizada
através do Kanban.

Em cada uma destas seções são adesivadas (ou registradas eletronicamente) as ações recorrentes da
produção daquela empresa. Nos papéis ou arquivos costuma existir uma breve descrição da atividade a ser
realizada, o horário de entrada e, preferencialmente, um horário limite ou referência para a saída e o nome do
colaborador responsável por desempenhar aquela função.

Como as atividades das empresas ou indústrias são as mais variadas possíveis, a título de simplificação do
entendimento, muitas vezes são utilizados Kanbans de cores ou tamanhos diferentes para que a visualização
seja muito mais rápida e eficaz por parte dos profissionais responsáveis.

54
O Kanban fora da indústria
O sistema Kanban pode ser utilizado com muita eficiência também fora do setor industrial. Empresas que
se baseiam em escritórios ou prestações de serviços também utilizam a técnica da gestão visual para evitar que
seus funcionários fiquem ociosos ao longo da jornada de trabalho, e para garantir que todas as atividades sejam
realizadas dentro do tempo definido para elas ou, de preferência, antes do tempo destinado. Mas sempre
visando que as ações anteriores não sejam feitas antes das posteriores, inviabilizando o processo ágil que é
pressuposto do sistema Kanban.

O uso é bastante parecido ao da indústria, com murais, post-its ou softwares para realizar a gestão, a
comunicação e a divulgação das informações organizacionais de prazos, atividades e profissionais responsáveis
por determinadas ações.

Dicas para o uso do Kanban

Limite o número de atividades que podem ser feitas simultaneamente dentro de seu projeto com os Kanbans.
É interessante que estas atividades sejam limitadas justamente para evitar o inverso do ócio– a sobrecarga de
alguns funcionários em atividades que deveriam ser feitas por mais pessoas, ou que deveriam aguardar para
que possam ser realizadas com dedicação exclusiva do colaborador responsável.

55
 Módulo: Tópicos para Prova ASF
Workspace / Comunicação Osmótica e Times distribuídos
Nesta aula veremos 3 tópicos muito importantes ligados ao melhor local de trabalho recomendado
quando falamos de equipes ágeis e por consequência, times Scrum.

Espaço de trabalho adequado

Os eventos do Scrum são ferramentas de comunicação, e é importante ter um ambiente adequado para
que possamos realizá-los. Por exemplo, um dos requisitos é que o time seja “co-localizado” na mesma sala,
em vez de ser distribuído nos diferentes departamentos da organização. Esta é sem dúvida uma medida que
contribui para melhorar a relação entre todos os membros da equipe e facilita sua colaboração.

Comunicação osmótica
A co-localização dos membros do time em um mesmo espaço não só contribui para facilitar a troca
de ideias, como também para facilita a comunicação osmótica, ou seja, os membros da equipe capturam
informação relevante como se por osmose, apenas ouvindo o que outros membros estão dizendo.

Isso normalmente ocorre porque todos estão na mesma sala e quando uma pessoa faz uma pergunta,
outros podem ouvir e contribuir para a discussão.

Maximizar a comunicação osmótica é uma boa prática. E isso é facilmente atingido quando temos uma
co-localização adequada.

Equipes distribuídas
Embora seja altamente recomendável que os times Scrum estejam trabalhando todos no mesmo local,
nem sempre isso é possível. Em grandes projetos, podemos ter membros e distribuídos em várias cidades e
até mesmo países. Mesmo assim, ainda é possível usar o Scrum. Mas neste caso devemos fazer o melhor uso
possível das ferramentas de comunicação atuais para facilitar a interação entre todos os membros. O uso de
ferramentas de vídeo chamada tais como Skype, Hangout e outras podem e devem ser utilizadas.

Planejamento em camadas (Planning Onion)

Nesta aula veremos que em todos os projetos ágeis existem diferentes níveis de planejamento. E isso é
representado no inglês por uma cebola com várias camadas. Para o português, o Planning Onion foi traduzido
como Planejamento em camadas, ainda bem...

Em um projeto ágil existem diferentes níveis de planejamento dispostos em diferentes camadas

sobrepostas.

E os níveis são:

1. Planejamento de Produto - é realizado para o Backlog do produto. Muitas vezes é um planejamento

que envolve altas esferas da organização e que exige também o desenvolvimento da Visão do Produto.

2. Planejamento de entregas – aqui definimos as entregas do produto, ou seja, o plano de releases é

elaborado. Nesse plano indicamos quais as datas de liberação de novos incrementos para os usuários finais.

3. Planejando a iteração - no Scrum este nível de planejamento é feito durante a reunião Planejamento

56
da Sprint, durante a qual o Backlog da Sprint é criado.

4. Planejando o dia - no Scrum este nível de planejamento é feito nas reuniões diárias, onde o time vai
planejar o que fará nas próximas 24 horas.

Os demais níveis de planejamento, ficam fora dos limites de projetos Scrum. De forma breve, temos que
no nível de planejamento estratégico os objetivos da organização são definidos e estabelecidos. E ao nível de
portfólio, devemos selecionar e financiar os melhores projetos para alcançar os objetivos estabelecidos no
nível anterior, o estratégico.

Planejamento por Sucessão

Nesta aula veremos o que é o planejamento da sucessão e como ele está relacionado à continuidade de
projetos Scrum.

O planejamento por Sucessão é uma técnica que promove o conceito de evoluir a arquitetura de um
sistema apenas “o suficiente para o momento atual”, considerando apenas o que é relevante para o presente
e o que será necessário para a próxima versão.

Os métodos ágeis não incentivam o desenvolvimento completo da arquitetura do sistema logo nas
primeiras sprints, já que muitas vezes esse desenvolvimento não vai entregar nenhuma funcionalidade que
possa ser testada pelo cliente. Assim, desenvolvemos exatamente o necessário para que uma funcionalidade
possa ser liberada.

À medida que o projeto vai evoluindo a arquitetura vai sendo remodelada e entregue na medida exata da
necessidade da construção do produto.

Muita gente acha que já deixar toda a arquitetura pronta o quanto antes será um ganho de
produtividade, de evolução do sistema, de estratégia de mercado ou até de menor custo, porém, às vezes boa
parte dessa arquitetura pode acabar não sendo usada, por modificações de tecnologia, funcionalidades etc e
o que se teve foi apenas desperdício de tempo e dinheiro.

O planejamento por sucessão incentiva o design simples, ou seja, nada de penduricalhos desnecessários.

Várias práticas ágeis, incluindo o Extreme Programming sugerem manter a arquitetura simples e somente
com o tempo, e conforme a necessidade, evoluir seus códigos.

Integração continua e refatoração

Já vimos em uma aula anterior várias práticas da Extremme Programming. Nesta aula veremos em
detalhes duas delas a integração continua e a refatoração.

Integração Continua
A integração contínua consiste em integrar forma automática “as partes” de um projeto o mais
frequentemente possível para que possamos ser capazes de detectar falhas o quanto antes.

Em projetos que utilizam o método cascata, essa integração é feita ao final do projeto, o que chamamos
de lançamento Big Bang, porque normalmente vai tudo pelos ares, já que vai se levar muito tempo para fazer
o produto funcionar.

A integração continua exige que todos os programadores subam as últimas versões de seus códigos
para o repositório a cada uma ou duas horas e que seja integrado ao incremente ali existente. Para isso, essa

57
prática requer um sistema de controle confiável dessas liberações, pois muitas vezes elas vão direto para o
cliente.

Algumas das vantagens da integração continua são

-É mais fácil conseguir incrementos reais no final das iterações ou sprint; já que passamos o tempo todo
integrando trechos de código e liberando para operação.

- Ele permite detectar e resolver problemas de integração continuamente, evitando o caos de última hora
muito comum em lançamentos Bing Bang.

Refatoração contínua
A refatoração consiste em revisar o código com o objetivo de melhorar sua estrutura interna sem alterar
seu comportamento externo. A meta é manter um código limpo e estruturado.

Esta técnica envolve dedicar parte do tempo de desenvolvimento na melhoria do código, e com isso
facilitar a sua manutenção futura. Esta é uma boa técnica para diminuir o débito técnico.

Triangulação e estimativa por afinidade

Nesta aula veremos duas técnicas de estimativa utilizadas em projetos ágeis. Já as vimos em aulas
anteriores com outros nomes, por isso nesta aula faremos uma breve referência de cada uma delas.

Triangulação

A técnica de triangulação é aplicada naturalmente quando se utilizamos o Planning Poker para estimar,
pois a triangulação se dá quando o time pega uma história e a compara com outras duas para saber
exatamente onde encaixá-la.

Veja o exemplo:

O Time já estimou as seguintes histórias:

• História 15 — Tem o esforço estimado de 10

• História 22 — Tem o esforço estimado de 30

• História 54 - Tem o esforço estimado de 5

• História 19 — Tem o esforço estimado de 15

O Time recebe a nova história 61 e discute brevemente entre si. O Time decide então que a história 61 é
maior que a história 15 e é menor que a história 19. Assim ela terá uma estimativa de esforço maior que 10 e
menor que 15 pontos. Podemos então imaginar que ela terá esforço estimado de 13 pontos.

Essa comparação de três pontos é chamada de triangulação e permite encaixar uma história entre outras
duas com menor e maior esforço.

58
Estimativa de afinidade
Estimar por afinidade é a ação de determinar o tamanho e/ou esforço de grupos de histórias com
classificações similares. Esta é uma técnica utilizada para estimar rapidamente um grande número de histórias
de Usuário.

Frequentemente são utilizadas as definições de tamanho da estimativa T-shirt, que vimos em uma aula
anterior. Essa técnica separa os tamanhos e/ou esforços das histórias como camisetas, tais como PP, P, M, G e
GG. Com base na estimativa T-shirt, o time agrupa as histórias em categorias, coleções ou temas similares e
determina qual o tamanho T-shirt de cada grupo.

Tais equivalências PP, P, M, G e GG podem ser convertidas para pontos de história, horas ou outra unidade
de medida que o Time entenda e com a qual tenha familiaridade.

Horas ideais / dias ideais e Tempo decorrido

Nesta aula veremos 3 tópicos que se inter-relacionam: os dias ideais, as horas ideais e o tempo decorrido.

Dias ideais
Um dia ideal é aquele no qual uma quantidade de trabalho é realizada sem qualquer interrupção ou
distração. É um dia em que hipoteticamente tudo está perfeito e disponível, nada dá errado e até a inspiração
profissional está alta.

O dia ideal é aquele em que o desenvolvedor trabalhará apenas na sua história, e tudo o que ele precisará
para completar o seu trabalho estará imediatamente à mão.

É importante reforçar que o dia ideal não é real e raramente irá acontecer se não houver uma conspiração
positiva para favorecê-lo, portanto é recomendado não utilizar o dia ideal para estimar o tempo, mas sim o
esforço em relação à conclusão de uma história.

Horas ideais
As horas ideias são simplesmente as horas realmente produtivas durante um dia de trabalho.

Muitos ainda insistem em prever oito horas de trabalho para um profissional durante o dia. Para que um
profissional trabalhe e produza realmente oito horas por dia será preciso que ele não levante, não interaja com
ninguém, não tome café, não vá ao banheiro, não atenda o telefone, não leia e-mails ou seja, se isole e trabalhe
freneticamente.

Quem realmente acredita que isso é possível?

Quando se estima pensando que um dia tem oito horas de produção de código e de desenvolvimento de
sistema, já está começando atrasado, pois haverá pelo menos duas horas a menos por dia de produção e ao final
do mês serão 40 horas de atraso por pessoa, ou seja, uma semana atrasada.

É comprovado que as horas ideais de trabalho em um dia giram em torno de quatro a seis horas, afinal é
impossível ficar focado em uma tarefa por oito horas seguidas – além do que todos precisamos nos alimentar,
ir ao banheiro, ligar para clientes, participar de reuniões etc.

Sendo assim, para não errar, considere no máximo seis horas diárias de produção real. Com isso, uma
semana de trabalho de 40 horas produzirá em torno de 30 horas reais, completando em um mês de 120 a 130
horas de produção efetiva.
59
Tempo decorrido
O tempo decorrido é aquele contado no relógio, independentemente do tempo real produzido ou do
tempo ideal de trabalho.

Assim o tempo decorrido é aquele que vai desde o início de uma tarefa até a sua finalização. E isso pode
incluir interrupções, folgas etc.

Um exemplo bem trivial é quando você assiste a uma série no Netflix. A depender da série, cada episódio
terá a duração de por exemplo 45 minutos. Já na TV aberta, se esse mesmo episódio for veiculado, ele será
exibido em 60 minutos, pois com certeza teremos intervalos comerciais. Assim, embora o “esforço” de exibição
tenha sido de 45 minutos, o tempo decorrido no caso da TV aberta será de 60.

Em outras palavras, o tempo decorrido é aquele do relógio e do calendário, sem considerar esforço ou horas
ideais.

E veja que para o cliente, em um atraso geralmente é observado em tempo decorrido, pois se algo deveria
ter sido entregue no dia 20 e isso ocorreu apenas no dia 24, houve quatro dias de atraso e para ele não importa
quanto de esforço foi realizado nesse meio tempo.

Defeito que escapou (Escaped Defect)

Nesta aula veremos o que é o escaped defect, ou defeito que escapou.

Defeito que escapou é uma tradução livre para escaped defect, e esses são os defeitos que escaparam dos
processos de testes e dos trabalhos da equipe de qualidade de software e que geralmente são descobertos
pelos clientes ou pelas operações de usuários fora das etapas de validação previstas.

Um defeito desse tipo gera insegurança e muitas vezes desgasta a relação de confiança existente entre
o fornecedor de software e seu cliente, pois a última coisa que um usuário de software quer ver é um erro
explodindo na sua tela exatamente no momento em que ele precisa realizar emitir um relatório urgente para o
chefe que está esperando na sala de reunião.

Por isso é importante implantar um mecanismo de análise desses defeitos, de modo a mapeá-los e evitá-los
no futuro. O defeito que escapou deve ser estudado pelos times de desenvolvimento e de qualidade, para que
este seja capturado ao longo da validação e não apareça mais em entregas futuras.

Diversas estratégias podem ser aplicadas para minimizar os escaped defects, tais como o acréscimo de
testes unitários, a implantação de testes integrados e/ou automatizados e outras técnicas sugeridas pelo TDD.

E muitas vezes é na definição de Pronto que essas estratégias são aplicadas.

Divisão de times
Muitas vezes, no início do projeto, não temos a exata noção se precisaremos de mais de um time Scrum.
E à medida que o projeto progride descobrimos que realmente iremos precisar de mais de um time. E como
fazer isso é o que veremos nesta aula.

Existem diferentes maneiras de formar novas equipes, entre elas:

- Forme equipes completamente novas: essa é uma boa opção quando a organização já conhece bem os
métodos ágeis e já tem equipes formadas. Porém, esse novo time não estará suficientemente familiarizado
60
com o projeto, o que causará ineficiências a curto prazo.

- Dividir equipes usando o modelo Split-and-seed: neste modelo a equipe original é dividida em várias
equipes, e novos membros são adicionados a essas equipes. A vantagem deste modelo é que o conhecimento
do projeto é distribuído entre todas as equipes. A desvantagem é que perdemos o time original.

- Dividir equipes usando o modelo Grow-and-Split: é bem semelhante ao anterior, mas mais gradual.
Neste caso, novos membros são adicionados ao time existente até que ele atinja a capacidade de 9 membros
para o time de desenvolvimento. Atingido esse número, dividimos a equipe em duas e deixamos crescer. E aí
dividimos de novamente.

Os modelos Grow-and-Split e Split-and-seed são ótimos também para disseminação e adoção de modelos
ágeis dentro da organização: podemos começar implementando o Scrum em um projeto-piloto, e quando o
time já está bem treinado podemos dividi-lo para criar novos times.

Veja que em qualquer um dos tipos de divisão de times, uma queda na produtividade será observada,
pois membros dos times originais estarão treinando os novos membros.

O Bus Factor (Fator ônibus)

O fator ônibus, do inglês, Bus Factor se refere ao número de membros de uma equipe que poderia ser
“atropelado por um ônibus” sem que o projeto seja encerrado por falta de pessoal competente. E é isto o que
veremos nesta aula.

É um tanto tenebroso pensar que seu time será atropelado por um ônibus, mas no fundo o Bus Factor
trata da questão de que o conhecimento do projeto não deve ficar concentrado em apenas algumas pessoas.
Pois se uma delas tiver que se ausentar, mudar de emprego, tirar férias, se aposentar, ganhar na loteria ou até
mesmo se por infelicidade seja realmente atropelada, será que seu projeto conseguirá prosseguir sem ela?

Então, ao perdermos um dos membros da equipe do projeto, independentemente do motivo, será que
seremos capazes de continuar com o projeto, já que ninguém mais tem a informação, ou o conhecimento
chave desse membro? Se a resposta for não, temos o Bus Factor com o índice 1, ou seja, uma pessoa se
ausentou e o projeto parou. Péssimo isso, não?

Quanto maior o índice, melhor para o projeto, pois isso indica que para o projeto parar mais pessoas
precisariam desaparecer.

Os métodos ágeis são ótimos para manter o Bus Factor em níveis elevados, já que esses métodos
incentivam o conhecimento compartilhado e times multifuncionais.

Tipos de contratos e o Scrum

Este é um tópico de dar dor de cabeça em quem tem que tratar das formas de contratação disponíveis
quando estamos rodando projetos Scrum. Como o cliente será cobrado? Por funcionalidade entregue? Por
incremento rodando? Por dias que foram trabalhados? Nesta aula veremos os tipos mais comuns.

Existem e tipos de contrato recomendados:

Tempo e Materiais (ou tempo e recursos): Com este modelo, cobramos o cliente com base na quantidade
de homens/hora utilizados por Sprint. Este é o tipo preferencial de contrato para o fornecedor do software, já
que independentemente do que será entregue, o cliente vai ter que pagar.

61
 Preço fixo: Este tipo de contrato tem se tornado muito popular entre os clientes, pois ele passa o
maior risco para o desenvolvedor. Se o projeto atrasa, o desenvolvedor arca com os custos. Este tipo de
acordo não é amigável em casos de mudança de escopo, o que pode em certo estágio do projeto causar
desentendimentos sobre o que está ou não no escopo.

Nesta aula mostramos um pequeno resumo dos tipos de contratos recomendados quando tratamos de
projetos Scrum. Não há necessidade de se aprofundar no tema, pois é neste nível que será cobrado na prova
de certificação.

62