Papo de Corredor

junho 29, 2010

Resumo do Curso CSPO – Primeiro dia

Filed under: eventos,motivacional,scrum — Alan Rafael R. Batista @ 12:19 am
Tags: , , , ,

Já faz algum tempo que não publico nada aqui no meu blog, bem acho que inicialmente preciso compartilhar a minha felicidade de estar já a três meses na Locaweb, que além de uma empresa competitiva no ramo de serviços de internet (Líder na prestação de serviços hospedados de TI), também é um excelente lugar para trabalhar.

Entre os vários benefícios e atrativos que a empresa oferece, tais como um excelente ambiente de trabalho, desafios constantes e etc., ela também investe pesado em treinamento e aprecia ter pessoas ligadas a comunidade de software no seu quadro de colaboradores.

Nesse espírito de investir nos seus funcionários a Locaweb custeou a ida de algumas pessoas para o Agile Brazil 2010 em Porto Alegre e além disso possibilitou que algumas pessoas fizessem alguns cursos e é aí que eu entro, eu fui um dos premiados a fazer o curso do CSPO (Certified Scrum Product Owner)!

Inicio do curso CSPO

O curso foi excelente, ministrado pelo Alexandre Magno com o parceria do Luiz C. Parzianello, apesar de o formato do curso com dois “Mestres de Cerimônia” não tenha ficado tão bom quanto o esperado, a integração dos assuntos abordados pelos dois foi excelente!

Para saber mais informações de como foi o dia a dia do curso, recomendo a leitura do post de um amigo que fiz lá o André Nascimento e de meu amigo locaweber Rafael Rosa Fu.

A partir de agora vou repassar um pouco do resumo que fui fazendo ao longo do curso, espero que aproveitem!

  • PO – todas as empresas tem problemas com esse papel do Scrum.
  • Uma das primeiras frases do Alexandre Magno no curso foi que o papel do PO é um papel que merece mais atenção nas empresas pois ainda muita falta de experiência para executá-lo.

  • No início havia muito foco no papel do time.
  • Focava-se muito esforços no papel do time (Integrantes do time + Scrum Master) e agora é o momento de focar-se mais no papel do PO.

  • Nada adianta um bom time se o produto está sendo desenvolvido errado.
  • Aqui o recado é que não adianta ter ótimos técnicos no seu time e um Scrum Master excelente em facilitação, se o produto desenvolvido não estiver focado nas necessidades do cliente.

  • Pouco adianta práticas de engenharia para o produto errado.
  • Vale o mesmo recado da sentença anterior, TDD, Pair Programming, Continuos Integration pouco terão valor se o produto está errado no aspecto de negócio.

  • Devemos focar mais esforço no negócio.
  • Nossos esforços devem estar mais direcionado a atender as necessidades de negócio.

  • Pouco material técnico e mais práticas para deixar as pessoas mais focadas (curso).
  • Aqui foi uma frase que me chamou atenção, onde o Alexandre Magno deixou claro que o foco dele seria nas práticas e não em apostilinhas!

