Documentação Ágil

Por: Guilherme Chapiewski

Alguns pensamentos sobre “documentação ágil”

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.

Palestra de Vinicius Teles no Rails Summit 2009

Acabei de ver pela santa web a palestra do @viniciusteles no #railssummit 2009.

Excelentes lições de tec #empreendedorismo

Link: http://blip.tv/file/2726351

É legal ver o sucesso do produto(be on the net) dele. É legal ver ele se dando bem mantendo-se fiel ao que sempre acreditou. É legal ver, no flashback que ele faz na palestra, um cara ficando adulto e paralelamente não se tornado um desistente (adultos, por muito muito comumente abrirem mão das visões de futuro que tinham quando jovens, deveriam ser chamados de desistentes, acho que foi em [Senge, A quinta disciplina] que li isto).

E o mais legal de tudo é que uma parte substancial do flashback apresentado na palestra, eu acompanhei relativamente de perto. Espero ser o próximo. Se o único motivo para a improve it não ter fechado foi ele ser muitíssimo teimoso, eu tô muito bem encaminhado. Me faltam reservas, mas eu chego lá. :-)

Att.,
Vinicius AC
Voltando a ativa :-)

Paggo e Globo.com (XP e SCRUN) – Bons exemplos de sucesso

A SWX será a próxima : – )

1 – A globo.com foi exemplo de sucesso na época que eu estava estudando pra mono, mas não citei na apresentação pq tava muito no início ainda, a experiência deles.

No link abaixo, Guilherme Chapiewski comenta como estão as coisas na Globo.com. Ele já comentou algumas vezes aqui no blog \o/. Legal ver estas coisas. Chega deu um frio na barriga.  : – )
http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/

———————————–

2 – Já a Paggo foi mostrada em detalhes na apresentação de minha mono como um dos exemplos práticos de sucesso . O Oi Paggo estava sendo lançado na época.
Rapidão e muito legal. http://blog.improveit.com.br/articles/2008/07/26/entrevista-com-cicero-torteli-fundador-da-paggo (no final deste post, tem uma pequena explicação do Vinicius Teles, sobre o vídeo, aconselho a ir lá e ler, antes de ver)

Vinicius Teles , o carinha que no vídeo entrevista Cicero Torteli, fundador da Paggo, é na minha opinião um dos maiores nomes do desenvolvimento ágil no mundo. Já escutei dezenas de podcasts dele, li um monte de artigo, e o livro dele foi o culpado pelo tema da minha monografia.

=====================================

Depois de ver estes exemplos de sucesso(e outros), tenho certeza que daqui a um tempo, a coisa vai tá bem encaminhada até nas universidades (até na UFS onde já se fala de desenvolvimento ágil nas matérias de análise, mas de forma ainda muito tímida). Especificamente em desenvolvimento de Software, o meio acadêmico é uma onda. Só aceita inovações verdadeiras depois que estas estão consolidadas nas empresas, ou seja, quando elas já deixaram de ser inovações (normalmente quando já são mainstream). No fundo é um comportamente típico de replicadores de conhecimento e não de geradores. O meio acadêmico imponhe barreiras que tornam as unviversidades verdadeiros late adopters(lembrei de bernabó) no que diz respeito a desenvolvimento de software .

Enquanto isto, as certificadoras adaptam-se para não perder seu bom e certo ganha pão (não vão perder, tenho certeza). Porém, por mais que mudem o discurso(já mudaram muito), no fundo serão Frankensteins, porque estão exertando partes de coisas que, ainda por cima, vem de fontes nas quais nem acreditam. Pior é que acabam distorcendo no atacado, justamente a base de tudo, ou seja, valores e princípios, deixando complexo o que nasceu pra ser simples. :)

Já a algum tempo, na verdade desde que li o post de Chapiewski , tive vontade de comentar aqui, mas nunca tinha tido tempo para fazer minhas considerações. Acordei agora, sentei e fiz. Agora voltarei a estudar, pq se Deus quiser, em poucos meses a primeira versão de um produto filé será lançado. : – )
———- Forwarded message ———-
From: Vinicius Manhaes Teles
Pessoal,
Sei que ando sumido das listas. Desculpem, mas não tem dado para
participar. Estava há pouco em São Paulo, onde acabei re-encontrando
meu amigo Cicero Torteli, fundador da Paggo. Para quem não conhece, a
Paggo se juntou com a Oi em 2005 para criar o Oi Paggo, uma solução de
mobile payment inédita no mundo. A Paggo criou uma operadora de cartão
de crédito do zero em menos de um ano, usando uma metodologia ágil, no
caso o XP.

Neste breve vídeo, de apenas seis minutos, o Cicero conta um pouco do
que foi essa experiência e dá uma mensagem para os gestores que ainda
têm medo de usar métodos ágeis.

http://blog.improveit.com.br/articles/2008/07/26/entrevista-com-cicero-torteli-fundador-da-paggo

Grande abraço,
Vinícius Teles

Improve It

Desenvolvimento Ágil com Extreme Programming

(atualizado em: 09/01/2007)

Desenvolvimento Ágil
com
Programação Extrema

Finalmente estou publicando o conteúdo completo da minha monografia aqui no Blog. Considerando que o blog surgiu em função do estudo para este trabalho, e que a apresentação foi a uns 2 meses, realmente demorei tempo demais. Mas foi por um bom motivo. Acrescentei conteúdo novo e corrigi algumas coisas também.

O título é:
DESENVOLVIMENTO ÁGIL COM PROGRAMAÇÃO EXTREMA
EFICÁCIA E DISCIPLINA EXTREMA NO DESENVOLVIMENTO ORIENTADO A OBJETOS DE SOFTWARE

AVISO

O autor é o titular dos direitos autorais do trabalho que você está preste a baixar em seu computador. Este trabalho destina-se para uso pessoal ou científico.
Está proibida comercialização de qualquer espécie sem autorização prévia do autor.

DOWNLOAD

Qualquer ajuda, crítica, sugestão, correção, será muito bem vinda.
Obrigado!

BETA - Apesar do beta estampado no topo das páginas, esta versão está finalizada. Não há versão mais nova do que esta.

Qualidade (Princípio da XP)

3.3.12 Qualidadade (Princípio da XP)

Maior qualidade significa menos defeitos e retrabalho, menos aborrecimentos e maior segurança para clientes e desenvolvedores, maior confiança, menos ansiedade, maior motivação, maior efetividade, maior produtividade e maiores lucros, entre outras coisas. Ou seja, maior qualidade significa gerar maior valor de forma mais simples e eficientes, e com menos custos [IMPROVE IT, XP].

Qualidade motiva a equipe, entre outras coisas, porque as pessoas geralmente não gostam de fazer trabalhos medíocres, pelo contrário, elas sentem-se muito mais motivadas quando têm a oportunidade de trabalhar com qualidade e se orgulham disto [BECK, 2005].

Existe uma crença de que alta qualidade signifique gastos mais elevados. Não há dúvidas de que a qualidade tem um preço, mas a falta dela tem um preço ainda maior [IMPROVE IT, XP]. Sacrificar a qualidade nunca é uma boa forma de controlar o tempo ou os custos. Projetos não se tornam mais rápidos ou mais baratos, de acordo com a diminuição da qualidade, assim como não se tornam mais lentos ou mais caros de acordo com o aumento. Geralmente ocorre o contrário, ou seja, o aumento da qualidade gera entregas mais rápidas e com menores custos, enquanto que a diminuição resulta freqüentemente em atrasos e maiores custos [BECK, 2005].

A XP acredita que qualidade não é uma boa variável de controle para projetos. Para a XP, uma forma eficiente de gerenciar o andamento de um projeto com alguma flexibilidade é através do controle do escopo, já que este nunca é conhecido precisamente e em detalhes com uma boa antecedência. Além disso, o tempo e o custo são comumente fixados logo no início do projeto. Os ciclos semanais e trimestrais provêem pontos explícitos para acompanhamento e escolha do escopo [BECK, 2005].

Qualidade não é um argumento para falta de ação. Caso não se conheça uma solução clara para uma tarefa urgente, o indicado é resolver da melhor maneira possível. Se existe uma solução clara, mas que vai levar muito tempo, deve-se fazer com a melhor qualidade possível de acordo com o tempo disponível [BECK, 2005]. O mais importante é sempre ter em mente o significado e a importância de princípios como qualidade e melhoria, e assim agir da forma mais efetiva de acordo com cada contexto.

Talvez a única característica que realmente justifica o nome programação extrema para a metodologia, seja a extrema importância dada à geração do máximo de valor da forma mais simples e eficiente possível, e é por este motivo que a qualidade é tão importante para a XP.

Abraços,
Vinicius AC.

Desenvolvimento Ágil x Tradicional – Resultados (Sucessos)

(atualizado em: 08/01/2007)

Resultados do Desenvolvimento Tradicional

Desde 1994, o Standish Group International publica a cada dois anos um estudo intitulado de Chaos Research [STANDISH, 2001] que consolida as informações de uma grande pesquisa sobre sucessos e fracassos dos projetos de software (figura 2.4). Neste estudo, os resultados dos projetos são enquadrados em uma das seguintes categorias:

  • Bem sucedidos – O projeto é finalizado no prazo, dentro do orçamento e contendo todas as funcionalidades especificadas.
  • Comprometidos – O projeto é finalizado e um software operacional é entregue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além disso, o software entregue possui menos funcionalidades do que o especificado.
  • Fracassados – O projeto é cancelado em algum momento durante o desenvolvimento.

14.jpg

Figura 2.4 – Resultados dos estudos Chaos Research

Este estudo é bastante abrangente, pois engloba uma grande quantidade de projetos com as mais diversas metodologias de desenvolvimento. Porém, apesar da diversidade de metodologias, a grande maioria delas é baseada no desenvolvimento tradicional. A figura 2.4 mostra que apesar de ter ocorrido um aumento substancial da porcentagem de projetos bem sucedidos e diminuição de fracassados, os últimos resultados ainda são muito ruins, pois os projetos fracassados e comprometidos equivalem a 66% do total.

Como já foi dito neste trabalho, todas as metodologias tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software. Porém, de acordo com os resultados alarmantes conseguidos nos últimos anos (figura 2.4), está claro que o desenvolvimento tradicional não tem conseguido atingir este objetivo. Estes resultados respaldam a afirmação de Brooks (seção 2.2.5) de que o desenvolvimento tradicional é equivocado.

 

Resultados do Desenvolvimento Ágil

Nos anos de 2006 e 2007, Scott Ambler organizou pesquisas para medir a adesão dos profissionais e das empresas aos valores, princípios e práticas comumente usadas no paradigma ágil. Os pesquisados tiveram que responder um questionário com perguntas relacionadas ao objetivo da pesquisa. Os resultados das duas pesquisa foram publicados na revista Dr. Dobb’s [DOBBS, WEB].

Os resultados mostram, entre outras coisas, que a grande maioria das empresas pesquisadas já adota técnicas ágeis, e que um adicional de aproximadamente 7% pretende adotar em no máximo 1 ano (figura 2.7).

Taxa de adoção de técnicas ágeis pelas organizações

Figura 2.7 – Taxa de adoção de técnicas ágeis pelas organizações

Outra constatação muito importante é que a adoção de técnicas ágeis não está restrita a projetos pilotos, isto fica claro na figura 2.8 que mostra a quantidade de projetos ágeis em andamento por organização.

Número de projetos ágeis em andamento

Figura 2.8 – Número de projetos ágeis em andamento

Os dados da pesquisa de 2007 também mostram claramente que as técnicas ágeis foram implantadas com sucesso na maioria das empresas pesquisadas. A figura 2.9 mostra a porcentagem global de sucesso nos projetos. Neste caso não houve na pergunta uma definição formal de sucesso, já que esta definição em projetos de TI costuma variar por organização e freqüentemente até mesmo por projeto.
As fatias do gráfico indicam as porcentagens de pessoas que acreditam que seus projetos ágeis estão dentro da faixa de sucesso representada pela cor. A faixa de sucesso que cada cor representa está descrita na legenda.
Ex.: 77%(verde claro + verde escuro) das pessoas pesquisadas indicaram que seus projetos ágeis tiveram mais que 75% de sucesso. (nada mal)

Porcentagem global de sucesso nos projetos
Figura 2.9

Apesar da diferença de tamanho da amostra, em relação ao Chaos Research [STANDISH, 1994], os resultados mostrados na figura 2.9 são muito significativos e esclarecedores, pois dão uma boa idéia da grande diferença que existe em termos de resultados, entre os processos ágeis e os tradicionais. A pesquisa, feita através da Internet, recebeu respostas de 781 pessoas da área de TI, sendo 52% desenvolvedores e 22% gerentes, em março de 2007 [DOBBS, WEB; AMBLER, WEB].

Com base nos dados mostrados, fica claro que as metodologias ágeis, seis anos após seu surgimento, estão deixando de ser algo incerto, adotado somente por empresas jovens e com cultura fortemente voltada para inovação. O grande crescimento dos projetos que usam técnicas ágeis, em número e tamanho, nas mais variadas organizações, incluindo as grandes e tradicionais, mostra que o desenvolvimento ágil está tornando-se rapidamente a opção comum da maioria das empresas para projetos de software.

Essa pesquisa não é “A PESQUISA!”. Mas, independente de outras coisas, ela já merece algum crédito por ter sido publicada numa das maiores revistas, focada em desenvolvimento de aplicações e sistemas embarcados, do mundo. Somado a isto, existe o crédito da pesquisa ter sido organizada por um cara extremamente competente e bastante conhecido (Scott Ambler). Minha opinião pessoal é que, por estes dois motivos, ela merece mais que “algum crédito”, ela merece muito respeito e quase tanto crédito quanto o Chaos Research [STANDISH, 2001]. :)

Abraços,
Vinicius AC

Processo iterativo e em espiral no mundo ágil

No desenvolvimento ágil, os projetos adotam o processo iterativo e em espiral (figura 2.5). No modelo espiral a dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral.

Processo iterativo e em espiral no mundo ágil

Figura 2.5 – Desenvolvimento iterativo em espiral

No desenvolvimento ágil cada setor da espiral corresponde a um ciclo de desenvolvimento, sendo que estes ciclos devem ser curtos e ter tamanho(tempo) fixo.

Cada ciclo é precedido por uma retrospectiva que objetiva manter um processo de evolução contínua com base no aprendizado adquirido até o momento através dos ciclos anteriores.

Os ciclos são chamados de iterações e sempre acrescentam valor ao projeto na forma de novas funcionalidades implementadas, testadas e aprovadas. Isto permite que o cliente acompanhe na prática e gradativamente a evolução do projeto, obtenha muito mais cedo os benefícios do sistema, avalie a evolução do projeto e dê feedback constante para os desenvolvedores sobre as funcionalidades implementadas [TELES, 2004].