Arquivo da categoria: Scrum

Como construir um Product Backlog efetivo

Para entender como construir um efetivo backlog do produto, primeiro é preciso entender os conceitos que permeiam esse tema. Product Backlog é uma lista de necessidades que o cliente possui, descritas com sua própria linguagem, e que precisam ser atendidas pelo produto que será entregue ao final do projeto. Já a efetividade está relacionada a algo que tem efeito real. Unindo os conceitos, temos uma lista de necessidades que ao serem supridas, causam efeito real sobre o indivíduo.

É necessário, em primeiro lugar, entender que o Product Backlog é algo que deve ser construído de forma incremental, ou seja, no início do desenvolvimento teremos apenas uma visão macro que será detalhada à medida que se aprende mais sobre o produto e seus usuários. Deve ser formado por histórias de usuário que, segundo Mike Cohn, são pequenas e simples descrições de funcionalidades sob a perspectiva da pessoa que deseja as novas capacidades, usualmente um usuário ou um cliente do produto.

Publieditorial-2015_Dez

Traduzir as necessidades do cliente, através do Backlog do Produto, em uma linguagem não técnica, compreensível por todas as pessoas envolvidas no projeto é um dos papéis do Product Owner. Para isso, uma boa prática é registrá-lo com as seguintes informações: ID (único), Nome (representativo), História de Usuário, Prioridade, Complexidade/Esforço (série de Fibonacci) e Observações. Dessa forma, teremos um backlog de produto detalhado, compreensível e alcançável para que o time possa produzi-lo e satisfazer às necessidades do cliente.

Deseja tornar seus backlogs de produto mais efetivos e alcançáveis? Uma boa oportunidade é participar do curso Fundamentos em Métodos Ágeis da Projectlab. O curso foi desenvolvido para ajudar você a entender e a praticar os principais conceitos sobre o gerenciamento ágil de projetos.

Este post trata-se de um publieditorial.

Retrospectivas Eficazes

filme1-300x183

Entende-se por retrospectiva o relato de uma série de acontecimentos decorridos durante certo período de tempo. Segundo o Scrum Guide, “a retrospectiva do Sprint é uma oportunidade para a Equipe do Scrum inspecionar-se e criar um plano de melhorias que deve se valer durante o próximo Sprint”. Em outras palavras, ao final de cada Sprint o time realiza uma reunião com o objetivo de avaliar o que deu certo e deve continuar sendo aplicado, assim como, o que ocorreu de errado e o que pode ser feito para reduzir os erros e melhorar o desempenho nas próximas Sprints.

É importante, no início da reunião, contextualizar os participantes deixando claro qual é o objetivo da mesma, ou seja, direcionar esforços para o que deve estar em foco. Esse papel pode ser realizado pelo Scrum Master, ou qualquer membro da equipe, visto que ela é auto gerenciável. Em seguida, pode  ser realizada uma análise de SWOT onde a equipe  identifica, individualmente e imparcialmente, seus pontos fortes e fracos, além de oportunidades e ameaças, registrando comentários a respeito. Ao final, os participantes  discutem seus registros e a equipe sintetiza o que foi reportado. Dessa forma, criam-se lições aprendidas que servirão para melhorar o desenvolvimento das Sprints seguintes. Esse é um processo incremental que busca a melhoria contínua.

Publieditorial-2015_Nov

Finalizada a síntese, o time  decide o que será priorizado na próxima iteração. Pode ser utilizada a técnica que a equipe desejar, desde que esta seja baseada em critérios claros e objetivos sobre o que realmente gera valor para o cliente. Isso evita a ocorrência do cenário em que “quando tudo é prioridade, nada é prioridade”. Ao final, deve ser discutido como o backlog da próxima Sprint deverá ser realizado.

Está em busca de tornar suas retrospectivas de Sprints mais eficazes? Uma boa oportunidade é participar do curso Preparatório para Certificação PMI-ACP da Projectlab. Com a metodologia e o material didático mais completo do mercado, desenvolvido pela RMC, empresa da renomada Rita Mulcahy, o curso foi desenvolvido para ajudar você a se preparar para o exame, e obter o máximo de entendimento sobre o gerenciamento ágil de projetos.

