codebits 2014

Posso dizer que comecei este ano de 2014 em grande!

Fui eleito speaker do SAPO Codebits com a talk “Pair Programming“.

Inclusivamente com honras de primeira página: https://codebits.eu/ (secção “Who’s going to be talking”).

O tema é algo que me apaixona e depois de ver em acção fiquei adepto incondicional.

É possivelmente a prática de XP que mais aprecio.

Não vou falar sobre o tema aqui para não ser um spoiler… 🙂

Nesta edição vou “viver” literalmente dentro do recinto já que não vou trabalhar nesses dias… podendo disfrutar o evento 24x7x3 (o evento é non-stop durante 3 dias).

Espero ver-vos lá.

Até para a semana.

Scrum vs Kanban vs Lean

Em 2009 Henrik Kniberg ao escrever um artigo no seu blog sobre Scrum e Kanban nunca pensou que iria cunhar um conceito (na minha opinião) completamente errado e que após 4 anos continua para durar.

Acho interessante como ele começa por escrever o seu post a dizer que havia muito “buzz” sobre Kanban (em 2009) e se olharmos para Portugal a verdade é que (infelizmente) ainda pouco se fala. Em Portugal, temos realmente uma comunidade bastante forte de Scrum. Temos também uma comunidade crescente de Agile (a tentar de certa forma abraçar a comunidade de Scrum). Agora comunidade de Kanban ainda não sei de nenhuma.

Voltando ao Henrik e ao titulo deste post… o que o Henrik escreveu no post dele (e que depois deu origem a um livro) com o titulo “Scrum vs Kanban” era que o Scrum e o Kanban poderiam ser usados em conjunto (suprimindo as suas lacunas / best of both worlds). Ora se olharmos para o titulo do post dele, o que é sugerido (à primeira vista) é que o Scrum esta contra o Kanban (e vice-versa) e que apenas poderíamos usar um ou o outro.

Como o ser humano é preguiçoso, muitas pessoas na comunidade Agile olhando apenas para o titulo trataram logo de separar as aguas e dar origem a uma certa rivalidade entre os “seguidores” de Scrum e os “crentes” em Kanban e Lean. A rivalidade cresceu de tal forma que inclusivamente o autor sentiu-se na “obrigação” de vir a terreiro dizer que o titulo tinha sido mal interpretado e que ambos os “métodos” podiam (e em alguns casos deviam) ser usados em conjunto.

A verdade é que depois do Scrum, do Kanban e do Lean se darem a conhecer ao mundo e de já terem sido bastante explorados, a rivalidade mantém-se e pelo que percebo está para durar.

Inclusivamente, Ron Jeffries, co-autor do eXtreme programming, manifestou este mês a sua desilusão por ter testemunhado que no maior evento Agile do mundo, #Agile2013 em Nashville (EUA), organizado pela Agile Alliance, os participantes estavam mais preocupados em demonstrar que a sua metodologia fetiche (Scrum, Kanban, Lean, etc.) era melhor do que as outras do que propriamente trabalhar em conjunto para tirar proveito do melhor de cada uma delas.

Tal como Henrik teve oportunidade de dizer em 2009 e agora Ron em 2013, o Scrum, o eXtreme Programming, o Kanban e o Lean não são incompatíveis. Inclusivamente existe a forte convicção de que combinando um pouco de cada uma destas “ideologias” podemos atingir um alto nível de eficiência.

O que eu penso sobre este assunto (e apesar de simpatizar mais com Scrum e eXtreme Programming do que com o Kanban e o Lean) é que a comunidade Agile é pequena de mais para este tipo de rivalidades e clivagens. Tal como qualquer grupo, separados pouco valemos mas juntos valemos muito.

Não entendo o interesse que existe por de trás destas separações ou se é apenas um fenómeno humano ficarmos “cegos” com algo que (realmente) apreciamos ignorando tudo o que está à nossa volta.

Sinceramente não sei… agora que é uma pena a malta de Scrum não se dar com a de Kanban (e vice-versa) e passarem mais tempo a discutirem uns com os outros em vez de trabalhar em conjunto… lá isso é.

Pode ser que isto mude no futuro mas já nisto há tempo suficiente para saber que é pouco provável. 😦

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.