Month: abril 2013

TDC 2013 – Florianópolis

 The Developers Conference 2013, um evento organizado pela Globalcode

Estou muito feliz em avisar a todos que minha palestra sobre Continuous Deploy foi selecionada para o TDC de Florianópolis. O tema é: Os desafios da entrega contínua, você está preparado?

Nessa palestra teremos um debate interessante sobre a prática, bem como mostrar como as empresas fazem isso na realidade. Abaixo tem um pequeno resumo:

Embora muitas pessoas nem mesmo saibam, estão usando práticas que nasceram no XP, só que com outra roupa, outra cara, um pouco mais fashion. Nessa palestra vamos falar de uma só, a integração contínua e sua evolução, a entrega contínua (do Lean).
Vamos conversar sobre os desafios que envolvem essa prática, como preparar a sua equipe, seu produto e principalmente seu cliente para tudo ocorra com o mínimo trauma possível.

Para quem quiser participar tem palestras em várias trilhas. Para ver a trilha Agile clique aqui. Para ver as demais trilhas, com excelentes temas também, clique aqui.

Sobre spikes

Spiked_War_Club__85853.1333504552.1280.1280A minha motivação para esse post foi que essa semana um amigo veio me perguntar sobre o assunto. Portanto esse post é praticamente a transcrição do que expliquei naquele dia. Como tudo o mais nesse post, reflete a minha visão sobre assunto, que vai muito além do descrito pelos órgãos oficiais.

Spike são quase User Stories, exceto pelo fato de que não se sabe exatamente no que ela vai dar. Pense no spike como uma história sobre a qual você não pode se comprometer por não ter informações ou conhecimento sobre o assunto. Por exemplo, uma equipe de desenvolvimento de um ERP precisa ler informações de uma balança eletrônica para acrescentar esses dados em uma nota fiscal, ou mesmo controlar o quanto será transportado no caminhão. Enfim, esse time nunca lidou com algo semelhante, portanto precisa pesquisar, testar algumas possibilidades e enfim ter uma visão mais clara sobre o que precisa ser feito, até mesmo como.

Podem ser estimados? Eu acabei respondendo essa com outra pergunta, se não seria exatamente por que não sabemos toda a informação necessária para poder estimar e realizar determinada história que o criamos? Portanto, spike não deveria ter uma estimativa em story point ou que seja, mas sim, precisa ter é data pra acabar. Após esse timebox, de posse de mais informação sobre o assunto o time pode finalmente estimar com mais propriedade. Isso pode ser dias, horas, semanas, o quanto o PO e o Time acordarem que seja o adequado. Ao final desse prazo, o mesmo se encerra, atingindo algo tangível ou não. O objetivo pode ser uma prova de conceito, uma pesquisa, uma leitura de uma documentação, o que for.

O conceito básico é: não sabemos o que é, ou como fazer ou as duas coisas, por isso precisamos descobrir pra poder estimar corretamente. Pode acontecer (já vi isso), que no final do spike, parte da implementação já esteja feita, então o time só precisa estimar pra fazer o restante.

Por que limitamos um timebox para o Spike? Não poderíamos buscar até achar a solução? Infelizmente para todos nós, o orçamento nunca é infinito (quem me dera fosse). Portanto é importante estabelecer prazo muito bem definido, para que a busca pela solução não se transforme em uma cruzada pelo Santo Graal.

É importante ser cuidadoso e guiar o time para que, como já citei antes, não é por que descobrimos o martelo, tudo virou prego. Toda história tem um nível de incerteza inerente a ela e mesmo assim podemos dar uma estimativa aproximada. Se um história extrapola esse nível (que não está definido, vai do sentimento do time, de sua segurança), essa tem altas chances de se transformar em spike. Times menos maduros ou muito inexperientes tendem a usar spikes a revelia, como forma de se proteger ao invés de se comprometer com estimativas.

Qual a diferença entre realizar um spike e fazer uma análise? Spike pode envolver implementação, mas pode haver programação que não resulte em produto. Entenda como um tempo pra testar algo, uma idéia, ou buscar mais informações para formar essa idéia. Uma metáfora interessante é que estamos testando uma hipótese. A diferença entre spike e analise é que análise é algo prévio pra determinar o “o que” precisa ser feito. Spike tem muito mais relação com o time determinar “o como”, o que na verdade é o seu domíno.

Finalizando spikes não são coisas complexas ou ferramentas maravilhosas para a solução de um determinado problema. É apenas o time assumindo que não entende o suficiente de determinado assunto e indo buscar o máximo de informações antes de dar qualquer parecer.

Sobre martelos e pregos

Era uma vez um menino que fazia brinquedos, assim como eu ou você em nossa tenra infância. Sua ferramenta era a criatividade. Apenas ela.

Com ela, papel virava avião, galho virava varinha de condão e o mundo ficava mais divertido aos seus olhos. Digo aos seus olhos, pois qualquer adulto não entenderia a relação existente entre os objetos do mundo real e o imaginário daquele menino. Seu mundo não tinha limites. Sua capacidade de criar era infindável.

Um dia, seu pai resolveu que era hora de aumentar a sua caixa de ferramentas, até então só composta de imaginação, presenteando com um martelo velho que já não se usava mais.

A partir daí, seu mundo se abriu. Novos brinquedos surgiram, como pequenos robôs com retalhos de madeira, carrinhos com restos de rolamentos inúteis e por aí foi. Os brinquedos mais simples, como o papel e a varinha perderam a graça e seu gosto foi se afunilando por brinquedos mais elaborados, feitos com seu habilidoso martelo que ganhara de presente.
Conforme o tempo passou, outras ferramentas se somaram e com cada uma o menino descobria novas possibilidades.

Percebia que para criar carros melhores, precisava serrar aqueles retalhos de madeira e então veio o serrote. Percebeu que para que os movimentos de seu robô ficassem mais precisos, seriam necessários articulações parafusadas. Ao seu arsenal enfim se somavam então furadeira, parafuso e chaves de fenda.

Assim o menino cresceu feliz e se tornou um adulto versátil. Pois aprendeu que ter a ferramenta adequada para determinada situação é sempre o certo a se fazer.

Ok, o que quero dizer com essa história? Simples. Não é porque você aprendeu que existe o martelo, que tudo daqui para frente é prego. Não é por que você aprendeu sobre Java, que essa linguagem se aplica a todo projeto, não é porque você aprendeu Kanban, que o Scrum ficou ultrapassado ou ruim. Toda a ferramenta tem o seu valor e sua correta aplicação. Aprenda a usar todas e você saberá o momento certo de aplicar cada uma delas.

O Controle Sutil

Hoje se vê muitas pessoas falando que praticam Scrum. Isso quase sempre é bom. Eu vejo pessoas que têm um quadro bonito, que pregam post-its nele, que fazem reuniões curtas e em pé todos os dias. Eu vejo pessoas que planejam de tempos em tempos suas iterações e que têm papéis declarados dentro de seus departamentos, que por força da literatura chamam de “times”. Como disse meu amigo Edson, o que no fim das contas estamos fazendo é simplesmente entregar porcaria mais rápido.

Claro que estou generalizando, existem pessoas que compreendem e sabem como fazer de uma equipe um time ágil. Mas como é isso? Porque mais e mais pessoas falam tanto de ágil sem saber do que realmente falam? Como levar a essas equipes a razão de tudo isso?
Continue reading

O espírito de grupo

Vejam o quanto é perigoso se implantar algo sem o devido conhecimento, maturidade e experiência.

Antes de começar é importante esclarecer minha opinião sobre esse assunto: CMMI e Scrum podem conviver muito bem juntos. Mas é fundamental que você saiba o que está fazendo.

Existe uma área do CMMI chamada medição e Análise. Nela trata-se de fazer um acompanhamento rigoroso e ativo do projeto usando-se as métricas pré estabelecidas no Plano de Medição e Análise. Simples não? Não. Como medir uma equipe ágil? Horas trabalhadas? Story points entregues?

Para dizer a verdade, eu não estou pensando em dar essa resposta. Só falo de uma diretriz fundamental. Uma que nem mesmo é citada no Manifesto ágil, imagino que por estar subentendida. Não faça estimativas e medições sobre a produção das pessoas. São equipes, mais que isso, times.

Ao fazê-lo, trocamos cooperação por competição. As pessoas vão passar a se perguntar porque devem ajudar os demais colegas se isso só atrapalha as suas metas individuais.

Claro que há o risco inerente. O de cairmos numa experiência socialista, como já citei num post anterior. Mas as vantagens superam as dificuldades. Ao colaborar, indivíduos aprendem mais, assim como nossa espécie evoluiu pela troca de gametas, desenvolvedores crescem trocando informações. Num ambiente colaborativo não temos super heróis. Claro que há os destaques e a equipe os respeita, mas o foco é o crescimento do todo, não da parte.

Mas se você conhece um pouco de história sabe que os heróis são os que vão a frente na batalha, portanto, os primeiros que morrem. Quando a batalha acaba, como você quer estar? Morto ou no exército vencedor?