Comment les délais serrés et la pression des horaires affectent-ils le TCO et les délais de livraison?

Le père d'un ami, qui est directeur du génie logiciel, a déclaré avec insistance: "La première cause de dépassements d'horaire est la pression d'horaire."

Où en est la recherche? Est-ce une quantité modérée de pression de programmation revigorante, ou le gestionnaire que j'ai mentionné a-t-il raison ou tort, ou s'agit-il de "plus vous avez de pression de programmation, plus le délai de livraison et le coût total de possession sont longs?" Est-ce une de ces choses où, dans l'idéal, l'ingénierie logicielle fonctionnerait sans pression d'horaire, mais pratiquement nous devons travailler avec des contraintes de situations réelles?

Tout lien vers la littérature en génie logiciel serait apprécié.

La cause numéro un des dépassements de programmation est la pression de programmation.

Je ne suis pas d'accord. La cause numéro un des dépassements d'horaire est un calendrier qui ne reflète pas la réalité, et d'une manière trop optimiste. La nature humaine dicte qu'une certaine pression de programmation est une nécessité absolue. Quelques-uns des problèmes qui surviennent sans une certaine pression de programmation sont des problèmes intéressants et "le meilleur est l'ennemi du bien". Nous, les techniciens, préférerions de loin travailler sur les problèmes qui nous intéressent plutôt que sur le problème à résoudre pour sortir le produit. Supprimez les délais (alias la pression du calendrier) et nous travaillerons sur ces problèmes intéressants, au détriment du produit.

Un autre problème est que le produit doit être "assez bon". Il n'a pas besoin d'être parfait. Les ingénieurs et les scientifiques voient les hypothèses simplificatrices qui ne sont pas tout à fait valables dans certaines circonstances particulières. Les graphistes voient des problèmes d'alias qui sont invisibles pour tout le monde. Les programmeurs voient des verrues dans leurs architectures qui n'ont aucun impact sur le comportement du produit. "Le meilleur est l'ennemi du bien", ce qui signifie que parfois nous devons vivre avec des problèmes qui ne sont pas vraiment des problèmes.

Le manque de pression sur les horaires entraînera un produit avec un coût de possession très élevé. Les dépassements sont dus à de mauvais horaires. Cela peut prendre différentes formes. Effort nécessaire sous-estimé, ne tenant pas compte des dépendances, ajout de personnes à un projet déjà en retard. Juste pour en nommer quelques-uns.

Le temps, la qualité, les ressources et le nombre de fonctionnalités sont tous connectés. Vous pouvez en corriger trois et obtenir le dernier comme sortie de votre processus de planification.

La façon dont votre question est formulée implique que le temps est votre variable, et les trois autres (la qualité, les ressources et le nombre de fonctionnalités) sont tous fixes. La question peut gagner à changer un peu la perspective en fixant l'heure ^* et en laissant flotter la qualité.

