The post Cuidado com o Ciclo da Morte do Produto appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

1- A reunião é longa e dura muito mais do que o planejado.

Afinal, não é qualquer um que consegue se manter 100% focado em uma reunião muito longa. Quando os participantes perdem o foco (ou interesse) no que está sendo apresentado, a revisão perde seu propósito.

2- A equipe sai desmotivada da reunião.

Existem ocasiões em que o P.O. sente a necessidade de dar uma “sacudida” na equipe. Tem-se o caso em que estas são tão frequentes ou intensas, que fazem um sentimento de desânimo, ou desmotivação prevalecer na equipe. Aqui deve-se tomar o cuidado de dirigir as críticas aos problemas e não às pessoas diretamente.

3- As discussões da reunião de revisão não são produtivas.

É extremamente fácil fazer com que uma reunião perca o rumo com discussões improdutivas. Para alguns, a tentação as vezes é muito grande quando uma certa história está sendo apresentada, deste “aproveitar o momento” para abordar uma questão sobre alguma regra de negócio polêmica. O Scrum Master deve lembrar a todos que o objetivo da revisão é a inspeção do que foi feito e não questionamentos de requisitos.

4- A equipe sai da reunião sem entender o porquê das histórias reprovadas terem tido este destino.

O P.O. deve conseguir passar para a equipe o motivo pelo qual uma história foi reprovada e a equipe deve se preocupar em saber o que será necessário para corrigi-la. Sem este entendimento, as correções necessárias não serão possíveis, e corre-se o risco de que esta seja reprovada novamente.

5- Atribuições individuais de culpa.

Uma história reprovada não é culpa de um indivíduo específico, mas é uma derrota da equipe como um todo. O objetivo da reunião de revisão não é apontar quem é o culpado de quê. Este tipo de discussão deve acontecer na reunião de retrospectiva, caso pertinente.

6- As pessoas não estão a par do que está acontecendo na sprint.

Se algum membro da equipe chega na reunião de revisão de sprint sem saber que uma história não foi finalizada, o porquê de uma decisão ter sido tomada, ou outros eventos significativos que ocorreram, esta pessoa não conseguirá participar ativamente do que está sendo apresentado, não fará questionamentos pertinentes e logo, não se beneficiará das discussões.

The post 6 sinais de que a sua reunião de revisão é ineficiente appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

É importante frisar que estes posts tratarão de idéias e dicas e não como a implementação é feita integralmente.

Uma breve introdução sobre o MR-MPS-SW

O MR-MPS-SW, ou Modelo de Referência do Software Brasileiro, é um programa mantido pela SOFTEX que tem por objetivo arquitetar uma indústria brasileira de software competitiva nos cenários nacional e internacional. Isto é, utilizar as práticas de Engenharia de Software para aperfeiçoar seus processos organizacionais no intuito de desenvolver produtos com padrões de qualidade aceitos internacionalmente.

O modelo de referência define níveis de maturidade para as organizações que vão do G ao A e estão descritos nos Guias de Implementação, que podem ser encontrados no site da SOFTEX. Cada nível possui processos específicos a serem implementados, sendo estes descritos por meio de resultados esperados.

Nível G

No nível G, Parcialmente Gerenciado, são dados os primeiros passos no sentido da mudança da cultura organizacional no que se refere ao aperfeiçoamento dos seus processos. Neste nível é dada importância na definição de alguns padrões dos projetos da organização.

O nível G trata dos processos de Gerência de Projetos e Gerência de Requisitos, que serão tratados a seguir e no próximo post, colocando-os frente a frente com o SCRUM.

Gerência de Projetos

Resultados Esperados do nível G:

GPR 1. O escopo do trabalho para o projeto é definido.

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

O GPR 1 trata de definir o que há de ser feito no projeto, suas restrições e limites, já o GPR 2 trata da complexidade do que há de ser feito. Trazendo estes para o mundo SCRUM, podemos implementá-los através do Product Backlog. Se no início do projeto forem inseridas as histórias a serem realizadas, mesmo que sejam macro-histórias, há uma definição de escopo, e ao realizar estimativas, utilizando, por exemplo, o planning poker, a complexidade individual destas está sendo definida.

GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos.

Aqui está sendo definido, de fato, que será utilizado o SCRUM com suas cerimonias etc.

GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

Mantendo-se registros dos Product Backlogs e Sprint Backlogs antigos é possível estimar com algum nível de precisão o HH necessário para a realização do novo projeto. É uma boa prática guardar informações de contexto sobre estes, por exemplo: datas de início e fim, quantos desenvolvedores seniors, juniors participaram, quais suas cargas horárias, horas extras, quantos pontos foram planejados, aceitos e reprovados. Isto ajuda o seu especialista analisar o que ocorreu para evitar que possíveis problemas venham a acontecer.

Este foi o primeiro post da série da união do MPS.BR com o SCRUM. No próximo post darei seguimento ao processo de Gerência de Projetos – GPR.

The post Implementando o MPS.BR com SCRUM – Nível G (Parte 1 – Gerência de Projetos) appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Segundo De Bono, as pessoas tendem a abordar estas situações sempre da mesma maneira, por exemplo, indivíduos mais emotivos são guiados mais pelo instinto, enquanto que os lógicos costumam utilizar mais a lógica e se ater mais aos fatos. A idéia dos Six Thinking Hats é abordar o alvo da decisão sob diversas perspectivas, e isto é feito utilizando a metáfora dos chapéus.

• O chapéu azul é vestido pelo Scrum Master ou por algum outro facilitador da reunião. Esta pessoa irá dirigir a ordem dos outros chapéus.
• Colocando-se o chapéu branco, a equipe se atém a expor todos os dados disponíveis sobre o problema/decisão. Aqui, toda informação é reunida e explicada para todos.  
• O chapéu vermelho leva a considerar o problema/decisão utilizando-se a intuição. Aqui os indivíduos são levados a utilizar seus instintos.
• Quando se coloca o chapéu preto é hora de ser pessimista. É hora de levantar tudo o que pode dar errado e pontos fracos.
• Quando se coloca o chapéu amarelo é hora de ser otimista, levantando-se os pontos positivos e benefícios da decisão.
• Por último, temos o chapéu verde. Nele é hora de ser criativo e explorar diversas soluções. A ideia é fazer um mini brainstorming sem ser crítico.

A ordem dos chapéus é muito importante e deve ser considerada com cuidado pelo Scrum Master que deverá levar em consideração o conhecimento que ele tem da equipe. Uma ordem sugerida para a resolução de problemas é: azul, branco, amarelo, preto, verde e vermelho.

Esta é uma técnica simples e fácil de ser utilizada, e que pode economizar incontáveis horas de reuniões e evitar discussões que não levam a lugar algum.

Fonte: MindTools.com

The post De Bono Hats: Uma ferramenta para ajudar a tomada de decisão da equipe appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Outro problema relacionado a medição é o famoso “medir por medir” que ocorre quando sabe-se que medir é importante, mas as medições são feitas sem planejamento ou sem um objetivo claro. Vale lembrar que por mais que o custo de se realizar uma certa medição seja baixo, caso esta não seja utilizada para nenhum fim, no final das contas ela se torna cara, pois significou um esforço da equipe que não serviu para nada.

Para solucionar estes problema, foi criado o GQM (Goal Question Metric). Ele é um método simples para planejar medições de forma que estas sejam baseadas em objetivos específicos de medição. A utilização do GQM com o SCRUM será mostrada a seguir.

Como uma das funções do Scrum Master é zelar pelo processo, a medição deve ser um aliado importante para seu trabalho. Uma boa prática seria analisar os pontos negativos e positivos levantados nas retrospectivas (principalmente os recorrentes) e identificar pontos falhos no processo. Por exemplo, um ponto negativo recorrente nas restrospectivas pode ser que muitos bugs estão sendo encontrados na versão de homologação, mostrando que a atividade de testes automatizados do processo de trabalho está falha.

A partir desta identificação, é possível aplicar o GQM para planejar o processo de medição, isto ocorre definindo:

• O objetivo da medição (GOAL). Ex: Melhorar a eficiência dos testes automatizados.
• A questão a ser respondida (QUESTION). Ex: Qual a eficiência dos testes automatizados?
• As métricas que respondem a questão respondida (METRIC). Ex: Intervalo entre falhas, Número de bugs encontrados em homologação etc.

Com o planejamento definido, é possível dar início ao programa de medição que será seguido pela equipe. É importante também que o Scrum Master agende reuniões periódicas de análise de dados, onde os dados medidos serão exibidos de forma que seja possível tirar conclusões para ações corretivas  (ex: gráficos, tabelas etc).

O GQM é apenas um dos muitos métodos que podem ser utilizados para se planejar medições. Outros podem ser encontardos em guias como o MPS.BR, CMMI e algumas ISOs. A conclusão importante deste post é: Medições devem ser planejadas.

The post Uso de medições com GQM (Goal Question Metric) no SCRUM appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.