Estou absolutamente convencido que um Design Document é um ser vivo. Nasce fruto de uma necessidade, cresce alimentando-se de intelecto, multiplica-se em testes, protótipos e iterações e quando na cadeia alimentar, os bichos maiores se alimentaram dele, morre e é esquecido apenas para dar lugar a outro de certeza diferente.
Pela parte que me toca sou apologista dos Design Documents que cumpram dois propósitos: ajudarem-me na decisão e que sejam documentos de consulta. Se falharem qualquer um dos dois propósitos são completamente inúteis.
Por um motivo que me ultrapassa, leio de tempos a tempos e por essa Internet fora, opiniões que vão contra a realização de Design Documents em equipas de reduzida dimensão. As mais comuns são que os Design Documents são inúteis antes de um protótipo e com a realização deste tornam-se desnecessários porque as decisões estão tomadas com a prova feita com o protótipo na medida em que não há assim tanta gente a quem passar esse conhecimento e que este é partilhado por todos. Outra é que os Design Documents são uma perda de tempo.
Os dois propósitos que eu julgo indispensáveis para um Design Document são a prova de que estas duas ideias não serão uma visão adulta e profissional do dito documento. Se a realização de um Design Document me ajuda na decisão, quer dizer que, já houve um protótipo e que se vai avançar com produção, mas desta vez, sem experiências desnecessárias. Elas vão existir de certeza mas serão menos. A segunda é que se é um documento de consulta, permite o acesso rápido à informação, ao próprio processo, ao que se pretende e/ou é necessário. Qualquer uma das duas bate o preconceito de ser uma perda de tempo.
Há um defeito nos Design Documents para o qual pessoalmente não arranjei solução. Como ser vivo evolutivo, o Design Document vai sofrer alterações durante as diversas iterações de desenvolvimento por motivos mais ou menos válidos. A única forma de o tornar perfeito seria conseguir prever essas alterações e penso que isso é praticamente impossível. Por isso o defeito é não haver um momento definido em que sei que o Design Document não deve entrar na fase seguinte sem iniciar o desenvolvimento.
Pela parte que me toca sou apologista dos Design Documents que cumpram dois propósitos: ajudarem-me na decisão e que sejam documentos de consulta. Se falharem qualquer um dos dois propósitos são completamente inúteis.
Por um motivo que me ultrapassa, leio de tempos a tempos e por essa Internet fora, opiniões que vão contra a realização de Design Documents em equipas de reduzida dimensão. As mais comuns são que os Design Documents são inúteis antes de um protótipo e com a realização deste tornam-se desnecessários porque as decisões estão tomadas com a prova feita com o protótipo na medida em que não há assim tanta gente a quem passar esse conhecimento e que este é partilhado por todos. Outra é que os Design Documents são uma perda de tempo.
Os dois propósitos que eu julgo indispensáveis para um Design Document são a prova de que estas duas ideias não serão uma visão adulta e profissional do dito documento. Se a realização de um Design Document me ajuda na decisão, quer dizer que, já houve um protótipo e que se vai avançar com produção, mas desta vez, sem experiências desnecessárias. Elas vão existir de certeza mas serão menos. A segunda é que se é um documento de consulta, permite o acesso rápido à informação, ao próprio processo, ao que se pretende e/ou é necessário. Qualquer uma das duas bate o preconceito de ser uma perda de tempo.
Há um defeito nos Design Documents para o qual pessoalmente não arranjei solução. Como ser vivo evolutivo, o Design Document vai sofrer alterações durante as diversas iterações de desenvolvimento por motivos mais ou menos válidos. A única forma de o tornar perfeito seria conseguir prever essas alterações e penso que isso é praticamente impossível. Por isso o defeito é não haver um momento definido em que sei que o Design Document não deve entrar na fase seguinte sem iniciar o desenvolvimento.
2 comentários:
Eu também era desses tipos que achava que equipas pequenas não precisavam de design docs... agora que me apanhei com uma carrada de linhas de código a monte devido a features metidas à pressão planeadas à última da hora, já mudei de ideias. :P
Nice! :) Fico feliz JD. Os DDs são importantes, digam o que disserem e quanto mais organizada for uma equipa, mais necessita de um DD e mais rápido se torna o desenvolvimento.
Enviar um comentário