28 outubro 2008

Falando em Agile: Antonio Carlos Silveira

Antonio Carlos Silveira, um dos mais novos gerentes do Yahoo! Brasil, apresentou uma palestra com o tema O Product Owner e o Product Backlog. Pra variar, ele também é um dos caras que já trabalhou na Globo.com, e que ajudou a empresa a utilizar Scrum, tornando-se o maior case de utilização no Brasil. Minha impressão: a melhor palestra do evento

Tudo começa com uma brincadeira muito boa. No dia anterior, o Guilherme Chapiewski apresentou um pouco da atuação dos líderes Ágeis na Globo.com e é claro, mantendo a imagem de uma empresa massa pra caramba!(Foi muito massa a palestra, logo escrevo um pouco sobre ela).

Mas, mantendo seu compromisso principal com a verdade, o Antonio Carlos mostrou como é realmente o trabalho na Globo.com: A competitividade é acirrada!!

A intenção da apresentação era realmente esclarecer o conceito de Product Owner, e o artefato Product Backlog do Scrum. O nome em si não importa, mas os princípios por trás dos papéis e dos artefatos.

Alegoria interessante:

Uma equipe Scrum é formada por:

  • Darth Vader - Scrum Master - O protetor do processo
  • Stormtrooper Crew - Equipe - Responsável pela qualidade
  • Indiana Jones - Product Owner - Vem de uma cultura de chicotada (normalmente um Product Manager)

Tradicionalismo x Agilidade - De onde viemos e Para onde vamos

Carrasco - O Gerente Tradicional Tradicionalmente, principal missão de um Product Manager era se antever e prever futuro. Mas Por quê? A fórmula é simples:
  • Se antecipar aos acontecimentos de um projeto pode reduzir incertezas
  • Reduzindo incertezas provavelmente diminuirá a quantidade de Change Requests
  • Como Change Requests são caras, reduzir sua ocorrência certamente diminuirá o custo do projeto
Surge a figura de um Product Manager carrasco, que não se importa com a saúde das equipes que trabalham para ele, e está mais preocupado a cumprir um cronograma custa o que custar.

Não existe, neste ambiente, uma preocupação em adaptar-se à mudança, mas em restringir a mudança. Antecipar-se é o principal foco deste modelo, mesmo que o nosso mundo esteja seguindo na direção contrária. AC atribuí a isso uma espiral negativa dentro das empresas: setores de tecnologia querendo restringir mudanças devido aos custos elevados, e os setores de marketing buscando adaptar os produtos aos mercados.

Este é o principal motivador para o crescimento de métodos Ágeis. Assim, o que queremos é a agir rapidamente a qualquer Request de mudança. Ao invés de criar procedimentos para restringir mudanças, precisamos abraçar as mudanças adaptando-se o mais rápido possível.

O Product Owner

O papel do PO primeiro de tudo é: Ele precisa entender o Cliente Ele precisa responder às seguintes perguntas:

  • Qual o seu Target ?
  • Quem é o seu público alvo?
  • Quais são as personas? (dica do Danilo Bardusco)
  • Quem se quer atingir?
  • Por que um cliente gastaria dinheiro com o seu produto?

Além disso também, o cliente é uma Ponte entre os Clientes e o Time, inclusive na hora de buscar mais informações quando seu conhecimento do domínio do problema não é completamente compreendida. Assim, ele facilita o contato entre o Business e o Desenvolvimento.

Existe sempre uma tenção entre este PO e a equipe. Em métodos Ágeis, TUDO é baseado em confiança. E qual o paradoxo desta realidade: estamos num mundo em que confiamos muito poucos uns nos outros, e desenvolvimento Ágil para funcionar precisa muito de confiança.

Espiral negativa da vez:

  • PO não confia no time, porque normalmente não recebe o que solicita. Assim, o que ele faz? Atola a equipe de solicitações, na esperança de ganhar alguma coisa "do balaio"
  • A equipe sabe que o PO vai pedir mais do que eles conseguem produzir. Como sair dessa? Estimar cada vez mais tempo para completar as tarefas...

É isso que precisa ser mudado para que um ambiente ágil seja produtivo. Transparência é a palavra de um projeto Ágil. Inclusive, para que se entenda melhor essa alegoria. Imagine um projeto scrum como um barco: Se ele afundar, vai todo mundo pro buraco.

  • O PO pode ser técnico? Não necessariamente. Primeiramente, o PO precisa entender a equipe: sua capacidade de produção. Precisa entender que não é apenas empurrando trabalho para a equipe que mais software vai ser entregue. O Danilo Bardusco já escreveu sobre isso.

É necessário criar um ciclo virtuoso em que:

  • O PO entender as necessidades de esclarescimento da equipe.
  • Estimula a equipe no limite, para que ela consiga se comprometer e produzir o melhor produto. Tendo orgulho do que faz.
  • Sabe que um número, que a preocupação apenas com produtividade não trará o resultado esperado.
  • Trás um ponto de vista para a equipe que agregue valor para a equipe

PO: Cria a Visão

Uma visão compartilhada gera comprometimento O PO precisa pintar uma imagem bonita, para onde todos da equipe queiram seguir. Dois exemplos foram citados: Disney e Mirosoft. A primeira empresa cria uma Visão única, que guia todos da empresa, e é um dos motivadores de seu sucesso:
We create happiness by providing the finest in entrertainment for people of all ages, everywhere

Na criação desta Visão, o Product Owner deve estar preocupado em conquistar a equipe como um todo. E para isso a visão deve ser:

  • Compartilhada e compreendida por todos
  • Deve criar o desejo na equipe em fazer parte desta conquista
  • Deve ser clara e concreta
  • Deve ser difícil de ser alcançada, mas não impossível

Você é o product owner de um projeto? Qual a visão do seu software? e a equipe, entende essa visão?

PO: Entende o domínio do Problema e da Solução

Deve ser a referência sobre o Domínio do problema. Ele deve ser o ponto focal para a equipe, quando ela estiver em dúvida. E pra isso ele deve ter poder de decisão.

Receita para o fracasso:

Um product Owner que nunca decidiu nada. Criando a "Síndrome para o PO Mensageiro": Se para tomar qualquer decisão o PO precisa se comunicar com alguém para pedir a opinião, o problema está formado. Quais as consequências disso?

  • Equipe vai desconsiderar o papel do PO, indo diretamente à pessoa que decide.
  • O Time passa a tomar decisões. Se sentindo no direito de tomar as próprias decisões sobre o produto.

É necessário que o PO imponha respeito à equipe. Tudo que está sendo dito aqui é sobre pessoas, e a interação entre elas. Esqueça ferramentas! O que importa é a relação entre esse as pessoas, a maneira como você interage com elas. Comunicação Oral é o principal! Lembre-se disso: ferramentas não vão substituir o sucesso da interação pessoal entre as pessoas. (Repetitivo? náá)

Além disso, é obrigação do PO aceitar o que for produzido pela equipe. Para isso:

  • Deve estar presente para esclarecer dúvidas (deve estar próximo)
  • Deve avaliar o que for produzido

Aqui, o AC indica um estudo bastante interessante: A universidade de Michigan descobriu (há quase 10 anos), que equipes multiciplinares juntas produzem mais que o dobro do que equipes separadas por salas, predios, etc. external Leia a notícia

Nota importante: é o PO que organiza o Release Plan para o produto. Ele que encontrará o melhor momento para lançar uma versão nova do produto.

PO: Responsável pelo ROI

Sim!!! Retorno sobre investimento!

É o foco do PO! Normalmente relacionado a dinheiro. Mas não necessariamente o dinheiro em si. Acima de tudo, ROI deve estar ligado a um objetivo mensurável:

  • Dinheiro
  • Audiência
  • Satisfação do Cliente
  • Fidelidade

PO: Responsável pelo Product Backlog

