ti-enxame.com

Quanto tempo você dedica ao (s) documento (s) de design do seu software?

Obviamente, o tamanho do projeto em que você está trabalhando será um grande fator em quanto tempo você gasta escrevendo o documento/especificação de design. Mas você passa por tudo, escolhendo cada pequeno detalhe? Ou você adota uma abordagem mais ágil e começa a escrever o software bem cedo e resolve os problemas à medida que aparecem?

Sempre achei que só há um limite para o qual você pode ir com o design. Haverá inevitavelmente algumas coisas que serão perdidas e, nesse ponto, o quão bem você pode se adaptar à situação significa mais do que a própria especificação.

Estou tendo o ponto de vista correto sobre isso? É realmente uma opinião ou uma especificação de design perfeita é sempre o melhor caminho a seguir?

6
Harry

Depende um pouco do seu público-alvo, mas minha experiência (mais no desenvolvimento de pequena/média escala do que no trabalho em escala muito grande) é que documentos de design detalhados são árduos e tediosos de escrever, raramente lidos e tendem a ficar desatualizados pelo momento em que um projeto é entregue.

Isso não significa que eles sejam inúteis - se você está entregando algo para alguém, é necessário que haja uma declaração oficial e acordada do que será entregue, suficientemente detalhada para que todos possam apontar caso alguém esteja insatisfeito com o negócio e diga " isso é o que prometemos "e avalie com o que foi entregue.

Se eu estivesse montando uma empresa para construir um produto, entretanto, não me preocuparia tanto com uma especificação detalhada. Eu gostaria de documentar o que que íamos fazer, mas não gostaria de entrar em detalhes sobre como - essa é a parte que provavelmente alterar e deixar os documentos desatualizados e inúteis ou mesmo imprecisos o suficiente para serem realmente obstrutivos. Eu preferiria documentar o "como" no código usando qualquer formato de documentação que a linguagem ou IDE suporta melhor, de modo que conforme o código muda seja mais fácil atualizar a documentação ao mesmo tempo. Não vai impedir que fique desatualizado, mas vai reduzir um pouco.

O ideal é que você deseje um documento de design que possa funcionar como seu manual quando o código estiver completo, mas não conheço ninguém que tenha conseguido isso.

3
glenatron

Definitivamente, depende do tamanho e da estrutura do projeto.

Para projetos de clientes, especificações detalhadas são obrigatórias. Gosto de envolver fortemente o cliente durante a especificação do projeto. Isso ajuda a eliminar considerações extras e dá ao cliente uma melhor compreensão do que esperar. Geralmente, há uma mudança positiva na atitude (em relação ao tempo e ao preço) depois que a descoberta e as especificações são concluídas. Isso também nos permite definir marcos - e atingi-los - o que é favorável para o cliente e nossa equipe de desenvolvimento.

Para projetos internos e projetos paralelos divertidos, geralmente crio um fluxograma e uma lista de recursos e, em seguida, começo a hackea-los juntos. Nesses casos, o que considero mais importante do que uma folha de especificações de recursos é a IU real. Vou criar um wireframe do site no papel e fazer uma construção simples da IU (html/css). Isso me ajuda a pensar sobre a experiência do usuário, que valorizo ​​mais do que recursos específicos em meus próprios projetos. Sempre posso voltar e juntar os recursos mais tarde.

1
Maxmzd

Depende do que você entende por documentos de design.

Passo 1/3 a 1/2 do meu tempo escrevendo projetos para o software que escrevo, em um caderno, esboçando coisas, descobrindo algoritmos, relacionamentos, histórias, etc.

Eu não faço isso tudo na frente.

Não tenho um documento principal assinado e selado com o qual estou trabalhando. Já fiz no passado, e nunca terminei nenhum trabalho, porque estava sempre esperando alguém assinar alguma coisa. Isso era mais um problema com a burocracia da empresa com a qual eu trabalhava do que com o conceito de projetar tudo na frente, mas ainda prefiro a abordagem mais fluida/ágil que tenho agora.

1
Matt Ellen