Como impedir que as especificações de desenvolvimento mudem no desenvolvimento do meio?

Há um famoso ditado militar, atribuído a Helmut von Moltke: "Nenhum plano de batalha sobrevive ao contato com o inimigo". Na mesma linha, eu não acho que é possível fazer uma especificação que não tenha que ser mudada - a não ser que você possa prever o futuro e ler as mentes das partes interessadas (mesmo assim elas podem não ter ainda decidido, mesmo se eles afirmam que fizeram). Sugiro, em vez disso, abordá-lo de várias maneiras:

1. Faça uma distinção clara sobre o que pode ser mudado e o que não pode. Comunique-o claramente às partes interessadas, faça-as explicitamente assinar coisas imutáveis o mais rápido possível.
2. Prepare a mudança antecipadamente. Use metodologias de código que permitem alterar as partes mutáveis mais facilmente, investir em configurabilidade, encapsulamento e limpar protocolos que permitiriam que as peças fossem alteradas e substituídas de forma independente.
3. Fale frequentemente com as partes interessadas, solicite feedback e aprovação. Isso os manteria em sincronia e os evitaria alegando "oh, não é isso que queríamos" quando é tarde demais. Como observado em outras respostas, as metodologias ágeis e os mini-lançamentos frequentes ajudariam você com isso.
4. Coloque na agenda o tempo para acomodar as mudanças inevitáveis. Não tenha medo de dizer "vamos precisar de mais tempo" cedo se você acha que faria - se o cronograma que você está dando é irrealista, é melhor saber (e você está no registro dizendo isso) no início do que em o fim.
5. Se as alterações forem muito extensas e ameaçarem o prazo - retroceda e diga algo como "essa mudança é possível, mas vai empurrar o prazo por X vezes, faça sua escolha".
6. Faça um processo formal de solicitação de alterações, priorizando mudanças e atribuindo alterações a versões ou releases. Se você pudesse dizer às pessoas "Eu não posso fazer isso neste lançamento, mas ficarei feliz em colocá-lo na agenda para o próximo", é muito melhor do que dizer-lhes "você está muito atrasado, sua mudança não pode entrar , adeus "e faria deles seu amigo - eles ficariam felizes por você liberar a tempo para que você pudesse se libertar mais cedo para chegar ao próximo lançamento que terá a mudança deles - e não seu inimigo.

Entregue algo (hesito em usar a palavra qualquer coisa) cedo e entregue com frequência. Ou seja, use algum tipo de metodologia de desenvolvimento iterativo.

Esta é a base do desenvolvimento Agile, mas pode ser usada com (quase) qualquer metodologia.

Quando eles vêem o sistema evoluir, alguns requisitos mudarão, alguns se tornarão redundantes e outros aumentarão em prioridade. No entanto, ao ter um ciclo de vida de projeto curto, você será capaz de lidar com essas mudanças.

A teoria de que é possível especificar completamente um projeto de software de qualquer tamanho significativo é uma fantasia completa. Descobriu-se que essa teoria não funciona em organizações de grande a pequeno para praticamente toda a história do desenvolvimento de software.

Você DEVE encontrar alguma maneira de acomodar as mudanças à medida que avança! Eles vão acontecer, porque a maioria das partes interessadas, mesmo que digam "sim, é o que eu quero", na verdade não têm idéia do que querem até estarem na frente delas. É por isso que temos tantas pessoas adotando métodos iterativos.

Se você iterar o produto ou o que quer que seja, você DEVE encontrar alguma maneira de acomodar essas mudanças, porque tentar encontrar maneiras de não ter mudanças é apenas pedir que a gravidade se desligue por alguns minutos para que você possa voar.

Não tente impedir a mudança, abraçar . Quanto mais você planejar com antecedência, maior a probabilidade de o seu plano mudar. Então, planeje menos , não mais. Adote uma metodologia de desenvolvimento ágil em que você forneça pequenos trechos de código de trabalho com frequência, dando ao cliente a chance de alterar as especificações a cada duas semanas.

Você está fazendo a pergunta errada. Mudanças de especificação sempre acontecem em projetos de desenvolvimento de software de qualquer tamanho.

Geralmente, é porque os requisitos de negócios mudam, mas eu também vi isso acontecer porque os clientes (internos ou externos) podem achar difícil visualizar o que é possível sem ver algo do qual interagir, então eles têm uma visão que muda lentamente à medida que eles envolver-se com a solução em desenvolvimento.