Excelentes Discussoes

  • Discussão do gerente de produto na (sua) empresa. Quais são as atribuições do Gerente Produto?
  • Neste momento tivemos uma excelente discussão de qual seria o papel do Gerente de Produtos, se quiser saber a conclusão faça o curso 😉 !

  • Onde o GP e o PO se encontram (papéis)?
  • Outra excelente discussão, onde falamos muito sobre a intersecção do papel do PO e do cargo Gerentes de Produtos.

  • Scrum foi pensado para projetos e não para empresas.
  • O Magno deu um recado que apesar de muito claro, tem muita gente que ainda não compreende que é o Scrum foi pensado para projetos e não para gestão de empresas! Ele foi bastante enfático nesse momento.

  • PO é um papel do projeto e não da empresa… o GP é um cargo na empresa.
  • Mais um recado muito claro do Magno, o PO é um papel e o gerente de Produtos é (deveria ser) um cargo na empresa.

  • A necessidade de um PO inicia quando o projeto inicia, não antes!
  • Não deveria ter PO eternos na empresa, a necessidade de um PO inicia quando o projeto inicia e não antes!

  • Se não há projeto, não há Product Owner.
  • Resumindo: “Se não há projeto, não deveria haver Product Owner!”

  • Time de alto desempenho as vezes não entregam valor por causa do PO ruim.
  • Um cruzado de direita do Magno, mesmo tendo um time de alto desempenho é muito provável não entregar nada de valor caso o PO for muito ruim.

  • No mundo perfeito, todo PO será do cliente.
  • O ideal seria que o PO sempre fosse do cliente, ou seja, muito ligado ao produto, mas nem sempre isso é possível.

  • De nada adianta um PO do cliente se ele não priorizar, ou priorizar mal.
  • Porém de nada adianta um PO do cliente se ele não for hábil para priorizar ou na pior das hipóteses priorizar mal.

  • Mais difícil é encontrar lideres com objetivos do que times auto gerenciados.
  • Esta sentença para mim está muito ligada ao que o Magno disse no início do curso, muito foi focado no time, agora é muito mais fácil encontrar times auto-gerenciados do que lideres com objetivos bem definidos.

  • O comum é lideres com time sheeting do que com objetivos claros.
  • Em muitas empresas que se auto denominam “Ágeis”, na verdade é comum encontrar liderem com um o gráfico de gantt e planilhinha de horas!

  • PO deve ter um cuidado com o product backlog.
  • O product backlog deve ser um filho para o PO, que deve cuidar, proteger, defender :)!

  • PO desenvolve a visão do produto e os passos para atingir o objetivo da visão.
  • A tão falada visão do produto deve ser desenvolvida pelo PO assim como os passos para atingir o objetivo determinado na visão.

  • O macro management fica na mão do PO.
  • O macro management fica a cargo do PO, verificando as features e os releases numa perspectiva macro para atingir o objetivo do produto.

  • O passos para atingir o objetivos das estórias (micro management) fica a cargo do time.
  • Já o micro management fica com o time, ou seja, os passos (tarefas) para atingir o objetivo da sprint.

  • O PO tem que realmente ser um porco do projeto (é difícil ser porco em dois projetos).
  • O recado aqui é que é difícil dar o sangue (couro no caso do porco, :D) em mais de um projeto, o PO sempre tem que se perguntar se será capaz de focar no projeto antes de ingressar nele.

  • Scrum é incompleto e não precisa somente de práticas de engenharia, existem outro pontos (análise de risco, controle).
  • Aqui um recado do Parzianello, todos sabemos que o Scrum é incompleto, mas não é somente pela falta de práticas de engenharia, na verdade também lhe falta análise de risco e outras disciplinas ligadas ao negócio.

  • Scrum é controle! (reunião diária, review, definition of done).
  • Apesar de soar muito estranho, mas Scrum é controle! Reunião diária, Review, Definition of Done, são provas que há sim, muito controle no Scrum, o que não tem é Comando!

  • É interessante o time ter um integrante como Scrum Master exclusivo.
  • Sempre que possível é interessante ter um protetor do Scrum e do time, esse papel responde pelo nome de Scrum Master, mas claro, se o time for maduro a ponto de achar interessante que esse papel possa ser executado por um integrante do time não há problemas.

  • Quais são os seus valores?
  • Aqui mais uma discussão aberta pelo Magno: Qual são seu valores? O que realmente importa para você?

  • Dá para estimar o valor e o tempo com práticas ágeis?
  • Mais uma discussão sobre a possibilidade de se fazer estimativas de valor e de prazo com práticas ágeis, mas com certeza deverá haver uma quebra de paradigmas de quem for fazer a estimativa, bem como de quem for recebê-la.

  • Product roadmap com práticas ágeis tem que quebrar paradigmas.
  • Ainda relacionado com a sentença anterior, deve-se quebrar paradigmas para se executar, receber e interpretar um product roadmap com práticas ágeis, caso contrário será difícil ter sucesso no projeto.

  • Todo o ambiente de projeto deveria entender o que é Scrum para ter sucesso (principalmente patrocinadores e clientes!).
  • Essa é mais uma sentença auto explicativa, para ter sucesso todo mundo tem que compreender o Scrum!

  • Premissa para o PO: você realmente tem disponibilidade para esse papel?
  • Ou seja, ou você estará disponível, envolvido ao projeto, caso contrário esse papel de PO NÃO é para você. Simples assim!

