Posts Tagged ‘Agile Manifesto’

Alguns pensamentos sobre “documentação ágil”

Monday, September 20th, 2010

Existe um mito de que não se documenta em projetos que usam metodologias de desenvolvimento ágil. Não é bem assim, aliás, não chega nem perto de ser verdade.

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.

Agile indo para o buraco?

Saturday, November 22nd, 2008

Acabei de voltar de férias, já comecei a recuperar o atraso do meu Google Reader e não demorei muito para me deparar com a polêmica do momento…

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!

[FISL 9.0] Desenvolvimento Ágil com XP e Scrum

Sunday, April 20th, 2008

Scrum no FISLOntem, no último dia do Fórum Internacional de Softwre Livre, fiz minha apresentação sobre Desenvolvimento Ágil com XP e Scrum, um assunto muito interessante que está se tornando cada vez mais popular nos últimos meses. A sala estava lotada, muita gente nem conseguiu entrar (fotos no Flickr)!

Infelizmente os 40 minutos não foram suficientes para falar tudo que eu queria/deveria e a apresentação ficou meio corrida… Então, como prometí, estou disponibilizando os slides da apresentação sob a licensa Creative Commons 2.5 para quem quiser dar uma olhada com mais calma.

Desenvolvimento Ágil com XP e Scrum
View SlideShare presentation or Upload your own. (tags: xp scrum)

Além disso, seguem alguns ponteiros para quem quiser estudar mais sobre o assunto:

Livros recomendados

Blogs sobre “Agile”, Scrum e XP

Links

Scrum Master técnico?

Sunday, April 6th, 2008

Há algum tempo que tenho pensado muito sobre o que um Scrum Master pode/deve ou não fazer dentro de uma equipe Scrum.

Lendo vários livros e artigos sobre o assunto, percebi que todos eles enfatizam várias características do Scrum Master. Ele deve ser influente dentro da empresa, corajoso, comprometido com o projeto, deve ajudar o time a entender as práticas do Scrum e assegurar que elas não sejam violadas, dentre outras coisas.

O Scrum Master não precisa ser técnico. Todas as tarefas principais exigidas pela função podem perfeitamente ser realizadas por uma pessoa sem nenhum conhecimento técnico. Porém isso não significa que é ruim quando ele tem conhecimento técnico e usa-o em favor do time ou do projeto. Mais do que isso, acredito fortemente que os melhores Scrum Masters necessariamente devem ter conhecimento técnico e do negócio, pois isso os ajuda a entender melhor os problemas do projeto e ajudar melhor o time.

Essa não é uma opinião só minha. Mike Cohn, um dos grandes nomes do mundo ágil, escreveu no ano passado um artigo sobre o que ele considera que sejam as seis principais características dos melhores Scrum Masters. Uma dessas características é:

Knowledgeable

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.” Lockhart, K. 2006. Responsibility Junkie. Harvard Business Review (October): 30.

A princípio o Scrum Master não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Primeiro, porque impedirá que ele se concentre em resolver os impedimentos e problemas que estão no caminho do time, que no início da adoção são muitos e muito graves. Segundo, porque ele pode acabar tirando o compromisso do time. Ele pode acabar tomando decisões que nem todos concordam exatamente, mas farão porque alguém acima na hierarquia determinou e aí voltamos ao gerenciamento command-control onde as pessoas só fazem o que são mandadas. Para evitar esses problemas, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca e que se concentre em cuidar só disso.

Porém, vejo que depois de um certo tempo o time e o Scrum Master se adaptam tanto à empresa e a forma como ela trabalha (assim como a empresa se adapta às necessidades do time) que o time precisa cada vez menos do Scrum Master. Ele continuará sendo necessário na hora em que aparecerem problemas fora do alcance do time, mas penso que isso aconteça na menor parte do tempo e cada vez menos. O time e a empresa amadurecem sua relação e evoluem tanto que o time entra num ritmo de alta produtividade e sofre cada vez menos interferências.

E quando isso acontecer o Scrum Master deverá ficar sentado esperando o próximo problema/impedimento a ser resolvido? Certamente isso não seria bom para a empresa.

Todos os Scrum Masters ou líderes de projeto que conheço são pessoas excelentes tecnicamente. Muito modestamente e humildemente falando, eu me incluo neste grupo. Eu e todos esses líderes/Scrum Masters que conheço chegaram nesta posição por terem sido ótimos técnicos e se destacarem entre os demais. Como é que se pode ignorar este fato e pedir que eles simplesmente deixem de fazer o que mais sabem? Porque o Scrum Master não pode trabalhar com impedimentos técnicos? Ou programar? Desde que se concentre primariamente em exercer seu papel de Scrum Master, que não atrapalhe o time e que não atrapalhe o projeto, é totalmente aceitável que ele faça isso. Aliás, nenhum livro sobre Scrum fala o contrário.

Hoje, por exemplo, eu diria que uso metade do meu tempo exercendo ativamente o papel de Scrum Master. Na outra metade, eu não fico parado esperando o próximo problema acontecer.

No último Sprint do meu time, por exemplo, trabalhei para resolver um impedimento técnico gigantesco do próximo Sprint. Estamos no meio de um projeto importante para a empresa e a história que talvez seja a mais importante de todas acabou ficando de fora do Sprint. Já é certo que ela será a primeira história do próximo Sprint, porém, existe um grande impedimento técnico relacionado à forma como funciona uma API de busca interna da empresa, e eu trabalhei para contornar este problema e o time possa trabalhar tranquilamente na próxima semana. Outro exemplo, foi quando parei uns três dias para reconfigurar todo nosso ambiente de integração contínua e fazer um refactor agressivo no build. Ou então, para não desfocar o time do seu trabalho, eu resolvo silenciosamente vários bugzinhos chatos.

Muitas pessoas discordam dessa atitude simplesmente porque eu tive que codificar alguma coisa. Mas eu não estou facilitando o trabalho do time? Não estou resolvendo problemas e fazendo com que o time só precise se concentrar em entregar seu trabalho? O Scrum é um framework onde a cada período de desenvolvimento temos oportunidade de avaliar o que fizemos e nos adaptarmos às circuntâncias do projeto/time/empresa. Refletindo sobre o meu trabalho, percebi que se eu me adaptasse para trabalhar desta forma poderia contribuir muito mais com o time e a empresa do que simplesmente fazendo o feijão-com-arroz do Scrum.

Coincidentemente (ou não), o Phillip Calçado escreveu um post que vou usar como argumento para outro ponto importante. O manifesto ágil, base para todas as metodologias ágeis que conhecemos, coloca pessoas acima do processo. Ou seja, o processo importa menos do que as pessoas que participam dele. Parafraseando o Phillip, você não pode fazer que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor (ou Scrum Master) completamente desestimulado e frustrado na equipe. Mais ainda, você não pode fazer com que o processo deixe de lado pessoas técnicas altamente capazes.

A verdade é que não existe uma regra. Você faz a regra, mas faça com consciência e sabedoria.