Tarefas técnicas possuem valor para o product owner?

9 de março de 2010

Na última turma de Agile e Scrum que ministrei, assim como nos diversos projetos que atuei desde 2005 com alguma metodologia ágil (xp, scrum ou lean), a questão das tarefas técnicas e seu valor para o cliente sempre apareçe.

Sonhando sobre o assunto, como de costume, encontrei uma resposta mais objetiva, menos subjetiva do que a abordagem tradicional, o clássico sim ou não.

O objetivo do PO

Como PO, o mais importante é a entrega de um produto que adicione valor ao que meu cliente utilizará, permitindo ganhar mercado contra meus concorrentes ou cobrar um valor mais alto pelo meu produto ou serviço.

Toda e qualquer história que não tenha como resultado final – direto ou indireto – aumentar o retorno do produto para minha empresa não possui valor.

E é esse o conceito objetivo que utilizamos na hora de aceitar e priorizar histórias técnicas: se ela não permite um retorno nesse instante ao meu produto, ela pode ser postergada.

Visto o último post que indica a importância da priorização adequada em relação ao retorno ganho, a execução de histórias técnicas sem retorno ao negócio poderiam atrasar ainda mais o sucesso do último.

Exemplo 1: Requisitos não funcionais

Quando tratamos de requisitos não funcionais, como por exemplo escalabilidade, foque em objetivos claros. Exemplificando, se os seus desenvolvedores indicam a necessidade de migrar seu banco de dados relacional para uma estrutura baseada em documentos pois o mesmo “agüenta mais usuários”, peça uma meta mais objetiva.

Primeiramente, a necessidade de atender mais usuários deve surgir de seus clientes, reclamando por mais performance em picos de uso, ou de você mesmo – prevendo um aumento de seus clientes em uma futura propraganda do sistema, por exemplo.

Supondo que o pedido surgiu de uma necessidade do produto, agora está na hora dos desenvolvedores criarem um spike – uma experiência para medir o possível sucesso de tal abordagem – e então retornarem com uma média esperada de melhora na escalabilidade do sistema (ou em outro requisito não funcional qualquer).

Tanto o spike, quanto a execução da tarefa técnica, com uma avaliação objetiva de seu sucesso (i.e. atender a X page views por segundo, respondendo em menos de 5 segundos), são histórias para seu backlog, pois ambas agregam valor a seu produto: se você não executá-las, seus possíveis e atuais clientes migrarão para os concorrentes.

Exemplo 2: Outras histórias técnicas

Por vezes as histórias técnicas que surgem não estão ligadas a requisitos não funcionais. Um exemplo é a instalação de um servidor de homologação e processo de homologação e deploy contínuo no estilo devops, fugindo do estilo tradicional, menos ágil, de operações. O que fazer?

Novamente, a equipe de desenvolvimento deve mostrar para o PO que tal história possui valor, e o PO priorizar de acordo com o valor mostrado.

O argumento a ser utilizado, no exemplo acima, estaria relacionado a velocidade de entrega de valor. Se a média dos últimos sprints tem sido de 20 pontos devido a bugs que são encontrados somente em produção, pois a máquina dos devs e de homologação está muito diferente das configurações reais, deixe claro que essa média poderá aumentar, uma vez que os bugs invalidadores de história serão encontrados antes e, com o passar dos sprints, X pontos que são utilizados agora para implementar tal processo serão retornados.

Existe valor na história técnica?

Em suma, histórias técnicas podem entrar no Backlog de maneira benéfica para seu produto, mas não se deve aceitar qualquer história. Ela deve ser julgada e priorizada de acordo com o valor que a mesma agrega ao seu negócio, e é responsabilidade dos desenvolvedores – seus clientes técnicos – mostrarem tal valor para o PO.

É importante ressaltar que qualquer tipo de debito técnico grande pode ser explicado de uma maneira que adicione valor ao produto, pois diminui a velocidade de entrega de retorno. Mas se o débito for muito pequeno, ele pode ser executado dentro do sprint, no dia a dia.

Exemplo 3: E na Caelum?

