Est-ce qu'avoir des dates de livraison fixes pour les éléments est une manière de travailler "Agile"?
On nous dit toujours que nous allons travailler de manière agile sur un nouveau projet par la direction. Ils ont mis en place des stand-ups, la planification du sprint, des rétrospectives, etc. une. Ce plan sort jusqu'au T2 2017.
Pour moi, cela ressemble à Waterfall dans le pire des sens, un plan sans contribution de l'équipe technique a été élaboré où certaines histoires sur le plan sont très peu claires et aucune n'a été estimée par l'équipe de développement.
Cependant, je sais que leur argument sera "les principaux intervenants doivent avoir des dates et il doit y avoir un plan, nous ne pouvons pas simplement travailler à partir d'un arriéré". Pour moi, cela semble que les principaux intervenants n'ont pas adhéré à Agile et nous sommes donc condamnés à ne pas le mettre en œuvre à un niveau inférieur.
Est-ce un jugement juste ou suis-je en train de réagir de manière excessive à ce plan!?
Il y a une différence entre respecter le délai et répondre à toutes les exigences. C'est comme le vieil adage "rapide, bon ou pas cher, choisissez-en deux".
Donc, ici, vous avez des dates fixes pour la livraison - c'est bien, cela signifie que vous êtes limité dans le temps en ce que ce que vous livrez à la fin de votre dernier sprint sera le produit final. Vous vous souvenez que vous devez toujours publier un logiciel fonctionnel à la fin de chaque sprint, n'est-ce pas?.
Ce qui peut arriver, c'est que le logiciel final manquera de certaines fonctionnalités. Eh bien, cela se produit avec toutes les méthodologies de développement, y compris la cascade. Tout ce qui se passera, c'est que vous serez chargé de produire une version de correctif par la suite, ou une version 2. Cela suppose bien sûr que votre livraison finale est assez bonne!
Les dates fixes ne sont donc pas une manière de travailler non agile. Agile ne signifie pas qu'il existe un budget illimité pour jouer avec vos nouveaux outils de planification. Cela signifie que vous devrez vous concentrer sur la livraison, ce n'est jamais une mauvaise chose.
Non. C'est exactement le genre de choses que les sociétés non logicielles ont tendance à faire. Il y a des plans, des délais et des budgets. Et cela échouera inévitablement, car les humains craignent de prédire l'avenir.
Passons en revue les différents points ici:
On nous dit toujours que nous allons travailler de manière agile sur un nouveau projet par la direction.
Si vous étiez Agile, alors vous auriez des équipes auto-organisées, sans que la direction vous dise comment travailler.
Cependant, ils ont maintenant élaboré un plan détaillant tous les travaux qu'ils souhaitent que nous livrions avec des dates pour chaque élément et présenter à nouveau les dates avec ce qui sera démontré dans chacun.
Nan. C'est à peu près l'antithèse du développement itératif. Quelque chose va se produire (quelqu'un tombe malade, quelqu'un part, une exigence a été oubliée, vos serveurs meurent, peu importe) et ensuite vous manquez l'un de ces objectifs. Maintenant, la direction peut recalculer le plan entier , ou casser le fouet sur le développement.
aucun n'a été estimé par l'équipe de développement.
Alors, comment la direction sait-elle que ce plan est viable ? En Agile, le travail est une négociation. Les entreprises disent: nous aimerions cela. L'ingénierie dit: d'accord, en supposant XYZ, cela prendra 3 semaines. Il n'y a pas de collaboration client dans ce que vous décrivez. Pas d'individus et d'interactions.
Pour moi, cela semble que les parties prenantes de haut niveau n'ont pas adhéré à Agile et nous sommes donc condamnés à ne pas le mettre en œuvre à un niveau inférieur.
Vous n'êtes pas nécessairement condamné, mais sinon, ce n'est qu'une coïncidence. Lorsque tout le travail apparaît parce que la direction ne peut pas voir l'avenir, vous manquerez vos dates (ou vous produirez du code de mauvaise qualité ou vous aurez besoin de plus de ressources que prévu). Ce sera alors votre faute. La direction vous incitera probablement à travailler plus d'heures pour atteindre la date, ou peut-être jeter les gens au problème.
Meilleur cas, la gestion est en fait agile et suffisamment intelligente pour réduire la portée. Cela signifie qu'ils ont juste passé tout ce temps à élaborer un grand plan détaillé qui ne vaut rien.
Si l'on s'attend à ce que des ensembles spécifiques de fonctionnalités soient livrés à des dates spécifiques, alors non, ce n'est pas une gestion de projet agile. La gestion de projet agile est de nature empirique. Les projections ne sont pas faites sur la base des souhaits des dirigeants mais plutôt sur l'analyse des performances antérieures.
Votre description correspond à ce que je considère être agile comme un cargo. L'accent est mis sur les processus et cérémonies spécifiques et non sur les concepts fondamentaux de la gestion de projet fondée sur des preuves. Vous pourriez avoir de la chance de faire comprendre aux gens d'affaires si vous reliez cela à Lean ou TPS . Le vrai problème que vous devez résoudre ici est de faire en sorte que la direction dépasse sa peur de l'inconnu. La bonne réponse aux dirigeants est "nous ne pouvons pas vous dire maintenant quand les choses seront faites mais une fois que nous commencerons à fournir de la valeur, nous pouvons construire des projections basées sur notre expérience." Les développeurs ont tendance à dire des choses comme "c'est fait quand c'est fait" et "je ne sais pas quand cela sera fait". Les gestionnaires ne diront pas des choses comme ça aux cadres, cela les fait sonner comme des nincompoops. Ils font simplement ce qu'ils savent.
Très probablement, le plan échouera et devra être révisé. Le plus grand risque pour l'équipe est qu'il y aura une grosse poussée pour respecter les délais et la qualité en souffrira. À un moment donné, vous ne serez pas sur la cible (très probablement, ce sera la première échéance) et il y aura un Push pour atteindre cette date. Des heures supplémentaires seront attendues et il y aura une pression pour couper les coins (sauter le test unitaire, les revues de code, etc.) C'est une pente glissante et une fois que vous commencez sur cette voie, c'est un peu une spirale descendante et les choses vont mal tourner. La productivité va empirer à mesure que le projet se poursuit de cette façon.
Si vous pouvez amener l'équipe de développement à présenter un front unifié, vous devriez vraiment faire reculer et maintenir la ligne sur la qualité. D'après mon expérience, les chefs de projet ont tendance à penser que la sortie du logiciel est linéaire. C'est-à-dire que chaque période X produira Y "précentage terminé". Autrement dit, si vous n'êtes pas "terminé à 50%" à la moitié du temps imparti, les klaxons commencent à hurler. En réalité, si vous le faites correctement, la première fonctionnalité a tendance à prendre beaucoup plus de temps que la 50e fonctionnalité (de taille similaire.) Si vous pouvez passer à travers cette période de crise de danger initiale ("que se passe-t-il?", "Je ne ' t voir rien se faire! ") vous serez probablement OK.
Bienvenue dans les vraies affaires.
Il y a un style d'entreprise plus ancien, que j'ai tendance à appeler dérisoire "développement traditionnel", puis un nouveau style, "développement agile". Si j'essaie de les traiter comme des idéaux opposés, nous voyons une division simple au milieu: les plans et les exigences vont dans la colonne traditionnelle, la découverte et l'évolution vont dans la colonne agile. C'est net, bien rangé et faux.
En réalité, l'entreprise est une recherche du juste milieu entre les deux. Il est facile de montrer que l'un ou l'autre extrême tombe à plat sur son visage. Nous qui aimons Agile, nous montrons avec impatience tous les problèmes de l'idéal pur du développement traditionnel, et nombreux sont ceux qui peuvent montrer les nombreuses façons dont l'Agile pur s'effondre. Les entreprises agiles qui réussissent sont celles qui trouvent leur équilibre particulier entre les deux. Les entreprises traditionnelles qui réussissent sont celles qui trouvent leur équilibre particulier entre les deux. Vous ne pouvez pas avoir l'une sans l'autre.
Même notre processus SCRUM béni montre un équilibre entre les deux. Bien qu'il y ait une tentative claire de maximiser l'agilité, quelques compromis clés sont faits. Par exemple, le Product Owner a la tâche puissante de défendre tous les clients. SCRUM ne précise pas intentionnellement comment cette interaction fonctionne. Il remet intentionnellement sur le fait que tout le monde doit être payé à la fin de la journée. C'est le travail du propriétaire du produit de créer l'illusion que cela n'a pas d'importance.
(Il est intéressant de noter que l'agilité pure fonctionne très bien, tant que vous n'êtes pas payé jusqu'à ce que vous produisiez un produit et que vous n'ayez accès à des informations propriétaires que lorsque vous êtes acquis. Je pense que les seuls ingénieurs logiciels qui sont à l'aise avec ce métier sont les entrepreneurs)
La direction a donc dicté les fonctionnalités qui y seront et quand elles doivent y être. C'est très bien. Une phrase que j'ai entendue est "le client choisit le quoi et le quand, le producteur choisit le qui et le comment." Vous avez été inscrit pour le "quoi" et le "quand". Ils n'ont rien dit sur le qui ou le comment, sauf pour vous offrir la possibilité d'utiliser "Agile" comme votre comment. Il ne reste plus qu'à aider la direction à comprendre combien de personnes elle devra embaucher pour répondre à ses besoins.
Dans un monde parfait, votre entreprise est agile de l'extérieur. Il interagit avec ses clients de manière agile, permettant aux développeurs de se développer agily pour eux. Cependant, très souvent, l'entreprise doit interagir avec l'extérieur tout en se développant agily à l'intérieur. Entre les deux est toujours un ensemble complexe de compromis, unique à chaque entreprise.
Personnellement, je traite cette situation comme un test pour tous ceux qui pensent comprendre le développement agile. À un moment donné dans le futur, vous devrez développer un produit pour une date limite, et cette paire produit/date limite sera relativement fixe. Si un produit/délai fixe brise votre processus, pouvez-vous vraiment dire que vous étiez Agile en premier lieu?
Mon conseil: ne pensez pas à cela comme une cascade. Vous contrôlez toujours le "comment". Vous pouvez toujours faire tout le sprint rapide et le prototypage flexible pour lesquels Agile est si célèbre. Vous avez simplement pour être conscient que le caoutchouc rencontre la route, et vous devez livrer. C'est le monde réel, pas le monde idéal. Aurait-il été préférable pour eux de vous demander en premier lieu? Sûr. Ce n'était peut-être pas votre appel. Il peut y avoir mille raisons professionnelles de le faire à leur façon que vous ne comprenez tout simplement pas. N'hésitez pas à les repousser, mais comprenez qu'ils peuvent avoir une très bonne raison pour ce qu'ils ont fait.
CHAQUE projet pertinent pour l'entreprise a des contraintes:
- Temps
- Ressources
- Un ensemble de fonctionnalités minimum attendu
Ce n'est rien d'autre. Développer l'agilité ne signifie pas "les gens nous paient de l'argent, donc nous pouvons développer ce que nous voulons quand il sera prêt" - vous aurez toujours un certain délai. Il y aura toujours une date avec des exigences minimales et si elles ne sont pas remplies, le projet sera annulé et appelé échec. Ils peuvent parfois être implicites - donc le gestionnaire sait "Si je n'ai pas d'interface utilisateur fonctionnelle avec ces fonctionnalités après 4 semaines, ce projet est voué à l'échec" - ou il peut y avoir des actionnaires qui se fixent un objectif.
De nombreux projets découlent de la législation. - Si le gouvernement décide que vous devez mettre en œuvre la fonctionnalité X jusqu'en 2017 pour respecter une nouvelle loi, vous aurez un délai non négociable et un ensemble de fonctionnalités qui doivent être prêtes. La seule variable est la quantité de ressources que la direction peut allouer à la tâche. - Et dans ces projets, où la date limite est une décision externe, ils devront surveiller vos progrès, vous entendre pronostiquer et embaucher les équipes ou externaliser une partie du travail pour atteindre leurs objectifs.
Tout cela ne s'oppose pas au développement agile. Vous aurez toujours vos sprints, développez vos fonctionnalités dans votre propre calendrier. Vous obtiendrez toujours vos priorités de fonctionnalités auprès d'un client - et vous travaillerez à fournir autant de ces fonctionnalités que possible jusqu'à la date limite.
Si le délai sera effectivement respecté avec les ressources disponibles, c'est un problème de gestion. Vous pouvez donner votre pronostic et des mises à jour de statut hebdomadaires/quotidiennes et ils peuvent décider s'ils ont besoin de plus de ressources. Sinon, vous continuerez à travailler dans les sprints et à fournir des runnables - les mêmes que n'importe quel projet.
Agile ne vous empêche pas de planifier des jalons (par exemple, nous publierons V 1.0 dans 3 mois), mais ce qui entre dans chaque jalon ne peut pas être corrigé.
Je pense que la façon dont vous devez réagir dépend de la nature du projet. Si le projet consiste à envoyer un homme sur la lune d'ici le T2 2017, tout le monde conviendrait qu'il est voué à l'échec. Si vous pensez pouvoir livrer un MVP d'ici la fin du deuxième trimestre 2017, vous devriez y travailler sprint par sprint.
Si la direction pense que votre équipe fait de son mieux et que vous pouvez montrer des progrès à chaque sprint, vous devriez pouvoir négocier plus longtemps.
Comme quelqu'un l'a déjà souligné avant le manifeste dit:
Individus et interactions au cours du processus
Je vous suggère de jeter un coup d'œil au plan proposé et de proposer des changements. N'oubliez pas que le Manifeste dit que l'arriéré n'est jamais définitif, il continue d'évoluer.
Vous pouvez donc transmettre vos suggestions à l'équipe. Si vous avez un raisonnement valide et que l'équipe y consent, tout propriétaire de produit digne de ce nom les considérera et éliminera l'arriéré pour refléter l'opinion de toute l'équipe.
C'est le point où cela pourrait aller de deux façons.
Le propriétaire du produit et l'entreprise sont d'accord avec votre raisonnement et peuvent augmenter les ressources pour respecter le délai si c'est une option OR ils peuvent choisir de supprimer certaines fonctionnalités pour respecter le délai.
Ils peuvent toujours vouloir s'en tenir à leur propre version contre l'avis collectif de l'équipe.
Si le résultat est n ° 2, ce n'est pas Agile.
Si vous vous retrouvez avec le n ° 1, je dirais que l'équipe est sur la bonne voie, car Agile ne concerne pas seulement les Devs "Répondre au changement", c'est aussi que l'entreprise puisse réagir au changement.
Imaginez que vous demandiez à quelqu'un de Peindre un mur, une maison puis une rue entière pour vous, combien de temps donneriez-vous à cette personne pour le faire?
Quelle que soit votre réponse, vous vous tromperez. C'est ça.
Il n'y a aucun moyen qu'ils aient raison sur les dates s'ils ne demandent pas aux gens qui ont besoin de faire le travail ce qu'ils pensent.
Soit dit en passant, si vous (en équipe) acceptez ces dates, vous vous trompez.
Vous devriez demander un peu de temps pour travailler sur cette planification avec les parties prenantes, afin de pouvoir fixer des priorités en fonction de la facilité et de la rapidité avec laquelle les choses sont faites.
Par exemple, peut-être que le travail final prendra deux fois plus de temps qu'ils le pensaient, mais ils pourraient utiliser une version bêta beaucoup plus tôt que prévu.
Dans l'ensemble, vous ne pouvez pas laisser les gens penser que vous pourrez faire X en Y si vous ne pouvez pas ou pourriez être plus rapide, c'est votre responsabilité de préciser ce dont vous avez besoin en termes de détails et de temps.