Artigos Engenharia de Software Projeto de software como um processo evolutivo

Escutamos vários absurdos que poderiam ser evitados como “...imagina construirmos um prédio sem projetarmos encanamento, sem projetarmos a fiação elétrica, sem projetarmos estacionamentos e cômodos…”.

É um absurdo escutar isso. Então tente imaginar um software como um prédio, um software não é uma obra de engenharia civil, um software pode ser comparado a algum tipo de organismo vivo, que poderá evoluir ao longo do tempo, ou alguém já projetou um software todo antes e no final do projeto o software está igual ao o projeto inicial? Pouco provável, não acham?

Esse exemplo dado faz refletir muito sobre quanto um exemplo como esse tem um impacto em nossos projetos de software, pois todos que estão trabalhando ou estudando podem levar para suas empresas e grupos essa “metáfora” que lhes foi dita e ser interpretada de forma errada.

No início do desenvolvimento de software talvez essa metáfora tenha sido de grande valia, uma vez que projetávamos e desenvolvíamos softwares bastante simples em comparação aos desenvolvidos atualmente. Porém, nos tempos de hoje, onde os negócios mudam em um piscar de olhos, onde os sistemas são imensamente mais complexos do que antes e que nossos softwares a cada dia que passa, tentam imitar mais os seres humanos, é impossível projetar um sistema inteiro antes do desenvolvimento. O software tem que evoluir ao longo do tempo, isso não está sendo dito agora neste artigo, isso já é discutido há tempos.

“A metáfora do edifício” já perdeu sua utilidade, é hora de mudar novamente. As estruturas conceituais que hoje construímos são complexas demais para serem especificadas detalhadamente com antecedência, são também complexas demais para serem construídas sem defeitos. Devemos, portanto, adotar uma abordagem radicalmente diferente. Vamos nos voltar à natureza e estudar a complexidade das coisas vivas, em vez dos trabalhos mortos do homem. Seguindo este contexto, encontramos estruturas com uma complexidade imensa: o cérebro, por exemplo, é mais complexo do que é possível mapear e mais poderoso do que se pode imitar, é rico em diversidade, auto protetor e auto renovador. O segredo é que o cérebro evolui, não é construído, o mesmo deve acontecer com nossos sistemas de software, onde qualquer sistema de software deve ser evoluído através do desenvolvimento incremental. Isso ainda mostra que esse tipo de pensamento não é algo recente, porém, ainda nos tempos atuais temos que escutar que o software é um “trabalho morto” feito pelo homem. Sendo assim, existem alguns pensamentos sobre “documentação ágil”, pois 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 do 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, sendo que 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 ideia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Pode haver projetos onde documentar é extremamente necessário, por exemplo, um projeto com vários times onde nem sempre os desenvolvedores estão no mesmo espaço físico, portanto, era preciso documentar alguns pontos chaves da arquitetura e ambiente para que todos pudessem trabalhar sem problemas, podendo haver situações onde o time desenvolva componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times possam trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso, neste projeto foi documentado apenas o que fazia sentido a ser documentado.

Documentação ágil

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 chamamos de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observamos ao longo do tempo em diversos projetos. 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 ideais entre os analistas e os programadores. No desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos. Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. A documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros da equipe.

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-se 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 há uma maneira mais fácil de ser feita.

Documente o necessário, não mais que isso e de maneira fácil: 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 não deve ser documentado. Documento tem que ter um motivo documentar sem uma necessidade real não faz nenhum sentido. Assim o documentar fica muito mais rápido, se for fácil documentar, as chances de você fazê-lo serão maiores, a documentação tem que ser fácil de ser acessada, assim ela fica muito mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros da equipe possam documentar.