Papéis no SCRUM – Você sabe responder?
Atualização em 18/08/09 – Depois de esvaziar o buffer neste post, continuei lendo e pesquisando sorbe o assunto. Pretendo formatar um modelo que funcione bem para as características específicas aqui da Myfreecomm. Nas leituras achei este post que responde exatamente as minhas perguntas.
Atualização em 06/08/09 – A questão não é a literatura sobre P.O. e Scrum Master em si, mas o que é vivenciado na prática. Algumas literaturas dizem que o P.O. deve ser o cliente, outras dizem que pode ser um representante dele e por aí vai. Minha idéia é tentar entender como isso funciona em alguns casos práticos. Realmente a pergunta no título ficou muito ruim, deveria ser: Como funciona pra você?
***
Este post é fruto de uma conversa que tive ontem sobre a necessidade de delimitar as responsabilidades de cada papel no SCRUM. Essa conversa vai de encontro com um ponto que queremos melhorar no processo desenvolvimento na Myfreecomm.
Geramos algumas dúvidas que eu não sei a resposta exata, mas pretendo respondê-las após alguns estudos e experimentos na prática. Se você tiver alguma resposta, deixe um comentário.
O P.O. é o cliente? Cliente e P.O. são as mesmas coisas? O P.O. tem que ser necessariamente o representante do cliente?
O P.O. precisa entender de software?
É papel do P.O.trazer o que ele quer já detalhado em forma de itens do software a ser desenvolvido ou é papel do Scrum Master entender a necessidade de negócio e traduzir em software?
Dado um cliente externo (ou interno off-site) não se faz necessário designar um “P.O. Interno” que seja um analista e que faça a ponte com o cliente?
O “P.O. Interno” pode ser o Scrum Master, dado o fato de que o Scrum Master entende de tecnologia e é um analista de sistema em geral?
É responsabilidade do Scrum Master definir o prazo real para o desenvolvimento e demonstrar ao P.O. no Sprint Planning ou é responsabilidade do P.O. ter o entendimento de desenvolvimento para criticar o prazo estipulado?
Qual a sua opinião?
Posts Relacionados:
Rafael, vou responder segundo minha visão e experiência. Vamos lá…
O P.O. é o cliente? É bom que seja, afinal o dinheiro está saindo do bolso dele e espera-se que, portanto, esteja altamente orientado a obter o melhor resultado pelo dinheiro investido (ROI oriented).
Cliente e P.O. são as mesmas coisas? Depende, mas a luz da resposta anterior, é de se esperar que sim. Se for, por exemplo, um projeto interno ou um software de “pacote”, é importante, acho recomendável que o P.O. seja alguém que conheça as necessidades de mercado (o nicho que o software a ser desenvolvido pretenda atender), o que relevante ou não em termos de funcionalidades, etc.
O P.O. tem que ser necessariamente o representante do cliente? Vide resposta anterior.
O P.O. precisa entender de software? É bom que sim, mas é mais importante que entenda do problema a ser resolvido pelo software.
Respondo as demais logo que tiver mais um tempinho.
http://www.scrumalliance.org/pages/scrum_roles
http://www.scrumalliance.org/pages/scrum_ceremonies
Isso lhe dá um bom overview sobre o assunto. Do mais, sugiro o livro do Ken Schwaber, Agile Project Management with Scrum.
Meus dois centavos:
Acho que mais importante do que a nomenclatura PO vs. Cliente, é ter como avaliador do resultado do sprint a mesma pessoa que priorizou as estórias ao inicio do sprint. Chame-o como quiser. A aceitação do que foi entregue ao final do sprint tem que ser feita pela mesma pessoa que concordou com o time quanto ao rumo que ia ser tomado lá no inicio do sprint.
(http://www.caikesouza.com/blog/2009/05/as-tres-perguntas/)
O Scrum Master entender de software pra mim é muito mais importante do que PO entender de software.
É papel de todos (PO + SM + developers) chegar a um consenso quanto aos requisitos. Uma frase que ouvi do Vinicius em uma de suas palestras e que eu nunca esqueço é que “o cliente pode não saber o que quer, mas sabe muito bem o que não quer”.
Quanto ao “PO Interno” fazendo uma ponte, não sei… mas acho que pode gerar algum ruído ou então cair no problema de um pedindo e outro cobrando.
Acredito que cabe a todos, principalmente ao time de desenvolvedores, construir as espectativas de entrega (nome bonito que eu inventei agora para “prazo”). As vezes, melhor do que tentar apertar o passo para entregar mais, é renegociar os requisitos para tentar entregar menos (http://www.caikesouza.com/blog/2009/05/dhh-e-o-segredo-para-a-alta-produtividade/)
Abracø!
Rafael, excelente post. Essas perguntas sempre estão presentes na cabeça da maioria das pessoas envolvidas com Scrum atualmente.
Vou passar a minha opinião, pela minha experiência e pelas dezenas de relatos e experiencias alheias que tive oportunidade de conhecer através dos livros, blogs e afins.
O PO é aquele responsável pelo ROI do produto. Ele precisar realizar todas as tarefas que estejam ao seu alcance para maximizar o ROI do produto. É disso o que se trata ser Product Owner.
Como ele irá fazer isso é o grande desafio que o PO tem pela frente. Se ele irá designar representantes para responder por ele, participar das reuniões ou definir requisitos, é problema dele. Mas não deveria. Em última análise, o sucesso ou fracasso do produto é de sua INTEIRA responsabilidade. Mas, naturalmente, ele poderá obter ajuda de outros profissionais. Se o produto for muito complexo, poderá criar uma equipe que irá ajudá-lo a criar o produto, incluindo desde especialistas em mercado, passando por profissionais de user experience, até mesmo analistas de requisitos que ajudem a equipe a escrever o backlog. O Scrum Master tem papel fundamental nesse processo, auxiliando o PO a criar o backlog e servindo como ponte entre o PO e a equipe de desenvolvedores quando necessário para especificar requisitos.
Não se define que alguém é o PO e aí se transfere a ele essa responsabilidade. É o contrário. A pergunta é: Quem é o responsável pelo sucesso do produto, pelo seu ROI? A resposta é o PO. Se ele quiser ter um representante ou não, é a forma que ele decidirá trabalhar e deve assumir os riscos da sua decisão.
A pergunta não define bem o que seria “entender” de software, mas certamente o PO precisa conhecer a fundo as capacidades da tecnologia. Não precisa ser um profissional da área, nunca ter programado (apesar de ajudar bastante), mas deve ter um profundo conhecimento das possibilidades que a tecnologia provê, estando sempre atualizado nesse sentido.
A pergunta sobre o prazo está um pouco ambígua. Pode ser sobre o prazo para desenvolver os itens de backlog ou o prazo para entregar um release. O prazo do release quem define é o PO. O prazo para desenvolver os itens de backlog – as estimativas – quem define é o time, e exclusivamente o time e mais ninguém.
Ninguém, repito ninguém, e principalmente o PO, deve jamais criticar as estimativas do time. Sempre que uma estimativa é criticada por ser grande, o time não terá o menor problema em diminuí-la de acordo com a “vontade” do crítico. O problema será na qualidade do código gerado, que precisará se adaptar ao prazo menor. Para bom entendedor meia pala ba…
Legal seu comentário José Leme.
Muito obrigado!