Maintenant, votre question devient la suivante: "Les contraintes de temps ont-elles un impact négatif sur la qualité"? La réponse à cette question est un "oui" retentissant: la recherche confirme que les gens font pire sous la pression sur des problèmes liés aux mathématiques ^** qu'ils n'ont pas pratiqué de manière intensive auparavant (c'est-à-dire tenté cinquante fois ou plus), donc le père de votre ami a raison.

^** Il y a une hypothèse implicite ici que la programmation est similaire à faire des mathématiques; Je pense que cette hypothèse est juste.

plus vous avez de contraintes de programmation, plus le délai de livraison est long et plus le TCO est élevé?

Eh bien, toute planification effectuée par le gestionnaire sans en discuter avec le responsable technique est sujette à cela. Il est très évident que la planification ou les estimations qui ne sont PAS basées sur des faits sont sujettes à l'échec .

En outre, les gestionnaires qui évitent la planification basée sur des preuves évoluent également vers l'échec suivant de leur projet. Il existe un certain nombre d'études sur ce sujet et la planification basée sur des mesures est la bonne façon de suivre.

Planification de droite à gauche.

Quelqu'un dans la direction pense toujours qu'il s'agit de Steve Jobs avec sa célèbre zone de distorsion de la réalité. Jusqu'à ce que quelqu'un dans le développement de produits les éduque, les gestionnaires non techniques peuvent souvent avoir une vision de la programmation aussi sophistiquée que le premier film français "Le voyage dans la lune" était pour la science des fusées.

Le problème existe depuis un certain temps. Fred Brooks parle d'estimation sans intestin dans Mythical Man-Month . Barry Boehm en parle dans ses propositions pour une approche Theory-W de la gestion. Plus récemment, Steve McConnell (auteur de Code Complete ) met l'accent sur le concept de négociation de principe dans "Comment défendre un calendrier impopulaire" .

Agile pousse la portée des projets à un endroit où elle est très visible. Le Manifeste Agile appelle à "la collaboration des clients sur la négociation des contrats". J'espère également que cela habilitera les personnes tenues pour responsables. Le jeu de planification évite aux parties prenantes non techniques de contraindre les développeurs aux promesses qu'ils ont faites il y a longtemps et qui ont été dépassées par des changements dans les exigences ou de nouvelles découvertes.

Si votre organisation rejette l'agilité, il existe d'excellentes méthodes liées à l'étalonnage des estimations pour recalculer un calendrier en fonction de la valeur acquise . Je ne pense pas que la valeur acquise fasse un excellent travail avec certains des vrais problèmes de prédiction, mais cela peut aider à dissiper les illusions sur la vitesse des projets et l'escalade des estimations que nous avons comme étant en quelque sorte des faits.

Il y a un dicton selon lequel plus vous commencez à coder tôt, plus cela prend de temps. La pression d'horaire peut avoir pour effet de forcer le changement de méthodologie. Parfois, c'est de la cascade au "code comme l'enfer". Cela peut avoir un impact négatif sur la qualité, sans parler du moral lorsque les travailleurs ne peuvent pas faire de leur mieux et que leurs pairs et futurs responsables les voient à leur pire, pas à leur meilleur. Dans un environnement comme celui-ci, un certain degré de chaos peut être contrôlé avec le contrôle des sources, la construction et les tests quotidiens (ou l'intégration continue et les tests unitaires), les revues de code, en utilisant une équipe expérimentée et hautement qualifiée, résistant à la tentation d'ajouter du personnel tard dans la le projet, et l'ancien standby, les heures supplémentaires.

D'autres fois, le changement de méthodologie peut passer d'une cascade à une augmentation progressive itérative. D'après mon expérience, la direction a mis du temps à adopter Agile. Mais après un certain temps, il y a eu une nouvelle direction plus favorable à Agile. La boxe temporelle peut être comme la budgétisation - elle peut nous obliger à réfléchir à la meilleure utilisation d'une ressource limitée. Scrum a deux plages horaires - l'une est quotidienne pour les commentaires entre les membres de l'équipe, l'autre est mensuelle pour le sprint à travers la liste déroulante.

Licence Creative Commons - voir http://en.wikipedia.org/wiki/File:Scrum_process.svg

Vous n'avez pas besoin de littérature en génie logiciel. La probabilité conceptuelle et les statistiques du premier cycle sont tout ce dont vous avez besoin.

Une estimation n'est que cela, une estimation. Ce n'est pas précis, ce n'est pas garanti. Pour toute estimation, il y a une certaine probabilité que vous le dépassiez ou le frappiez sur le nez, et une certaine probabilité que vous le dépassiez.

Probabilité 101: p (sous-dépassement ou frappe exacte) + p (dépassement) = 100%.

Un programme basé sur une estimation a exactement les mêmes caractéristiques.

Vous ne pouvez pas éliminer complètement l'incertitude. Il y aura TOUJOURS une certaine probabilité de dépassement. Il pourrait être faible, la probabilité que l'Iran nuque à votre immeuble de bureaux, mais il est toujours là. Le mieux que vous puissiez faire est de tout regarder et de réduire l'incertitude autant que possible. Une fois que vous avez fait cela, vous aurez, si vous êtes chanceux, un calendrier avec une petite incertitude et une probabilité de 50% de chaque côté.

Maintenant, pensez-y: si vous tirez sur le calendrier, la probabilité que vous manquiez ou atteigniez exactement le calendrier diminue. Le total doit encore totaliser 100%. Où va cette probabilité? Réponse, il entre dans la probabilité de dépassement.

La division General Dynamics / Fort Worth a appris celle-ci à la dure. Ils ont fait leur estimation initiale pour le développement du F-16C / D et l'ont envoyé dans la chaîne alimentaire. Quelqu'un d'en haut a arbitrairement coupé un an et l'a envoyé à l'Air Force. En conséquence directe, GD / FW avait un an de retard au test en vol, et l'Air Force n'était PAS contente. (Notez que "un an de retard" était conforme au calendrier révisé, ce qui signifie que le calendrier d'origine était DROIT SUR LA CIBLE.)

Je pense qu'une certaine quantité de pression dans un projet est OK car elle aide à maintenir la concentration.

Cependant, si la pression n'est pas réaliste, ou si la communication entre la direction et le personnel technique ne fonctionne pas correctement, oui, il existe un risque que la pression de programmation entraîne une mauvaise qualité et / ou un retard de livraison.

Un développeur expérimenté saura qu'il / elle n'est pas censé produire la solution parfaite mais plutôt une solution qui est assez bonne . Ainsi, l'estimation donnée par un tel développeur reflétera déjà sa compréhension de ce qui est assez bon pour un projet particulier.

Il existe de nombreux facteurs qui influencent la définition de suffisamment bon.

Par exemple, combien de mois dure le projet? Si le projet dure un an, vous pouvez écrire un prototype de ce module particulièrement difficile assez rapidement au début du projet, puis vous avez plusieurs mois pour le tester et le déboguer en tant qu'activité parallèle au développement d'autres modules plus routiniers. (Vous pouvez laisser ce module mûrir pendant plusieurs mois jusqu'à ce qu'il soit suffisamment bon pour que vous n'ayez pas besoin de le faire correctement dès le début.) Je trouve cette stratégie très efficace mais vous avez besoin d'un gestionnaire qui vous fait confiance et vous laissera garder un projet ouvert pendant des mois. Un autre gestionnaire (méfiant) pourrait vous pousser à terminer ce module dès que possible (peu importe si vous devrez le réparer plus tard et si cette approche coûtera finalement beaucoup plus de temps au total).

Autre exemple: le projet concerne un produit qui n'aura qu'une seule version. Ensuite, vous pouvez essayer de le faire rapidement et compter sur des tests approfondis pour vous assurer que le produit fonctionne comme prévu (rapide et sale est assez bon ). D'un autre côté, si le produit doit avoir deux ou trois versions, mieux vaut consacrer un peu de temps à sa conception, afin d'éviter une réécriture importante du code pour les versions ultérieures. (Dans ce cas, rapide et sale n'est pas suffisant car le temps de développement total sur les trois versions est plus long.)

En fin de compte, je pense qu'une mauvaise communication entre la direction et les techniciens et un manque de compréhension commune de ce qui est assez bon pour le projet en cours peut entraîner une pression de programmation excessive, entraînant une mauvaise qualité / retard de livraison.

Il n'y a jamais assez de temps pour le faire correctement la première fois, mais il y a toujours assez de temps pour le réparer plus tard.