Scrum e XP direto das trincheiras

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sim!! O melhor livro para se aprender SCRUM agora está em português!

Leia mais aqui.

Você pode fazer download diretamente aqui.

Aproveitem. Agora não há mais desculpa!

Scrum vs. cultura da empresa

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje numa lista saiu este post do Rodrigo Lima. Achei bem pertinente e selecionei algumas respostas.

Pessoal,

Eu trabalhei um tempo atrás com Scrum, tenho um conhecimento prático grande, leio bastantes, etc. Atualmente estou num empresa que tem um forma de gerenciamento totalmente "torta".

Tem um projeto rolando, começou em setembro e com prazo pro final de dezembro. Pelo que eu to vendo o projeto está caminhando pro fracasso, a empresa tem pessoas muito boas tecnicamente, mas não tem um time de desenvolvimento. É um projeto em que a pressão por resultado está grande, cliente cobrando, pressionando, etc.

Queria saber dos mais experientes da lista se é uma boa oportunidade pra iniciar com scrum na empresa. Tenho medo que se no final der errado, a culpa seja colocada no scrum e não de tudo de errado que aconteceu no projeto anteriormente.

O que falo de dar errado é, não conseguir entregar as coisas nos prazos que já estão acordados e não podem ser redefinidos.

Qual a opinião de vocês em relação a isso?

Este tipo de mensagem é bastante recorrente nas listas. As respostas costumam ser praticamente as mesmas.

"Faça isso! Faça aquilo! Não faça isso!"

Mas uma pessoa (Fabiano Milani) postou uma mensagem que realmente trata da realidade nua e crua:

Bom, gostaria de dar a minha opiniao sobre o assunto, e deixando claro que é apenas a minha opinião e não que eu tomo ela como verdade, li todos os post do mesmo e vou fazer um comentário a respeito dos comentários.

Primeiramente gostaria de lembrar 2 pontos extremamente importantes :
1) Não podemos esquecer do fator principal que é a CULTURA DA EMPRESA, e isso meu amigo Rodrigo Lima, você melhor que ninguém que vivencia o dia a dia da empresa pode analisar e ver a real possibilidade ;
2) Levando em consideração a CULTURA da empresa podemos dizer que, não há a menor chance de funcionar a implantação na sua empresa se você tentar implantar Scrum da mesma forma que eu fiz na minha, ou o Wescley, Raony, Kerber fizeram na deles, podemos pegar algumas dicas e como cada projeto é um projeto, cada implantação do Scrum será uma também;

Infelizmente, por mais que todos nós fiquemos felizes em ajudar, temos que ter a convicção de que assim como cada projeto é um projeto, cada empresa é uma empresa. Parecidas, mas nunca iguais.

Eu tive recentemente um problema de falta de comunicação na minha empresa atual, onde todos querem implantar métodos ágeis, mas ao mesmo tempo tem algum receio de seguir em frente. E apesar de eu tentar demonstrar que a mudança seria gradual, por algum motivo demonstrei que queria fazer a mudança de forma "radical".

O que eu estou fazendo então? Por acreditar nos métodos ágeis estou buscando exercitar as práticas do agile antes de mais nada: valorizar as pessoas e a comunicação (embora já tenha ocorrido alguns problemas de comunicação - alguns até mesmo meus), focar em entregar partes do sistema funcionando em iterações, tentar a colaboração com o cliente e reagir às mudanças, ao invés de achar que tudo é imutável. E estou com a plena consciência de que estou aprendendo diariamente. Procuro tentar aprender algo de cada erro e acerto, mesmo que ainda não seja um hábito.

Tenho tido bons resultados até o momento. Tivemos um pequeno atraso de dois dias em um dos projetos devido a pessoa que está o tocando ser nova na empresa. E mesmo assim foi excelente para ele aprender o framework já do começo ao fim, e de forma iterativa... ao invés de fazer TODO site.

É importante perceber que para começar a usar o SCRUM nós temos duas maneiras de iniciar:

a) Tentando praticá-lo com a base, ou seja, com os desenvolvedores do projeto.
b) Tentando vender a idéia para nossos chefes.

Ambos os casos tem vantagens e desvantagens. Mas dependendo da cultura da empresa, um será mais benéfico do que o outro.

Então a minha sugestão é simples: avalie BEM a cultura da sua empresa. Sua equipe de desenvolvimento é resistente? Tente a abordagem com seus chefes ou busque aliados estratégicos. Seus chefes são tradicionais? Tente a abordagem com sua equipe.

Sua equipe é resistente e seu chefe é tradicional? Bom... daí você tem duas outras opções. Chutar o balde e tentar pisar nos calos das pessoas da empresa, mostrando como o agile pode ajudar (neste caso, vale muito a pena ter dados concretos, como valores) ou... sair da empresa. Mas essa última opção, sabemos que não é tão simples. Porém, sabemos que também você encontrará com certeza um mercado de empresas "ágeis" que vão recebê-lo de braços abertos.

Ultimo lembrete: lembre-se que a cultura da empresa não é aquilo que ela FALA que faz. Mas sim aquilo que ela REALMENTE É.

Dinâmica de aviões - PUCRS 2008/2 (com fotos e vídeos!)

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Como eu havia dito, no último dia 11/11 realizei novamente a convite do prof. Rafael Prikladinicki a dinâmica dos aviões em uma turma de gerenciamento de projetos da graduação da PUCRS (Sistemas de Informação).

Essa foi uma das melhores turmas que eu ministrei a dinâmica: todos, sem exceção, demonstraram enorme interesse não só na dinâmica, mas nos resultados e discussões que fizemos após. O fato é que a aula acaba as 22h30, mas eram 22h35 e eu terminava de falar e ainda TODOS estavam em sala de aula. Este é o melhor feedback que uma turma pode dar.

Se você não conhece a dinâmica, clique aqui.

Desta vez, por lição aprendida, não utilizei os cartões para definir os papéis. Isto pois quando a turma é muito grande, temos alguns problemas com um lendo o cartão do outro ou então um não se segurando e falando o que tem que fazer. Ao invés disso, o Rafael chamou um de cada equipe, discretamente, e passou a idéia desta pessoa ser o gargalo do time.

Pela primeira vez desde que comecei a aplicar a dinâmica, as TRÊS equipes produziram o protótipo bem próximo da realidade, mas claro, sempre esquecendo de alguns detalhes "pega-ratão" ;)

E felizmente, todos os erros de estimativas iniciais e as correções posteriores, ocorreram de forma ideal. Uma equipe falou que produziria muito a mais da sua capacidade (por não conhecer seu limite) e quando percebeu que não entregaria isso, reduziu a estimativa... mas nem por isso deixou de tentar superar este limite posteriormente. Ou seja, aplicaram exatamente o conceito do PDCA. Em todas as equipes o resultado foi similar, o que demonstrou que os três grupos estavam bastante maduros em relação a este ponto central da dinâmica.

E o gargalo? Ahh o gargalo. Os três gargalos das três equipes foram perfeitos. E mais perfeitos ainda foram os demais integrantes da equipe (e Scrum Master) que perceberam o gargalo e reduziram o trabalho neles. É essa a intenção: fazer a equipe perceber o problema e superá-lo de alguma forma.

Enfim, a dinâmica foi uma das melhores, na minha opinião. Os principais eventos da dinâmica para causar uma bela discussão no final do processo, aconteceram. E graças a ele eu senti que os principios do agile foram bem assimilados e bem praticados. Tomara que futuramente eu pegue turmas no mesmo nível ou, se der sorte, melhor do que esta.

Abaixo, curta algumas fotos e um vídeo desta dinâmica.

A Scrum Master corre contra atrás de matéria prima para atingir a meta da equipe.

O Scrum Master dá uma discreta conferida na equipe adversária.

Linha de produção em pleno vapor. Um membro do time fica de pé sendo elemento móvel.

Linha de produção em ação.

Linha de produção em ação.

Vista geral da sala. Três equipes.

