Arquivos do Blog

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.
Anúncios

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.

Certificação EXIN-ASF: o mix da agilidade

“Pedro, necessito das peças de montagem em até 2 dias. Alexia, já solicitei a João via sistema de estoque. Ele que se vire!”  Esse é um diálogo atual e bastante comum nas organizações que buscam celeridade nas entregas de projetos, os quais materializam o planejamento estratégico da empresa. Para solucionar o conflito apresentado no cenário acima, os métodos ágeis aproximam as pessoas dando atenção especial às interações entre elas e, por conseguinte, possibilitando a criação de um ambiente colaborativo que forneça respostas rápidas às constantes mudanças que se fazem necessárias.

Um dos métodos ágeis mais conhecidos no mercado é o Scrum. Baseado em planos de iterações chamados de Sprints, ele provê mais agilidade na entrega do produto e, dessa forma, fornece valor mais rápido para o cliente. Suas reuniões diárias, curtas e objetivas, permitem ao time responder rapidamente à quaisquer mudanças que se façam necessárias, estando assim, constantemente alinhados às expectativas do cliente e evitando prejuízos no cronograma e nos custos planejados. As demais reuniões de revisão e retrospectiva, permitem ao time analisar o que deu certo ou errado durante a execução dos trabalhos e como se antever a possíveis problemas que atrasem as entregas e gerem insatisfação por parte do cliente.

Visando atender à demanda do mercado por profissionais alinhados aos conceitos e práticas ágeis, o instituto EXIN criou a certificação ASF (Agile Scrum Foundation). Apesar da nomenclatura, essa certificação atesta também que seus detentores possuem conhecimentos básicos em outras metodologias ágeis como XP, Kanban, DSDM, Crystal, FDD e TDD, porém o foco maior é o Scrum.

Você pode se inscrever para realizar o exame EXIN ASF online, diretamente no site da Exin, mas é recomendável que você faça o curso Preparatório ASF – Agile Scrum Foundation 8h, da Projectlab, que contempla todos os tópicos que são abordados na prova:

  • Conceitos de Agile (Kanban, XP, Crystal, DSDM, TDD e FDD) e Scrum;
  • Práticas Scrum;
  • Planejamento Scrum;
  • Monitoramento de projetos com Scrum;
  • Conceitos avançados de Scrum.

Essa característica fornece uma vantagem competitiva, pois permite ao profissional aplicar a técnica mais adequada ao cenário em que ele se encontra ou ainda uma combinação de técnicas.

Se você tiver mais alguma dúvida sobre a certificação, baixe o White Paper “Guia Rápido das Certificações Ágeis do Mercado”

Este post trata-se de um artigo patrocinado (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).

 

2º Congresso Nacional de Gerenciamento de Projetos do PMI-SE

Face - Palestras full clean

O objetivo deste projeto é realizar o 2º Congresso Nacional de Gerenciamento de Projetos do PMI Sergipe para proporcionar uma troca de experiências e uma disseminação de conhecimento através de palestras, minicursos e apresentação de casos reais em diversas áreas de conhecimento do Gerenciamento de Projetos.

  • Até 16 PDUs

OBS: Os minicursos são vendidos separadamente. A aquisição da cota PALESTRAS dará direito a assistir todas as palestras do evento. A aquisição da cota referente ao minicurso dará direito a assistir SOMENTE o minicurso adquirido. VAGAS LIMITADAS.

Inscreva-se aqui! 

Investimento:
Minicursos
 Minicurso – PM4Plane – Scrum + PMBOK no Gerenciamento de Projetos – Fábio Cruz:

Será apresentada uma proposta inédita de união entre o ágil e o Guia PMBOK 5a edição, visando demonstrar como ter times altamente ágeis sem abandonar o PMBOK e ao mesmo tempo como manter o controle eficiente sem perder a agilidade. Esta abordagem é apoiada em um caso real de aplicação em um grande projeto global.

Minicurso – Gerenciamento de Tempo em Projetos com MS Project 2013 (PMBOK 5ªed.) – Daniel Ettinger:

Conteúdo Programático:

– Gerenciamento do Tempo em Projetos com o PMBOK (5ª Ed.)
– Dicas para um bom Cronograma

PLANEJAMENTO
– Calendários
– Atividades
– Determinando o Caminho Crítico

CONTROLE
– Linhas de Base
– Acompanhando o progresso das tarefas
– Linhas de Andamento
– Movendo o Projeto para uma nova data.

AGENDA DO EVENTO:

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

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.

Certificado ScrumMaster

O Backlog do Produto e a arte da User Story

Pesquisando sobre o framework Scrum você, certamente, já deve ter lido algo do tipo: “O Backlog do Produto contém as funcionalidades do novo produto solicitadas pelos usuários” ou ainda “Os requisitos para o produto que o time está dsenvolvendo estão listados no Backlog do Produto”. Esses, caso você não saiba, são conceitos equivocados ou que podem gerar diferentes interpretações.

Segundo Mike Cohn,  user story é uma pequena e simples descrição de uma funcionalidade dita da perspectiva da pessoa que deseja a nova capacidade, usualmente um usuário ou cliente do sistema. Em outras palavras, o Backlog do Produto deve conter as necessidades dos usuários ou clientes e não as funcionalidades do sistema. Trata-se de uma mudança de paradigma quando comparado ao modelo criado pelo PMI (Project Management Intitute) para gestão de projetos. E é esse um dos papéis do Product Owner: 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.

Para compreender melhor essa mudança de paradigma vamos exemplificar. Observe atentamente a história abaixo:

 

Vantagens do uso do template para User Story

“Como um <ator>, eu gostaria de <ação>, para <objetivo>.”

Você, caro leitor, pode estar agora se perguntando. Mas qual o motivo de usar esse template sempre que eu for escrever uma user story? Pesquisando sobre o assunto, descobri que existem duas razões principais pelas quais esse template se torna tão importante (fonte: mountaingoatsoftware.com).

Razão 1: A magia dos pronomes

Algo mágico acontece quando as exigências são colocadas na primeira pessoa. Obviamente, dizendo: “Como tal e tal, eu quero …” você pode ver como a mente da pessoa vai imediatamente imaginar seus desejos. Paul McCartney foi entrevistado e perguntado sobre por que as canções dos Beatles foram tão incrivelmente populares. Uma de suas respostas foi que suas músicas estavam entre os primeiros a usar um monte de pronomes. Pense nisso: She Loves You, I Want to Hold Your Hand, I Saw Her Standing There, etc. Seu ponto era que essas pessoas passaram a se identificar mais de perto com as canções. Assim acontece nas user stories.

Razão 2: Estrutura a serviço do Product Owner

A estrutura do template ajuda o Product Owner a priorizar as histórias dos usuários. Se o product backlog é um amontoado de coisas como Permita controlar exceção, Permita que os usuários façam reservas, Os usuários querem ver fotos, e assim por diante, o Product Owner tem que trabalhar muito mais para entender o que o recurso é, quem se beneficia a partir dele, e qual o valor dele.

DICA

Muitas pessoas alegam que esse modelo acaba suprimindo o conteúdo da informação devido ao uso de tantos clichês. Se você também concorda com esse pensamento, sugiro que faça o seguinte. Organize seu Backlog do Produto em um tabela com o seguinte cabeçalho. “Como”, “eu gostaria”, “para”. Isso facilita o modo de leitura e compreensão das necessidades. Veja o exemplo abaixo:

%d blogueiros gostam disto: