XP: Você é um coach?

Todos que me conhecem bem sabe que sou fanático por métodos ágeis, especialmente por Extreme Programming. Evangelizo o XP, dou palestras sobre esse assunto e , principalmente, procuro aplicar da melhor maneira possível essas práticas durante meu dia-dia. O livro que sempre recomendo é o Extreme Programming do Vinícius Teles e, obviamente, a bibliografia do Kent Beck sobre esse assunto.

A teoria, após a leitura desse livro a uns anos atrás, de imediato me ajudou na questão profissional, principalmente nas tomadas de decisões e como montar um esquema de trabalho que funciona para desenvolvimento de software. Porém, só a teoria não é o suficiente para dizer-se conhecedor do assunto. No dia-dia aparecem várias situações adversas e depende da capacidade do time conseguir aplicar esse conhecimento de boas práticas. A leitura de uma bibliografia nos dá informação , mas de nada adianta se ignorado na prática. A informação só se torna conhecimento quando aplicado naturalmente.

Definição de coach retirada do livro Extreme Programming (Vinícius Teles), pag 29:

O coach é o responsável técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.

Em métodos ágeis o time precisa ser auto-gerenciável e todos precisam estar preocupados com a qualidade do projeto, boas práticas, métricas e cobertura de testes. Todos precisam buscar melhorar o processo de desenvolvimento, pesquisar sobre novas ferramentas de testes, automatizar tarefas, acompanhar e manter a integração contínua do projeto. O coach precisa ter um bom conhecimento técnico para ajudar o time no desenvolvimento e, principalmente direcionar a equipe a cumprir essas práticas importantes. Ele ajuda a manter o foco na qualidade e no processo de desenvolvimento. Busca motivar as pessoas para desempenharem a cada dia o melhor de si.

Quando a interação, ou se preferir sprint, não está caminhando bem, o coach precisa auxiliar o time a identificar o que pode ser melhorado. É preciso identificar esses pontos e definir um plano de ação e indicar responsáveis por melhorar o processo. O time não pode encarar essa divisão de responsabilidade como uma cobrança top-down. O objetivo do coach não é cobrar pois assim o time deixa de ser auto-gerenciável.

Vejo que práticas do XP já são muito bem conhecidas mas as vezes não tão bem compreendidas. Algo que sempre recomendo em toda equipe que trabalho é a programação em par. Já escutei de tudo sobre essa prática e dificilmente vejo que as pessoas entenderam o real benefício disso. Definição do livro:

No XP, os desenvolvedores implementam as funcionalidades em pares, ou seja, diante de cada computador, existem sempre dois desenvolvedores que trabalham junto para produzir o mesmo código. Essa prática, que recebe o nome de programação em par permite que o código seja revisado permanentemente, enquanto é construído. Também contribui para que a implementação seja mais simples e eficaz, já que os desenvolvedores se complementam e tem mais oportunidade de gerar soluções inovadoras.

Tanto para tarefas simples como para mais complexas, se exige desenvolvimento, o trabalho sai melhor se feito por duas pessoas. Problemas de design são melhor identificados se o desenvolvimento é em par. A revisão de código é feita no ato evitando bugs mais obscuros. O foco na tarefa é maior tendo em vista que a “internet” pode desviar a atenção. Conhecimentos técnicos e de negócio são compartilhados entre a dupla a todo momento.

Eu particularmente gosto muito de parear, pois sempre aprendo coisas novas com outra pessoa. Nessa prática procuro sempre passar todo meu conhecimento para quem parea comigo. Gosto sempre de trocar duplas justamente para que a equipe evolua integralmente. Parear com devs de backend, interface, testadores, independente da especialidade.

Considerando a importância de parear, mesmo  dentro de uma equipe entrosada e experiente, vejo ser imprescindível parear com pessoas novas na equipe mesmo já tendo um bom conhecimento técnico. Conhecimentos de negócio vem com o andamento do projeto e a aceleração de aprendizagem é muito maior quando realizado o pair. Se por algum motivo o código não foi desenvolvido em pair, é necessário que haja a revisão do código entregue, preferencialmente por outra pessoa que não o autor.

O XP procura transmitir idéias através de metáforas. “Se você está mudando de casa, prefere carregar o sofá sozinho ou carrega em dois?” Apenas para concluir essa questão, pair programming não é só quando um desenvolvedor precisa de ajuda, é para realizar o trabalho mais bem feito. 🙂

