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?

Para quem já leu e tentou praticar Scrum sabe que o processo é simples. Não tem grandes segredos e é pouco prescriptivo. Não há muitas regras e com um pouco de treino qualquer time pode executar o processo. Estou falando de executar e não manter. Se existe algo que é capaz de manter um processo de maneira contínua e duradoura é a mudança cultural. E como sabemos isso não é feito por processos, mas sim por valores.

Para quem estudou as origens da “agilidade” conhece o artigo escrito pelos professores Takeuchi e Nonaka. Nesse artigo, escrito há quase 30 anos, eles estudaram o desenvolvimento de alguns produtos em equipes de alto desempenho. Com isso, conseguiram reunir quais eram os valores praticados pelos membros dessas equipes. Destes, eu vou falar hoje só de um, o controle sutil, por julgar que é um dos mais difíceis de se aplicar.

Como diz meu guru, Heitor, eu posso lhe explicar ou fazer você sentir…

Para fazer você sentir, vamos contar uma história. Na última semana, estávamos finalizando um projeto quando percebemos que um requisito havia passado sem ser atendido. O desenvolvedor dessa equipe rapidamente pensou em uma solução, coisa realmente simples, que em menos de duas horas foi implementada. Quando ele foi me mostrar a solução, percebi uma falha perigosa na lógica dele. Expliquei e dei a minha própria solução. Fui taxativo ao dizer que aquela seria a única solução possível, algo que logo o mesmo argumentou. Debatemos por alguns minutos até um sino tocar em minha cabeça me lembrando dos valores dentro da agilidade. Foi quando dei minha conclusão ao debate dizendo:

Está bem, eu vou tomar um café, vou deixar você batendo cabeça um pouco até eu voltar.

Sinceramente, eu nem café queria. Quando eu voltei, ele havia elaborado a lógica perfeita para aquela situação. Melhor que a solução inicial, melhor que a solução que eu propus, melhor do que eu podia ter imaginado.

Entenderam? Não? Então vou contar um nova história.

Essa mesma equipe aceitou uma história pesada, difícil de ser executada, mas aceitou o desafio. No primeiro dia, nenhuma tarefa pronta e o nosso burndown nem se mexia, no segundo dia a coisa parecia ir para o mesmo caminho. Foi quando intervi, sugerindo uma determinada configuração do time, no qual um par continuava a codificação, outro desenvolvedor executava os testes. Assim a coisa começou a melhorar e no dia seguinte essa equipe já se reorganizou, realizando um rodízio entre os papéis até que encontraram a configuração ideal e no fim do sprint, tivemos o nosso sucesso do desafio vencido.

Agora você percebeu? Nas duas situações eu poderia ter comandado, exercido a autoridade que meu cargo me permite e feito a equipe se dobrar a minha vontade, fazendo aquilo que eu julgava como sendo melhor. Mas não. Podia ter tido um final diferente, que talvez não fosse o ideal, mas tivemos sorte nos dois casos. Se bem que em equipes ágeis, o erro deve ser permitido, pois incentiva o aprendizado, mas isso é tópico para outro post.

O controle sutil é isso, conduzir as pessoas, dar as dicas de como atingir uma meta, mas sem mandar. Impor a autoridade de um cargo de gerência ou coordenação pode simplesmente conduzir a resultado já previsto, censurando o processo crítico e criativo desses times. Assim, a grande sacada é iniciar o processo e acompanhar para que nada possa impedi-los de performar o melhor de si.

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?

Scrum Bolívia Day 2013

A Massimus estará patrocinando o Scrum Bolívia Day 2013, assim como fizemos em anos anteriores.
Nesse ano apresentaremos a palestra “Por que usamos Scrum?”. Através de exemplos demonstraremos porque fizemos essa escolha e como usa-la de maneira correta para extrair o melhor desse framework.
Será dia 30 de março, em Santa Cruz de La Sierra. Estaremos fazendo todo o registro e posteriormente publicaremos tudo aqui e na nossa página no facebook.

Uma experiência socialista