Em projetos internos da Caelum, temos uma preocupação que é incomum as empresas de desenvolvimento. A transferência de conhecimento entre instrutores e consultores tem que ser realçada, assim como o estudo de novas tecnologias e práticas de desenvolvimento.

Sendo assim, histórias envolvendo o aprendizado entregam valor direto para nosso negócio e acabamos por aceitá-las ou até mesmo colocá-las dentro do backlog.

Não se isole do resto de sua equipe

Os dois lados, PO priorizando valor, e desenvolvedores que priorizam qualidade, devem ser capazes de entender a necessidade do outro: não existe equipe auto gerenciável onde PO e desenvolvedores são inimigos, ambos fazem parte da mesma equipe.

PO, você anda colocando histórias de qualidade, spikes etc em seu backlog?

E você desenvolvedor, anda deixando claro para seu PO o retorno que o mesmo obtém ao priorizar tais tarefas e o comprometimento com um resultado objetivo?

Anúncios

8 Respostas to “Tarefas técnicas possuem valor para o product owner?”

  1. Alex Hubner Says:

    Guilherme, e no que diz respeito à velocidade da equipe? Devemos considerar pontos para bugs e tarefas/atividades técnicas?

  2. Washington Botelho Says:

    Tarefas técnicas como a própria integração contínua realmente agrega muito valor, já que o retrabalho sera reduzido.

    Troca de conhecimentos acaba rolando nas pair programming, assim como em horários de estudos dedicados, e isso traz muitos benefícios à equipe como um todo.

    Parabéns pelo tópico.

  3. guilhermesilveira Says:

    @Washington, concordo plenamente. O tempo de estudo por exemplo, pode ser facilmente avaliado como um desentupimento do problema que vai ocorrer a frente, quando for crucial a utilização da tecnologia nova.

    @Alex, quando uso o termo “histórias técnicas”, acredito que o PO julgou-a como valorosa para o produto, portanto faz sentido pontuá-la.
    A abordagem do bug ser pontuado e/ou trazer valor também é complexa, em resumo não existe regra geral: os dois lados da discussão estão certos, bugs deveriam ser minimizados e bugs diminuem a velocidade da equipe, portanto deviam e não deviam ser contados, dependendo do seu objetivo. Vou escrever um post mais longo em breve sobre esse assunto do workshop.

    Abraço!

  4. David Paniz Says:

    Ótimo post Gui, só acho importante lembrar que, na maior parte dos casos, se temos um débito técnico grande o suficiente para entrar como história é porque alguma coisa bem errada aconteceu durante o desenvolvimento nos sprints anteriores.

  5. guilhermesilveira Says:

    Bom ponto @Paniz, verdade.

    Um débito técnico grande pode surgir por uma decisão ruim ou uma mudança na realidade do produto.

    A escolha uma tecnologia ruim para o produto ou a falta de testes pela pressa é uma decisão ruim que deve ser revertida para não continuar acontecendo.

    O aumento na demanda e a necessidade de escalar pode ser algo que só surja 5 anos depois, e fugindo do Big-Design-Up-Front, só nos preocupariamos daqui 4 anos e uns bons meses.

    Abraço!


  6. […] RSS Feed: agile « Tarefas técnicas possuem valor para o product owner? […]


  7. Fiquei preocupado pela forma como a questão da escalabilidade foi abordada. Uma situação bem corriqueira é o PO não se preocupar, primeiramente, com isso e, posteriormente, acusar a qualidade da aplicação como responsável.

    Mas o exemplo 3, me tranquilizou:
    “Em projetos internos da Caelum, temos uma preocupação que é incomum as empresas de desenvolvimento. A transferência de conhecimento entre instrutores e consultores tem que ser realçada, assim como o estudo de novas tecnologias e práticas de desenvolvimento.

    Sendo assim, histórias envolvendo o aprendizado entregam valor direto para nosso negócio e acabamos por aceitá-las ou até mesmo colocá-las dentro do backlog.”

  8. guilhermesilveira Says:

    Pois é, o começo mostra uma abordagem, o exemplo 3 outra.. todas são válidas, e depende da empresa e de seus objetivos.

    Abraço


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: