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


61

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?


9
Établissez un jalon pour le gel des fonctionnalités dans le développement et organisez / négociez les opérations de manière à ce que toutes les demandes de fonctionnalités soumises après ce jalon soient transmises à la prochaine version et non à la version actuelle. Point clé est ici bien sûr de prévoir plus d'une version de l' avant et de partager cette compréhension avec les clients
moucheron

4
@gnat Vous supposez que le PO fonctionne dans une organisation où la mise en place d'un jalon Freeze Feature serait acceptable pour les parties prenantes. Sur la base de mon expérience personnelle au sein d’équipes de développement internes, si je proposais une telle chose, les parties prenantes me regarderaient et diraient: «Qui diable pensez-vous que vous me dites quand je peux et ne peux pas changer? mes demandes de fonctionnalités sur un caprice? Que pensez-vous que je vous paye? Connaissez votre place. "
maple_shaft

29
Avez-vous essayé de sauvegarder la spécification dans un fichier en lecture seule?
Orlp

14
Bien sûr, vous les facturez: chaque modification de la spécification retarde la publication. Par conséquent, votre réponse à une demande de modification doit consister en une estimation de la date de la nouvelle version si la modification est ajoutée à la spécification. Celui qui demande le changement est responsable du retard et doit l'expliquer exactement de la même manière que les dépenses.
Simon Richter

7
N'est-ce pas la raison pour laquelle Agile existe? Vous ne pouvez pas geler la spécification afin que votre processus gère une spécification changeante.
Craig

Réponses:


89

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.

3
Vous pouvez également les «geler» par phases et insérer les modifications dans la «version suivante» .
Grant Thomas

3
Formaliser le processus de changement et définir clairement le périmètre est un conseil judicieux - si vous effectuez un travail contractuel périmètre / prix fixe. Dans d’autres contextes, cette approche s’impose car elle donne la priorité au calendrier et aux prix par rapport à la portée et à la qualité. Peut-être que c'est ce dont vous avez besoin dans une situation donnée. Mais là encore, peut-être que ce n'est pas ...
retardé le

3
+1 pour le numéro 6. J'ai eu une excellente expérience de la mise en œuvre de cette exigence par le Premier ministre.
Joshua Drake

3
Les cycles courts sont la clé. Les gens sont beaucoup moins inquiets à l'idée que quelque chose soit poussé dans le prochain sprint de deux semaines que lorsque la "prochaine version" aura lieu dans six mois.
Adam Jaskiewicz

1
"investir dans la configurabilité, l'encapsulation" est un conseil extrêmement dangereux. Cela peut trop facilement conduire à un effet de plate-forme interne et à des couches vides d'abstraction, qui rendent en réalité beaucoup plus difficile la modification d'un système. Le système le plus facilement modifiable est celui qui est le plus simple.
Michael Borgwardt

40

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.


22

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.


2
La NASA le fait avec certains de ses logiciels, ou au moins suffisamment bons pour envoyer des navettes dans l'espace. La chose est qu'ils suivent réellement le modèle de cascade. La spécification est réellement gelée. Au moins c'est ce que je comprends de l'extérieur de l'organisation.
Joshua Drake

5
J'ai travaillé sur plusieurs projets au cours desquels nous avons pu définir complètement des systèmes assez importants (accessoires de commutation téléphonique). La clé dans tous ces cas est que nous ciblions le matériel déjà développé et évoluions vers des spécifications publiées (ITU), de sorte qu'aucun des deux ne pouvait changer. Donc, votre argument ne tient pas pour tous les projets - seulement 99% d'entre eux! ;)
TMN le

@TMN: Je ne serais pas d'accord avec 99% non plus. Je pense que le développement semblable à une cascade a beaucoup, beaucoup plus de succès que les agilistes ne le reconnaissent. Sinon, il ne serait plus utilisé. La plupart des projets sur lesquels j'ai travaillé ressemblent à des cascades. La clé consiste à établir une base de référence, puis tous les changements qui surviennent sont estimés en temps et en argent supplémentaires. Le client décide ensuite d'inclure ou non le changement, et l'échéancier et les dollars glissent en conséquence.
Dunk

1
@Dunk: Je sais qu'une grande partie de notre succès réside dans notre adhésion à une méthodologie développée par les Bell Labs. C'était une véritable ingénierie, avec une traçabilité complète des exigences aux spécifications en passant par les conceptions, les plans de test, le codage permettant de tester les résultats en fonction des livrables. Lorsqu'un test échouait, vous pouviez voir exactement quelles exigences n'étaient pas satisfaites et vous saviez exactement où chercher le code défaillant (ou la conception défaillante). Il faut beaucoup de discipline et de surveillance pour que la cascade fonctionne, mais vous avez raison, cela peut bien fonctionner.
TMN

1
@TMN Je me demande alors quelle est la clé du succès. L'utilisation du modèle en cascade ou votre approche disciplinée? Je pense que le dernier est le plus important des deux.
Ross Goddard

19

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.


Je ne sais pas pourquoi cela ne m'est pas venu à l'esprit plus tôt, mais l'idée que le fait d'avoir un code permet de changer plus facilement de changement ne peut pas être correcte. Est-il plus facile et plus rapide de modifier certains diagrammes ou de modifier le code? Surtout quand le changement est grand. Je conviens que vous n'essayez pas d'empêcher le changement, vous devez simplement souligner les impacts et les appliquer en conséquence à l'annexe. Agile embrasse ne change pas plus que les méthodes de type cascade. Je pense même que le changement est pire que la cascade, car il peut être beaucoup plus coûteux d’apporter des modifications (en fonction du moment où elles surviennent).
Dunk

6
@Dunk Vous avez raison de dire qu'il est meilleur marché de changer un diagramme puis un code, mais comment découvrir que le changement doit avoir lieu? Souvent, cela ne se produira que si vous avez donné à l'utilisateur quelque chose à utiliser et qu'il se rend compte qu'il a communiqué la mauvaise idée, que ce n'est pas ce qu'il voulait ou qu'il a également souhaité cela. L'astuce consiste à comprendre comment découvrir ces changements le plus rapidement possible.
Ross Goddard

@ Ross: C'est l'une des raisons pour lesquelles les prototypes sont utilisés. Vous simulez une sorte de système fonctionnel et obtenez des retours. C'est un mythe qu'en cas de chute d'eau, le client ne sait pas ce qu'il obtient avant de l'avoir fait. J'ai participé à des projets suffisamment importants pour que la ou les personnes de l'interface utilisateur passent les premiers mois à se moquer d'un prototype représentatif afin de garantir que le client obtienne ce qu'il veut. On pourrait affirmer que l’utilisation du système actuel est préférable, mais si cela prend beaucoup plus de temps, car le code doit être fréquemment redéfini, ce n’est pas un bon compromis.
Dunk

12

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.


Oui. Pour reformuler la question initiale: "Comment pouvons-nous garantir que nous livrons ce que le client voulait au début du projet, plutôt que ce qu'il souhaitait à la fin?"
Steve Bennett

5

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".


+1 "Le changement est la nature de ce que nous faisons" - j'aime le changement. Le changement peut être une bonne chose. Cela me donne une chance de voir si mes compétences en conception étaient suffisantes pour priser ou non. Si le changement entraîne de nombreuses retouches, j’ai fait une mauvaise conception. Cela permet également de rendre la conception plus générique. Cela donne une excuse pour régler ce que vous avez fait rapidement afin de respecter le calendrier. Cela me permet de revenir en arrière et de réparer les déchets des autres peuples. Il vous suffit de suivre les demandes de changement et de les incorporer dans le calendrier afin que vous ayez des preuves lorsque vous livrez au-delà du calendrier initial.
Dunk

4

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.


4

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.


4

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.


3

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"


1

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.


1

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?)


:) Si les clients veulent une personnalisation délirante, ils devront payer avec temps et argent. Si les vendeurs doivent absolument promettre de proposer des fonctionnalités qui n'existent pas encore la plupart du temps, ils ont un problème plus important: ils ont de nombreux concurrents et ne sont pas au top de leur jeu, par exemple: Fournisseur de base de données SyBase. En tant qu'entreprise, cela deviendra inutile ou il faudra un PDG et des députés révolutionnaires.
Job le

1

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.


1

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.


0

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.


0

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. "

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.