balho planejado esteja concluído para que uma entrega seja realizada. No momento
16
Casa do Código
Capítulo 1. Introdução à Métodos Ágeis
da entrega, algumas tarefas estarão prontas e outras em progresso; as que estiverem prontas farão parte da entrega, e as que não estiverem ficarão para a próxima.
Em meados de 2007, Rick Garber e David J. Anderson apresentaram nas confe-
rências o Lean New Product Development e Agile 2007, os resultados prelimina-
res do uso de Kanban na Corbis, uma empresa que vende imagens e clips de vídeo
fundada por Bill Gates, da Microsoft. Desde então, o Kanban vem ganhando mais e
mais força na comunidade de desenvolvimento de software e mais empresas passa-
ram a adotá-lo.
Kanban está bastante relacionado
com o conceito de Pull Systems (sistemas de
produção puxados), do Toyota Production System (TPS). Tradicionalmente, antes da
Toyota, a grande maioria das indústrias utilizava o conceito de Push Systems (sistemas de produção empurrada).
Um sistema de produção empurrada caracteriza-se quando a primeira operação
do processo recebe uma ordem de produção e a executa, empurrando o resultado da
operação atual para a operação seguinte. Em sistemas empurrados, não há ligação
direta entre o que é produzido e a demanda do cliente, ou seja, pode-se dizer que
o fato de um item ter sido produzido não significa que um outro item tenha sido
vendido.
Já um sistema de produção puxada exige que cada operação do processo seja
alimentada pela demanda da etapa anterior, estabelecendo uma ligação direta entre
o consumo real do cliente e a quantidade produzida. Dessa forma, o fato de um item
ter sido vendido, geraria a demanda para a fabricação de outro. Em uma abordagem
de desenvolvimento de software, poderíamos dizer que a demanda para se trabalhar
em uma nova funcionalidade seria gerada quando alguma outra fosse entregue.
Kanban é uma palavra japonesa que significa cartão sinalizador. É utilizado no
Sistema Toyota de Produção (TPS) e também por diversas empresas que aderiram à
filosofia Lean para representar, em um sistema puxado de produção, um sinal para
que se puxe mais trabalho, ou seja, para que o processo seja alimentado.
Kanban é dos métodos de desenvolvimento de software menos prescritivos, que,
de acordo com Henrik Kniberg, possui apenas três prescrições [34]:
1) Visualizar o fluxo de trabalho (workflow);
2) Limitar o trabalho em progresso;
3) Gerenciar e medir o fluxo.
17
1.8. Qual é o Melhor Método?
Casa do Código
Kanban incentiva a adaptação baseada em contexto. Deste modo, parte-se da
premissa que não existe uma única solução que resolva todos os problemas de to-
dos os diferentes contextos, e por isso há a necessidade de adaptação, em que cada
processo deve se adequar às necessidades do contexto a que pertence.
Kanban também recomenda que se meça o lead time, tempo médio para se com-
pletar um item, de forma que o processo deve ser continuamente otimizado para
tornar esse tempo cada vez menor e mais previsível.
1.8
Qual é o Melhor Método?
Kniberg define ferramenta como qualquer coisa que possa ser usada para atingir
uma tarefa ou objetivo , e processo como a forma que se trabalha [34]. Para ele, métodos como Scrum, XP e Kanban são ferramentas para processos, e questionar
qual é o melhor deles é o mesmo que comparar se um garfo é melhor do que uma
faca, ou seja, isso depende do contexto e do objetivo em questão.
Nenhum método é completo e nenhum é perfeito, por isso, sinta-se livre para
combinar as ferramentas e aproveitar o que funcionar melhor para seu contexto, ou
seja, considerando a cultura da sua organização, as habilidades da sua equipe e as
restrições de seu projeto. É comum, por exemplo, que se adote práticas de engenha-
ria de XP, como programação em par e integração contínua, em times que utilizam
Scrum.
Todo projeto de desenvolvimento de software é diferente, possui pessoas com
habilidades diferentes, níveis de experiência diferentes, orçamento, prazo, escopo e riscos diferentes. Os valores da organização e suas metas também são específicos,
e com toda essa variação, sem dúvida, as restrições também serão diferentes. Por-
tanto, você deve procurar compreendê-las de forma a explorá-las da melhor maneira
possível visando atingir bons resultados.
Assim como as práticas, os papéis em uma equipe ágil, podem variar de acordo
com o método utilizado e contexto da equipe. Fique atento para utilizar apenas pa-
péis que de fato agreguem valor, e para não incluir papéis conflitantes.
Cada novo método que você estuda e conhece é mais uma ferramenta para sua
caixa de ferramentas, a pergunta certa não é qual é o melhor método, mas qual o
método mais adequado para esse contexto, e então, munido de sua caixa de ferra-
mentas, você terá condições de escolher a melhor abordagem para cada desafio.
18
Casa do Código
Capítulo 1. Introdução à Métodos Ágeis
1.9
E agora, o que eu faço amanhã?
Revise os quatro valores ágeis: você acredita que sua organização reflete esse valores?