A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos tradicionais geralmente são bastante prescritivos e você tem que documentar tudo que estiver definido no processo (que geralmente é muita coisa). Você não pensa no que está fazendo, simplesmente segue o que foi definido e escreve documentos. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que você não pode documentar nada. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande engano. Em projetos ágeis você pode documentar sem problemas desde que seja necessário de fato. A idéia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Já participei de projetos onde documentar foi extremamente necessário. Por exemplo, uma vez trabalhei num projeto com vários times onde nem sempre os desenvolvedores estavam no mesmo espaço físico, portanto era preciso documentar alguns pontos chave da arquitetura e ambiente para que todos pudessem trabalhar sem problemas. Também já participei de situações onde meu time desenvolvia componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times pudessem trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso. Documentamos apenas o que fazia sentido ser documentado.

Enfim, há diversas situações onde você pode precisar documentar por diversos motivos. Para te ajudar a decidir quando documentar e como documentar, veja a seguir alguns princípios do que chamei de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observei ao longo do tempo em diversos projetos de que participei. Certamente existe muito mais do que isso, mas vamos lá:

Documentação não substitui comunicação

Em projetos tradicionais, muitos documentos são usados para comunicar idéias entre o Analista e o Programador, com QA e por ai vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos (como os motivos acima). Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. Documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros do time.

Documentação não pode ser perecível

Documentação tem que ser leve e não pode ser perecível, ela deve ser durável. Se você documenta algo que precisa ser modificado todo dia, existem grandes chances de você esquecer de atualizar a documentação e ela passa a ficar desatualizada. É melhor não ter documentação do que ter documentação errada. Além disso, se você precisa mudar a documentação toda hora significa que você está se aprofundando demais nos detalhes, e então a documentação vai “quebrar” a cada linha de código que você escrever. Quando estiver documentando, pergunte-se: “daqui a algum tempo essa documentação ainda será válida?”. Faça documentação durável. Não entre num nível de detalhe que te faça mudar a documentação o tempo todo (a não ser que você realmente precise disso – e mesmo assim pense se não dá pra fazer de outro jeito, por exemplo, automaticamente).

Documente o necessário, e não mais do que isso

Assim como você deve implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso, você deve documentar apenas o que for necessário e nada mais do que isso. Não perca tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem que ter um motivo, documentar sem uma necessidade real não faz sentido

Documentar tem que ser fácil

Documentar tem que ser rápido, não pode dar trabalho. Use ferramentas como wikis, geradores de documentação (como o Sphinx) e por aí vai. Se for fácil documentar, as chances de você fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa online/web), use ferramentas para publicar a documentação automaticamente. Se a documentação for fácil de ser acessada (e tiver busca) ela fica mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros do time possam documentar. Por exemplo, se você escolher usar LaTeX, você está reduzindo as chances de designers documentarem, pessoas de negócio e outros membros não-programadores de um time.

Documentação faz parte do “Definition of Done”

Se o seu projeto precisa de documentação por qualquer motivo, a documentação deve fazer parte da “Definition of Done”. É melhor documentar no momento que as histórias estao sendo desenvolvidas – quando o conhecimento está fresco na cabeça – do que acumular um monte de débito e ter que pagar de uma vez só – quando você vai precisar conferir um monte de coisas que já estão prontas para documentar com precisão, o que vai te dar mais trabalho e consumir mais tempo.

Documentação no código pode ser um “code smell”

“Code smell” é um sintoma no seu código que pode indicar um problema maior. Muitas vezes códigos precisam ser documentados porque eles são desnecessariamente complexos. Sempre que possível prefira refatorar o código para ele ficar mais fácil de entender ao invés de escrever comentários (até porque muitas vezes o código muda e o comentário fica lá desatualizado, e isso acaba mais atrapalhando do que ajudando). Tenha uma boa suite de testes (uma suite bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software seja mais bem escrito e não mais bem documentado.

Quando você começa com desenvolvimento ágil não é só o processo de desenvolvimento de software que muda mas também vários detalhes de como a sua empresa funciona. Por exemplo, é muito difícil imaginar um time ágil que funcione com “comando-e-controle”. Os times são auto-gerenciados, o que implica em um outro estilo de gestão. Ao invés de chefes que cobram, aparecem os líderes-servidores, que dão todos os recursos possíveis para que seus times possam trabalhar e tomar decisões. A base da pirâmide é que passa a decidir e não mais o topo, porque eles são os mais indicados por deterem o melhor conhecimento para fazer isso. Em alguns casos mais extremos em empresas mais modernas como a Semco, são os próprios funcionários que contratam seus gerentes.

Ou seja, quando falamos de métodos ágeis, por mais que estejamos nos referindo aos métodos ágeis de desenvolvimento de software existem uma porção de outros conceitos e filosofias que acabam entrando no mesmo barco por serem tão intimamente relacionados.

Tenho um exemplo para tentar explicar melhor onde eu quero chegar. Uma vez eu trabalhava numa empresa de tamanho razoável que, como várias outras desse porte, tinha um tradicional departamento de RH. Num dia eu tive um problema bem urgente e precisei da ajuda do pessoal do RH. Quando fui conversar com eles, duas coisas desagradáveis aconteceram. Primeiro, eles me trataram mal e como se estivessem fazendo um favor pra mim. Segundo, eles disseram que meu pedido só seria atendido em alguns dias, porque eles tinham muitas coisas importantes para fazer. O que acontece é que minha filha estava muito doente, eu tive um problema com meu plano de saúde e eles não estavam liberando meu atendimento por nada. Um time de RH com a “cultura ágil” saberia em primeiro lugar que, dado que eu sou o principal “usuário” deles, eu mereço atenção, respeito e os meus problemas são os problemas deles. As urgências dos funcionários deveriam ser mais importantes do que qualquer papelada que eles tenham para fazer. E em segundo, mesmo que o backlog deles fosse absurdamente grande, um assunto com tamanha severidade com certeza “furaria” a fila.

Então, quando eu digo que outros departamentos das empresas poderiam ser “ágeis”, não estou sugerindo que eles trabalhem com desenvolvimento ágil de software – o que não faria nenhum sentido – mas sim que eles usem os mesmos conceitos de liderança, times auto-organizados trabalhando num ambiente participativo, baseado na confiança e cooperação, fazendo um movimento e esforço maiores para entenderem quem de fato são seus “usuários” e quais são suas necessidades, criar visões para seus produtos e departamentos (que os ajudariam a tomar melhores decisões) e por aí vai.

Pegando esse departamento de RH que falei acima como exemplo, não seria perfeitamente aceitável que eles fizessem um exercício de personas para descobrirem qual é o perfil dos seus usuários? Não seria ótimo que eles fizessem sessões de chartering, discutissem seus valores, fizessem retrospectivas para descobrirem como melhorar seu processo e assim por diante? Imagine quão transparente e organizado seria chegar na sala deles e ver um quadro de Kanban mostrando sua linha de atividades, o progresso delas e os gargalos da equipe?

Acho que talvez isso não aconteça porque grande parte do material e exemplos disponíveis sobre esses assuntos estão formatados para pessoas relacionadas à desenvolvimento de software. Sim, existem livros como os do Ricardo Semler que estão categorizados nas livrarias como “Administração” ou “Negócios”, mas não sei porque o pessoal de Administração e Negócios não parece se interessar por esses assuntos. Porque será?

Já está na hora desse “fork” entre a comunidade ágil das empresas e as outras áreas acabar. Chega uma hora que parece que existem duas empresas funcionando totalmente diferentes dentro de uma. Precisamos trazer pessoas das outras áreas e outros níveis hierárquicos para as conferências e para o nosso mundo. Vou adorar o dia que eu for na Agile Conference e conversar com Gerentes de RH, VPs de Marketing e outras pessoas que não sejam do departamento de desenvolvimento; ou então quando for nas reuniões de grupos de usuários e não encontrar somente os “agilistas” mas também os administradores, os analistas de recursos humanos, os contadores e por ai vai.

E aí, por onde vamos começar?

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.

Amanhã será o primeiro de dois dias de tutoriais seguidos de dois dias de conferência com a participação de grandes nomes do mundo ágil como Jeff Patton, Alistair Cockburn, Mike Cohn, Jim Highsmith, Andy Hunt, David Hussman, Joshua Kerievsky, Linda Rising, Alan Shalloway e por aí vai. Para encerrar, na sexta-feira acontecerá o Agile Leadership Summit liderado pela Pollyanna Pixton.

Os próximos dias prometem!

Passadas algumas semanas encontrei denovo com essa pessoa em um outro evento. Para a minha surpresa, ela me disse que sua vida estava um inferno! Os clientes não estavam dispostos a fechar contratos de escopo negociável, eles queriam saber exatamente o que e quando os projetos seriam entregues. Eles definitivamente não quiseram trabalhar com desenvolvimento iterativo, até porque os projetos já eram bem curtos (menos de 1 mês). Pra terminar, por ser uma agência pequena a equipe é de menos de 10 pessoas fazendo com que uma pessoa precise trabalhar em 3 ou 4 projetos ao mesmo tempo. E por aí vai…

Então eu perguntei: Quantos projetos davam errado antes de você começar com Agile?
E ele respondeu: Todos os nossos projetos sempre foram bem sucedidos.
E eu perguntei denovo: Então qual é o problema que você está tentando resolver usando Scrum e desenvolvimento iterativo?
(silêncio…)
Eu novamente: Ok, já entendí. Faça o seguinte, volte para o seu processo de trabalho antigo. Não sei como é mas me parece ótimo.

Muita gente se surpreende quando eu falo isso. Só porque eu falo sobre desenvolvimento ágil não significa que eu acho que isso é a solução para todos os problemas. Se todos os seus clientes estão satisfeitos do jeito que você está trabalhando, seus projetos não falham, você faz ótimas entregas e tudo está ótimo, você não tem um problema. E se você não tem um problema, você não precisa resolver nada. E nesse caso eu recomendo: não use uma metodologia de desenvolvimento ágil só porque está na moda.

Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar. Geralmente em projetos de software grandes é muito difícil de planejar todos os requisitos de uma vez no início do projeto. Não seria impossível fazer isso mas o custo é tão alto que vale mais a pena planejar menos e ir adaptando o software e os requisitos ao longo do tempo até que ele esteja pronto. No cenário dessa pessoa, como os projetos são muito pequenos é perfeitamente possível planejar tudo antes em pouco tempo e desenvolver em seguida.

Em alguns outros casos onde os requisitos não mudam waterfall também pode fazer sentido. Por exemplo, quando você desenvolve software para o governo, toda a especificação do projeto normalmente é produzida e informada antes em um edital. Algumas vezes até o prazo de entrega já está definido. Eu pessoalmente já trabalhei em vários projetos desse tipo que deram certo, que foram entregues dentro do prazo, atendendo a especificação e sem maiores problemas. Como tudo estava funcionando, não havia motivo para pensar em outra forma de desenvolvimento que eventualmente poderia trazer mais problemas do que soluções, como no caso dessa pessoa que conversou comigo.

O que eu quero dizer com isso tudo é que não existe uma metodologia que funciona para todos os casos e todos os projetos do mundo. Assim como você deve usar a melhor ferramenta para cada problema, você deve usar a melhor metodologia para cada projeto.

No projeto que eu estou atualmente estamos quebrando vários paradigmas de desenvolvimento ágil. Estamos com times gigantes, usando quadros de Lean totalmente customizados misturados com Scrum e por aí vai. Estamos sempre analisando os resultados das iterações e replanejando nosso processo. Apesar de todos os livros dizerem que os times têm que ser pequenos, estamos trabalhando com um time de 20 pessoas que dá certo e está super produtivo. Esse é o espírito: faça o que for melhor para o projeto e o que te fizer ter os melhores resultados, não o que alguém diz que é certo ou é errado ou o que está na moda.

É perfeitamente possível desenvolver projetos bons em qualquer metodologia. Entenda qual é o seu cenário, quais são os seus problemas, limitações e aí sim decida qual é a melhor forma de trabalhar nos seus projetos.

Nas outras duas cidades percebí que minha apresentação ficou confusa porque fiz uma mistura de tecnologia com processo de desenvolvimento que eu senti que não deu muito certo. Então em Floripa decidi jogar todo o plano fora e fazer um totalmente novo, separando em duas apresentações.

Introdução a metodologias ágeis

Nessa apresentação tentei explicar metodologias de desenvolvimento ágil de software da forma mais simples e mais abrangente possível. Meu objetivo era fazer algo que pudesse servir tanto para quem nunca teve nenhum contato saber do que se trata como para quem já conhece aprender alguma coisa nova. Para isso eu fiz um paralelo com algumas historinhas e acabou virando uma apresentação bem humorada, despojada e (acredito eu) fácil de entender. Pelos comentários que li no Twitter parece que dessa vez “acertei a mão”.

No final falei de alguns livros para se aprofundar no assunto que foram:

• Agile Software Development with Scrum é o livro mais básico sobre Scrum e que descreve como funciona esse framework para gerenciamento ágil de projetos.
• Extreme Programming Explained é importantissimo para entender as práticas de XP, que são essenciais para o sucesso de projetos ágeis de software. Inclusive, é possível (e eu diria até que é mais legal) usar XP sozinho, sem Scrum. O grande problema é que XP é mais difícil de ser “vendido”, mas se você conseguir vá em frente! Leia mais sobre XP nessa excelente referência organizada pelo pessoal da ImproveIt.
• Lean Software Development, que fala sobre os princípios de Lean manufacturing aplicados ao desenvolvimento de software.
• Agile Estimating and Planning contém informações sobre planejamento de projetos e estimativas ágeis. É essencial entender esse assunto, já que é um dos mais questionados e complicados numa transição para metodologias ágeis.
• Além disso tem mais indicações de livros nesse post e esse outro post em especial (sobre o FISL) tem bastante informação, links para artigos e blogs sobre metodologias e desenvolvimento ágil.

Python Coding Dojo: O primeiro passo para se tornar um programador Python Samurai

Nos últimos meses tenho trabalhado bastante com Python e tenho gostado muito. Graças a isso e a confiança do pessoal da Arteccom no meu trabalho, resolvi fazer uma coisa bem diferente e um pouco ousada: tentar ensinar Python em apenas duas horas usando um formato de Coding Dojo! Essa apresentação foi uma cópia da minha apresentação no PythOnCampus, porém dei uma reduzida no conteúdo, adicionei uma breve introdução sobre Coding Dojo e troquei o formato para ter uma seção prática de programação.

Apesar de ter conseguido fazer uma boa introdução e passado bastante informações sobre a linguagem, é claro que o objetivo não era fazer com que as pessoas saissem de lá sabendo fazer tudo em Python. Elas apenas tiveram um primeiro contato com a linguagem, viram que não é nenhum bicho de 7 cabeças (muito pelo contrário) e ainda se divertiram programando em par no palco, fazendo TDD e resolvendo desafios de programação. Me surpreendi pela procura/interesse do pessoal e pelo feedback me parece que também deu certo.

De quebra também mostrei para o pessoal como funciona um Dojo, quais os objetivos e benefícios. É uma prática muito legal e muito fácil de fazer, qualquer um pode (e deveria) organizar um Dojo na sua empresa ou com seus amigos.

Para quem quiser saber mais sobre o que vimos:

• No site http://codingdojo.org tem informações sobre as regras de Dojo e links para uma porção de problemas legais de resolver. Para que não sabe existe um Dojo organizado por um grupo de programadores em Floripa. Ele anda meio parado mas quem sabe essa não é uma ótima oportunidade para continuar?
• Para aprender Python recomendo a leitura dos livros Learning Python (que fala do básico da linguagem), Programming Python e Python in a Nutshell (que são mais avançados). Esse último ainda não li mas me foi muito bem recomendado. Além disso há uma extensa documentação no site oficial do Python.
• Além disso falei sobre o Django, que é um framework em Python muito popular para construir websites. A melhor forma de conhecê-lo e aprender como ele funciona é fazendo o tutorial que está no site do projeto.

Não vou disponibilizar os slides porque eles em sua maioria só tem um monte de fotos e palavras desconexas que não servem pra nada sem mim, são apenas um suporte para a apresentação. Além do mais, não quero fazer spoiler para o pessoal das outras cidades.

É isso aí pessoal, obrigado pela recepção calorosa e pelo bate papo! Nos vemos na próxima!

Enquanto o Akita se diverte na Rails Conf eu fiz uma apresentação sobre Agilidade e Qualidade em projetos de software. Não vou publicar o PDF da apresentação aqui porque os slides não tem a menor graça e o menor valor se eu não estiver apresentando (já que a maioria deles são fotos e desenhos). No entanto, seguem alguns links para quem quiser se aprofundar no que falamos:

• Tem alguns livros para se aprofundar em metodologias ágeis nesse post. A maior parte das coisas que falei estão no Agile Software Development with Scrum e no Extreme Programming Explained. Também comentei com alguns sobre o Lean Software Development no final do evento.
• O “Orkut” de programadores que algumas pessoas não conheciam chama-se Github.
• E por último, tem mais informações e histórias sobre metodologias ágeis em outros posts do meu blog. Esse post em especial (sobre o FISL) tem bastante informação, links para artigos e blogs sobre metodologias e desenvolvimento ágil.

Espero que tenham se divertido como eu me diverti!

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ê!!!

Gostaria de tirar uma dúvida (ou mesmo sugestão) sobre como vcs estão trabalhando ai na Globo.com com os designers, arquitetos de informação, etc, inseridos nos times ágeis.

A empresa onde trabalho tem um “setor” de criação artística muito forte, alias, excelentes profissionais, e eles trabalham independentes praticamente do desenvolvimento.

Devido a maneira da empresa gerir seus projetos – waterfall – eles fazem toda a parte de criação e entregam um wireframe+layout de telas prontos pras equipes de desenvolvimento, ai é cada um por si.

Como estamos fazendo um processo de migração de waterfall pra desenvolvimento ágil, esse ponto específico do pessoal de criação inseridos nas equipes ágeis ainda deixa muitas dúvidas, na maneira que eles podem fazer parte dos times.

Talvez esse tenha sido um dos maiores problemas que tivemos na adoção de Scrum aqui na Globo.com, ou pelo menos é um dos problemas que têm durado mais tempo. Novamente, não acho que exista uma receita de bolo, cada time ou empresa precisa encontrar a melhor forma de trabalhar. Vou me limitar a dar algumas idéias e falar do que temos tentado fazer aqui para integrar desenvolvimento e design.

Por último, vou falar especificamente de Scrum porque é o que usamos aqui (apesar de usarmos também práticas e conceitos de XP e Lean), mas as mesmas idéias servem para outros processos similares.

O ponto de vista do processo

Do ponto de vista do Scrum, o correto seria desenhar a cada história que fosse feita somente as partes da tela necessárias para a conclusão da história.

Fazer todo o design antes nos mínimos detalhes não é o mais indicado porque para isso é preciso fazer um levantamento de requisitos para entender as necessidades e é exatamente assim que funciona a fase de análise e levantamento de requisitos do waterfall (ou seja, o que não queremos fazer).

Outro problema é que se no início de um projeto você só trabalha telas, o que você irá entregar no fim de um Sprint? Com certeza não será software funcionando e toda aquela história de antecipação do ROI vai por água a baixo.

Por fim, um dos objetivos do desenvolvimento com Scrum é produzir software de maneira iterativa e incremental. A cada Sprint deveria ser entregue uma pequena parte do produto funcionando e quando isso é feito, o Product Owner pode chegar em qualquer ponto do projeto e perceber que o investimento em mais um Sprint já não vale mais a pena como valia no início – porque as histórias que sobraram darão um retorno bem menor do que o valor investido em um Sprint – e ele pode decidir que é necessário encerrar o projeto por razões econômicas óbvias e partir para outro.

O ponto de vista do desenvolvedor

Os princípios de desenvolvimento ágil também não deixam dúvidas. Big Design Up Front (BDUF) é coisa de cascateiro, e as práticas de desenvolvimento como Test-Driven Development (TDD) fomentam justamente o desenvolvimento incremental.

Do ponto de vista do desenvolvedor ágil também é um erro desenvolver todo o design antecipadamente.

O ponto de vista do designer

Só depois de muitas conversas com o Cainã Nunes e o André Braz – dois dos melhores “criativos” que temos aqui na Globo.com – é que eu consegui entender o problema de verdade. Eu não sou nem de perto um especialista no assunto (e nem pretendo ser), mas vou tentar explicar o pouco que eu entendo.

Para entendê-los, precisamos entender a diferença entre “design de interface” e “design de UX”.

Desenhar uma tela qualquer é muito fácil. No início da minha carreira quando eu trabalhava em uma agência de desenvolvimento de sites cansei de mudar e algumas vezes até fazer layouts. Depois que você aprende a usar direitinho o Photoshop e o Fireworks é realmente muito muito muito fácil desenhar uma tela, desenhar objetos diversos e entregar qualquer coisa. Não que todos os designers façam isso, mas que é fácil fazer uma tela qualquer é.

O problema é que aqui na Globo.com nós não queremos fazer somente telas. Além do design e beleza em sí, estamos preocupados com a experiência do usuário (a famosa UX). Ao contrário de desenhar uma simples tela, projetar a UX é muito muito muito difícil. Em UX, não basta ter uma tela, ela precisa ser fácil de usar, os usuários precisam querer usá-la e a experiência de uso tem que ser memorável – porque isso fará com que os usuários queiram voltar. Isso é tão difícil de fazer que muitas vezes falhamos, mas essa é a nossa mentalidade e como queremos desenvolver nossos produtos.

Quando falamos de projetar a UX, vários fatores além do Photoshop ou Fireworks estão envolvidos (veja o experience design manifesto para ter uma idéia). Aspectos como ergonomia, sentimento e psicologia entram em cena. Alguns projetos que fazemos são testados exaustivamente com usuários comuns no laboratório de usabilidade, e mesmo assim continua difícil de alcançar o resultado que queremos.

Pense friamente e veja como todas essas “loucuras” fazem muito sentido. Independente do processo que usamos, não é isso que queremos dar para os nossos usuários nos produtos que desenvolvemos?

O problema

O problema é que para projetar a experiência do usuário, os designers acreditam que é difícil (ou impossível) pensar em pequenas partes do site e que é preciso pensar na experiência como um todo. Isso vai totalmente de encontro com a forma que o processo funciona e que os desenvolvedores trabalham…

Para ser muito sincero, eu não entendia porque eles não gostavam da idéia de ir refatorando o design e ir adaptando conforme as partes fossem sendo desenvolvidas. O que eu sempre entendi é que indivíduos e interações devem estar acima do processo, então ao invés de ficar procurando respostas no processo precisamos confiar nessas pessoas – que são especialistas no que fazem – e junto com elas encontrar uma saída.

Isso não nos exime da responsabilidade de fazê-los entender claramente como funcionam os processos e princípios de desenvolvimento ágil para que eles saibam o impacto das suas decisões e ajudem a encontrar uma forma de trabalhar que seja compatível com essa realidade.

Harmonia entre desenvolvimento e criação

Depois de muitas tentativas e erros, a forma de trabalhar mais próxima do ideal que eu consigo enxergar é uma mistura dessas três visões.

Os projetistas de UX podem e devem sempre pensar na visão do todo mas não necessariamente precisam entrar em todos os detalhes de cada uma das telas. Com a visão inicial do projeto os designers já têm muitas informações que precisam para começar a trabalhar na experiência do usuário e devem desde já pensar no produto como um todo, mas mais uma vez, isso não quer dizer que tudo precisa ser feito e pensado nos mínimos detalhes antes do projeto. Abaixo ao BDUF!

Na nossa equipe os designers têm feito sketches, wireframes e desenhos à mão para discutir funcionalidades e usabilidade. Muitas vezes isso é feito durante as discussões do Sprint planning e re-pensado algumas vezes durante o Sprint. Depois, durante o desenvolvimento, a cada história que vai sendo desenvolvida o time vai implementando junto com os designers, que vão fazendo as pequenas partes necessárias para aquela funcionalidade específica e ao mesmo tempo o design da experiência como um todo é continuamente revisto e refatorado para atender à visão do projeto.

A idéia é mais ou menos como a do cone da incerteza: no início do projeto você têm uma vaga idéia de como será na prática a experiência do usuário, e essa certeza vai continuamente aumentando até que depois de algum tempo (mais próximo do fim) você tem certeza absoluta de como ela será.

Ainda não estamos craques em fazer isso mas promete funcionar bem melhor do que tudo que já tentamos.

Concluindo

Você é realmente ágil quando não existe algum processo burocrático que te impede de fazer alguma coisa com mais eficiência. Criar um processo ou ambiente que impeça as pessoas de trabalhar ao invés de facilitá-las vai totalmente de encontro à agilidade.

Para citar um exemplo, o próprio criador do Scrum – Jeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como algo que dificulta o trabalho (torna menos ágil), portanto, a usabilidade do software tem que ser perfeita. Sendo o design tão crítico e tão importante para o sucesso do projeto, eles decidiram se organizar para trabalhar com definição de telas e criação de protótipos antes do desenvolvimento. E não adianta achar que todos os projetos devem ser assim; cada caso é um caso!

As pessoas precisam conversar mais e entender as motivações das outras e o que as levam à tomada de decisão. Quando você consegue entender de verdade o lado do outro (dos designers no meu caso) você começa a entender quais são as reais motivações para o que ele está fazendo. O designer no meu time não queria atrapalhar o processo fazendo todas as telas antes, ele simplesmente queria fazer um trabalho espetacular de usabilidade e essa era a melhor forma que ele conhecia. Fazer um trabalho excelente de UX foi exatamente o que o gerente de UX pediu para ele e é essa a direção que a empresa quer seguir. Só depois que eu me dispus a entender como funciona a cabeça dele (e de todos os outros de UX) é que eu estou conseguindo pensar de outra forma. Agora existem muito mais chances que a adaptação que estamos fazendo no processo funcione melhor.

Então, respondendo a pergunta do post: como trabalhar com os designers? Pense fora da caixa! Aqui estão algumas idéias e opiniões, mas que eu aconselho é que cada time experimente e encontre a sua resposta.

Se você ficou decepcionado com a resposta e achava que eu ia te dar uma regra para ser seguida sem precisar pensar, talvez você esteja procurando nas metodologias ágeis a resposta errada e precise de alguma outra coisa que dê isso para você.

Se fosse possível eu gostaria que você falasse um pouco de como funciona para vocês o tratamendo de incidentes em produção e defeitos. Como num ambiente ágil isso é tratado? Eles entram no backlog independente do projeto ou existe um tratamendo especial para fix/test/deploy? Alguma equipe específica faz o fix e corrige os testes unitários se for o caso?

Seria legal ter uma luz a respeito disso.

Como esse era um assunto que eu já estava para falar mesmo, aproveitei o gancho para fazer esse post.

Depois de conversar com muitas pessoas ao longo do tempo, o que eu percebí é que cada um trabalha de um jeito. Eu não acredito que exista uma forma certa ou errada de trabalhar, o que existem são formas diferentes que funcionam melhor ou pior em determinado lugar ou outro. Apesar disso, deve-se tomar cuidado para não criar alguma forma de trabalhar que viole os princípios básicos da metodologia/framework (Scrum no nosso caso). E por último, nem sempre conseguimos fazer dessa forma que vou falar, mas no geral é o que tentamos fazer.

Antes de tudo nós tentamos tratar cada tipo de defeito de acordo com sua gravidade. Para auxiliar, assim que um defeito chega para a equipe nós tentamos enquadrá-lo em uma das 3 categorias de defeitos, que para facilitar a explicação acabei de batizar de defeitos simples, importantes e gravíssimos.

Defeitos simples

São defeitos que têm pouco ou nenhum impacto para o usuário. Para citar um exemplo, nós tivemos recentemente um minúsculo defeito de alinhamento em um dos elementos da página do player do Globo Vídeos. Esse defeito não precisou ser visto imediatamente porque ele não impacta o uso do site e também quase não impacta visualmente, visto que o usuário está prestando muito mais atenção ao vídeo do que no resto.

Neste caso o Product Owner é notificado e a regra de priorização normalmente é “quanto antes corrigirmos isso, melhor”.

Defeitos importantes

São defeitos que não são tão simples como meros detalhes visuais mas que não impedem o produto de funcionar. Por exemplo, tivemos um caso que a Macromedia lançou uma nova major version de plugin do Flash e com isso descobrimos que a nossa verificação de versões tinha um problema. O resultado é que a exibição em tela cheia não funcionava corretamente em alguns casos, mas ainda assim o usuário conseguia ver o vídeo numa pop-up que simulava a tela cheia.

Neste caso temos duas opções. A primeira opção é colocar o defeito no backlog para que ele seja a primeira história a ser trabalhada no próximo Sprint. A segunda opção é como normalmente fazemos hoje em dia: o time sempre trabalha a 80~90% da sua capacidade para que quando esses incidentes aconteçam ele possa “puxar” ou assumir mais histórias – desde que todos se sintam confortáveis para isso. Caso não ocorra nenhum incidente durante o Sprint e sobre algum tempo no final, o time pega outra história qualquer que caiba no tempo que sobrou.

Defeitos gravíssimos

São defeitos que impedem o produto de funcionar. Usando mais uma vez o caso do Globo Vídeos, um defeito gravíssimo poderia ser algo que fizesse com que os vídeos parassem de ser exibidos, ou que alguma página estivesse indisponível, ou qualquer outra coisa que impeça os usuários de usarem o produto. Quando os defeitos desse tipo chegam para nós eles já passaram em 2 ou 3 níveis de suporte, então provavelmente trata-se de algum problema do software mesmo (e não de ambiente, de configuração do usuário, etc.) e precisa ser visto com a maior urgência possível.

Neste caso, o mais apropriado seria cancelar o Sprint imediatamente, planejar rapidamente, iniciar um novo Sprint com este item como o primeiro item a ser resolvido e fazer um release o mais rápido possível para corrigir o problema.

Para falar a verdade nunca tivemos esse terceiro caso depois que começamos a trabalhar de uma forma mais organizada com Scrum e cuidando cada vez mais da qualidade do que é entregue. Sendo bem realista, como trata-se de um defeito que coloca em risco a imagem/credibilidade/audiência/dinheiro da empresa, pode ser que seja mais apropriado parar tudo e dar atenção máxima ao problema sem seguir um script específico, afinal de contas o bom funcionamento da empresa deve estar sempre à frente de qualquer coisa. Se isso acontecesse, acho que eu daria o Sprint como cancelado, re-planejaria e começaria um novo Sprint.

Concluindo

Apesar de tudo isso eu pessoalmente sou favorável a corrigir todo e qualquer bug o mais rápido possível, independente de sua gravidade. Eu sou totalmente contra acumular débito técnico porque já sabemos como isso pode afetar a produtividade e velocidade do time a médio/longo prazo. Porém, como já havia dito, dadas as nossas condições e restrições essa foi a forma que melhor funcionou para a nossa realidade – e para ser franco acho que tem funcionado bem.

Sei que muitos já fizeram isso mas não poderia deixar de comentar sobre o post do James Shore sobre o declínio e queda das metodologias ágeis. Recomendo a leitura do post, ou no mínimo do resumo do InfoQ.

O ponto do James Shore é muito simples: as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que a princípio podem não fazer muito sentido – como por exemplo exigir que o cliente esteja presente – mas no final fazem uma diferença enorme.

Outra polêmica muito grande é sobre a “popularização” do Scrum e seu mal uso. Como disse o Uncle Bob em um excelente post, usar uma metodologia ágil pura e simplesmente não faz com que você faça algo bom automaticamente. É perfeitamente possível fazer desgraças de design usando XP e com toneladas de código gerado com TDD, por exemplo. Será que ainda não deu para perceber que o caminho não é se apegar a metodologias e nomes? Elas são simplesmente uma porta de entrada!

Acho que isso tudo aconteceu porque com o “surto” de adoção e procura das metodologias ágeis, do dia para a noite surgiram milhares de especialistas ágeis. Esses agilistas espertalhões surgiram com dezenas de teorias malucas, princípios absurdos e uma quantidade incontável de barbaridades. O mais triste é ver que essas barbaridades são tantas que podem ser encontradas facilmente em listas de discussões, cursos, revistas, blogs e por todos os lados!

Estão pipocando comentários indignados (e com razão) sobre a deturpação de Agile, como o Christiano Milfont que comentou sobre a combinação estranha de Agile e CMMI, do Fernando Meyer sobre as pessoas não terem o pé no chão em relação ao Scrum, do Rafael Mueller, Phillip Calçado, Ivan Sanchez, José Papo e muitos outros comentando sobre o post do James Shore… Parece que muitas pessoas na comunidade – asssim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento.

É realmente triste ver as metodologias ágeis sendo estupradas, é vergonhoso ver pessoas falando abobrinhas gigantescas sobre Scrum sem terem a menor idéia de como funciona e é enojante ver mensagens nas listas de discussões de pessoas que conseguem quebrar todos os valores do manifesto ágil em menos de um parágrafo. O triste resultado disso é que já dá para perceber em algumas pessoas o início de uma rejeição à metodologias ágeis…

Seja XP, Scrum, Lean ou qualquer outra, as metodologias ágeis serão tão boas e darão resultados tão bons quanto as pessoas que as usam.

Cuidado com os falsos agilistas, eles estão por todos os lados!

Com mais de 400 apresentações em 5 dias, o calendário da conferência, divulgado no início do mês passado está ótimo! Teremos a presença de vários nomes conhecidos do mundo ágil como Jeff Sutherland, Mary Poppendieck, Robert Martin (o Uncle Bob), Mike Cohn, Henrik Kniberg, Dan North, Mishkin Berteig, Scott Ambler, Linda Rising, Jim Highsmith, Neal Ford, James Shore… Vai ter tanta coisa legal que está até difícil escolher quais apresentações vou assistir! E isso tudo sem falar do amigo brasileiro e ThoughtWorker Danilo Sato, que apresentará o case do Coding Dojo de São Paulo.

Quem lê meu blog já deve ter percebido que desenvolvimento ágil é um dos meus assuntos favoritos, por isso podem esperar que provavelmente vou blogar mais do que o normal na semana que vem!

Nossa história no início foi bem parecida com as histórias tradicionais. Sabe aquelas empresas que gastam uma semi-fortuna com uma consultoria para desenhar um processo de desenvolvimento de software? Assim estávamos nós no início de 2007. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido á risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

Resumindo a história, isso não funcionou na Globo.com e acho que existem poucas chances de algo tão complexo assim funcionar em algum lugar. E por incrível que pareça, no fim das contas ninguém havia pensado em nada para resolver o problema principal: como entregar o software que nossos clientes querem no menor tempo e com a maior qualidade possível?

Um pouco de história

Ao contrário do que acontece em muitas empresas, as metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (Extreme Programming) nos projetos. A porta de entrada foi a oportunidade de melhorar a qualidade dos nossos sistemas, pois tinhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Alguns desenvolvedores mais experientes começaram a desenvolver usando desenvolvimento guiado por testes (TDD), e com isso houve uma melhora nítida na qualidade do que era entregue. Aos poucos, enquanto isso acontecia, algumas seções de programação em par aconteciam de vez em quando para difundir o conhecimento e ensinar a técnica a outros programadores, mas ainda de forma muito tímida e sutil (afinal às vezes é difícil convencer que dois programadores fazendo apenas um código é uma coisa boa).

Em seguida foi a vez de organizar as demandas de clientes e os ciclos de desenvolvimento. Lembro-me de ter colocado nessa época o mesmo software em produção quatro vezes em duas semanas, e depois disso o mesmo software foi trabalhado durante dois meses para só depois poder ir novamente para produção. Para piorar, nossos clientes nos traziam todo tipo de demanda que se pode imaginar, sempre em lotes e com prioridade máxima. Por exemplo, acontecia frequentemente do mesmo cliente demandar cinco coisas e todas elas com máxima urgência. Resumindo, os ciclos de planejamento, desenvolvimento e entrega eram totalmente irregulares e afetavam o desempenho de toda a equipe. Explicando todas as dificuldades que tinhamos para nos organizar nesse caos, conseguimos acordar que fariamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teriamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de Scrum com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Me lembro de nessa época alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar Scrum no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabiamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do Scrum.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de Scrum, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões. O Phillip falou bastante sobre essa fase introdutória no seu blog no ano passado.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi colocada em produção em pouco mais de uma hora e na primeira semana nem ouviamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo que acontecia o Globo Vìdeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando Scrum, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos – mais uma prova viva de que o Scrum era uma possível resposta para os nossos problemas. O Danilo inclusive fez uma apresentação sobre esse projeto na semana passada num evento do C.E.S.A.R. em Recife.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de Scrum em massa na Globo.com.

Como estamos hoje

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando Scrum.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar Scrum da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderiamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vinhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo Scrum, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily Scrum, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estouravamos o tempo da reunião discutindo um monte de coisas que não eram necessárias mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com planning poker também evoluiram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de Scrum Of Scrums, onde todos os Scrum Masters se reunem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem.

Definimos o nosso conceito de “done” (finalizado), que é a parte mais divergente entre as equipes. Na equipe de desenvolvimento de vídeos (minha equipe), uma história ou funcionalidade está pronta quando foi desenvolvida (incluindo testes unitários), integrada à base de código, testada novamente (fazemos testes de aceitação com critérios definidos no Sprint Planning ao criar as histórias) e homologada. Como nosso time tem uma pessoa da área de QA, podemos incluir a homologação da aplicação dentro do Sprint (nem todos os times fazem dessa forma).

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time – ele deu excelentes toques importantissimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

Concluindo…

Não só o Scrum como todos as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais. Por conta disso nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou Scrum Masters no caso do Scrum) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

Em primeiro, Roman Pichler escreveu um excelente artigo no InfoQ entitulado “Creating Product Owner Success” com vários insights sobre como ser um Product Owner de sucesso. Além disso ele também fala de alguns erros comuns cometidos nesse papel. Há uma lista de outros artigos sobre Scrum e P.O.s no site do Roman, vale a pena dar uma vasculhada.

O segundo artigo é do Rodrigo Yoshima entitulado “Product Owner: Um de$graçado ganancio$o”. O Rodrigo colocou um ponto interessante que eu também vejo acontecendo em alguns projetos: a falta de compromisso com o ROI. O Scrum é totalmente “ROI-oriented” e é absolutamente essencial que o P.O. entenda isso plenamente para o sucesso dos projetos.

E por último, o Danilo Bardusco escreveu sobre “Product Owner Técnicos”, argumentando porque o P.O. também deve ter bons conhecimentos técnicos e como isso é benéfico para que ele possa guiar bem o time e expressar melhor suas idéias.

Além disso, há uns meses escreví sobre esse mesmo assunto referenciando um artigo do Antonio Carlos Silveira sobre “O papel do Product Owner e priorização do Product Backlog”, que também vale a pena ler.