Introdução ao Agile Scrum

Vídeo muito interessante sobre Scrum, apenas 10minutos vale á pena conferir.

Anúncios

Scrum ou Kanban, qual escolher?

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 formingnecessidade 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/

Sessões de Backlog Grooming (Organização do Backlog)

Para Roman Pichler, assim como o seu jardim que vai crescendo até se tornar uma selva se for devidamente cuidado, o seu backlog também vai crescendo e tornando desajeitado se for dada a ele a devida atenção. “O Backlog precisa de atenção e cuidado frequente, precisa ser organizado cuidadosamente.”

O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog.

A palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. Para facilitar a semântica do artigo, traduzirei “Backlog Grooming” como “Organização do Backlog“, considerando que organizado é por consequentemente limpo e arrumado. Alguns autores preferem chamar de Refinamento de Backlog.

Backlog Grooming

Organizar o backlog é uma processo contínuo que envolve:

  1. A descoberta de novos itens, assim como alteração e remoção de itens antigos.
  2. Quebrar Estórias muito grandes (épicos).
  3. A priorização dos itens do backlog (trazendo os mais importantes para o topo).
  4. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento.
  5. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas).
  6. Incluir Critérios de Aceitação.

Muitas equipes que utilizam métodos ágeis como Scrum e XP, reclamam que suas reuniões de planejamento “levam uma eternidade”. Sessões de Backlog Grooming, podem ser utilizadas como uma ferramenta simples e rápida para tornar as reuniões de planejamento mais eficientes.

Embora a manutenção do Backlog seja de responsabilidade do Product Owner, outros membros do time podem colaborar na reunião de Organização do Backlog, Ken Schwaber sugere a participação de 10% da equipe durante de 5 a 10% do tempo da Sprint, de forma a incentivar a comunicação face-a-face entre as pessoas ao invés de outros meios como comunicação por e-mail ou documentos.

Roman sugere a utilização de cartões de papel como ferramenta para facilitar a colaboração na reunião, cada participante pode pegar um cartão e escrever suas ideias. Depois, estas podem ser agrupadas e, caso necessário, pode-se transferir as informações para uma ferramenta eletrônica, como o Pronto, por exemplo.

Referências

Metodologia Ágil

 “Governança de TI é igual redbull, pode lhe dar asas”

Em 2001, um grupo de 17 profissionais se reuniu para discutir sobre como melhorar o desempenho em seus projetos. Cada um deles possuía suas próprias praticas e métodos de trabalho, mas concordaram que um conjunto de princípios sempre estava sendo respeitado em todos os projetos que deram certo.

Por fim desenvolveram o manifesto ágil. Este manifesto definia os valores e princípios a serem seguidos, para se obter maiores e melhores resultados. O foco maior do manifesto é o de desenvolver softwares tornando este processo  mais pessoal, mais colaborativo e mais fácil.

 Valores das metodologias ágeis:

Indivíduos e interação entre eles 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 doze princípios das metodologias ágeis:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  2. 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.
  3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
  4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  6. 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.
  7. Software funcional é a medida primária de progresso.
  8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Para se utilizar dos benefícios fornecidos pelo manifesto ágil devemos adotar uma metodologia ágil, essa metodologia define algumas regras e formas de trabalho. Alguns exemplos de metodologias ágeis:

Cada metodologia tem sua maneira de trabalho, mas em geral são processos iterativos e incrementais. Sendo que ao final de cada iteração o cliente recebe uma versão utilizável do produto.

Hoje as metodologias mais conhecidas no mercado são a XP e a SCRUM. A XP (Extreme Programming), que possui um número de práticas um pouco maior e oferece práticas de certo modo radicais, ou vistas com certo receito, como é o caso do “pair programming”. Mas é uma metodologia que fornece excelentes benefícios quando aplicada corretamente. A SCRUM é outra metodologia ágil bastante utilizada atualmente, ela é um pouco mais simples e direta, não possui tantas praticas quanto a XP, mas fornece excelentes resultados para os projetos. A grande vantagem do Scrum é que através dele pode-se gerenciar vários tipo de projetos, mesmo que não seja de software.