Je veux expliquer pourquoi la spécification ne doit pas être modifiée pendant la période de développement

Je veux expliquer pourquoi la spécification ne doit pas être modifiée pendant la période de développement pour le nouvel employé du service de planification.

Une spécification change presque toujours au cours du développement pour tout projet, sauf le plus simple.

Les raisons sont les suivantes:

• Le développement ou, plus probablement, les tests d'intégration du projet révèlent des choses qui n'avaient pas été remarquées lors de la spécification d'origine - des cas marginaux aux principales facettes. Par exemple, le développeur remarque que des confirmations de messages hors service peuvent arriver.

• Les conditions réelles qui déterminent la spécification ne sont pas figées. Par exemple, un nouveau produit financier est créé qui doit être ajouté aux spécifications de traitement direct.

• Les pressions sur les délais entraînent l'élagage des fonctionnalités.

• D'autres parties prenantes au projet sont découvertes (par exemple, à mi-parcours du projet, un projet similaire est découvert dans une zone différente, et les sous-systèmes communs doivent être centralisés / partagés - cela m'est arrivé à mi-parcours d'un projet de 2 ans, ce qui a entraîné une importante réorganisation). architecture).

• Les sponsors supplémentaires du projet ont de nouvelles exigences (l'un des exemples les plus célèbres est l'histoire du développement de Bradley Fighting Vehicle).

Quant à savoir pourquoi les changements de spécifications ont un effet négatif (vous ne pouvez pas dire "ne doit pas se produire" car comme vous pouvez le voir, il y a beaucoup de raisons pour lesquelles ils le font, presque tous en dehors de votre contrôle et beaucoup pour une bonne raison) -

• Les changements de spécifications entraînent des changements de code, vous distrayant de l'achèvement des parties du projet qui ne sont pas encore écrites (comme nous le savons tous, et évangélisés par Joel Spolsky, les changements de focus sont très mauvais pour les développeurs)

• Certaines modifications de spécifications (parfois apparemment TRÈS mineures) pourraient entraîner la nécessité de réorganiser / ré-architecturer complètement le système, car un choix entre 2 architectures a été fait sur la base d'une hypothèse tirée de la spécification .

• En cas de TDD, une grande partie du travail mis à l'épreuve peut être annulée.

• Si les changements de spécifications proviennent de parties prenantes supplémentaires comme indiqué ci-dessus, ils peuvent être contradictoires avec les spécifications existantes, entraînant une baisse significative de la qualité du produit (voir Fighting Vehicle, Bradley).

• Le changement de spécification peut violer une exigence commerciale existante dont le changeur / demandeur pourrait ne pas être au courant ou ne pas se soucier (c'est vraiment la même chose que le dernier point).

Bien entendu, la date de livraison du projet est allongée (parfois de manière significative) et la probabilité de défauts potentiellement augmentée.

Pour le meilleur exemple de la façon dont un changement mineur dans la spécification peut créer des problèmes extrêmes, j'ai 3 lettres pour vous:

Y2K .

Tout ce qu'ils ont fait, c'est changer la spécification pour dire " doit travailler après l'an 2000 ".

De plus, dans certaines situations, il est en effet vrai que la spécification NE DOIT PAS changer (par opposition à "ne devrait pas changer sans raison valable"):

• Une partie de la spécification est (ou dépend) d'une spécification d'un système externe qui doit être en interface avec.

• Une partie de la spécification est (ou dépend) d'un matériel sur lequel le système est implémenté.

• Exigences du contrat avec un client (bien que la limitation concerne strictement la modification de la spécification sans passer par les modifications avec le client et changer le contrat, par opposition au simple fait du changement)

• Un système peut devoir répondre à des exigences légales ou réglementaires spécifiques quelle que soit la préférence du client. Exemples: cryptage de carte de crédit, protection des données fiscales.

Interdire les modifications de la spécification pendant le développement est idéal pour le programmeur, mais ce n'est pas réaliste dans un environnement réel. Les gens voudront toujours apporter des changements, même lorsque la chose est expédiée par la porte. Ça ne s'arrête jamais. Et certaines de ces personnes peuvent signer votre chèque de paie. Plus ils se soucient, plus ils y pensent, et donc plus souvent ils veulent réviser le design. Vous devez pouvoir tolérer de modifier la conception avant la fin, même si cela signifie recommencer.

L'important est de communiquer clairement les conséquences des changements afin que chacun ait des attentes réalistes du processus de conception.

Les changements doivent être correctement discutés, et la personne en charge de la chose doit avoir une compréhension claire de l'impact que les changements auront sur la date de livraison. Pour l'obtenir, il doit parler au développeur. Cependant, étant donné qu'une discussion en cours sur les modifications inondera le développeur et empêchera tout travail réel de se produire, les modifications doivent être mises en file d'attente et discutées à des intervalles planifiés et peu fréquents. C'est ce que vous espérez, bien sûr.

Idéalement, vous demandez aux gens de noter les changements qu'ils souhaitent apporter et de les faire évoquer lors de la réunion de coordination hebdomadaire / bihebdomadaire / mensuelle / quelle que soit la situation. Au cours de la réunion, chaque demande de changement est discutée, y compris une discussion sur les modifications sous-jacentes qui devront être apportées afin de mettre en œuvre la fonctionnalité demandée, et donc l'effet sur la date d'achèvement. Une fois que le «coût» du changement est établi, ils peuvent alors déterminer s'il faut l'inclure ou non.

La chose importante que ce processus introduit est la notion que chaque changement a un coût associé, et le coût est généralement plus élevé au fur et à mesure de l'avancement du projet, car plus de travail doit être dupliqué. Les personnes qui ne travaillent pas dans le développement n'ont généralement aucune idée du coût d'un changement; la seule façon pour eux de le dire est de le proposer et d'évaluer votre réaction. La création d'un processus d'examen des changements bien défini vous aidera à la fois pour vous et pour vous.

Notez que les programmeurs ont tendance à être extrêmement optimistes quant à la facilité d'un changement, ou extrêmement pessimistes quant à l'impossibilité de le faire. Essayez de comprendre ce que vous êtes en comparant vos estimations originales aux résultats et ajustez en conséquence.

Il serait peut-être préférable de dire que la spécification ne doit pas changer sans une demande et un processus de modification valides. La demande d'un changement de spécification a des effets sur le calendrier et les coûts, ils doivent donc être pris en compte dans l'approbation.

Étant donné qu'il existe un processus de gestion des changements approprié, il n'y a rien de "mal" à changer les spécifications, mais cela risque d'être très coûteux, de sorte que vos clients ne seront peut-être pas trop satisfaits. Vous pouvez les protéger d'eux-mêmes en essayant d'obtenir à l'avance de bonnes exigences et spécifications, de sorte que moins de modifications soient nécessaires.

La meilleure analogie que j'ai est de la comparer à la construction d'une maison. L'architecte établit les plans, puis établit un devis, le client accepte alors (ou non) le plan. Si le client souhaite une salle de bain supplémentaire, les travaux s'arrêtent, les plans doivent changer, une nouvelle estimation est effectuée et le client accepte (ou non).

Le logiciel d'écriture n'est pas différent. une fois l'accord conclu (après la conception et le devis), si des modifications doivent être apportées, le travail doit s'arrêter pour pouvoir établir un nouveau plan, un nouveau devis, puis les faire approuver (ou non), puis le travail reprend.

où que je dise ou non signifie que le projet se poursuit sans les nouveaux changements. Bien sûr, il y a toujours le temps et le matériel pour arriver à de nouveaux plans et devis.