Outra questão bastante polêmica é a integração contínua. Regra básica: Nunca PUSH sem BUILD. Ou seja, não integre seu código se for quebrar o build. E se quebrar, o foco é totalmente em arrumar o build e não continuar comitando ou fazendo novas features. Quando o build está quebrado os outros desenvolvedores perdem toda a confiança em fazer alterações no código. Outros vão querer descobrir porque quebrou o build e todo o time é prejudicado com isso. Em algumas equipes na Gonow, se um código quebra o build ou não tem cobertura de testes, o commit é desfeito até que haja cobertura ou que o build seja arrumado. Eu sou totalmente a favor dessa prática pois obriga que o time tenha a cultura de não descuidar da qualidade do projeto.

É normal em um time ocorrer argumentações sobre design como nomes de attributos, métodos, responsabilidades de modelos. Discussões sobre o design são sempre sadias pois visam melhorar a qualidade final. O XP fala de simplicidade e coragem. Simplicidade para fazer apenas o necessário para satisfazer o que vai trazer Valor para o cliente. Coragem entre outros para fazer refatorações sem medo de quebrar regras importantes no sistema. Recomendo fortemente a leitura dos livros Refactoring do Martin Fowler e o Código Limpo de Bob Martin.

O importante em equipes é que aconteça a inspeção e adaptação no processo em busca da melhoria contínua. Todas essas práticas do XP tem o objetivo de atingir os seguintes Valores:

Feedback, Comunicação, Coragem, Simplicidade e Respeito

A reflexão que quero deixar sobre o tema desse post é: O que um lider técnico precisa para se tornar um coach? O que você faz no dia-dia para conseguir direcionar sua equipe a obter o sucesso?

Retrospectiva

A Retrospectiva é muito importante em equipes ágeis porque proporciona uma reflexão sobre o sprint, com o intuito de inspecionar e adaptar em futuras iterações. É um momento de aprendizado pois são expostas as coisas boas e o que pode ser melhorado num futuro próximo.

Parece ser fácil fazer uma retrospectiva, mas para que ela seja objetiva é necessário que o dia-dia seja muito envolvido nesse processo. Na retrospectiva normalmente nos lembramos apenas do que foi bastante ruim e esquecemos de falar de coisas boas, que quando ditas podem ser um forte ponto motivacional para o time. A mente humana é muito seletiva e esquecemos facilmente o que aconteceu durante a semana, a não ser o que foi realmente marcante. Por isso existe uma técnica que ajuda na retrospectiva que é usar post-its coloridos em cada acontecimento diário. O fato de usar post-its vermelhos quando acontece algo ruim do sprint, amarelos quanto surgem idéias e verde quando acontece algo bom, causa um efeito visual em nossa mente e a equipe trabalha mais proativamente. Esses post-its diários ajudam bastante pois são discutidos na retrospectiva e não perdemos tempo tentando lembrar o que aconteceu na semana.

Importante! A retrospectiva não é o momento de se achar os culpados, e sim uma solução para o que pode ser melhorado. Portanto não se deve falar nomes nessa reunião, porém um elogio é sempre bem vindo!

De nada adianta a retrospectiva se não for documentada e não houver um plano de ação após essa reunião. Após a retrospectiva, são definidos os responsáveis pelos itens que precisam ser melhorados e como será o plano de ação. A documentação pode ser uma simples foto do quadro de discussão e que fique de fácil acesso a todo o time. Isso é importante para que se tenha uma Linha do Tempo de todas retrospectivas do time para acompanhamento do progresso.

Escrevi outro artigo sobre isso no link:

https://manifestonaweb.wordpress.com/2009/03/20/qcon-london-2009-retrospectivas/

TDD é realmente necessário?

Antes de mais nada assistam esse video muito engraçado, que diz Test All the F***in Time! 

 

O TDD é fundamental para um time ágil por alguns motivos que vou citar agora. 

• O desenvolvimento guiado a testes influencia o time a fazer design simples para desenvolver somente o que é realmente necessário para passar no teste.
• Influencia o time a ter uma boa cobertura de testes, o que possibilita mudanças no código mais facilmente.
• A equipe tem mais confiança para fazer refatorações, deixando o código mais simples e limpo.

