1. Teoria do Scrum

2. O Scrum é uma framework que visa a gestão de projectos e o desenvolvimento ágil de software. É utilizado em projectos complexos -projectos de requisitos variáveis ou tecnologia incerta. Teoria do Scrum

3. O Scrum é uma framework na qual podem ser utilizados vários processos e técnicas. Baseia-se na teoria de controlo de processos empíricos e efectua uma abordagem iterativa e incremental para optimizar a previsibilidade e controlar riscos. Teoria do Scrum

4. O Scrum assenta em 3 pilares: Transparência – garantindo que os aspectos do processo que afectam o resultado devem ser visíveis para quem gere o resultado; Inspecção – os vários aspectos do processo devem ser inspeccionados com frequência suficiente para ser possível detectar variações inaceitáveis no processo; Adaptação – necessidade de ajustar o processo ou o material que está a ser processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores. Teoria do Scrum

5. Pontos de inspecção e adaptação: Daily Scrum Reuniões de Planeamento da Sprint e de Revisão da Sprint Retrospectiva da Sprint Teoria do Scrum

6. A framework Scrum é composta por: Equipas Scrum Papeis associados: Team Boxes Artefactos Regras Scrum

7. Em cada Equipa de Scrum há 3 papéis: O ScrumMaster - responsável por garantir que o processo seja compreendido e seguido; O Product Owner – responsável por maximizar o valor do trabalho da equipa (representa o negócio e os stakeholders, define os requisitos); A Equipa – quem executa o trabalho. Teoria do Scrum

8. O Scrum Master É um papel de líder-servidor da equipa; É o responsável pela adesão da equipa aos valores, práticas e regras do Scrum; Educa a equipa, tornando-a mais produtiva e aumentando a qualidade do seu produto; Ajuda a equipa a entender a multidisciplinaridade e a auto-organização. Teoria do Scrum

9. O Product Owner É o responsável por maximizar o valor do trabalho da equipa; Define as prioridades a ter em conta; É responsável pela gestão e visibilidade do Product Backlog. O Product Owner nunca deve ser o Scrum Master. Teoria do Scrum

10. A Equipa É multi-disciplinar - os seus membros devem possuir todo o conhecimento necessário para criar um incremento no trabalho. Devem compartilhar o conhecimento. Na equipa não há títulos. Também não há sub-equipas dedicadas a áreas especializadas como testes ou análise. É auto-organizável . O tamanho óptimo é de 7 pessoas(+-2), sem incluir o Product Owner e o Scrum Master. A equipa trabalha em iterações. Teoria do Scrum

11. Team Boxes – são eventos com duração fixa, que criam regularidade. Teoria do Scrum

12. Reunião de Planeamento da Release O plano da release estabelece: A meta da release As maiores prioridades do Product Backlog Os principais riscos Características gerais e funcionalidades Estabelece a data de entrega e o custo prováveis Requer estimar e priorizar o Product Backlog para a release. É possível alterar o plano da release, a cada Sprint. Teoria do Scrum

13. Sprint É uma iteração; Tem duração fixa; Todas as sprints utilizam o mesmo modelo de Scrum; As sprints têm como resultado um incremento do produto final potencialmente entregável; Durante a Sprint, o Scrum Master garante que não será feita qualquer mudança que possa afectar a Meta da Sprint; Cada sprint começa imediatamente após a anterior. Teoria do Scrum

14. Sprint Cada sprint contém : Reunião de planeamento da Sprint O trabalho de desenvolvimento A revisão da Sprint A retrospectiva da Sprint Teoria do Scrum

15. Sprint Cancelamento de uma Sprint Uma Sprint pode ser cancelada antes que o seu prazo fixo tenha terminado; Só o Product Owner pode cancelar a Sprint; A Sprint deve ser cancelada se a sua Meta se tiver tornado obsoleta. O cancelamento de uma sprint raramente ocorre. Teoria do Scrum

16. Reunião de Planeamento da Sprint Dura 8 horas para uma sprint de 1 mês. Tem duas partes (4 horas cada): 1ª parte -decide-se o que será feito na Sprint 2ª parte - a equipa entende como desenvolverá a funcionalidade Teoria do Scrum

