Posts Tagged ‘Experiências’

2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi

Friday, December 4th, 2009

Já se passaram pouco mais de 2 anos desde que começamos a trabalhar oficialmente com Scrum e Agile na Globo.com e um pouco mais de 2 anos e meio desde que a coisa toda começou de fato.

Depois de trabalhar diariamente com processos ágeis e uma porção de times diferentes na Globo.com, minha sensação é a daquele dito popular que diz que quanto mais você sabe de alguma coisa, mais você descobre que tem que aprender. De tempos em tempos surgem idéias novas excelentes e as vezes são coisas tão simples que eu me pergunto porque nunca tinha pensado nelas. Ou então algumas idéias que não deram certo no passado voltam à tona, são colocadas em prática e passam a funcionar muito bem. Sempre que eu acho que já aprendi como alguma coisa funciona alguém aparece com uma idéia melhor e me prova que eu estava errado em achar isso.

Me lembro quando perguntei lá no início para o Boris Gloger sobre o tempo que levaria para as coisas acontecerem. Na época ele falou que para uma empresa do tamanho da Globo.com certamente levaria de 2 a 4 anos para as coisas mudarem de fato. Eu achei um exagero e que ele estava louco, mas era eu que não tinha noção do tamanho da coisa toda. Ele estava certo.

Infelizmente eu não tenho uma história romântica para contar e estaria mentindo se dissesse que as coisas são maravilhosas depois que você adota Agile, Scrum ou o que quer que seja. Muito pelo contrário, os problemas começam a aparecer e tudo fica caótico. As vezes a quantidade de problemas chega a ser enlouquecedora e minha insônia aumentou consideravelmente depois disso. Mas eu não tenho nenhuma dúvida de que os processos ágeis são os que mais se adaptam às características de projetos de desenvolvimento de software, mais do que qualquer outra coisa que eu já tenha usado. Tivemos muito mais sucesso do que em qualquer outra iniciativa na história da empresa e as coisas acontecem muito mais e muito melhor do que aconteciam antes, mas mesmo assim ainda temos um caminho muito longo pela frente.

Hoje eu consigo entender com mais clareza o real sentido do empirismo que tanto se fala. Mesmo com pilhas de livros sobre desenvolvimento ágil na minha prateleira, eu olho para trás e vejo que o processo de “tentativa e erro” foi muito mais importante para o meu aprendizado do que qualquer teoria. Várias coisas escritas nos livros deram certo para alguns times e não deram para outros, e no fim das contas o que ficou foi uma mistura de todas essa experiências. Fomos fazendo as coisas, vendo o que dava certo ou errado, mudando, adaptando e seguindo em frente. Hoje não dá pra dizer que a Globo.com usa Scrum, XP, Lean ou Kanban. Você pode encontrar todos os seus sabores preferidos de Agile por aqui, às vezes misturados e até mesmo bem customizados e diferentes do tradicional.

Nesse tempo todo vivenciei muitos problemas, muitos sucessos, muitas derrotas, muitas falhas e muita mudança. Eu queria poder dizer que encontrei o Santo Graal do desenvolvimento ágil, mas dificilmente isso existe. E se existir, provavelmente o da minha empresa será diferente da sua e por ai vai. Porém, eu posso falar de algumas coisas que eu aprendi e que talvez possam ser úteis para outras pessoas e empresas:

Você sempre estará em transição.

Basicamente eu não acredito mais em transição ágil como eu já li por ai, que parece uma coisa que tem inicio, meio e fim. Hoje eu percebo que sempre se está em transição. Sempre surgirão projetos novos com características diferentes e sempre será necessário ajustar e se adaptar. Isso tudo fora que as pessoas e os times também mudam, e ai começa tudo denovo. É um trabalho que nunca acaba.

É muito fácil começar a fazer Scrum, o difícil é vencer a resistência das pessoas.

Grande parte do meu tempo nesses anos foi investido em quebrar barreiras e a resistência das pessoas. E não estou falando de diretores ou gerentes, às vezes os piores problemas estão dentro dos times. Os mais diversos tipos de problemas acontecem: tem gente que tem medo de trabalhar em par e expôr suas fraquezas para os outros, tem gente insatisfeita na empresa que envenena iniciativas, enfim, acontece de tudo. É muito importante trabalhar com pessoas bem intencionadas, comprometidas e que acreditam no que estão fazendo e que acreditam que as coisas sempre podem (e devem) ser melhoradas.

As pessoas precisam estar felizes.

É importantíssimo que a empresa reconheça seus talentos, que eles ganhem o que merecem e que eles trabalhem num ambiente agradável. Ninguém trabalha direito e dá 100% do seu potencial se não estiver feliz e satisfeito com a empresa. Pessoas infelizes e insatisfeitas podem acabar com um time inteiro, por isso a empresa tem que dar o primeiro passo e dar todas as condições para que isso não aconteça e, quando acontecer, resolver o problema o mais rápido possível.

Se o foco das pessoas for em “fazer telas”, “testar” ou “escrever software”, você está perdido. O foco das pessoas deve ser o produto, e não a sua função.

Muito desenvolvedor não gosta de fazer teste exploratório “porque isso é função do cara de QA”. Muito designer não gosta de fazer CSS e HTML porque isso é coisa de “desenvolvedor de front-end”. Bullshit! Imagine se um zagueiro está com a bola na linha do gol e diz que não vai fazer o gol porque não é atacante? Não tem essa, o foco é ganhar o jogo, entregar o produto, deixar o cliente feliz, não importa fazendo o que. Com o tempo você descobre a receita do time (quantidade de pessoas de cada especialidade) para que as pessoas passem a maior parte do tempo fazendo sua especialidade, mas isso não significa que elas não devem fazer ou entender de outras coisas.

Escalar não é facil. Aliás, se for possível, não escale nunca.

Times ágeis funcionam melhor quando são pequenos, porque o universo de pessoas é menor e a comunicação é melhor, as pessoas confiam mais no resto do time e por aí vai. Quando o número de pessoas e de times aumenta, a comunicação fica problemática e isso gera uma porção de problemas, desde coisas triviais como conflitos de merge até coisas mais complexas de resolver como falta de confiança, dificuldade em mudar de direção, dificuldade de passar a visão do produto, pessoas querendo aparecer mais do que outras e por aí vai. Faça um teste: reuna 30 amigos seus e tentem combinar um lugar para almoçar em no máximo 2 minutos. Repita o teste com 3 amigos e compare os resultados. Foi possível combinar um único lugar de forma unânime? Quanto tempo levou? Quais foram os conflitos de interesse? Qual foi o nível de barulho, stress e insatisfação das pessoas? Ter mais pessoas ajudou a fazer com que a decisão fosse mais rápida ou mais demorada? Talvez esse não seja o melhor exemplo do mundo mas vai ser bem fácil de perceber como times grandes se organizam com muito mais dificuldade.

Boas práticas de engenharia e desenvolvimento ágil como automatização, testes, refatoração, programação em par, integração contínua e TDD são fundamentais, imprescindíveis, inevitáveis, totalmente obrigatórias.

Todos os grandes saltos de qualidade e produtividade que demos na história da evolução da Globo.com foram porque essas práticas foram intensificadas e usadas com mais disciplina, e todas as vezes que elas não recebem a devida importância a velocidade diminui, a produtividade baixa e o time entrega menos (e com mais defeitos).

Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco).

As regras são excelentes quando você não sabe o que está fazendo. Depois que aprender, quebre-as.

Geralmente quando as pessoas começam com Agile o que se recomenda é que você siga as regras à risca por algumas iterações até que você aprenda e que o processo esteja “no sangue”, e só depois que possíveis customizações devem ser feitas. Muita gente confunde isso com “sempre siga as regras à risca”. Por exemplo, hoje alguém me convenceu numa conversa que o Sprint Planning 2 do jeito que um determinado time estava fazendo estava bem inútil, uma grande perda de tempo. A sugestão foi fazer uma coisa mais “just-in-time”, ou seja, na hora que a história começar a ser desenvolvida. Muita gente pode falar que “ah, mas não é assim que o Scrum funciona” ou o clássico “aqui na empresa nós não fazemos desse jeito”. Se você tem um bom motivo para mudar as regras do jogo, discuta o assunto com o time e implemente as melhorias. Não existe essa coisa de “as regras do Scrum”, existem times produtivos com alta capacidade de adaptação e em constante evolução ou times que passam 50% do tempo discutindo o processo e não deixam o cliente feliz.

Trabalhar num ambiente ágil é muito muito muito mais divertido.