Apresentação dos protótipos iniciais (com pouquíssimo escopo). O momento mais divertido.

Adivinhem quem é o gargalo deste time? hehe

Reunião de replanejamento de processo.

Apesar de tudo, essa foi a equipe vencedora! Não parece... mas se puxaram! :)

Planilha com as estimativas iniciais e o previsto/realizado de cada equipe, por sprint.

Aviões prontos para serem avaliados por mim ao final do sprint.

Os vídeos!

O desafio do agile

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Atualmente estou tendo pouco tempo para participar mais ativamente das listas. Porém, encontrei este tópico e achei muito interessante. Uma colega da lista teve sérios problemas em implantar o SCRUM em sua empresa. Por quê? Resistência ferrenha dos seus colegas mais antigos.

Este é um dos maiores desafios do agile: mudar a cultura das pessoas. E não pensem que é fácil. A mensagem da Lívia e as respostas dos colegas que se sucedem retratam bem essa situação:

Olá pessoal,

Já aviso que é um post negativo e triste... :(

Tentei implantar scrum onde trabalho. Após muitas palestras, leituras de livros e listas de discussão, tínhamos uma equipe motivada a usar Scrum.
Mas acho que fomos vencidos pela outra equipe, os seres que já estavam aqui antes de nós: os analistas "experientes".

Não nos deram a chance de testar, boicotaram nossas reuniões diárias, ignoraram o sprint backlog, pensaram em fazer um sistema muito além do escopo definido pelo usuário, não estudaram a metodologia e, para melhorar, fecham-se a coisas novas.

E agora estamos aqui. Após 1 mês e meio de trabalho, tínhamos planejado e estimado uma tarefa simples de criação de um cadastro, mas nem terminamos a modelagem. 1 mês e meio para realizar uma modelagem... de um cadastro...

Depois de tanto ponto negativo, pergunto-lhes: O que me resta? Sentar e chorar?

Att,
Lívia. Triste. Muito triste.

--
Lívia Silva Santos

Resposta do Antônio Carlos Zegunis Filho:

Olá, Livia!

Acho que podemos fazer algumas ponderações e quem sabe te oferecer alguma alternativa.

De qual nível da empresa partiu a idéia de utilizar Scrum? Foi do pessoal da área operacional (desenvolvedores, analistas, etc)?

Se sim, as áreas interessadas em $$$ (tática e estratégica) ficaram sabendo do objetivo da troca de metodologia? Acho válido que esse tipo de movimento parta do pessoal operacional, mas é importantissimo que quem manda na conta bancária da empresa não fique de fora, pois a idéia é que esses caras obtenham a maior parte dos benefícios oferecidos pelo Scrum que é o foco em
ROI.

Talvez uma alternativa que você tenha é em caso do pessoal da grana não estar sabendo desse tipo de movimento, preparar um pequeno estudo e fazer uma apresentação que mostre quanto $$$ potencialmente pode ser economizado com essa estratégia nova.

Uma vez que esses caras estejam convencidos e você tenha alguma liberdade pra tocar pra frente o Scrum ai você pode tentar ver se o pessoal das antigas se adapta a nova forma de trabalho ou então trocar cada um que não se adaptar.

Agora...se o pessoal que pensa em $$$ ficou sabendo e mesmo assim a coisa foi pro brejo das duas uma: ou vocês acabaram pisando na bola em um determinado ponto (talvez conversando com a gestão isso seja esclarecido) ou então o pessoal não quer economizar $$$ e sua melhor opção é de fato procurar outro lugar pra trabalhar...

Nem todas as empresas estão preparadas pra esse tipo de mudança, mesmo que só traga melhorias.

Att.,
Antonio Carlos Zegunis Filho

Resposta do Wescley Costa:

Oi Lívia... não acho que seja o momento de sentar e chorar... mas sim de repensar, reorganizar e tentar novamente, porém, da forma certa.

Faz um tempo que venho planejando usar Scrum onde trabalho, mas devido ao que aconteceu com vc, e vários artigos, pdfs, e etc que li por aí, aprendi que existe o momento e lugar certo para se fazer isso.

Na minha opinião, oq aconteceu com vc é normal, vc pode ter se precipitado, na ansiedade de começar logo não esperou o momento ideal, e nisso os tradicionais(analistas experientes) se aproveitaram da situação para derrubar sua iniciativa, e talvez o objetivo deles foi alcançado
né, pois vc já pensa em sentar e chorar, ou seja, desistir.

Quer um conselho? não dê esse gostinho a eles... analise melhor as coisas na sua empresa, molde as coisas pouco a pouco e na hora certa, tente novamente... vá incentivando todos aí que será
melhor para a empresa usar Scrum e quando todos estiverem de acordo, comece...

ou então, consiga montar uma equipe onde todos estejam realmente interessados em adotar as práticas ágeis... oq é a melhor opção. E relaxa... raramente alguem consegue o sucesso na primeira tentativa!

Att,
Wescley Costa

Resposta do Adail Retamal:

Lívia,

Enquanto não estivermos preparados para explicar, claramente:

* Por que mudar?

* O que mudar?

* Para o que mudar?

* Como causar a mudança?

não conseguiremos superar as várias camadas de resistência à mudança.

Tenho usado a TOC (Teoria das Restrições) justamente para me auxiliar nesse processo de convencimento e de transição, pois as empresas estão fartas de mudanças que não necessariamente se traduzem em melhorias. Essa resistência à mudança tem seus motivos... As pessoas não são idiotas (ok, algumas nos levam a pensar que sim)...

Veja um pouco aqui: www.heptagon.com.br/toc

Se puder ajudar em algo, pode me procurar...

Heptabraço,

Adail Muniz Retamal

Resposta do Manoel Pimentel:

Olá Lívia,

Na verdade isso é muito comum (muito mesmo), então talvez seja o caso de você rever a estratégia e tudo aquilo que os colegas da comunidade já falaram nesse tópico.

Mas, permita lhe dar só duas sugestões:

1) Leia o livro: O livro "A quinta disciplina" de Peter Senge, que além de você ver que "Quando mais você empurra, mais o sistema empurra de volta", você verá que talvez sua empresa tenha um sério problema de aprendizagem e que precisa ser resolvido, através de injeções à questões que vão além da proposta do Scrum.

2) E também é importante que você faça as seguintes perguntas:
- Por quê implantar Scrum nessa empresa?
- Existem algum problema que justifique usar Scrum nela?
- E outra, essa empresa, merece usar Scrum (eheheh)???

Grato,
Manoel Pimentel

Então a Lívia se revitalizou um pouco e explicou melhor a sua situação:

Olá pessoal,

Nossa, fiquei mais animada depois das mensagens.

Vou tentar explicar um pouco mais a minha situação. Trabalho em um hospital de clínicas de uma universidade estadual...

Situação atual (que queremos reverter): Os analistas desenvolvem aplicações pro hospital em cobol e db2, usando mainframe. Cada um é dono de um sistema, e todos torcem para ninguém sair de férias. Quando alguém sai, o sistema fica literalmente parado por 1 mês pois ninguém mais quer colocar a mão. Existem ilhas de conhecimento, não há cooperação. Não há o conceito de equipe. Ninguém gosta de expor o próprio código.

Porém, a universidade quis mudar a plataforma de desenvolvimento e escolheu java por N motivos. O primeiro desafio foi informar a mudança. Houve um choque! Passado o choque, fizeram cursos. Mais de um ano depois, ninguém desenvolveu nada na tecnologia nova por não conseguir, não entender e não ter apoio da diretoria da informática. Depois do desastre, começaram a contratar uma equipe para trabalhar com java. Eu fui a segunda pessoa a ser contratada no ano passado. A equipe já conta com 4 analistas e 1 programador novos.

A universidade também tentou utilizar o RUP, mas parece que não deu muito certo. Usaram o RUP para justificar as falhas. Por exemplo: "Fulano, por que você não perguntou isso para o cliente?"... "Ah, porque o RUP não fala que eu tenho que fazer isso!"