Este post trata-se de um publieditorial.

Jogando as cartas na mesa com o Planning Poker

 
Estimar o tamanho de um software não é uma tarefa trivial. Requer esforços de tempo e custos que usualmente os investidores não estão dispostos a pagar. Sendo assim, surge a necessidade de utilizar uma técnica que agilize o processo, mas não reduza sensivelmente a qualidade das estimativas.

O Planning Poker, definida por James Grenning em 2002, é uma técnica de estimativa de tamanho voltada para as metodologias ágeis de desenvolvimento de software. Consiste em realizar estimativas através de um jogo de cartas, no qual os membros do time (analistas, programadores, testadores, etc), baseados em fatores como tempo e esforço, interagem de forma colaborativa e expõe sua visão de complexidade afim de pontuar um cartão que representa determinada estória do usuário. Por fim, analisam as diferentes visões e buscam chegar a um denominador comum na equipe por meio do consenso geral.

A técnica consiste no seguinte: os participantes do jogo deverão realizar, em conjunto, rodadas de pontuação afim de obter a estimativa de um cartão que possui uma estória de usuário. Eles dispõem de um baralho com 13 cartas numeradas sequencialmente de acordo com a série de Fibonacci, ou seja, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Existe ainda uma carta com o símbolo de interrogação que configura a não aptidão do jogador em estimar e outra carta com o símbolo de uma xícara de café que sugere uma pausa para discussões e avaliações preliminares sobre a estória em questão. O Scrum Master será responsável por mediar as diferentes visões, enquanto que, o Product Owner deverá esclarecer o que deverá ser produzido pelo time.

Ficou curioso sobre a técnica de estimativa Planning Poker e deseja se aprofundar mais no universo da agilidade? O curso Fundamentos em Métodos Ágeis da Projectlab poderá te proporcionar o conhecimento que deseja. Inscreva-se aqui.

Este post trata-se de um publieditorial.

Os benefícios das histórias de usuários

Segundo Mike Cohn, história de usuário é uma pequena e simples descrição de uma funcionalidade dita da perspectiva da pessoa que deseja a nova capacidade, usualmente um usuário ou um cliente do sistema. Em outras palavras, o Backlog do Produto deve conter as necessidades dos usuários ou dos clientes, enão as funcionalidades do sistema. Para compreender melhor essa ideia, é preciso analisar atentamente as nuances que permeiam esse conceito.

“Eu como gerente de PMO, desejo visualizar uma lista completa do portfólio de projetos da organização para poder classificá-los e priorizá-los de acordo com o planejamento estratégico”.

É possível observar algumas vantagens no uso do template de história de usuário: “Como um <ator>, eu gostaria de <ação>, para <objetivo>”. O primeiro benefício está relacionado ao que chamamos de magia dos pronomes, pois algo especial ocorre quando as exigências são colocadas na primeira pessoa. As partes envolvidas passam a se identificar mais de perto com as histórias. A segunda vantagem é fornecer uma estrutura a serviço do Product Owner, pois a estrutura do template ajuda o PO a priorizar as histórias dos usuários. Dessa forma, ele consegue visualizar mais facilmente o que o recurso é, quem se beneficia a partir dele, e qual o valor dele.

Algumas pessoas alegam que esse modelo acaba suprimindo o conteúdo da informação devido ao uso de tantos clichês. Se você concorda com isso, é possível organizar as histórias através de uma tabela com os campos “Como”, “eu gostaria” e “para”. Isso facilita o modo de leitura e compreensão das necessidades.

Caso deseje aprofundar seus conhecimentos em histórias de usuários, participe das Oficinas de Inverno promovidas pela Projectlab, pois apresentam uma visão conceitual e prática de como especificar os requisitos através de histórias de usuários, por que utilizar este formato, como identificar, documentar, priorizar e selecionar as histórias que entrarão na composição do produto a ser produzido.

Este post trata-se de um publieditorial.

Breve panorama sobre os Métodos Ágeis – XP, Scrum e o Manifesto