Acabei de passar quase 40 dias de férias e em conferências. Muita gente estaria odiando voltar para o trabalho depois disso, mas eu gostei. Quando eu cheguei hoje na empresa depois de mais de 1 mês a minha mesa já não era mais minha e eu não achava meu computador. O escritório mudou totalmente e o time que eu estava está todo misturado. Quando eu entrei na sala as pessoas estavam em pé discutindo, rabiscando no quadro e o barulho estava alto pra caramba. Depois de contar as novidades, de almoçar e de alguns updates, passei o resto da tarde programando em par numa tarefa que nem eu e nem o meu par faziamos idéia de como resolver, mas juntos descobrimos como fazer e resolvemos o problema. Foi um dia caótico porém muito produtivo e muito divertido, como a maioria dos que eu tenho. Tudo muda muito e está em constante evolução, e cada dia é um novo desafio. Se você gosta de ficar escondido atrás da “baia” e tem dificuldades em dividir o seu teclado com um amigo, recomendo fortemente que você não use Agile.

Agile não é o Santo Graal.

Nenhum processo de desenvolvimento (ágil ou não) é perfeito. Muita gente gosta, muita gente não gosta, alguns não se adaptam, outros se motivam a cada dia com os novos desafios e é assim que as coisas funcionam. <ironia> “Agile é tão perfeito” </ironia> que quando as coisas dão errado é muito mais fácil culpar o seu processo e reclamar que ele não funciona. Bullshit! Como o Jeff Patton fala, as pessoas fazem isso porque o processo não vai se defender de você e porque é muito mais dificil assumir e enxergar os problemas de verdade. Uma das chaves de ser bem sucedido nesses processos é entender que eles são apenas ferramentas muito simples e que se não estão funcionando é porque você precisa encontrar e resolver algum problema da sua empresa, do seu time, das pessoas ou do que quer que seja. Não bote a culpa no processo.

As pessoas são mais importantes que o processo. Foco nas pessoas.

São elas que fazem tudo acontecer. Quanto mais agentes de mudança sua empresa puder ter, melhor. A empresa tem que reconhecer essas pessoas e motivá-las para que elas motivem ainda mais seus pares e assim por diante. É preciso dar liberdade para elas criarem, tentarem coisas novas e errarem sem medo de serem repreendidas. Faça de tudo para que todos estejam felizes e motivados. Resolva os conflitos. Coloque tudo em pratos limpos. Trate todos com respeito e como amigos. Faça as pessoas crescerem e deixe (e ajude) que elas tenham visibilidade dentro da empresa. De todas as coisas que eu vi até hoje, nada é mais eficaz do que ter as pessoas certas do seu lado.

Nada disso é definitivo e eu posso mudar de opinião a qualquer momento sobre qualquer uma dessas coisas. Aliás, hoje numa conversa aprendi que é ótimo mudar de opinião, porque significa que você aprendeu alguma coisa nova/diferente que te fez pensar de uma forma nova/diferente e, portanto, você evoluiu. Fica então a última:

Crie sua opinião, aprenda mais e mude sua opinião. Esteja em constante evolução.

Louco por automatização!

Wednesday, April 15th, 2009

Ultimamente tenho feito uma brincadeira que todos ficam achando que eu sou maluco. Costumo dizer que o meu objetivo a cada dia é tentar fazer com que todo o trabalho que eu faria em 2 dias seja feito em apenas 1 hora, e assim eu posso aproveitar as outras 15 horas escrevendo posts no meu blog, estudando coisas novas, jogando Guitar Hero ou até mesmo dormindo (se eu não tivesse insônia).

Parece loucura mas não é. Quando eu ainda era um jovem Padawan um dos vários mentores que tive ao longo da minha vida me ensinou uma lição muito valiosa.

Há bastante tempo atrás, observando um amigo trabalhar percebi que ele passava horas e horas automatizando cada pequena tarefa que faziamos na empresa. Se precisavamos criar uma entrada no DNS, tinha um shell script para fazer isso. Se precisavamos fazer backup, existia um script para fazer isso e ele até já funcionava sozinho. E no caso dele, ele tinha scripts prontos até para facilitar fazer as compras do mês no Zona Sul online (isso é sério mesmo). Basicamente ele era obcecado por automatizar tarefas.

