Metodologias Ageis E Book 2018 PDF
Metodologias Ageis E Book 2018 PDF
Metodologias Ageis E Book 2018 PDF
2
Sumário
Sumário ........................................................................................................................................ 3
Apresentação .............................................................................................................................. 5
Capítulo 1 - Mergulhando nos princípios ágeis ..................................................................... 7
1. Como surgiu ............................................................................................................... 7
2. O que as metodologias ágeis não são e não pregam ....................................... 11
3. O que as metodologias ágeis são e pregam....................................................... 12
4. Manifesto Ágil........................................................................................................... 12
5. Os doze princípios ................................................................................................... 12
Capítulo 2 – Scrum................................................................................................................... 14
6. Princípios e fundamentos ....................................................................................... 14
7. Os papéis .................................................................................................................. 16
Dono do produto / product owner (PO) ......................................................................... 17
Scrum Master (SM) .......................................................................................................... 17
Equipe de Desenvolvimento ........................................................................................... 17
8. Os artefatos .............................................................................................................. 17
Backlog do produto / product backlog ........................................................................... 18
Backlog do Sprint / Sprint backlog ................................................................................. 20
Incremento do produto..................................................................................................... 20
9. As cerimônias........................................................................................................... 21
Sprint .................................................................................................................................. 21
Reunião de planejamento da Sprint / planning meeting / Sprint planning ............... 22
Reunião Diária / Daily Meeting /Daily Scrum ............................................................... 22
Revisão da Sprint / Sprint Review ................................................................................. 23
Retrospectiva / Retrospective ......................................................................................... 23
10. Gráfico de burndown ............................................................................................... 24
Capitulo 3 - Existe vida além do Scrum ................................................................................ 26
11. FDD – Featrue Driven Development .................................................................... 26
DMA – Desenvolver um modelo abrangente ............................................................... 27
CLF – Construir a lista de funcionalidades ................................................................... 27
PPF – Planejar por funcionalidade ................................................................................ 28
DPF – Detalhar por funcionalidade................................................................................ 28
3
CPF – Construir por Funcionalidade ............................................................................. 28
12. OpenUP .................................................................................................................... 28
Princípios do OpenUP ..................................................................................................... 28
Micro incremento .............................................................................................................. 28
Ciclo de vida da iteração ................................................................................................. 28
Ciclo de vida do projeto ................................................................................................... 28
13. Kanban ...................................................................................................................... 30
Diagrama de fluxo cumulativo (Cumulative Flow Diagram) ....................................... 32
Lead time ........................................................................................................................... 34
Tempo de ciclo .................................................................................................................. 35
Throughput: ....................................................................................................................... 36
Índice de defeitos ............................................................................................................. 37
14. Scrum e Kanban, por que não usá-los simultaneamente?! .............................. 39
15. Lean ........................................................................................................................... 41
Capítulo 4 - Agilidade na codificação – eXtreme Programming (XP) .............................. 43
16. Valores ...................................................................................................................... 43
17. Princípios .................................................................................................................. 44
18. Práticas para codificação ....................................................................................... 45
Referências: .............................................................................................................................. 49
Referências das figuras: .......................................................................................................... 51
4
Apresentação
Olá, este é o livro de metodologias ágeis, que foi elaborado especialmente para você
conhecer ou aprimorar as diversas práticas e ferramentas no desenvolvimento de
software. O conteúdo deste livro se aplica a codificadores, gerentes de projetos,
implantadores, analistas, testadores e donos de produtos (que já é uma terminologia
ágil).
Meu nome é Wagner Mendes Voltz e sou o autor deste livro. Minha formação é em
Tecnologia em Informática pela Universidade Federal do Paraná (UFPR) e o ano de
conclusão desta graduação foi em 2005.
Creio que esta especialização trouxe uma nova visão de como trabalhar com pessoas
e computadores e o desejo de lecionar já era existente em 2007.
Em 2011, tive o meu primeiro contato com agilidade. Uma consultoria, que visitou o
lugar onde eu trabalhava, nos apresentou o Scrum. Gostei tanto que investi tempo
esforço para me certificar neste framework, com isto me tornei um CSM (Certified
Scrum Master) pela Scrum Alliance.
Com o passar dos anos fui percebendo a necessidade de aprender outros “sabores”
da agilidade e fui sendo apresentado para a imagem que está no início do livro.
5
Hoje estudo de tudo um pouco e amplio a minha caixa de ferramentas e tento
identificar qual é o momento para usar cada um dos aprendizados.
Espero que este livro possa lhe ajudar a conhecer um pouco mais deste assunto.
6
Capítulo 1 - Mergulhando nos princípios ágeis
Como surgiu
A tecnologia é parte do nosso dia a dia e para interagirmos com ela, faz-se necessário
o uso de diversos dispositivos. Como exemplo, podemos citar os notebooks,
smartphones e tablets. E para cada um destes dispositivos temos pelo menos um
software em funcionamento. E como cada um de nós tem uma necessidade, existe
uma imensa oportunidade na produção de softwares para atender esta demanda.
Talvez esta seja a indústria que mais cresceu nos últimos anos.
A produção de um software não é tão simples quanto parecer ser. E nem tão pouco é
um trabalho repetitivo, como o de um operário em uma indústria. A produção de
software está muito mais próxima da criação de uma obra criativa (como um quadro ou
música), do que o trabalho fabril executado em fábricas.
Os modelos acima citados têm suas características e premissas, mas muitas das
vezes eles não atendem a velocidade que a indústria de software requisita. Por
exemplo, o modelo em cascata prevê que todos os requisitos estejam definidos e
escritos para daí começar a etapa seguinte, a de elaboração do projeto. Em sequência
começa a implementação e codificação dos requisitos. Após esta etapa, começam os
testes e em sequência a implantação do software. Com isto, chegamos ao fim do
processo. Uma nova rodada destes passos deve começar, repetindo todas as etapas.
7
Figura 2- Modelo em cascata
Para não ficarmos somente na teoria, vamos olhar alguns fatos identificados em
projetos que estavam usando estes modelos tradicionais. Para isto, vamos considerar
um estudo que o Standish Group, uma empresa localizada em Massachusetts, EUA,
publica desde 1994 e permanece até os dias atuais. Este estudo é chamado CHAOS
Report.
• Mal sucedido;
• Comprometido e
• Bem sucedido.
8
Em 2000, o resultado final da pesquisa mostrou a seguinte distribuição entre os
projetos:
Figura 4 - Histórico dos indicadores dos projetos de software entre 1994 e 2000
9
funcionalidades encontradas em um sistema típico jamais são usadas e 19 por cento
raramente são usadas:
Os dados são de mais de 10 anos atrás, mas o relatório CHAOS continua sendo
publicado e os comportamentos de muitos projetos ainda estão semelhantes aos
reportados há 10 anos. Os projetos que tem melhorado o desempenho deve-se, em
especial, a adoção de metodologias ágeis. Para entender um pouco mais da diferença
do modelo tradicional para o ágil, Prikladnicki, Willi e Milani (2014) elaborou o seguinte
quadro:
10
Figura 6 - Diferença modelo tradicional e metodologias ágeis
11
Nada pode ser melhorado se não tiver sido medido. A inspeção é um
item muito presente nas metodologias ágeis.
Para entender mais o que é pregado, leia o manifesto ágil, que é foi elaborado por 17
engenheiros de software e neste manifesto encontramos os princípios que
fundamentam o desenvolvimento ágil de software.
Manifesto Ágil
Foi publicado em 2001 por um grupo de agilistas. Seu conteúdo está disponível em
www.manifestoagil.com.br e pode ser conferido abaixo:
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda.
Os doze princípios
No mesmo site onde encontramos o Manifesto Ágil, é possível identificar os princípios
que embasam o manifesto. São eles:
12
• Entregar software funcionando com frequência, na escala de semanas até meses, com
preferência aos períodos mais curtos.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.
Fonte: http://www.manifestoagil.com.br/principios.html
13
Capítulo 2 – Scrum
Princípios e fundamentos
O termo Scrum é muito comum para um jogador de rugby. Ele representa uma
formação que ambos os times, unidos, vão em busca da bola. A formação Scrum deve
ser feita para reiniciar uma partida que foi para por uma jogada irregular ou
penalização.
A figura acima mostra a posição Scrum sendo realizado poucos momentos antes da
bola ser colocada em disputa.
A partir daí, o Scrum tornou-se a metodologia mais empregada no mundo ágil. Como
características do Scrum temos conceitos de Lean, desenvolvimento iterativo e
incremental, teoria das restrições, teoria de sistemas adaptativos complexos e do
14
estudo de Takeuchi e Nonaka, somadas com experiências positivas vividas por
profissionais de desenvolvimento de software.
A transparência diz que os processos devem estar visíveis aos responsáveis pelos
resultados. Para isto, faz-se necessário um padrão comum para que todos
compartilhem do mesmo entendimento do que está sendo visto. Exemplo: uma
definição de pronto deve ser clara e compartilhada por todos. Quando um membro do
time falar que uma funcionalidade está pronta, todos saberão o que isto significa.
15
Figura 8 – o framework Scrum
• Três papéis
• Três artesanatos
• Quatro cerimônias
Os papéis
16
Dono do produto / product owner (PO)
É responsável por gerenciar o backlog do produto, garantir o ROI (retorno do
investimento), definir a visão do produto, gerenciar a entrada de novos requisitos e
definir a prioridade e aceitar ou rejeitar o que será entregue no final de cada iteração.
O dono do produto é comumente chamado de PO, que quer dizer product owner.
Equipe de Desenvolvimento
É uma equipe responsável por desenvolver incrementos no produto. Também é
responsável pela estimativa quanto ao tamanho dos itens do backlog. A equipe deve
ser auto-organizada e nem muito grande. O Scrum Guide sugere times 7 pessoas.
Mike Cohn, conta em seu livro Succeeding with Agile, como a Amazon monta os seus
times de Scrum. A Amazon sugere o tema “times de 2 pizzas” por afirmar que o time
deve ter o número de pessoas que possa ser alimentado com apenas duas pizzas.
Esta é uma boa referência na hora de trabalhar com Scrum. Os benefícios de ter um
time de 2 pizzas são:
Os artefatos
Um artefato dá uma visão do andamento do projeto e das sprints. Os artefatos são
divididos em:
• 1 semana de trabalho,
17
• 2 semanas de trabalho
• 4 semanas de trabalho.
Em cada sprint são realizados as cerimônias que serão descritas logo mais a frente.
BACKLOG DO PRODUTO
Prioridade do
História do usuário negócio Pontuação
Tela de Cadastro de Veículos 1 2
Relatório Curva ABC 2 8
Otimização da consulta a tabela
Pessoa 3 5
18
comparada com os demais, não entenderam realmente a tarefa. E os que
escolheram cartas muito altas, talvez estejam enxergando uma complexidade
não declarada.
6. O processo de votação se repete até que um consenso exista.
• Valor 0: não precisa ser feito, provavelmente já foi implementada ou tem uma
forma similar no sistema que pode atender a necessidade do PO.
• Valor 20 ou 40: tarefa grande demais para ser estimada. A sugestão é quebra-
la em itens menores
• Valor 100: tarefa muito grande e não é possível fazer em sprints. Time sugere
que seja quebrada.
• Valor ?: Não ficou claro o que precisa ser feito.
19
Backlog do Sprint / Sprint backlog
BACKLOG DA SPRINT
META DA SPRINT: USUÁRIOS PODERÃO CADASTRAR VEÍCULOS
História do Usuário Demanda técnica
Criação da tela de login e senha Permitir autenticar com a conta Facebook
Autenticação no Criação das tabelas na base de
sistema dados Permitir autenticar com a conta Twitter
Permitir autenticar com a conta
Google
Criação das tabelas na base de
Cadastro de veículos dados
Criação da tela de veículos
Incremento do produto
O incremento é o resultado final de cada sprint. Ao realizar a entrega do incremento, o
dono do produto vai perceber o valor do investimento e também vislumbrar outras
possibilidades. A equipe de desenvolvimento deve entender que o incremento é algo
20
potencialmente entregável. Para saber se é algo entregável, o time deve entender que
o que foi entregue pode ir imediatamente entrar em funcionamento (ser disponibilizado
em produção).
As cerimônias
As cerimônias são eventos de duração fixa (timebox). Cada cerimônia é uma
oportunidade para inspeção e adaptação e deve ocorrer em intervalos regulares.
Abaixo vamos detalhar cada cerimônia do Scrum.
Sprint
É um ciclo completo de desenvolvimento de sistema com duração fixa de tempo.
Aconselha-se a utilização de intervalos de 2 semanas de duração. Utilizar mais que 4
semanas não é aconselhável. Ao final da sprint temos um incremento do produto. A
cada final de Sprint temos o feedback do dono do produto quanto ao que está sendo
desenvolvido. A Sprint é formada por quatro cerimônias:
• Reunião de planejamento
• Reuniões diárias
• Reunião de revisão
• Reunião de retrospectiva
21
Figura 14 - cerimônias da sprint
O dono do produto deve apresentar os itens que estão no topo do backlog e que estão
estimados. Cabe a equipe de desenvolvimento informar o quanto de itens serão
atendidos na sprint.
22
Ela deve ser realizada em pé. Isto irá garantir que o timebox da reunião seja cumprido.
Esta reunião visa melhorar e sincronizar a comunicação da equipe de
desenvolvimento. Ela não deve ter o intuito de reportar status das tarefas, pois isto é
feito pelo quadro de tarefas. Caso algum membro tenha algum impedimento, a própria
equipe se auto-organiza para solução deste. O que a equipe não consegue resolver, é
classificado como impedimento e informado o scrum master para que este encontre a
melhor maneira de remover o impedimento.
O objetivo desta cerimônia é apresentar o que foi desenvolvido na sprint. Além disto
serve para a equipe de desenvolvimento colher opiniões e impressões dos presentes
para adaptar-se para a próxima sprint. O foco é o aprimoramento do produto.
Retrospectiva / Retrospective
Esta reunião não é menos importante que as demais. Alguns autores a consideram a
mais importante, pois é o momento que toda equipe scrum (dono do produto, scrum
naster e equipe de desenvolvimento) aprimoram o processo. Nesta reunião são
levantados tudo o que funcionou e o que precisa ser melhorado. Para que isto ocorra,
o scrum master utiliza-se de diversas técnicas e dinâmicas para o bom andamento da
mesma.
Deve-se existir um cuidado nesta reunião para que a mesma não seja nociva aos
membros da equipe scrum, pois em alguns momentos a “roupa suja” será lavada. Uma
forma de gerar equilíbrio na reunião é compartilhar a visão que se espera ao participar
23
da mesma. Pensando nisto KERTH,2001 definiu o que é chamada de diretiva
primária:
Com esta declaração, conduzimos a equipe scrum para uma mentalidade colaborativa
e podemos começar a reunião.
Alguns sites como o Retro ágil e o Fun Retrospectives ajudam o Scrum Master a
planejar as dinâmicas e a sequência da reunião. Para conhecer mais sobre estes
materiais, acesse:
Gráfico de burndown
O gráfico de burndown demonstra o progresso do time durante uma Sprint. Ele possui
a quantidade de trabalho a ser feita no eixo Y com a quantidade de dias da Sprint (eixo
X). Se você esta utilizando pontuação do planning poker, você deve somá-los e terá o
a quantidade de trabalho a ser feita (eixo Y). O eixo X representa os dias ou meses, de
projeto, mas desaconselha-usar exibir sábado e domingo no gráfico por não serem
dias anterior acesso, em iterações de uma a Nallva
No centro do gráfico, vamos ter uma linha central que descreve o andamento
esperado dos incrementos. No exemplo da figura 16, esta linha é a vermelha ou a
linha que não osciliou
Já a outra linha do gráfico representa a quantidade de entregas num dia. O ideal é que
os dois gráficos caminhem o mais próximo possível.
24
Figura 16 - Gráfico Burndown
Através deste gráfico, você poderá encontrar respostas para as seguintes perguntas:
Para finalizarmos, vamos fazer uma revisão sobre o que vimos referente ao Scrum:
25
Capitulo 3 - Existe vida além do Scrum
Quando se fala em métodos ágeis, muito se fala do Scrum. Mas Scrum não pode ser
considerado bala de prata, ou seja, algo que resolve todos os problemas. No
framework Scrum, o trabalho é “puxado”, sendo dirigido por cerimônias bem definidas.
O Scrum pressupõe a possibilidade de planejamento e execução com meta e
finalidade. Mas este cenário nem sempre atende todas as demandas. Numa equipe de
manutenção, sustentação ou infraestrutura, a previsibilidade das tarefas é reduzida.
Para isto, o Kanban se encaixa melhor.
À medida que o ambiente está estabilizado, um novo trabalho pode começar a ser
feito que seja o de enxugamento, otimização e geração máxima de valor. Para isto
temos o Lean, que é uma derivação do Lean Manufactury, já conhecido da empresa
Toyota.
[AÇÃO] [RESULTADO][OBJETO]
Exemplos:
FDD é composto por cinco processos, tendo como matéria-prima os requisitos. Estes
cinco processos estarão categorizados em duas fases:
• Inicialização: é uma fase linear que tem o objetivo de criar um plano inicial de
entregas incrementais. Ela costuma durar de 2 a 4 semanas.
• Construção: é uma fase iterativa a qual tem como meta a entrega de
incrementos ao produto de forma frequente, funcional e com qualidade para ser
utilizado pelo cliente. Tradicionalmente, as iterações são de 2 semanas.
26
Figura 17 – o quadro de processos do FDD
o Áreas de negócios
o Atividades de negócios
o Passos da atividade de negócios, sendo esta a funcionalidade
propriamente dita.
Exemplo:
o Área de negócio: Gestão de vendas
o Atividade de negócio: [VERBO]... ou [SUBSTANTIVO]...
Repor estoque
Entrada de mercadoria
o Passo da atividade de negócio: [AÇÃO] [RESULTADO][OBJETO]
Calcular quantidade disponível de um produto
27
PPF – Planejar por funcionalidade
A partir deste processo será possível ter o plano de desenvolvimento. Geralmente este
plano é feito em nível de atividade de negócios, definindo o mês que se espera ter a
funcionalidade implementada.
OpenUP
É um processo enxuto, baseado no Unified Process (UP). Para aqueles que usavam
Rational Unified Process (RUP) não irão sentir tanta dificuldade ao decidirem utilizar o
OpenUP. O ciclo de vida é interativo e incremental. Enquanto o RUP é um framework
muito completo (atendendo quase todas as possibilidades), o UP é um processo de
engenharia de software mínimo e que pode ser customizado.
Princípios do OpenUP
São quatro princípios que devem ser seguidos. São eles:
Micro incremento
• É composto por item de trabalho de uma iteração
• Estas pessoas interagem para atingir um objetivo definido.
28
Figura 18 - OpenUP
29
Kanban
Kanban se utiliza desses elementos comuns a maioria dos processos para projetar um
mapa visual que represente o modelo de trabalho na forma como ele é. Este mapa
visual é semelhante ao quadro da figura 18. Com Kanban, é possível enxergar os
gargalos que interferem no fluxo de valor. Para resolver o gargalo, o time deverá se
reorganizar e com isto o processo muda e o mapa visual também. Com a mudança,
uma nova forma de ver o trabalho é evidenciada e novas oportunidades de melhoria
emergem. Um ciclo evolucionário é estabelecido.
O Kanban se apoia fortemente na gestão visual. É através dela que o andamento dos
trabalhos é evidenciado e decisões de mudança de percurso são identificadas. Para
isto utilizamos de flipcharts, quadros, post-it, adesivos personalizados ou então
ferramentas online, como o Trello. Mas para manter a gestão visual quando se usa
ferramentas online, faz-se necessário deixar o quadro de trabalho sempre visível
através de um monitor visível a todos.
30
Figura 20 - Quadro Kanban com tarefas categorizadas
E por fim, as métricas estão presentes e nos ajudam a ter números referente a
melhoria contínua. As métricas são fundamentais para que seja possível avaliar se
uma mudança levou a uma melhora ou não em todo contexto. Aqui vale a máxima:
“Não se pode melhorar o que não se pode medir”. Sendo assim, em projetos Kanban
devem ser adotadas métricas para avaliar a evolução do modelo. Vale lembrar que
estas métricas podem ser utilizadas em outras metodologias e frameworks.
31
Diagrama de fluxo cumulativo (Cumulative Flow Diagram)
Ele apresenta a quantidade de itens em cada situação do fluxo ao longo do tempo. Ele
pode substituir o gráfico de burndown. Sua atualização é fácil e fornecem dados do
projeto como um todo. Ele possui os dados do burndown e mais alguns.
32
Figura 21 – Fluxo cumulativo no Kanban
33
A linha em vermelho é denominada WIP (work-in-progress) e a linha azul vai
representar o backlog.
• Se a distância entre as duas linhas no WIP aumentar, isto pode ser sinal de
gargalo.
• Se a linha do backlog estiver mais inclinada do que a linha Done, identificam-se
a inclusão de trabalho acima da capacidade suportada pelo time.
• Para estimar a data final da entrega, projeta-se um cenário aonde as linhas de
backlog e done irão se encontrar.
• O tempo médio de ciclo e quantidade de item na fila, já são oposições.
Lead time
Lead time é o tempo, geralmente em dias, desde o início de uma história (a criação da
demanda) até a sua entrega (finalização ou implantação).
Ele engloba o tempo gasto com o desenvolvimento da demanda. Caso você deseja
saber somente o tempo de desenvolvimento da tarefa, este é chamado de templo de
ciclo (cycle time).
34
Figura 23 - Gráfico de lead time
O único problema deste gráfico é que você tem que trabalhar com tarefa já concluídas.
Estes dados geram informações importantes, mas só no final da iteração.
Tempo de ciclo
Este indicador também é chamado de Cycle Time e ele está dentro do Lead Time.
Enquanto o lead time verifica tempo total da demanda, o templo de ciclo verifica
somente o tempo investido no desenvolvimento da demanda. A diferença deles pode
ser conferida na figura 21.
Para elaborar este indicador, é necessário preencher a data de inicio que se começou
a trabalhar na atividade e marcar o número de dias gastos para finalizar o item. Para
isto podemos usa a formula da figura 23.
35
O resultado destes dados gerará um gráfico semelhante ao que vemos em sequência.
Neste gráfico, a linha em vermelho representa o tempo médio de ciclo.
Este indicador tem o mesmo problema do lead time. Ele só poderá ser utilizado no
final da produção da demanda.
Throughput:
É quantidade de tarefas entregues em um determinado período de tempo. Throughput
significa vazão e para determina-lo: usamos a fórmula apresentada na imagem 23,
mas de maneira adaptada.
36
Este indicador irá responder algumas perguntas, em especial:
Índice de defeitos
Este indicador pode nos ajudar a responder as seguintes perguntas:
37
O indicador deve exibir as semanas de trabalho no eixo X e com a quantidade de
novos erros no eixo Y. Deverá haver uma linha representando a quantidade de erros
abertos e uma segunda linha com os novos erros.
38
Scrum e Kanban, por que não usá-los simultaneamente?!
Não há nada de ruim em juntar estas duas práticas ágeis e gerar um “scrumban”. Mas
para um time que não tem maturidade ou tempo em agilidade, aconselha-se o uso de
uma ou outra ferramenta.
Mas como será que eles se relacionam? Como eu posso tirar proveito de ambos?
39
O primeiro item que devemos ressaltar é que ambos são ferramentas de processos.
As duas ferramentas objetivam o trabalho mais eficaz.
O segundo item que vale ressaltar é que ambas as ferramentas não são completas e
nem perfeitas. Isto fica evidente através da figura 28.
No Scrum, os papéis são definidos e claros (product owner, scrum master e time). Já
no Kanban não há discriminação dos papéis. Isto não quer dizer que obrigatoriamente
deva continuar sem papéis. A existência de papéis é válida, pois deixa mais clara as
atribuições de cada participante da iteração.
No Scrum, as estimativas geralmente são feitas utilizando pontuação (como foi visto a
técnica de planning poker). Um item deve estar sempre pontuado para daí seguir para
desenvolvimento. Já no Kanban as estimativas são opcionais. O mais importante é
manter um baixo número de projetos simultaneamente. Com este controle de WIP, as
partes interessadas começam a deixar de esperar tanto.
Para decidir quando utilizar Scrumban (Scrum + Kanban) analise a natureza das suas
demandas. Aconselha-se o uso do Scrumban nos seguintes casos:
• Manutenção de projeto,
• Gerenciamento de projetos problemáticos (projetos com histórias de usuários e
bugs inesperados),
• Desenvolvimento de novo produto (trabalho que precede o mutirão de
desenvolvimento ou a seguir ao mutirão de desenvolvimento) ou
• Gerenciamento contínuo de melhorias.
40
Lean
1) Eliminação de desperdício
Toda etapa deve contribuir para a construção de um produto final com menos
custo, mais rapidez e com qualidade. Os desperdícios podem ser
categorizados em:
o Funcionalidades incompletas
o Códigos incompletos
o Excesso de processo
o Criação de documentos
o Processos complexos
o Antecipar funcionalidade
o Troca constante de tarefa
o Esperas
o Defeitos
41
4) Entregar o mais rápido possível
O ambiente deve existir ou ser criado para que pessoas trabalhem de forma
auto-organizada e autodirigida evitando micro gerenciamento
7) Construir qualidade
O desenvolvimento de software deve aplicar técnicas como TDD, refatoração e
integração contínua
8) Otimizar o todo
Entender que o software concluído é muito mais que a soma das partes
entregues e verificar como ele está alinhado com os objetivos da empresa.
42
Capítulo 4 - Agilidade na codificação – eXtreme Programming
(XP)
Enquanto Scrum é focado nas práticas de gerenciamento e organização, o
eXtreme Programming (XP) dá atenção a programação. O XP foi criado por Kent
Beck, Ward Cunningham e Ron Jeffries. Ele foi um dos primeiros métodos ágeis. O
sucesso do XP vem da busca constante pela satisfação do cliente. Ao invés de
entregar tudo o que o cliente possa querer em alguma data no futuro, esse método
possibilita a entrega do software que o cliente precisa quando ele precisa. Com XP, os
desenvolvedores devem abraçar as mudanças. O XP enfatiza o trabalho em equipe.
Gestores, clientes e desenvolvedores são parceiros de igual peso em um time
colaborativo.
Valores
• Comunicação
O desenvolvimento de software é muito mais que saber programar, é
entender as pessoas. Visto isto, a comunicação é essencial para a criação de
um produto de qualidade. Esta comunicação deve ser transparente entre
desenvolvedores, clientes e usuários.
• Simplicidade
Para manter a simplicidade, faça só o necessário e quando precisar ser
feito. Não adicione complexidade antes do tempo. Simplicidade não quer dizer
solução de baixa qualidade. Encontrar uma solução simples é mais difícil do
que encontrar uma solução.
• Feedback
Este valor é a chave para a criação de software que atende a necessidade
do cliente. Ciclos curtos de desenvolvimento e feedback podem garantir o
sucesso e o bom andamento das alterações. Em ciclos curtos, os defeitos
podem ser corrigidos e já validados rapidamente.
• Respeito
As pessoas são os principais elementos para o sucesso do projeto. Elas
devem ser respeitadas. O desempenho de cada membro do time está relacionado
com a contribuição exercida e as dificuldades individuais são pontos de melhorias
da equipe.
43
• Coragem
É preciso coragem para assumir o comprometimento de mudar, inovar e de
aceitar que não sabemos tudo.
Princípios
O XP baseia-se em 14 princípios. Estes princípios transformam os valores em
práticas fáceis de implementação no dia a dia do desenvolvimento.
• Humanidade
A criação de um software depende do desenvolvedor e suas necessidades
individuais devem ser respeitadas e balanceadas com os interesses de negócios e
necessidades da equipe
• Economia
A equipe deve conhecer as necessidades de negócio e definir prioridade para
agregar valor no menor tempo possível.
• Melhoria
Devem ser implementadas constantemente.
• Benefício mútuo
Atividades como testes e refatorações beneficiam todos. Investir tempo
demasiado em análise com muitas documentações, não gera benefício a todos, já
gerará dificuldade na manutenção.
• Semelhança
Boas soluções devem ser aplicadas novamente.
• Diversidade
Quanto maior o conjunto de habilidades, opiniões e pontos de vista no time,
melhor será para alcançarmos mais perspectivas.
• Passos pequenos
A qualidade é mantida quando pequenos passos são desenvolvidos, testados e
entregues
• Reflexão
A equipe deve refletir sobre suas decisões e aprender com o passado para que
a experiência de sucesso repita mais vezes
• Fluxo
Ritmo de trabalho e de entrega de codificação devem ser seguidos.
• Oportunidade
Melhore e esteja atento as oportunidades que surgem.
• Redundância
Testar com frequência para liberação
• Falha
O código nos ensina o tempo todo, por isto experimentamos e não apenas
debatemos sobre possíveis abordagens.
44
• Qualidade
A qualidade não é negociada.
• Aceitação da responsabilidade
Cada membro do time deve aceitar as responsabilidades. As mesmas não
devem ser impostas.
Figura 33 - Práticas XP
• Padronização do código
Definir como o código será escrito. Pode envolver padrões para nomes
de variáveis, uso de chaves e colchetes, entre outras opções. Uma sugestão é
utilizar o livro Clean Code que possuem uma lista de orientações para
padronizar o código.
• Programação pareada
Não é só programar. É analisar, projetar, implementar, testar e integrar
a funcionalidade. E para isto, o trabalho deve ser feito em dupla. Enquanto um
digita o outro revisa. Com isto, a inserção de erros é reduzida e juntamente
com a implementação de uma solução inadequada. Como os pares precisam
trocar informações, o aprendizado de ambos participantes aumentará.
45
Figura 34 - Pair Programming ou programação em par
Para termos sucesso nesta prática, algumas orientações devem ser seguidas:
1. Utilizar apenas 1 computador e que seja rápido, reduzindo a distração e
aperfeiçoando a comunicação dos membros.
2. Utilizar somente o necessário para desenvolver a tarefa. Não abrir outros
programas ou sites de redes sociais.
3. Revezar as duplas para que o conhecimento seja disseminado
4. Utilizar formas de pareamento para melhor proveito da prática.
Além destas formas, outras podem ser utilizadas. Existem plug-ins para as IDE´s
(programas para desenvolvimento de software) que implementam cronômetros e
desafios para que o pair programming seja aplicado.
46
Figura 35 - Pair Hero - um game para pair programming
• Repositório de código
O time deve trabalhar com um repositório com a última versão estável
do código fonte.
• Propriedade coletiva
Não podem existir donos de códigos dentro do time. Todos podem
modificar tudo.
• Integração contínua
As mudanças em códigos fonte e as refatorações devem ser enviadas
com frequência para o repositório para serem validadas e disponibilizadas para
os demais membros da equipe
47
• Testes automatizados
Cada desenvolvedor deve se tornar o responsável por entregar uma
solução testada e pronta para ser usada pelo cliente. Os desenvolvedores
devem criar testes unitários para cada parte do sistema. Erros detectados no
desenvolvimento causam menos impacto no software do que erros em
produção.
• Refatorações
É uma melhoria técnica no código com objetivo de torná-lo mais legível,
simples, organizado ou preparado para acomodar novas funcionalidades.
• Build ágil
A construção de uma versão de software não deve ultrapassar 10
minutos e o build deve executar as automatizações de testes e as demais
tarefas necessárias para verificar a consistência o código
48
Referências:
49
• MANIFESTO ÁGIL - http://www.manifestoagil.com.br/ - Acesso em 30/07/2017
• BURNDOWN - https://www.infoq.com/br/news/2010/02/deciphering-burndown-
charts - Acesso em 11/08/2017
50
Referências das figuras:
1. https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ - acesso
em 30/07/2017
2. https://pt.wikipedia.org/wiki/Modelo_em_cascata#/media/File:Modelo_em_casc
ata.png – acesso em 30/07/2017
7. http://sportycious.com/wp-content/uploads/2015/01/A-Beginnerss-Guide-to-the-
Basics-of-Rugby-Union-Positions.jpg - acesso em 05/08/2017
8. https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/PageGraphics
/ScrumExplained-4-620.jpg - acesso em 05/08/2017
9. https://www.solutionsiq.com/wp-content/uploads/2016/06/Simple-Scrum-Team-
Icons_Artboard-1-300x300.png - acesso em 05/08/2017
10. http://www.blog-gestion-de-projet.com/wp-
content/uploads/2016/02/ezuaeiuzieoau.jpg - acesso em 06/08/2017
51
11. http://a1.mzstatic.com/us/r30/Purple20/v4/92/c7/24/92c72401-2413-a610-c32e-
34736de12aa8/sc1024x768.jpeg - acesso em 06/08/2017
13. https://s3.amazonaws.com/scrumorg-website-prod/drupal/inline-images/2017-
05/ScrumFrameworkTest.png - acesso em 05/08/2017
14. PRIKLADNICKI, Rafael, WILLI Renato, MILANI, Fabiano - Métodos ágeis para
desenvolvimento de software. Porto Alegre: Bookman, 2014, página 31.
15. https://agilefellow.files.wordpress.com/2016/06/daily-scrum-team.jpg?w=620 –
acesso em 06/08/2017
18. http://open2up.blogspot.com.br/2010/04/introducao-ao-processo-unificado-
aberto.html - acesso em 03/08/2017
19. https://s3.amazonaws.com/static.written.com/kanban-board1488229197.png -
acesso em 04/08/2017
20. https://www.culturaagil.com.br/wp-content/uploads/2014/12/kanban-quadro.png
- acesso em 17/08/2017
23. https://image.slidesharecdn.com/workshopkaizengame-apresentao-
170711170145/95/workshop-kanban-22-638.jpg?cb=1499792589 – acesso em
17/08/2017
52
24. https://cdn-images-1.medium.com/max/800/1*22HzRg7VzZAIvhAArefsUg.png
– acesso em 17/08/2017
25. https://confluence.atlassian.com/agile/files/391087320/641597718/3/142467075
3619/agile-controlchart-fixedresolutiononly.png - acesso em 17/08/2017
27. https://medium.com/@berrondo/diario-kanban-ii-metricas-34ebc3d472e7 -
acesso em 04/08/2017
33. http://arquivo.devmedia.com.br/artigos/Fabio_Gomes_Rocha/xp/image1.png -
acesso em 17/08/2017
34. http://galvanize-wp.s3.amazonaws.com/wp-
content/uploads/2016/08/25125440/fullstack-infographic-week-9-pair-
programming-01-1.jpg - acesso em 17/08/2017
53
36. https://arcadsoftware.com/wp-content/uploads/2016/05/devops-300x148.png -
acesso em 17/08/2017
54