CONTEÚDO PROGRAMÁTICO 1.Introdução 2.Organização de Atividades com Kanban 3.O Framework SCRUM 4.Papéis e responsabilidades 5.Artefatos e cerimônias

Introdução Manifesto para Desenvolvimento Ágil de Software Diz: Indivíduos e interações 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.  

O que é Scrum E uma metodologia usada para uma gestão dinâmica de projetos, sendo muitas vezes uma prática relacionada com o desenvolvimento ágil de um software. O scrum é uma ferramenta que permite controlar de forma eficaz e eficiente o trabalho, e potencia o trabalho em equipe, onde essa equipe trabalha para alcançar um objetivo comum. Esta metodologia é essencial para muitas empresas atualmente, porque não apenas facilita a definição de objetivos, como ajuda a cumprir os prazos estabelecidos. http://www.youtube.com/watch?v=KAnBZHmvggs

Trabalho em equipe é fundamental TRADICIONAL Sem auto-gestão Fortemente hierarquizada Formada por especialistas Comando-Controle Auto Gestão Auto-gestão Auto-organizada(ninguém diz a equipe como se organizar) Interdisciplinar Não tem Hierarquia formal

Quadro Kanban Historias A FAZER FAZENDO FEITO 1.1 1 1.2 2 2.3 2.1 2.2 Kanban é fluxo continuo. Se os posts pararam de andar por muito tempo é porque há algo errado! Historias A FAZER FAZENDO FEITO 1.1 1 1.2 2 2.3 2.1 2.2 Quebrar as tarefas em partes menores, o ideal e quebrar em 8 horas diárias cada tarefa. Data Entrada:xx/xx/xx Descrição da Atividade, tarefa ou atividade Data Limite xx/xx/xx

Sonho de Consumo de Todo Gestor O pessoal está trabalhando? Exatamente no que? Em qual etapa? O que e quanto está pronto? Kanban pode ajudá-lo.

Eventos Formais do Scrum Reunião de planejamento da sprint Reunião diária Reunião de revisão da Sprint Retrospectiva da Sprint

Papéis e Responsabilidades

Alguns dos elementos que fazem parte do processo do Scrum são: O Product Owner O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. 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; e, 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 acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner http://www.youtube.com/watch?v=L_KX457DwaM#aid=P9mCTTuNHZo

O Time de Desenvolvimento O Time de Desenvolvimento consiste de profissionais que realizam o 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.

- Eles são auto-organizados - Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; -Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. -O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. -Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e, -Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios. -O idéal para um tamanho do time de desenvolvimento e entre 3 a 7 pessoas.

O Scrum Master O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.

Dinamica Linha de produção de aviões

O Scrum Master trabalhando para o Product Owner 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; e, Facilitar os eventos Scrum conforme exigidos ou necessários.

O Scrum Master trabalhando para o Time de Desenvolvimento O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo: 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; e, Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido. http://www.youtube.com/watch?v=NoqbI79p-Rk

Artefatos e Cerimônias Backlog O Backlog é uma lista (em alto nível) de todas as funcionalidades desejadas no produto, ou itens que compõem o produto final, estimadas pelo time e priorizadas pelo Product Owner. E revisado ao final de cada ciclo. Necessita ser definida peso e prioridade para cada item. http://www.youtube.com/watch?v=nr95nzsGB8Y

Estimativas Ágeis Esforço e diferente de duração ou tempo Não pesne em horas ou tempo mas apenas em esforço com relação ao tamanho Não pense em duração pois isto depende do número de pessoas e/ou recursos. Suponha que você queira mover um monte de 100m3 de brita. Quanto tempo levará? -Depende de quais recursos vai utilizar. -No entanto, o tamanho e o esforço sempre serão de 100 m3

Estimar o Backlog Story Points Pontos por História é uma forma relativa de medir o tempo necessário, focado no esforço para implementar uma historia. É uma forma de estimar a dificuldade sem se comprometer com a duração de tempo especifico. As variações nos tamanhos da equipe não afetem as estimativas.

Backlog BurnDown

Estimar o Backlog História 1 2 História 2 5 História 3 8 História 4 2

Priorizar o Backlog O que é mais importante? Técnica Moscow Quem prioriza é o Product Owner! MUST: Sem elas o produto não funciona ou não tem valor; apenas com elas já há um produto SHOULD: Tem que ser incluídas para que o produto esteja completo COULD: itens legais e úteis, fazer se tiver tempo. WONT: não será feito neste projeto. Podem ser incluídas na versão 2. MUST SHOULD COULD WON’T

SPRINT Objetivo ou meta da Sprint A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento. Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro dos limites da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas

REUNIÃO DE PLANEJAMENTO DA SPRINT Parte 1: Reunião Estratégica(seleção do backulog) – Objetivo da Sprint Parte 2: Reunião Tática(criação das tarefas) – Sprint backulog

Exemplo de Quebra de 1 item de Backulog Posto de Gasolina 6 6 1 6 3 6 2 6 5 6 4

Reunião Diária O que fiz? O que farei até a próxima reunião?Ha algum impedimento? No máximo 15 minutos Participa scrum master e time. O TIME conduz a reunião. Fazer sempre no mesmo local e horário SM deve assegurar o comparecimento de todos a reunião diaria.

Reunião de Revisão de SPRINT Participa toda a equipe + stakeholdes(boa prática) Re-leia o objetivo sprint Momento para inspecionar o produto(Aceita/Rejeita!) Maximo de 2h para sprint de 15 dias Não é um momento para testar os itens entregues, mas sim de apresentação, conferência e avaliação dos itens de acordo com a indicação de pronto de cada um dos itens

Reunião de Retrospectiva da Sprint Ao final da iteração as pessoas querem ouvir e dizer o que acertaram e erraram. Principalmente as novas gerações Participa somente a equipe Conhecimento como Lições aprendidas Foco nas melhorias para a próxima sprint “Aplique, verifique, corrija e adapte conforme necessário” Desde a parte técnica, quanto na social(relacionamento,comunicação...)

Dinamica Montar um Hospital com 3 andares Montar um posto de gasolina Montar um prédio de 5 andares Montar uma ponte pencil Montar um casa com garage e toda cercada Montar um estádio de futebol. Montar um parque de diversão