Comment empêcher les spécifications de développement de changer en cours de développement?

Problème : Il semble que dans presque tous les efforts de développement auxquels je participe, quel que soit le temps consacré à la planification avant de commencer le développement, de nombreux changements sont toujours nécessaires à mi-parcours ou à la fin du projet. Ce sont parfois de grands changements qui nécessitent beaucoup de re-développement.

Je ne travaille pas pour des clients qui paient de l'argent, il s'agit d'une équipe de développement interne sur des sites Web de développement internes. Donc, ce n'est pas comme si je pouvais facturer cela ou quoi que ce soit. Et en fin de compte, nous devons essayer de respecter les délais.

Questions : Quels sont les meilleurs moyens que vous avez trouvés pour minimiser et empêcher les modifications de spécifications d'apparaître à mi-parcours ou après le développement?

Un dicton militaire célèbre, attribué à Helmut von Moltke: "Aucun plan de bataille ne survit au contact de l'ennemi". Dans le même ordre d'idées, je ne pense pas qu'il soit possible de faire une spécification qui ne devra pas être modifiée - à moins que vous ne puissiez prédire l'avenir et lire dans l'esprit des parties prenantes (même si elles ne l'ont peut-être pas encore fait, même si ils prétendent qu'ils ont fait). Je suggérerais plutôt de l'aborder de plusieurs manières:

1. Faites une distinction claire entre ce qui peut être changé et ce qui ne peut pas. Communiquez-le clairement aux parties prenantes, faites-les signer explicitement dès que possible.
2. Préparez le changement à l'avance. Utilisez des méthodologies de code qui permettent de changer plus facilement les pièces interchangeables, investissez dans la configurabilité, l’encapsulation et des protocoles clairs permettant de modifier et de remplacer les pièces en toute indépendance.
3. Parlez fréquemment aux parties prenantes, sollicitez des commentaires et l'approbation. Cela vous permettrait à la fois de rester synchronisé et d'éviter de dire "oh, ce n'est pas ce que nous voulions" quand il est trop tard. Comme indiqué dans d'autres réponses, des méthodologies agiles et des mini-versions fréquentes vous aideraient dans cette tâche.
4. Mettez dans le calendrier le temps nécessaire pour faire face aux changements inévitables. N'ayez pas peur de dire "nous aurons besoin de plus de temps" si vous pensez le faire. Si l'horaire qui vous est donné est irréaliste, il est préférable de le savoir (et de l'avoir dit au compte rendu) au début plutôt qu'à la fin.
5. Si les changements sont trop importants et menacent le délai - repoussez et dites quelque chose du type "ce changement est possible, mais repoussera le délai de X fois, faites votre choix".
6. Effectuez un processus formel de demande de modifications, d'établissement de priorités et d'attribution de modifications aux versions ou aux versions. Si vous pouviez dire aux gens "je ne peux pas le faire dans cette version, mais serais heureux de le mettre dans les temps pour la prochaine", c'est bien mieux que de les dire "vous êtes trop tard, votre changement ne peut pas entrer , au revoir "et en feraient votre ami - ils seraient heureux que vous libériez à temps afin que vous puissiez être libre plus tôt pour arriver à la prochaine version qui changera - et non votre ennemi.

Livrer quelque chose (j'hésite à utiliser le mot n'importe quoi) tôt et livre souvent. C’est-à-dire, utilisez une sorte de méthodologie de développement itératif.

Ceci est la base du développement Agile, mais peut être utilisé avec (presque) n'importe quelle méthodologie.

En divisant le projet en une série de mini-projets, vous obtenez plus de contrôle car vous pouvez mettre quelque chose devant le client plus tôt, vous n'êtes pas enfermé dans un long calendrier de développement qui devient obsolète lorsque le client change d'avis (comme elles vont).

Lorsqu'ils verront le système évoluer, certaines exigences changeront, certaines deviendront redondantes et d'autres deviendront de plus en plus prioritaires. Cependant, en ayant un cycle de vie court, vous pourrez faire face à ces changements.

La théorie selon laquelle il est possible de spécifier complètement un projet logiciel de toute taille significative est un fantasme complet. Il a été constaté que cette théorie ne fonctionnait pas dans les organisations de toutes tailles, à peu près toute l’histoire du développement logiciel.

Vous DEVEZ trouver un moyen d’adapter les changements au fur et à mesure! Ils vont arriver, parce que la plupart des parties prenantes, même si elles répondent "oui, c'est ce que je veux", n'ont en réalité aucune idée de ce qu'elles veulent jusqu'à ce que ce soit devant elles. C'est pourquoi beaucoup de gens adoptent des méthodes itératives.

Que vous fassiez une itération du produit ou autre chose, vous DEVEZ trouver un moyen d’adapter ces changements, car essayer de trouver des moyens de ne pas avoir de changements revient à demander à la gravité de s’éteindre elle-même pendant quelques minutes pour pouvoir voler.

N'essayez pas d'empêcher le changement, adoptez- le. Plus vous planifiez à l'avance, plus votre plan changera probablement. Alors, planifiez moins , pas plus. Adoptez une méthodologie de développement agile dans le cadre de laquelle vous livrez fréquemment de petits morceaux de code fonctionnel, ce qui permet au client de modifier les spécifications toutes les deux semaines.

Vous posez la mauvaise question. Les modifications de spécifications se produiront toujours dans les projets de développement logiciel de toute taille.

C’est souvent parce que les besoins de l’entreprise changent, mais j’en ai déjà vu d’autres parce que les clients (internes ou externes) peuvent avoir du mal à visualiser ce qui est possible sans voir quelque chose d’itéré, de sorte qu’ils ont une vision qui change lentement au fur et à mesure de leur engagement solution de développement.

La question que vous devriez poser n'est pas "comment puis-je verrouiller les spécifications", mais "comment structurer mon code et mes processus pour répondre à un environnement en mutation sans jeter tout ce que j'ai déjà écrit?"

Cela vous mène ensuite dans l'arène du bingo à la mode: méthodologies agiles, développement itératif et solutions techniques telles que codage à base de composants / modulaire, intégration continue ... la liste est longue.

Je ne dis pas que ce sont des solutions miracles à tous vos problèmes, mais ils sont tous dus à un désir de gérer la situation même que vous décrivez afin qu'ils méritent au moins une enquête.

Désolé si cela n’offre pas de solutions concrètes, mais j’ai tendance à penser qu’un changement d’esprit en faveur de l’acceptation et de la gestion du changement rapportera des fruits plus importants que d’essayer de l’éviter.

Un changement n'est qu'une surprise ... si c'est une surprise!

Je suggérerais de penser à:

• D'où viennent ces changements?
• pourquoi tu ne les connais pas plus tôt?
• pourquoi ne contribuez-vous pas à ces changements (et en faites-vous potentiellement davantage)?

Le changement est la nature de ce que nous faisons. Depuis quand avez-vous codé un algorithme exactement comme prévu au jour 1?

Mais si vous voulez éviter d'être continuellement le développeur frustré "surpris" par les changements, je pense que vous devez vous trouver de manière plus proche de l'action consistant à prendre les décisions. Après tout, je suis sûr que vous avez une foule d’idées sur la manière d’améliorer le produit. Obtenez une place à la table ou acceptez pour toujours que vous devrez simplement faire face à ces "changements inattendus".

Les clients en veulent toujours plus, mais voici quelques points à considérer:

Maquettes HTML: créez toujours des maquettes HTML pour définir la partie UI d'une application, montrez-leur à quoi cela va ressembler et demandez-leur leur avis. Si vous trouvez quelque chose de raisonnable à changer, faites-le dans le prototype HTML. En utilisant cela, vous pourrez régler de nombreux problèmes tels que les problèmes d'interface utilisateur, le flux de base et certains ajouts (comme le tri, la pagination, le nombre d'enregistrements à afficher, etc.).

Participation active de l’autre extrémité: c’est très important si vous développez pour une entreprise, lancez-vous dans leur entreprise, demandez-leur de clarifier vos doutes et demandez-leur sans faute quels changements ils souhaitent dans leur flux (si nécessaire).

Libération modulaire: publiez votre code de manière modulaire, publiez, testez, prenez en compte les commentaires et relâchez-les.

C'est pourquoi il est presque impossible de planifier à l'avance, mais ce n'est pas une excuse pour ne pas planifier du tout. Ne tombez pas trop amoureux de vos projets et vous ne craindrez pas qu'ils vous brisent le cœur.

Au sein de votre entreprise, l’utilisation des ressources informatiques a un coût, que quelqu'un l’admette, la surveille, qu’elle ait un budget ou non. En réalité, votre équipe ne peut créer autant de code que dans un certain laps de temps. Tous les départements et projets partagent ce budget.

Vous ne pouvez empêcher personne de vouloir modifier les exigences, mais elles ne peuvent échapper aux conséquences. Les changements peuvent augmenter considérablement les temps de développement. C'est un fait auquel ils doivent faire face ou décident de ne pas effectuer le changement. Une demande émanant d'un ministère en affecte-t-elle un autre? Vous devrez peut-être déplacer complètement leur projet derrière un autre service, car la demande de changement empiétera sur le calendrier de l'autre groupe.

L'implication active des utilisateurs tout au long du cycle de développement et l'utilisation de la méthodologie Agile autant que possible nous aident réellement avec nos produits.

Les changements de spécifications sont inévitables, mais en étant transparents avec les utilisateurs et surtout, en les consultant fréquemment, la plupart des changements sont capturés le plus tôt possible.

Pour moi c'est assez facile.
Dites à celui, le "propriétaire du produit" , qui a commandé les fonctionnalités que cela ne pose pas de problème, mais il doit choisir une ou plusieurs fonctionnalités planifiées sans lesquelles il pourrait être privé avant cette date limite.
Pensez-y comme à une réunion de demi-sprint avec le PO où vous lui dites que le sprint ne brûlera pas à 0.

Ps. Si ce n'est pas le "PO", je dirais: ne me parlez pas, passez par le "PO"

Quels sont les meilleurs moyens que vous avez trouvés pour minimiser et empêcher les modifications de spécifications d'apparaître à mi-parcours ou après le développement?

Il n'y a pas de meilleurs moyens. Il appartient à la direction de limiter les modifications de spécifications dans certaines phases du développement.

Cependant, vous devez concevoir votre logiciel de manière à pouvoir anticiper les modifications. Alors l'impact des changements serait beaucoup moins. Le développement itératif et progressif est un bon début.

J'ai constaté que les clients sont directement ou indirectement à l'origine de la plupart des modifications (et également des bogues les plus critiques, BTW). La solution évidente consiste donc à éliminer les clients. (À quoi servent-ils quand même?)

Puisque vous ne pouvez pas empêcher le changement, vous devez l'accepter. Je pense que la chose la plus importante que vous puissiez faire est la suivante: vous devez essayer d’ obtenir les demandes de changement du client le plus tôt possible , car il est moins coûteux de changer les choses quand il n’ya que peu de code. Vous devez donc présenter votre conception le plus tôt possible au client en utilisant des prototypes (peut-être même un prototype en papier), des méthodes agiles, etc.

Vous pourriez envisager d'introduire une certaine discipline dans le processus de développement en utilisant une méthodologie telle que SCRUM. Dans SCRUM, une équipe établit un plan initial en scindant la mise en œuvre des fonctionnalités en récits et en attribuant à chaque récit une estimation de l'effort (nombre d'heures de travail ou de jours nécessaires pour mettre en œuvre cette récit).

Si un changement tardif est demandé (pour une histoire déjà mise en œuvre), vous devez créer une nouvelle histoire et en estimer les efforts de mise en œuvre. Ensuite, vous pouvez vous adresser à votre responsable (le responsable produit ) et lui expliquer simplement que la nouvelle fonctionnalité coûtera plus de temps. Le chef de projet a alors la responsabilité d'accepter l'effort supplémentaire et d'ajuster le calendrier (éventuellement, d'annuler d'autres histoires non encore implémentées).

Même si votre équipe ne mettra pas complètement en œuvre SCRUM ou un autre processus de développement, vous pouvez au moins introduire la planification basée sur les récits , estimer les efforts de développement de chaque récit et ajuster le calendrier à la demande de nouveaux récits.

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

J'ai passé trop de soirées après le travail stressées et malheureuses parce qu'un autre type ne comprend pas ou ne s'intéresse pas au fonctionnement du logiciel. Je n'ai aucun problème à affronter quelqu'un de plus haut placé, mais je n'ai pas l'appui de mes camarades nerds. Avoir des enfants est une chienne, hein? Je vais probablement quitter bientôt.

Franchement, j'aimerais que les programmeurs en général aient plus de couilles. Regardons ceci:

"" "Je ne travaille pas pour des clients qui paient de l'argent, il s'agit d'une équipe de développement interne sur des sites Web de développement internes. Donc, ce n'est pas comme si je pouvais faire payer pour cela ou quoi que ce soit. Et à la fin de la journée, nous devons essayer de respecter les délais. ""

Si vous aviez affaire à un client payant et que vous couvriez votre cul en ayant un contrat (http://vimeo.com/22053820?utm_source=swissmiss), des modifications de spécifications coûteraient plus de temps ET plus d’argent à ce client ( ou potentiellement le même temps ou moins mais de façon exponentielle plus d’argent). Votre entreprise essaie de modifier les spécifications sans perdre plus de temps et d'argent.

En attendant, essayer de respecter les délais vous cause, à vous et à vos collègues, un stress INUDIQUE. vous ne pouvez pas passer un week-end de qualité avec des amis ou en famille. C'est vraiment inutile, car quiconque vous lance un travail ne le sait probablement même pas, ce qui est triste.

Ma solution proposée: avoir collectivement les moyens de les confronter et d'expliquer qu'il n'y a pas de repas gratuit et que tout a un coût, qu'un mécanicien prendrait plus de temps et facturait davantage si les spécifications étaient modifiées à mi-travail, qu'un organisme contractant prendrait plus de temps. et facturer plus si les spécifications ont été modifiées à mi-travail, et il y a une bonne raison pour cela. S'ils ne sont pas disposés à travailler avec vous de manière raisonnable, votre groupe se lèvera et partira, et ils devront engager des développeurs capables de prendre en charge le projet là où il a été laissé et de livrer à temps.

Il y a aussi une promesse de développement agile, qui n'implique aucune échéance stricte.

Je n'ai pas encore vu les programmeurs se mettre en grève, mais cela aurait été quelque chose. Les gestionnaires incompétents sont trop nombreux dans les sociétés de logiciels. Beaucoup trop de gens veulent obtenir quelque chose pour rien, sur Craigslist ou au sein d'une entreprise réelle. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Les programmeurs doivent avoir plus de balles.

Une approche que j’ai trouvée qui fonctionne assez bien (pas avec tous les gestionnaires évidemment) est "je pense que je peux le faire, oui. Cela dépend - combien de temps supplémentaire attribuez-vous à ce projet? C’est un changement assez important que vous êtes demande. "