La mesure de l'intelligence est
la capacité de changer.
Albert Einstein
Préface
Je présente "Reflections on Agile" à la communauté informatique, ou cet article peut-il être intitulé "Agile, est-ce encore une philosophie ou une méthodologie de conception?"
Le but de cet article est de discuter avec la communauté informatique de la question d'Agile que j'ai eue après de nombreuses années de pratique de projet, des conclusions et du résumé que j'ai dégagés sur la base de l'analyse de cette question.
La Question elle-même est citée un peu plus bas, car pour y procéder, il est logique de formuler quelques arguments et conclusions.
Des sujets similaires ont déjà été soulevés sur Habré dans divers fils de discussion, donc la question est urgente et a sa propre histoire.
À mon avis, la plupart des articles ne donnent pas de réponse sans équivoque à ma question, donc cet article peut intéresser beaucoup de gens.
Plusieurs articles sur Habré sur le sujet:
En bref sur le sujet
Pour préciser un peu où le "vent souffle", je note que mon expérience dans le domaine des TIC est de plus de 10 ans. Au tout début de sa carrière, il a travaillé activement dans les télécommunications, je travaille dans le développement de logiciels relativement récemment, pas plus de quatre ans.
Tout au long de sa carrière, il a participé à divers projets informatiques et télécoms, en tant que chef de projet, ces dernières années, il a également été analyste d'affaires et s'est essayé en tant que programmeur. À la suite d'une immersion brève mais volumineuse dans le développement Java, il n'a pas acquis une grande expérience, mais néanmoins, dans le développement indépendant, pompant des compétences techniques en tant que programmeur junior.
Maintenant, je travaille activement dans le domaine du développement logiciel en tant que chef de projet, agissant éventuellement en tant que Business Analytics.
Ainsi, le sujet de discussion de cet article est la pratique de la gestion de projet pour le développement de produits logiciels, par ailleurs, en relation avec le développement domestique.
Comprendre la question de l'auteur
Au cours de son expérience de projet dans les TIC, il est venu avec une règle clé: gérer un projet en utilisant la méthodologie du projet est bon, ce n'est pas clair sans méthodologie.
Dans le cadre de ce qui précède, il est apparu nécessaire d'étudier diverses méthodologies de conception, les méthodologies ITSM, divers livres commerciaux sur le sujet, et simplement des livres «intelligents» et complexes.
Compte tenu de la popularité du PMI en général et de mon industrie des télécommunications natale en particulier, j'ai commencé à étudier avec PMBoK. Bien que ce Talmud délicat n'ait pas été immédiatement compris, plus d'une fois en lisant le chapitre suivant, j'ai dû penser à ce que fumaient tous les mêmes compilateurs du livre. En conséquence, l'ensemble des connaissances a été décomposé en atomes et adopté en totalité. Soit dit en passant, il n'est même pas une fois mis en œuvre dans un certain nombre de projets avec «zèle prolétarien», patience et agilité (pas PMBoK bien sûr, mais ses outils ont été introduits).
Comprendre PMBoK vient avec l'expérience.
@PM
En plus de ce travail «épique», d'autres méthodologies ont été étudiées et étudiées, il y avait simplement des auteurs de livres sur la gestion de projet (bien que des personnalités telles que T. Demarco, S. Berkun, S McConnell ne soient pas seulement des auteurs, mais quelque chose de plus), pas tous cela a du sens, et l'article ne traite pas de cela.
Pour résumer, l'auteur de l'article sur le sujet, tente de suivre les tendances mondiales, n'oublie pas les classiques.
Plongée dans la gestion de projet de logiciels
Lassé des télécoms après huit ans de travail et décidant d'aller de l'avant, il se précipita dans l'informatique.
Il s'est avéré que le secteur informatique ne veut pas vivre dans un cadre clair de «cascades» classiques, GOST 34 n'est pas à la mode, à moins bien sûr que l'État ne soit pris en compte. secteur. Il existe d'autres tendances dans la gestion de projet dans la gestion de projet globale.
Le manifeste agile ne pouvait pas passer. Après avoir étudié un certain nombre de livres et parlé avec plusieurs collègues, j'ai décidé que Agile est, au moins, intéressant. Mais il n'est pas tout à fait clair comment travailler avec cela en Russie, la philosophie n'atteint pas la méthodologie, et dans notre pays il y a une sagesse populaire «ce qui n'est pas interdit est permis».
En résumé: je suis arrivé à la conclusion qu'Agile est certainement une chose intéressante, mais néanmoins, elle convient mieux aux livres de mode et aux petits projets, mais la façon de la mettre en pratique n'est pas claire.
L'analyse des articles sur Habré, en général, a confirmé le bref résumé donné ci-dessus.Après plusieurs itérations d'apprentissage de l'Agile à partir de livres, j'ai eu de la «chance», il m'est arrivé de participer à plusieurs projets Agile nationaux.
Ce n'était pas du tout amusant d'un tel Agile, et un RP avec une expérience dans la planification et la gestion de projets de l'industrie des télécommunications était tout simplement triste. Quand on essaie de prendre le contrôle du développement spontané de tels camarades, tout se casse complètement, et les gars disent à l'unisson: "Nous sommes créatifs, nous avons Agile, ne vous embêtez pas à vivre / travailler / se développer". Ils ne veulent pas apprendre et penser, ils ont seulement Agile dans leur tête.
Mais malgré mon scepticisme, Agile a parcouru le pays, il a été activement promu par G. Gref et professé par divers gourous de l'industrie informatique occidentale et nationale.
Mais, comme l'expérience personnelle l'a montré, Agile utilise tout à sa manière, avec notre mentalité, nous venons de créer «Agile en russe».
En conséquence, la question a grandi et s'est renforcée, et personne n'a pu y répondre.
Qu'est-ce que cet Agile tout de même, une pile philosophique d'idées sur la psychologie et l'organisation du travail, l'extravagance de la raison, et non un désir de travailler selon les règles, ou cache-t-il encore quelque chose de plus sérieux d'un point de vue méthodologique, quelque chose qui peut être appliqué ici patrie, sur des projets sérieux, qu'est-ce qui mérite attention?Avant de terminer cette section, il y a plusieurs points à noter:
- Après la sortie de la 6e édition de PMBoK en 2018, la question d'Agile est devenue encore plus intéressante (dans la 6e édition, les auteurs ont inclus des cas utilisant Agile).
- Pour la lecture, j'ai lu le livre de Lawrence Leach, «On Time and Within the Budget».
Lawrence Leach Book, «On Time and On Budget»
Ouvrage intéressant sur la gestion de projet utilisant la méthode de la «chaîne critique», l'auteur peut être attribué aux idéologues de la gestion lourde. Le livre de L. Lich décrit une approche difficile mais extrêmement intéressante de l'application des théories d'E. Deming et d'E. Goldratt dans la planification de projet.Compte tenu des connaissances théoriques et pratiques acquises, la compréhension de l'incomplétude dans la compréhension de l'Agile en tant que méthodologie pour sa mise en œuvre adéquate dans les projets nationaux se développait.
Fin de partie
Le bon PMBoK agile ou adaptatif de Mike Cohn.Tout à fait par accident, ou comme on dit, "soudainement sorti de nulle part", je suis tombé sur un autre livre sur Agile. Il s'agit d'un livre écrit par un certain Mike Cohn (Cohn Mike) intitulé «Agile. Évaluation et planification de projet. ”
Au début, il a suggéré qu'il s'agissait d'un autre livre commercial décrivant qu'Agile était cool, à la mode, jeune.
Il en fut ainsi et décida de lire l'introduction, mais en lisant le premier chapitre, il devint intéressant de savoir qui il était, ce Mike Cohn, et pourquoi il écrivait de si bonnes choses.
Référence rapide Qui est Cohn Mike
Fondateur de Mountain Goat Software, une société de conseil en gestion de processus et de projets. Il se spécialise dans l'aide aux entreprises pour mettre en œuvre une approche agile afin d'augmenter l'efficacité. Derrière Mike, c'est plus de 20 ans d'expérience en tant que manager dans des organisations de différentes tailles, des startups aux sociétés Fortune 40. Il est co-fondateur d'Agile Alliance et membre de son conseil d'administration.Je ne prévois pas de décrire le livre dans son intégralité dans cet article, car il vaut mieux le lire à ceux eux-mêmes (ceux qui en ont besoin), mais je vais indiquer l'essentiel, le livre de Mike est un PMI PMBoK révisé prenant en compte la philosophie du manifeste Agile.
Je noterai immédiatement que Mike n'a pas écrit un autre ensemble de connaissances, ennuyeux et incompréhensible, il n'a pas copié PMBoK. Au lieu de cela, Mike Cohn a créé un livre intéressant, facile à lire et pertinent:
- Décrit les principes et les règles qui devraient être en Agile;
- Outils décrits pour planifier et évaluer le travail;
- A donné une idée et une gestion du développement compétente;
- Et bien plus.
Le livre décrit l'ensemble du cycle de vie du projet, se concentre sur la phase de planification du projet, décrit des méthodes et des approches très intéressantes et solides pour la planification et l'évaluation du travail, et décrit les approches et les outils pour les étapes du projet, le suivi et le contrôle.
Malgré le fait que le livre m'ait étonné par sa fonctionnalité, son applicabilité et sa maturité méthodologique, Mike a également appliqué une méthode extrêmement intéressante et difficile à décrire pour atténuer les risques d'incertitude, que Lawrence Leach décrit dans son livre. Avec tout ce qui précède, Mike propose dans un langage simple et compréhensible comment implémenter et étendre cette méthode dans la pratique.
Pour construire n'importe quel processus, vous avez besoin de règles, de normes et de principes, Mike les a décrits pour nous.
Résumé
À mon avis, nous sommes confrontés à plusieurs questions intéressantes depuis 2001:
Avons-nous besoin d'une philosophie, d'une méthodologie Agile ou avons-nous suffisamment de principes?
Voulons-nous développer des logiciels de haute qualité de manière efficace et claire, ou allons-nous laisser cette prérogative choisie et continuer à «inventer un vélo»?
Le livre de Mike, à mon avis, définit les règles dont beaucoup veulent s'éloigner, mais l'expérience montre que les règles sont toujours nécessaires.
En plus de celui décrit ci-dessus, le livre de Mike donne des instructions méthodologiques claires (bien que quelqu'un n'aimera peut-être pas ce mot) sur la façon dont la gestion de projet logiciel Agile doit être construite.
En tout cas, tout sera comme ça sera avec nous, mais une chose est claire, les règles et les principes sont nécessaires dans tout, et ils sont en Agile.
Ces principes sont décrits et fixés, ils peuvent être étudiés, ils peuvent être utilisés.
Pour finaliser mon CV, je désignerai les personnes suivantes:
Ageli n'est pas en crise, Agile n'est pas un problème, Agile fonctionne.La seule question est de savoir si nous voulons étudier les règles et faire comme elles sont prescrites, ou si nous voulons continuer à travailler comme nous voulons.
Ne perdez jamais une sainte curiosité.
Albert EinsteinPSChers lecteurs, qui ont néanmoins lu l'article, je suis très intéressé par votre opinion et vos commentaires, ainsi que par des recommandations sur des livres similaires, comme le livre de Mike Cohn.