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