2. 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'. # 3. Papéis do Scrum ## 3.1 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. ## 3.2 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. ### 3.2.1 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. ## 3.3 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. # 4. Artefatos ## 4.1 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. ## 4.2 Charts ### 4.2.1 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.
 ### 4.2.2Burndown 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.
 ## 4.3 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. # 5. Reuniões ## 5.1 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. ## 5.2 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. ## 5.3 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). # 6. Referências * [Manifesto Agil](http://www.manifestoagil.com.br/) * [Guia do SCRUM](http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf) * [Service Now](http://wiki.servicenow.com/index.php?title=Scrum_Charts#gsc.tab=0) * [Metodologia Ágil](http://www.desenvolvimentoagil.com.br/scrum/) * [Imagem: Ciclo do Scrum](http://www.desenvolvimentoagil.com.br/images/scrum/ciclo_scrum.gif) * [Imagem: Velocity Chart](https://www.scrumalliance.org/scrum/files/e3/e3a2ff2a-27a2-444c-81af-c2e8dbfb3128.jpg) * [Imagem: Burndown Chart](https://upload.wikimedia.org/wikipedia/commons/0/05/SampleBurndownChart.png)