As ferramentas que temos hoje facilita muito esse tabalho, como por exemplo a família xUnit, Selenium, Mocks, cobertura de testes etc. Porém as ferramentas são para auxiliar e não devem ser impedimento para fazer TDD. Por exemplo, mesmo que alguma linguagem ainda não tenha um suporte tão bom para testes, nada impede que a gente crie nossas próprias assertions. 

Na estimativa tem que ser considerado os testes, para a própria segurança do time. Porém acontece o caso que o cliente pede para deixar os testes para depois. Nesse caso podemos dizer ao cliente que estamos estimando a construção do comportamento do software. Reparem que os testes são parte do comportamento do software!

BDD = TDD + DDD. Behaviour-Driven Development (BDD) é o desenvolvimento de software dirigido ao seu comportamento. É a união de desenvolvimento guiado por testes(TDD) e Design dirigido ao domínio da aplicação (DDD). 

Testar é investir! Ou seja, se as pessoas não conhecem a sintaxe de xUnit, nunca usaram Selenium ou se deparam com a necessidade de criar mocks para eliminar a dependência de outras classes que não são interessantes para o teste de unidade, eles terão que considerar esse tempo de aprendizagem dentro do sprint. Porém depois de familiarizado com a ferramenta/framework, os testes podem ser executados sem mesmo precisar subir um servidor de aplicação, aumentando assim a produtividade da equipe. 

No livro do Vinícius Teles tem uma metáfora muito interessante com a saúde das pessoas. O que é melhor: prevenir ou remediar?

É interessante lembrar que os Testes estão muito ligados a outra prática ágil como a Integração Contínua.

Sei que todos concordam que os testes são imprescindíveis. Portanto o cerne da discussão desse tópico é fazer os testes antes ou não. Porém acredito que fazer teste antes traga mais valor ao cliente.

Conclusão, só não testa quem realmente não quer. 😉

Eu escrevi alguns posts sobre esse assunto, quem quiser pode dar uma lida e fiquem a vontade em comentar aqui e aqui

Criar um novo Barco

Gosto muito de barcos e desde pequeno eu tenho fascinação por mar. Já que nossa área ganha bem e só perde para o salário dos políticos, eu decidi comprar um barco todo personalizado. Então fiz uma pesquisa de mercado para saber quem poderia me fornecer o barco a um custo razoável e a um prazo aceitável. Não foi muito difícil para aparecer duas pessoas interessadas no meu negócio. Um chamado Dunga e outro chamado Phelps.

O Dunga me falou que trabalha com os melhores barcos de mercado e todos tem ótima qualidade. Ele disse também que trabalha com uma fábrica de talentos na construção de barcos. Então ele me propôs as seguintes fases para a construção do barco:

1- Fazer a concepção detalhada de tudo que eu quero no meu barco. Analisar e documentar tudo que o barco precisa ter e fazer. Quantos cômodos vai ter meu barco, quantas portas e janelas. Se os bancos serão de couro, se as paredes terão detalhes com gessos. Qual altura vai ter os mastros. Qual vai ser a velocidade desejada para meu barco etc. Após essa fase de análise, iniciar a construção do barco. Em seguida testar se o barco tem estabilidade desejada em mar aberto ou se está pendendo muito. E finalmente entregar o barco para ter o meu feedback. O Dunga disse que precisaria de 11 pessoas para a construção, sendo que um ficaria responsável pela retaguarda do barco ( motor e âncora ),  quatro fariam a parte traseira, outros quatro fariam o interior do barco e dois últimos ficariam responsáveis pelo bico do Titanic. O tempo de entrega seria 2 anos de concepção, análise e documentação, mais 2 anos de construção, testes e implantação. Sem contar as manutenções necessárias depois da entrega. Total de 4 anos. O custo seria equivalente ao passe do Riquelme e Messi juntos!

O Phelps me fez a seguinte proposta:

2- Fazer todas as fases da proposta 1 muito mais vezes! O prazo seria estipulado em entregar partes do barco mensalmente e o custo seria apenas as horas que ele e outro profissional, chamado César Cielo, estiverem fazendo o barco. 

