Scrum
Scrum¶
Durante muito tempo, empresas de desenvolvimento de software conviveram com problemas relacionados ao planejamento e gerenciamento de projetos. Mediante essa situação, um grupo de profissionais da área de desenvolvimento de software se reuniram e criaram o que ficou conhecido com Manisfesto Ágil, que foi gerado de acordo com as experiências de cada um. Dentre os criadores do manifesto ágil estavam Ken Schwaber e Jeff Sutherland, que desenvolveram o Scrum. Segundo os criadores desse método, o Scrum "é um framework para desenvolver e manter produtos complexos". O Scrum consiste em um método que trabalha com ciclos curtos de desenvolvimento. Deste modo, o feedback a respeito do resultado é obtido rapidamente, o que garante a qualidade do produto desenvolvido e a satisfação do cliente.
Principais Diferenças: (Scrum vs Tradicionais)¶
Os métodos ágeis possuem uma maior liberdade no planejamento de ações, enquanto os tradicionais possuem um planejamento mais rígido. Outra diferença importante é que as entregas de partes do projeto são feitas de forma contínua e incremental (iterações), geralmente não muito longas, a fim de obter um rápido feedback do cliente acerca do andamento do projeto.
Na questão de comunicação entre os membros do projeto, os métodos ágeis utilizam reuniões diárias entre o time, ou seja, há uma interação constante entre todos os membros da equipe, enquanto que em tradicionais, o contato não é tão frequente. O intuito disso está em discutir o que será feito naquele momento, revendo o planejamento a médio e curto prazo, além de prováveis impedimentos. As equipes são auto-organizáveis e não necessitam de líderes indicando 'O que fazer' e 'Como fazer'.
Papéis do Scrum¶
Product Owner¶
O Product Owner, "dono do produto", é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar por projeto ou time de desenvolvimento, sendo que o Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:
- Expressar claramente os itens do Backlog do Produto;
- Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
- Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
- Garantir que o Backlog do produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir;
- Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
O Product Owner pode fazer o trabalho citado acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto não é muito recomendado já que o Product Owner continuará sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê, mas pode representar o desejo de um comitê no Backlog do Produto, sendo que aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner das necessidades de tais mudanças.
Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões, estas devendo ser visíveis no conteúdo e na priorização do Backlog do Produto.
Scrum Master¶
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado, ou seja, para garantir que o Time Scrum adira à teoria, práticas e regras do Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum e se estas são úteis, de modo que mostra, também, quais não são úteis para o projeto. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.
Papéis do Scrum Master¶
O Scrum Master serve o Product Owner de várias maneiras, incluindo:
- Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
- Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento;
- Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
- Compreender a longo-prazo o planejamento do Produto no ambiente empírico;
- Compreender e praticar a agilidade;
- Facilitar os eventos Scrum conforme exigidos ou necessários.
- Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
- Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor;
- Remover impedimentos para o progresso do Time de Desenvolvimento;
- Facilitar os eventos Scrum conforme exigidos ou necessários;
- Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido;
- Liderando e treinando a organização na adoção do Scrum;
- Planejando implementações Scrum dentro da organização;
- Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
- Causando mudanças que aumentam a produtividade do Time Scrum;
- Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.
Development Team¶
O Time de Desenvolvimento consiste de profissionais que realizamo trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.
O Scrum Team é a equipe de desenvolvimento. Nela não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.
Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum.
O tamanho ideal do Time de Desenvolvimento deve ser pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites de tempo da Sprint. Menos de 3 integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de 9 integrantes é exigida muita coordenação. De maneira que o Time não pode ser grande demais ou pequeno demais.
Artefatos¶
Product Backlog¶
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. Não tem a necessidade dessa lista estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Charts¶
Velocity Chart¶
O Velocity Chart pode ajudar a determinar quantos pontos de trabalho pode ser concluído por Sprint para uma determinada equipe, se a composição da equipe e duração da Sprint permanecerem os mesmos. A Estimativa dos pontos de história devem ser precisos para o cálculo do Velocity ser significativo. Pode-se criar Velocity Chart para lançamentos ou Sprints concluídas.
Burndown Chart¶
Burndown Chart compara o progresso esperado versus o progresso real para releases e Sprints. Este Chart pode ajudar a identificar problemas inesperados que podem estar afetando o progresso. Os usuários com as funções Scrum admin ou Scrum user podem visualizar as informações do Burndown Chart.
Sprints¶
Sprint é considerado como o coração do Scrum, é o tempo que dura geralmente de um mês ou menos. Ao final de uma Sprint é esperado que tenha um versão estável do produto e incrementada em relação a versão anterior. O tempo de duração de uma Sprint é coerente com o esforço demandado para o desenvolvimento.
Para iniciar uma Sprint é necessário realizar a reunião de planejamento, reuniões diárias, o trabalho desenvolvido durante o período da Sprint, a realização da revisão de Sprint e a retrospectiva dela para poder encerrá-la.
Reuniões¶
Daily Meetings¶
As reuniões diárias são reuniões rápidas, de aproximadamente 10 a 15 minutos, dependendo do tamanho da equipe, onde os participantes a realizam de pé. O objetivo desta é explanar para o restante do time o que foi feito no dia anterior e o que pretende-se fazer no dia atual, bem como a existência de quaisquer impedimentos no desenvolvimento. Deste modo, todo o time está sempre atualizado em relação ao andamento do projeto como um todo, não somente em suas demandas/tarefas, o que permite a possibilidade de tomadas de decisão rápidas e forte adaptação a mudanças. As reuniões diárias são realizadas sempre no mesmo horário e local.
Retrospectiva¶
A retrospectiva é uma reunião realizada com o intuito de abordar os pontos positivos, negativos e de melhoria do período passado, com a finalidade de não repetir os erros e manter e/ou melhorar os acertos. Esta reunião pode ser realizada ao fim de cada Sprint ou em períodos pré-determinados, como a cada mês, por exemplo.
Revisão da Sprint¶
Revisão de Sprint é uma reunião realizada ao final de toda Sprint, onde são mostrados ao restante do time tudo o que foi realizado durante o período da Sprint passada. Esta reunião pode incluir o(s) cliente(s).