O problema: Unir essas duas equipes para trabalharem em projetos novos. Quando nós soubemos como eles trabalhavam, não achamos legal continuar nesse esquema. Além disso, há outro agravante: muitos analistas estão para aposentar em até 5 anos. Ou seja, o conhecimento deles tem que ser passado aos poucos para os outros. A diretoria de informática ainda não tinha pensado nisso. Ano passado, eu e outro analista novo fomos ao Java Brasil e voltamos cheios de idéias. Scrum e XP nos trouxeram um pouco de esperança por alguns motivos, tais como:

-trazer de volta o trabalho em "equipe", acabando assim com as ilhas de conhecimento (pensamos muito na programação em par e em como isso poderia nos ajudar);
-conseguir aumentar nossa produção, já que a equipe antiga demorava até 4 meses apenas levantando requisitos (e para variar, quando entregavam o produto, muito tempo depois, muita coisa tinha mudado e eles faziam os clientes aceitaram do jeito errado mesmo por medo de fazer alterações);
-melhorar o gerenciamento e fazer a diretoria do hospital entender que mesmo que trabalhemos em um órgão público, há SIM gastos e custos;
-melhorar a integração dos novos com os que já trabalhavam aqui para disseminar o conhecimento de java e para nós, os novos, aprendermos as regras do negócio que só eles sabiam...

Explicamos para a diretoria de informática, que comprou a idéia. Chegou inclusive a pagar um treinamento para dois analistas.

O problema que eu já apontei e entendi depois de ler alguns posts: realmente, houve imposição da utilização dessa metodologia. Os analistas que já trabalhavam aqui não acreditam, não apoiam e não querem usar. A diretoria pediu que nos dessem uma chance para tentar testar e ver se realmente funciona. Mas acredito que enquanto houver resistência á tentativa, nada sairá do papel.

Por mais que a gente explique para os outros analistas o que é o scrum e como ele poderia nos ajudar e facilitar nossas vidas em vários aspectos, também tentamos informar os pontos em que talvez ele não se aplique aqui. Mas esses analistas não se interessam, não estudam a metodologia, não se esforçam para fazer funcionar.

Essa modelagem do sistema novo está demorando tanto porque estão agindo como faziam antigamente: querem prever tudo o que o sistema pode ter, aumentar o escopo do projeto, demorar para definir as coisas. Nós queremos feedback, queremos que o usuário aprenda sobre o sistema enquanto o fazemos. Mas todos aqui tem medo, muito medo, de mudanças, de todos os tipos: código, conceitual, paradigma...

Ana, falei da tarefa para o cadastro, mas me enganei. Era realmente uma história. A modelagem é que era uma tarefa. Sei que com certeza erramos em vários pontos na implantação do scrum. Afinal, foi nosso primeiro, e já esperávamos ter que corrigir coisas no meio do caminho. Mas acho que aqui a gente luta por algo não tão no nível do scrum.

Estou chegando à conclusão que o problema não foi só o scrum dar errado. Talvez o problema esteja mais embaixo. :(

Obrigada a todos pelas dicas!

[]s
Lívia

O que eu posso dizer sobre isso? Mudar um processo é difícil. Conscientizar as pessoas é mais difícil ainda. Você poderá ser mal comprendido, poderá ser visto como revolucionário. E com certeza escutará coisas do tipo: "Você não conhece os processos" ou então "Isso não vai funcionar aqui... é outra realidade".

Embora o sentimento seja de desistir, temos que aprender e retomar as tentativas. E mostrar que tudo o que queremos é, na verdade, AJUDAR a empresa a se adequar ao futuro.

No meu MBA um dos meus professores falou sobre empresas orgânicas, que isto é a tendência do futuro para todas organizações de todos os tipos. A maioria dos princípios são aderentes ao do agile. Mas isso é assunto para outro post :)

Abraços

Por que agile é TÃO legal

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Falei da reunião, certo?

Num determinado momento nós iríamos simular alguns processos. Dessa forma saberíamos as disposições, os recursos atuais, projetos por equipe e onde faltam recursos. Logicamente, como eu já tive algumas experiências anteriores, eu sabia que uma reunião que teria tudo para se tornar monótona e sem graça, precisava de um toque especial... um toque agile.

E então eu criei cartões sobre os processos e afins. E com post-its fomos preenchendo o resto. A reunião ficou tão divertida, que um dos diretores pegou a máquina e fotografou.

Sim, eu sou o laranjão.


Agile é legal porque é VISUAL.
Quanto mais VISUAL, mais INTERATIVO.
Quando mais INTERATIVO, mais COLABORATIVO e INFORMATIVO.

Por isso que usar dinâmicas, post-its, taskboards, burndowns, planning poker, etc. é tão importante. Motiva e cativa as pessoas.

Eis ai um exemplo BEM prático :)

Sexta-feira, o dia do "yes!"

Nesta última sexta-feira aconteceu uma coisa que eu merecia (sem falsa modéstia).

Vocês que acompanham o blog sabem que eu sempre costumo expressar minhas opiniões sobre comunicação, liderança, gestão, etc. Porém, sabem também o quanto eu tenho de problemas no trabalho, devido a falta de uma cultura de projetos, principalmente.

O que estava acontecendo então? Eu me sentia aquele cara que sabe tudo na teoria, mas que nunca consegue colocar as coisas em prática. É um sentimento muito ruim, desmotivador, inclusive.

Desde que eu assumi esse "projeto" (já que me foi jogado no colo para eu "resolver") eu tive um pequeno desacerto com o meu chefe, vi meus antigos funcionários cairem fora, recebi um novo funcionário (indicação de outro chefe) e tive diversos problemas com os requisitos do projeto.

Eu estava crente que seria mais um projeto que iria para o lixo, sem chance alguma de sucesso, qualquer que fosse o meu esforço. Eu me senti como se estivesse numa competição do "Aprendiz" em que o Trump ou o Justus me jogam para a arena com uma espada de madeira para lutar com uma dezena de gladiadores e leões. Embora a analogia seja meio pobre, posso dizer que mostra o sentimento de impotência que eu estava sentindo.

Porém, algo me motivou. Inicialmente eu comecei a pensar que de nada adiantaria eu ficar em cima do muro, fazendo apenas o necessário para depois dizer "eu avisei que não ia dar certo". Eu precisava encarar isso como um desafio e fazer o que fosse possível para resolver a situação. Junto a isso, e que foi um daqueles suplementos alimentares na minha motivação, o fato do novo funcionário ser um jovem de excelente competência técnica, me mostrou que SIM eu posso obter ótimos resultados tendo uma equipe razoável e um desafio pela frente.

Nesta sexta-feira os meus dois chefes me solicitaram para ver o projeto, onde estávamos, o que havíamos feito, etc. E o que eu apresentei a eles, não apenas solucionou os problemas propostos como ainda consegui ir além.

Desenvolvemos em uma semana: um software para o celular (a melhor solução possível para um problema crítico deste projeto - que envolve um processo específico), dois sistemas de relatórios via web (para demonstrar o que podemos manipular em nível de dados), além de uma pesquisa sobre os processos envolvidos, com soluções propostas e vantagens e desvantagens. Tudo isso em um Powerpoint para ser apresentado ao cliente. O que eu fiz, basicamente, foi tentar orientar essa "demanda" em um projeto. E espero fazer isso após a reunião com o cliente.

A reação dos meus dois chefes foi daquelas de deixar qualquer subordinado animado. Eles sairam felizes! A sensação foi de que superamos as expectativas deles. Lógico que a expectativa deles também não era muito alta, pois eles sabem o histórico ali do laboratório... mas ainda assim foi uma das únicas vezes que eu vi os meus chefes realmente satisfeitos com o que viram (de cabeça, eu lembro da vez que apresentamos o antigo projeto na feira, que o meu chefe ficou muito feliz também, mas apenas um deles... o outro não estava envolvido).