Mas como isso ser possível? Minha primeira impressão foi que o Phelps bateu a cabeça no barco e ficou louco! Com a testa inchada agora ele acha que pode fazer todas as fases da proposta 1 diversas vezes, entregar essas fazes a cada mês e ainda fala que vai sair muito mais barato?

Apesar do susto, eu tive uma leve impressão que o Phelps me entregaria o barco pronto com mais agilidade, então decidi arriscar pela proposta 2.

Na verdade, após o andamento do projeto, eu percebi que de louco o Phelps não tem nada. Ele pediu para que eu sempre estivesse presente na construção do barco. Tínhamos uma comunicação face-a-face sobre como deveria ser o resultado. Eu percebi que o dia que o Phelps não trabalhava a produtividade continuava quase a mesma, pois o Cielo sabia fazer tudo que o Phelps estava fazendo. Depois de três meses, consequentemente três entregas, toda a estrutura da base do meu barco estava montada, o que já me permitia atravessar parte do mar até uma ilhazinha paradizíaca. Lembro-me a vez que eles me entregaram todas as 50 janelas do barco. Primeiramente me mostraram apenas 10 moldes nas paredes, sem janela nem acabamentos. Esses moldes seriam onde as janelas se encaixariam. De imediato eu bati o olho e vi o formato das janelas sendo todas quadradas. Então conversamos e o meu feedback foi de mudar as janelas para que todas fossem redondas, e para não ter tanta claridade interna, seriam necessárias apenas 30 janelas e não 50. Minha surpresa foi que na entrega posterior todas as janelas estavam prontas, mesmo aqueles moldes que estavam quadrados. Eu fiquei imaginando quanto retrabalho eles teriam se tivesses feito todas as 50 janelas com formatos quadrados.

Reparei que eles nunca fazias horas extras de trabalho, eles mantinham um ritmo sustentável de trabalho e mesmo assim faziam as entregas no prazo. O que primeiramente parecia um projeto de longas datas, até anos, em apenas 9 meses eu já tinha o simples, mas que era tudo o que eu realmente necessitava.

Fiquei bastante surpreso com a agilidade do Phielps, como se ele já tivesse nascido para construir o meu barco.

 

Mas se eu não me contentasse com um barco e quisesse um navio? Será que esse método de trabalho funcionaria para mim? Hoje sei que se fosse um navio, ainda mais um navio, eu não seria louco de fechar um contrato com o Dunga.

Return Of Investment

“Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.” Guilherme Chapiewski

Recomendo muito a leitura dos posts:

• Times Scrum trabalhando em vários projetos ao mesmo tempo? (Scrum na Globo.com)
• Atendendo de forma ágil às janelas de mercado

Comportamento de Software

 Behaviour-Driven Development (BDD) é o desenvolvimento de software dirigido ao seu comportamento. É a união de desenvolvimento guiado por testes (TDD) e Design dirigido ao domínio da aplicação (DDD).

Para entender direito o que é BDD é necessário comentar sobre TDD e DDD. Nesse post quero focar no TDD. Um assunto tão importante como esse merece muita atenção!

Quando acontece um bug num software é bastante comum os desenvolvedores gastarem mais tempo tentando achar o erro do que consertar o erro em si, principalmente se o sistema não tiver testes automatizados.

O TDD é uma prática usada por times que seguem Extreme Programming. Desenvolvedores que não usam essa prática se encaixam em um dos itens abaixo:

• Tem preguiça de fazer testes
• Faz os testes no final
• Não conhecem os benefícios de o TDD trás.

Existem desenvolvedores que confiam tanto no seu trabalho que deixam para outros testarem o que desenvolveu. Porém um bug pode não ser pego no teste de outros e ocorrer quando estiver em produção.

Os que deixam os testes para o final podem não lembrar de testar todos os cenários. E se ocorrer atrasos no projeto o primeiro que vai ser cortado são os testes.

Para quem não conhece os benefícios do TDD fale a pena comentar um pouco do assunto.

Iniciar essa prática pode parecer um pouco difícil e chato, mas para a equipe de XP isso se torna muito natural. Todo código implementado deve coexistir com um teste automatizado, para garantir o funcionamento do software com a entrada de novas funcionalidades. Esses testes automatizados garantem a qualidade do software pois, se uma nova codificação afetar alguma regra de negócio, o teste deve instantaneamente apontar o problema antes que o release seja entregue. Quando essa automatização existe, os desenvolvedores ficam com mais coragem de alterar uma parte do código que ele não desenvolveu e eles tem mais confiança de fazer refatorações necessárias para melhorar o código. A Refatoração é muito importante seja para facilitar a manutenção do sistema ou para melhorar a performance do código, mas que seja feira sem alterar a funcionalidade do software. Geralmente a gente refatora quanto encontramos códigos duplicados, pouco legíveis, mal codificados, sem padronizações, lentos etc.

Primeiro implemente o que (comportamento) você quer testar, e execute testes de sucesso que garantam falhas do sistema e testes de sucesso que garantam o bom funcionamento. Depois disso você implementa a funcionalidade em questão.

Uma boa prática de trabalhar com TDD é fazer o que o pessoal de XP chama de seguir “passos de bebê”. O benefício disso é que quando você faz um teste para um software que tem poucas linhas é bem mais difícil de você ter inserido um bug. E a medida que a funcionalidade vai crescendo os testes automatizados tem que continuar executando, tanto os de falha quanto os de sucesso.

Fazer TDD não é apenas testar a aplicação e sim fazer um design simples. Muitos problemas de acoplamento das suas classes serão percebidos quando escrever um teste. TDD é muito relacionado com refactoring, tornando o código fácil de ler. O fato das pessoas não saberem o que testar e como testar torna uma barreira para fazer os testes, mas depois de se conhecer os benefícios e começar a praticar, o desenvolvimento guiado por testes tente a ser uma maneira natural de pensamento. 

“Nos dias de hoje, é irresponsabilidade um desenvolvedor entregar qualquer linha de código sem que exista um teste unitário para comprovar o seu funcionamento” frase de Bob Martin

Existem basicamente dois tipos de testes, os testes de unidade e os testes de aceitação (integração). Os testes de unidade seriam para testar os métodos de uma classe. Já os de integração tem como objetivo validar a integração das classes que implementam uma funcionalidade, atendendo as necessidades de maneira correta. Os testes de integração, na maioria dos casos, são descritos pelos clientes, mas quem implementa são os desenvolvedores.

Para fazer testes automatizados temos muitas ferramentas disponíveis, basta usá-las.

Testes unitários, em Java, temos JUnit, UnitNG, JMock. Para testes de integração temos o Selenium, Fit, Fitnesse. Ferramentas de BDD JBehave, JDave, beanSpec, Instinct.

Em Ruby on Rails temos autotest para automatização dos testes. Para BDD tem ótimas ferramentas como RSpec , Shoulda.

Em Javascript, para o JQuery, temos o JQunit. Para BDD tem o JSSpec.

Para Integração Contínua tem o CruiseControl.

Para verificar a cobertura de testes temos o Emma, Clover, JCover.

Precisei fazer uma refatoração num sistema que não tinha testes unitários e as classes eram bastante acopladas. Mas isso não foi problema para eu criar os testes. Usei o JMock e criei objetos de mentira para simular outras classes que não era minha intenção testar. O JMock pode ser usado para simular uma classe que faz acesso a banco, HTTPRequest ou qualquer outra classe do seu sistema. Um exemplo de uso nesse post.

Um excelente exemplo de TDD pode ser lido nesse post da Improve It.

Uma das ferramentas que mais gostei foi o Selenium. O Selenium-IDE funciona como um robozinho que grava as ações em uma tela. Por exemplo o click em um botão deve trazer uma lista de resultados. Se ao disparar o teste do botão a listagem não aparecer, o Selenium-IDE avisa que tem erro no sistema. A ferramenta pode disparar o mesmo teste em vários browsers diferentes.

Quando pensamos em qualidade no software devemos lembrar das ferramentas ideais para nos auxiliar em nosso ambiente. Pensar nos testes como sendo automatizados, pois são mais eficientes que qualquer teste de usuário, o qual também é importante.

Resistência à Mudanças

As metodologias ágeis enfrentam muitas resistências no mercado. Muitas vezes a resistência está em nós mesmos! 

Esse post causou uma boa polêmica e levantou vários pontos que o mercado utiliza para não adotar agilidade (Vejam os comentários aqui). Conheço o Fábio, e ele é um arquiteto de muitíssima competência com várias certificações e demonstra bem o que muitas empresas pensam a esse respeito. Porém uma opinião tem que ser formada quando se conhece bem os opostos. Muitas perguntas passam por nossa cabeça quando a gente depara com um novo paradigma, é normal!

Como estimar prazos em uma metodologia ágil? Como fica o contrato? Como garantir implementar funcionalidades dentro do escopo?

Um dos grandes ganhos da metodologia ágil com certeza é estimativa de prazos. O Scrum tem várias técnicas para estimar um prazo conciso. Mas como estimar? O Scrum tem o Planning Poker.

 

E se a estimativa falhar? É mais difícil isso acontecer pois os sprints (iterações) devem ser curtos, mas se acontecer o Scrum tem o Sprint Retrospective, Sprint Review. 

Como aprender com os erros? Sprint Backlog atualizado. Como manter o time auto-motivado? Daily Scrum. Como fazer códigos melhores? Pair Programming.

O assunto é muito rico. Tem muitos cursos bons no mercado. Para quem gosta de auto-estudo eu recomendo os livros:

• Agile Software Development with SCRUM 
• Agile Software Development, Principles, Patterns, and Practices
• Extreme Programming Explained: Embrace Change (2nd Edition) 
• Extreme Programming (Em Português!)

 

Alguém já pensou nos problemas que a gente enfrenta. Sempre ouvimos a frase “Não reinventar a roda”.

Apenas mais um ditado que gosto muito:

“Um tolo erra e insiste no erro

Um inteligente aprende com os próprios erros

Um gênio aprende com os erros dos outros”

Divisão de Responsabilidades

Quando eu falei sobre divisão de responsabilidades no post anterior eu não quis dizer uma pessoa fazer o trabalho de todos, muito pelo contrário! E para uma equipe maior que umas 9 pessoas pode ser impraticável algumas técnicas do Scrum, por exemplo o Daily Scrum que tem o objetivo de ser rápido. Mas quando ocorre um time tão grande assim? Não é impossível ter muitas pessoas num projeto. Eu particularmente já participei de um time de 11 desenvolvedores. Nesse caso talvez algumas técnicas do Scrum me ajudasse, mas não todas! Porém a maioria das vezes a equipe não é tão grande, então quanto mais técnicas usar, melhor!

Mas vamos pensar um pouco. Um problema que acontece muito nos projetos atuais é o software final não sair da maneira que o cliente esperava, e aí ocorrem os retrabalhos. Por que isso acontece tanto? Não quero generalizar, só vou dar um exemplo. Ocorre porque no levantamento do projeto os analistas de negócio fazem toda a documentação e passam para uma fábrica de software implementar. Os desenvolvedores são cobrados por prazos e muitas vezes não lêem todas as 50 páginas do documento e fazem da forma que entenderam podem interpretar de maneira erronea, a não ser que exista um documento de Visão que não permita esse mal entendimento. Eles não participaram das reuniões com o cliente não sabem o escopo do projeto o que facilitaria o entendimento e possibilitaria ter uma visão macro do projeto. Mesmo se o conhecimento for passado do analista de requisitos para o desenvolvedor por meio de uma conversa, não será tão bom como o próprio cliente passar o conhecimento, pois esse último é o que realmente entende do negócio. As vezes um intermediário pode causar o problema de telefone sem fio. Daí quando o projeto está quase acabando já é tarde demais. Comentei sobre isso nesse post.

Uma metodologia ágil deve dizer que o cliente tem que estar sempre próximo do time, e quanto mais desenvolvedores participarem das reuniões, sobre os requisitos por exemplo, é melhor. No scrum existe os papéis de Product Owner (pode pensar no cliente do exemplo citado), o Time, e o Scrum Master. Isso muitas vezes é o suficiente.

Devemos ter testers? Sim, mas se o time trabalhar com TDD do Extreme Programming pode ser que não precise.

Podemos ter analistas de negócios? Sim, desde que não seja um intermediário.

IBM adotando Metodologia Ágil?

Estive dia 18/06 no evento IBM Development Conference 2008 e quero comentar sobre a estratégia que a IBM vem tendo com metodologias ágeis e processos. Espero lembrar de bastante coisa para poder compartilhar as idéias.

O evento começou com um filme de computação gráfica com a intenção de mostrar os problemas reais de desenvolvimento de software. O filme foi apresentado em vários capítulos divididos entre as palestras. Os heróis, ainda sem seus poderes, eram o desenvolvedor, a tester, o gerente de projeto, o arquiteto etc. Eles começaram a ter os problemas que a gente não conhece no dia-dia dos projetos por exemplo apagar incêndios! E começaram a ser ameaçados por inimigos, outros personagens gráficos, que representam os problemas reais que aparecem nos projetos. E ameaçaram dizendo aos heróis: Salvem o seu dia de trabalho se puderem, se é que conseguirão salvar seus trabalhos. Daí apareceu um cara com uma testa enorme, um tipo de oráculo. Esse cara surgiu para acordar os heróis pra vida e ajudá-los a salvar o dia de trabalho e depois….

Não peguei o final da estória! Se alguém souber pode comentar o post. Apesar que está um pouco óbvio quais são as ferramentas que eles vão usar no final do filme. Agora vamos ao que interessa.

A maior aposta da IBM está sendo na plataforma Jazz, uma integração em tempo real de pessoas, processos e ferramentas. O nome é uma metáfora a um conjunto musical mesmo. Essa é uma iniciativa de trabalho em conjunto para entregar mais VALOR e melhor performance para um investimento de software. O Jazz não é nada novo, já faz uns dois anos de vida, mas está na versão beta e eles pedem para a comunidade contribuir e cadastrar idéias de melhorias, que vai ter um desenvolvedor lá para implementar.

A um tempo atrás eu falei sobre a importância de uma Metodologia Ágil, e a IBM não quer ficar para trás. Eles estão adotando internamente uma Engenharia de Software Ágil chamada IRUP, uma abreviação de IBM Rational Unified Process.

Eles se mostraram muito preocupados em unir desenvolvimento ágil com a governança, como um “Investimento disciplinado”.

“Tailoring governance is a progress.”

Com uma Governança adequada eles citaram:

• É mais fácil ficar aderente aos padrões
• Detecção de resolução de defeitos antecipadamente
• Melhor previsibilidade dos projetos.

Uma frase interessante foi:

“Muitos clientes só sabem o que querem quando eles vêem o que não querem.”

Porque a IBM está falando em agilidade? A própria IBM concorda que RUP + CMM trouxe muita coisa que não era realmente necessário para o desenvolvimento de software. Eles falaram:

“Os clientes que usam RUP e CMM estão na verdade fazendo mais processo do que eles realmente precisam.”

“Deve-se fazer menos reuniões e relatórios”

“Ter um maior aproveitamento dos especialistas e do conhecimento.”

Eles falaram também que:

“Software funcionando é mais importante que o processo!”

 

Uma coisa dita em uma das palestras sobre agilidade foi focar em ferrementas, e não regras. Será que isso tem o mesmo significado do que fala o Manifesto Ágil em que pessoas e interações são mais importantes que processos e ferramentas?  

Para trabalhar com agilidade basta post-its! Apesar que gostei da experiência de usar o Mingle com template para Scrum. Só que a IBM se mostrou preocupada com equipes distantes como, por exemplo, desenvolvedores no Brasil, testers na Índia e gerentes de projeto na Europa. E para isso propôs uma ferramenta para gestão de processos ágeis: O Rational Team Concert. Tráta-se uma ferramenta de gerência de metodologia ágil e é também uma gerência de build. Ela foi a primeira ferramenta construída totalmente na plataforma Jazz. Segundo eles é uma ferrameta muito fácil de instalar, roda no tomcat e pode ser customizado com a metodologia ágil de preferência (IRUP, Scrum, Open Up…)

Os times ágeis, para a IBM, devem trabalhar com desenvolvimento de software dirigido a mudanças e haver uma integração contínua. A produtividade deve aparecer no primeiro dia, pois o início do projeto deve começar em dias e não em semanas. Deve haver uma redução do tempo até o primeiro Demo. Um exemplo foi:

“Microsoft gera um build cada 3 anos.

O Flickr faz deploy todos os dias.”

Alguns dados que eles passaram:

• 37% dos usuários estão satisfeitos com a velocidade do desenvolvimento dos projetos.
• 50% dos projetos terceirizados performam abaixo do esperado.
• 42% dos usuários acham a qualidade satisfatória.

