Rails Summit, eu vou 26/09/2008
Por: Bruno Mentges de Carvalho , 1 comentarioDias 15 e 16 de outubro estarei em São Paulo para prestigiar o evento Rails Summit. Vou com o Guilherme Chapiewski e espero encontrar todo mundo lá. O evento vai contar com palestras de desenvolvedores importantes como David Chelimsky, Chad Fowler, Jay Fields, Carlos Vilella, Os koreanos da Phusion (<3 passenger), Charles Nutter, Danilo Sato, Fabio Kung e Obie Fernandez.
Nos vemos lá.
Criando um Product Backlog, parte 1 14/09/2008
Por: Bruno Mentges de Carvalho , 1 comentarioRecentemente um dos nossos clientes internos na globo.com pediu para que nós os ajudássemos a elaborar um product backlog para uma nova versão de seu produto. Eu representando o lado técnico, um product owner, um arquiteto da informação e um designer fomos escolhidos para tal atividade.
Product backlog é um documento de alto nível do projeto. Nele é contido todas as features, wish-lists, etc. que o cliente deseja para o sistema descritas de uma maneira bem abrangente e na linguagem do cliente, que chamamos de “histórias”. Cada história contém também uma estimativa de complexidade e o valor de negócio da mesma para o cliente, para facilitar na priorização.
Um exemplo de uma história é o seguinte: “Para poder ter uma experiência melhor assistindo um vídeo, eu como usuário gostaria de poder assistir o vídeo em tela cheia“.
A primeira etapa foi marcar uma reunião com os envolvidos para ouvir deles o que eles tem hoje, o que os atrapalha, e o que eles querem para resolver seus problemas. Do ponto de vista técnico, que é o que vos apresento, o maior desafio é se ater ao “O QUÊ” ao invés do “COMO”. Ouvir o que eles querem fazer, o que eles precisam, o que os atrapalha, etc. Por vezes me peguei com vontade de perguntar se queriam isso dessa ou daquela forma, e precisei me conter para não tirar o foco da reunião.
Depois dessa reunião nós tivemos uma visão mais clara da necessidade de nossos futuros clientes e resolvemos reunir o time e conversar a respeito, visto que serão eles (e eu) que iremos desenvolver o produto. Essa reunião foi muito produtiva pois levantou diversos pontos que ainda precisavam ser trabalhados.
Já aí temos alguns pontos desse nosso processo:
1. Se reunir com o time do cliente e o cliente e ouvir deles os “o quês”
2. Se reunir com o seu time e discutir os pontos levantados
3. Marcar uma reunião com o cliente e o time do cliente para dar este primeiro feedback.
Como podemos ver, a presença do cliente é fundamental. E esse ciclo de reuniões já produz um primeiro feedback. Tivemos uma nova reunião para passar o feedback e atacar os pontos levantados. Tudo isso foi feito em menos de uma semana, o que é o mote das práticas ágeis: ciclos curtos de feedback.
A partir destes 3 pontos já é possível rascunhar um primeiro product backlog. E, como seguimos o scrum e práticas ágeis, isso não é nenhum problema, pois o product backlog é aberto e modificável.
Essa foi a parte 1 do processo de criação do product backlog. Em breve estarei escrevendo o próximo da série, enquanto avançamos com a criação product backlog.
