Quão bem definido deve ser um produto de software antes de começar a codificar?

Eu queria saber até que ponto as pessoas geralmente definem um produto de software antes de começar a codificar e como ele funcionou para eles. Refiro-me à definição de casos de uso, análise de riscos, desenho de diagramas de classes, etc.

Sei que é uma boa idéia ter uma idéia suficientemente boa de qual será o produto final para evitar riscos no futuro, mas também é importante não definir um produto tão bem que seja difícil se adaptar a ele. mudança.

Outras perguntas mais específicas provavelmente seriam:

1. Qual a porcentagem do tempo de um projeto normalmente gasta nos estágios de planejamento antes do desenvolvimento?

2. Você tem certos critérios mensuráveis ​​que tenta atender antes de começar a codificar ou isso é algo mais instintivo?

3. Você diagrama todas as classes antes de começar a codificar ou está tentando criar um design dinâmico desde o início, esperando que as coisas mudem?

Qualquer experiência que você esteja disposto a compartilhar seria incrível!

A resposta literal para "quão bem definido?" é

Bem definido o suficiente para você começar.

Bem definido o suficiente para que você possa identificar um escopo inicial de trabalho (para um conceito inicial). Isso é suficiente para ajudar a identificar as mudanças que inevitavelmente acontecerão.

Bem definido o suficiente para que você possa priorizar os sprints.

Estou me referindo à definição de casos de uso,

Sempre útil. Mas não todos . Você deve priorizar e cobrir os casos de uso importantes primeiro. Outros casos de uso serão abordados em releases posteriores. Alguns casos de uso terão uma prioridade tão baixa que nunca serão concluídos.

analisando risco,

Geralmente uma perda de tempo.

diagramas de classes de desenho etc.

Se isso ajudar.

Qual a porcentagem do tempo de um projeto normalmente gasta nos estágios de planejamento antes do desenvolvimento?

Isso varia muito. Compre um bom livro, como Software Engineering Economics, para obter números "oficiais".

Você tem certos critérios mensuráveis ​​que tenta atender antes de começar a codificar ou isso é algo mais instintivo?

"mensurável". Isso é quase impossível de definir.

"intestino". Política ruim.

A questão é "você entende o que está fazendo?"

Não é uma coisa instintiva. É uma pergunta sim / não.

Não é "mensurável", pois é apenas uma pergunta de sim / não.

E, além disso, você precisa priorizar. Você não faz tudo. Apenas o suficiente para lidar com os primeiros sprints.

Você diagrama todas as classes antes de começar a codificar ou está tentando criar um design dinâmico desde o início, esperando que as coisas mudem?

Você não pode saber tudo com antecedência.

Não tente.

Se o seu cliente ingressar ativamente no projeto como um membro da equipe do projeto, que está disponível para os desenvolvedores para perguntas e para tomar decisões rápidas sobre a funcionalidade. Então a especificação pode ser menos detalhada.

Se o seu cliente estiver longe e não estiver disponível para feedback por um longo período de tempo, suas especificações deverão ser muito detalhadas.

Em nossa empresa, criamos histórias de usuários e jogamos o Planning Poker com os desenvolvedores do projeto. Isso nos dá uma indicação justa das horas a serem gastas em uma história de usuário.

O quão bem definido o projeto precisa ser é suficiente para você começar e saber para onde vai se dirigir nas próximas duas semanas.

Como Scrum Master, eu simplesmente diria que você precisa definir recursos brutos do seu produto em uma planilha do Excel ou em qualquer outro lugar, apenas para acompanhar seus recursos. Torná-las Histórias de Usuário ajuda muito a pensar sobre qual recurso você precisará a seguir. Em seguida, priorize-os: o recurso mais importante ou imperativo para o topo e o menos para o fundo.

Depois de listar alguns dos recursos mais importantes, selecione os recursos que você acha que pode desenvolver e que levem ao estado Concluído após um período de duas semanas ou um mês, se preferir. Em seguida, exploda esses recursos selecionados para poder começar a codificar em alguns.

Ao codificar, você certamente pensará em outros elementos necessários para desenvolver os recursos selecionados em um estado Concluído. Concluído significa que você não tem mais nada a fazer, ou seja, testes, codificação, montagem, documentação está concluída!

