1
2
3
4
• Processos fornecem direcionamento e suporte, e ferramentas produtividade, mas sem as pessoas certas, que possuam satisfatório conhecimento técnico e habilidades para formar uma equipe altamente eficaz, todos os processos e ferramentas do mundo irão falhar;
• Bons processos devem mais auxiliar o time que ditar as ações que seus membros devem tomar;
• Processos devem se adaptar ao time, e não o inverso; • Processos e ferramentas são úteis, mas quando decisões tiverem que ser tomadas,
estas serão feitas de acordo com a capacidade e conhecimento de seu time.
5
• Troque a entrega de documentação e artefatos por versões iterativas de um produto real que será útil para o cliente;
• Documentos não funcionam, produtos sim; • No entanto, produtos funcionando não excluem a necessidade de documentação.
Documentos auxiliam a comunicação e colaboração, facilitam a transferência de conhecimento e preservam informações históricas. Não estamos dizendo que documentação não é importante, mas apenas que é menos importante que produto funcionando;
• Documentação não deve substituir a interação.
6
• Em projetos ágeis, clientes e gerentes de produto são os guias; • A meta de um time em projetos ágeis é entregar valor para o cliente; • Clientes definem o que é valor. Os stakeholders definem as restrições. Quando
fazemos confusão entre clientes e stakeholders nosso projeto está tomando o rumo errado.
• A fórmula para o sucesso é simples: entregue hoje, adapte amanhã!
7
• Todos os projetos são conhecidos e desconhecidos, certos e incertos, e portanto todos eles precisam ter um balanceamento entre planejamento e mudanças;
• Evite a “Síndrome de Nostradamus”. Adaptação ao invés de antecipação; • Projetos baseados na exploração são caracterizados por um processo com ênfase em
formar uma “antevisão” e então explorá-la dentro de uma visão, e não de um plano detalhado. Isso não significa que isto seja “a única verdade”, mas sim que é o melhor a ser feito em muitos tipos de projeto;
• Rob Austin e Lee Diven citam em Artful Making que o lema “Planeje o trabalho, e trabalhe o plano” os levou ao fracasso em um projeto de TI que envolveu mais de U$ 125 milhões.
8
9
De ->Para Iteração – Sprint Reunião de Planejamento – Planning Meeting Reunião de Retrospectiva – Retrospective Meeting Reunião Diária – Daily Meeting Reunião de Revisão – Review Meeting Analista de Negócio – Product Owner Líder de Sistemas – Scrum Master Lista de Funcionalidades - Product Backlog Lista de Funcionalidades da Iteração – Sprint Backlog
10
11
Todo projeto inicia com a “visão do produto”. E é através desta visão que montamos a Lista de Funcionalidades. Durante o desenvolvimento do produto, o conteúdo dessa Lista de Funcionalidades pode mudar – entretanto, a “Visão do Produto” deve sempre permanecer a mesma. Uma vez criado a Lista de Funcionalidades (priorizado pelo Analista de Negócio), o Time se reúne com o Analista de Negócio para esclarecimentos sobre os itens e os estima, para que possam definir quais itens farão parte da Iteração. A esta reunião damos o nome de Reunião de Planejamento, que é dividida em duas partes. Na segunda parte do Reunião de Planejamento, o time decompõe os itens selecionados em tarefas técnicas e as estima em horas (ou dias). Durante a execução da Iteração , temos diariamente uma reunião de no máximo 15 minutos chamada Reunião Diária, onde os membros do time respondem a três perguntas: 1) O que fiz desde o último Reunião Diária ?; 2) O que pretendo fazer até a próxima Reunião Diária ? e 3) Estou com algum impedimento?. Ao término da Iteração, o Time apresenta o que foi produzido na Iteração em uma cerimônia chamada Reunião de Revisão. Esta apresentação é feita no formato de demonstração (sem slides) e é feita pelo Time. Finalmente, após apresentar o que foi produzido, o Time se reúne para uma cerimônia chamada Reunião de Retrospectiva, onde analisam o que funcionou na Iteração e o que deve ser melhorado para a próxima. Esta cerimônia é de extrema importância, pois é através dela que o Time consegue melhorar seu processo de desenvolvimento, além de atitudes e comportamento individuais.
12
• É quem tem o conhecimento das necessidades do(s) cliente(s) ou é o próprio cliente;
• Responsável por garantir o retorno do investimento (ROI); • Está em constante contato com o Time; • Ele é o responsável pelo levantamento de requisitos, a chamada Lista de
Funcionalidades; • Monitora o projeto através das metas; • Gerencia a entrega do produto (Releases) .
13
• É quem tem a característica de ser um líder “facilitador” / líder “servidor”; • Permite que o Time seja auto-gerenciável / auto-organizado; • Responsável por remover os impedimentos do Time; • Garantir que sempre estejam abertos os caminhos de comunicação entre o Time /
Analista de Negócio / Líder de CDS; • Garantir que as práticas do Scrum sejam executadas; • Facilitar todas as reuniões (Planejamento, Diária, Revisão e Retrospectiva); • Proteger o time das interferências externas, assim a produtividade do Time não é
afetada; • Responsável por gerenciar o processo. • Combate o comando-controle
14
• Seleciona e desenvolve as funcionalidades de maior prioridade na Lista de Funcionalidades;
• Cria a Lista de Funcionalidades da Iteração; • Definem junto ao Analista de Negócio a “meta” da Iteração; • Comprometido com o trabalho e com qualidade; • Participar das reuniões diárias; • Manifestar impedimentos; • Gerenciar seu próprio trabalho; • Colaborar com outros membros do Time e ajudá-los a serem auto-gerenciáveis.
15
16
Quando formamos Times em Scrum, procuramos mesclar profissionais com diferentes níveis de conhecimento com o objetivo de nivelar o conhecimento entre os diversos membros. Mas além disso, Times Scrum possuem outras características: • Times multifuncionais - Um Time Scrum deve incluir pessoas com todas as
habilidades e conhecimentos necessários para atingirem a “meta” da Iteração. Scrum evita Times verticais de analistas, designers, controle de qualidade e engenheiros de código. Um Time Scrum se auto-organiza de forma que todos contribuam com o resultado. Cada membro do Time Scrum aplica seu expertise em todos os problemas. Por exemplo, a sinergia resultante de um tester ajudando um designer a escrever código melhora a qualidade do código e aumenta a produtividade.
• Auto-gerenciamento – Em Scrum não existem títulos para membros do time. Os times se auto-organizam para transformar os requisitos e tecnologia em funcionalidades do produto. Todos se doam e fazem o seu melhor, fazendo ou aprendendo o que for necessário. Sem descrições de funções. Sem títulos, sem exceções. Por exemplo, pessoas que se recusam a codificar por serem arquitetos de sistema ou designers não podem fazer parte de um Time Scrum.
17
18
19
20
21
22
Ao iniciar uma Iteração, devemos planejar o que será produzido nela. E isto é feito em uma reunião chamada “Planejamento”. A Reunião de Planejamento é realizada em duas partes, onde na primeira o Analista de Negócio explica ao Time o que significa “cada um” dos itens (ou User Story) da Lista de Funcionalidades. O Líder do CDS participa geralmente como um facilitador. Após discutir os detalhes de um item, o Time estima o tamanho (ou Story Point) do item para, de acordo com a velocidade do time, determinar se será possível incluí-lo na Iteração ou não.
23
• Story points são relativos • Determinar Velocidade
24
25
26
Com os itens (ou User Stories) selecionados para a Iteração, o time juntamente com o Analista de Negócios definem uma meta para a mesma. Esta meta é criada com o objetivo de manter o Time focado no valor do que será produzido para o cliente. Por isso ela deve ser criada em termos de negócios.
27
A segunda parte da Reunião de Planejamento é onde o time decompõe os itens selecionados em tarefas técnicas. Ela é feita logo depois da primeira parte da reunião. Cada uma destas tarefas é estimada em “tempo” – horas ou dias, de acordo com a preferência – e geralmente é estimada pela pessoa que se habilitar a executá-la.
28
29
30
31
Todo Time se reúne diariamente por 15 minutos para atualização do status da Iteração. A estas reuniões damos o nome de Reunião Diária ou Daily Scrum. Nestas reuniões, os membros do time respondem a três perguntas: 1. O que fiz desde a última Reunião Diária 2. O que pretendo fazer até a próxima Reunião Diária 3. Quais impedimentos estou encontrando As Reunião Diária melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos ao desenvolvimento, promove tomadas rápidas de decisões e aumenta o nível de conhecimento do projeto entre os membros. O Líder do CDS toma as providências para que a reunião aconteça, sempre no mesmo horário e local, enquanto que os membros são os responsáveis pela condução da mesma. Isso significa que as perguntas devem ser respondidas ao time e não ao Líder do CDS .
32
33
34
Ao final da Iteração, uma reunião é feita, chamada de Revisão. Durante esta reunião, o time apresenta o que foi feito na Iteração e o Analista de Negócios valida os itens de acordo com o que foi combinado na Reunião de Planejamento. Esta é uma reunião informal onde o time, Analista de Negócio e stakeholders podem discutir os próximos passos no projeto de acordo com o que foi apresentado até o momento e o que ainda deve ser feito. Isto pode influenciar no conteúdo da Lista de Funcionalidades para as próximas Iterações.
35
36
Após a Reunião de Revisão e antes da próxima Reunião de Planejamento da Iteração seguinte, o Time tem uma reunião chamada Retrospectiva. Nesta reunião, o Líder do CDS encoraja o time a revisar, dentro do processo e práticas de Scrum, seu próprio processo de desenvolvimento para torná-lo mais eficiente e divertido para a próxima Iteração. O propósito da Reunião de Retrospectiva é inspecionar como foi a última Iteração em relação às pessoas, relacionamentos, processos e ferramentas. A inspeção deve identificar e priorizar os principais itens que funcionaram bem e aqueles que se fossem feitos de forma diferente poderiam tornar as coisas melhores. Isto inclui a composição do time, arranjos para as reuniões, ferramentas, definição de “pronto” (“done”), métodos de comunicação, etc. Ao final da reunião, o Time deve ter identificado medidas a serem tomadas que devem ser implementadas para melhorar a próxima Iteração.
37
38
39 39
Top Related