Um professor de economia na universidade Texas Tech disse que nunca reprovou um só aluno antes, mas tinha, uma vez, reprovado uma classe inteira.

Esta classe em particular tinha insistido que o socialismo realmente funcionava: ninguém seria pobre e ninguém seria rico, tudo seria igualitário e “justo”.

O professor então disse:

- Ok, vamos fazer um experimento socialista nesta classe.. Ao invés de dinheiro, usaremos suas notas nas provas. Todas as notas seriam concedidas com base na média da classe, e portanto seriam “justas”.

Com isso ele quis dizer que todos receberiam as mesmas notas, o que significou que ninguém seria reprovado. Isso também quis dizer, claro, que ninguém receberia um “A”

Depois que a média das primeiras provas foram tiradas, todos receberam “B”. Quem estudou com dedicação ficou indignado, mas os alunos que não se esforçaram ficaram muito felizes com o resultado.

Quando a segunda prova foi aplicada, os preguiçosos estudaram ainda menos – eles esperavam tirar notas boas de qualquer forma. Aqueles que tinham estudado bastante no início resolveram que eles também se aproveitariam do trem da alegria das notas. Portanto, agindo contra suas tendências, eles copiaram os hábitos dos preguiçosos.. Como um resultado, a segunda média das provas foi “D”. Ninguém gostou.

Depois da terceira prova, a média geral foi um “F”. As notas não voltaram a patamares mais altos, mas as desavenças entre os alunos, buscas por culpados e palavrões passaram a fazer parte da atmosfera das aulas daquela classe. A busca por “justiça” dos alunos tinha sido a principal causa das reclamações, inimizades e senso de injustiça que passaram a fazer parte daquela turma. No final das contas, ninguém queria mais estudar para beneficiar o resto da sala.
Portanto, todos os alunos repetiram o ano… Para total surpresa!!!

O professor explicou que o experimento socialista tinha falhado porque foi baseado no menor esforço possível da parte de seus participantes. Preguiça e mágoas foi seu resultado. Sempre haveria fracasso na situação a partir da qual o experimento tinha começado.

“Quando a recompensa é grande”, ele disse, “o esforço pelo sucesso é grande, pelo menos para alguns de nós. Mas quando o governo elimina todas as recompensas ao tirar coisas dos outros sem seu consentimento para dar a outros que não batalharam por elas, então o fracasso é inevitável.”

“É impossível levar o pobre à prosperidade através de legislações que punem os ricos pela prosperidade.
Para cada pessoa que recebe sem trabalhar, outra pessoa deve trabalhar sem receber.
O governo não pode dar para alguém aquilo que não tira de outro alguém.
Quando metade da população entende a idéia de que não precisa trabalhar, pois a outra metade da população irá sustentá-la, e quando esta outra metade entende que não vale mais a pena trabalhar para sustentar a primeira metade, então chegamos ao começo do fim de uma nação.
É impossível multiplicar riqueza dividindo-a.”

atribuído à Adrian Roger, 1931.

Esse foi mais um texto muito bom enviado pelo meu irmão, Jefferson.

Uma fábula indiana

Certo dia, um príncipe indiano mandou chamar um grupo de cegos de nascença e os reuniu no pátio do palácio. Ao mesmo tempo, mandou trazer um elefante e o colocou diante do grupo.

Em seguida, conduzindo-os pela mão, foi levando os cegos até o elefante para que o apalpassem. Um apalpava a barriga, outro a cauda, outro a orelha, outro a tromba, outro uma das pernas…

Quando todos os cegos tinham apalpado o paquiderme, o príncipe ordenou que cada um explicasse aos outros como era o elefante.

Então, o que tinha apalpado a barriga disse que o elefante era como uma enorme panela. O que tinha apalpado a cauda até os pelos da extremidade, discordou e disse que o elefante se parecia mais com uma vassoura.

“Nada disso”, interrompeu o que tinha apalpado a orelha. “Se ele se parece com alguma coisa é com um grande leque aberto.”.

O que apalpara a tromba deu uma risada e interferiu:

“Vocês estão por fora. O elefante tem a forma, as ondulações e a flexibilidade de uma mangueira de água…”

“Essa não”, replicou o que apalpara a perna, “ele é redondo como uma grande mangueira, mas não tem nada de ondulações nem de flexibilidade, é rígido como um poste…”

Os cegos se envolveram numa discussão sem fim, cada um querendo provar que os outros estavam errados, e que o certo era o que ele dizia. Evidentemente cada um se apoiava na sua própria experiência e não conseguia entender como os demais podiam afirmar o que afirmavam.

O príncipe deixou-os falar para ver se chegavam a um acordo, mas quando percebeu que eram incapazes de aceitar que os outros podiam ter tido outras experiências, ordenou que se calassem.

“O elefante é tudo isso que vocês falaram, explicou. Tudo isso que cada um de vocês percebeu é só uma parte do elefante. Não devem negar o que os outros perceberam. Deveriam juntar as experiências de todos e tentar imaginar como a parte que cada um apalpou se une com as outras para formar esse todo que é o elefante.”.

Moral da estória:
A experiência das coisas que cada homem pode ter é sempre limitada. Por isso, a sensatez nos obriga a levar em conta também as experiências dos outros para se chegar a uma síntese.

A pessoa, o ser humano, apresenta muitas facetas, Existe o risco de polarizar a atenção em alguma delas, ignorando o resto. Fazendo isso, estaríamos repetindo os cegos da parábola. Cada um ficaria com uma visão unilateral e parcial.

Para obtermos uma visão o mais integral possível do que é uma pessoa, devemos reunir, numa unidade, os numerosos aspectos que podem ser observados no ser humano. É o que devemos tentar fazer, cientes, porém, de que uma visão completa, como diria o príncipe indiano, é sempre impossível.

Recebido por e-mail

Talentos

Um dia desses, estava trabalhando em código complicado, difícil mesmo. Levei alguns dias para resolver o problema, envolvia coisas que eu ainda não conhecia, paradigmas “novos”, ao menos para mim e outras coisas que me ferveram a cabeça. Quando conclui o trabalho, todo orgulhoso do meu feito, fui comentar com meus entes sobre o “feito” e ouvi a seguinte resposta:

Graças a Deus, que resolveu esse problema para você.

Juro que me senti mal com a resposta. Afinal senti meu esforço reduzido a nada. Bastava que eu me sentasse, que uma divindade superior veria a minha dificuldade e solucionaria para mim o problema como mágica. Realmente me desagradei com aquilo, pois senti que o mérito daquilo tudo deixou de ser meu e passou a ser de alguém com quem eu não posso competir.

Nesse momento, me lembrei da parábola dos talentos, descrita no evangelho de São Mateus. Nela, um patrão vai viajar (imagino eu ser por um longo período) e deixa para seus três criados uma certa quantidade de talentos (que também suponho ser algo como a moeda da época). Ao retornar dois, que receberam mais talentos, os souberam multiplicar. O que recebeu menos, por achar pouco, escondeu e manteve a quantidade que tinha.

E com essas palavras me confortei. Afinal, eu tinha a minha parcela de mérito sim. Por mais que eu tivesse habilidades com as quais eu nasci, dadas por qualquer força superior, eu as desenvolvi, eu busquei ser melhor naquilo que faço e nessa semana resolvi um problema muito difícil, com os talentos que eu multipliquei.

Acredito ser esse o caminho da vida: evoluir. Jamais ficar parado. Se algo caiu do céu, já foi, já aconteceu, agora está na hora de correr atrás e multiplicar, crescer, evoluir. Por mais que se conheça o seu trabalho, mude, saia da zona de conforto. No meu contexto, aprenda uma nova linguagem, um novo paradigma, uma nova tecnologia. Isso pode nem ser imediatamente aproveitável, mas com certeza o tornará melhor naquilo que é seu foco.

Sou cristão católico, talvez por isso essas palavras pareçam um pouco carregadas de fé. Mas independente de sua crença, aceite uma verdade: você tem talentos (independente de onde vieram) e cabe a você, somente a você decidir o que será feito deles, enterrar ou multiplicar.

O que você escolhe?