Enfim, a sexta-feira foi a recompensa que eu há muito estava buscando. O resultado da minha superação em atingir um resultado e superá-lo, inclusive. Fui gerente de projetos, analista, desenvolvedor e DBA (analista de banco de dados). Não é o que eu quero que se repita - e irei deixar isso claro futuramente - mas o esforço valeu a pena.

Por pior que seja o nosso ambiente de trabalho (o meu é ruim apenas na questão organizacional, vale ressaltar) nós sempre temos um objetivo em comum: encantar nosso cliente. Seja ele o cara que compra o seu produto ou mesmo o cara que paga o seu salário. Nada melhor do que atingir isso.

A lição que dá pra tirar disso é: se você está desmotivado, busque motivação. Se você quer passar uma mensagem, a melhor forma de fazer isso é motivado, atingindo um bom resultado... e depois apresentar uma forma alternativa de superar aquilo. Nenhum chefe vai dar atenção a alguém que falha (para depois dizer "eu avisei") e se demonstra desmotivado. Porém, se você tiver os holofotes por algo bom que tenha feito, sua mensagem será potencializada. Tenha a certeza disso.

Sexta-feira: o dia em que eu esperei por um bom tempo chegou. E o seu? Lute para que ele chegue o mais cedo possível.

Dinâmica: fábrica de aviões versão 2.0

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, com atraso estou publicando para vocês a dinâmica da fábrica de aviões que apliquei na turma de "Especialização em gerenciamento de projetos" na PUCRS. A idéia da dinâmica é vivenciar os conceitos do SCRUM, de forma prática, facilitando a visualização dos benefícios. Usamos bastante o conceito PDCA e processos empíricos, que são algumas das bases do SCRUM.

Esta dinâmica foi desenvolvida com base na primeira versão, só que agora ela se tornou mais "ágil" e divertida. Por quê? Inseri algumas novas variáveis e situações que tornam ela mais aderente ao que desejamos passar, ou seja, o conceito do SCRUM.

Para acompanhar este post, é legal você primeiro baixá-la no link abaixo.

Baixar a dinâmica (PDF)
Baixar a tabela em excel (XLS)
Baixar as fichas de responsabilidades (PPT)

Qual a essência da dinâmica? Criar uma linha de produção de aviões de papel que segue uma regra bem simples: a folha de papel começa numa ponta e "termina" avião na outra ponta. Na dinâmica que eu apliquei, foram 3 equipes com 7 membros cada. Se você tiver mais gente envolvida, tente manter no máximo 4 equipes com os membros necessários. Assim você consegue fazer o papel de Product Owner, avaliando o que foi produzido. Crie nomes do alfabeto grego para as equipes (no meu caso foram Sigma, Omega e Gama. Você já verão o por quê disso.

Avise as equipes que a forma como eles se organizarão para fazer a engenharia é com eles. Se quiserem ficar de pé, organizar as mesas em círculos, etc. é problema deles. DESDE QUE o produto comece numa ponta e acabe na outra. Além disso, a outra restrição é que não pode haver estocagem de material, ou seja, cada grupo só pode pegar mais 10 folhas quando a última folha entrar em produção. Isso existe só para tornar o processo mais difícil e para dar trabalho ao Scrum Master, na hora dos sprints :)

A estrutura da dinâmica é simples: as equipes tem três minutos para discutir o processo (retospectiva e planejamento) e ao final do tempo passam a estimativa de produção. Depois elas tem três minutos para produzir o que prometeram, conforme as definições do escopo solicitadas. E assim por diante (ciclo PDCA).

Neste primeiro momento, os papéis não existem ainda. O cliente fictício é a Força Aérea. É informado que a organização quer um novo avião e entrou em contato com as empresas deles. Então a organização quer saber das equipes quantos aviões eles produzem em três minutos. E eles tem UM minuto para dar a estimativa.

Isso mesmo, curto e grosso assim. Qual a idéia por trás? Quantas vezes nossos clientes e chefes chegam para nós: "Quanto tempo a gente entrega um sistema de cadastro e relatórios para o cliente XYZ?". "Bem... depende, como é o escopo?". "Escopo? É um sistema de cadastro e relatórios!! Quanto tempo?". Notaram a semelhança? É exatamente essa. Dar uma estimativa de algo que não se tem a menor idéia. No fim da dinâmica, na retrospectiva, isso serve para avaliar como as estimativas melhoram quando a equipe trabalha e conhece sua capacidade.

Enquanto as equipes fazem as estimativas, abra a planilha Excel para fazer o controle do "previsto / realizado". E marque ali assim que eles derem as estimativas.

Continuando, passe para eles que a Força Aérea gostou das estimativas. E vai abrir concorrência. Agora, a organização passou o escopo do avião. Com base no escopo, as equipes terão 3 minutos para produzir um protótipo. O escopo é bem simples:

- O avião deve possuir 12 janelas
- Deve possuir uma cabine
- Deve possuir o logotipo da empresa que está produzindo, nas asas e na cauda (o logotipo tem que ser o símbolo do Sigma, Gama, Omega - aqui é outra pegadinha!)

Note que não é dito "que tipo de avião" deve ser produzido. A idéia é mesmo que as equipes quebrem a cara na hora de apresentar o protótipo. Esse é o momento mais divertido da dinâmica. Se as equipes perguntarem algo mais sobre o escopo, diga que você não sabe... a organização não passou mais informações.

Cuidado para não passar o próximo slide, onde tem o projeto que a Força Aérea quer. Esse slide é para depois das apresentações!!

Após a produção, peça para um de cada equipe vir até a frente e apresentar o avião. No final, faça o teste do vôo. Não esqueça de solicitar os aplausos para cada apresentação :)

Depois das apresentações, passe o feedback de cada avião. Compare os protótipos com a idéia do que o cliente queria (o slide que mostra isso). Uma coisa que quase nenhuma equipe coloca é PORTA. Pergunte: "Como o pessoal vai entrar no avião???". Se eles reclamarem que isso não foi dito no escopo, fale: "Mas precisava dizer?!". Aqui é a velha demonstração das expectativas do cliente versus produção. :)

Pronto. Agora eles já sabem o que deve ser produzido. Então as linhas de produção vão começar. Diga que eles terão 3 minutos para avaliar a engenharia que irão utilizar para o processo e ao final, passarão a estimativa de produção. Eles deverão produzir os aviões criteriosamente conforme o escopo passado. Aqueles que, ao final dos três minutos do sprint, não estiverem de acordo (faltou uma janelinha, faltou o logotipo correto, etc) não contam como finalizados, mas podem voltar para a linha de produção para serem finalizados. Essa regra é importante e segue os princípios do SCRUM.

Antes de começar, porém, é preciso definir os papéis. Utilize as fichas que estão ali em cima para download (imprima mais fichas "membro da equipe"). Diga que você irá passar para cada um dos membros das equipes uma ficha contendo o papel deles na equipe. Invente que as equipes serão multi-funcionais e cada um terá um papel para desempenhar. Diga que eles devem ler a ficha e atuar conforme está escrito ali e não devem comentar com ninguém quais são suas atribuições.

Por que dessa cena toda? Porque os papéis nas equipes são: SCRUM MASTER (não pode produzir, deve cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima), MEMBRO DO TIME (produzirá o produto e avaliará o processo) e ... ELO FRACO.

Cada equipe tem UM Scrum Master e UM Elo Fraco (se você quiser colocar dois por equipe, dependendo do tamanho, é uma idéia interessante também). O Elo Fraco tem como função principal ser exatamente a pessoa que atrasa o processo todo. Aquele cara descompromissado, que destoa dos demais. É o gargalo do time. Mas ele participará do time como se quisesse melhorar o processo (dará sugestões, etc), mas na produção será sempre o gargalo. Ele tem que ser um bom ator e não pode deixar ninguém saber que ele está atuando assim, dai a importância de deixar claro que ninguém pode ler a ficha do outro (se possível, recolha as fichas após eles lerem).

Sabendo disso, diga que o SCRUM MASTER deverá sair da linha de produção e ficar de pé, auxiliando o time nas suas funções. Ele, lógico, pode dizer o que pode ou não fazer.

