Agile

A Ilusão do Gorila

Posted by on Dec 20, 2011 in Agile | 5 comments

Para David Koontz, todo o time de Scrum precisa de um Scrum Master Integral (100% do tempo), para provar o motivo ele se apóia nessa interessante experiência chama “The Monkey Business“.

Veja o vídeo:

Koontz afirma que o Scrum Master deve estar em busca de Impedimentos o tempo todo. Se você está envolvido em uma tarefa provavelmente perderá os impedimentos óbvios e as mudanças sutis nos membros do time e no ambiente.

Para Jeff Sutherland, um dos criadores do Scrum, times de Scrum sem um ScrumMaster nunca atingirão o seu potencial total (disse no grupo de discussão Scrum Development do Yahoo).

Eu (André Faria) já prefiro ir mais na linha da Toyota e dizer que, não há uma única solução para todos os times, como sempre, depende do contexto. Cada contexto é uma realidade diferente e precisa de uma solução diferente. Mas fica aí a Provocação para você pensar. Vale a pena ter um ScrumMaster/Facilitador no seu Time trabalhando em tempo integral? Será que você está vendo os Gorilas Passarem?

Read More

Apresentação sobre Programação em Par

Posted by on Nov 30, 2011 in Agile | 0 comments

Fiz essa apresentação na Bluesoft há alguns meses atrás, inspirado no curso de práticas da engenharia ágil do “Neal Ford on Agile Engineering Practices”.

Falo sobre:

  • Produtividade
  • Flow State
  • Keycaster
  • Pairing
  • Mentoring
  • Guidelines
  • Ping Pong Pairing
  • Tech Lead
  • Pair Mariage

Veja o vídeo do vimeo, e acompanhe os slides no slideshare.

Read More

Mas o que faz um Product Owner?

Posted by on Nov 22, 2011 in Agile | 6 comments

Recentemente recebi uma pergunta no Facebook, sobre o que faz um PO. Gostaria de responder a pergunta e deixar minha opinião registrada através deste post.

A pergunta foi mais ou menos assim:

Onde eu trabalho estou para assumir o desafio de ser PO, e parece que a empresa não tem bem definido o quais são as funções do PO pois alguns dos POs desenham diagramas como um analista de requisitos, isto está correto?

Segundo eles esta é a lista de atividades:

  • Entender, criticar, questionar e mapear processos de negócio do cliente;
  • Levantar requisitos funcionais e não funcionais de sistema;
  • Mapear e descrever atores e casos de usos/user stories de sistema;
  • Definir complexidade dos requisitos de negócio;
  • Elaborar documento de escopo do sistema;
  • Prototipar interfaces de usuário do sistema;
  • Realizar reuniões de licitação de requisitos com cliente;

Vamos então as origens. De acordo com o Scrum Guides:

O Product Owner é responsável por maximizar o valor do trabalho que o Time de Scrum faz, [...] é  a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo.

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro conjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o contrário. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e  recompensador ao mesmo tempo.

Isso dito, vamos fazer uma analise.

Product Owner (PO) é apenas um Papel do Scrum

Scrum é um  é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software [Wikipedia]. O processo define 3 papéis, entre eles o do Product Owner . Dessa forma em se tratando de Product Owner, podemos afirmar apenas que suas responsabilidades são apenas o que dita o processo:

  1. Maximizar o valor do trabalho que o Time
  2. Gerenciar o Backlog (Manter, Priorizar, etc)
Isso significa que um Product Owner não pode fazer nada além disso? Não. Product Owner  não é um Cargo, é um papel, ou seja, é muito provavel que a pessoa que assumir esse papel tenha outras responsabilidades na sua organização, e isso tem uma relação direta com o contexto (projeto, produto, equipe,  cliente, etc.).
O Product Owner pode ser o próprio cliente, pode ser uma pessoa que faz parte da equipe do cliente (um médico, um advogado, um contador, um CEO), pode ser um gerente de produtos, pode ser um analista de negócios, etc. Se essa pessoa tiver disponibilidade para estar perto do time e estiver capacitada a maximizar o valor do trabalho do time e gerenciar o backlog, do ponto de vista do processo, não há nada de errado com isso.
Em outras palavras, se o PO fizer bem o papel, e tiver outras atividades, não há problema algum, e essas outras atividades que fizer estiverem relacionadas à gestão do Backlog e a Maximizar o trabalho do time, melhor ainda.

Mas então quais são essas atividades?

  • Criar protótipos?
  • Fazer Pesquisas de Mercado?
  • Detalhar Requisitos?
  • Visitar Diferentes Clientes?
  • Pesquisar Produtos Concorrentes?
  • Conversar com Usuários?
  • Desenhar Diagramas?
  • Escrever Testes de Aceitação?
  • Documentar?
  • Manter um Documento de Visão?
  • Servir Café aos Desenvolvedores?
A resposta, na minha opinião, é: Depende do Contexto/Cenário!
Alguns produtos são criados para um único cliente, outros para centenas de milhares, alguns envolvem grande complexidade, outros baixíssima, alguns produtos envolvem diversas áreas de conhecimento, como é o caso de um ERP, por exemplo, alguns produtos são tão grandes, ou tem um prazo tão curto que precisam que diversos times trabalhem simultaneamente para um mesmo target release (Agile Release Train), alguns produtos são construídos em empresas com 20 funcionários, outros em empresas com milhares.

Conclusão

Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada. 

H L Mencken

Podemos concluir que não existe bala de prata! Ou seja não há um conjunto único de atividades (baixo nível) que um PO possa fazer que seja eficiente em todos os projetos e contextos. Você precisará, através de um processo de inspeção e adaptação, encontrar quais são essas atividades que fazem sentido na sua organização.
Read More

Padrões para Quebrar Estórias de Usuário

Posted by on Oct 10, 2011 in Agile | 1 comment

Recentemente, lendo o livro “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise” encontrei uma lista com 10 padrões para dividir estórias de usuário, achei muito interessante, e já estou utilizando os padrões no dia-a-dia.

Preparei alguns slides para apresentá-los e difundí-los:

Referências

Read More

Agile e Lean Startups

Posted by on Sep 8, 2011 in Agile, Business | 2 comments

Recentemente Joshua Kerievsky, postou as principais diferenças entre as práticas da comunidade ágil e da comunidade de lean startups.

Segundo Joshua, Lean Startup é um método disciplinado, cientifico e lucrativo para descobrir e construir produtos e serviços em que as pessoas se apaixonem.

Lean Startup faz o melhor de ágil ficar mais lean e combinado ao brilhante processo de Customer Development.

Na minha visão, ágil e lean startups tem muito em comum, e na verdade podem ser complementares. Não entendo que as práticas adotadas pelas startups de maneira alguma possam ferir principios ágeis. Lean Startups utiliza formas diferentes (inclusive mais eficazes em muitos contextos) de representar a mesma essência. É importante porém entender que Lean Startups tem uma intersecção com ágil, no diz respeito ao desenvolvimento de software, mas vai além.

A idéia portanto, não é provar o que é melhor, mas explorar as diferenças. Isso dito, vale analisar algumas diferenças das práticas das duas comunidades, destacados por Joshua:

 

Agile

Lean Startup
Product Roadmap Business Model Canvas
Product Vision Product Market Fit
Release Plan MVP (Minimal Viable Product)
Sprint Kanban
Sprint Review Pivot or Persevere Decision
On-Site Customer “Get Out Of The Building”
User Story Hypothesis
Backlog “To Learn” List
Definition of Done Validated Learning
Red-Green-Refactor Learn-Measure-Build
Customer Feedback Customer Validation
Acceptance Test Split Test
Velocity AARRR
Mock Object Feature Fake
Continuous Integration Continuous Deployment
Certified Scrum Master Customer Success Manager
Recentemente fiz uma apresentação na Bluesoft sobre Lean Startups, ficam os slides para quem quiser se aprofundar mais assunto.
Read More

Lista com todas as Práticas Ágeis

Posted by on Sep 1, 2011 in Agile, Featured, Software | 5 comments

Calma, calma, eu sei que o título está um pouco, ou melhor, muito ambicioso, mas em 2009, Jurgen Appelo fez um post chamado “A grande lista de práticas ágeis“, sabendo desde o inicio que o post seria odiado e amado por muitos, visto que já muita gente encara metodologias de modos mais partidários ou religiosos. Com este aqui não será diferente.

Eu gosto de encarar essas práticas como uma caixa de ferramentas, e nessa linha, podemos encarara que cada ferramenta certa para o problema certo, ou seja, dependendo de cada realidade ou contexto, ferramentas diferentes serão ou não úteis. Tomei como base a lista do Jurgen e incluí algumas outras práticas.

Requisitos (Requirements)

Design

Desenvolvimento (Construction)

Testes (Testing)

Processo (Process)

Organização (Organization)

Aprendizado

  • Coding Dojos
  • Clubes de Livro (Book Clubs)
  • Palestras da Equipe para a Equipe (Brown Bag Seminars)
  • Biblioteca Rica à Disposição (Livros, Screencasts, Áudio-livros, Contas no SafariBooks)
  • Participação em Eventos (Alta cobertura de eventos)

Gestão Ágil

Referências

Agradecimentos Especiais à Jurgen Appelo, Daniel Cukier, e Fábio Aguiar pela colaboração.
Sentiu falta de alguma prática na lista? Deixe seu comentário.
Read More