Pessoal, boa tarde.
Sempre trabalhei em projetos com documentação como caso de uso e diagramas.
As metodologias ágeis defendem que a documentação deve ser mínima equilibrando o suficiente pro desenvolvedor entender o que deve desenvolver e pro cliente entender o que está sendo desenvolvido (até pra não se tornar um projeto de manutenção de documentação).
Mas o que vocês me dizem de um projeto SEM documentação? Mesmo se for uma equipe pequena é importante ter a referência da documentação? No que a documentação é importante?
Valeu!
Um projeto sem documentação torna o entendimento do sistema sempre parcial. Cada um da equipe acaba conhecendo apenas uma parte da aplicação ficando sem conhece o todo. Não estou dizendo que não funciona, mas quando funciona acaba ficando muito traumático a manutenção do código.
Além disso, os requisitos estabelecem um contrato com o cliente, definido o que será feito. Sem isso como serão tratadas as alterações de uma funcionalidade que acabou de ser implantada no sistema? Pro cliente pode parecer uma correção quando na verdade é uma evolução (ou seja o cliente não quis algum comporntamento num primeiro momento e agora decidiu colocar na aplicação).
Já trabalhei em sistemas sem documentação e com documentação. Por mais que documentar seja trabalhoso (e até chato), prefiro ter o sistema bem documentado.
E quando a gestão do projeto insiste em não documentar, alegando que é desperdício de tempo quando “tá todo mundo ali do lado pra perguntar”…?!?
Que prós vocês me dão que eu possa utilizar pra demonstrar a necessidade dessa documentação?
faça uma classe com uma regra de negocio ainda nao especificada pela equipe toda, e manda alguem da manutençao =) dai vao saber o por que da documentaçao
[quote=Fox McCloud]E quando a gestão do projeto insiste em não documentar, alegando que é desperdício de tempo quando “tá todo mundo ali do lado pra perguntar”…?!?
Que prós vocês me dão que eu possa utilizar pra demonstrar a necessidade dessa documentação?[/quote]
Gosto quando o “tá todo mundo ali do lado pra perguntar” na verdade é uma “Euquipe”, e esta já está vazando da empresa.
Por essas e outras que se envolve o cliente do produto na produção do mesmo, ele é quem deve saber de verdade o que um sistema faz.
Prossigo argumentando como se eu fosse o gestor da equipe pra ver que argumentos vocês me dão (preciso reunir esses argumentos, rsrsrs).
Tenho enfrentado dificuldades por exemplo em lembrar a regra toda durante o desenvolvimento, já que só posso me concentrar em uma parte de cada vez, e acabo tendo que “tirar dúvida” em cada ponto do escopo que eu alcanço…
Fora as vezes em que eu fico com uma dúvida da regra de negócio ou funcionalidade e quando vou perguntar eu ouço um “putz, é mesmo… precisamos ver isso, o que você acha?” (detalhe, com prazo pra daqui a um ou dois dias)
Gestor:
No caso o produto foi vendido fechado e o conceito é nosso, então não corre o risco de o cliente perder pessoal que detém as regras de negócio porque o conceito é nosso (da consultoria) e todo mundo aqui é parceiro de confiança.
Além disso já atuamos assim anteriormente e sempre foi rapidinho chegar, explicar a regra toda e se surgir alguma dúvida você vem e tira comigo, que é muito mais rápido do que ter que ficar digitando documentação que pode até acabar sendo redundante ou explicando coisas que você já sabe…
Gostamos da forma como você interage com a gente abordando os pontos do negócio e ajudando a enriquecer as funcionalidades, já agilizando o que pode ser melhorado facilmente, sem burocracia.