17. Reunião de Planeamento da Sprint 1ª Parte – o que será feito Inputs para esta parte da reunião: Product Backlog O incremento mais recente ao produto A capacidade da equipa O histórico do desempenho da equipa . É definida a Meta da Sprint Teoria do Scrum

18. Reunião de Planeamento da Sprint 2ª Parte – como será feito O trabalho é projectado pela equipa, sendo identificadas as tarefas necessárias. As tarefas são decompostas até poderem ser efectuadas em menos de 1 dia. A lista de tarefas é o Sprint Backlog. A equipa auto-organiza-se para efectuar o trabalho. Teoria do Scrum

19. Reunião de Revisão da Sprint Dura 4 horas (para sprints de 1 mês); Apresenta-se a funcionalidade; Tem a participação da equipa e dos stakeholders; Teoria do Scrum

20. Reunião de Revisão da Sprint O Product Owner identifica o que foi feito e o que não foi feito; A equipa refere os pontos positivos, os problemas que ocorreram e a forma como foram resolvidos; A equipa apresenta o trabalho; O Product Owner estima várias datas de conclusão prováveis; Todo o grupo colabora sobre o que está feito e o que será feito em seguida. Teoria do Scrum

21. Reunião de Retrospectiva da Sprint Dura 3 horas (para sprints de 1 mês); Realiza-se entre após a Revisão da Sprint e antes do Planeamento da Sprint seguinte; Tem uma perspectiva de melhoria contínua: identifica-se o que correu bem e aquilo que poderia ter sido feito de forma diferente – ex. composição de equipa, preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos. Teoria do Scrum

22. Daily Scrum Dura 15 minutos; Realiza-se todos os dias, à mesma hora, no mesmo local. Teoria do Scrum

23. Daily Scrum A cada membro da equipa são feitas 3 perguntas: O que fez ontem? O que planeia fazer hoje? Há algum problema que o impeça de atingir o seu objectivo? Cada resposta é um compromisso! Teoria do Scrum

24. O Scrum utiliza 4 artefactos principais: Product Backlog – é uma lista prioritizada de tudo o que pode ser necessário no produto; Sprint Backlog -lista de tarefas para transformar o Product Backlog por uma Sprint, num incremento de produto potencialmente entregável; Release Burndown – mede o Product Backlog restante ao longo do tempo de um plano de release; Sprint Burndown – mede os itens do Sprint Backlog restantes ao longo do tempo de uma Sprint. Teoria do Scrum

25. O Product Backlog e o Burndown da Release O Product Backlogcontém os requisitos do produto - é a lista de todas as características do produto; Cada item possui uma descrição, prioridade (determinada por risco, valor e necessidade) e, estimativa; o item mais prioritário é o mais urgente. O Product backlog é dinâmico – para minimizar o rework, apenas os itens mais prioritários necessitam de ser mais detalhados. Release Burndown – regista a soma das estimativas dos esforços estimados restantes do Product Backlog ao longo do tempo; Teoria do Scrum

26. OSprint Backlog e o Burndown da Sprint O Sprint Backlog contém todo o trabalho identificado pela equipa, para alcançar a Meta da Sprint. Cada item deve ser descomposto até à duração de 1 dia, ou ainda menos. O Sprint Backlog vai sendo actualizado durante a Sprint, pela equipa, e só pela equipa. Sprint Burndown– é o gráfico da quantidade restante de trabalho do Sprint Backlog, numa dada Sprint, ao longo do tempo dessa Sprint. Deve ser acompanhado diariamente. Teoria do Scrum

27. As Regras ligam as team-boxes, os papéis e os artefactos do Scrum. Ex. só os membros da equipa podem falar durante uma Daily Scrum. Teoria do Scrum

28. Definição de “Pronto” (“done”) A definição de “pronto” adoptada pela equipa deve estar clara para o Product Owner. O Product Owner deve poder saber se um incremento completamente “pronto” inclui, ou não inclui: análise, projecto, programação, documentação e testes (sendo que os testes deverão incluir testes unitários e de integração, bem como testes performance, estabilidade e segurança). O trabalho “pronto” será inspeccionado pelo Product Owner, no fim de cada Sprint. Teoria do Scrum

29. Referência KenSchwaber e JeffSutherland Adaptação Maria João Costa Portugal mjoao.costa@hotmail.com Teoria do Scrum