A pergunta que você deve fazer não é "como posso bloquear a especificação", é "como eu posso estruturar meu código e processos para responder a um ambiente em mudança sem jogar fora tudo o que já escrevi?"

Isso, então, leva você à arena do bingo do buzzword: metodologias ágeis, desenvolvimento iterativo e soluções técnicas, como codificação baseada em componentes / módulos, integração contínua ... a lista continua.

Eu não estou dizendo que estes são uma bala de prata para todos os seus problemas, mas todos eles surgiram por causa do desejo de gerenciar a mesma situação que você está descrevendo, então, no mínimo, eles merecem alguma investigação.

Desculpe se isso não está oferecendo soluções concretas, mas tenho a tendência de pensar que uma mudança de mentalidade para aceitar e administrar a mudança pagará dividendos maiores do que tentar evitá-la.

Uma mudança é apenas uma surpresa ... se é uma surpresa!

Sugiro pensar em:

• de onde vêm essas mudanças?
• por que você não está ciente deles antes?
• por que você não está contribuindo para essas mudanças (e potencialmente fazendo ainda mais delas)?

A mudança é a natureza do que fazemos. Desde quando você codificou um algoritmo exatamente como previsto no dia 1?

Mas se você quiser evitar perpetuamente ser o desenvolvedor frustrado "surpreso" pelas mudanças, eu acho que você precisa encontrá-lo mais perto da ação de onde as decisões são tomadas. Afinal, tenho certeza de que você tem um monte de ideias sobre como você pode melhorar o produto. Sente-se à mesa ou aceite para sempre que você terá que lidar com essas "mudanças surpresa".

Bem, apesar de ser uma chamada, os clientes sempre querem mais, mas aqui estão alguns pontos que você deve considerar:

Mock-ups em HTML: Sempre crie modelos em HTML para definir a parte da interface do usuário de um aplicativo, mostre a eles como será e peça a opinião deles. Se você encontrar algo razoável para mudar, faça isso no protótipo HTML. Usando isso você vai resolver muitas coisas, como problemas de interface do usuário, fluxo básico e alguns complementos (como classificação, paginação, número de registros a serem exibidos etc.)

Participação ativa do outro lado: Isso é muito importante se você estiver se desenvolvendo para uma organização comercial, entrar em contato com eles para esclarecer suas dúvidas e, sem falhar, perguntar a eles quais mudanças eles querem em seu fluxo (se necessário).

Versão modular: Libere seu código de maneira modular, libere, teste, receba feedback e libere novamente.

É por isso que é quase impossível planejar com muita antecedência, mas não uma desculpa para não planejar nada. Não se apaixone muito por seus planos e você não terá que se preocupar com eles quebrando seu coração.

Dentro de sua empresa, há um custo para usar os recursos de TI, se alguém o admite, rastreia ou tem orçamento para isso ou não. A realidade é que sua equipe só pode criar muito código em um determinado período de tempo. Todos os departamentos e projetos estão compartilhando este orçamento.

Você não pode impedir que alguém deseje alterar os requisitos, mas não pode evitar as consequências. As alterações podem aumentar significativamente os tempos de desenvolvimento. Esse é um fato com o qual eles precisam lidar ou decidir não fazer a mudança. Um pedido de um departamento afeta outro? Você pode ter que mover completamente seu projeto para outros departamentos porque a solicitação de mudança invadirá o cronograma de outro grupo.

O envolvimento ativo do usuário em todo o ciclo de desenvolvimento e o uso da maior quantidade possível de metodologia Ágil realmente nos ajuda com nossos produtos.

Mudanças de especificação são inevitáveis, mas por ser transparente com os usuários e, acima de tudo, consultá-las freqüentemente significa que a maioria das mudanças é capturada o mais cedo possível.

Para mim é bem fácil.
Diga a um, o "Product owner" , que ordenou os recursos que isso é bom, mas ele tem que escolher um par de recursos planejados que ele poderia ser sem esse prazo.
Pense nisso como uma reunião de meia-sprint com o PO, onde você diz a ele que o sprint não vai queimar até 0.

Se é não o "PO" eu diria que não fale comigo através do "PO"

What are some of the best ways you guys have found to minimize and prevent spec changes from cropping up midway or after development?

Não há melhores maneiras. Cabe ao gerenciamento limitar as alterações à especificação na fase certa do desenvolvimento.

No entanto, você deve projetar seu software de forma a esperar as alterações. Então o impacto das mudanças seria muito menor. Desenvolvimento incremental e iterativo é um bom começo.

Descobri que, direta ou indiretamente, os clientes são a causa da maioria das alterações (e também dos bugs mais críticos, BTW). Então a solução óbvia é eliminar os clientes. (De que adiantam eles, afinal?)

Desde que você não pode impedir a mudança, você precisa abraçá-lo. Eu acho que a coisa mais importante que você pode fazer é: você precisa tentar obter as solicitações de mudança do cliente o mais cedo possível , porque é menos custoso mudar as coisas quando há pouco código. Portanto, você precisa apresentar seu projeto o mais cedo possível ao cliente usando protótipos (talvez até mesmo um protótipo de papel), usar métodos ágeis e assim por diante.

Você pode considerar introduzir alguma disciplina no processo de desenvolvimento usando uma metodologia como SCRUM. No SCRUM, uma equipe faz um plano inicial dividindo a implementação de recursos em histórias e atribuindo a cada história uma estimativa de esforço (número de horas de trabalho ou dias necessários para implementar essa matéria).

Se uma alteração atrasada for solicitada (para uma história já implementada) você precisa criar uma nova história e estimar o esforço de implementação para ela. Então você pode ir ao seu gerente (o product owner ) e simplesmente explicar que o novo recurso vai custar esse tempo extra. O gerente de projeto então tem a responsabilidade de aceitar o esforço extra e ajustar a programação (possivelmente cancelando outras histórias ainda não implementadas).

Mesmo que sua equipe não implemente o SCRUM ou outro desenvolvimento processo, você poderia pelo menos introduzir o planejamento baseado em histórias , estimar o esforço de desenvolvimento de cada história e ajustar o cronograma como novas histórias são solicitadas.

link

Eu passei muitas noites depois do trabalho estressadas e infelizes porque outro cara não entende ou se importa como o negócio de software funciona. Eu não tenho nenhum problema em confrontar alguém mais alto, mas eu não tenho o apoio de meus colegas nerds. Ter filhos é uma puta, né? Eu provavelmente vou sair em breve.

Francamente, eu gostaria que os programadores em geral tivessem mais bolas. Vamos ver isto:

"" "Eu não trabalho para clientes que pagam dinheiro, esta é uma equipe interna de desenvolvimento em sites internos de desenvolvimento. Então, não é como se eu pudesse cobrar por isso ou qualquer coisa. E no final de o dia, nós temos que tentar atingir os prazos. "" "

Se você estivesse lidando com um cliente de $ -paying e se cobrisse sua conta com um contrato (http://vimeo.com/22053820?utm_source=swissmiss), as alterações na especificação custariam mais tempo a esse cliente E mais dinheiro (ou potencialmente igual ou menor tempo, mas exponencialmente mais dinheiro). Sua empresa está tentando mudar as especificações sem incorrer no custo de mais tempo e mais dinheiro.

Nesse meio tempo, tentar atingir prazos faz com que você e seus colegas de trabalho se preocupem; você não pode passar um fim de semana de qualidade com amigos / familiares. É realmente desnecessário, porque quem está jogando o trabalho em você provavelmente nem sabe disso, o que é triste.

Minha solução proposta: coletivamente, ter coragem de confrontá-los e explicar que não há almoço grátis e tudo custou, que um mecânico demoraria mais e cobraria mais se as especificações fossem mudadas no meio do trabalho, que uma agência contratante levaria mais tempo e cobrar mais se as especificações foram alteradas no meio do trabalho, e há uma boa razão para isso. Se eles não estão dispostos a trabalhar com você de uma maneira razoável, então você, como um grupo, se levantará e partirá, e eles terão que contratar desenvolvedores que possam pegar o projeto onde ele foi deixado e entregar na hora certa.

Depois, há também uma promessa de desenvolvimento ágil, que não implica prazos rígidos.

Ainda estou para ver os programadores entrarem em greve, mas isso teria sido algo. Gerentes incompetentes são muito abundantes em empresas de software. Muitas pessoas querem obter algo por nada, no Craigslist ou em uma empresa real. link

Os programadores precisam ter mais bolas.

Uma abordagem que descobri que funciona bem (não com todos os gerentes, obviamente) é "Eu acho que posso fazer isso, sim. Depende - quanto tempo extra você está atribuindo a este projeto? É um grande problema." mudança que você está solicitando. "