[Open Source] Workshops

Depois de ter partilhado as perguntas que faço numa entrevista de Scrum Master e nos KPIs que costumo ter em conta em equipas ágeis venho hoje divulgar os “meus” workshops. Digo “meus” (entre aspas) porque nenhum deles é de minha autoria. Todos os workshops que coloco aqui são workshops com que me deparei desde 2010 e que achei interessantes o suficiente para fazerem parte da minha toolbox.

Aqui estão eles (nomes e slides em Inglês):

Espero que achem estes workshops úteis. 🙂

Se tiverem dúvidas em relação ao propósito ou à dinâmica de qualquer um deles digam-me que tenho todo o gosto em esclarecer.

Até para a semana.

the scrum experience

Após estarmos à um tempo considerável a usar Scrum aqui fica o status da experiência.

O primeiro contacto da equipa com o Scrum não foi muito pacífico (embora também não tenha sido nenhuma desgraça), pois apesar de ter transmitido que a presença de um quadro com as tarefas de um projecto não tinha como propósito ser um “big brother”, a verdade é que senti alguma resistência à mudança, pois o white board era encarado como uma ferramenta de controlo/subjugação. Constatei que o white board (inicialmente) em vez de se tornar um facilitador tinha-se tornado uma fonte de stress.

Mas na verdade, e tal como esperava, após a equipa habituar-se à presença do white board (uma questão de dias), bem como das daily scrums, o trabalho começou a fluir de uma forma muito interessante e sem dúvida que nos tornamos bastante mais eficientes.

Com as nossas daily scrums e com o white board conseguimos de forma rápida e simples aferir em que ponto do projecto estamos, que dificuldades estamos a sentir no desenrolar das actuais tarefas, o que está feito, o que está por fazer e o que está realmente feito (validado).

Inclusivamente tivemos um projecto em que o cliente quis fazer uma versão beta e como tínhamos todas as tarefas claramente identificadas foi muito simples definir que features seriam possíveis para uma versão beta e que features apenas estariam disponíveis para a versão final. E é neste tipo de situações em que o Scrum se torna uma mais valia e se destaca das demais metodologias de gestão de projectos.
Apenas deixamos de utilizar o white board quando entramos em fase de testes. Aí usamos uma ferramenta open-source, chamada redmine, para fazermos toda a gestão do fluxo de reporting de bugs (desde o momento em que o bug é reportado até à sua resolução e validação por parte do cliente).

Neste momento estou muito satisfeito com o Scrum e a equipa também já o perfilhou. Estamos todos (a equipa) satisfeitos com o Scrum. As “coisas” mudaram para melhor e somos hoje uma equipa mais eficiente.

Gostaria só de deixar um aviso à navegação: o Scrum não é uma silver bullet, ou seja, não é a solução para todos os males de uma equipa. É apenas uma excelente forma de gerir e desenvolver projectos. Li uma frase na internet que explica da melhor forma o que acabei de escrever: “A great team will have great success with or without Scrum. A shitty team will still produce shit with scrum. Just that the shitty scrum team will see it earlier than the shitty no-scrum team”.

Até para a semana.

scrum na optimus

Comecei há cerca de um mês a fazer scrum aqui na Optimus.

Não é um scrum bíblico mas posso dizer que é o scrum à nossa moda! 🙂

Quase que dava uma receita.

Aqui ficam os ingredientes:
1 quadro branco (obtido de forma caricata);
100 post-its (amarelos);
1 caneta para o quadro (para identificar as sprints e fazer separações);
1 scrum master (cabe-me a mim a honra);
1 product owner (cabe-me novamente a mim a honra);
várias equipas de projecto;
boa disposição (de toda equipa) q.b..

E a preparação:
Primeiro colocamos o quadro branco (scrum board) num local bem visível para toda a equipa.

Depois com a caneta separamos o quadro em 5 colunas: “Todo”, “In progress” (que subdividimos em “Going” e “On hold”), “To verify” e “Done :-)”. Inicialmente não tínhamos a coluna “In progress” dividida mas assim que tivemos um post-it bloqueado sentimos logo a necessidade de criar uma coluna que nos diga quando uma tarefa está parada. Qualquer post-it ali parado não é bom sinal e requer a nossa atenção. Na coluna de tarefas terminadas recomendo o smile “:-)” porque qualquer post-it que chegue a essa coluna é motivo de satisfação de toda a equipa.

De seguida colocamos em linhas as nossas sprints (que são os nossos projectos) escrevendo o nome da sprint e o respectivo código interno (código que utilizamos para identificarmos os emails relativos à sprint/projecto).

Passamos agora para a estimativa de cada sprint (temos várias a decorrer) e as suas user stories. As nossas estimativas são orientadas à user story e não à sprint, pois desta forma é só colocar os post-its, na coluna “Todo”, com o nome de cada user story e com a indicação da sua estimativa no quadro.

Todos os dias, logo ao início da manhã, fazemos a nossa standing meeting/daily scrum, ou como gosto de lhe chamar, os nossos 5 minutos intensos de reunião diante do quadro branco. Durante uns breves 5 minutos fazemos, de forma animada, informal e descontraída, o status diário da sprint onde abordamos o que foi feito no dia anterior, o que iremos fazer hoje e dificuldades com que possivelmente tenhamos em mãos.

Após todas as reuniões do dia abrimos um excel onde tenho a burndown chart de cada projecto e actualizo com o status obtido. Desta forma conseguimos visualizar o progresso e principalmente o ritmo do projecto. Estamos atrasados? Estamos adiantados? Com que ritmo estamos a trabalhar? A nossa burndown chart tem resposta para todas estas questões.

O resultado final são sprints/projectos terminados a tempo e horas altamente orientados ao cliente e aos seus requisitos. No fim garantidamente ficamos todos felizes, a equipa por ter a performance desejada e o cliente por ter os resultados esperados.

Recomendamos servir o vosso “cozinhado” acompanhado de Extreme programming (XP), principalmente pair programming (2 developers a trabalhar no mesmo computador), de Test-driven development (TDD) (programação orientada aos casos de sucesso e insucesso que se pretende testar) e de Coding standards (regras e/ou boas práticas de programação).

Por fim polvilhem tudo com metodologias AGILE a gosto.

Claro que existem muitos pontos que podemos melhorar e/ou fazer de forma diferente, mas sou da opinião que o Scrum é uma receita de autor, onde cada um o aplica de acordo com a sua realidade. A implementação do Scrum não é por si só um objectivo, mas sim um meio para atingirmos o verdadeiro objectivo que são projectos bem sucedidos.

E vocês também fazem Scrum?

Até para a semana.