Posts Tagged "scrum"

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

Pergunte-se: Por quê?

Posted by on Feb 16, 2010 in Agile | 15 comments

Para ser produtivo é essencial ter sempre em mente o objetivo por trás de tudo que se está fazendo. O propósito deve estar bem claro.

Question Mark by Marco Bellucci

Question Mark by Marco Bellucci

É muito comum nos dias de hoje que as pessoas façam suas atividades sem ter verdadeira consciência do por que, da razão pela qual estão fazendo e qual resultado desejam alcançar.

Sem ter uma definição clara do propósito pelo qual se está fazendo determinada atividade, e qual é o objetivo é impossível medir se está indo bem ou se mal. Não há possibilidade de vencer ou ser derrotado, pois não se sabe o que é derrota ou vitória.

Para ter certeza de você sabe exatamente qual é a razão das atividades que você está fazendo, crie o hábito de perguntar-se: por quê?

Ter objetivos claros dá suporte à tomada de decisões, uma vez que todas as decisões tomadas devem estar alinhadas ao objetivo. Ter um objeto é como ter um norte, uma direção, não tê-lo é como vagar no deserto em círculos. Nas palavras de Stephen Covey, autor do livro “Os 7 Hábitos das Pessoas altamente Eficazes”:

“Começar com o objetivo em mente significa começar tendo uma compreensão clara do destino. Significa saber para onde você seguindo, de modo a compreender melhor onde você está agora e dar os passos sempre na direção correta.”

Ter objetivos claros motiva, permite que tenha noção de progresso, ajuda a manter o foco, dá visão, abre as portas da criatividade, uma vez que se em mente o resultado que deseja alcançar.

Em se tratando de trabalho em equipe, quando não se tem objetivos claros, a situação pode agravar-se ainda mais, pois cada um pode seguir por caminhos diferentes tomando como referencial sua interpretação pessoal de objetivo.

Por essas razões metodologias ágeis como Scrum reforçam a importância de se ter metas bem definidas, é o Sprint Goal. Toda a equipe deve estar alinhada em relação às expectativas de sucesso do cliente. Devem ter claro o que se deseja ter como resultado e dessa forma todos poderão remar na mesma direção tomando decisões, por menores que sejam sempre alinhadas ao objetivo.

É pelo mesmo motivo, que existe a definição de pronto, este como se fosse um micro-objetivo de cada tarefa, atingir o estado de pronto, que deve estar bem definido de forma que todos possam compreender e identificar a diferença entre uma tarefa completa e uma incompleta.

Em uma reunião de retrospectiva, por exemplo, é essencial que todos tenham consciência que o objetivo é tornar a equipe melhor, caso contrário, pode transformar-se em um mero jogo de culpa, perda de tempo e investimento.

Não faça as coisas de forma mecânica, faça de forma consciente, entenda o porquê.

Read More