No segundo valor “Software em funcionamento, mais que documentação abrangente”, não ter a documentação completa do “projeto” não impacta caso tenha alguma correção/erro futuro? Ressaltando, também, que hoje muitas das empresas terceirizam os DEVs.
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
No segundo valor “Software em funcionamento, mais que documentação abrangente”, não ter a documentação completa do “projeto” não impacta caso tenha alguma correção/erro futuro? Ressaltando, também, que hoje muitas das empresas terceirizam os DEVs.
Oi, Gabrielle! Tudo bem?
Essa é uma ótima pergunta e uma preocupação válida quando se trabalha com desenvolvimento ágil. O segundo valor do Manifesto Ágil, "Software em funcionamento mais que documentação abrangente", não significa que a documentação deve ser completamente ignorada. A ideia é priorizar a entrega de um software que funcione e que atenda às necessidades do cliente, em vez de gastar muito tempo criando uma documentação extensa que pode não ser tão útil.
No entanto, isso não quer dizer que a documentação não é importante. A abordagem ágil sugere que a documentação deve ser "suficiente" para que o time possa continuar o trabalho de forma eficiente e que qualquer pessoa nova, incluindo desenvolvedores terceirizados, possa entender o sistema sem dificuldades excessivas.
Aqui estão algumas práticas que podem ajudar a equilibrar a necessidade de documentação com a filosofia ágil:
Documentação Just-in-Time (JIT): Em vez de criar toda a documentação no início do projeto, você pode documentar as partes mais críticas conforme elas são desenvolvidas. Isso garante que a documentação esteja sempre atualizada e relevante.
Documentação Automática: Ferramentas como Javadoc para Java ou Sphinx para Python podem gerar documentação a partir do código, o que ajuda a manter a documentação sincronizada com o software.
Comentários no Código: Comentários bem escritos no código podem servir como uma forma de documentação que está sempre próxima do que realmente está sendo executado.
Wiki ou Confluence: Manter uma wiki ou uma página no Confluence onde a equipe pode adicionar informações importantes sobre o projeto pode ser muito útil. Isso pode incluir diagramas de arquitetura, decisões de design, e outros detalhes importantes.
Revisões de Código e Pair Programming: Essas práticas ajudam a disseminar o conhecimento do sistema entre os membros da equipe, reduzindo a dependência de documentação extensa.
Lembre-se, o objetivo é encontrar um equilíbrio que permita que a equipe seja ágil e eficiente, mas também preparada para lidar com mudanças e novos membros no time.
Bons estudos!