Quels sont les défis de la transition Une équipe dans une atmosphère d'entreprise à partir d'une liste traditionnelle non itérative, de spécifications, de la carte de gantt, une équipe dépendante de la phase à une approche plus itérative?
En outre, quel était un moyen efficace d'accepter d'autres groupes tout en utilisant une nouvelle stratégie de développement?
6 Réponses :
Vous pouvez être intéressé dans le livre Changement sans peur: motifs Pour introduire de nouvelles idées par Lynn Manns et Linda montante. C'est un recueil d'expériences dans l'introduction de méthodes agiles dans des organisations.
+1 - Nice lien. Je suis partout sur celui-là. ;)
Yah, c'est peut-être un nouveau livre sur ma bibliothèque bientôt! belle recommandation.
Je suis en train de tenter de le faire maintenant. Nous avons un département de développement client sur place et je peux vous dire qu'ils sont essentiels pour essayer de prendre un buy-in pour un processus de développement itératif.
Quelques bonnes réponses sur celui-ci voici . < / p>
Si vous avez déjà reçu une piste de livraison de projets en retard et plus budgétaire en raison de morceaux importants et non gênants qui ne se faisaient pas, c'est un bon début de convaincre les parties prenantes de vos projets d'obtenir la balle de changement de change.
processus peut se révéler, mais uniquement avec les bonnes parties en l'appui. Votre clé est d'obtenir d'autres joueurs d'équipe pour voir la valeur dans ce que vous essayez de faire.
Pour nous, cela revient à approcher des choses d'une perspective des clients. Nous devons constamment revenir au client pour vous assurer que ce que nous construisons est ce qu'ils envisagent. Nous voulons rationaliser le processus pour arrêter de gaspiller tout le temps de tous les .
Maintenant, bien sûr, différentes parties de travail agile pour différentes organisations et très peu d'entreprises utilisent réellement des processus agiles le font dans un sens puriste.
Par l'essai et l'erreur déterminent ce qui fonctionne pour votre entreprise, votre culture et votre équipe. Il n'y a rien qui dit que vous ne pouvez pas adopter progressivement le processus global et la cerise choisissez les pièces qui fonctionnent le mieux pour votre modèle d'entreprise.
Super conseil, il est difficile de demander aux clients de penser que ce n'est pas seulement une autre tactique de vente de les vendre plus d'heures de développement.
Oui bien sûr. Nous sommes chanceux parce que nous le faisons avec un département interne qui entretiennent ensuite les clients. Vraiment presque comme un service commercial serait dans une autre société. Ils veulent livrer un produit qui répond à des attentes des clients afin qu'ils obtiennent finalement la vente, soit même mieux, répéter les affaires. J'essaie de justifier une approche agile principalement parce que je peux aider à fournir des parties fonctionnelles du logiciel plus tôt et la plupart des clients souhaitent toujours tout hier.
Vers ici, il a commencé avec une équipe qui souhaitait aller de l'avant et être plus agile en utilisant Scrum. Cette équipe était la "équipe pilote" et est allé pour quelques sprints (3 mois). Ils ont été entraînés par une personne de l'intérieur qui lisait déjà et apprenait à propos de Scrum. Faire un "pilote" au lieu d'une commutation complète a permis d'accepter des membres de l'équipe de direction et de réfraction.
Avoir une attitude "Essayons" Attitude aidez vraiment à amener les clients dans le processus également (clients internes ici, mais les clients nulles autres).
Et pour le faire prendre, vous devez prendre note des progrès réalisés et les avantages que cela vous apporte à vous et à votre équipe (cela peut être une meilleure performance, une meilleure communication avec les membres / clients de l'équipe, de meilleurs résultats, des clients plus heureux, etc. .)
Dans mon expérience, la transition de l'équipe n'est pas le problème. C'est la gestion de la transition.
+1: La direction connaît simplement (sans preuve) que le plan de projet valide Seul est un plan de cascade avec toutes les tâches définies.
Yah, et pour nous, c'est surtout nos clients. Je suis la seule chose sur leur esprit consiste à économiser de l'argent et à savoir à quel point quelque chose va coûter "hors-la-porte".
Qu'est-ce que nous avons fait:
a expliqué à la direction qu'un plan (qui entend prédire l'avenir) est simplement des peluches, une vapeur, une liste d'hypothèses sans base factuelle.
prévu une liste de sprints. A écrit un tableau de brûlure. Oublié de mettre en place des estimations sommaires.
a commencé à exécuter sur la liste des sprints.
Après les deux ou trois premières ou trois premières, la direction a commencé à se rendre compte que le "plan" n'était qu'une liste de brûler, sans "dates", "risques", "hypothèses" ou quelque chose comme un plan traditionnel de projet de cascade.
À ce stade, bien sûr, il est trop tard. Nous avons déjà terminé un sprint et sommes la plupart du temps à travers la seconde. Le cheval est hors de la grange. La cloche était déjà par anguille.
La direction exige de certaines choses.
Le budget total. Nous avons dit "Ajoutez les sprints qui sont importants pour vous. Dessinez simplement une ligne aléatoire, où que vous soyez heureux. C'est votre budget." Personne n'aime cela, parce que c'est trop de contrôle. "Comment pouvez-vous justifier cela?" ils ont demandé. "Facile. Nous construisons en ordre de priorité jusqu'à ce que vous annuliez le projet."
Qu'est-ce que nous avons dû ajouter était une durée indicative pour chaque sprints. Les nôtres sont de taille variable: 2 à 4 semaines. Une liste de 10 sprints était d'environ 26 semaines - 6 mois. Après cela, nous avons cessé de poser des chiffres.
la liste des "hypothèses". Nous venons de refuser cela. "Écrivez votre propre". Ils ne pouvaient penser à aucun seul. C'était ça.
la liste des "risques". Encore une fois, nous avons demandé ce qui les a effrayés . S'ils avaient été dérangés par quelque chose, ils devraient peut-être changer la priorité dans la perte de temps pour aborder cela.
date d'échéance. Nous avons tourné cela autour de cela et nous leur avons demandé de hiérarchiser les dates et les budgets et les risques qui leur étaient importants. Nous n'avons pas beaucoup de confiance de l'ordre - c'est leur appel en tant que gestionnaires.
Après deux autres sprints, ils ont cessé de faire des demandes de "cascade" et ont commencé à hiérarchiser et à gérer la perte de valeur.
Fait intéressant, ils n'ont jamais demandé à propos de la fluage de la portée. Les gestionnaires qui demandent "comment contrôlez-vous la portée?" rejeter activement le développement incrémentiel. Ils essaient de ne pas l'obtenir.
Lorsque les gestionnaires veulent savoir comment les méthodes agiles "empêchent" le fluage d'étendue, ils ont (a) étiqueter le processus d'apprentissage comme "fluage" (qui est mauvais) et (b) résistant à l'idée que l'apprentissage conduit à des changements de portée. La seule façon dont vous avez même la portée "fluage" est lorsque vous vous engagez à une portée spécifique, quel que soit tout apprentissage pouvant arriver. Les méthodes agiles ne s'engagent que dans un prochain sprint, pas une étendue globale. Si vous ne vous engagez pas dans une portée, cela ne peut pas se glisser parce qu'il n'existe pas.
C'est un excellent point, c'est "Comment prévenir l'étendue du fluage de la portée" un synonyme de "comment nous résoutons-nous de devoir mettre en œuvre une meilleure conception"?
+1 - J'aime ce que vous dites, mon seul ajout est que vous devez être sensible à la culture de votre organisation. Cette approche peut très bien ne pas fonctionner pour vous si vous n'avez pas assez de gens pour atteindre l'adhésion et obtenir cette balle roulant du haut en bas.
Nous n'avons pas eu la balle qui roule de haut en bas. Nous venons de faire une équipe à la fois.
de mon expérience (certitude), assurez-vous que tous vos programmeurs participent à la décision de passer à Agile / Scrum / Whak, et qu'ils sont tous en faveur de cela - ou du moins ne vont pas s'opposer activement à s'opposer activement à ce que ce. J'ai vu la résistance des membres de l'équipe lorsque Agile / Scrum a été perçue comme mandatée d'en haut sans son consentement / son entrée. Il est assez difficile de recycler les gestionnaires sans avoir à convaincre constamment votre équipe.
Ceci est vrai, fait rarement des choses mandatées inspirent la passion dans ceux qu'elle est imposée.
Cette question est hors sujets car ce n'est pas dans la portée de ce site, tel que défini dans Quels sujets puis-je poser ici? aussi Voir: quels types de questions dois-je éviter de demander? Vous pourrez peut-être demander sur Un autre site d'échange de pile , par exemple gestion de projet ou Génie logiciel . Assurez-vous de lire la page sur le sujet dans le centre d'aide pour tout site sur lequel vous avez l'intention de poster une question.
Curieusement, ce n'était pas hors tension il y a 8 ans pour le moment;) Mais assez sûr, c'est aujourd'hui!
Oui. Le fait que ce qui est sur le sujet / hors sujet sur le débordement de pile a changé, ne se reflète pas négativement sur vous, ni cette question. C'est juste la façon dont le site a évolué au fil du temps.