Scrum - Complementando!

PRODUCT BACKLOG (complementar)

Lista de necessidades que devem ser produzidas para o sistema. “Lista de requisitos ou atividades”.

Deve existir apenas um Product Backlog refletindo todas as necessidades do cliente e deve ser mantido pelo PO refletindo todas as mudanças do negócio (estratégias, tecnologias, novas ideias, etc).

O PO (Cliente) deve priorizar conforme suas necessidades.

Estória – pequena, fácil de concluir, é fácil prever o esforço, tem poucas dúvidas, desta forma possuo poucas incertezas facilitando o cumprimento dos objetivos do sprint. Recomenda-se ter no máximo 7 critérios de aceite por estória. Se for mais de 7 recomenda-se criar 2 estórias. É um exemplo de Caso de Uso, porém mais simples.

Exemplo: Uma tela pode se tornar várias estórias. Um gráfico dentro de um dashboard pode ser uma estória.

As demandas devem ser objetivas. Ex.: O meu site tem que ser rápido. Cada um tem um conceito de rápido por isto precisa ser medido. Ex.: Cada operação de venda por cartão de crédito deve levar no máximo 2 segundos.

Épico – estória grande, é muito complexa, existem dúvidas (vai na parte de baixo do iceberg), difícil estimar o esforço,

Ex.: Um dashboard com diversos gráficos. Um único gráfico do dashboard pode ser uma estória.

Definition of Read – as caracteristicas que uma estória necessita para que possa entrar no Sprint backlog. Deve estar bem escritas, com critérios de aceite claros e testáveis e a equipe se sente segura em realizá-la.

Backlog Grooming – Forma para manter o backlog atualizado e torna as reuniões mais produtivas.

Atividades: criar e refinar itens, estimar itens e priorizar itens do Product Backlog.

Participantes: Product Owner (lidera o grooming), Stakeholders (se necessário), Scrum Master, Time Scrum

Atividades / Fases:

Planning – Planejamento do sprint. Alinhamento com o time de negócio para definição de todas as atividades a serem desenvolvidas dentro do Sprint (é essencial a participação do PO).

Daily Meeting – Reuniões de acompanhamento diário

Review – Como se fosse uma homologação e o cliente da um feedback que deve ser usado para melhoria dos próximos sprints. É extremamente importante a participação das partes interessadas.

Retrospectiva – o time inspeciona e melhora o trabalho realizado.

Planning

O time escolhe as estórias de que é capaz de realizar dentro do sprint conforme prioridades estabelecidas pelo PO no Product backlog.

O time analisa a forma de entregar as estórias (Como)

Tira dúvidas com o PO sobre estórias.

Cria o Sprint backlog (itens a serem desenvolvidos) que será realizado dentro do Sprint (período utilizado).

Eventuais ausências de membros do time são apontadas

O time quebra as estórias em tarefas e são definidas em pontos (horas).

Estórias são dividas em pontos e tarefas em horas

Daily Meeting

Acontece diariamente para obter informações das evoluções em relação a ultima reunião, expor o planejamento até a próxima reunião e para expor os impedimentos.

Duração de 15 minutos

De pé – tem como objetivo ficar em pé para se cumprir os 15 minutos

Tem como objetivo expor problemas ou impedimentos

Se o problema tomar muito tempo para ser discutido, marca-se outra reunião.

Discussões que surgirem que não podem ser resolvidos de imediao e de forma rápida, deve-se agendar uma reunião somente com os envolvidos no problema fora do Daily Meeting.

Impedimentos que surgem são resolvidos pelo Scrum Master. A equipe foca no desenvolvimento do trabalho.

Review

É uma atividade de inspeção e adaptação focada no produto

Acontece após a execução do sprint e antes da Sprint Retrospective

Nessa cerimônia apresentada o que foi desenvolvido no Sprint. São apresentadas somente estórias que atingiram o Definition of Done (finalizados / pronto conforme conceito)

O Time Scrum colhe o feedback do que foi produzido

Retrospectiva