Feito isso, as regras estão expostas, o escopo é sabido e os papéis e responsabilidades são conhecidos. Dê o start para que eles comecem a planejar o processo e ao final passar a estimativa.

Uma sugestão que causa um efeito psicológico bacana: Durante esses períodos de planejamento, controle o tempo e passe para eles quanto tempo falta para encerrar. Mas nos sprints não avise o tempo, só diga quando encerrou. A idéia é que o Scrum Master ou a equipe percebam que eles que tem que controlar o tempo.

Ao final do planejamento, eles começam os sprints de 3 minutos. Repita daí o processo de "planejamento/estimativa 3 minutos" e "sprint 3 minutos". São três sprints (um número ideal para ninguém cansar ou encher o saco!).

Quando as equipes passarem as estimativas, marque na planilha Excel, na coluna "previsto". Quando você fizer a contagem dos produtos finalizados (que devem estar totalmente de acordo com o escopo) marque na outra coluna "realizado". Assim até acabarem os sprints.

Ao final do terceiro sprint, veja qual foi a equipe vencedora (a que entregou o maior número de produtos). Entregue algum prêmio, como uma caixa de "Bis" para motivá-los :)

Encerrada a dinâmica, avalie com o pessoal como foi o processo. Revele os papéis "obscuros" que existiam nas equipes (os elos fracos) e questione se a equipe havia percebido isso e se tomaram alguma atitude para contornar o problema. Avalie a questão do protótipo versus expectativa do cliente... a questão do trabalho em equipe... a identificação do limite de produção da equipe... o desafio de superar esse limite... a questão do empowerment (onde os membros da equipe avaliavam o processo e tinham poder de sugerir mudanças)... os benefícios da inspeção e adaptação com base na experiência... e encerre comentando a idéia de usar sprints de trabalho.

Faça a pergunta que contém no slide: "Seria melhor entregar todos os aviões em 10 minutos ou % deles a cada 3 minutos?". Dificilmente alguém dirá que o ideal será a primeira opção. Lembre da teoria do estudante (deixar tudo para a última hora), a motivação que será alta nos primeiros minutos e depois cairá com o tempo (afetando a produção).

Antes de terminar, abra a segunda aba da planilha Excel, onde tem o gráfico baseado nas estimativas passadas. Demonstre que o primeiro ponto representa a estimativa quando eles não sabiam NADA do que tinha que ser feito (quando a Força Aérea pediu estimativa sem passar nada). As outras estimativas já foram com base na experiência e no conhecimento do escopo. Possivelmente você terá um gráfico que começa mais alto ou baixo e que depois tende a ficar parecido com uma reta, estabilizando. A idéia é que a gente erra nas estimativas iniciais em +400% e -20%, normalmente. E com o tempo, conhecendo o escopo e nossos limites de produção, as estimativas tendem a ser mais próximas à realidade e tendem a estabilizar. Comente que se houvessem novas sprints, o gráfico se estabilizaria de vez, cabendo à equipe e ao Scrum Master a idéia de tentar encontrar soluções para superar aos poucos estes limites.

Por exemplo, se as equipes produzissem 15 aviões no máximo, o que eles teriam que fazer para otimizar o processo para produzirem 17-18? E assim sucessivamente, quando conseguissem atingir os resultados.

Por fim conclua, demonstrando que eles vivenciaram a essência do SCRUM, ou seja, um ciclo PDCA onde eles planejaram o que fariam, realizavam as tarefas, checavam e avaliavam o processo e por fim tomavam decisões de mudança com base nisso, para alimentar o planejamento.

Termine desafiando: "E se usássemos isso na produção de um software?". Aí é discussão para não acabar mais :)

Ufa! Apesar deste texto longo, eu tenho certeza que você conseguirá aplicar essa dinâmica com o mesmo sucesso que eu tive ao aplicar na turma de especialização em gerenciamento de projetos, na PUCRS. Ali foi muito bacana. Os momentos mais divertidos foram na prototipação e durante os sprints (tive a sorte de escolher bem quem seriam os elos fracos - que foram excelentes atores!).

Ao final da dinâmica, todos entenderam a essência do SCRUM. A mensagem foi passada com total sucesso e tenho a certeza que abriu um novo horizonte para aqueles que não conheciam essas práticas.

Use essa dinâmica como um reforço para passar a mensagem do SCRUM ou mesmo para vender a idéia para sua diretoria. Apesar do pretexto bobo (criar aviões de papel) tenha a certeza de que ao final todos vão ficar bastante satisfeitos com o resultado.

Peço encarecidamente que, quem for aplicar a dinâmica, me envie um email contando como foi a experiência :)

Um grande abraço e façam bom uso!

Ótima notícia para a comunidade de SCRUM

O grande Henrik Kniberg, autor do excelente livro prático de SCRUM "SCRUM and XP from the trenches" (baixe aqui) divulgou em seu blog que uma versão do livro em português está a caminho.

Os brasileiros que tem dificuldade com inglês possuiam pouquíssimo material de apoio no assunto, e agora teremos um bem bacana. O livro é sem dúvida alguma um dos melhores sobre SCRUM que existem, pois basicamente ele passa a visão prática dele. O subtítulo é "How we do scrum", ou seja, "como usamos o scrum".

Se você quer começar a utilizar, siga os processos propostos pelo Henrik e adapte com a necessidade à sua empresa.

Enfim, a tradução do livro é uma excelente notícia para todos.

Post original.

Abraços!

Retrospectiva do projeto (lições e prática)

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Conforme dito, vou passar aqui alguns itens citados na retrospectiva do meu projeto.

A retrospectiva abrangiu o projeto como um todo (2 anos) e infelizmente não pôde contar com todos os envolvidos (faltou o chefe/cliente e um membro da equipe).


Apresentação


O processo da retrospectiva foi realizado em dois momentos. No primeiro momento, uma linha do tempo que abrangia todo o projeto foi desenhada. A partir disso, foram sendo citados os eventos que ocorreram durante o projeto, numa espécie de brainstorming. Estes eventos eram colocados em ordem da data em que aproximadamente ocorreram.

Após este levantamento, alguns eventos foram excluídos por serem “duplicatas” ou então por serem conseqüências de alguns itens citados.

O segundo momento foi a divisão entre o que foi bom e o que não foi legal no projeto, e a classificação de cada um dos eventos nesse quadro comparativo. Para cada evento também eram analisados alguns fatos, como comentários sobre o evento, causas e conseqüências. Alguns eventos também foram discutidos pela equipe, apenas como relembrança.

Ambos os processos foram fotografados para posterior documentação. Este documento apresenta estes eventos classificados em “o que poderia ter sido melhor” e “o que foi bom”, com comentários do autor do documento (Flávio, gerente do projeto). Alguns outros itens foram incluídos pelo gerente posteriormente.

A figura abaixo demonstra a organização da retrospectiva.

Este post pode (e deve) ser usado como referência para futuras tomadas de decisão, sendo um excelente repositório de lições aprendidas na prática. Use-o para refletir se suas decisões e atitudes podem ou não causar os mesmos estragos ou oportunidades aqui descritos.

--------------------------

O que poderia ter sido melhor