Agenda do PO

  • Atribuições do PO
  • Definir a visão (com workshops etc.)
    Manter o product backlog
    Maximizar o ROI
    Gerenciar, planejar release
    Define as metas
    Leva as informações do projeto para fora (divulgar o projeto)
    Gerenciar conflitos de cliente, prioridades
    Fazer gerenciamento macro
    Bastante coisa, não?

  • Meta: ou atingiu ou não atingiu!
  • Simples, atingiu a meta ou não atingiu a meta, não existe meia meta!

  • PO sem poder de decisão ou com baixa disponibilidade ou que não foi preparado para exercer o papel.
  • Com um PO nessas condições será praticamente impossível ter um projeto de sucesso, ou se mitiga esses riscos ou é melhor nem iniciar o projeto.

  • PO deve estar próximo no momento de quebrar tarefas.
  • E muito importante o PO estar próximo (sempre que possível) quando se for quebrar as tarefas, para auxiliar o time, para que essa atividade tenha o máximo de precisão possível.

  • QA junto com PO para descobrir estórias e definir critérios de aceitação.
  • Outra dica do Magno, ter o QA próximo do PO no momento de descoberta de estórias e na definição dos critérios de aceitação.

  • A cada review deve ser apresentado o que foi gerado para entregar aquele release!
  • Esse foi um soco de esquerda, a cada review o time deve apresentar o que foi gerado para entregar aquele release, mas também é importante que o PO tenha em mãos tudo para o próximo release que será desenvolvido.

  • Retrabalho nível 2 – problemas intrínsecos do projeto nível 1
  • Aqui eu não me lembro, assim que eu lembrar atualizo aqui (poxa, o curso era de manhã!)

  • Prestar atenção e conhecer Lean!
  • Apesar de neste momento o Magno e o Parzianello estarem falando de Lean, fica a dica de também prestarem atenção ao Kanban.

  • Proteger receita e diminuir custo.
  • Aqui uma dica no Parzianello que fez a diferença, nós sempre pensamos no produto para aumentar as receitas ou lucros, mas muitas vezes poderíamos estar focados em proteger a receita atual e diminuir o custo. Esta discussão iniciou quando eu trouxe um problema enfrentado pelo meu time, sobre como eliminar o legado e entregar valor, nós não conseguíamos ver a possibilidade disso, mas na verdade o que nós queriamos era proteger a receita da empresa (manter os produtos atuais) porém diminuir o custo (software funcionando, manuteníveis, extensíveis com o mínimo possível de bugs), resumindo entregando valor sim!

  • As vezes não é debito técnico, mas sim melhoria tecnológica.
  • Ainda na discussão anterior, as vezes não podemos encarar tudo como débito técnico, mas sim melhoria tecnológica que na verdade também é entrega de valor.

  • Técnica Elevator Statement para definir a visão do produto.
  • Aqui fizemos uma excelente dinâmica para definir uma declaração que define a visão do produto, mais informações no curso.

Product Vision Box

  • Desenvolver o product vision box.
  • Outra dinâmica show, foi o desenvolvimento do product vision box, o melhor, além da técnica e a explicação do Magno é claro, foi a integração com as outra pessoas que estavam fazendo o curso conosco. Foi um momento super descontraído e divertido!

E assim terminamos o primeiro dia do CSPO e agora fico devendo o segundo post, até lá!

Anúncios

2 Comentários »

  1. Fala man!

    Achei legal o formato do post. Apesar de longo, ficou com uma leitura fácil e agradável. Serve tanto como um guia de referencia dos assuntos abordados no curso para quem participou como também para dar uma noção legal do conteúdo para quem não pode comparecer!

    Abraço!
    -LeoLuz-

    Comentário por LeoLuz — junho 29, 2010 @ 2:41 pm | Responder

  2. […] dica de leitura é o review que o Alan, também da Locaweb, fez do curso de CSPO que ele fez na prévia da conferência. […]

    Pingback por Como vi Scrum ser completamente rechaçado em uma grande empresa | CØdeZØne! — junho 29, 2010 @ 6:24 pm | Responder


RSS feed for comments on this post. TrackBack URI

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

Blog no WordPress.com.

%d blogueiros gostam disto: