Autor: Roman Pichler é um especialista alemão em Scrum e gerenciamento Ágil de produtos. Este é seu primeiro livro em inglês. Anteriormente publicou “Agiles Projektmanagement erfolgreich einsetzen” (Scrum – Applying Agile Project Management Successfully) pela dpunkt.verlag, em 2008.
Editora: Addison-Wesley | Mike Cohn Series (2010).
Tema: Gerenciamento Ágil de produtos através do Scrum (dã!). É mais que isso: é o único livro que conheço dirigido especificamente para Product Owners (Donos de Produtos), o papel mais complexo e controverso em projetos guiados pelo framework Scrum.
São no mínimo curiosas algumas contradições do Universo Ágil, particularmente aquele que defende e dissemina o uso do Scrum. Por muito tempo deram atenção quase exclusiva para a formação de ScrumMasters. Só agora começamos a ver a devida preocupação, através de cursos e deste livro, com aquele que de fato é o papel mais crítico e complexo em um projeto Scrum, o Product Owner (PO).
A quem se destina: Todos que desempenham, sonham em desempenhar ou caíram de paraquedas no role (hole?) Product Owner.
Dê de presente para:
- Super-usuários e / ou especialistas destacados para o papel de PO;
- Gerentes de Projetos;
- Gerentes de Produtos;
- Analistas de Negócios (principalmente se estiverem atuando em projetos guiados pelo Scrum).
Contra-indicações: Só não é indicado para quem apresenta reações alérgicas ao termo Agile.
Prós:
- Texto objetivo (o livro tem só 133 páginas);
- Bem ilustrado com exemplos e casos reais;
- Não fica “em cima do muro” em alguns pontos polêmicos sobre o uso do Scrum. (Mais sobre isso abaixo).
Contra:
- O que é uma vantagem (a objetividade) pode ser percebida como superficialidade. Roman poderia ter explorado um pouco mais alguns pontos mais complexos, como a criação da Visão do Produto (capítulo 2, “Envisioning the Product”). Apelo para Fred Brooks¹ para justificar minha crítica: “A fase mais complexa e crítica de um projeto de software é aquela onde definimos o que precisa ser feito.” Na trilha de estudo, abaixo, apresento uma sugestão para preencher um certo ‘vazio’ deixado por Pichler.
Cutucando Feridas (alguns trechos):
- “Minha experiência sugere que um Product Owner não consegue cuidar de mais de dois times de maneira sustentável”. (pág. 12)
- “A criação da Visão [do Produto] é melhor compreendida como um processo de descoberta, um processo de aquisição de conhecimento e aprendizagem que requer experimentação”. (pág. 37)
- “O Scrum não dita como um requisito deve ser descrito”. (pág. 53)
- “As atividades de manutenção e evolução² [do Product Backlog] da primeira iteração (sprint) tratam de itens da segunda iteração, e aquelas da segunda iteração têm como foco os item da terceira iteração, e assim por diante.” (pág. 60)
Destaquei este trecho porque ele toca em um ponto que gera estranhos debates. Quem cuida do desenvolvimento de requisitos, seja o PO ou um analista de negócios, sempre estará pelo menos uma iteração à frente do restante do time. Pichler sugere que, dependendo dos riscos e incertezas acerca do projeto, o PO trabalhe com até três iterações de distância. O planejamento de cada iteração depende da existência de um conjunto de itens adequadamente entendido e detalhado. - “Product Owner e ScrumMaster não devem fazer estimativas nem influenciá-las”. (pág. 67)
- “A fixação do prazo, orçamento e escopo não é possível; pelo menos uma das três restrições deve ser tratada como uma ‘válvula de escape’”. (pág. 76)
- “Seu papel [PO] durante o planejamento de uma iteração é ajudar o time a entender o que precisa ser feito. O time decide quanto pode ser entregue e como será feito”. (destaques em itálico do autor, pág. 98)
Trilha de Estudo:
- Será simplificada desta vez: “Agile Project Management – Second Edition”, de Jim Highsmith (Addison-Wesley, 2010), é um complemento mais que necessário e natural para o livro do Pichler. Por isso será a próxima entrada desta biblioteca, a ser publicada ainda nesta semana.
Observações:
- No artigo “No Silver Bullet” (1987), republicado como capítulo adicional do clássico “The Mythical Man-Month” (“O Mítico Homem-Mês”, Campus, 2009).
- Utilizei os termos “manutenção e evolução” como tradução de “grooming”, termo amplamente utilizado por Pichler. Perdão, mas não consegui encontrar tradução mais adequada. Sugestões?

The Agile Product Management with Scrum by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
- Agile Project Management
- Scrum kanbanbanban balangandã
- Scrum !
- Scrum ‘de Raiz’
- O Mundo Ágil precisa de Analistas de Negócios?
Related posts brought to you by Yet Another Related Posts Plugin.





{ 4 comments… read them below or add one }
Olá Paulo,
Uma coisa que discuto muito com as pessoas é sobre a fixação de custo, prazo E escopo. Os argumentos são sempre os mesmos, e a solução nunca é propor um contrato de escopo aberto ou de compra de horas mensais.
Sempre que discuto com alguém sobre esse tema, as desculpas para todo o ônus recair sobre a empresa que desenvolve o produto são:
1) Para propor contrato de escopo aberto, a empresa primeiro deve ganhar a confiança do cliente.
2) O cliente tem um budget, por isso, o valor não pode ser variável.
3) O projeto tem q ficar pronto em X meses pq o cliente tem pressa, mesmo que o tempo ideal para desenvolvimento seja 2X.
Ou seja, a minha visão é que não importa o tanto de cursos, livros, palestras que o AN faça, que a equipe faça. A empresa SEMPRE é refém do cliente (ou se faz de refém), usando isso como forma de não mudar a cultura de relacionamento com os clientes.
Oi Eduardo,
O tema realmente é controverso. E apesar de todos os traumas de décadas de projetos problemáticos, há uma enorme resistência em adotar um modelo de contratação mais humano, transparente e eficaz. Por quê?
São várias as razões, mas desconfio muito que uma delas seja realmente o péssimo histórico de diversos provedores de serviços. Do outro lado pode haver o seguinte raciocínio: “se o cara não entrega nem quando o contrato é super restritivo e detalhado, se abrirmos brechas aí é que eles não entregam mesmo”.
Vejo muito disso por aí: não funcionou? Então detalha mais os requisitos, arrocha mais o contrato, estipula multas por atrasos…
A substituição deste ‘mind-set’ não será fácil nem acontecerá da noite para o dia. Colocarei o tema em minha pauta e espero retomá-lo em breve, ok?
Abraços e obrigado pela participação.
Paulo Vasconcellos
Olá Paulo,
Não me lembro (também não procurei no blog) de você já ter escrito sobre esse tema, mas estou ansioso para que você publique algo sobre isso.
Mas é algo que eu queria discutir, pois hoje, não consigo encontrar pessoas que se incomodem com isso e trabalhem de verdade para ver a situação mudar. Ou que pelo menos aceitem discutir abertamente a questão, debatendo com argumentos convincentes de que fazer contratos amarrados é a melhor solução para ser tão utilizada hoje, em detrimento de outras abordagens de contratos no desenvolvimento de produtos.
Oi Eduardo,
Já toquei no tema aqui no finito, mas estou longe de esgotá-lo. E, como você, ansioso para discuti-lo com mais frequência. Daí minha intenção de voltar logo ao tema. Enquanto isso, se você ainda não leu, dê uma olhada nos seguintes artigos:
http://bit.ly/8pwxAl
http://bit.ly/dv9Fcd
http://bit.ly/9hHKq0
Espero que ajudem. Abraços,
Paulo Vasconcellos
{ 2 trackbacks }