• Utilização do conceito Waterfall, como engenharia. A utilização do waterfall (concepção, análise, desenvolvimento e finalização) se mostrou bastante inútil para nosso projeto. Houve uma perda de tempo enorme uma vez que o desenvolvimento já poderia ter sido iniciado muito anteriormente.
• A não utilização do Wiki como ferramenta. A idéia do Wiki como repositório de conhecimento foi muito boa. A ferramenta é fácil de usar e bastante simples. Infelizmente não houve uma cultura (e cobrança) para que o uso fosse disseminado.
• Muito tempo na fase de concepção. Seguindo o modelo Waterfall, a equipe acabou levando muito tempo na fase de concepção. Houve muita desorganização, apesar do documento de concepção ser bem completo (e boa parte estar defasada já).
• Equipe muito grande. Houve muita desorganização no começo. O projeto começou inicialmente com 8 desenvolvedores, um gerente e um coordenador. Ficou evidente que o ideal seria uma equipe com 4 desenvolvedores no máximo (finalizamos com 3).
• Software poderia ter iniciado logo depois da concepção. Perdeu-se muito tempo para modularizar e definir de fato o software embarcado, uma vez que tivemos muito foco no hardware. Posteriormente ficou evidente que pelo menos dois ou três módulos poderiam ter sido iniciados logo após a concepção.
• Utilização do Status Report semanal. O documento, apesar de boa intenção para identificar as tarefas realizadas pela equipe, se mostrou bastante burocrático e ineficaz. Boa parte do resultado que desejava se atingir com ele, poderia ter sido feito com mais reuniões e com a cobrança da gerência.
• Escopo muito solto. Por muito tempo o projeto teve um escopo muito “solto”, ou seja, não se sabia ao certo o que iríamos produzir. Isso custou tempo, foco e afetou a produtividade. Deveria ter havido mais cobrança junto ao cliente para formalizar o escopo.
• Tentativa de utilização de um TCC como hardware do projeto. Perdeu-se algum tempo com a idéia de usar como placa-mãe um trabalho de TCC de alunos. A idéia era muito boa, mas mostrou-se ineficiente (já que os alunos pediram um valor altíssimo pelo projeto).
• Falta de datas (deadlines). Por diversas vezes a equipe sentiu a necessidade de vislumbrar uma data final para a realização de alguma atividade. Faltou cobrança e planejamento, muito devido ao escopo “solto”. Isso acabou levando a equipe a também se comportar de forma mais “solta”.
• Curso extraprojeto com membros da equipe. O curso, além de ser muito ruim – na opinião dos dois – ainda demandou que dois membros da equipe saíssem por alguns dias do projeto para aprenderem sobre uma tecnologia que nada agregaria ao projeto. Além disso, o projeto em que seria usado o que foi aprendido no curso, acabou sendo abandonado.
• Documentação do projeto. Por diversas vezes a equipe foi cobrada para realizar a documentação do projeto. O documento foi desenvolvido, mas sempre foi desaprovado pelo cliente. Infelizmente faltou, por muitas vezes, um norte para que a equipe desenvolvesse o que o cliente queria (lhes foi dito que a documentação deveria permitir que até mesmo uma empregada pudesse montar o sistema). A falta de norte também levou a produção de uma documentação acadêmica e desnecessária, que não agregariam nada ao projeto em si. Perderam-se meses nesta documentação, levando a desmotivação de todos (equipe e cliente). Por diversas vezes a aprovação da documentação ficou pendente por muito tempo, levando todos a questionar se essa documentação era realmente importante.
• Falta de definição de papéis. O coordenador do projeto trabalhou no projeto como coordenador, especialista e cliente. Isso confundiu bastante a equipe e o próprio coordenador, por diversas vezes.
• Coordenador segurou as compras durante o desenvolvimento. Apesar de ter sido uma ótima decisão no início do projeto, a insistência na decisão de só comprar os componentes após a documentação ter sido finalizada acabou atrasando bastante o projeto, uma vez que a documentação foi problemática (conforme citado anteriormente). Alguns módulos e ferramentas poderiam ter sido adquiridos para o início da produção. Essa falta de materiais “tangíveis” do projeto, gerou um pouco de desmotivação no projeto.
• Falta de aproximação do coordenador com a equipe. Por ser o especialista do projeto, poderia ter tido uma participação mais efetiva no projeto, onde algumas coisas poderiam ter sido agilizadas.
• Reuniões sem agenda. Diversas reuniões foram realizadas sem uma agenda para ser seguida, o que levou a falta de foco e decisões.
• Reuniões de acompanhamento e de escopo. Por diversas vezes as reuniões de acompanhamento (onde também eram discutidas algumas idéias de escopo) foram muito problemáticas. Por um período grande, o cliente decidia por uma funcionalidade ou componente, para na outra semana desistir. Ou então sugeria algumas funcionalidades interessantes, mas que fugiriam do real objetivo do projeto (ex: capacete 3D!). A desmotivação de ambas as partes, ao final das reuniões, era visível.
• Mudança da empresa para o laboratório. Essa decisão foi bastante criticada por todos os integrantes da equipe. Na empresa, a equipe mantinha-se mais focada e produtiva. No período ainda estava sendo implantado o SCRUM, o que causou uma grande mudança no projeto. A mudança para o laboratório reduziu muito a concentração, foco, comprometimento e a produtividade da equipe. Isso foi dito pelos próprios.
• Comunicação ineficaz. A comunicação foi sempre um problema no projeto. Diversas decisões eram tomadas sem que os envolvidos tivessem conhecimento. Recursos específicos do projeto eram solicitados para outros projetos, decisões de escopo eram tomadas sem consulta a equipe e gerência, poucos sabiam ao certo o que o outro deveria fazer, papéis e responsabilidades eram incertos. A comunicação foi bastante maximizada com a utilização do SCRUM, isto sendo bastante evidenciado pela equipe.
• Mau uso de alguns recursos. Por diversas vezes ocorreu um mau uso dos recursos do projeto. Financeiramente falando, o projeto poderia ter sido mais bem planejado e executado (algumas compras foram feitas na correria, devido aos prazos). Também ocorreram situações onde recursos do projeto (materiais e humanos) foram usados em outros projetos, com perda de foco e tempo. Além disso, a equipe poderia ter utilizado com mais responsabilidade alguns recursos do projeto, como ocorreu no caso onde o Valter, por acidente, formatou o seu “home” do computador. Não ocorreu uma perda crítica de conhecimento, porém o tempo para restaurar isso foi bastante grande para a situação em que o projeto se encontrava.
• Aumento dos salários como motivação. Isso foi uma lição aprendida na prática, embora pudesse ter sido evitada. O aumento dos salários, que foi usado como questão motivacional, não surtiu o efeito desejado. Em um projeto como o Agritec, o impacto só foi sentido devido ao atraso no cronograma. Porém, deve-se evitar isso. A motivação se dará por diversos outros fatores como técnicas de empowerment, feedback, etc.
• O projeto em segundo plano, em algumas vezes. Por diversas vezes, mesmo com alguns prazos apertados, a equipe decidiu por dar prioridade aos estudos e a questões pessoais em detrimento ao projeto. Isso gerou por um período, um certo mal estar, mas por pelo menos uma vez, um feedback da gerência foi suficiente para a retomada. Porém, o sentimento de que “poderia ter havido maior comprometimento” ficou evidente.

O que foi bom

• O coordenador segurou as compras no início. A decisão de segurar as compras no início do projeto, indo contra a ansiedade da equipe, foi excelente. Diversos componentes solicitados, na época, se mostraram inúteis no projeto, o que seria um gasto desnecessário.
• Saída de alguns membros da equipe. Alguns membros da equipe (não terão os nomes citados) reduziram os conflitos dentro do projeto, o que melhorou o foco e a cumplicidade.
• Mudança do laboratório (antigo) para a empresa. A mudança para a empresa possibilitou a equipe sentar junto. A comunicação melhorou e o comprometimento também, apesar de algumas ressalvas no período “pré-SCRUM”. O ambiente de trabalho melhorou consideravelmente.
• Reunião semanal de pesquisa. Uma reunião semanal, no início do projeto, foi uma idéia válida para alinhar a pesquisa de todos. Infelizmente algumas pessoas não levavam a sério, o que tornava esta reunião apenas uma burocracia. A idéia foi melhorada posteriormente.
• Mudança do foco (não produzir o GPS). A idéia inicial de produzir um GPS felizmente foi abortada. Dificilmente teríamos uma precisão decente para o projeto. A idéia foi abortada logo, o que evitou a perda desnecessária de tempo.
• Produção do documento de concepção. Embora tenha sido detalhado demais, o documento possibilitou naquele momento a consolidação da pesquisa inicial realizada. Além disso, serviu como nivelamento para possíveis novos integrantes. De ruim, apenas o tempo que se levou produzindo o mesmo e também o caráter “completo” que ele possuía, com muitas informações que não seriam aplicáveis com o tempo.
• Feedback aplicado na parte inicial do projeto. Infelizmente por apenas uma vez, o Flávio e o coordenador realizaram um feedback com a equipe. A idéia foi de entrevistar cada membro da equipe para identificar problemas e necessidades que a equipe enfrentava. Foi interessante e útil para identificar conflitos, até então não conhecidos. A idéia de usar o feedback foi elogiada pela equipe.
• Primeira versão do SCRUM. A implantação do SCRUM pelo Flávio teve um impacto extremamente positivo. Ficou muito mais claro para todos quais eram suas responsabilidades, quem estava sub ou super alocado, a comunicação melhorou muito e a freqüência também. A primeira versão do SCRUM foi uma versão adaptada (que não é exatamente como deveria ser o SCRUM) com uma taskboard onde havia nomes (linhas) e situação da tarefa (colunas). Reuniões diárias e retrospectivas foram utilizadas com sucesso (veja abaixo).
• Reuniões diárias. As reuniões diárias foram uma das grandes mudanças que ocorreram para maximizar a comunicação do projeto. Através das três perguntas que cada pessoa da empresa respondia (na 1ª versão, inclusive os não integrantes do projeto) que eram “O que você fez ontem? O que pretende fazer para hoje? Quais seus impedimentos?” possibilitou criar cumplicidade na equipe e também a realidade de todos saberem o que o colega ao lado estaria fazendo. A implantação de um horário fixo para a reunião, no início dos trabalhos, fez com que a freqüência passasse a ser muito maior, evitando o “trabalho em casa”. Foi possível identificar alguns focos de problemas também, que foram resolvidos com o tempo. Além disso, segundo a própria equipe, as reuniões melhoraram a cobrança interna entre eles.
• Descontração no ambiente de trabalho. O “carro-chefe” desse item é o cofrinho em forma de porco, que foi comprado com a idéia de que quem chegasse atrasado nas reuniões pagaria 50 centavos ao porco. O dinheiro, no final do mês, era revertido na compra de comes e bebes para uma confraternização e retrospectiva do projeto (que ocorreu muito pouco, apenas duas vezes). O porco serviu para deixar o ambiente mais leve e divertido, e contribuiu muito para manter a moral da equipe elevada. Deve-se estudar para buscar alternativas!
• Retrospectivas. As primeiras retrospectivas foram importantíssimas para avaliar a situação do projeto, seja em relação ao escopo, cronograma e processos, seja em relação a equipe, comunicação e infra-estrutura. Logo na primeira retrospectiva foi evidenciado que a infra-estrutura da empresa, para a produção do projeto, era quase nula. Faltavam ferramentas e materiais simples (como canetas para o quadro branco). Também foi possível identificar as necessidades das equipes (descontentamentos, por exemplo) às necessidades do projeto, sempre que possível. As retrospectivas, posteriormente, acabaram ERRÔNEAMENTE ficando em segundo plano. Mas a última, que avaliou o projeto e gerou este documento, foi muito bem sucedida.
• Melhora na infra-estrutura. Este era um dos maiores problemas do projeto: a falta de material e ferramentas para a realização de diversas tarefas. Por muito tempo, por exemplo, ocorreu uma improvisação absurda com a utilização de canivete suíço e até moedas, como chave de fenda. A partir da primeira reunião de retrospectiva onde isso ficou evidente, o Flávio solicitou a equipe que levantassem tudo o que precisaria para o projeto. Após a listagem completa, deliberadamente foi com um membro da equipe até uma loja especializada onde comprou todos os itens da lista. De um dia para o outro a empresa possuía ferramentas para o projeto (e outros também). Isso ocorreu por diversas outras vezes. Talvez não tenha sido a forma ideal (pode-se ter gasto a mais em alguns itens – o ideal seria pesquisar preços), mas naquela situação específica a mudança precisava ser rápida. E o resultado foi excelente.
• Visita do pessoal da agricultura (clientes finais). A possibilidade de conversar diretamente com os usuários finais do projeto fez com que fosse possível ter uma visão bem mais próxima da real necessidade do projeto. O escopo foi priorizado e modificado para atender ao máximo as necessidades dos agricultores. Ter uma aproximação junto aos usuários finais é sempre uma excelente idéia para agregar aos projetos. Graças à visita foi possível identificar que as trajetórias retilíneas não poderiam atender as necessidades deles. Essa informação possibilitou a abertura do escopo para trajetórias curvilíneas.
• Visita à Empresa Especializada no assunto. Assim como no caso do pessoal da agricultura, a empresa especializada foi uma grande parceira no projeto, trazendo idéias inovadoras que o produto poderia possuir. A maioria acabou não podendo ser implantada, mas possibilitaram a citação como funcionalidades futuras, dando um caráter inovador ao produto.
• 2ª versão do SCRUM. A implantação da segunda versão do SCRUM, agora mais aderente a prática real, tornou o processo mais auto-suficiente e seguro. Algumas técnicas novas foram aplicadas e garantiram excelentes resultados.
• Planning Poker. Essa foi uma das técnicas que foram utilizadas na 2ª versão do SCRUM. Foi usada apenas uma vez, mas possibilitou a visualização por parte da equipe e do cliente de como os dois pensamentos da complexidade do projeto estavam distantes. A maioria das funcionalidades era tida como “simples” pelo cliente e como “difíceis” pela equipe. Essa técnica auxiliou o cliente a desistir de algumas idéias e funcionalidades para a versão inicial do projeto.
• Finalização do 1º protótipo do painel. A realização deste primeiro protótipo começou a ser definida com a melhora na infra-estrutura do projeto. Foi um grande marco no projeto ter esse protótipo funcionando, pois evidenciou que estávamos no caminho certo e que toda pesquisa não havia sido em vão. A necessidade de ter algo tangível em um projeto ficou claramente exposta aqui. Além disso, possibilitou a realização dos primeiros testes reais.
• Contato com empresas para solução Kalman. O contato com empresas especializadas, em forma de parceria, possibilitou o abandono da idéia de usar a tecnologia de Kalman no projeto o que, segundo os próprios donos da empresa, era inviável devido ao alto custo e complexidade.
• Uso do Doxygen como documentação de software. A utilização do sistema “Doxygen” para documentar o software do projeto foi muito boa. O sistema gera uma documentação com base nas funções e comentários direto no código, o que facilitou muito a manutenção do projeto. Ele também acabou forçando a equipe a comentar muito o código, o que tornou um código que seria bastante complexo em algo um pouco mais “tragável”.
• Mudanças internas no laboratórioA mudança de alguns mestrandos de dentro do laboratório para fora tornou o ambiente um pouco mais favorável à concentração. Infelizmente, segundo a equipe, ainda não está o ideal.
• O sucesso da feira que apresentou o produto. A realização de um evento como marco no projeto, como foi a feira realizada no início de Julho/08 se mostrou como uma excelente forma de motivar o time a atingir o resultado. O bom planejamento que foi realizado para o dia, com a finalização do protótipo físico (para demonstração), a criação de um programa que simulava o projeto, textos e banners informativos e um vídeo demonstrando todo o processo de criação tornou o projeto um dos mais bem planejados e representados na feira, sendo bastante elogiado pelos avaliadores.
• O comprometimento com a deadline, pela equipe. Nos dias finais que antecederam a feira citada acima, a equipe não se preocupou em trabalhar inclusive à noite e sábados e domingos para entregar o projeto funcional. Isso demonstrou uma capacidade de comprometimento da equipe, com o projeto, que deveria ser um exemplo. A decisão de fazer isso partiu da própria equipe. Muito embora por diversas vezes o projeto tenha ficado em segundo plano (devido a situações pessoais e de estudos), essa demonstração de comprometimento demonstrou como um projeto pode deixar de ser apenas trabalho para se tornar parte da realização pessoal de uma equipe.

