XP vs traditionnelle bonne gestion de projet [fermé]

Question

Je suis dans l’industrie de l’informatique depuis maintenant 10 ans, mais j’ai travaillé dans la catégorie "traditionnellement". équipes de projet gérées (à la fois bien gérées et mal gérées).

J'ai entendu parler du " nouveau " Scrum ou XP type de gestion de projet et aspirait à en faire partie (comme les gens de S / W, nous aimons toujours tout ce qui est nouveau, je suppose), mais n’avons pas la possibilité.

Ma question est la suivante: quelles sont vos expériences pour passer au "nouveau" était-il significativement meilleur ou pire ou pas différent? Y at-il eu une amélioration du taux de réussite des projets lors de l’utilisation de la méthode de développement XP ou est-il identique à celui de projets traditionnels bien gérés?

Cela ne devrait pas être une question politique, mais simplement vos expériences en tant que personnes ayant déménagé dans le nouveau monde ou expérimentées au moins une fois et de nouveau.

Merci d'avance

Answer 1

Avant d’avoir entendu parler de XP, j’ai eu un très bon manager (Mike) à un poste très précoce. Il était habitué à gérer des ingénieurs et est passé à la gestion de logiciels. Après quelques mauvaises expériences professionnelles, j’ai jeté un regard sur son style par rapport à la gestion de projet typique que j’avais avant et après avoir travaillé avec lui.

• Rencontré tout le monde au moins une fois par jour mais nous a laissé un espace de travail
• A utilisé un tableau blanc avec deux colonnes, les personnes travaillant et ce sur quoi tout le monde pouvait regarder ce tableau et voir si quelque chose avait été fait ou était en train d'être fait
• Est-ce que tout le monde s'est entraîné? J'ai appris rcs puis cvs et comment utiliser make files
• Ran productif & post; post mortum " quand une tâche a été complétée. Il poserait une question comme "aurait-il été utile si X?" ou "la prochaine fois, pouvons-nous essayer de ..."
• Nous avons gardé tout le monde sur des tâches courtes et géré notre temps afin que nous travaillions toujours sur quelque chose, mais nous n'avions jamais accumulé une tonne de choses

Mike a tout fait sur le papier. Il gardait des cahiers et des fiches avec lui. Il a insisté pour que tout ce qui lui était demandé par la direction soit converti en tâches gérables, souvent écrites sur des cartes de correspondance. Il a refusé à quiconque de travailler sur tout ce qui ne pouvait pas être expliqué clairement ou qui avait un objectif clair. Il demanderait aux vice-présidents "Qu'est-ce que vous entendez par plus rapide?" "Quels types de métriques les rapports sont-ils censés afficher?" "Pourquoi cela devrait-il être une priorité?" Il semblait avoir une patience quasi infinie pour écrire ce qui devait être fait et ce que l’on entendait par "fait"

Lorsque j'ai lu le livre XP pour la première fois, j'ai été étonné de constater à quel point «le mode de travail de Mike» était connu de tous.

Il semble qu'Agile consiste simplement à mettre en œuvre un ensemble de meilleures pratiques et à évaluer leur fonctionnement dans votre environnement. Quand ils ne travaillent pas, changez-les. Quand ils travaillent, respectez-les.

Je pense que le vrai problème de la gestion de projet traditionnelle est qu’elle n’existe pas vraiment. Je suis étonné du nombre de magasins qui prétendent utiliser RUP, Code Complete ou même Agile et qui n’ont en réalité rien de reconnaissable en gestion de projet. Bien sûr, il y a des réunions. Et des gens appelés chefs de projet. Mais posez une question simple, telle que "Qu'est-ce qui a été fait sur le projet X"? ou "que reste-t-il à faire sur le projet Y" et personne n'a de réponse. Ils doivent creuser des e-mails ou pointer vers un fichier de projet MS comiquement inexact.

Si une personne affirme avoir une diète et ne peut pas répondre aux questions sur ce qu’elle mange ou comment elle fait de l’exercice; Accepteriez-vous qu'ils étaient vraiment au régime?

Answer 2

Vous emportez votre ancien bagage avec vous lorsque vous partez. Cela signifie que toutes les mauvaises pratiques de gestion de projet que vous avez eues avant vont persister.

Cependant, je dirai que les choses se sont grandement améliorées lorsque nous avons commencé à boucler la boucle entre nous et le client. Des retours et des prototypes plus nombreux et plus fréquents avec le client signifient bien moins de choses de la part du client: "Ce n’est pas ce que je voulais."

Answer 3

J'ai déjà utilisé Scrum (légèrement modifié) au travail et voici ce que je pense:

• Les réunions quotidiennes et l’allègement sur le lieu de travail ont fourni la motivation nécessaire pour faire avancer les tâches.
• Notre responsable pourrait parler à des collègues de l'autre côté de l'étang et leur montrer "c'est ce sur quoi nous travaillons ce mois-ci."
• Vous saviez exactement quelles tâches vous deviez accomplir et vous aviez déjà estimé le temps requis pour le terminer.
• Lorsque les priorités changeaient (nouvelles tâches, bogues importants ajoutés), il existait un processus bien défini pour gérer leur ajout au sprint ou tout simplement les transférer dans l'arriéré.

Answer 4

Ce sont de belles réponses, mais je pense que tout le monde confond la gestion de projet avec les méthodologies de développement / conception.

Answer 5

Je fais partie d'une équipe qui a démarré Scrum il y a quelques mois et nous semblons accomplir nos tâches plus rapidement et avec beaucoup moins de "gaspillage". (projets mis au rebut). Juste mes observations de notre petite équipe (4 développeurs).

Answer 6

J'ai trouvé le changement général vers les pratiques Agile / XP très positif. À bien des égards, il introduit de la qualité dans le processus de projet / développement. Vous aurez besoin de l’assentiment de la direction et de l’équipe pour vraiment voir le succès ... quelques suggestions:

• testez tout changement avec un petit projet (2-3 personnes)
• comprenez les domaines que votre équipe actuelle peut le plus améliorer (qualité? productivité? délais de mise sur le marché?) et incorporez quelques processus Agile / XP / Scrum (quels qu'ils soient) dans ... ne les incorporez pas tous dans en même temps et comprendre quels processus traitent quels problèmes avant toute modification
• si possible - suivez les domaines que vous souhaitez modifier et comparez-les à un autre projet exécuté simultanément (le simple objectif d'améliorer quelque chose suffit souvent à l'améliorer, il existe une étude / terme pour cela, mais j'oublie ce que c'est)
• parfois, vous constatez un creux de performance lorsque vous démarrez un nouveau processus, cela fait partie de la courbe d'apprentissage
• Ne présumez jamais qu'un bon changement aujourd'hui restera un bon changement pour demain, examinez toujours les domaines de votre projet et soyez prêt à changer tout processus à tout moment
• aucun changement ne reste valable pour toujours, tout comme le code de refactoring, refactorisez vos processus
• assurez-vous d'obtenir l'adhésion de l'équipe et de la direction, vous ne pouvez pas forcer le succès

Answer 7

J'aime certaines des choses que font les approches agiles, mais j'apprécie aussi certaines des choses que font les approches traditionnelles.

Les deux peuvent fonctionner, de même qu'une combinaison des deux, ce qui, à mon avis, convient le mieux à mon équipe. J'ai mis en place un développement incrémental et cela nous aide vraiment. Le développement itératif est un peu plus difficile et nous y travaillons encore. Cependant, nous avons une variété d'électeurs, et beaucoup de nos parties prenantes (et de nos ministres) préfèrent les artefacts et les jalons traditionnels. Nous devons donc continuer à chercher le bon équilibre.

J'ai également constaté que les personnes qui la mettent en œuvre sont encore plus importantes que la méthodologie. Les bonnes personnes trouvent le moyen de faire du bon travail et de faire avancer les choses quelle que soit la méthodologie employée, bien que celle-ci puisse avoir des effets sur l'efficacité (et le moral :)). Cependant, des ressources mal alignées peuvent utiliser la meilleure méthodologie et trouver des moyens d’obtenir des résultats médiocres.

Answer 8

Pour les développeurs, les grandes leçons de XP & amp; Cie sont des cycles de publication plus courts et une approche plus évolutive - en ce sens que le changement des exigences est accepté comme une partie naturelle de tout projet. En outre, les clients proposent des solutions, mais les concepteurs et les développeurs doivent comprendre les problèmes.

Leçons pour les responsables: Les développeurs ne sont pas des convertisseurs de spécifications en codes échangeables. Leurs forces et leurs faiblesses peuvent faire une différence de productivité de 10 ou plus pour un sujet donné. Les connaissances et l'expérience sont les compétences les plus précieuses de votre équipe, et les développeurs peuvent enseigner à chaque oterh. Les gestionnaires ne doivent pas comprendre ce que les développeurs font pour appliquer les résultats souhaités.

XP & amp; Les entreprises combinent généralement des solutions à ces problèmes avec le problème de faire changer une entreprise . Le consultant héroïque de XP économisant à lui seul un projet condamné, retardé et déraillé joue le rôle de tampon entre développement et gestion. Mais si vous cherchez quoi apprendre, vous devez séparer ces aspects.

Ce que j’ai appris ces dernières années, c’est que les bugs ne sont pas un défaut de personnalité et que le ciel ne tombe pas lorsque les spécifications changent. J'ai appris que, même si les erreurs de conception restent les plus coûteuses, il n'y a pas une seule solution "parfaite". conception. Au lieu d’obtenir une bonne chose, nous devons mettre en œuvre des mesures de protection: aucun des nombreux détails ne va mal, et j’ai appris à utiliser la marge de manœuvre entre "bonne" et "bonne". et "pas mal" à notre avantage.

Answer 9

Selon mon expérience, je préfère utiliser Scrum par rapport aux approches traditionnelles, car il n’est pas souvent arrivé que les exigences restent inchangées pendant toute la durée d’un projet, où les projets semblent durer au moins six mois. sur un an.

Il peut aussi arriver qu'il n'y ait pas de gestion de projet et que tout le monde se démène pour "le faire fonctionner". Donc, avoir une structure formelle est bon pour rien. Il y a quelque chose dans la question de savoir comment l'équipe se rassemble et les egos apparaissent rarement car ce n'est pas le code de quelqu'un mais le code de l'équipe et il y a une sorte de groupe qui pense que quand chaque personne a son opinion, personne essaie de faire en sorte que tout le monde voit les choses de cette façon.

Parfois, il me semble que certaines approches Scrum et Agile que j'ai utilisées finissent par ressembler à des rapides plutôt qu’à une grande cascade. Ce que je veux dire, c'est que le cycle de collecte des exigences - Analyse et conception - Implémentation - Test - Déployer et obtenir les exigences mises à jour semble se répéter encore et encore, de sorte qu'il soit extrêmement difficile de définir ce qui en ressort au début du processus. projet à moins que le parrain du projet ne puisse donner des exigences très détaillées qui ne changeraient jamais.