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


13

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!

Respostas:


10

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.


pessoalmente, acho que gastar muito tempo escrevendo diagramas de classe é uma perda de tempo, pois o modelo e o código com ele são alterados assim que você inicia.
AndersK

Concordo que você não pode saber tudo com antecedência, mas um bom documento de design ajudará você a identificar o escopo e a fluência de recursos quando isso acontecer.
Tim Post

@ Tim Post: Boa sugestão. Essa é uma maneira de definir o "quão bem definido" na pergunta. Isso "ajudará a identificar o escopo e a fluência dos recursos". Não muito mais, certo?
precisa saber é o seguinte

@ Tim Post: "identificar escopo" é enganoso. Isso implica que existe algum conhecimento definido do "escopo" disponível no início do projeto, o que não é verdade. O escopo mudará ao longo do ciclo de vida do projeto, conforme as necessidades dos negócios mudarem, porque nenhum mercado é estático.
Rein Henrichs

@ Rein Henrichs: ajustei a resposta levemente para incorporar o seu argumento. Definição de escopo suficiente para começar. Estou tentado a adicionar "e não mais".
precisa saber é o seguinte

2

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.


Um "representante do cliente" (a função que você está sugerindo para o cliente) é a função mais vital em toda a equipe. Se sua equipe não pode obter respostas para perguntas sobre produtos e negócios, como eles devem tomar a decisão certa?
Re

Esse é um ótimo ponto, obrigado! Não pensei em como o envolvimento do cliente poderia mudar drasticamente o que funciona melhor para um determinado projeto. Definitivamente, algo que eu deveria ter em mente. Além disso, eu nunca tinha ouvido falar de "Planning Poker" e isso parece ser realmente valioso.
drewag

2

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! =)


Muito obrigado! Foi ótimo ver isso em um cenário tão específico. Eu sinto que essa é uma boa estrutura para ter algo que seja pelo menos um pouco mensurável, referente ao que você define sobre o produto geral, mas enfatizando subobjetivos e uma abordagem orientada a recursos. Essa abordagem será definitivamente importante quando eu começar novos projetos no futuro!
drewag

Seja bem-vindo! Estou feliz que meu grão de sal possa ajudá-lo! =) É importante não definir muito em profundidade os recursos, pois os requisitos do produto podem mudar ao longo do caminho, porque o cliente, quando ele ver o que você fez até agora, pode ter outras idéias ou alterações para fazer com o que você Feito. Você precisará ajustar o produto de acordo com os novos requisitos. Portanto, se você estabeleceu tudo de uma só vez no início do projeto, imagine a perda de trabalho que isso pode causar! Talvez você tenha trabalhado horas apenas para jogá-lo fora e reiniciar do zero. Deixá-lo evoluir =)
Will Marcouiller

1

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.


Obrigado por compartilhar sua experiência. Parece concordar com o consenso de que o importante é que você, como desenvolvedor, se sinta à vontade o suficiente para começar. É claro que você descobrirá as coisas que mudaria se o fizesse novamente, caso contrário, passaria muito tempo planejando. Conheço a sensação de querer fazer uma reescrita completa assim que um produto terminar, e é isso que estou tentando evitar;) (pelo menos em um grau razoável).
drewag

1

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.


Obrigado pela perspectiva. Eu não tinha considerado como o idioma e a plataforma poderiam afetar as melhores práticas quando se trata de gerenciamento de projetos. Por acaso, estou falando principalmente sobre Objective-C, UIKit e AppKit. No entanto, eu também trabalho em várias outras linguagens (C, C ++, C #, Java, Python, etc.). Isso significa que eu devo tomar cuidado para não supor que um determinado método seja melhor para todos os projetos; devo ajustar minha base de metodologia na plataforma e no idioma de destino (e talvez escolher um idioma com base nisso, se eu tiver uma escolha).
drewag

1

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.


Essa é uma terminologia realmente ótima, obrigado! Essa é de longe a melhor coisa aqui por apresentar algo mensurável. Claro que não é perfeito, mas parece que será razoavelmente fácil decidir se um recurso é comercializável e / ou agrega valor ao produto.
drewag
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.