Embed Size (px)
Citation preview
Guia do Papel e Responsabilidade do Scrum
Master
● Remover os impedimentos do time. Sejam técnicos, operacionais ou organizacionais.
● Garantir que o time não sofra interferência externas, mantendo o time protegido.
● Garantir que o método seja seguido sempre buscando a melhoria contínua.
● Facilitar as cerimônias realizando toda a organização e a preparação.
O Papel do Scrum Master
● Garantir que o time se comprometeu com as entregas, não permitindo que o time assuma mais trabalho do que realmente consegue entregar.
● Motivar a produtividade do time mostrando os resultados.● Gerar transparência do andamentos das demandas.● Garantir o compromisso do time com os critérios de aceite
estabelecidos pelo P.O..● O Scrum Master é o responsável por garantir que o scrum seja
entendido e aplicado.● Transparência, inspeção e adaptação.
Não é Papel do Scrum Master
● Definir a solução técnica, arquitetura ou modelo de desenvolvimento.
● Estimar o trabalho a ser realizado.● Definir as tarefas necessárias para a entrega de cada requisito.● Gerenciar o time. O time é auto-gerenciável.● Priorizar as histórias ou alterar a priorização definida pelo P.O..● Distribuir as tarefas entre os membros do time.● Definir os critérios de aceite das entregas.● Estabelecer os critérios de aceite.● Detalhar os requisitos ou definir regras de negócios.
Dicas 1/7❏ Impedimentos... Um bom Scrum Master precisa se atentar aos detalhes do dia a dia para se
antecipar a possíveis impedimentos que o team possa ter (Victor Eiras)❏ Motivação... Acredito que seja de fundamental importância um Scrum Master saber motivar sua
equipe, seja mostrando os resultados para todos, seja conversando com cada um individualmente, pois cada pessoa é diferente da outra, existindo maneiras únicas de se sentir motivada, portanto o Scrum Master precisa entender essas formas de abordagens para cada perfil (Victor Eiras)
❏ Entregas.. o time precisa ter software funcionando sem bugs(ou já corrigidos) ao final da sprint. Se assumir mais trabalho que a capacidade terão iniciado muitas tarefas, porém sem concluir, ou com muitos bugs abertos. Conceito Lean de Jidoka - fazer certo já na primeira vez, isto traz uma produtividade muito grande ao time (Thiago Torricely)
❏ "Priorizar as histórias ou alterar a priorização definida pelo P.O": Nesse ponto, concordo que não seja uma atribuição do SM, mas o SM pode sempre auxiliar o PO nessa tarefa (Paulo Lomanto)
❏ O SM é a consciência (bom ou ruim) do Time ;) (Cihangir Deniz Ozdemir)
Dicas 2/7❏ Mostrando resultados... Se o time não tem visibilidade de seus resultados, logo sentirão
desmotivados (Thiago Torricely)❏ Mais trabalho que a capacidade...Times podem ser otimistas em sua capacidade de concluir
demandas, mas fazendo isto podem falhar em reduzir o débito técnico e afiar suas serras. Gerentes também pressionam times para entregar acima da capacidade por uma falta de entendimento básico de práticas Lean. O estresse em cima de escopo excessivo pode causar desaceleração maciça na equipe. Muri - uma das 3 formas de desperdício no Lean. Logo não conseguirão completar o backlog da sprint, fazendo o time se sentir desmoralizado e sobrecarregado, todos ficam infelizes.E não terão tempo para pensar claramente sobre como melhorar o trabalho na próxima sprint. Todos exibirão os sintomas de times de esportes quando perdem. Pegando menos trabalho na Sprint irá maximizar a probabilidade de sucesso, e através das melhorias contínuas o time conseguirá aumentar a capacidade de aceleração gradualmente (Thiago Torricely)
❏ Complementando o comentário do Thiago Torricely. O importante é o time entender que deve parar de começar e comece a terminar. Limitando o trabalho em andamento e focando nas estórias, uma vez que já foram definidas as prioridades. Após termos a expertise de quantas estórias em paralelo o time suporta com qualidade na execução, podemos tomar as decisões em aumentar o fluxo em andamento ou não (Vitor Martinez)
Dicas 3/7❏ Os itens “Não é Papel do Scrum Master” não são executados pelos Scrum Master, porém o
Scrum Master também precisa garantir que isto esteja sendo feito da melhor forma, realizando coach do time para melhorar nestes pontos. Exemplo: Ajudar o PO a como estabelecer e elaborar melhores critérios de aceite, Ajudar aplicar melhor os conceitos de INVEST nas histórias até virar habito do time, Fazer coach do time em utilização de técnicas de estimativas como Story Points, Verificar juntamente a equipe se os requisitos e regras de negócios estão claras, e o que pode ser melhorado. Engraçado, que pode existir muita atividade para o SM ajudar o time onde não está muito explícito sua atuação (Thiago Torricelly)
❏ Sobre "gerenciar o time". Até o time conseguir ser auto-gerenciavel, pode ser papel do SM um certo nível de interferência, mas não de forma muito intrusiva e autoritária, no processo de gerenciamento. O SM pode adotar algumas técnicas que direcionam o time, mas sempre mostrando a eles que caberá no futuro a eles as suas decisões. Afinal, nenhuma equipe "nasce" auto-gerenciável e pode necessitar de alguns passos iniciais, e ninguém melhor que o SM para dar esse "empurrãozinho" (Paulo Lomanto)
❏ A atuação do Scrum Master vai depender muito da maturidade do time (Cihangir Deniz Ozdemir)
Dicas 4/7❏ Será que um scrum master pode fazer parte do team(desenvolvendo)? Um scrum master que
assume a responsabilidade de uma tarefa perde a visão do "todo", deixando o processo vulnerável (Victor Eiras)
❏ Este item é interessante. Eu já fiz parte de equipe de code e ainda sendo scrum master. Eu deixava fora da velocidade da equipe a minha capacidade de produção, para que a equipe não contasse comigo nas suas metas (Abu)
❏ Abu, perfeito comentário. Já atuei também como coder de algumas equipes das quais eu também era SM. A sua colocação sobre o tempo é essencial nesse caso. As atividades que um SM pode assumir durante a Sprint não podem ser contabilizadas como tempo útil, visto que a sua demanda em atividades que não as de coder podem acabar por prejudicar a performance da sprint (Paulo Lomanto)
❏ Ainda na linha de garantir padrões, o SM não é responsável pela solução técnica, mas deve garantir que os padrões técnicos e arquiteturais são seguidos (Douglas Serra Braga)
Dicas 5/7❏ Ref. Impedimentos: Visando o Futuro do time, com o objetivo de elevar a maturidade do time,
dependendo da maturidade atual, o SM também deve ajudar o time a remover impedimentos (Cihangir Deniz Ozdemir)
❏ Ref. Imepdimentos/ Limitacoes: Ajudar o Time a aceitar as coisas que nesse momento não podem ser mudadas e aprender conviver com as limitações, sem sacrificar a motivação (Cihangir Deniz Ozdemir)
❏ Três simples verdades: 1. é impossível enxergar todos os requerimentos no começo do projeto; 2. Não importa os requerimentos que você tenha, é garantido que eles irão mudar; 3. Sempre haverá mais para fazer do que tempo e dinheiro disponível. Aceitando a primeira verdade quer dizer que você não terá mais medo de começar sua jornada sem saber tudo que está pela frente.Você descobre que requerimentos são feitos para serem descobertos. Aceitando a segunda verdade quer dizer você não terá mais medo da mudança, você sabe que ela virá. Você adapta seu plano quando necessário e segue em frente. E aceitando a terceira verdade você não irá mais se estressar quando sua To-Do list exceder seu tempo e recursos, esse é o estado normal de qualquer projeto interessante (Diego Busin Poblete)
Dicas 6/7❏ Garantir que o time não assuma MAIS e nem MENOS trabalho que consiga entregar conforme a
velocidade dele (isso implica que o Scrum Master deve garantir que a velocidade do time seja medido, pois a velocidade muitas vezes não tem mas deve ter (Cihangir Deniz Ozdemir)
Dicas 7/7❏ Gosto muito da relação com um time de futebol, onde o papel do Scrum Master seria a de um
técnico. Ele não entra em campo para fazer gol e defender, mas orienta, motiva, auxilia o time para alcançar o objetivo, que no caso do futebol seria ganhar a partida e o campeonato, e no caso do Scrum seria entregar uma Sprint e o produto (Victor Eiras)
❏ Ainda sou "beginner" em Scrum, mas acredito que o papel do Scrum Master, é semelhante ao do maestro, orquestrando vários processos. Seu objetivo, é garantir a plena utilização das atividades e políticas estabelecidas, buscando a percepção de valor (Luiz Antonio Gimenez)
P.O. Team
ScrumMaster
Fazer
o que é
certo
Fazer certo
Fazer rápido
Foco do Scrum Master
Dicas❏ Scrum Master é o responsável pelo processo, quando ele está vendo as coisas saírem errado,
ele vai aguardar o Team tomar uma atitude e isso pode levar mais tempo que o projeto comporta ou ele como dono do processo vai fazer a intervenção? (Abu)
❏ Como responsável pelo processo, ele DEVE zelar pelo bom andamento do todo. Se ele, ao perceber uma possível situação que pode causar danos, é sua função procurar entender e atuar sempre que necessário. Se ele sempre deixar o TEAM se auto-ajustar, isso pode não ocorrer e corre-se o risco de ter que efetuar intervenções de maiores escalas, quando pequenas atuações mais constantes nos momentos iniciais podem evitar dores de cabeça muito maiores (Paulo Lomanto)
❏ Ainda agregando ao comentário do Paulo Lomanto aqui, acho que o momento ideal para essa pequenas intervenções, são os dailys, visto que dia a dia temos a oportunidade de corrigir o prumo de algo que está indo para o rumo errado, um dos melhores momentos para o coach por que é a chance de falar a todos do time e não somente a um membro isolado (Anderson Agustinho)
Dicas❏ Fazer rápido não é trabalhar mais rápido e sim ter foco em
remover os desperdícios definidos pelo Lean (Abu)
Lean é uma metodologia ágil, mas também pode ser encarada como uma filosofiaDesperdício é tudo que não acrescenta valor ao que está fazendo
● Aprenda a enxergar o desperdício;● Ele aparece quando você deixa algo pela metade;● Se faz algo que não serve pra nada;● Se faz algo sem necessidade;● Na atenção que perde quando se faz várias tarefas ao mesmo tempo;● No tempo que se perde esperando algo de alguém;● Na movimentação que pode ser evitada;● Criando-se defeitos;● No excesso de controle;
Estratégico
Tático
Operacional
Atitudes de um Scrum Master
● Disruptivo:❏ Capaz de mudar um “status “quo” atual e ajudar a criar um
novo caminho de trabalho.❏ Eliminar distrações.❏ Busca da causa raiz e eliminar.
● Respeito:❏ Pelo team, pela organização e ser íntegro.
Dicas❏ Distuptivo... eu vejo a necessidade de quebrar paradigmas de como fazer as coisas. Um
exemplo: Não basta apenas pegar requisitos em formato de histórias, por que não ter um ambiente que permita realmente contar uma historia, utilizar técnicas como "storytell"? (Abu)
❏ Distrações... como realmente tirar as distrações do Team? Não é neste momento que um Scrum Room realmente faz sentido? (Abu)
❏ Causa raiz... Não basta apenas fazer lições aprendidas, temos que buscar a raiz do problema. 5 Why? Espinha de Peixe? Aplique essas técnicas na Retrospectiva (Abu)
Como garantir um ambiente de Disruptivo?❏ Patrocínio do CEO❏ Blindar a equipe para que ela não seja remanejada para atividades incrementais quando estão desempenhando
atividades de Ruptura❏ Foco no “Owner”. Ter o “empowerment” de se reorganizar (reconstruir) para atender as necessidades do
cliente. Este item é muito importante inclusive para inibir interesses pessoais no modelo de trabalho ou na solução a ser adotada.
❏ Os Teams no modelo Scrum desenvolvem processos conforme a necessidade, mas temos que fazer os processos externos da equipe não tirar a performance de execução da equipe. Isso vai gerar uma melhor eficiência operacional
❏ Criar pessoas que sejam a referencia da mudança que a empresa deseja ter e ser. Com isso temos que focar nos gerentes, para que eles possam ser os professores de suas equipes. Este é o modelo Lean de trabalho, onde o gerente é o professor
❏ Com relação aos Teams o foco continua sendo pessoas e principalmente “indivíduos e interação entre eles, mas do que processos e ferramentas”
❏ Temos que ter o modelo de promover funcionários com habilidades de realizar vários tipos de tarefas. Quanto menor uma equipe é relacionada a necessidades de habilidades para entregar um produto, mais a equipe se torna multidiciplinar, a restrição de recursos leva a este modelo. Empresas grandes disponibilizam recursos abundantes acreditando que isso vai melhorar a performance de execução das tarefas.
Dicas❏ O segredo todo esta neste "disruptivo", isto é, fazer diferente. Afinal já sabemos os resultados
no nosso modelo de trabalho, para resultados diferentes temos que fazer diferente (Abu)❏ Uma forma de promover habilidades diferentes seria criando um Tour de ocupação do
funcionário. Por exemplo 1 ano trabalhando em projetos com Java, depois 1 ano trabalhando com projetos de mobile, depois 1 ano com projetos de Front-end. O mesmo pode ser feito nas áreas de negócios, fazendo a pessoa desenvolver habilidades de várias áreas, construindo uma visão mais abrangente do todo. A pessoa terá crescimento real na carreira, e a empresa irá se beneficiar de equipes motivadas com multiplas habilidades (Thiago Torricelly)
❏ Complementando essa discussão, esse é um fator realmente complexo para muitos SMs, equipes, empresas, projetos. É fácil encontrar diversos profissionais que preferem o caminho da especialização ao invés da multidisciplinaridade. Raros são os casos de profissionais que "aceitam" ou gostam de atuar em diversas especialidades (Paulo Lomanto)
❏ Ambiente. Tudo o que as pessoas veem, escutam e sentem deve ser controlado. Os Líderes em geral influenciam e muito no ambiente, portanto, para mudar um ambiente devemos mudar os líderes (Douglas Serra Braga)
● Inspirador:❏ Gerar entusiasmo e energia para outras pessoas.❏ Sinergia no foco da meta da sprint.❏ Burndown ou Up ajudar na transparência.
● Treinar:❏ Indivíduos e teams.❏ Fazer desenho de como grandes team trabalharam no
passado.❏ Foco no team e não no individuo.
Dicas❏ Meta... Se não for estabelecido uma meta a ser alcançada, o team não compreenderá
facilmente o valor gerado (Victor Eiras)❏ Eu sempre gostei de comunicação visual, podemos mostrar como grandes equipes trabalharam
no passado fazendo desenhos e até mesmo processos (Abu)❏ Alguns elementos básicos não devem ser negociados com o team. Eu entendo que cerimonias
e ferramentas do Scrum são de responsabilidade do Scrum Master. Dashboard Visual e em papel (não eletrônico), Burndown, Calendário de Datas Importantes do projeto, Timeline para todos terem visão do todo são alguns exemplos de ferramentas originais e complementares ao Framework. O Scrum Master tem que entender bem o Framework e Princípios Ágeis e fazer o que é certo para o processo. Quando ele abre mão desta responsabilidade como o team vai ter o seu "porto seguro"? (Abu)
❏ O que o Scrum Master deve fazer quando se deparar com um team de baixa qualidade técnica, onde a entrega fique comprometida? É responsabilidade dele? Code review; Pair programming (Victor Eiras)
Dicas❏ Ainda sobre comunicação visual X meta do time, uma coisa legal a se fazer é colocar no board
o nome da feature que o time entregará ao final da Sprint, assim fica fácil de mostrar a todos qual o valor estaremos entregando ao final daquela iteração (Anderson Agustinho)
● Desembaraçado:
❏ Remover impedimentos para aumentar a produtividade.❏ Na retrospectiva pergunte ao team como você pode ser um
Scrum Master melhor.❏ Grandes Scrum Masters encorajam seu team a ser adaptativo,
ter ação, divergir, ter avaliação, explorar (aprofundar), tentar, envolver, visualizar e exibir.
Dicas❏ Desenvolver uma cultura de Feedback constante, do produto, processo, team e também do
próprio Scrum Master, para que o Scrum Master possa se tornar um Scrum Master melhor (Douglas Dornel)
❏ Complementando: o SM não deve esperar apenas as retrospectivas para alcançar esses feedbacks. Ele deve buscar isso o tempo todo. Inclusive, são em conversas informais com membros dos TEAMS e em particular que o SM muitas vezes obtém os melhores insights para seu aperfeiçoamento com o TEAM (Paulo Lomanto)
❏ Complementando… Essa troca de feedbacks entre SM e team coloca todos no mesmo eixo, melhora a sinergia e faz ambas as partes se sentirem importantes e respeitados em suas atividades. Mas sempre tomando o cuidado de como apontar os pontos a melhorar, pois nem sempre é aceito por todos de forma agradável, podendo gerar futuros problemas de relacionamento à equipe (Vitor Martinez)
❏ Uma forma de aprendizado para o Scrum Master é participar, como ouvinte, de cerimônias com outros teams para conhecer diferentes formas de processos, já que no Scrum não existe certo e errado, mas sim uma adaptação de acordo com o contexto em questão (Victor Eiras)
● Alternativa:❏ Saber propor uma alternativa para a cultura atual.❏ Scrum Master deve ajudar a transformar a cultura da empresa
para que o team scrum possa prosperar. Exemplos: ted.com e “the marsh mallow challenge” or “the penny game”.
❏ Usar a técnica de t-shaped people para equipes multidiciplinares (responsabilidade compartilhada).
❏ O team deve entender sua definição de “done”.
O Scrum Master deve promover debates ao término de cadasprint:
❏ Novas prioridades.❏ Nova release.❏ Novo requisito.❏ Novo processo.❏ Novo design.❏ Novo plano.❏ Novas estimativas.❏ Nova velocidade.
O Scrum Master deve evitar mini-waterfalls.
Dicas❏ Novos Processos: Introduzir mudanças de forma fragmentada a cada nova sprint, pode ser uma
forma sábia de entender o que faz aumentar a velocidade do time. Ao invés de ter muitas mudanças ao mesmo tempo, e não ter como acompanhar quais realmente influenciaram na melhoria dos resultados. É uma prática de Kaizen, fazer melhorias no processo passo-a-passo como numa escada, obtendo aceleração a cada nova sprint (Thiago Torricelly)
❏ Perfect! Só adicionaria um item nesse pensamento: mudanças, mesmo que pequenas, precisam ser mensuradas (antes X depois) e precisam de um tempo de maturação. Não podemos correr o risco de efetuar uma pequena mudança, e no final de apenas 1 sprint, tomar conclusões definitivas. Toda mudança, ao meu ver, precisa de acompanhamento, ajustes e observação ao longo do tempo para medir a sua efetividade (Paulo Lomanto)
● Tato❏ Sabe lidar com cada individuo do time.
● Capacitar❏ Ajudar outras pessoas a serem mais efetivas.❏ O Scrum Master deve treinar o team para que o team não
necessite dele.❏ O Scrum Master deve buscar grandes fustrações da equipe e
removê-las (retrospectiva).❏ Ter um mapa funcional da empresa ajuda a melhorar o
relacionamento e abrangência de influência.
Dicas❏ Sobre "Tato", costumo brincar com algumas pessoas dizendo sempre que o SM é, além de
tudo, um psicólogo (além de engenheiro, médico, advogado, etc), pois ele tem que se envolver com cada indivíduo, entender como está a sua vida, a sua rotina, entender o que o motiva ou não, saber se está com algum problema que afete o seu dia-a-dia. Enfim, um bom SM cria uma conexão empática com os membros dos times (Paulo Lomanto)
Não ter proxies entre o P.O. e o teamMétricas:
❏ Iterations.❏ Testing.❏ Users Stories.❏ Product Owner.❏ Product Backlog.❏ Estimates.❏ Burndown.❏ Team Disruption.❏ Team Ownership.
Trabalhar com nível de maturidade do teams aos princípios ágeis.Observação: Anexo 2
Dicas❏ Uma metrica super interessante eh o custo de ter um proxy entre o PO o Team, por exemplo o
PO fica 2 dias sem responder definiçoes de negocio para o time, isso gerou uma dificuldade para o time progredir nas atividades, entao eh realizado um calculo das horas improdutivas do time (em R$) aguardando resposta do PO (Douglas Dornel)
❏ Sim podemos ter métricas… (Abu)
● Empatia:❏ Sensível aos que o rodeiam.❏ Aprender a escutar as pessoas (vale para Scrum Master e
Team).
Cerimônias
Executar:❏ Sprint Planning.❏ Sprint Review.❏ Sprint Retrospectiva.❏ Daily. ❏ Grooming.
Observação: Anexo 1
Dicas❏ O maior ganho na realização de retrospectivas, reviews, daily, debates e outras dinâmicas ágeis
é nos aproximar uns dos outros, deixando de ser apenas mais uma pessoa da equipe. Devemos fomentar a sinergia, amizade a ajuda entre os membros da equipe, deixando claro para a equipe como está a situação de trabalho e o rendimento de cada envolvido (Douglas Chaves)
❏ No Scrum cerimonias não tem negociação e é responsabilidade do Scrum Master executa-las (Abu)
Ferramentas
Executar:❏ Release Burndown.❏ Sprint Burndown.❏ Software (se necessário).❏ Dashboard.
Dicas❏ A beleza destas ferramentas é que mostram o progresso do time e o quanto resta de trabalho
em direção ao Objetivo da Sprint/Release. Se a linha do burndown está muito abaixo, o time precisa rapidamente implementar um padrão com um procedimento de emergência. O Scrum Master precisa ajudar o time agir antecipadamente, antes de derrapar com a falha da sprint. Ser Ágil é responder rápido a mudanças (Thiago Torricelly)
❏ Temos que usar as ferramentas para promover uma comunicação mais efetiva, de novo, ferramentas do Scrum, não tem negociação, é de responsabilidade do Scrum Master utilizar (Abu)
Processos
A empresa define processos necessários e o Scrum Masterdeve trabalhar respeitando esses processos.Exemplo:
❏ Itil.❏ Cobit.❏ Segurança.❏ Compras (Aquisição).❏ PMO❏ etc.
Dicas❏ Por mais que alguns dos processos pareçam implicar em "não agilidade" (ex.: ITIL) ela deve ser
incorporada às equipes ágeis. Se pensarmos em todos os processos nesse slide, eles podem co-existir sem problemas nos princípios ágeis, com as suas devidas adaptações (Paulo Lomanto)
❏ Concordo Plenamente. O grande ponto é que "Não existe equipe Ágil" se não existir "Organização Ágil". Definir o Valor, Eliminar os desperdícios utilizando o VSM (Value Stream Mapping), Garantir a Fluidez nos Processos, Fazer com que a Demanda seja Puxada mais a Busca pela Perfeição … Processos ITIL ou de PMO mal implementados, irão gerar gargalos e a "Equipe Ágil" irá sofrer as consequências (Douglas Serra Braga)
Dicas❏ Um exemplo de processo end-to-end. Eu não gosto do scrum master apenas dentro do Team,
eu entendo que ele deve olhar o processo de ponta a ponta e desempenhar suas funções nesta abrangência (Abu)
Anexo 1Serie: “Como Fazer”
Como Fazer Daily Meeting
O que é?● Reunião de 15 minutos realizada pela equipe para o alinhamento e sincronismo, das atividades
que estão sendo realizadas, vão ser realizadas, já terminadas e problemas que estão impossibilitando a conclusão dos trabalhos.
O que não é?● Reunião de debates técnicos de como vamos fazer nossas atividades. Também não é uma
reunião de atribuição de trabalho as pessoas, em Scrum a equipe deve se auto- organizar com as atividades que devem ser realizadas.
● Daily também não serve para passar o status da tarefa para o superior
Organização● Ser realizado em frente ao Dashboard ou monitor com a ferramenta de gestão utilizada(Trello,
Kanbanize, Jira,..).
Execução● Todos da equipe falam o que estão fazendo, vão fazer, já terminaram de fazer e se possuem
impedimentos;
● Product Owner também fala o que está preparando para a próxima Sprint;
● Scrum Master fala os impedimentos que já resolveu e os que pretende resolver;
● Responsáveis pela execução do plano de ação da retrospectiva anterior lembrar do plano ao
término da Daily Meeting;
● Scrum Master atualiza o Sprint Burndown;
Saída do Processo● Dashboard ou ferramenta de gestão com tarefas atualizadas;
● Sprint Burndown atualizado;
Boas Práticas● Uso de ”Token” para sinalizar quem fala;
● Todos sempre estarem na frente do quadro de post-its ou monitor segurando / mostrando o
post-it que refere-se ao que está sendo falado;
● Muta para quem chegar atrasado, faltar ou não lembrar o que fez no dia anterior;
● Painel de retrospectiva ao término da Daily Meeting com a informação se a equipe gostou ou
não da reunião;
Exemplo● Team Scrum na frente do quadro (Product Owners, Scrum Masters e Equipe).
● Todos falam: o que fiz, o que pretendo fazer e quais os impedimentos que possuo.
Token● Qualquer item pode ser um Token, caneta, lápis, relógio, um bloco de post-its, brinquedos, etc;
Quadro de Feedback do Daily● Pegar ao término da Daily Meeting a opinião de todos e já identificar o que podemos melhorar.
Caixa de Multa por Falhas no Daily Meeting● MULTA para quem: Chegar atrasado, não lembrar o que foi feito, não saber o que vai fazer, etc
Como Fazer Sprint Planning
O que é?● Reunião em que o Team Scrum faz o entendimento do Sprint Backlog;● Reunião em que o Team Scrum define a estratégia de solução e testes do Sprint Backlog;● Reunião em que o Team Scrum determina as tarefas necessárias para a entrega do Sprint
Backlog;
Organização● Convidar todos os interessados com antecedência;● Reservar sala;● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;
Documentos de Entrada do Processo● Histórias aderentes ao conceito de Ready;● Calendário da Sprint;
Execução● Product Owner apresenta a meta da Sprint;● Product Owner apresenta todas as histórias da Sprint para a equipe;● Equipe revisa se as histórias apresentadas atendem a meta da Sprint;● Equipe faz a estimativa de cada história utilizando Planning Poker;● Equipe se compromete com a quantidade de histórias que ela consegue fazer na Sprint, de
acordo com sua velocidade;● Equipe pega cada história e quebra em tarefas;● Equipe faz a estimativa de horas de cada tarefa utilizando Planning Poker;● Scrum Master atualiza a velocidade da equipe;● Product Owner fica disponível durante toda a cerimônia de planejamento de Sprint;
Saída do Processo● Sprint Backlog;● Dashboard ou Jira com tarefas estimadas em horas;● Sprint Burndown;
Como Fazer Sprint Review
O que é?● Reunião de oficialização das histórias aceitas e rejeitadas pelo Product Owner.
O que não é?● Reunião de apresentação do produto para o Product Owner.
Observação● As histórias devem ser entregues ao Product Owner durante a execução da Sprint e não
apenas na Sprint Review;● Isso permite fazer os pequenos acertos necessários durante a execução da Sprint para que o
Product Owner possa dar o aceite na história;● Este modelo de trabalho evita deixar para as próximas Spritns os pequenos acertos que
poderiam ser resolvidos no momento de apresentação ao Product Owner;
Organização● Convidar todos os interessados com antecedência;● Reservar sala;● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;
Documentos de Entrada do Processo● Sprint Backlog;● Calendário da Sprint;● Conceito de Done;● Sprint Burndown;
Execução● Equipe apresenta as histórias em conformidade com o conceito de Done ao Product Ower;● Product Owner da o aceite integral, parcial ou recusa a história;● Scrum Master atualiza o documento de Sprint Review;
Saída do Processo● Documento de Sprint Review.
Como Fazer Retrospectiva
O que é?● Reunião de melhoria do processo para reduzir desperdícios;● Reunião de foco a busca da causa raiz que levou a não entrega de um item de backlog;
Organização● Convidar todos os interessados com antecedência;● Reservar sala;● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet;● Ter na reunião as informações do Sprint Planning e Sprint Review;● Ter na reunião as informações da retrospectiva anterior;
Documentos de Entrada do Processo● Sprint Planning;● Sprint Review;● Plano de Ação da Sprint Anterior;
Execução● Scrum Master apresenta as informações do plano de ação da retrospectiva anterior,
identificando o que foi solucionado e não solucionado;● Todos escrevem os pontos positivos da Sprint sem diálogo entre os participantes;● Todos escrevem os pontos negativos da Sprint sem diálogo entre os participantes;● Scrum Master lê todos os post-its deixando aberto o diálogo para entendimento de todos;● Scrum Master promove a priorização dos pontos negativos utilizando a técnica de Dot Poitns;● Scrum Master junto com todos elaboram o plano de ação;● Scrum Master deixa o plano de ação visível a todos no local que é realizado o Daily Meeting;
Saída do Processo● Plano de Ação da Retrospectiva;
Quadro de Retrospectiva - Continuar, Melhorar e Parar
Quadro de Retrospectiva - Positivo e Negativo
Como Fazer Grooming
O que é?● O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog;● O Grooming (preparação) do Product Backlog é o ato de adicionar detalhes, estimativas e
ordem aos itens no Product Backlog.● É um processo contínuo em que o PO e o time colaboram com os detalhes dos itens do Product
Backlog.● Durante o Grooming os itens são analisados e revistos, no entanto, eles podem ser atualizados
a qualquer momento.
Organizar o backlog é um processo contínuo que envolve:
● A descoberta de novos itens, assim como alteração e remoção de itens antigos;● Quebrar histórias muito grandes;● A priorização dos itens do backlog (trazendo os mais importantes para o topo);● Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;● Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);● Incluir critérios de aceitação;
Como Fazer Dashboard
O que é? Para que Serve?● Quadro com as atividades que a equipe esta executando● Permite a gestão compartilhada das atividades pela equipe● Permite gestão “radiano” onde todos conseguem ter a percepção que algo foi mudado● Mostra a visão do “todo”Documentos de Entrada do Processo● Sprint Backlog● Tarefas de cada item do Sprint Backlog
Execução● Desenhar o quadro em local que todos da equipe possam visualizar● Ter a informação da equipe, pode ser “avatar”● Pode ser processual, quadro para técnica de Kanban onde o processo fica visível oupode ser de Scrum onde o processo é apenas “A fazer”, “Fazendo”, “Impedimento” e“Feito”● Deixar claro o que cada pessoal esta fazendo● Deixar claro o que já esta pronto● Deixar claro o que esta com impedimento● Deixar claro o serviço que não foi previsto● Deixar claro os indicadores de entregas durante a SprintSaída do Processo● Dashboard montado
Quadro de Dashboard
Indicadores da Sprint
Avatar
Quadros Modernos
Quadro Sofisticado
Quadro de Bugs (Vivo com, Crítico, Fazer
Como Fazer Agenda da Sprint
Organização● Não se aplicaDocumentos de Entrada do Processo● Não se aplicaExecução● Scrum Master deve montar um calendário visual com as datas importantes da Sprint,como planning, retrospectiva, review, daily meeting, grooming● Scrum Master deve colocar no calendário eventos já definidos e conhecidos comoreuniões, treinamentos ou feriados● Scrum Master deve deixar em observação a ausência já conhecida de profissionais daequipe, seja por motivos de ferias, medico, etc● Scrum Master com esses dados deve calcular a capacidade da equipe, semprelembrando de subtrair 15% para cerimonias do Scrum e 10% para groomingSaída do Processo● Calendário da Sprint
Como Fazer Ready e Done
Organização● Convidar todos os interessados com antecedencia● Reservar sala● Disponibilizar na sala post-its, canetas, projetos, notebook, acesso a internetDocumentos de Entrada do Processo● Não se aplicaExecução● Todos devem definir em conjunto o conceito de Preparado e Pronto por BlocoSaída do Processo● Documento de Ready and Done da Sprint● Documento de Ready and Done da Regressão● Documento de Ready and Done da Transição● Documento de Ready and Done da Operação
Como Fazer Estimativas
O que é? Para que Serve?● Técnica de medir esforço de todos os itens do Product Backlog, Release Backlog, SprintBacklog, Grooming, etc● Importante: do esforço buscamos o tempo e nunca a busca do tempo em primeiro lugar● A estimativa vai garantir com que a equipe esteja entendendo a demanda, seguindo oprincipio que conseguimos apenas estimar o que entendemos● Ao termino da estimativa a equipe sabe o que fazer para planejar como fazer e aempresa tem a visão do tempo necessário para fazer as demandasOrganização● Convidar todos os interessados com antecedencia● Reservar sala● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internet
Documentos de Entrada do Processo● Documento de Ready e Done● Calendário da Sprint● Product BacklogExecução● Product Owner apresenta todas as histórias do product backlog para a equipe● Equipe identifica uma história para ser utilizada como ancora de referencia naestimativa de todas as outras histórias● Equipe faz estimativa de pontos de esforço utilizando planning poker para cada história● Scrum Master monta em uma parede colunas com os números da régua de fibonacci● Equipe vai colocando na parede e na coluna adequada a história com o esforçoestimado● Equipe sempre vai validando todas as histórias de uma determinada coluna, garantindocom isso coerência entre as histórias que estão nessa coluna● Equipe define a sua velocidade com as informações obtidas pela estimativa e tamanhoda Sprint
Saída do Processo● Product Backlog estimadoExemploQuadro de Estimativas● Monte os números de fibonacci em colunas. Para cada coluna coloque um desenho querepresenta o número, pode ser cachorros, dinossauros, copos de bebidas, etc● Pegue um item de backlog para ser referencia de medição dos demais itens de backlog,chamamos de ancora de referencia● A ancora de referencia é uma boa pratica receber valor igual a 2 (dois)● Estime todos os itens de backlog necessários utilizando o conceito de Planning Poker● Coloque cada item de backlog estimado na coluna correspondente● Valide sempre se todos os itens de backlog de uma coluna são de mesma grandeza deesforço.
Planning Poker Sem Baralho e Com Baralho● Os valores devem ser mostrados ao mesmo tempo, para que nenhuma pessoa possaser influenciada por outro colega do Team● Esta técnica permite termos respeito a opinião de todos● Quando não existe consenso na estimativa mas os valores são vizinhos na régua defibonacci podemos deixar o pior caso● Quando não existe consenso na estimativa e os valores não são vizinhos na réguade fibonacci devemos pedir para as pessoas justificarem sua estimativa e jogamos oPlanning Poker de novo● Quando os valores estimados são muito grandes, devemos quebra o item de backlogem pedaços menores e estimar carda pedaço● Depois de três jogadas de Planning Poker para um item de backlog e este item debacklog não ter um consenso, colocamos ele como “?” e aguardamos a remoção dealgumas incertezas pelo Product Owner até o item de backlog ser possível de serestimado
Exemplo de Planning Poker
Como Fazer a Inception
O que é?● Reunião de transformação de um plano de negócio em um produto, seu Roadmap epriorização do que vai fazer parte do MVP (minimum viable product)Organização● Convidar todos os interessados com antecedencia● Reservar sala● Disponibilizar na sala post-its, canetas, projetor, notebook, acesso a internetDocumentos de Entrada do Processo● Canvas de Negocio
Execução● Product Owner apresenta o Canvas de Negócio a todos● Equipe junto com o Product Owner desenvolvem as histórias● Equipe monta arquitetura inicial do produto● Equipe monta mapa de navegação de interfaces● Equipe monta modelo de domínio do produto● Usar paredes para arquitetura inicial, modelo de domínio, mapa de navegação, históriasetcSaída do Processo● Product Backlog● Roadmap● Visão do Produto● Arquitetura Inicial do Produtp
ExemploNome do Produto, Roadmap, etc
Mapa de Navegação, Histórias, etc
Story Boards
Canvas de Negócio
Product Box
Anexo 2Exemplo de Indicadores
Backlog❏ Projeto possui backlog❏ Projeto possui backlog estimado❏ Projeto possui backlog priorizado❏ Projeto possui tamanha das sprints definidos (1, 2, 3, ou 4 semanas)❏ Projeto possui Scrum Master❏ Projeto possui Product Owner❏ Projeto possui cronograma (backlog distribuído por sprint's)❏ Projeto possui centro de custo para contabilização de custos❏ Projeto possui repositório de versionamento de código❏ Projeto possui custo médio da equipe para calculo de custo por sprint❏ Riscos identificados do projeto (backlog)
Sprints❏ Pontos planejados por sprint❏ Pontos entregues e aceitos por sprint❏ Pontos entregues e não aceitos por sprint❏ Pontos entregues e aceitos parcialmente por sprint❏ Pontos não executados por sprint❏ Capacidade em horas de trabalho da equipe na sprint❏ Total de todas as tarefas estimadas em horas por
sprint❏ Total de horas da equipe utilizada para Scrum (gasto
no framework)❏ Diferença entre total de horas de trabalho da equipe e
total de horas das tarefas executadas pela equipe (identificar a perda real da equipe, exemplo 8:48 contrato de trabalho mas de produção 7:00)
❏ Quantidade de histórias não previstas adicionadas na sprint
❏ Total de pontos não previstos das histórias adicionadas na sprint
❏ Quantidade de histórias da sprint❏ Quantidade de histórias prontas para desenvolvimento
da sprint (Ready) colocadas no planning❏ Quantidade de histórias realmente prontas para
desenvolvimento identificadas pela TIME na review❏ Data e hora de abertura de um impedimento❏ Data e hora de fechamento de um impedimento❏ Percentual de cobertura de TDD dos algoritmos da
sprint❏ Riscos identificados na sprint❏ Categorização de impedimentos (infra, qualidade, regra
de negocio, api de terceiros, etc)❏ Total de bugs gerados na sprint❏ Possui a meta da sprint definida❏ Quantidade de pontos da meta da sprint
Histórias❏ Possui pontos❏ Possui priorização❏ Possui critério de aceite❏ Possui tarefas
Tarefas❏ Possui estimativa em horas, com intervalo de 1 a 8 hrs
Outros❏ Total de tarefas novas por dia❏ Total de impedimentos por dia❏ work real de cada história❏ wait real de cada história❏ Banco de horas por pessoal da equipe ao termino de cada sprint❏ Incidentes em produção❏ % turnover do projeto❏ Produto possui roadmap❏ Happiness Index das pessoas envolvidas
Agenda de Trabalho❏ Possui agendado as reuniões de planejamento da sprint❏ Possui agendado as reuniões de retrospectiva❏ Possui agendado as reuniões de review❏ Possui agendado as reuniões de daily
Evidencias de Execução❏ Planejamento de Sprint❏ Retrospectiva❏ Review❏ Daily
Review – Satisfação de Produto❏ Possui a informação das histórias aceitas pelo PO❏ Possui a informação das histórias não aceitas pelo PO❏ Possui a informação das histórias aceitas parcialmente pelo PO
Qualidade❏ Quantidade de Bugs❏ Quantidade de Necessidades de Refactory❏ Quantidade de Incidentes❏ Quantidade de Problemas❏ Cobertura de testes automatizados❏ Testes de regressão do produto não automatizados
Tempo e Custo
Portfólio❏ SPI consolidado do portfólio❏ CPI consolidado do portfólio❏ Índice de pontualidade do portfólio: percentual de projetos que estão com o cronograma
em dia.❏ Índice de projetos dentro do orçamento: percentual de projetos que estão com o
cronograma em dia.❏ Índice de pontualidade financeira do portfólio: pode ser calculado pela seguinte fórmula
= orçamento_total_disponível_para_o_portfólio_até_hoje_em_R$ - total_gasto_no_portfólio_até_hoje_em_R$
❏ ROI (Retorno do Investimento) do portfólio: pode ser calculado pela seguinte fórmula = (lucratividade_dos_projetos_em_R$ - custo_total_dos_projetos_em_R$) / custo_total_dos_projetos_em_R$
❏ Índice de clima organizacional da equipe: a partir de pesquisa de clima organizacional❏ Índice de satisfação dos clientes internos e externos: a partir de pesquisa junto a clientes
internos e externos
Anexo 3Scrum Room
Scrum Room❏ Sala do time aberta, estimulando comunicação face a face e interações regularmente❏ Espaço na parede para Kanbans com post-its, Backlog do Produto e da Sprint, Dashboards de
acompanhamento do projeto, diagramas de arquitetura, e outros artefatos que desejar colocar na parede.
❏ Eliminar fios onde puder (laptops na rede wireless, mouses sem fio, etc) para boa mobilidade da equipe
❏ Quadro branco - Indispensável (móvel se possivel)❏ Espaço para a Daily standup meetings❏ Televisão para Demo meetings e outras reuniões❏ Webcam da sala para comunicação com times externos❏ Mesa extra para reuniões ou desenhos de cartões❏ Mobilia móvel para reconfigurar o espaço❏ Mesas sem divisórias❏ Ergonomia: cadeiras de qualidade para boa produtividade❏ Algum espaço privado para utilizar quando necessário❏ Conveniências: Café, Impressora, Armários, Frigobar
Dicas❏ Gostei da Idéia do Scrum Room. Funciona como as Salas onde se reúnem as equipes Kaizen.
Naturalmente, as pessoas reagem ao ambiente a qual estão inseridas e criar um ambiente onde as pessoas possam VIVER o Projeto certamente traz muito resultado. É o funcionamento natural do Cérebro e não tem como fugir (Douglas Serra Braga)
Anexo 4Ferramentas
Skill / Team
Canvas de Risco
Aderência ao Processo / Métricas
Canvas de Entregas
Canvas de Treinamento
Mapeamento de Processos
Canvas de Negocio
Big Picture
Anexo 5Dinâmicas para Ajudar na Mudança de
Cultura
Exercício – 1
Aumentando Produtividade pela Redução de Estoques
Exercício – 2
Aumentando a Produtividade por Executar uma Tarefa por Vez
Exercício – 3
Aumentando a Produtividade por Executar uma Tarefa por Vez
Exercício – 4
Scrum na Pratica
✓
✓
✓
☑
☑
✓
✓
✓
✓
✓
✓
59
Exercício – 5
Boneco de Papel
Exercício – 6
Eficiência Operacional
Anexo 6Glossário
Behavior Driven Development - BDD
O que é?● Técnica de desenvolvimento Ágil que encoraja a colaboração entre desenvolvedores, setores
de qualidade e pessoas não-técnicas ou de negócios num projeto de software. Benefícios
● Melhora a comunicação;● Documentação dinâmica;● Visão do todo;
Práticas de BDD
● Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora para Dentro);
● Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código;● Automatizar os exemplos para prover um feedback rápido e testes de regressão;
Palavras Chave● Dado que● Quando● Então
Exemplo
Cenário 1:
Estoque disponível
DADO QUE o estoque da coca-cola é de 50 unidades
QUANDO informo uma venda de 40 unidades
ENTÃO a venda é registada
E o estoque passa a ser de 10 unidades
Cenário 2: estoque indisponível
DADO QUE o estoque da coca-cola é de 50 unidades
QUANDO informo uma venda de 60 unidades
ENTÃO a venda não é registada
E é exibida na tela a mensagem "estoque insuficiente!"
Cartão de Histórias
O que é?
● Técnica de captura de requisitos;● Pode ser desenvolvido na reunião de Grooming ou na cerimônia de Sprint Planning;● Deve ser escrito a partir de uma perspectiva do usuário, logo, não deve possuir jargões
técnicos;
Ele tem o objetivo de capturarmos:
● Conversa de cada história;● Conversa de cada critério de aceite;● Capturar cada comportamento esperado pelo Product Owner;● Conversa de como vamos testar a história, seus critérios de aceite e comportamentos;
Dashboard
O que é? Para que serve?
● Quadro com as atividades que a equipe está executando;● Permite a gestão compartilhada das atividades pela equipe;● Permite gestão “radiano” onde todos conseguem ter a percepção que algo foi mudado;● Mostra a visão do “todo”;
Documentos de Entrada do Processo
● Sprint Backlog;● Tarefas de cada item do Sprint Backlog;
Execução
● Desenhar o quadro em local que todos da equipe possam visualizar;● Ter a informação da equipe, pode ser “avatar”;● Pode ser processual, quadro para técnica de Kanban onde o processo fica visível ou pode ser
de Scrum onde o processo é apenas “A fazer”, “Fazendo”, “Impedimento” e “Feito”;● Deixar claro o que cada pessoa está fazendo;● Deixar claro o que já está pronto;● Deixar claro o que está com impedimento;● Deixar claro o serviço que não foi previsto;● Deixar claro os indicadores de entregas durante a Sprint;
Saída do Processo
● Dashboard montado;
Quadro de Dashboard
Indicadores da Sprint
Gestão VisualUtilizar Gestão Visual para Entendimento de Todos
● Utilizar as paredes para colocar o Sprint Backlog;
● Utilizar as paredes para colocar desenhos de arquitetura;
● Utilizar as paredes para colocar os Cartões de Histórias;
● Fazer com que o trabalho manual seja realizado por todos;
● Fazer a equipe desenhar o negócio com DDD (Domain Driven Design) para garantir que estão entendendo o Sprint Backlog;
GroomingO que é?
● O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog;● O Grooming (preparação) do Product Backlog é o ato de adicionar detalhes, estimativas e
ordem aos itens no Product Backlog.● É um processo contínuo em que o PO e o time colaboram com os detalhes dos itens do Product
Backlog.● Durante o Grooming os itens são analisados e revistos, no entanto, eles podem ser atualizados
a qualquer momento. Organizar o backlog é um processo contínuo que envolve:
● A descoberta de novos itens, assim como alteração e remoção de itens antigos;● Quebrar histórias muito grandes;● A priorização dos itens do backlog (trazendo os mais importantes para o topo);● Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;● Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);● Incluir critérios de aceitação;
MoSCoWO que é? Para que serve?
● Técnica de priorização;● Vai permitir uma busca de
funcionalidades obrigatórias do projeto, na visão do Product Owner.
Técnica
● MUST – Tem que ter;● SHOULD – Deveria ter;● COULD – Poderia ter;● WANT – Interessante ter;
Pair ProgrammingO que é?
“Boa prática” da metodologia Extreme Programming – XP; Execução
Programação feita em par; Revezar, periodicamente, as duplas;
Benefícios
Entendimento da regra de negócio; Nivelação do conhecimento técnico; Minimização de erros;
Planning PokerO que é?
● Técnica de medir esforço de todos os itens do Product Backlog, Realease Backlog, Sprint Backlog, Grooming, etc.
Planning Poker Sem Baralho e Com Baralho
● Os valores devem ser mostrados ao mesmo tempo, para que nenhuma pessoa possa ser influenciada por outro colega do Team;
● Esta técnica permite termos respeito a opinião de todos;● Quando não existe consenso na estimativa mas os valores são vizinhos na régua de fibonacci
podemos deixar o pior caso;● Quando não existe consenso na estimativa e os valores não são vizinhos na régua de fibonacci
devemos pedir para as pessoas justificarem sua estimativa e jogamos o Planning Poker de novo;● Quando os valores estimados são muito grandes, devemos quebra o item de backlog em pedaços
menores e estimar carda pedaço;● Depois de três jogadas de Planning Poker para um item de backlog e este item de backlog não ter
um consenso, colocamos ele como “?” e aguardamos a remoção de algumas incertezas pelo Product Owner até o item de backlog ser possível de ser estimado;
Product BacklogO que é?
● Lista de requisitos do produto;● Geralmente é feito em um arquivo excel e compartilhado entre o Team Scrum;
Tema Item Importância Estimativa Como demonstrar Notas Status
Paciente
Sendo um paciente posso fazer meu cadastro para agendar uma consulta.
100
8
Entrar no site, ir para página de cadastro de paciente, fazer o cadastro, ir para página de login e logar-se.
Criptografar senha do paciente.
Concluído
Login
Sendo um usuário posso logar no sistema.
30
5
Entrar no site, ir para página de login e logar-se.
Pendente
Definition of Ready Definition of Ready
● É uma história que já pode ser estimada pela equipe, porque ela atende a todos os quesitos necessários para seu desenvolvimento, ou seja, é uma história clara e entendida por todos.
● A definição de Ready é elaborada em comum acordo entre o time e o PO, podendo variar de equipe para equipe, e também entre projetos.
● O acordo entre equipe e PO é necessário para que exista a preocupação de preparar a história antes do planejamento da Sprint.
Definition of Done● É uma história que teve seu desenvolvimento terminado, e já
pode ser avaliada na reunião de revisão pelo PO.● A definição de Done é elaborada em comum acordo entre o
time e o PO.● Esse acordo é necessário para que o time saiba quais são
todos os artefatos que devem ser gerados durante o desenvolvimento de uma história.
● Essa definição deve conter uma lista simples de atividades que agregam valor ao produto.
Roadmap
O que é?
● “Mapa” que visa organizar as metas de desenvolvimento de um software.
O que é?● Gráfico utilizado para representar, diariamente, o progresso do trabalho em desenvolvimento,
fazendo um comparativo entre o planejado e o realizado;● Eixo X : Dias da Sprint;● Eixo Y : Total de pontos por história;
Story PointO que é?
● Um Story Point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma feature, a complexidade desse desenvolvimento, o risco contido nele, e por aí vai.” [Mike Cohn, Agile Estimation and Planning];
● Importante: do esforço buscamos o tempo e nunca a busca do tempo em primeiro lugar;
Test Driven Development - TDD
O que é?● Desenvolvimento orientado a testes;● Técnica de desenvolvimento de software que baseia em um ciclo curto de repetições;● Não é um método para testar software, mas para construir software;● Vem do conceito de “test-first programming” do XP (Extreme Programming);
Objetivo
● “Clean Code That Works”;● Código limpo que funciona;
Benefícios● Maior produtividade;● Qualidade do código;● Compreensão do negócio;
Passos: Vermelho-verde-refatora
● Codifique o teste;● Faça ele compilar e executar (não deve passar – vermelho);● Implemente o requisito e faça o teste passar (verde);● Refatore o código;
User StoryO que é?
● Forma de especificação de requisito; Perguntas à serem respondidas
● Quem? Para quem estamos desenvolvendo a funcionalidade.● O que? Uma descrição resumida da funcionalidade em si.● Por que? O motivo pelo qual o cliente precisa desta funcionalidade. Se possível citando o valor de
negócio obtido.
Técnica para responder
SENDO
POSSO
PARA QUE
Visão do ProdutoO que é?
● Breve descrição, em auto nível, do produto a ser desenvolvido.● Não tem o objetivo de ser uma apresentação detalhada dos requisitos;● Pode ser melhorada ao longo do projeto, não sendo uma regra a sua apresentação apenas no início do
projeto;
Técnica: Declaração do Elevador (Elevator Statement)PARA [cliente-alvo]
QUE [indique a necessidade ou oportunidade]
O [Nome do projeto]
É UM(A) [categoria do produto]
QUE [indique o principal benefício; ou seja, a razão convincente que motiva a compra]
DIFERENTE [principal alternativa da concorrência]
NOSSO PRODUTO [indique a principal diferença]
PARA empresas médias de marketing e departamento de vendas
QUE necessitam de um sistema de CRM
O EeaseCRM
É UM software baseado na web, intuitivo e fácil de usar
QUE fornece a possibilidade de fazer a rastreabilidade de vendas, geração de leads e possibilita o estreitamento do relacionamento com o cliente.
DIFERENTE De outros serviços ou produtos,
NOSSO PRODUTO Oferece a melhor relação custo benefício.
Product Vision Box
Product Vision Box● O Product Vision Box é uma técnica que ajuda no entendimento da Visão do Produto, pois
quando fazemos uma representação visual do produto (embalagem, por exemplo) isto auxilia na redução do nível de abstração.
Informações Sobre o Produto
● Nome do produto;● Logotipo ou desenho que represente o produto;● Principais benefícios que ajuda a “vender” o produto;● Principais características e/ou funcionalidades do produto;● Principais requisitos técnicos;
Feito por… (1/3) Nome Email
Nelson Abu Samra Rahal Junior [email protected]
Thiago Torricelly [email protected]
Victor Eiras da Silva [email protected]
Douglas Chaves [email protected]
Carlos Freitas [email protected]
Douglas Dornel [email protected]
Paulo Lomanto [email protected]
Feito por… (2/3)Nome Email
Douglas Braga [email protected]
Vitor Martinez [email protected]
Anderson Agustinho [email protected]
Diego Poblete [email protected]
Rafael Capra [email protected]
Robertt Carvalho [email protected]
Cihangir Deniz Ozdemir [email protected]
Feito por… (3/3)Nome Email
Rodolfo Perenha [email protected]
Luiz Antonio Gimenez [email protected]
Silvio Neto [email protected]
Fabio Sanches [email protected]