Teve uma palestra sobre Testes de Software e Gerenciamento de Qualidade, o que a IBM ainda considera um débito em relação ao mercado. Por isso eles estão lançando o Rational Quality Manager. Essa e outras ferramentas é que compões o Jazz. Mas segundo eles será possível integrar com outras ferramentas de mercado, por exemplo o Bugzilla.

Nenhuma das palestras que participei falaram de XP ou Scrum. O que eu mais ouvi sobre métodos ágeis foi sobre desenvolvimento em iteração, o que já existia no RUP. Esse IRUP me pareceu um RUP um pouco melhorado, com menos documentações e muita ferramenta. 

Agora tenho a seguinte dúvida: Será que a metodologia ágil da IBM trará os benefícios que Scrum + XP trás para nós? Os heróis do filme da animação gráfica eram em 6, ainda não é muita divisão de responsabilidades para um time ágil?

Metodologia Ágil

Estava conversando sobre metodologias com um amigo, gerente de projeto da empresa o qual trabalho, e quando falei de Scrum ele se mostrou muito interessado no assunto. Porém fui surpreendido quando ele falou que conhecia outra metodologia, o famoso XP, e disse que se o Scrum for como o XP seria uma carta fora do baralho. Curioso em saber o porquê ele me disse que trabalhar em par é coisa de criança, e não tinha mais argumentos para falar sobre o XP. Então eu expliquei que tem o outro lado da moeda. Trabalhar em par possibilita a troca de conhecimentos da equipe e a codificação é revisada a todo momento. E para fazer críticas a uma metodologia temos que pelo menos entendê-la como um todo, e não por causa de uma ou duas regras dessa.

Muita gente ainda tem preconceito de metodologias ágeis pois acha que isso não vai pegar, mas por puro desconhecimento nem imagina que isso já pegou! No Brasil ainda não está muito difundido, mas acretido que o mercado está mudando. Grandes empresas já adotam essa metodologia, como por exemplo a Globo.com com alguns cases de sucesso. Mas por que estão adotando agilidade? Vejamos:

Os projetos atuais e tradicionais não estão tendo sucesso! Gantt Chart não funciona! Processos waterfall não funcionam! As fábricas de software não estão conseguindo cumprir os prazos porque esse modelo tem muitos problemas!

Esse gráfico é antigo, mas acredito que hoje ainda não esteja muito diferente. Ele mostra que apenas 16% tem sucesso e são entregues no prazo.

Muitos comparam a engenharia de informática com engenharia mecânica mas são engenharias completamente diferentes. Na informática a formula ( Progresso = Número de Pessoas / Número de Tarefas) não é verdade.

Um modelo em cascata, também conhecido como waterfall, tem o seguinte aspecto:

Já num modelo incremental essas fases devem ocorrer a todo tempo. Em curtos intervalos de tempo todas essas fases devem ser executadas e revisadas.

Muita gente diz que aplica RUP mas na verdade faz tudo waterfall. Passam meses fazendo páginas e mais páginas de documentação e entregam para desenvolvedores que precisam ler tudo, interpretar os textos e traduzir tudo em código. Sempre ocorre problemas de interpretação e geralmente nem tudo é lido antes de começar o desenvolvimento. Depois vem a frase conhecida do cliente “mas não era isso que eu queria”. Acontece que é difícil manter a documentação porque os requisitos mudam. As vezes o cliente descobre o que realmente queria depois que começa a usar o software, e o que mais vemos é trabalhos e re-trabalhos. Esses documentos, muitas vezes chamados de contrato, serão o alicerce de discussões entre clientes e prestadores. Vejam, eu não sou contra documentação e nenhuma das metodologias ágeis falam que não deve ter documentação! Documentação é importante, mas é mais importante o software funcionando do que o detalhamento de todos os escopos num documento. Melhor ainda se a documentação for executável para garantir que está refletida no código.

Por isso que surgiu as metodologias ágeis, por isso que surgiu o Scrum, por isso surgiu o Manifesto Ágil!

Comecei a utilizar técnicas do Scrum junto com técnicas de XP e obtive melhorias em meu trabalho rapidamente. Essas idéias ágeis formam um framework de processos que resolve a maioria dos problemas conhecidos, então por que não usar? Será que é muito difícil?

É claro que não é a certeza do sucesso, mas se a equipe for bem  qualificada e atenta, dificilmente ocorrerá desvios que possam prejudicar o andamento do projeto.