Resumindo o que apresentamos acima: O Product Owner tem como função?

  • Entender o Cliente
  • É o elo de comunicação entre os Clientes e a Equipe
  • Entender do domínio do problema e principalmente possui o poder de decisão sobre o projeto
  • Aprova/Rejeita o resultado do Sprint
  • Responsável pelo Release Plan
  • Responsável pelo ROI
  • Responsável pelo Product Backlog

Lembrando que: Product Backlog é uma lista priorizada (em qualquer mídia) e ordenada com coisas que trarão algum benefício para o usuário.

Como descrever itens do backlog? User Stories!

AC ainda explicou sobre a profundidade na elaboração do Product Backlog, já explicado na apresentação: 10 ways to screw up with Scrum and XP. (Numa imagem muito bonita: 3D, tons pastéis, Estrelinha e um "r" no logo!)

O que define um bom Product Backlog?

  • Está Planejado adequadamente para os próximos 3 Sprints, ajudando o time a ter uma visão maior sobre para onde estão indo.
  • Sempre priorizado. Para que a equipe consiga escolher sempre o item mais prioritário
  • Sempre visível: Isso trás transparência
  • Deve ser mantido pelo Produtc Owner (não é função da equipe priorizar o Backlog)

Priorização

Foram citados os modelos de priorização:

  • Kano Model
  • Benefício Relativo
  • Modelos Financeiros
    • VPL
    • TIR
    • Payback

Principal Bibliografia Ágil sobre o assunto: Agile Estimating and Planning por Mike Cohn

No Modelo de Kano, deve-se categorizar o product backlog através do valor percebido pelo cliente. Em três categorias:

  • Must-have: Obrigatórios (Um hotel deve ter cama)
  • Linear: Quanto mais melhor (Cerveja grátis no quarto do hotel - ótimo )
  • Exciters: Necessidades não conhecidas (TV de LCD 42'' no Quarto - ótimo, mas não faz tanta diferença)

Para cada item do Backlog, faça duas perguntas:

  • Funcional: O que vc acha de ter uma Latinha de cerveja de graça no quarto de hotel, quando vc chegar?
  • Disfuncional: Se você chegar num hotel e não tiver uma latinha de cerveja de graça no quarto, o que vc acha?

No método de Benefício Relativo é necessário, primeiramente, que as estórias estejam estimadas. Após isso, preencha a seguinte tabela:


Benefício em ter Penalidades em não ter SUM(BV) Estimativa BV/Est
Funcionalidade 1 1 9 10 2 5
Funcionalidade 2




Funcionalidade 3




Funcionalidade 4




A Ordenação se dá pela coluna BV/EST

Mesmo sendo um método bastante interessante, em sua experiência, Antonio acredita que no final é o chutão que conta. A Utilização de personas pode ajudar bastante.

É isso... Esses relatórios estão ficando bastante extensos... mas espero ter passado a idéia da apresentação... aos que não assistiram...

Antonio: Parabéns pela apresentação!

(Acompanhe as impressões dele sobre o evento, além inúmeras referências)

Tomei a liberdade de adicionar neste blog os slides da apresentação (sem autorização, desculpe!). Aproveite:


3 comentários:

  1. Olá Victor,

    impressionante, nem eu lembrava que tinha falado sobre tudo isso.

    É quase uma transcrição :-)

    Fico feliz que vc tenha gostado, e pode sim colocar a Apresentação onde vc quiser, por isso a coloquei no Slideshare.

    abs,

    Antonio

    ResponderExcluir
  2. Obrigado Antonio!
    Fico feliz que tenha gostado!!

    A coisa aqui é assim: anotações monstruosas, para não perder nenhuma parte da apresentação. Afinal, tenho que repassar isso tudo por aqui....

    ResponderExcluir
  3. Aliás... foi por causa da sua apresentação, Antonio, que resolvi mudar o Blog A Maldita Comédia..... agora tem:

    * Piadinhas toscas

    * Tons pastéis

    * Cantos arredondados

    * Imagens bonitas e engraçadinhas

    * Fazendo propagandas bem humoradas em listas de discussão

    =)
    =)

    ResponderExcluir