Traiter avec «Scope Creep» dans les projets de développement logiciel

Faire face à «Scope Creep» dans les projets de développement logiciel
Résumé
Portée fluage est un risque important dans les projets de développement de logiciels. Nous expliquer pourquoi il en est ainsi, et comment les éviter ou au moins d'atténuer le risque.
Qu'est-ce glissement dans l'ampleur?
Un nouveau logiciel est généralement élaboré à la suite d'un client (qui peut être un interne ou un organisme externe) l'identification d'un besoin. La prochaine étape est de préciser comment le logiciel va répondre à ce besoin, plus précisément, quelles fonctionnalités seront développées. Il s'agit de la «portée» du projet. Les plans du projet sont établis sur la base des estimations pour développer et apporter la fonctionnalité spécifiée et une date de fin est convenu
commence le développement et le projet semble être en bonne voie. Mais alors, le client se rend compte qu'il ya des exigences supplémentaires qu'ils ont oublié de mentionner, ou des éléments supplémentaires de la fonctionnalité dont ils ont besoin. Souvent, l'ajout de ces extras cause la durée du projet doit être étendu, entraînant retards et l'augmentation des coûts, conduisant à l'érosion de la marge sur le projet et, éventuellement, l'insatisfaction des clients et la perte de crédibilité en raison de retard de livraison.
Comment faire face aux dérives du contenu
Il est important que les spécifications fonctionnelles est produit au départ, rédigées en des termes que le client puisse comprendre. Par exemple, un rendez-vous par le biais du processus que le logiciel de soutien, peut-être illustré par moque-up des captures d'écran, permettra de préciser comment le nouveau système fonctionnera à partir du point de l'utilisateur de vue.
La spécification fonctionnelle doit être approuvé et signé par le client, et doit inclure un Énoncé de la portée. Cet article stipule que seule la fonctionnalité qui est explicitement décrit dans le cahier des charges est inclus dans la portée du projet, et que tout ce qui n'est pas décrite est «portée à l'extérieur.
Lorsque le client identifie ensuite des éléments supplémentaires, il est fait référence au cahier des charges: la fonctionnalité requise est décrite ou fait allusion? Si ce n'est pas le cas, le développement de nouvelles possibilités à l'extérieur.
La prochaine étape est de travailler sur l'impact du développement de la nouvelle fonctionnalité: ce que des efforts supplémentaires seront nécessaires? Quel effet cela aura-t sur la durée globale du projet? Quels sont les autres coûts seront engagés et comment cela affectera la marge de projet?
Si l'impact est négligeable, il peut être décidé d'inclure les nouvelles fonctionnalités dans le projet existant, mais, idéalement, cela doit être indiqué par écrit par l'émission d'une spécification révisée. Le danger ici est que le client estime qu'un précédent a été établi et que d'autres révisions seront de la même façon: il est important de communiquer les raisons de permettre à la révision dans ce cas.
Il est plus probable que le développement supplémentaire entraînerait un retard et / ou des coûts supplémentaires. Le client doit être mis au courant des implications de la révision des termes de son impact sur les délais et les coûts, et une spécification des ajouts et des changements doivent être écrits (avec son propre énoncé de portée). Il appartient ensuite au client de décider s'ils sont prêts à payer plus, et si elles peuvent accepter la date de fin révisé pour le projet. S'ils sont d'accord, la nouvelle spécification devrait être signé comme avant.
Avons-nous vraiment besoin d'un Énoncé de la portée?
Vous pouvez penser que la rédaction d'un cahier des charges suffisamment détaillé pour pouvoir faire la déclaration de portée impliquerait plus de temps (et le coût) que cela est justifié par la valeur du projet dans son ensemble. Par exemple, si l'ensemble du projet devrait seulement prendre quelques semaines et il faudra 5 jours pour rédiger une spécification détaillée, une analyse coûts / bénéfices devrait montrer qu'il ne vaut pas le faire.
Si tel est le cas, d'évaluer la probabilité du risque - en fonction de votre connaissance du client et comment êtes vous confiant que toutes les exigences ont été identifiés - et l'impact possible. Construit en urgence suffisante dans vos estimations de temps et le coût pour couvrir tous mais la plupart des grandes révisions de la spécification.