Grupo de estudo #3: Kanban

Para nosso terceiro encontro de estudos , escolhemos o Kanban, como referência usamos o vídeo:

Kanban – Rodrigo Yoshima from Bluesoft on Vimeo.

e artigo: Que legal esse tal de Kanban

-Kanban tem origem no Japão e significa “registro ou placa visível”.
-Trata-se de um quadro visível no ambiente de trabalho, onde a equipe consegue consultar o andamento da produção. Em se tratando de desenvolvimento de software, a equipe consegue visualizar no Kanban todos os componentes, as funcionalidades que fazem parte da entrega de um release de software.
– uma filosofia , não um metodo de gerenciamento de processo
– processo tajota de produção
– deixar sempre visivel para todos
– possui limites (de quantas historias serão feitas ) que o PO (Product Owner)
Historias(PO)       |Desenvolvimento|        QA            |Infra(Homologação)|     Produção
|Inicio|Fim|                |Inicio|Fim|        |Inicio|Fim|
– quebra em etapas, não em tarefas como SCRUM
– limitar o trabalho que é feito ao mesmo tempo
– cascata não é boa idéia em muita coisa feita ao mesmo tempo e pouco valor ser integre.
– SCRUM – verifica a melhoria de processo na retrospectiva, no Kanban percebe a melhoria de maneira continua
– planejamento mais rápido
– Gargalo- quando aparece, pensa o que pode melhorar, investiga as práticas ágeis
– se você não coloca limites você não vai saber onde está o gargalo
– SCRUM é um método invasivo, muda a hierarquia , papéis rotinas, dinamica da equipe
– Kanban não é tao invasivo, as mudanças são mais suaves

Conceito:

“Kanban foi idealizado pelos altos-executivos da Toyota há décadas, como um recurso para dar visibilidade na linha de produção. É uma ferramenta integrante da metodologia denominada just-in-time. Apesar de sua aplicação inicial ter sido idealizada para a indústria automobilística, a aplicação de just-in-time na indústria de software mostrou-se extremamente eficaz. Tudo o que está fixado no Kanban deve ser movimentado. Uma funcionalidade de software nunca é empurrada para a próxima fase no Kanban. Pelo contrário, o time responsável pela fase seguinte é quem puxa a funcionalidade para si. Por exemplo, quando é concluída a fase de especificação de uma funcionalidade, ela permanece na coluna “Especificação” até que um desenvolvedor esteja livre para iniciar a fase de desenvolvimento. Somente aí é que a funcionalidade move-se no Kanban, passando para a fase “Desenvolvimento”. De acordo com o just-in-time, nada deve empurrado na linha de produção. Não se deve formar estoques. Para software o mesmo: não devemos sobrecarregar os times, mas sim prover um fluxo organizado e estável de produção de software. É um caminho certo para a qualidade de software, tão almejada.” Referência: http://www.leopoldobarreiro.com/blog/?p=27