Imagine esse cenário: Um ambiente onde há muitos produtos legados, código que requer manutenção constante e que necessita de fluxo contínuo, não podendo aguardar até determinada data para realizar um deploy. Neste cenário é evidente que o Kanban melhor ser adapta, pois com ele é possível visualizar esse fluxo e proporcionar um ambiente onde é possível organizar o trabalho a ser feito.
Por ser menos prescritivo que o Scrum, que tem suas cerimônias, papéis e artefatos, o Kanban é mais lean e menos complexo, talvez por isso, sua adoção é mais suave que o Scrum.
Porém se você necessita de um certo grau de controle, ciclos mais definidos possivelmente com necessidade de sincronia com outros departamentos, talvez ai o Scrum se encaixe melhor. Acredito que não há uma regra para definir qual método ágil é melhor. Não é porque estou em um projeto novo que devo usar Scrum e nem porque estou em um projeto de manutenção de sistemas legados que devo usar Kanban.
Aqui na empresa quando escolhemos adotar Kanban para manutenção, era evidente que não seria possível manter um backlog com itens de vários produtos legados com complexidades distintas e necessidades de negócios divergentes. Por este motivo foi-nos sugerido pelo Giovanni Bassi durante uma consultoria usar Kanban neste ambiente.
O que percebemos ao adotar Kanban:
- Possibilidade de manter itens de vários produtos diferentes ordenados e juntos;
- Marcando com post-its de cores diferentes cada produto visualizamos qual era o que mais demandava esforço;
- Limitações nas marcações permitem visualizar onde estão os gargalos na execução de tarefas;
- Deploy mais rápidos, entregando valor mais cedo;
Há outras coisas que podem ser evidenciadas também, como tempo médio de realização de uma tarefa, onde o trabalho está enroscando. Isto nos permite tratar as causas destes gargalos e ser mais eficientes na entrega de valor, não apenas seus efeitos. Um exempo pode ser o QA acumulando ou travando o fluxo de trabalho. Talvez seja aconselhável treinar melhor os executores do QA ou melhorar as práticas ao invés de contratar mais duas pessoas para realizar estas tarefas mais rápido.
Legal também citar que o Kanban não serve apenas para manutenção de código legado. Perceba que ao trabalhar com Kanban é possível ao final do ciclo realizar deploy da aplicação, logo, o valor daquilo que foi realizado já está disponível para o cliente, seja ele uma correção ou até mesmo uma nova feature. Assim notamos que assim é muito ágil seja para ambientes de desenvolvimento ou manutenção de software.
Agora imagine este cenário: Um produto novo, com um time to market predefinido, equipe com pouco conhecimento do negócio e da arquitetura e ainda em estado de forming, necessidade de alguma previsibilidade de deploy. Penso que este ambiente é bom para aplicação do Scrum, por muitos fatores, mas o principal é por ele ser mais prescritivo e assim garantir um pouco mais de controle do processo, mas veja que negritei o processo justamente por isso, para que não seja confundido com controle das pessoas envolvidas.
Se na sua empresa há uma necessidade de estimar projetos para que o departamento comercial ou o marketing possam se organizar seja para uma determinada campanha, pré-lançamento ou mesmo plano de posicionamento de produto por exemplo, recomendo estruturar as releases de forma a atender essa necessidade. O Scrum fornece meios para realizar esse tipo de colaboração mais facilmente.
O Kanban assim como Scrum permite usar partes de outros métodos ágeis, por exemplo reuniões diárias, do Scrum ou Pair Programing do XP. Lembre-se que sempre será necessário que alguém diga dentre as tarefas existentes no quadro, qual é a mais prioritária e assim por diante. Chamar essa pessoa de Product Owner ou não dependerá de você, não há regra quanto a isso, aliás a única regra evidente no Kanban é que os limites das marcações devem ser respeitados.
Usar Scrum ou Kanban vai depender de muitos fatores, que variam de produto e suas necessidades até empresa e seu meio ambiente. Quando pensar em um processo ágil, leve em consideração quais pontos proporcionarão mais desempenho em termos de negócio e técnicos e seja feliz. Lembre-se que fazer software também pode ser divertido e, aliás, deve ser divertido.
Algumas pessoas na comunidade concordam que Scrum e Kanban são facilmente combináveis, a Professional Scrum Trainer KaTe Terlecka, explica em seu blog a maneira como ela combina esses dois métodos gerando o Kate-Ban, que segundo ela tem funcionado bem.
Fonte: http://micajeho.wordpress.com/