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

Problema : parece que em quase todos os esforços de desenvolvimento em que estou envolvido, independentemente do tempo gasto no planejamento antes de iniciar o desenvolvimento, sempre há uma grande quantidade de mudanças necessárias no meio do caminho ou no final do projeto. Às vezes, essas são grandes mudanças que exigem muito re-desenvolvimento.

Eu não trabalho para clientes que pagam dinheiro, essa é uma equipe de desenvolvimento interna em sites de desenvolvimento interno. Então, não é como se eu pudesse cobrar por isso ou qualquer coisa. E no final do dia, temos que tentar cumprir prazos.

Perguntas : Quais são algumas das melhores maneiras que vocês encontraram para minimizar e impedir que alterações nas especificações surjam no meio do caminho ou após o desenvolvimento?

Há um famoso ditado militar, atribuído a Helmut von Moltke: "Nenhum plano de batalha sobrevive ao contato com o inimigo". Na mesma linha, não acho que seja possível fazer uma especificação que não precise ser alterada - a menos que você possa prever o futuro e ler as mentes das partes interessadas (mesmo assim elas ainda não se decidiram, mesmo que eles afirmam que sim). Em vez disso, sugiro abordá-lo de várias maneiras:

1. Faça uma distinção clara do que pode ser mudado e do que não pode. Comunique-o claramente às partes interessadas, faça-as assinar explicitamente as coisas imutáveis ​​o mais rápido possível.
2. Prepare-se para a mudança com antecedência. Use metodologias de código que permitam alterar as partes alteráveis ​​com mais facilidade, invista em configurabilidade, encapsulamento e protocolos claros que permitiriam que as peças fossem alteradas e substituídas independentemente.
3. Converse com as partes interessadas com frequência, solicite feedback e aprovação. Isso manteria você em sincronia e evitaria que eles alegassem "ah, não é isso que queríamos" quando é tarde demais. Conforme observado em outras respostas, metodologias ágeis e mini-lançamentos frequentes o ajudarão nisso.
4. Coloque na programação o tempo para acomodar as mudanças inevitáveis. Não tenha medo de dizer "precisaremos de mais tempo" mais cedo, se você pensa que sim - se o cronograma que você recebe não for realista, é melhor conhecê-lo (e você está dizendo isso) no início do que em o fim.
5. Se as alterações forem muito extensas e ameaçarem o prazo - recue e diga algo como "essa alteração é possível, mas o prazo será adiado por X tempo, faça sua escolha".
6. Faça um processo formal de solicitação de alterações, priorizando alterações e atribuindo alterações a versões ou liberações. Se você puder dizer às pessoas "Eu não posso fazer isso neste lançamento, mas ficaremos felizes em agendá-lo para o próximo", é muito melhor do que dizer "você está atrasado demais, sua mudança não pode acontecer , adeus "e faria deles seu amigo - eles ficariam felizes em você liberar a tempo, para que você pudesse ficar livre mais cedo para chegar ao próximo lançamento, que terá a mudança deles - e não seu inimigo.

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

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

Ao dividir o projeto em uma série de mini-projetos, você obtém mais controle, pois pode colocar algo na frente do cliente mais cedo, não fica preso a um longo cronograma de desenvolvimento que fica desatualizado quando o cliente muda de idéia (como elas vão).

Quando eles vêem o sistema evoluir, alguns requisitos mudam, alguns se tornam redundantes e outros aumentam em prioridade. No entanto, com um ciclo de vida curto do projeto, você poderá lidar com essas mudanças.

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

Você DEVE encontrar uma maneira de acomodar as alterações à medida que avança! Eles vão acontecer, porque a maioria das partes interessadas, mesmo que digam 'sim, é isso que eu quero', na verdade não tem ideia do que querem até que esteja na frente delas. É por isso que temos tantas pessoas adotando métodos iterativos.

Independentemente de você repetir o produto ou o que for, você DEVE encontrar uma maneira de acomodar essas alterações, porque tentar encontrar maneiras de não ter alterações é apenas pedir para que a gravidade se desligue por alguns minutos para poder voar.

Não tente impedir a mudança, aceite -a. Quanto mais você planejar com antecedência, maior a probabilidade de seu plano mudar. Portanto, planeje menos , não mais. Adote uma metodologia de desenvolvimento ágil, na qual você fornece pequenos pedaços 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. As alterações nas especificações sempre acontecerão em projetos de desenvolvimento de software de qualquer tamanho.

Muitas vezes, é porque os requisitos de negócios mudam, mas também vi isso acontecer porque os clientes (internos ou externos) podem ter dificuldade em visualizar o que é possível sem ver algo para iterar, para que tenham uma visão que muda lentamente à medida que se envolvem com o solução em desenvolvimento.

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

Isso leva você à arena do bingo da palavra-chave: metodologias ágeis, desenvolvimento iterativo e soluções técnicas, como codificação modular / baseada em componentes, integração contínua ... a lista continua.

Não estou dizendo que isso seja uma bala de prata para todos os seus problemas, mas todos surgiram por causa de um desejo de gerenciar a mesma situação que você está descrevendo, pelo menos vale a pena investigar.

Desculpe se isso não está oferecendo soluções concretas, mas eu acredito que uma mudança de mentalidade para aceitar e gerenciar mudanças trará dividendos maiores do que tentar evitá-las.

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

Sugiro pensar em:

• De onde diabos essas mudanças vêm?
• por que você não os conhece antes?
• por que você não está contribuindo para essas mudanças (e potencialmente fazendo ainda mais)?

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

Mas se você deseja evitar perpetuamente ser o desenvolvedor frustrado "surpreendido" pelas mudanças, acho que precisa encontrar o caminho mais próximo da ação de onde as decisões são tomadas. Afinal, tenho certeza de que você tem um monte de idéias de como você pode melhorar o produto. Sente-se à mesa ou aceite para sempre que você terá que lidar com essas "mudanças surpreendentes".

Bem, isso é uma ligação, os clientes sempre querem mais, mas aqui estão alguns pontos que você deve considerar:

Modelos 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 solicite suas opiniões. Se você encontrar algo razoável para mudar, faça isso acontecer no protótipo HTML. Com isso, você resolverá várias 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 desenvolvendo para uma organização comercial, entrar nos negócios deles e pedir que eles esclareçam suas dúvidas.

Liberação modular: libere seu código de forma modular, libere, teste, obtenha feedback e libere novamente.

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

Dentro da sua empresa, há um custo no uso dos recursos de TI, independentemente de alguém o admitir, acompanhar ou ter que fazer um orçamento para isso ou não. A realidade é que sua equipe pode criar tanto código em um determinado período de tempo. Todos os departamentos e projetos estão compartilhando esse orçamento.

Você não pode impedir que alguém queira alterar os requisitos, mas eles não podem escapar das consequências. As alterações podem aumentar significativamente os tempos de desenvolvimento. É um fato que eles precisam lidar ou decidir não fazer a mudança. Uma solicitação de um departamento afeta outro? Pode ser necessário mover completamente o projeto para outros departamentos, pois a solicitação de alteração invadirá o cronograma de outro grupo.

O envolvimento ativo do usuário ao longo do ciclo de desenvolvimento e o uso da maior metodologia possível, realmente nos ajuda com nossos produtos.

As alterações nas especificações são inevitáveis, mas, ao serem transparentes com os usuários e, sobretudo, consultá-las com frequência significa que a maioria das alterações é capturada o mais cedo possível.

Para mim é bem fácil.
Diga a ele, o "Dono do produto" , que solicitou os recursos que está correto, mas ele precisa escolher alguns dos recursos planejados que ele poderia ficar sem nesse prazo.
Pense nisso como uma reunião de meio sprint com o OP, onde você diz a ele que o sprint não queimará até 0.

Ps. Se não for o "PO", eu diria que não fale comigo, vá até o "PO"

Quais são algumas das melhores maneiras que vocês encontraram para minimizar e impedir que mudanças nas especificações surjam no meio do caminho ou após o desenvolvimento?

Não há melhores maneiras. Cabe à gerência limitar as alterações às especificações em determinada fase 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 iterativo e incremental é 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). Portanto, a solução óbvia é eliminar os clientes. (Que bom eles são afinal?)

Como você não pode impedir a mudança, é necessário adotá-la. Acho que a coisa mais importante que você pode fazer é: você precisa receber as solicitações de alteração do cliente o mais cedo possível , porque é menos dispendioso alterar 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é 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 ou dias úteis necessários para implementar essa história).

Se uma alteração tardia for solicitada (para uma história que já foi implementada), você precisará criar uma nova história e estimar o esforço de implementação. Depois, você pode ir ao seu gerente (o proprietário do produto ) e simplesmente explicar que o novo recurso custará esse tempo extra. O gerente de projeto tem a responsabilidade de aceitar o esforço extra e ajustar o cronograma (possivelmente cancelando outras histórias ainda não implementadas).

Mesmo que sua equipe não implemente totalmente o SCRUM ou outro processo de desenvolvimento, você pode pelo menos introduzir o planejamento com base em histórias , estimar o esforço de desenvolvimento para cada história e ajustar o cronograma à medida que novas histórias forem solicitadas.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Passei muitas noites após o trabalho estressado e infeliz, porque outro sujeito não entende nem se importa com o funcionamento dos negócios de software. Não tenho problema em confrontar alguém de cima, mas não tenho o apoio de meus colegas nerds. Ter filhos é uma merda, não é? Eu provavelmente vou sair em breve.

Francamente, eu gostaria que os programadores em geral tivessem mais bolas. Vamos olhar para isso:

"" "Não trabalho para clientes que pagam dinheiro, é uma equipe interna de desenvolvimento em sites de desenvolvimento interno. Portanto, não é possível cobrar por isso ou qualquer coisa. E no final do dia, nós temos que tentar cumprir prazos. "" "

Se você estava lidando com um cliente pagador de dólares e se cobertas por um contrato (http://vimeo.com/22053820?utm_source=swissmiss), as alterações nas especificações custariam a esse cliente mais tempo e mais dinheiro ( ou potencialmente igual ou menos 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 cumprir prazos causa um estresse desnecessário a você e seus colegas de trabalho; você não pode passar um fim de semana de qualidade com amigos / família. É realmente desnecessário, porque quem está jogando trabalho para você provavelmente nem o conhece, o que é triste.

Minha solução proposta: coletivamente, tem a coragem de enfrentá-los e explicar que não há almoço grátis e tudo custa, que um mecânico de automóveis levaria mais tempo e cobraria mais se as especificações fossem alteradas no meio do trabalho, que uma agência contratadora 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 estiverem dispostos a trabalhar com você de uma maneira razoável, você, como um grupo, se levantará e sairá, e eles terão que contratar desenvolvedores que possam pegar o projeto onde ele foi deixado e entregar dentro do prazo.

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 alguma coisa. Gerentes incompetentes são muito abundantes em empresas de software. Muitas pessoas querem algo por nada, no Craigslist ou dentro de uma empresa real. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Os programadores precisam ter mais bolas.

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