BDUF ou LDUF? Qual seu defensor loja e por quê? [fechadas]

Question

Nossa loja está passando por algumas mudanças em diferentes áreas quando se trata de como realizamos nossos projetos de desenvolvimento. Originalmente, sendo uma grande organização, temos tradicionalmente seguido um modelo em cascata apenas ligeiramente modificado (não minha escolha !!!). Essencialmente passar o tempo pela primeira vez em requisitos, então lotes no projeto, em seguida, lotes de codificação, em seguida, mostrando as coisas para o cliente. Não é possível iniciar a fase seguinte até completar o primeiro!

Adivinha o quê? Que não exatamente garimpou para fora o melhor ao longo dos anos! Estou tentando fazer com que todos a bordo e mudança para um modelo mais centrado na metodologia ágil e prototipagem rápida. Eu sei para um fato que ele vai funcionar muito melhor do que as práticas atuais.

De qualquer forma, ao fazer design, o que são alguns de seus processos em torno dele? Mais especificamente, como você sabe quando você fez o suficiente, os processos que você segue?

Answer 1

"De qualquer forma, ao fazer design, o que são alguns de seus processos em torno dele? Mais especificamente, como você sabe quando você fez o suficiente, os processos que você segue?"

Na verdade, ele começa antes de design.

Comece com o início do projeto. Você tem duas maneiras de definir escopo. Tudo ou apenas o suficiente.

• Tudo é útil porque ele define uma ampla, objetivo distante, provavelmente inacessível. Mas, ele também estabelece um custo e cronograma que é vasto, enorme e tem um monte de zeros no preço.

• Just Enough é desconfortável porque parece que você colocou o ponto de laser alvo em um único micro-problema e você nunca vai construir algo escalável, abrangente e blá blá blá. Just Enough tem a vantagem de configuração e meta alcançável seguido por um rastro de potenciais objetivos futuros que provavelmente vai entrar em jogo.

Advice : O escopo deve ser a menor coisa que você pode fazer e resolver o problema de alguém. Isto é seguido por objetivos futuros que entram em jogo, mais tarde.

Quando você reunir os requisitos, você tem duas abordagens: Todos e apenas o suficiente.

• Tudo é útil porque permite que você para cobrir o seu @ $$ e começar argumentos intermináveis ??sobre o que eo que não é necessário.

• Just Enough é assustador porque você reunir os requisitos para o primeiro gol detalhado somente, e definir os outros requisitos de lado para consideração posterior. Algumas pessoas sentem que cada pequeno peido de cérebro é "necessária". Outras pessoas são mais iluminados e perceber que há um espectro de Moscovo (Must, deveriam, poderiam, não).

Advice : agressivamente e constantemente priorizar todos os requisitos. Trabalho com todos os envolvidos para perceber que "mais tarde" não significa "nunca". Criar um backlog formal, e priorizá-los constantemente. Reúna-se com os usuários quantas vezes eles têm uma pergunta, comentário ou cérebro peido e deixar a ajustar as prioridades. Eles adoram essas coisas.

E isso permite que você a planejar os itens de alta prioridade. Você pode então tirar algumas linhas "feito" através do backlog mostrando o quanto vai ser feito por uma determinada data e quanto vai ser feito para uma determinada quantidade de dinheiro.

Quando você começa a projetar, você pode olhar para as necessidades futuras de possíveis direções de crescimento futuro. Mas você não tem que tudo superdimensionar para atender todas as coisas chamados "requisitos" (muitos dos quais nem sequer são necessários.)

Com o tempo você começa a projetar, a agilidade do projeto já estará em vigor.

Answer 2

Pergunta: Quando você tem feito projeto suficiente?

Para o meu processo a resposta para isso é:. Quando há informação suficiente para mão confiantemente fora da implementação da coisa mais simples que poderia funcionar para outro desenvolvedor

Este abrange duas partes principais:

• A coisa mais simples que poderia funcionar: Esta é uma solução para o problema do cliente que tem resistido a algum escrutínio perto pelo perito domínio, consultores técnicos, gerente de projeto, gerente de produto e muito importante, o cliente. Esta necessidade não leva muito tempo -. De passar algumas horas em este é geralmente suficiente
• informações suficientes para mão de desenvolvimento. Este deve ser o caso , mesmo se você vai fazer a implementação yourself . Basicamente deve haver documentação apenas o suficiente para que alguém que não está familiarizado com o recurso específico (mas familiarizado com os objectivos globais da aplicação) tem uma boa cobertura do que precisa ser feito para que esse recurso.

Em minha experiência a dizer "construir um para jogar fora, você vai de qualquer maneira" normalmente vai. Sua primeira aplicação normalmente irá descobrir alguns mal-entendidos entre você eo cliente, ou entre outros membros do processo de implementação. Você não pode evitar isso, e é por isso que você tenta fazer o time-to-primeiro-implementação curto.
Depois de conseguir a primeira versão fora do caminho você encontrará a comunicação se torna mais fácil porque a compreensão de todos os requisitos e o processo é muito mais clara.

Você pode até achar que logo após este primeiro protótipo você pode fazer uma fase de projeto mais tempo porque você tem uma idéia melhor muito do que e como.