Agile Product Management with Scrum

12/07/2010

in Biblioteca,Projetos

Post image for Agile Product Management with Scrum

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:

  1. 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).
  2. 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?
Share

Artigos relacionados:

  1. Agile Project Management
  2. Scrum kanbanbanban balangandã
  3. Scrum !
  4. Scrum ‘de Raiz’
  5. 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 }

Eduardo Souza July 15, 2010 at 13:30

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.

Reply

admin July 15, 2010 at 14:33

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

Reply

Eduardo Souza July 15, 2010 at 17:32

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.

Reply

admin July 15, 2010 at 17:54

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

Reply

Leave a Comment

Spam Protection by WP-SpamFree

{ 2 trackbacks }

Previous post:

Next post: