Quero explicar por que a especificação não deve ser alterada durante o período de desenvolvimento

Quero explicar por que a especificação não deve ser alterada durante o período de desenvolvimento para o novo funcionário do departamento de planejamento.

Uma especificação quase sempre muda durante o desenvolvimento para qualquer projeto, exceto o mais simples.

Os motivos são:

• O desenvolvimento ou o teste de integração mais provável do projeto descobre coisas que não foram notadas quando as especificações originais foram feitas - desde casos extremos até aspectos importantes. Por exemplo, o desenvolvedor nota que podem chegar confirmações de mensagens fora de ordem.

• As condições do mundo real que determinam as especificações não são congeladas. Por exemplo, é criado um novo produto financeiro que precisa ser adicionado às especificações de processamento direto.

• As pressões de prazo resultam na remoção de recursos.

• Outras partes interessadas do projeto são descobertas (por exemplo, no meio do projeto, um projeto semelhante é descoberto em uma área diferente, e os subsistemas comuns precisam ser centralizados / compartilhados - isso aconteceu comigo no meio do projeto de dois anos, resultando em grandes arquitetura).

• Patrocinadores adicionais do projeto têm novos requisitos de especificação (um dos exemplos mais famosos é a história do desenvolvimento do Bradley Fighting Vehicle).

Por que as alterações nas especificações têm efeito adverso (você não pode dizer "não deve acontecer", pois, como você pode ver, existem muitas razões para isso, quase todas fora do seu controle e muitas por uma boa razão) -

• As alterações nas especificações resultam em alterações no código, impedindo-o de concluir as partes do projeto que ainda não foram escritas (como todos sabemos, e evangelizadas por Joel Spolsky, as alterações de foco são muito ruins para os desenvolvedores)

• Algumas alterações nas especificações (às vezes MUITO menores) podem resultar na necessidade de re-projetar / re-arquitetar completamente o sistema, uma vez que uma escolha entre duas arquiteturas foi feita com base em uma suposição tirada das especificações .

• No caso de TDD, uma grande parte do trabalho posta em testes pode ser anulada.

• Se as alterações nas especificações vierem de partes interessadas adicionais, conforme observado acima, elas podem ser contraditórias às especificações existentes, resultando em uma redução significativa na qualidade do produto (consulte Fighting Vehicle, Bradley).

• A alteração nas especificações pode violar alguns requisitos comerciais existentes de que o trocador / solicitante pode não ter conhecimento ou cuidado (esse é realmente o mesmo que o último ponto).

O que tudo isso significa é, obviamente, a data de entrega estendida (às vezes significativamente) do projeto e a probabilidade potencialmente maior de defeitos.

Para o melhor exemplo de sempre de como uma pequena alteração nas especificações pode criar problemas extremos, tenho três letras para você:

Y2K .

Tudo o que eles fizeram foi mudar a especificação para dizer " deve funcionar após o ano 2000 ".

Além disso, em algumas situações, é de fato que a especificação NÃO DEVE mudar (ao contrário de "não deve mudar sem uma boa razão"):

• Parte da especificação é (ou depende) de uma especificação de um sistema externo que deve ser interface.

• Parte da especificação é (ou depende) de um hardware no qual o sistema está implementado.

• Requisitos de contrato com um cliente (embora a limitação seja estritamente relacionada à alteração das especificações sem antes trabalhar com as alterações com o cliente e alterar o contrato, em vez de apenas o fato da alteração)

• Um sistema pode precisar atender a requisitos legais ou regulamentares específicos, independentemente da preferência do cliente. Exemplos: criptografia de cartão de crédito, proteção de dados fiscais.

Proibir alterações nas especificações durante o desenvolvimento é ideal para o programador, mas não é realista em um cenário do mundo real. As pessoas sempre querem fazer alterações, mesmo quando a coisa está sendo enviada pela porta. Isso nunca para. E algumas dessas pessoas podem estar assinando seu salário. Quanto mais eles se importam, mais pensam e, portanto, mais frequentemente desejam revisar o design. Você precisa tolerar a alteração do design antes da conclusão, mesmo que isso signifique recomeçar.

O importante é comunicar claramente as consequências das mudanças para que todos tenham expectativas realistas do processo de design.

As mudanças precisam ser discutidas adequadamente, e a pessoa responsável pela coisa precisa ter um entendimento claro do impacto que as mudanças terão na data de entrega. Para conseguir isso, ele precisa conversar com o desenvolvedor. No entanto, como uma discussão contínua sobre mudanças inundará o desenvolvedor e impedirá que qualquer trabalho real aconteça, as alterações deverão ser enfileiradas e discutidas em intervalos planejados e pouco frequentes. É isso que você espera, é claro.

Idealmente, você instrui as pessoas a anotar as mudanças que desejam fazer e solicitá-las à reunião semanal / quinzenal / mensal / qualquer que seja a reunião de coordenação. Durante a reunião, cada solicitação de mudança é discutida, incluindo uma discussão das modificações subjacentes que precisam ser feitas para implementar o recurso solicitado e, portanto, o efeito na data de conclusão. Uma vez estabelecido o "custo" da alteração, eles podem determinar se a incluirão ou não.

O importante que esse processo introduz é a noção de que cada mudança tem um custo associado, e o custo geralmente é maior à medida que o projeto avança, uma vez que mais trabalho precisa ser duplicado. Pessoas que não trabalham em desenvolvimento geralmente não têm idéia de quanto custará uma mudança; a única maneira de dizerem é propor e avaliar sua reação. Criar um processo bem definido de revisão de alterações ajudará você e você.

Observe que os programadores tendem a ser extremamente otimistas quanto à facilidade com que uma mudança é feita ou extremamente pessimistas sobre o quão impossível será fazer isso. Tente descobrir o que você é comparando suas estimativas originais com os resultados e faça os ajustes necessários.

Talvez seja melhor dizer que a especificação não deve mudar sem uma solicitação e processo de alteração válidos. Solicitar uma alteração na especificação tem efeitos no cronograma e no custo, portanto, eles devem ser levados em consideração na aprovação.

Dado que existe um processo de gerenciamento de alterações adequado, não há nada "errado" em alterar as especificações, mas é provável que seja muito caro, portanto seus clientes podem não estar muito felizes. Você pode protegê-los de si mesmos, tentando obter alguns bons requisitos e especificações com antecedência, para que sejam necessárias menos alterações.

A melhor analogia que tenho é compará-la à construção de uma casa. O arquiteto elabora os planos e, em seguida, elabora uma estimativa, o cliente concorda (ou não) com o plano. Se o cliente deseja que um banheiro extra seja instalado, o trabalho para, os planos precisam mudar, uma nova estimativa é feita e o cliente concorda (ou não).

Escrever software não é diferente. uma vez que o acordo tenha sido feito (após o design e a estimativa), se houver alguma alteração necessária, o trabalho precisará parar para poder fazer um novo plano, nova estimativa e, em seguida, obter aprovação (ou não) e o trabalho será retomado.

onde quer que eu tenha dito ou não, o projeto continua sem as novas alterações. É claro que sempre há tempo e materiais para elaborar novos planos e estimativas.