Processo de inspeção e adaptação focada no processo. Acontece no final do Sprint.

O Time Scrum examina o processo utilizado para o construir o produto visando melhora dos próximos Sprints. O Time avalia o que deu certo e o que deu errado e toma as ações necessárias para melhor os erros ocorridos e desta forma se tornar mais produtivo.

A participação do PO é opcional (depende do clima), porém se participa é valido.

Cria-se em um quadro branco duas lista. “O que foi bom ? “ e “O que deve melhorar ?”.

Caracaterísticas:

Facil de Planejar

Rápido feedback

Limita o erro

Melhora o retorno do investimento

Rejuvenesce o entusiasmos

Checkpoints frequentes (ou Milestones)

Velocity

Capacidade de entrega do time dentro do Sprint

Definition of Ready

Estórias prontas para sair do Product Backlog e entrar no Sprint

Definition of Done

Quando o conceito de pronto esta aplicado.

Fim da série de artigos de autoria de Everton Amorim, PMP e edição de Renato Mendes, seguidores e agora colaborados do blog.

Ver Post ►

O ciclo de vida Scrum

Fala a verdade, tá acostumado com ele né? Claro, é o modelo utilizado na grande maioria dos projetos hoje em dia. 

Ao invés de etapas e atividades definidas no início do projeto, o ciclo de vida de um projeto Scrum é composto por iterações de software funcionando. O ciclo de vida é representado pela figura abaixo:

Ciclo de vída Scrum

Quando mais tempo eu demoro para entrega mais tempo eu levo para obter um feedback, portanto quando menor o tempo do sprint mais rápido eu obtenho um feedback. Recomenda-se 2 semanas.

Sprint (15 dias – 10 dias úteis)

Planning – 1 dia

Desenvolvimento – 8 dias

Review – ½ dia

Retrospective – ½ dia

·        Estabelece um limite ao WIP (Work in Progress) – uma vez definido o tempo de um sprint, todos os sprints devem ter o mesmo tempo. Deve ser feito desta forma para medir a capacidade produtiva.

·        Força a priorização – o PO deve priorizar o que ele quer receber como produto de trabalho para cada Sprint.

·        Evitar perfeccionismo desnecessário – O ótimo é inimigo do bom

·        Motiva o encerramento das tarefas – As entregas devem ser feitas dentro do sprint

·        Melhora a previsibilidade – como o tempo do sprint é pouco (geralmente 15 dias), é mais possível prever os términos conforme evolução dos sprints.

·        Transparência – entre os membros do time

·        Inspeção – avalio o que foi feito para adaptar

·        Adaptação – adaptar para evitar cometer os erros cometidos anteriormente

Os Artefatos:

Bom, o Scrum não oferece listas de templates ou modelos de documentos para que você possa sair usando. No entanto existem alguns artefatos que fazem parte do dia-a-dia, vamos falar dos principais:

·         Product Backlog é a lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato "vivo", pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories. Utilizando essa abordagem você verá muitos resultados interessantes em seu processo de engenharia. Mas, como já dissemos o Scrum não é um processo de engenharia então você pode utilizar o que quiser pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.

·         Impediment List é a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.

·         Sprint Backlog possui as atividades nas quais o Time vai atuar dentro de uma Sprint.

Timebox que será executado para executar parte do Product Backlog.

É como se fosse uma corrida. Hora que chegou na linha de chegada, acabou.

É um Ciclo PDCA – Planeja o que será feito, Executa, Verifica e toma uma ação para que o próximo sprint seja melhor. Melhoria continua, ou seja, os sprints devem evoluir conforme andamento.

Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.

Exemplo de Kanban

Product e Sprint Burndown são gráficos que mostram a tendência planejada para atendimento da Sprint / Product Backlog e como o time está evoluindo diariamente no caso da Sprint e a cada Sprint no caso do projeto.

Cerimônias:

Existem também algumas cerimônias no Scrum, que marcam cada etapa no ciclo de vida. As principais:

·         Sprint Planning Meeting é a reunião de planejamento da Sprint. Nela o Time discutirá com o P.O sobre a meta a ser alcançada naquela Sprint e fará o planejamento de todo o trabalho que será realizado dentro da Sprint.

·         Daily Meeting é a reunião diária que ocorre com todos os membros do Time, S.M e P.O. Preferencialmente deve ter 15 minutos e os integrantes do Time respondem a perguntas como:

·         O que fiz desde a última reunião diária;

·         O que planejo fazer até a próxima;

·         O que está me impedindo?

·         Sprint Review é a reunião de prestação de contas na finalização da Sprint. Nela todos os membros do Time apresentarão o resultado atingido na Sprint ao P.O e outros envolvidos.

·         Sprint Retrospective é a reunião de "lições aprendidas" que ocorre ao final de cada Sprint. Nela os membros do time respondem a perguntas como:

·         O que fizemos de bom e temos que continuar fazendo?

·         O que temos que mudar ou começar a fazer?

·         Quem está no controle?

O que temos que levar em conta é que Scrum ou práticas ágeis em geral não se resumem apenas na utilização de Kanbans ou na realização de reuniões diárias. O mais importante não está em evidência e tem a ver com mudança cultural. É imprescindível que se tenha o foco sempre na mudança cultural e não somente nas práticas. É preciso olhar para os itens do manifesto, entendê-los e praticá-los para conseguir resultados com o processo.

O mais importante é a cultura!

Continua....

Artigo de autoria de Everton Amorim, PMP e edição de Renato Mendes,  seguidores e agora colaborados do blog.

Ver Post ►

Os papéis no Scrum

Product Owner (P.O) é o dono do produto. Ele possui a visão do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog, planejar releases, priorizar requisitos e passar ao time uma visão clara sobre os objetivos do projeto. É muito indicado então que o P.O seja alguém do lado do cliente.

O P.O. (Cliente) deve estar diretamente envolvido senão não funciona.

Responsabilidades:

Definir a visão do produto (product vision).

Gerenciar o retorno do investimento (ROI).

Apresentar ao time os requisitos necessários para a entrega do produto.

Priorizar cada requisito de acordo com o seu valor para o negócio/cliente.

P.O.: Forma um time generalista.: Ex. Tenho um especialista em testes, porém formo outras pessoas com conhecimento de teste para não deixar o conhecimento centralizado e em caso de ausência deste especialista, tenho pelo menos um profissional para dar andamento em suas atividades ou auxiliar este especialistas no dia-a-dia executando atividades mais simples.

ScrumMaster (S.M) exerce um papel de liderança no processo, mas ele não é um gerente de projetos. O papel de S.M não possui autoridade alguma perante o P.O ou o Time. O SCRUM Master não pode fazer parte do time porque ele deve ser única e exclusivamente facilitador dos times. O SCRUM foca na produtividade e se o SCRUM Master fizer parte do time as atividades de “facilitador” dele pode fazer com que sua produtividade seja afetada pois em algum momento ele poderá deixar de exercer atividades de membro de time para exercer atividades de facilitador.

A responsabilidade do Scrum Master é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e P.O.

Responsabilidades do Scrum Master:

Garantir que os times SCRUM pratiquem os valores e práticas do SCRUM.

Garantir que o time não assuma mais coisas que não possam garantir

Facilita o Daily Scrum – Facilita a participação e transparência entre os membros.

Remove os impedimentos levantados pelo time – equipe “escala” o problema e o Scrum Master resolve o problema

Características Scrum Master:  Responsável; Humilde; Colaborativo; comprometido; Acessível.

·         O Time é o conjunto de pessoas que implementará o projeto. É composto por uma equipe multidisciplinar que tem a característica da auto-gestão. A responsabilidade do Time é manter a auto-gestão de suas atividades, planejar as Sprints, assumir metas com o P.O e dar feedback sobre os impedimentos para o S.M.

Características Time Scrum: Auto-organizado; Multidisciplinar;           Composto por no máximo 9 integrantes; Comprometido com o trabalho

Então vejamos:

·         O Product Owner gerencia: Escopo, prazo (datas de entregas) e acompanha o ROI (medição e análise);

·         O ScrumMaster gerencia: Processo, risco (impedimentos) e planejamento (atingir metas);

·         Os Membros do Time gerenciam: Configuração, riscos, requisitos e planejamento.

Neste momento, o leitor deve estar eufórico se perguntando: Onde está o Gerente de Projetos? Pois é, lamento dizer que este papel não existe no Scrum. Pelo menos, não como definido pelo mercado hoje, certo?

O gerenciamento é dividido entre os membros do Time, ScrumMaster e Product Owner. Este é um ponto muito forte e é requisito para buscar a agilidade: O auto-gerenciamento.

Ao contrário das chamadas metodologias tradicionais, que seguem um modelo definido de desenvolvimento de software baseado em fases e atividades, o Scrum é um processo empírico, ou seja, você não me diz como eu devo fazer, mas somente o que quer como resultado. Depois disso, nós aprendemos durante o processo e evoluímos com este aprendizado, buscando juntos o objetivo a ser alcançado.

Um processo padrão orientado por fases e atividades pode ser parecido com o modelo abaixo:

Modelo Tradicional de desenvolvimento baseado em cascata

Fala a verdade, tá acostumado com ele né? Claro, é o modelo utilizado na grande maioria dos projetos hoje em dia. 

Continua....

Artigo de autoria de Everton Amorim, PMP e edição de Renato Mendes,  seguidores e agora colaborados do blog.

Ver Post ►

Quer saber o que é Metodologia Ágil?

Continuamos a discorrer sobre SCRUM.

SOBRE A METODOLOGIA ÁGIL

Escopo é aberto, pois tem a oportunidade de mudanças.

Muitas vezes o cliente não sabe o que pedir, por isso ele vai desenvolver suas expectativas conforme o andamento do projeto.

SCRUM prega para documentar o que traz valor.

Não se faz horas extras, somente em casos exporádicos. Ex.: Tenho uma entrega crítica e tenho que trabalhar o sábado para entregar – neste caso ok, porém segundo SCRUM isto não pode virar rotina.

Segundo SCRUM se virar rotina o trabalho extra, a sua capacidade de trabalho aumenta, por isso suas estimativas dos próximos SPRINTS podem ser afetadas em detrimento  a isto.

Acredita-se também que o esforço extra dedicado, gera desgastes que influenciam no resultado da equipe.

O SPRINT não pode ser considerado como uma força-tarefa.

Como as entregas são rápidas, qualquer erro aparece rápido também.

SCRUM não vai resolver todos os problemas, porém ajuda a identificar vários problemas no processo.

Metodologia visa reduzir riscos, identificando erros. A metodologia ágil visa a transparência, ou seja, não esconder erros. O time deve expor suas deficiências.

Formar ambiente para as pessoas se auto gerenciarem com as pessoas se ajudando e colaborando.

Não possui cronograma.

Os indivíduos e interação entre eles são mais importantes que processos e ferramentas (prega interação entre pessoas mas não pode ignorar processos e ferramentas).

Colaboração com o cliente mais que negociação de contratos (deve haver uma relação de confiança e quebrar burocracias em relação a mudanças e processos para alteração de contratos)

Responder a mudanças mais que seguir um plano (mesmo que haja um plano traçado, a mudança que surgiu deve ser priorizada)

 BENEFÍCIOS SCRUM

Clientes mais satisfeitos – cliente recebe exatamente o que quer porque acompanha constantemente as entregas realizadas

Redução de custos – menor documentação, menos riscos no projeto por ter identificado antecipadamente possíveis problemas

Melhor retorno sobre o investimento – cliente obtém retorno a curto prazo porque entregas são realizadas constantemente e não somente no final do projeto. Desta forma, ele se aproveita dos retornos destas entregas.

Mais diversão – Colaboração entre as pessoas, trabalho em equipe, não faz horas extras, clientes é envolvido no processo e outros.

Confiança para ter sucesso em um mundo complexo – deve haver relação de confiança entre fornecedor e client

Resultados rápidos – cliente aproveita dos retornos do projeto antes do ciclo tradicional. Com a evolução dos sprints, o processo melhora.

Continua....

Artigo de autoria de Everton Amorim, PMP e edição de Renato Mendes,  seguidores e agora colaborados do blog.

Ver Post ►

Quer saber o que é Scrum?

Scrum é um framework para gerenciamento de projetos de software. Note que Scrum pode ser utilizado por outras áreas e não somente em desenvolvimento de software, mas daremos maior foco para sua utilização na área de TI. Falamos framework porque Scrum por si só não é um paradigma de gerenciamento. Ele é baseado num modelo chamado de Modelo Ágil de desenvolvimento de software. Quando falamos de agilidade estamos falando de vários outros pontos que se somam ao Scrum, como: Extreme Programing (XP) , por exemplo.

O nome Scrum vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida.

Jogada Scrum do Rugby

Percebeu onde já entra a primeira grande questão num modelo ágil? O trabalho em equipe é o ponto principal e talvez o mais importante. É crucial que se tenha um olhar de time para entender o que é ser ágil e praticar no dia-a-dia. O processo Scrum foi estabelecido por Ken Schwaber e Jeff Sutherland e está baseado no manifesto ágil, que defende os seguintes pontos:

·         Pessoas e suas interações mais importantes do que processos e ferramentas;

·         Software funcionando mais importante do que documentação abrangente;

·         Colaborar com o cliente mais importante do que negociar contratos;

·         Responder ás mudanças mais importante do que seguir um plano.

A idéia não é de que os itens do lado direito não sejam importantes, mas se eu tiver que escolher entre um deles vou sempre priorizar os do lado esquerdo.

Algumas pessoas de fora, que estão acostumadas a trabalhar em processos tradicionais, muitas vezes apresentam uma visão equivocada a respeito de Scrum. Abaixo temos algumas lendas que você poderá ouvir por aí:

·         É um processo que não possui documentação nenhuma;

·         Os "caras" gerenciam projetos com um monte de post-its;

·         Jogam baralho durante o trabalho;

·         É um processo que não possui gerente de projetos, logo, foi uma metodologia criada por programadores que tinham problemas com autoridade;

·         Não possui cronograma. COMO GERENCIAR SEM MSPROJECT ?

·         Precisa de um time muito especialista pra funcionar direito;

·         Não dá para estimar e metrificar, logo é impossível de vender;

·         Meu cliente nunca irá aceitar esse negócio de ?escopo variável?;

·         É feito para atender projetos pequenos e não complexos;

Importante saber que essas "afirmações" acima não passam mesmo de lendas. É preciso somente um pouco mais de conhecimento sobre Scrum ou Agilidade para ver que elas não tem fundamento algum.

Acima de tudo o Scrum é uma maneira de evidenciar problemas que acontecem no desenvolvimento de projetos de software. Ele não vai resolver seus problemas de engenharia ou de qualidade no projeto, mas vai oferecer mecanismos para que a equipe vá atrás de soluções para esses problemas.

Para a metodologia SCRUM é extremamente importante que todas as pessoas possam se expressar e ser ouvidas com suas opiniões e seus pontos de vistas. Cada membro possui um ponto de vista diferente do outro.

Scrum visa trabalho em equipe (time multi disciplinar), ou seja, pessoas com diversos papéis no mesmo time. O crédito é da equipe e não de membros específicos.

A ideia é buscar times com no máximo 9 pessoas para conseguir mais produtividade. Se o projeto tem 30 pessoas, divida em 3 ou 4 times.

60% dos custos de um projeto podem ser atribuídos à rotatividade de pessoal.

O SCRUM deve ser acompanhado de um trabalho de gestão de pessoas.

Método mais eficaz de comunicação do ser humano é olho no olho.

O profissional deve ajudar as outras pessoas e ser ajudado indiferente do grau de qualificação dele.

Continua....

Artigo de autoria de Everton Amorim, PMP e edição de Renato Mendes,  seguidores e agora colaborados do blog.

Ver Post ►