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.
Rafael,
Muito bacana documentar dessa forma, está me ajudando muito. Quero ver a continuação do processo. =)
José,
Pode deixar que a cada visita à empresa eu vou atualizar aqui no blog.
Abraços
Parabéns! 🙂
Salve camarada,
Seu site é muito útil, e esse post é uma pérola. Estou tentando implementar o modelo ágil onde trabalho mas como só conheço os conceitos através da teoria, fica difícil implementá-los.
Só por curiosidade, que tecnologias e ferramentas eles estão utilizando para desenvolver os sites?
Valeu.
continue com essa série de posts sim! muito interessante acompanhar esse processo.
Obrigados pelos comentários pessoal.
@Rafael Rosa, eles trabalham basicamente com PHP e o Zend Framework (que aliás eu não conhecia bem, mas até módulo para inversão/injeção de dependência já possui). As outras ferramentas/tecnologias eu vou detalhar melhor em algum post mais pra frente
@Rafael Dx7 pode deixar que eu vou continuar.
Abraços!
[…] Confiram aqui! […]
Muito bom mesmo o texto, vou correr ler os links indicados para entender ainda mais a teoria.
Espero a continuação, um abraço!
[…] Rafael Mueller Antes de começar, só vou adicionar algo importante que esqueci de escrever no post anterior. Antes da reunião para gerar as user stories, nós conversamos e geramos uma definição de […]
[…] 16, 2008 de Rafael Mueller Continuando essa série de post (parte 1 e 2), hoje vou comentar como foi o final da primeira iteração/sprint, reuniões de review, […]
Adoro suas matérias, mas gostaria de saber como organizou a metodologia e os artefatos entregues(documentos, atividades, etc…)
Obrigada,
Luciana
lucsoftconsultoria@hotmail.com
Luciana
Este projeto tinha como cliente a própria empresa (a empresa desenvolveu um serviço online), neste caso os artefatos importantes que foram entregues foram as funcionalidades com seus respectivos testes (de unidade e aceitação).
Sobre como eu organizei a metodologia, os outros posts desse mesmo assunto podem mostrar como fiz isso.
Embora este blog tenha ficado um tanto abandonado, prometo retomar o ritmo de posts em breve.
Abraços
Muito útil esta série de posts sobre como implementar o desenvolvimento ágil. O único problema são as pessoas fazerem mal uso deles, como por exemplo achando que com guias como este ele possa estar apto a implementar Scrum em outros ambientes. Na verdade a necessidade de uma consultoria e pessoas com experiência é essencial para que realmente a empresa possa adotar o scrum por completo.
Quando alguém internamente e sem experiência passa a tentar adotar ele naturalmente e a empresa são levados a criar um processo próprio, como citado no livro “Art of agile development”, realmente isto acontece…
Como muita gente citou, o conhecimento as vezes se restringe à teoria e foi assim comigo e quando vi na prática minha visão abriu completamente e hoje me sinto muito mais capaz depois de ter trabalhado realmente usando scrum, tendo consultoria e vivendo na prática de poder ajudar outras empresas a implantarem.
Realmente muito útil o seu post!
É a primeira vez que vejo a definição de “hora ideal” em desenvolvimento ágil!
Eu desenvolvo sozinho (freelancer) e gostaria de adotar algum método ágil para melhor aproveitar meu tempo, tornando meu trabalho mais organizado e minhas idéias sobre prazo mais “confortáveis”.
Parabens pelo post e pelo blog! ^^
Realmente muito útil o seu post!
É a primeira vez que vejo a definição de “hora ideal” em desenvolvimento ágil!
Eu desenvolvo sozinho (freelancer) e gostaria de adotar algum método ágil para melhor aproveitar meu tempo, tornando meu trabalho mais organizado e minhas idéias sobre prazo mais “confortáveis”.
Gostaria de saber se existe algum método de desenvolvimento que me atenda, ou alguma variação do próprio Scrum para essa ocasião.
Parabens pelo post e pelo blog! ^^