O conceito de agilidade está intimamente ligado à pratica de entrega rápida de valor ao cliente. Dessa forma, as metodologias ágeis possuem um enfoque voltado à colaboração com o cliente do que propriamente com a negociação rígida de contratos. Para tornar isso possível, a visão passa a ser a de priorização de ter software executável (produto construído) em detrimento à uma documentação abrangente. Ainda nesse cenário, os agilistas afirmam que devemos dar mais atenção aos indivíduos e suas interações do que aos processos e ferramentas que envolvem a construção do produto. Afirmam ainda que devemos reagir rapidamente às mudanças que se fizerem necessárias do que seguir um plano do início ao fim. Esses são os princípios do Manifesto Ágil, lançado em 2004 pela Aliança Ágil.

Aliados a esses princípios, existem algumas técnicas que são frequentemente utilizadas buscando favorecer a rápida entrega de valor ao cliente, a saber: programação em pares, refatoração, metáforas e integração contínua, no caso da Extreme Programming. Já o Scrum promove eventos, como as reuniões diárias e a reunião de retrospectiva, que aumentam significativamente a interação e comunicação entre os stakeholders do projeto. Existem ainda outros benefícios: pequenas iterações, equipes auto gerenciáveis e disseminação de princípios como compromisso, responsabilidade e respeito.

Contudo, como diria o dito popular, “nem tudo são flores”. Alguns pontos fracos necessitam ser pensados e trabalhados de maneira a maximizar os ganhos com o uso dessas metodologias. Elas carecem de uma análise de riscos, sem torná-las pesadas. Outro desafio é aprender a utilizar essas metodologias ágeis em grandes empresas e equipes, visto que usualmente são baseadas em equipes pequenas.

Caso deseje aprender mais sobre Métodos Ágeis, recomendo o novo curso recentemente lançado pela Projectlab. Você irá aprender novas técnicas e abordagens em um ambiente lúdico que estimula a absorção do conhecimento. Confira!

 

Este post trata-se de um artigo patrocinado (publieditorial).

 

Curso Gestão e Formação de Equipes de Alta Performance com Scrum

Apresentar como as práticas ágeis de gerenciamento de projetos baseado em Scrum apóiam o processo de formação e gestão de uma equipe (team building). Capacitar os profissionais nos conceitos e estágios de formação de um time e mostrar um case real da aplicação das técnicas baseadas em Scrum favorecem a formação e gestão de um time de alta performance.

Leia o resto deste post

Liderança é o tema do 10o. encontro do GE2PS – AGILIZE-SE! PARTICIPE!

Ferramenta de apoio à comunicação em projetos: A Matriz de Comunicação

Participando de diversos projetos percebi que, geralmente, determinados esforços são privilegiados em detrimento de outros. Isso se deve, muitas vezes, à frequente pressão para se encontrar uma solução rápida e adequada no gerenciamento de determinados projetos. Um dos esforços NÃO privilegiados é o planejamento da comunicação no projeto, igualmente relevante para o sucesso das atividades.

Um fato notório é que em quase todos os projetos com grau de complexidade mais elevado, pode ser constatada a ocorrência de uma abordagem não adequada da comunicação. A ideia de “transparência no projeto” deve fundamentar um bom plano de comunicação sem, contudo, agregar muita coisa no processo de gerenciamento do projeto.

Atualmente, contamos com diversas ferramentas que dão suporte a uma adequada comunicação em projetos. Estudos demonstram que “o sucesso de uma comunicação depende de uma adequada seleção de ferramentas e de suportes de gestão adaptados ao projeto” [VIEIRA, 2011]. Sendo assim, o objetivo deste post é apresentar conceitos e benefícios de uma dessas ferramentas como suporte à gestão da comunicação: a matriz de comunicação.

A matriz de comunicação é uma ferramenta que especifica quais documentos serão comunicados, para quais stakeholders, em que freqüência (quando) e por qual meio (como). Ela deve estar presenta dentro do plano de comunicação do projeto. Para um melhor entendimento, observe a matriz abaixo.

Figura 1 – Matriz de comunicação

