Posts Tagged "agil"
Mas o que faz um Product Owner?
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:
- Maximizar o valor do trabalho que o Time
- Gerenciar o Backlog (Manter, Priorizar, etc)
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?
Conclusão
Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada.
Agile e Lean Startups
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 |
Dossiê Cultura da Toyota – 4 Vídeos e 5 Apresentações de Slides
- O que é Cultura
- Cultura Organizacionais Fracas e Fortes
- Kaizen e Melhoria Contínua
- Criar uma Cultura x Mudar uma Cultura
- Lean – Eliminar o Desperdício
- Toyota House
- Value Stream Mapping
- Confiança
- Liderança
- Hoshin-Kanri
- Qualidade
- Cross-Training
- Processo de Seleção e Contratação na Toyota (Case de Kentucky)
- Identificar e Resolver Problemas
- Lidando com o Individualismo Ocidental
- O que é Gemba
- Hierarquia
- Analogia do Cirurgião
- Trabalho Padronizado
- Gerentes na Toyota
- Rotatividade
- Treinamento
- COPA (Critical Output Analysis)
- Resolução de Problemas com A3
- Um lugar para cada coisa e cada coisa em lugar com 5S
Introdução à Cultura da Toyota
Pessoas, Contratação e Comunicação
Pensamento A3
Toyota 5S
Por favor, deixe seu feedback através de um comentário.
Siga-me no twitter para ficar por dentro das novidades.
Artigo de Kanban na JavaMagazine
JM 84
É com grande satisfação que anuncio que o artigo que escrevi sobre Kanban finalmente foi publicado na Java Magazine 84.
Este artigo apresenta uma introdução ao método Kanban. Para isso, descreve os passos para implantá-lo em uma equipe de desenvolvimento de software, aborda a criação de um card wall que represente o processo e cartões que representem itens de trabalho, além da definição da cadência de reuniões e outros eventos importantes para o ciclo de desenvolvimento.
Kanban permite que um processo seja otimizado de acordo com um contexto específico, aderindo a diferentes tipos de equipes e projetos. Geralmente causa pouca resistência a mudanças por parte das pessoas e da organização, ao passo que ajuda a equipe a manter um ritmo sustentável e previsível através de um fluxo contínuo de trabalho, conquistado em virtude da definição do limite de trabalho em progresso.
Para quem tiver mais interesse, há também uma apresentação sobre o tema que fiz no Bluesoft Labs:
Harvard e Desenvolvimento Ágil
A descoberta mais notável foi que criar um versão com poucas funcionalidades e entregá-la aos clientes cedo melhora a qualidade dramaticamente.
Este é um trecho do artigo do Professor Alan MacCormack da Harvard Business School “Porque Desenvolvimento Evolutivo de Software Funciona“, em que fala sobre o desenvolvimento de software iterativo:
Desenvolvimento de sucesso é evolucionario por natureza. Empresas lançariam primeiro uma versão com poucas funcionalidades de um produto para determinados clientes logo no inicio do desenvolvimento. Posteriomente o trabalho continuaria de forma iterativa, permitindo que o design evolua em resposta ao feedback dos clientes.
Evolution por teamtraveller
Qualquer semelhante com a abordagem ágil, é mera semelhança. O professor apresenta ainda quatro práticas levam projetos de software ao sucesso. Consulte o artigo de Alan MacCormack.