A qualquer momento, sua lista de recursos selecionados poderá se expandir, desde que você atinja a meta, ou seja, você poderá desenvolver tudo o que disse durante um determinado período.

Em suma, nada tem que ser perfeito. Dê algumas idéias, compartilhe com seus companheiros e veja se o que está escrito faz sentido para atender aos requisitos do produto exigido. Se sim, então você está dentro! Para deixar claro, eu vou com um produto simples de Gerenciamento de Clientes. O que é preciso?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Seu primeiro rascunho pode ser tão simples quanto isso! Então, podemos ver que a segurança é uma parte importante do nosso sistema. É importante o suficiente para fazer a prioridade final (S / N)? Isso vai depender dos requisitos que você precisa atender. Digamos que o gerenciamento de clientes seja a coisa mais crucial aqui. Portanto, no próximo Sprint, precisamos gerenciar clientes de uma maneira básica, mas aceitável. O que é Gerenciamento de Clientes?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Isso já ilustra funcionalidades suficientes para poder começar a desenvolver o aplicativo. Se seus programadores precisarem de mais instruções, talvez um desenvolvedor que esteja familiarizado com os diagramas de classes possa criar a classe Customer e suas propriedades e métodos! Mas, no que me diz respeito, com os poucos que escrevi, teria o suficiente para começar. Alguns recursos podem ser adicionados ou alterados ao longo do caminho. O importante é focar no que você disse que iria ser feito. No nosso exemplo, é a coisa de Gerenciamento de Clientes. Não precisamos nos preocupar com a autenticação do usuário a partir de agora. Isso virá mais tarde no próximo Sprint.

Eu espero que isso ajude! =)

Bem, o que funciona muito bem para mim é ter a funcionalidade "razoavelmente bem" especificada e a arquitetura do software apenas muito vagamente especificada.

Para começar a trabalhar, preciso saber para o que estou trabalhando. Não funciona para mim quando apenas entendo as necessidades do cliente. Mesmo que eu esteja escrevendo uma ferramenta para meu próprio uso, eu desenho as telas, descrevo a funcionalidade, o que cada botão faz, tudo. Caso contrário, acho que não consigo começar.

Por outro lado, desisti de realmente desenhar exatamente como desenvolverei o código. Talvez essa seja a pior prática, mas funciona para mim. Posso definir um conjunto de tabelas de banco de dados que criarei, mas não quais colunas estão em cada uma. Posso pensar em quais objetos e classes preciso, mas definitivamente não desenho diagramas.

Inferno, às vezes nem sei como fazer direito até depois de fazer errado. Eu o construo uma vez, destruo e faço de novo, agora que sei como. Neste ponto, posso desenhar um roteiro bem detalhado e reiniciar.

Que linguagem e metodologia você está usando?

Algumas linguagens, como Java e C ++, exigem mais estrutura inicial do que linguagens como Common Lisp ou Python (C ++ mais que Java, porque a refatoração é mais fácil em Java). Leo Brodie (acho que em "Thinking Forth") deu dois conselhos sobre quando começar a codificar: mais cedo do que você se sente à vontade no Forth, mais tarde do que deseja em outro idioma.

A metodologia Waterfall (principalmente quando o design inicial é uma entrega) exigirá mais trabalho inicial do que o ágil (embora você também não queira negligenciar o planejamento inicial nos métodos ágeis). Ter um bom conjunto de testes automatizados torna mais seguro alterar coisas maiores e, portanto, permite que você se familiarize com menos trabalho inicial.

Além disso, depende dos indivíduos e sua familiaridade com o tipo de software a ser criado. Em um ponto, ao fazer aplicativos principalmente CRUD, eu poderia escrever um programa inteiro começando com algumas especificações e um pedaço de papel de nota em branco de 3 "x5". Não posso escrever as coisas que escrevo agora assim.

Dois termos úteis aqui são MVP (Produto mínimo viável) e MMF (Recurso comercializável mínimo). Um MMF é a versão menor de um recurso que agrega valor aos negócios. Um MVP é o menor número de MMFs viável como produto. Ao iniciar um projeto, a melhor coisa a fazer é identificar os MMFs e o MVP e começar a partir daí.

Libere seu produto assim que possível e continue melhorando gradualmente.