Fonte: Revista Mundo PM – Ed. 37.

 Segundo o PMBOK o plano de comunicação determina as necessidades de informação e comunicação dos envolvidos no projeto; por exemplo, quem precisa de qual informação, quando ela será necessária, como e por quem ela será distribuída. Um bom plano de comunicação deve especificar métodos que permitam transmitir a informação sem ruído, de maneira clara, tendo sempre o feedback do receptor. Assim, a matriz de comunicação, exemplificada acima, apresenta informações de grande utilidade para o plano de comunicação do projeto.

A matriz de comunicação pode ainda ser utilizada como ferramenta de apoio para projetos que utilizem metodologias ágeis de desenvolvimento. Vamos tomar como exemplo o framework Scrum, o qual desenvolve a comunicação por intermédio de Daily Meeting, Burndown Charts, Quadro de Kanban, etc. Sim, estas ferramentas permitem a comunicação e visibilidade do projeto, mas existem outras necessidades que estas ferramentas não atendem. É nesse ponto que entra a utilidade da matriz de comunicação: técnica complementar para apoio à adequada comunicação em projetos ágeis.

Figura 2 – Matriz de comunicação para projetos com Scrum.

Fonte: http://blogdoabu.blogspot.com

Para finalizar, gostaria de frisar que a comunicação em projetos tem que ser tratada como as demais gestões (custos, riscos, escopo, integração, etc.): um permanente facilitador para obtenção de sucesso em projetos. Trata-se de uma gestão bastante crítica, pois, se desprezada ou negligenciada, pode produzir onerosos retrabalhos, arruinar cronogramas, aumentar os riscos e custos, etc. Em posts futuros irei apresentar com mais incisão como planejar a comunicação em projetos de forma a criar um ambiente propício ao sucesso.

A engrenagem do Scrum

Muitas pessoas acreditam que Scrum é uma metodologia que ajuda a desenvolver melhores produtos. Isso não é verdade! Se a solução idealizada e projetada for ruim, o produto que será produzido também será ruim, independentemente da metodologia utilizada. Scrum não lhe dá a resposta de como desenvolver software de qualidade mais rapidamente. Trata-se de um framework que pode ser usado para identificar o que precisa ser feito para desenvolver software de qualidade rapidamente. Assim, aqueles que acreditam que o Scrum é uma bala de prata que irá sempre resolver todos os seus problemas de forma simplista e eficiente, se enganou! Tornar o Scrum eficaz e eficiente depende da correta aplicação dos conceitos que norteiam esse framework.

O Scrum, em sua essência, é simples de ser compreendido e aplicado. Porém, antes de explicar como funciona a engenharia desse processo é necessário compreender as pessoas que estão envolvidas e seus papéis. No Scrum existem três papéis de atuação:

  • Product Owner 
    • Define as funcionalidades do produto;
    • Decide a data de entrega e o conteúdo;
    • Responsável pelo ROI (Return of Investiment) do produto;
    • Prioriza as funcionalidades conforme o valor de negócio;
    • Ajusta as funcionalidades e suas prioridades a cada Sprint;
    • Aceita ou rejeita os resultados.
  • Scrum Master
    • Responsável pela aplicação dos valores e práticas do Scrum;
    • Remove impedimentos;
    • Assegura que a equipe está totalmente funcional e produtiva;
    • Permite a cooperação entre os diversos papéis e  funções;
    • Protege o time das interferência externas.
  • Time
    • Grupo formado, preferencialmente, por 5 a 9 pessoas;
    • Deve ser multifuncional;
    • Preferencialmente, dedicado única e exclusivamente ao projeto;
    • Auto-gerenciado.

A engrenagem do Scrum funciona de maneira a proporcionar rápida resposta a mudanças. Observe que primeiramente é concebida uma visão do problema existente. A partir dessa visão o Product Owner constrói o Backlog do Produto, o qual irá conter  tudo o que é necessário para desenvolver e lançar um produto com sucesso. Trata-se de “uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras” [SCHWABER, 2009]. O Backlog do produto é formado por User Stories ordenadas por prioridade. Ele nunca está completo: evolui à medida que o produto e o ambiente em que ele será usado evoluem.

Figura 1 – A engrenagem do Scrum.

Fonte: Blog Gestão de Projetos Ágeis

Após a definição e priorização do Backlog do Produto, o próximo passo é o Planejamento da Sprint. Sprint nada mais é que uma iteração do projeto. Em um primeiro momento dessa reunião é decidido o que será feito na Sprint, mais conhecido como Sprint Backlog. Em seguida, o Time deverá entrar em um consenso sobre como desenvolverá essa funcionalidade. Cabe somente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Time pode avaliar o que ele é capaz de produzir durante a Sprint. As user stories devem ser escolhidas baseando-se nas prioridades definidas pelo Product Owner e no prazo escolhido para essa iteração. Essas iterações são contínuas até que todo o Backlog do Produto tenha sido produzido. Podem ter duração entre duas e quatro semanas e devem ser acompanhadas pelas reuniões diárias. Essas reuniões devem ser conduzidas pelo Time, ter duração máxima de 15 minutos e ocorrerem sempre no mesmo horário e local. Durante a reunião diária, cada membro do Time deve explicar:

  • O que ele realizou desde a última reunião diária;
  • O que ele vai fazer antes da próxima reunião diária; e
  • Quais obstáculos estão em seu caminho.

As reuniões diárias servem para melhorar a comunicação, eliminar outras reuniões, identificar e remover impedimentos para o desenvolvimento, ressaltar e promover a rápida tomada de decisão e melhorar o nível de conhecimento de todos acerca do projeto. Vale ressaltar que o Scrum Master ensina o Time a manter essa reunião com curta duração, reforçando as regras e garantindo que as pessoas falem de forma rápida e objetiva.

Após o término de cada Sprint deverá ser feita a Revisão da Sprint, onde o Time deverá apresentar o que foi feito (produto potencialmente utilizável) e validar com as partes interessadas. Obtém-se assim, entrega de valor ao cliente com uma maior frequência, num menor espaço de tempo. O Time também deverá discutir o que correu bem durante a Sprint, quais os problemas enfrentados e como eles foram resolvidos. A Revisão da Sprint fornece entradas de extremo valor para as próximas reuniões de Planejamento de Sprints.

A Retrospectiva da Sprint é o passo seguinte e deve ocorrer antes da próxima reunião de Planejamento da Sprint. Durante essa retrospectiva o Scrum Master encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais produtivo para a próxima Sprint. Neste momento deve ser inspecionado como correu a última Sprint, em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. Ao final dessa etapa o Time deve ter identificado medidas de melhorias factíveis que deverão ser implementadas na próxima Sprint.

Por fim é válido ressaltar a importância da ferramenta Gráfico de Burndown, a qual nos fornece inúmeras possibilidades, tais como:

  • Permite medir o progresso e velocidade do time.;
  • Apresentar a quantidade de trabalho restante;
  • Ser personalizável, a depender da necessidade do time;
  • Permite avaliar riscos no projeto.

Portanto, vimos como a engrenagem do Scrum funciona de forma simples e objetiva, atacando os principais ideais defendidos pelo Manifesto Ágil: mais indivíduos e interações do que processos e ferramentas; mais software em funcionamento do que documentação abrangente; mais colaboração com o cliente do que negociação de contratos; e responder a mudanças mais facilmente do que seguir um plano. E lembre-se: o Scrum é o seu parceiro e não o seu chefe! Ele lhe fornece suporte (técnicas e ferramentas) para produzir produtos com qualidade mais rapidamente. Jamais ele irá lhe dizer como construir seu produto ou serviço! O leitor que deseja se aprofundar mais no assunto e conhecer mais detalhes sobre esse framework, basta acessar a seção Scrum no menu através da opção Documentos > Metodologias Ágeis ou através desse link.

SCHWABER, Ken. Guia da Scrum. ScrumAlliance, 2009.
GOLDENBERG, Michel. Curso Certified Scrum Master. GoToAgile!, 2010.

Meu artigo publicado no iMasters!

É o blog Gestão de Projetos Ágeis dando sua contribuição ao iMasters. Espero, em breve, postar outros artigos interessantes do blog lá no iMasters. Agradeço a todos os leitores pelos elogios, críticas e sugestões que venho recebendo. Cada vez mais acredito que compartilhar conhecimento não se trata de uma tarefa que precisamos cumprir e sim de uma atitude que devemos tomar!

%d blogueiros gostam disto: