Feeds:
Posts
Comentários

Posts Tagged ‘user story’

Desde semana passada estou trabalhando com uma empresa aqui da região para implantar desenvolvimento ágil no ambiente deles.

A empresa é pequena, atualmente são 4 (3 desenvolvedores) pessoas trabalhando internamente e outras 2 pessoas (designer e alguém que irá produzir os wireframes de um projeto) trabalhando externamente.

Atualmente a empresa desenvolve alguns sites e está iniciando um grande projeto (não posso comentar o que é eses projeto) e o dono da empresa veio conversar comigo, pois estava iniciando esse novo projeto e gostaria de aplicar desenvolvimento ágil desde o início.

Na semana passada eu apresentei a parte teórica do desenvolvimento ágil. Comecei com aquela introdução tradicional/histórica sobre o início com o sistema Toyota e processos empíricos. Falei do Agile Manifesto, falei várias vezes para eles se preocuparem com os valores e princípios, não as práticas. Continuei falando sobre princípios, agora os princípios do Lean, esses eu sugeri que eles imprimissem e colassem na parede da empresa.

Depois fui para o Scrum. Na verdade a parte de Scrum foi bastante sucinta, algo em torno de 2 horas. Expliquei os conceitos do Scrum, novamente sempre explicando que todas aquelas práticas tem um motivo para existir. Seguir somente as práticas é estar destinado a não alcançar os melhores resultados.

Nesta semana, na segunda-feira expliquei pra eles como funcionam as estimativas. Novamente comecei com uma introdução teórica de um pouco mais de 1 hora, onde falei sobre como estimar por tamanho, ao invéz da tradicional estimativa por tempo, o que é uma user story, estimativas em dias ideais, estimativas por pontos (story points), planning poker entre outros.

Assim que terminei essa explicação teórica partimos para a prática. O dono da empresa é o cliente (product owner), ele é quem tem a idéia do projeto principal. Quanto aos outros projetos (quase todos sites) ele é  quem conversa com o cliente e então toma a decisão sobre o que desenvolver na próxima iteração. Então a primeira tarefa foi gastar algum tempo escrevendo uma boa quantidade user stories.

Começamos escrevendo as user stories em um nível mais alto (epics) para o projeto principal, que ainda é somente uma idéia. Depois disso, ele decidiu qual user story ele gostaria de desenvolver primeiro e quebramos ela em user stories menores. Para os demais projetos (todos já existentes) escrevemos as demais user stories. Quando terminamos nós já tinhamos um product backlog.

O próximo passo foi fazer as estimativas. Convresei com eles e acertamos que iríamos utilizar story points para estimarem as user stories e dias ideias (horas, na verdade) para estimarem as tarefas. Então começamos identificando qual seria a user story com 1 ponto, que será utilizada como base para estimar as outras. Tendo identificado essa user story estimamos várias outras (utilizando planning poker), mas não todas, somente as que teriam chances de serem desenvolvidas nas próximas 3~4 semanas.

Durante o planning poker, houve somente uma situação interessante. Uma user story envolvia desenvolver algo bastante diferente, que nenhum dos desenvolvedores tem experiência ou poderia dar maiores informações de como desenvolver. Eles não tinham idéia do quanto de trabalho seria necessário para resolver aquele problema. Então conversei com eles e disse pra não estimarem esssa user story. Uma melhor solução será alocar algum tempo durante a próxima iteração e realizar um spike sobre esse problema, assim na outra reunião de planejamento (reunião para a 2ª iteração) eles vão poder estimar essa user story.

Devidamente estimadas, novamente o dono (que faz o papel do cliente/product owner) foi chamado para organizar o product backlog por ordem de importância, agora sabendo as estimativas de cada user story ele organizou a lista da maior para menor prioridade – da user story com maior valor para a user story com menor valor.

Antes de começarmos o planejamento da iteração, decidimos utilizar uma iteração (sprint) de 1 semana. É comum os clientes dessa empresa aparecerem com pedidos para um futuro bem próximo, iterações de 1 semana vai permitir que esses itens com maior urgência sejam atendidos, sem alterar a iteração atual. Certo, continuando fizemos as contas de quantas horas cada desenvolvedor terá de tempo livre na semana (descontamos algum tempo pois eles também prestam suporte), somamos as horas de todos os desenvolvedores, multiplicamos por 0,6 (consideramos que uma hora normal é igual a 0,6 de hora ideal, pois eles atendem telefones, trabalham em mais de um projeto e outras coisas que prejudica a produtividade). Com isso chegamos a um total de horas ideais livres que temos essa semana.

Então começamos o planejamento. Primeiro a user story com maior prioridade. Quebramos ela em tarefas e estimamos as tarefas em horas ideais. Continuamos por mais algumas user stories até que o total de horas ideais que tinhamos livre para a semana estava completa (sobrou umas 2~3 horas ideais, mas nenhuma user story era tão pequena, então sobrou esse tempo).

Depois disso, colocamos os cartões no quadro, cada desenvolvedor já pegou sua tarefa e começou a desenvolver.

Continuarei indo nesta empresa por mais alguns dias e vou colocando aqui no blog como anda a adoção do desenvolvimento ágil nesta empresa. Vamos continuar melhorando a adoção do Scrum e das práticas de estimativas e planejamento, depois vou começar com TDD, testes de aceitação e integração contínua.

Anúncios

Read Full Post »