RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)... 3 Scrum Master (SM)... 3 Development Team... 3 Artifacts... 4 Product Backlog... 4 Sprint Backlog... 5 Sprint Burndown... 5 Release Burndown... 5 User Stories... 5 Events... 6 Visão geral dos eventos... 6 Sprint... 6 Sprint Planning Meeting... 7 Daily Scrum... 8 Sprint Review... 8 Sprint Retorspective... 8 Revisão... 9
Referências: 2 Referências: Todas informações detalhadas no documento foram retiradas das seguintes referências: /livros-e-referencias/scrum/ Os conteúdos que se encontram sublinhados, representam pontos importantes para a realização do exame. O Scrum É um framework para gerenciamento que segue os princípios do desenvolvimento ágil de software. Não se trata de um processo detalhado e prescritivo onde se conhece todas as variáveis, não sendo processos repetitivos e são imprevisíveis. É considerado um guia para planejamento, definição dos papéis e forma de trabalho; O Foco principal são as pessoas envolvidas e relacionamentos do que processo, e os usuários estão envolvidos durante todo o ciclo de desenvolvimento e não somente no início e fim; Mais utilizado para trabalhos complexos; Baseado em desenvolvimento iterativo e incremental, onde deve ser apenas detalhado o suficiente para iniciar a construção do software: o Iterativo: quando construímos um esboço, depois avaliamos e fazemos as alterações, ou seja, é desenvolvido e refinado constantemente; o Incremental: adiciona funcionalidades (features) ou partes a cada vez de uma maneira incremental. Processo que permite que os requisitos mudem ao longo do tempo; Visa remover ou diminuir restrições (problemas) de negócio, priorizando o que tem maior potencial de gerar valor para o negócio; Trabalha com times auto-organizaveis, onde o time de desenvolvimento planeja como fazer, qual o melhor momento para fazer, e quem vai fazer o que; Trabalha com times multifuncionais, onde cada pessoa pode atuar naquilo que é melhor, porém pode executar outros tipos de tarefas, tornando a equipe mais flexível e rápida; Possui ciclos menores de desenvolvimento permitindo o melhor gerenciamento de riscos, identificando com mais facilidade os problemas com no máximo 30 dias; Aprende-se progressivamente sobre o produto, ou seja, o conhecimento é adquirido com a experiência, onde tomamos decisões são baseadas em conhecimentos obtidos, trabalhando com três princípios básicos: adaptação, inspeção e transparência: o Adaptação: Realizar ações parar que não aconteçam desvios indesejados e desnecessários, caso seja notado algum desvio no planejamento. o Inspeção: Os usuários frequentemente devem inspecionar os artefatos e progresso do Scrum. Deve ser avaliado: Como está sendo feito e qual está sendo o resultado. Os eventos dentro do Scrum que trabalham com inspeção são: Sprint Planning Meeting; Daily Scrum; Sprint Review; Sprint Retrospective. o Transparência: Os aspectos significativos devem estar visíveis para os responsáveis pelos resultados; Realizar as estimativas de acordo com aquilo que você realmente acredita; Utilizar definições claras para todos os participantes, por exemplo, definir o que significa a palavra pronto.
Papéis 3 Visão de Pronto : o Significa que não há nenhum trabalho remanescente, e que é potencialmente utilizável; o Todos que veem o incremento devem ter o mesmo entendimento; Papéis Product Owner (PO) Ele representa o cliente e usuário ou qualquer parte interessara (steakeholders), comunicando a visão do produto e tendo conhecimento do negócio; É responsável pelo macro gerencia do projeto, não devendo ser o chefe do time; Deve ter conhecimento sobre Scrum e como a equipe trabalha; Assume um papel ativo tendo responsabilidades e atividades; Deve sempre estar disponível; Pode estabelecer restrições em relação ao prazo para uma liberação; É necessário apenas um Product Owner para cada Product Backlog e ele deve ser uma única pessoa, não um comitê de pessoas, porém, se outras pessoas desejam mudar o planejamento ou itens do Product Backlog, devem convencer o Product Owner; É responsável por responder para os interessados qual status do projeto; É a única pessoa responsável por gerenciar o Product Backlog, e isso inclui: o Define o que terá no Product Backlog, e em qual ordem será desenvolvido, definindo sua prioridade; o Responsável por aceitar ou reprovar, e dar feedback para as funcionalidades apresentadas; O que gostou? O que não gostou? O que espera que seja melhorado? Scrum Master (SM) Remove os impedimentos, sendo um facilitador do processo e evitando as interferências externas; Não é quem desenvolve; O Scrum Master é uma posição de gerenciamento, mas não de pessoas e sim de processos; Guardião das regras do Scrum, deve garantir que o Scrum seja entendido e aplicado para Scrum Team; Ele não é responsável por tomar decisões técnicas pela equipe quando esta não tiver tempo para fazer isto; Mentor para o Product Owner o ensina como fazer; Mediador entre o Product Owner e o Development Team; Ajuda a implantar o Scrum na empresa; Tem como objetivo, fazer com o que o Development Team trabalhe sem que ele precise agir; Development Team É quem realiza e define todas as atividades necessárias para entregar o software ao final do Sprint. É responsável por desenvolver, testar, criar e desenhar interfaces gráficas, ou seja, realiza tudo que é necessário para transformar os itens do Product Backlog em incremento de software funcionando e potencialmente utilizável, sabendo o que fazer, quando e qual a melhor forma. O time deve ser formado por generalistas não especialistas, ou seja, os membros devem ter habilidades para fazer outras tarefas e todos são responsáveis; Equipes multifuncionais (cross-fimctional). Todos são denominados como DESENVOLVEDORES;
Artifacts 4 O ideal para uma equipe de desenvolvimento é no máximo 9 desenvolvedores. Os papéis Product Owner e Scrum Master não são incluídos nesta conta, a menos que eles também executem trabalho no Sprint Backlog. Não tem autoridade para mudar a ordem em que os itens do Product Backlog que serão desenvolvidos; Não precisa de que o Scrum Master diga como transformar o Product Backlog em incrementos; Escalar o Scrum (Scrum of Scrum): o É utilizado quando temos que escalar o Scrum, criando assim, mais equipes Scrum; o É uma maneira de manter todos do time Scrum atualizados através da reunião chamada Reunião scrum of scrum, onde um representante de cada time de desenvolvimento participa (deve ser alguém do time de desenvolvimento). o Cada time, deve ter um Product Owner e um Scrum Master, mas cada um deles pode fazer parte de mais de um time. Artifacts Product Backlog Todos os itens que precisam ser desenvolvidos no software; Pode ser formado por: o Requisitos funcionais (user stories); o Requisitos não funcionais; o Correções; o Manuais, e outros. Cada item do Product Backlog pode ser representado por: o Estórias de usuários; o Caso de uso; o Descrições contextuais. Cada item deve ser priorizado e organizado com base em: o Valor estimado; o Dependências; o Necessidades; o Riscos, e outros. Para o Item do Product Backlog estimamos pontos de complexidade, e pode utilizar a técnica do Planning Poker para isso; Ele pode sofrer alterações ao longo do projeto; Cada item do Product Backlog deve ser escrito na linguagem do negócio e estar disponível para todas as partes interessadas; Os itens do Product Backlog que ainda não entraram em um Sprint Backlog, devem estar preparados para isto, caso isso não aconteça, o Scrum Master deve impedir que o Product Owner vá para Sprint Planning. Grooming é o termo utilizado para a preparação e refinamento do Product Backlog, e ele é realizado pelo Product Owner, porém, pode contar com o apoio de toda a equipe para realização desta tarefa. Ele pode ser realizado a qualquer momento, sempre que houver a necessidade identificada pela equipe scrum. É recomendado que o time de desenvolvimento reserve 10% do tempo para realização desta tarefa dentro do Sprint, e este tempo não deve ser contabilizado como horas de produtividade do desenvolvimento da sprint.
Artifacts 5 Sprint Backlog São os itens selecionados do Product backlog mais as tarefas necessárias para transformá-los em incremento e software pronto; É o artefato resultante da segunda parte da reunião de planejamento do sprint; Sprint Burndown Pode representar o gerenciamento das atividades da Sprint ou dos itens do Sprint Backlog, sendo representado por horas ou por pontos das atividades; Representa o status real da Sprint, mostrando a quantidade de trabalho restante ao longo do tempo da Sprint; O gráfico deve ter duas linhas: o Linha do Planejado ideal: soma-se todo o trabalho que foi levantado e precisa ser realizado para a Sprint, subtraindo a cada dia o valor que deve ser realizado por dia. o Linha do Restante: representa o trabalho realizado, representando quantas horas de valor agregado já foi entregue. Representa também o quanto de trabalho ainda falta para terminar. Representa a soma das estimativas das tarefas, dividido pela quantidade de dias uteis da Sprint; Release Burndown Planejamento das liberações do Software; Não significa que necessariamente ao final de cada Sprint, o software será liberado; É o Product Owner que define o plano de release, cria e mantém o plano de liberação; É uma visão do produto em relação a linha do tempo, estabelece uma data de entrega e custos prováveis. Os custos são calculados em cima de quantas Sprints farão parte da liberação; É um evento time-box porém é opcional, pode ser estimado conforme a velocidade do time e a estimativa de complexidade; Deve-se atualizar o plano de releases quando novos itens são incluídos ou modificados no Product Backlog; O gráfico Burndown da Release representa as atividades das Sprints restantes, a soma dos pontos de cada item do Product Backlog pelos Sprints definidos no Release; Para saber uma média de quantos Sprints serão necessário, some os pontos de todos os itens do Product Backlog e divida pela velocidade média do Development Team, o resultado é a quantidade de Sprints restantes para serem desenvolvidos; Velocidade do time representa quantos pontos um time consegue entregar em cada Sprint (velocidade de medida de produtividade de cada sprint). User Stories Forma de documentar requisitos e funcionalidades no Backlog do Produto; Só deve fornecer detalhes suficientes para se chegar no entendimento necessário; Não deve ser descrito os detalhes técnicos; É um lembrete das principais características de cada funcionalidade; Pode-se ter a necessidade de quebrar a estória do usuário em outras, caso seja grande de mais; Devem ser escritas na voz ativa, ex: Um candidato pode enviar um currículo.
Events 6 Events Utiliza o conceito de eventos time-boxed, aonde cada evento tem uma duração máxima e imutável, sendo definido um tempo limite. São eventos time-boxed: o Sprint Planning; o Sprint (podendo ser finalizado antes do tempo planejado); o Daily Scrum; o Sprint Review; o Sprint Retrospective. Cada evento no Scrum é uma forma de inspecionar e adaptar algo. Visão geral dos eventos Sprint Planning (Parte 1): O que desenvolver Sprint Planning (Parte 2): Como desenvolver Daily Scrum: Progresso / Andamento Sprint Review: Apresentar o Resultado Sprint Retrospective: Melhorar o Resultado Sprint É o coração do scrum, é o principal evento; É considerado um evento time-box onde é determinado um prazo para se realizar algo; O time-box pode ser de 2 á 4 semanas, ou seja um mês ou menos; Nela é desenvolvido todo o trabalho para transformar os itens do Backlog do Produto em funcionalidades do software; As Sprints são compostos por: o 1º. Sprint planning meeting; o 2º. Daily Scrum; o 3º. Sprint review; o 4º. Sprint retrospective. Todos os eventos fazem parte da sprint; Deve-se seguir as regras durante o sprint: o Nenhuma mudança é feita que possa afetar a meta do sprint; o As metas de qualidade não diminuem; o O escopo pode ser renegociado entre o Product Owner e o Development Team. Cancelamento do Sprint: o Sprints podem ser cancelados antes do time-box do sprint finalizar e somente o Product Owner tem autoridade para realizar esta ação; o Um Sprint pode ser cancelado se a meta dele se tornar absoleta; o Quando um sprint é cancelado, todos os itens do Product Backlog que foram concluídos são revisados, e todos os itens que não foram completados são re-estimados e colocados no Product Backlog. o Os Sprints cancelados consomem recursos e devem ser reagrupados em outros Sprint Planning Meeting para serem iniciados em outro Sprint; O Product Owner não deve realizar mudanças do itens dentro da sprint, caso isso seja necessário ele deve esperar a próxima sprint, isso poderia levar a uma baixa produtividade do time e um produto com má qualidade;
Events 7 O Developmento Team é o dono da Sprint Backlog, e somente eles podem adicionar ou remover tarefas deste Backlog; Qualquer membro do Developmento Team pode adicionar ou remover tarefas sempre que for necessário, a qualquer momento; Sprint Planning Meeting É uma reunião onde é planejado o próximo sprint, onde toda Scrum Team deve participar. As principais atividades realizadas são: o Revisão do backlog do produto; o Acordar a próxima sprint; o Definir o objetivo da sprint; o Definir e estimar o Sprint Backlog. Sprint Planning Meeting é um evento time-boxed e seu tempo de duração é determinado pelo tempo que o escopo do Sprint irá levar: o Para Sprints de 4 semanas, a Sprint Planning Meeting deve levar 8 horas; o Para Sprints de 3 semanas, a Sprint Planning Meeting deve levar 6 horas; o Para Sprints de 2 semanas, a Sprint Planning Meeting deve levar 4 horas. Além do tempo de duração, ela é dividida em duas etapas: o Se a Sprint Planning Meeting levar 8 horas, a reunião deverá ser dividida em duas etapas de 4 horas cada; o Se a Sprint Planning Meeting levar 6 horas, a reunião deverá ser dividida em duas etapas de 3 horas cada; o Se a Sprint Planning Meeting levar 4 horas, a reunião deverá ser dividida em duas etapas de 2 horas cada; Para 1ª etapa, é necessário determinar o que será entregue no próximo sprint; o O Product Owner deve ir preparado para a reunião com todo Product Backlog organizado e priorizado, e ele deve explicar os itens mais importantes para o Development Team; o O objetivo está no que se deve fazer, não como fazer (o que será entregue como resultado); o É realizada uma avaliação dos itens do Product Backlog, podendo também o Development Team ajudar o Product Owner a refinar ainda mais o Product Backlog, melhorando as descrições e quebrando em itens menores, ou ajudando ele a repriorizar os itens do Product Backlog; o É definido uma meta da Sprint (baseado na vivencia e esforço estimado); o O Product Owner deve explicar o suficiente para o entendimento da sprint atual, não tendo necessidade de explicar item a item do Backlog da Sprint; o Ainda que haja negociação com o Product Owner, somente o Development Team pode dizer e se comprometer com a quantidade de itens que é capaz de entregar na Sprint; o Os itens selecionados pelo Development Team do Product Backlog são chamados de (Selected Product Backlog), e é por eles que se define a meta do Sprint (Sprint Goal); o Deve ter a presença de todo Scrum Team; Para 2ª etapa, o Como o trabalho será feito para atingir as metas da sprint? o Onde é criado e dividido as tarefas do Sprint, atribuindo as horas de estimativa para cada uma delas; o A presença do Product Owner é opcional; o Identificar as tarefas que precisam ser feitas para transformar os itens do backlog em um incremento de software funcionando e potencialmente utilizavel pelos usuários;
Events 8 o o São discutidos todos os tipos de atividades que podem ser necessários: Análise, construção, testes, desenho de interface, criação de banco de dados, entre outras. É uma decomposição dos itens do backlog em tarefas menores; Se o Development Team identificar que haverá um excesso de trabalho depois de determinar todas as tarefas e estima-las, pode-se negociar com o Product Owner; Product Owner é o dono do Product Backlog enquanto o Team é dono do Sprint Backlog. Daily Scrum Deve ter duração máxima de 15 minutos, e é ideal para que o Development Team sincronize e inspecione as atividades; Somente o Development Team e o Scrum Master devem participar desta reunião; É uma forma de inspecionar o trabalho desde a última Daily Scrum, e deve ser realizada todos os dias no mesmo horário e no mesmo lugar; Durante a reunião, cada membro do Development Team explica de forma objetiva, transparente e rápida: o O que fez desde ontem? o O que vai fazer hoje? o Há Impedimentos? Quais são? O Development Team deve avaliar se a meta do Sprint será cumprida. Case esteja claro que isso não irá acontecer, imediatamente deve-se conversar com o Scrum Master e se necessário, envolver o Product Owner, buscando a melhor alternativa para a situação; Os membros dos times devem falar para os membros dos times, e não para o Scrum Master; Deve ser realizada com todos ao mesmo tempo; Antes de irem para reunião, os membros do time devem atualizar os status de suas atividades; O Scrum Master só entra em ação quando solicitado ou se houver a necessidade de remover algum impedimento, sendo assim, não é obrigatória a parecença delo, porém, ele deve garantir que a reunião aconteça; Sprint Review Onde é demonstrado o uma demo do software, onde o foco e o produto; Onde é analisado se é aceitável ou não o que foi desenvolvido para o Product Owner, obtendo seu feedback no final de cada Sprint; O Development Team não deve mostrar os itens que não estão prontos ou potencialmente utilizáveis; Todo o trabalho que não foi acabado na Sprint, deve voltar para o Product Backlog, e deve ser dado outra prioridade para estes itens novamente pelo Product Owner; Esta reunião pode ter a participação do Development Team (todos do time de desenvolvimento), o Product Owner, e quem mais o Product Owner convidar; O time de desenvolvimento é quem conduz a apresentação do software ao Product Owner; As sugestões de alterações ou novas features devem ser incluídas no Product Backlog para futura priorização; Também é um evento Time-Boxed de 4 horas realizado ao final da Sprint para um Sprint de 30 dias. Sprint Retorspective Onde é levantado: o O que deu certo? o O que precisamos melhorar?
Revisão 9 o Como implementar as ações para melhorar? Tem foco no processo e não no produto e é fundamental para se obter uma melhora na equipe; É um evento time-boxed de 3 horas para um Sprint de 30 dias; Devem estar presentes o Development Team e Scrum Master. A presença do Product Owner é opcional. O Scrum Master neste momento é fundamental para encorajar a equipe para falar sobre coisas boas e ruins que aconteceram durante a Sprint; Cada membro do time deve falar sobre o que achou que foi bem e o que deve ser melhorada, e o Scrum Master é o responsável por anotar os itens de melhoria. Quando estes itens estiverem anotados, o próprio Development Team prioriza estes itens para os mais importantes e discutem um plano para novos resultados. Revisão Quem determina se foi atribuído trabalho suficiente para o Development Team é ele mesmo; O Development Team deve entregar ao final de cada Sprint um incremento de produto 'pronto' e potencialmente utilizável para o cliente; O Scprint Burndown Chart ilustra o trabalho restante em horas durante uma Sprint; O Development Team é o responsável por atualizar a estimativa de trabalho durante o Sprint; O Scrum Master não precisa estar presente na reunião diária, mas ele deve garantir que o Development Team a faça; Para garantir que o Development Team continue trabalhando no seu maior nível de produtividade, o Scrum Master deve ser um facilitador, removendo os impedimentos; Não é importante que um incremento do produto seja lançado para produção no final de cada Sprint; Um Sprint finaliza quando o seu tempo time-boxed expira; Todas as Development Teams devem ter uma mesma definição de pronto; Uma finalização anormal do Sprint acontece quando o Product Owner determina que não faz mais sentido para termina-lo; Se for necessário rever a quantidades de itens do Sprint Backlog caso o Development Team note que não irá dar conta de finalizar todos os itens, deve ser realizada uma revisão e adaptação do trabalho selecionado e nesta reunião devem estar presentes o Product Owner e o Development Team; A melhor descrição para a Sprint Review é quando o Scrum Team e Stakeholders inspecionam o resultado da Sprint, e descobrem o que deve ser realizado no próximo; Scrum Team é composto por: Scrum Master, Product Owner e Development Team; Se o Scrum Master tiver uma lista de impedimentos grande de mais que não esteja conseguindo dar conta, ele deve consultar o Development Team, priorizar os itens da lista ou alertar a gestão sobre os impedimentos e seu impacto; No Scrum não há uma função chamada Project Management; Scrum é um processo empírico; O tamanho do Development Team pode variar de 6 + 3 ou -3