Como ele passava a grande maioria do tempo automatizando coisas, um dia eu resolvi perguntar porque ele perdia tanto tempo fazendo aquilo. Não era apenas uma obsessão sem sentido, tinha um fundamento muito simples. Ele disse: “Quanto mais você trabalhar para tornar a sua vida mais fácil automatizando as tarefas repetitivas, mais você terá tempo livre para fazer mais coisas que você quiser! Fazendo assim você vai ter tempo de sobra para investir nas tarefas realmente desafiadoras, que vão exigir toda sua intelectualidade e que vão te dar prazer. É por isso que eu sempre trabalho com a meta mental de reduzir todo o trabalho que eu faria em 2 dias para 1 hora, e fazendo assim todo o dia e a todo momento as coisas simplesmente vão acontecer; e eu vou produzir muito mais que qualquer um sem absolutamente nenhum esforço”.

Eu sempre achei isso genial! Obviamente ele não passava 15 horas de bobeira fazendo outras coisas. O objetivo era apenas estabelecer uma meta agressiva de automatização de tarefas para conseguir alcançar um nível onde muitas coisas podem ser feitas com pouquissimo esforço, e a brincadeira de “passar 15 horas de bobeira” serve apenas para ilustrar e tornar o exemplo mais divertido. :)

Desde essa época eu venho usando essa abordagem para o máximo de coisas que eu consigo. Meu problema sempre foi que eu nunca tentei de verdade ser tão extremo quanto ele (ao ponto de automatizar até as compras do mês), mas de uns meses pra cá eu tenho sido cada vez mais e mais radical e tenho me tornado cada vez mais produtivo (apesar de ainda ir fisicamente no mercado fazer compras).

“Radical” e “extremo” são palavras que têm uma conotação muito negativa, mas ser radical ou extremo pode ser muito útil quando se tem um propósito como esse (ou então para se fazer uma abordagem como a que eu postei sobre porque eu não gosto de escrever comentários no código).

Em projetos de desenvolvimento de software, os ganhos com uma abordagem desse tipo são impressionantes. No último projeto que comecei (e que estou atualmente) propús para os meu amigos do time que tentassemos fazer uma abordagem desse tipo – radical e extrema – em relação a automatização. A regra que criamos juntos e concordamos ficou bem simples: se alguma coisa precisou ser feita mais de uma vez então ela necessariamente deve ser automatizada.

Depois de aproximadamente 3 semanas de trabalho as coisas funcionam mais ou menos assim:

  • Todos os testes unitários e de aceitação são automatizados e podem ser rodados com apenas um comando (desde criar/atualizar banco de dados até subir Selenium Server, colocar o sistema em um estado conhecido, executar os testes e depois desfazer isso tudo).
  • Toda vez que é feito um push para o Git, o build server roda primeiro todos os testes unitários automaticamente.
  • Se qualquer um dos testes falha, uma sirene toca automaticamente alertando que alguém fez besteira.
  • Se os testes passam, o Capistrano faz um deploy em cada uma das máquinas do ambiente de testes de aceitação e dispara a execução de todos os testes de aceitação nesse ambiente.
  • Se o banco de dados mudou, o upgrade do schema de banco de dados também é feito automaticamente.
  • Finalmente, quando todos os testes passam, é feito um deploy automatico para o ambiente “live”, que tem por objetivo ser o lugar onde se pode ver a última versão de desenvolvimento que passa em todos os testes.
  • Se precisarmos colocar a aplicação em produção, um script fará isso da forma mais simples, segura e instantânea possível.
  • Se um desenvolvedor precisar desenvolver nesse projeto, basta baixar o código do repositório e com um script tudo se configura e funciona automaticamente.
  • Se for preciso criar uma nova tela de cadastro padrão desse sistema, basta rodar um script e ela será quase toda criada automaticamente (apenas as particularidades precisam ser configuradas).
  • … e por aí vai.

Todas essas coisas juntas não foram simples de serem feitas, muito pelo contrário, foi bastante trabalhoso (e até chato algumas vezes). Porém, o resultado não deixa dúvidas: o ganho de performance é absurdamente alto e vale a pena cada minuto gasto investido.

No início levamos muito tempo automatizando tudo mas depois dos primeiros 3 ou 4 dias qualquer coisa passou a levar bem menos tempo do que levaria. Em pouquissimo tempo (algo em torno de 3 semanas, como eu disse) já é possível perceber resultados concretos dessa abordagem. Apesar de ainda termos um monte de coisas para melhorar, nossa agilidade para fazer coisas simples e vê-las funcionando é muito grande!

Não gaste seu nobre tempo fazendo coisas repetidas e chatas. Automatize tudo que puder! Faça os scripts trabalharem pra você!!!