Conclusão

Apesar de esta retrospectiva ter sido realizada pelo gerente do projeto e por dois membros da equipe, com a ausência do coordenador e de outro membro, ficou demonstrada a importância da realização de uma retrospectiva para analisar o projeto durante um período. Diversas questões problemáticas poderiam ter sido solucionadas se fossem identificadas mais rapidamente. E diversas questões benéficas poderiam ter sido potencializadas se tivessem sido percebidas com mais antecedência.

Para os próximos projetos as retrospectivas devem ser feitas mais frequentemente e, além disso, as lições relevantes devem ser documentadas e divulgadas para as demais equipes. Algumas lições poderão auxiliar a todos a atingirem um padrão de processo, além de evitar erros comuns que já possam ter sido cometidos por outras equipes.

Neste processo de retrospectiva do projeto poderia ter identificado planos de ação para os problemas levantados, mas nessa retrospectiva específica isso não foi utilizado. Porém é importante pensar em planos de ação para evitar que problemas ocorram ou voltem a ocorrer, funcionando como uma espécie de gestão de riscos do projeto.

No final, a equipe que participou da retrospectiva levantou 24 problemas e 27 coisas boas que ocorrem no projeto (algumas não citadas aqui no post do blog).

O case que me inspirou

Este post foi um dos que me inspiraram a usar o SCRUM. Confesso que, junto com um artigo que eu li na época, fiquei fascinado com os resultados que eu poderia atingir com o SCRUM. Não vi apenas o lado técnico do projeto, mas muito mais a questão anímica (comportamental) que a mudança causaria.

O Phillip Calçado publicou este relato que até hoje é citado como referência.

Felizmente, o meu blog também tem tido o mesmo reconhecimento. E a idéia é realmente essa: mostrar a todos interessados que aplicar SCRUM (ou mesmo alguns conceitos dele) não é nenhum bicho de sete cabeças. Qualquer um pode e o resultado quase sempre será bacana.

O post é este aqui:

http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

Sugestão para "intranet"

Amigos,

estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.

Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.

Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:

- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.

Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.

Fica a sugestão :)

Palestra "Scrum in Hell - Implantando agilidade em ambientes difíceis"

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Salve pessoal,

Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.

O link para download é este.

Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.

A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)

Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.

No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.

Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.

Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!

O link para download da apresentação é este.

Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.

Um grande abraço

É hoje a palestra!

Hoje é a palestra que irei dar ao público aqui em Porto Alegre entitulada: "SCRUM IN HELL - Uma abordagem prática da aplicação do SCRUM em ambientes difíceis". O nome é mesmo para instigar :)

Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.

Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)

Depois conto como foi.

---------------------------

Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.

Tomara que tudo corra nos conformes...

Implantando o SCRUM a conta-gotas.

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Não existe dúvida que a implantação de qualquer metodologia (ou prática ou padrão) requer um pré-requisito principal para funcionar: o apoio da direção.

De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.

Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.

Observação importante: essa é a minha opinião :)

Vamos lá

1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.

2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.

3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.

4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).

5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.

E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.

Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)

São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!

Abraços

SCRUM como cultura... e não superficial

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

É comum a gente encontrar artigos na internet criticando o Agile e até mesmo o próprio SCRUM, em particular. Até mesmo em discussões esse assunto é recorrente. Eu considero que quem critica o SCRUM, na maioria dos casos (vale ressaltar), tem uma visão MUITO superficial do que os processos ágeis sugerem.

Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.

Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!

Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.

Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.

Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.

Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.

Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...

Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.

Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:

- Nao vi nenhum de voces acompanhando o desenvolvimento disto com o Beltrano e/ou Sicrano (os dois da equipe atual) na ultima semana. Nao adianta simplesmente passar as tarefas para eles e nao acompanhar o desenvolvimento diario delas, assim como as dificuldades que eles estao tendo. Onde esta o scrum?

- Voces como gerente de projetos devem saber como as coisas sao/foram implementadas, pois voces sao a memoria da equipe. Se desenvolvedores saem da equipe, isto, em principio, nao deveria afetar em nada o trabalho em relacao a parte tecnica.

- Sempre falei que qq sistema deveria ser modular e de facil re-adaptacao. O codigo objeto deve ser realizado segundo as metodologias de projeto adequadas para que isto nao ocorra mais. Nao podemos ficar sempre tendo que reaprender codigo de outros. Onde foram para as metodologias de projeto? engenharia de sw?

Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.

SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.

Sobre cursos, palestras, blog...

Pelo visto, estou me tornando um "disseminador" de Agile. :)

Isso é muito bacana. Sempre é legal disseminar lições e experiências. Mas eu tenho os pés no chão.

Certa vez escutando um podcast do Ricardo Viana Vargas, um dos maiores nomes de gerenciamento de projetos no Brasil, ele falou uma coisa que eu sigo ao pé da letra: "Não tente vender aquilo que você não sabe".

Se formos ver, isso é corretíssimo. Uma pena que existam pessoas que fazem isso... uma pena para a própria pessoa, pois normalmente ela é desmascarada logo de cara.

Nas palestras e "workshops internos" que eu tenho feito, eu sempre deixo claro que estou apresentando a minha visão de agile, baseado nas minhas experiências e aprendizados (seja na prática, seja na teoria, seja nas discussões nas listas). Mas eu NUNCA tento me passar por "mago" ou o "bambambam" do SCRUM.

O meu próprio blog foi feito com o intuito de divulgar as minhas experiências, mostrar que ser gerente de projetos (iniciante - quando eu comecei o blog) e em ambientes "hostis" (pesquisa, micro e pequenas empresas) não é um bicho de sete cabeças. É difícil, sim. Mas a gente aprende... com erros e acertos.

Eu sigo essa filosofia. Exponho a minha vivência, a minha visão. Não pretendo nunca ser um xiita e dizer que "tenho a fórmula mágica para a solução dos seus problemas!".

Fico feliz em receber feedback de leitores, felizes com as experiências que eu exponho aqui. Mas tenham isso em mente: o que eu faço não é certo nem errado. É apenas a minha interpretação de agile, baseado no meu ambiente de trabalho.

Fuja de formulismos, e busque você também moldar o agile conforme as suas necessidades e situação.

Um abraço!

Index Cards e Planning Poker para download

Caros amigos!

Estou disponibilizando (em formato PPT - powerpoint) o modelo de Index card que eu utilizei abaixo. Basta imprimir em folhas A4 que você terá 2 index cards por folha :)

O download é aqui.

E também estou disponibilizando uma versão da Planning Poker para download, em PPT. Ele é similar a esse:



A carta "1" indica que a user story é muito pequena, e portanto deve ser anexada a outra story.
As cartas "2, 3, 5, 8 e 13" são os valores para trabalhar com as estimativas.
A carta "21" indica que a user story é muito grande e deve ser quebrada em duas.
A carta do "alien" indica que a pessoa não faz a menor idéia de uma estimativa para aquela story (por exemplo, um cara de hardware estimando um módulo de software).
A carta da "taça" indica que a pessoa quer dar um tempo para descansar.

É bem simples de fazer. O slide 1 é a frente e o 2 é atrás. Leve em uma gráfica e peça para eles fazerem frente e verso. Use o espaço em branco ali para colocar o logo da sua empresa, se quiser. Mas atenção, quando for imprimir, exclua a marcação pontilhada do slide 2. Ele é apenas um guia para você colocar o seu logo. A impressão não ficará igual se você deixar a linha pontilhada.

Faça o download aqui.

Espero que gostem!

Abraços

SCRUM para resgatar o projeto!

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje tivemos nossa reunião para começar o sprint. Não foi uma reunião oficial, daquelas em que passamos o dia planejando e tudo mais. Mesmo assim tivemos definições importantes.

Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".

Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:



(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos

A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:

SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING

O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.

O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:

X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)

O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".

As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)

O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.

O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".

As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.

Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:



Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).

O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.

Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:

- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento

E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:

- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso

Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.

Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:

- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)

E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)

Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.

O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)

Um abraço!