Analyse agile. Mythes et réalité

I Introduction

Le stand doit être déplacé! Il n'y a pas de saison, de sorte que quelques personnes ne font pas de shandarah.
Maintenant confondu avec les toilettes, puis avec une cabine de plage ...
(x / f Caractéristiques de la pêche nationale)

Fin d'année, résumer, remplir des questionnaires et autres guirlandes pré-vacances de fonctionnaires informatiques. Pour la énième fois, j’attire l’attention sur les questionnaires finaux des sociétés informatiques, conçus pour identifier les tendances dans les approches de développement de produits. Et à chaque fois, on ressent une sorte d'astuce lorsque vous répondez à des questions comme: «Vous utilisez toujours la méthode Waterfall (modèle cascade), ou vous (comme toute l'humanité avancée) pratiquez Agile (méthodologies flexibles).» Lorsque vous commencez à découvrir auprès de l'auteur de ce sondage, et ce qu'il comprend par Agile, ses explications ne cadrent pas très bien dans les grandes lignes du manifeste (Agile Manifesto). Il pense vraiment à de nombreux principes pour la première fois et ces mêmes principes le mettent directement au point mort. Mais après un peu de confusion, l'artillerie lourde avec justification en béton armé de notre position est utilisée: "Nous ne travaillons pas sur la cascade, donc Agile."

La thèse de la méthodologie flexible elle-même est tellement gutta-percha dans sa sonorité que beaucoup essaient de lui insérer quoi que ce soit, ou plutôt ce qui leur est le plus bénéfique. Progressivement, il est devenu un écran à la mode, qui peut couvrir toutes sortes de défauts et même de négligence, dans le processus de fabrication de produits informatiques, et en même temps, comme pour rester sur la crête de la vague, dans une tendance. Comme si nous ne sommes pas comme ça - mais une telle technique.

Ensemble, «frappons à nouveau l'analyse» sur le thème des méthodologies flexibles, essayons de trier les principaux artefacts et principes sur les étagères et de séparer le sens sacré qui était à l'origine défini dans ce concept de ce que les populistes négligents en font. Nous comparons également les approches d'Agile avec d'autres méthodes pour une compréhension plus précise de la ligne qui les sépare, ou vice versa - les combine. En même temps, essayons de découvrir où l'utilisation des principes Agiles est la plus appropriée et où elle n'est pas tout à fait appropriée?

II Contexte de l'émergence des techniques de développement de produits logiciels

L'histoire est comme une pâte de viande: il vaut mieux ne pas regarder comment elle est cuite.
Aldous Huxley

Par souci d'objectivité, plongeons-nous dans l'histoire et ressentons les circonstances qui ont formé le terrain sur lequel divers principes et méthodes de développement de produits logiciels, y compris flexibles, ont mûri.

1. Mythes et réalité sur la cascade

Comme déjà mentionné dans l'introduction, l'antagonisme (offrande sacrificielle) pour Agile (1) a été choisi la technique de la cascade, qui, dans sa forme pure, était pertinente au siècle dernier, à l'époque des cartes perforées et des lecteurs de bande, et a été présentée pour la première fois au monde dans un article de W.W. Royce ( WW Royce), publié en 1970.

Une telle comparaison aide sans aucun doute toute autre méthodologie à paraître fraîche et innovante par rapport à elle. Certains intervenants, pour plus de conviction, présentent le modèle Waterfall non pas comme un itératif, mais comme un flux de travail monolithique ponctuel, d'une phase successive: analyse des exigences, conception, mise en œuvre, test, intégration et support. J'ai été particulièrement touché par la phrase sur les méthodes de développement, qui a été observée dans l'article, jusqu'à la période Ajail: «Auparavant, les produits étaient fabriqués immédiatement dans leur ensemble. Pour ce faire, nous avons suivi la chaîne: idée → termes de référence → design → programmation → testing → release ». Excusez-moi, mais Royce a utilisé un modèle de développement itératif dans son approche. Simplifier l'idée de manière cynique n'est tout simplement plus éthique, d'autant plus qu'il n'y avait pas de vide entre Waterfall et Agile, mais une chaîne d'évolution assez longue.

Bien qu'en toute honnêteté, je dois admettre que la plupart de ce qui a été dit à propos de Waterfall, en général, n'est pas loin de la vérité. Si l'équipe s'est rendu compte à un moment donné que le résultat ne répondait pas aux attentes, alors elle a soit «terminé» le produit qui n'était pas tout à fait correct, soit jeté la majeure partie du travail dans le panier et a commencé le processus presque depuis le tout début, créant en fait un nouveau produit. Pourquoi, malgré une certaine absurdité par rapport aux normes actuelles d'une telle approche, la technique est depuis longtemps restée un produit phare populaire dans le monde du développement logiciel?

Pour comprendre ce phénomène, nous allons plonger dans l'atmosphère des centres informatiques d'alors (CC). Permettez-moi de vous rappeler qu'en ces temps lointains et lointains, le chemin entre la conception des développeurs et l'exécution de son ordinateur a été long et épineux. Il a parcouru les dispositifs de préparation de données déjà oubliés qui effectuent le poinçonnage mécanique des cartes perforées et affectueusement appelés «barmales». Cette opération n'a pas été réalisée par les développeurs eux-mêmes, mais par des personnes spécialement formées. Ayant reçu le précieux paquet de boîtes en carton perforé, dans l'ordre de priorité, en tenant compte de l'opérabilité de l'ordinateur, ces cartes perforées ont été placées dans un appareil spécial (encore une fois, des personnes spécialement formées) qui lisent le code et seulement après cela, il a eu une chance d'être exécuté par le processeur. Mais si l'une des cartes perforées du jeu est coincée pendant la lecture, vous devez répéter la procédure pour lire à nouveau le jeu entier. Et à Dieu ne plaise, une erreur s'est manifestée dans le code, il a fallu recourir à nouveau à l'aide de «barmaley», pour interrompre une partie des cartes perforées et, sans les confondre avec des places dans le jeu, répéter à nouveau toute la procédure depuis le début. Avec de tels charmes, le travail des programmeurs d'alors était ponctué tout le temps. Naturellement, une évolution rapide des exigences du produit développé au cours de sa mise en œuvre, avec une telle approche, était hors de question. Les exigences de haute qualité pour le produit en cours de développement et le processus strictement réglementé de sa production étaient pour toutes les équipes.

2. Et si ce n'est pas une cascade?

Mais le temps a passé et tout a changé. Les ordinateurs personnels sont progressivement devenus la capsule du monde numérique, déplaçant d'énormes monstres cliquetis dans l'arrière-cour. Le nombre d'opérations effectuées par les processeurs par unité de temps a augmenté de plusieurs ordres de grandeur, et la vitesse de l'opération d'entrée / sortie des informations semble simplement «cosmique». Les programmeurs ont eu un accès direct et instantané à l'exécution du code qui vient d'être tapé à partir du clavier - les ressources informatiques, sans quitter l'endroit. Maintenant, il est devenu beaucoup plus facile d'apporter des modifications au logiciel, et imaginer déjà que quelqu'un d'autre continue de travailler selon la méthode Waterfall dans sa forme pure est tout simplement ridicule.

La sélection naturelle et le besoin d'adaptation ont forcé les techniques à muter. De plus, la plupart d'entre eux ont emprunté un modèle de développement itératif à leurs prédécesseurs. Simplement, les cycles d'exécution ont été considérablement réduits et améliorés.

Mais un autre malheur est survenu. Jusqu'à présent, des opportunités sans précédent ont permis, de l'automatisation de sections de production individuelles, à l'automatisation d'entreprises entières et même de balayer complètement l'industrie. Avec de tels volumes d'opérations et quantités de ressources impliquées, il n'a pas été possible de simplifier simplement les méthodes de développement logiciel. Au contraire, elles sont devenues encore plus radicales et formalisées.

L'une des techniques les plus connues utilisant un modèle de développement itératif est Rational Unified Process (RUP). Il a été développé et mis en œuvre dans la seconde moitié des années 90 chez Rational Software.

Le terme RUP cache non seulement une méthodologie de développement logiciel, mais également un ensemble d'outils qui vous permettent de gérer les processus de développement. Dans le cadre de ce sujet, il est particulièrement intéressant de noter que la méthodologie RUP (2) décrit un processus général abstrait sur la base duquel une organisation ou une équipe de projet peut créer son propre processus de développement logiciel unique, centré sur ses propres besoins. Comment dites-vous que cette approche n'est pas flexible?

Avec une analyse et des comparaisons plus approfondies, on peut noter que certaines des principales caractéristiques de RUP sont également en partie héritées de la technique de la cascade.

1. Approche cyclique de la production de logiciels . Le cycle de vie du projet RUP est divisé en 4 phases et 9 processus de travail.
2. Processus de développement itératif . Le projet RUP consiste en une séquence d'itérations d'une durée recommandée de 2 à 6 semaines.
3. Développement obligatoire des exigences . RUP utilise des cas d'utilisation ou des cas d'utilisation pour décrire les exigences. Chaque cas d'utilisation est une description du scénario d'interaction de l'utilisateur avec le système qui exécute entièrement une tâche utilisateur spécifique.
4. Une approche incrémentale visant à incrémenter progressivement la fonctionnalité du produit. L'unité principale de la planification des itérations est le cas d'utilisation, qui vous permet d'apporter les modifications nécessaires aux exigences, aux décisions de conception et à la mise en œuvre pendant le projet.

Nous accordons une attention particulière au dernier point. Il indique que c'est la présence d'exigences détaillées établies sous une forme spécifique qui permet simplement d'apporter des modifications efficaces aux décisions de conception et à la mise en œuvre du produit pendant le projet. Y compris dans les dernières étapes du projet.

RUP est souvent considéré à tort comme un processus lourd avec un haut niveau de formalisme. Mais ce n'est pas entièrement vrai, car le processus RUP peut (et devrait) être personnalisé en fonction des spécificités d'une organisation et d'un projet particuliers. Même si l'équipe prend en charge un petit logiciel qui devra être développé, mis à l'échelle ou intégré à d'autres systèmes, RUP lui permettra de faire face assez confortablement à tous les défis qui se présentent.

3. Le renversement des fondations

Et puis plus. Après avoir sauté la période de l'avènement des ordinateurs personnels dans notre monde, nous nous tournons vers l'apparition de toutes sortes de studios d'outils, d'outils de visualisation et de modélisation, de constructeurs d'applications automatiques, etc. Dans toute cette variété d'aides, qui, par exemple, vous permettent de glisser-déposer un élément sur le diagramme avec la souris et d'obtenir un code d'application automatiquement modifié pour le produit final, a commencé à dévaluer le rôle même des techniques de développement logiciel. Ayant de tels outils avancés, avec un manque de temps ou de ressources, vous pouvez abandonner certains workflows de la méthodologie et en même temps ne rien perdre. Du moins à court terme. Ces libertés et, comme il s'est avéré, l'impunité, avec le professionnalisme des interprètes, ont conduit les têtes les plus désespérées à proclamer une nouvelle tendance informatique - "Méthodologies de développement flexibles".

Ici, à cet endroit de la ligne rouge, je souligne une fois de plus une thèse très importante, peut-être la clé - «avec le professionnalisme voulu»! Autrement dit, des spécialistes de haut niveau, qui ont des dizaines de projets achevés à grande échelle, qui sont capables de dessiner le diagramme de classe d'un petit module dans leur tête en 20 minutes, estiment immédiatement les processus qui changent leur état, suggèrent des dépendances critiques, etc. ont décidé qu'ils pouvaient, dans certains cas, se passer de l'adoption obligatoire des règlements adoptés. Dans le même temps, le projet sera toujours porté au résultat escompté avec une qualité acceptable dans un délai nettement plus court. Est-ce bon ou mauvais? À première vue, c'est tout simplement merveilleux. Sur le second, tout n'est pas si simple. Nous analyserons les avantages et les inconvénients un peu plus tard.

Certainement mauvais en est un autre. Jeune et audacieux, en le regardant de côté, posez la question: "Mais quoi, était-ce possible?" Ils n'ont jamais vu d'exigences de qualité dans leurs yeux, ils ne peuvent pas lire les diagrammes, mais maintenant ils n'en ont plus besoin. C’est tout! les exigences sont maintenant annulées! Diagrammes, processus de modélisation - là dans le four. Uniquement code, code et communication. En prime - ils peuvent laisser leurs commentaires dans le code pour les générations futures du même impudent.

Sur ce point, l'excursion historique peut être complétée et déplacée pour ainsi dire plus près du corps ...

III Analyse du phénomène des méthodologies flexibles

Chaque entité doit être analysée en termes de logique avant de la coller dans votre bouche.
Woody Allen.

1. Définitions des méthodologies flexibles

Comme Adjayl existe depuis de nombreuses années, profitons des informations disponibles et commençons par passer en revue les définitions et les opinions qui dominent le réseau. Et après les avoir déjà repoussés, nous passerons à l'artefact principal - le Manifeste du développement logiciel flexible.

La première chose qui a été trouvée dans un moteur de recherche par le terme Agile:

La méthodologie de développement flexible (développement de logiciels agiles, méthodes agiles) est une série d'approches de développement de logiciels axées sur l'utilisation du développement itératif, la formation dynamique des exigences et la garantie de leur mise en œuvre grâce à une interaction constante au sein de groupes de travail auto-organisés composés de spécialistes de divers profils.

Les points importants suivants peuvent être distingués de cette définition:

1. Utiliser une approche itérative . Il n'y a rien de nouveau ici, je n'ai pas entendu parler de méthodes de développement logiciel qui nient ce principe;
2. La formation des exigences se fait par étapes, au cours du développement du produit . Il s'agit d'une différence essentielle par rapport à de nombreuses autres techniques. À certains égards, il donne un avantage, à certains égards, il introduit des limitations fondamentales. Nous discuterons plus tard des deux;
3. Utiliser l'interaction étroite et constante de tous les membres de l'équipe , y compris le client. La plupart des autres méthodologies, bien sûr, prêtent attention au travail d'équipe, y compris avec les clients, mais positionner cette communication comme une ressource de projet supplémentaire qui donne un avantage absolu est plus exclusif;
4. Équipe auto-organisée . On suppose que chaque itération se termine par un débriefing et un changement constructif dans le processus, ce qui contribue au développement continu de l'équipe. Des techniques similaires sont très probablement empruntées à des techniques antérieures. Par exemple, il pratique RUP.

En principe, nous n'avons pas réussi à trouver grand-chose dans cette description, alors passons aux clarifications:

La plupart des méthodologies flexibles visent à minimiser les risques en réduisant le développement à une série de cycles courts appelés itérations, qui durent généralement de deux à trois semaines. Chaque itération en elle-même ressemble à un projet logiciel en miniature et comprend toutes les tâches nécessaires pour produire un mini-gain de fonctionnalité: planification, analyse des exigences, conception, programmation, test et documentation.

Mais nous avons déjà envisagé la même approche dans le bon vieux RUP. Autrement dit, il n'y a rien de fondamentalement nouveau ici.

La plupart des définitions que j'ai trouvées sont également abstraites et vagues, il y a très peu d'informations qui vous permettent de prendre immédiatement et d'utiliser la flexibilité. Mais ici s'ouvre un autre aspect tout aussi important de l'approche, qui clarifie la superficialité à travers laquelle le sujet considéré traverse. Voici un exemple:

Agile n'inclut pas les pratiques, mais définit les valeurs et principes qui guident les équipes. Agile est une famille de processus de développement, pas la seule approche du développement logiciel, et est défini par Agile Manifesto.

Agile est une façon de penser avec son propre système de valeurs. Il est similaire à la philosophie, la religion ou la culture - le même ensemble d'attitudes auquel une personne croit et qui influence son comportement.

Apparemment, pour cette raison même, il existe d'innombrables différends concernant les méthodologies flexibles. Il n'y a pas grand-chose dans l'idée de ce que vous pouvez vraiment ressentir. Apparemment à cause de cela, vous pouvez appeler quelque chose de vos propres (presque toutes), méthodologies flexibles non conventionnelles et ne pas être pris dans un manque de professionnalisme. À mon avis, cela est acceptable, si vous voulez être dans la tendance, nommez votre approche du développement aussi à la mode que possible, si seulement le processus de développement et le produit final lui-même ne souffraient pas.

Je me souviens d'un cas de ma pratique lorsqu'une grande entreprise informatique, avant un nouveau projet à grande échelle, a décidé d'améliorer ses processus technologiques. Pour cela (selon les recommandations), un spécialiste des méthodologies flexibles a été invité, sur les épaules duquel cette mission responsable a été confiée. Après avoir lu une très courte conférence sur la façon de penser et le système de valeurs d'Agil, il a commencé à découvrir comment les choses se passent réellement avec la production de logiciels dans l'entreprise. À la recherche de défauts et d'incohérences dans les processus existants, en collaboration avec l'équipe de l'entreprise, nous avons sélectionné les moyens et les méthodes les plus appropriés pour les résoudre. Heureusement, ces lacunes n'étaient un secret pour personne et plusieurs raisons les ont empêchés de surmonter. Par exemple: manque de temps, contradictions entre équipes subordonnées à différentes verticales de management, peur de prendre des responsabilités, etc. Étant donné que tout cet événement a été parrainé par la direction de l'entreprise et que le spécialiste invité était un véritable informaticien de haut niveau, les innovations développées ont été mises en œuvre presque à temps et avec un effet positif très sensible. C'est juste pour le manifeste des méthodologies flexibles qu'ils n'avaient rien à voir.En conséquence, la plupart des employés de l’entreprise sont restés convaincus qu’ils sont désormais complètement passés à Agile, abandonnant tout le reste. Tout cela ressemble beaucoup à un conte de fées sur la façon dont un soldat cuisinait de la bouillie à partir d'une hache, retirant astucieusement les ingrédients dont il avait besoin des propriétaires et améliorant le goût du plat. C'est juste que la hache n'est pas bouillie.

Mais puisque nous sommes ici pour analyser de manière impartiale le phénomène Agile, nous allons donc poursuivre notre étude. Passons à la source d'origine - le manifeste Ajail:

2. Analysons les principales idées du Manifeste Agile

Idées clés:

1. Les gens et l'interaction sont plus importants que les processus et les outils;
2. Un produit fonctionnel est plus important qu'une documentation complète;
3. La collaboration avec le client est plus importante que la négociation des termes du contrat;
4. La volonté de changer est plus importante que de suivre le plan initial.

Commençons par une mouche dans la pommade. Pour moi personnellement, tous les points sont controversés. Allons dans l'ordre:

Point 1 . À mon avis, l'une des principales raisons de l'apparition d'Ajail, comme je l'ai écrit ci-dessus, était le développement rapide de systèmes d'automatisation pour les processus de développement de logiciels, ce qui a permis de négliger la réglementation. C'est-à-dire que c'est simplement l'éviction du travail humain monotone par des processus robotiques qui nous permet de produire des résultats plus fiables et prévisibles, y compris le maintien d'une interaction de haute qualité des processus eux-mêmes. Par conséquent, à propos de «Les gens - la chose la plus importante», à mon avis, ce n'est qu'un slogan aidant à amuser la vanité humaine des membres les plus sentimentaux de l'équipe.

Mais en toute honnêteté, je note que ces slogans, applaudissant rétrospectivement et autres sentiments sur les jeunes employés, sont tout à fait valables et même (au début) renforcent l'esprit d'équipe. Il est important qu'il n'y ait pas de vide et de déception lorsque la compréhension des vacances aura disparu.

Point 2. Le développement n'est qu'un court instant dans la vie d'un système automatisé, puis commence la dure vie quotidienne de son fonctionnement, de la modernisation et de l'expansion des opportunités. Avez-vous déjà essayé de maintenir un bon logiciel, complètement dépourvu de documentation? Que se passe-t-il et pourquoi exactement, et surtout, comment peut-il être corrigé afin qu'il commence à fonctionner un peu différemment? Et s'il interagit avec d'autres logiciels, qu'est-ce qui peut généralement y être modifié et qu'est-ce qui ne peut pas être touché? Tout cela ressemble à marcher sur un champ de mines.

Et nous ajoutons ici le principe du développement progressif. Sans documentation, car il sera toujours nécessaire de déterminer à quel stade de développement le produit est généralement localisé.

Mais dans un souci d'objectivité, il convient de noter que lorsqu'une équipe livre un produit fini à un client, assemblé à partir d'un tas de modules, installé sur un tas de divers équipements, et même sous une charge "non enfant", alors avec une forte probabilité, il peut être nécessaire de modifier ou de changer le code. Parfois, les changements peuvent être nombreux et profonds. Et ici, ce n'est définitivement pas du formalisme, il faut sauver le visage de l'équipe. Pendant cette période, vous pouvez reporter la documentation à un moment meilleur et modifier le code de toute urgence. Je tiens à noter qu'il est beaucoup plus pratique de le faire lorsqu'il existe une documentation décente, rédigée au stade du développement, avec une description de la façon dont tout fonctionnait au moment de l'introduction.

Point 3. Eh bien, pour commencer, le point ne comprend pas l'opposition même. Mais l'accord des termes du contrat n'est-il pas une collaboration avec le client? Si le client, grâce à la clarification des termes du contrat avec l'équipe de développement, est capable de comprendre la quantité de travail, de réaliser à peu près le coût de leur mise en œuvre, et surtout d'imaginer le résultat qu'il peut obtenir, dans certains indicateurs vraiment tangibles (fonctions commerciales automatisées, modèles de mise en page, etc. .). Après tout, il lui sera plus facile de prendre une décision: s'il a besoin de ce produit particulier, s'il est prêt à financer sa production, etc. N'est-ce pas une collaboration?

Mais qu'en est-il de la coopération? Juste des conversations chaleureuses pour la vie sans aucune obligation? Qu'on le veuille ou non, si le projet est commercial, toutes les parties doivent avant tout atteindre leurs objectifs dans le projet. Et les termes du contrat - il suffit de fixer ces objectifs et les moyens de les atteindre. Au moment de l'élaboration et de l'approbation du contrat, les deux parties commencent à réaliser qu'elles sont censées obtenir des partenaires et le degré de responsabilité en cas de non-atteinte du résultat convenu. Le contrat dans ce cas est un facteur de motivation et un moyen de résoudre les désaccords, pour les deux. Après tout, les plus terribles ne sont pas les extrêmes, mais l'incertitude.

Aucun contrat - aucune responsabilité, aucune compréhension complète de ce qui devrait résulter de l'achèvement du projet. Cette approche vous convient - bonne chance.

Point 4. Nous avons déjà dit plus haut que s'il existe des outils modernes de conception et de développement de logiciels, il n'y a pas de difficulté particulière pour une équipe de développeurs professionnels à apporter des modifications à l'implémentation d'un produit à presque toutes les étapes. Il s'agit d'un processus normal, qui dépend dans une plus large mesure de la profondeur de la compréhension de l'équipe, du produit qu'elle développe. Par conséquent, dans ce cas, la question n'est pas tant sur la volonté de l'équipe d'apporter des changements, mais sur qui paiera pour tous ces excès. C'est là que le contrat établi qualitativement apparaît, ce qui détermine qui et dans quels cas subit des pertes matérielles de la réforme. Que les développeurs refassent à leurs frais ce qu'ils ont mal compris ou le client qui n'a pas correctement expliqué ce dont il avait besoin.

3. Discutez des principes du Manifeste Agile

Puisque nous voulons avoir un esprit ouvert sur le sujet, abordons au moins brièvement les principes que le Manifeste Agile explique:

• la satisfaction des clients en raison de la fourniture précoce et ininterrompue de logiciels précieux;
• accueillir favorablement les modifications des exigences même en fin de développement (cela peut accroître la compétitivité du produit résultant);
• livraison fréquente de logiciels fonctionnels (tous les mois ou semaines ou plus souvent);
• une communication étroite et quotidienne du client avec les développeurs tout au long du projet;
• le projet est mené par des personnes motivées qui bénéficient des conditions de travail, du soutien et de la confiance nécessaires;
• La méthode recommandée pour transmettre des informations est une conversation personnelle (face à face);
• l'exécution de logiciels est la meilleure mesure des progrès;
• , ;
• ;
• — ;
• , ;
• . .

La plupart de ce qui précède ne contredit pas d'autres méthodes et est très conseillé.

Mais ces principes ne sont pas toujours vraiment utilisables dans la pratique. Par exemple, un client est loin d'être toujours en mesure de collaborer avec une équipe pour discuter de solutions. Il n'a souvent pas de temps, et parfois aucun désir particulier. Ensuite, vous avez besoin d'un pro - un analyste, capable de lignes concises, discrètement, ayant ancré dans la confiance et utilisant toutes ses «petites choses» psychologiques, pour en tirer des informations utiles et les peigner en douceur, en douceur, pour les transmettre à l'équipe de développement sous la forme la plus appropriée pour la mise en œuvre. C'est intéressant si cela se produit, le travail de l'équipe n'est plus considéré comme flexible?

Pour la même raison, il n'est pas toujours possible d'organiser des livraisons fréquentes. Et ce processus peut être sérieusement affecté par un certain nombre de modules intégrables développés par différentes équipes, qui peuvent être assemblés (modules) en même temps, sur le même équipement, ce qui est très problématique. Oui, et pour un équipement spécifique, il arrive qu'il soit livré directement au plus près de la livraison. Cela doit également être pris en compte.

Et il y a une discorde dans la déclaration sur «les meilleures exigences techniques, design et architecture» malgré le fait que les principes d'Agile, en principe, n'accueillent pas la documentation et tout ce jazz. Si vous «offensez» une approche formelle de la documentation, il est peu probable qu'elle se révèle être la meilleure (sagesse populaire).

De plus, de mon point de vue, cela soulève un grief - élevant au rang de la meilleure méthode de transmission de l'information - «conversation personnelle (face à face)». À mon avis, la transmission d'informations dans un projet est beaucoup plus efficace, par exemple, en utilisant un tracker de tâches ou un système wiki, sans, bien sûr, exclure la communication personnelle.

IV Application des méthodologies agiles

En innovation, vous devez être à la fois têtu et flexible.
Si vous n'êtes pas têtu, vous refuserez d'expérimenter trop tôt.
Si vous n'êtes pas flexible, vous vous cognerez la tête contre le mur et vous ne verrez pas d'autre solution au problème que vous essayez de résoudre.
Jeffrey Preston

Si tant d'évaluations critiques sont survenues pendant l'examen, comment tout cela fonctionne-t-il?
Le succès d'Agile contribue apparemment à l'efficacité de l'utilisation de la méthodologie dans les petits projets et à la similitude (simultanéité) de l'utilisation de tous les éléments ci-dessus.

1. Avantages d'utiliser Agile

Grâce à l'utilisation des User Stories, l'équipe de développement est en mesure d'atteindre le niveau de compréhension nécessaire lors des discussions avec le client. Pour le client, le seuil de saisie du sujet est réduit, il lui est plus facile d'opérer avec le contenu du projet, de fixer des priorités, de corriger des inexactitudes, etc. De plus, même les chefs de projet, de produit et d'autres chefs d'équipe qui connaissent très bien les spécifications des exigences basées sur des histoires d'utilisateurs simples ont la possibilité de jongler beaucoup plus facilement avec les tâches d'un projet et de comprendre les attentes des clients.

En raison de la fourniture fréquente de prototypes, il est possible d'éviter de grandes disparités entre les attentes du client et les options offertes par les exécutants des solutions. À chaque nouvelle version, de plus en plus les rapprochent les uns des autres. Les prélèvements dans le temps d'exécution et, par conséquent, les pertes financières ne sont pas non plus importants et prévisibles, ils peuvent être intégrés directement dans le plan de projet.

Cela ressemble à ceci: le client s'attend à recevoir de nouvelles fonctionnalités, dont il ne représente pas pleinement les capacités. Il y a une «coopération étroite», à la suite de laquelle le contractant propose une solution pilote qui, en règle générale, ne répond pas complètement aux attentes du client, dont l'équipe est informée. Cet épisode encourage une nouvelle «coopération étroite», à la suite de laquelle l'entrepreneur effectue des ajustements au prototype et présente à nouveau le produit au client. Et donc dans un cercle jusqu'à ce qu'une certaine fonctionnalité gagne pleinement l'esprit du client, ou jusqu'à ce qu'elle devienne si «encombrée» en coopération qu'il ne sera pas confortable de rester en elle. Si la complexité du produit et le nombre de fonctions automatisées vous permettent d'effectuer 3-6 de ces cycles pour le bonheur complet et inconditionnel du client, alors pourquoi pas,régime tout à fait réalisable.

La seule chose sur laquelle je veux me concentrer est un point fondamental qui passe souvent sans attention - la nécessité de fixer dans les documents (au moins après coup), dont la solution technique a été obtenue à la suite d'essais et d'erreurs. Cela est important à la fois pour le client, qui peut ensuite embaucher une nouvelle équipe pour finaliser ou faire évoluer le produit, et pour l'équipe elle-même, qui, d'une part, sera en mesure de reproduire la solution ou ses composants, et d'autre part, s'il est recruté pour mettre à niveau le produit, il sera en mesure de plus rapide et mieux pour rejoindre le processus.

2. Petits projets - un environnement confortable pour Agile

Pour les petits projets, l'utilisation d'histoires utilisateur, au lieu des exigences complètes pour le produit développé, nous permet de simplifier et de rendre la communication plus confortable avec le client. En raison de l'interaction fréquente avec le client et de la simplicité de la forme de communication, l'équipe ne se lave pas, le patinage développe donc des exigences acceptables pour la fonctionnalité du produit. En l'absence d'algorithmes complexes et d'intégration avec d'autres logiciels, cela peut se produire sans trop de pertes. Niveau de domaine du problème - fermer les User stories et domaine de la solution - commentaires dans le code.

En utilisant une équipe de professionnels, vous ne pouvez pas vous embêter à élaborer l'architecture de la solution et les spécifications des exigences du produit. Quelque chose comme l'équipe ou ses membres a sûrement déjà décidé et ils ont derrière eux les modèles appropriés et les meilleures pratiques.

Si ce produit est unique et qu'il n'est pas prévu de le développer, cela suffit.

3. Comment utiliser Agile dans des projets de taille moyenne

L'utilisation d'Agile dans des projets de taille moyenne peut également être très efficace.

Dans les projets plus importants, une variété de plates-formes d'automatisation peuvent être utilisées, équipées de modèles prêts à l'emploi, de meilleures pratiques, d'outils d'auto-documentation, etc. Cela simplifie considérablement les processus formels, notamment la conception, la modélisation et la documentation. Les solutions présentées dans de tels cas sont le plus souvent dupliquées, avec un nombre limité d'améliorations et de changements.

Le plus grand effet peut être obtenu si des décisions similaires antérieures sont documentées. Sur cette base, vous pouvez consacrer plus de temps non pas à la conception et à la modélisation, mais à la sélection, avec le client, du prototype souhaité. «Essayez-le, mettez-le et c'est parti. N'appuyez pas? ". Il est important que les nouvelles solutions mises en œuvre soient également bien documentées. Dans ce cas, l'équipe reçoit un ensemble de blocs et des instructions pour l'assemblage de divers modèles, qui peuvent être proposés aux futurs clients.

, , Agile , , ( ). , , , .

4. Comment utiliser efficacement Agile dans les grands projets d'intégration

Dans les projets grands et complexes, dans lesquels une documentation de haute qualité est maintenue, il y a une idée architecturale du produit et du processus de sa production, des "pièces" du produit peuvent être externalisées à de petites équipes. Ce transfert intervient après une étude détaillée de l'architecture générale et la préparation d'exigences de haut niveau pour de nouveaux sous-systèmes. Et maintenant, ces pièces relativement petites peuvent être implémentées de manière assez efficace à l'aide d'Agile.

Le même schéma est applicable pour les petites améliorations ou le développement progressif d'un grand système complexe, surtout si vous devez effectuer des travaux de recherche.

Une autre option pour utiliser Agile dans les grands projets peut être appliquée efficacement en cas de livraison d'urgence du produit au client. Compte tenu du manque critique de temps et de ressources pour son raffinement et sa correction, c'est précisément la flexibilité de l'approche qui peut aider à éviter un fiasco. Dans de telles situations, à mon avis, cette méthodologie particulière est optimale.

Dans cette section, il convient de mentionner les méthodes existantes basées sur Agile, mais gravitant vers la résolution de problèmes à grande échelle.

Le processus unifié agile (AUP) est une version simplifiée du processus unifié (UP) développé par Scott Ambler. Cette méthodologie de développement logiciel combine des éléments de méthodologies flexibles et un processus unifié. En particulier, l'AUP implique le développement par le biais de tests (TDD), l'utilisation de la modélisation flexible (modélisation Agile anglaise) et le refactoring de base de données, la gestion flexible du changement.

OpenUP est une méthode de développement logiciel incrémentielle itérative. Positionné comme une version légère et flexible de RUP. OpenUP divise le cycle de vie du projet en quatre phases: la phase initiale, les phases de raffinement, de conception et de transfert. Le cycle de vie du projet garantit que les parties prenantes et les membres de l'équipe disposent de points de familiarisation et de prise de décision tout au long du projet. Cela vous permet de surveiller efficacement la situation et de prendre des décisions opportunes sur l'acceptabilité des résultats. Le plan de projet définit le cycle de vie et le résultat final est l'application finale.

5. Comment ne pas utiliser Agile

Une section tout aussi importante, peut-être au nom de laquelle toute l'analyse a été envisagée.

1. Le leader de mon anti-rating est la situation où ils essaient d'utiliser Agile, ou plutôt certains de ses principes, non pour atteindre des objectifs spécifiques qu'ils peuvent atteindre, mais simplement #CRAFT. Parce que c'est une tendance, elle est sur toutes les lèvres. Par exemple, quelqu'un a partagé des critiques positives lors de la soirée IT, un peu éphémères et même arrogantes, mais il y avait une rumeur, un entourage est apparu. Et maintenant, ils se sont déjà appelés adeptes d'Agile, ils se sentent en communication avec les autres - appartenant à un certain club d'élite. Tout cela contribue à l'apparente simplicité de la méthodologie et aux contours flous de ses frontières. Les implémentations sur ce principe se produisent sans réfléchir et formellement. Les gens appliquent formellement et sans principes des principes conçus pour réduire le formalisme.
   
   Par exemple, l'un des cas les plus récents. Dans une entreprise, effectuant des rétrospectives, elles ont été interdites par les Timlids. Voici une telle puce. De façon inattendue. Première pensée: eh bien, peut-être qu'ils ont raison pour qu'il n'y ait pas de pression des autorités sur l'équipe lors de la discussion des problèmes, etc. Mais les Timlids sont offensés, ils sont perdus et veulent le comprendre. J'ai essayé de convaincre qu'ils disent que cela pourrait être mieux, l'essentiel est que vous obteniez une liste de souhaits, avec une liste de ce qui doit être changé, de ce qui doit être amélioré, etc. Et ici, un terrible secret a été révélé. Et aucun résultat et aucun souhait d'améliorer les processus à la suite de ces rassemblements ne surviennent. Messieurs IT_shniki, et pourquoi alors une telle rétrospective? Louez-vous simplement et renforcez l'esprit d'équipe? A, disons et B. ont dit. Après tout, l'objectif principal de ce processus de méthodologie est que: "L'équipe devrait systématiquement analyser les moyens possibles d'améliorer l'efficacité et d'ajuster en conséquence le style de leur travail."
2. La deuxième situation dans mon classement est lorsque les équipes décident d'économiser sur la préparation des exigences dans des projets avec des algorithmes comportementaux ou logiques complexes. Autrement dit, lorsque la user story n'est qu'une petite partie de l'iceberg du problème, et que sa partie principale n'est pas visible et nécessite une analyse et une conception détaillées et approfondies pour la mise en œuvre. Que se passe-t-il avec ça?
   
   Avant de commencer à travailler, ni le client ni les développeurs ne comprennent même approximativement la quantité de travail à effectuer. Et en conséquence: soit le client paiera, paiera et paiera, chaque fois qu'il lui expliquera que tout s'est avéré beaucoup plus difficile et que maintenant le travail n'est toujours pas terminé. Et après tout, il sera dommage d'arrêter et commencera progressivement à ronger la sévère compréhension que ce produit "doré" ne sera jamais payant. Soit les développeurs, ayant accepté de terminer le travail pour un certain temps / temps, termineront et refont le produit (gratuitement) à leurs frais jusqu'à ce que le client manque d'imagination, soit il aura pitié des victimes d'une approche flexible.
3. Une troisième place honorable est occupée par la situation où, dans un grand projet multifonctionnel (et soudain aussi un projet d'intégration), l'équipe décide d'économiser sur l'élaboration de l' architecture de la solution et commence à mettre en œuvre des user stories individuelles en de courtes itérations. Avec un haut degré de probabilité, il arrivera qu'après 3 à 5 itérations, lors de la tentative de création d'une nouvelle fonction, il s'avère que vous devez refaire l'intégralité de la précédente, car les principes fondamentaux sur lesquels cette fonction aurait dû être basée n'ont pas été pris en compte. Pire encore, si après la 10ème itération on constate que les technologies sélectionnées ne permettent pas de satisfaire tous les besoins du client et il faut tout recommencer. Peut-être en changeant la commande.
4. La situation dans laquelle une startup pointue et incroyablement flexible pénètre dans les espaces ouverts d'un segment de marché atone n'est pas tombée dans le top trois. Une start-up, c'est aussi une startup, qui n'a pas de fondations, de liens, d'attachements, et en même temps de stabilité et de stabilité. Et tout simplement, il n'y a presque pas de documentation, l'équipe n'est pas harmonieuse et change souvent. Le marché déchire littéralement l'équipe, exigeant de plus en plus de nouvelles solutions dans le domaine jalonné, et tous les projets ultérieurs s'effondrent simplement sous nos yeux. Le plus souvent, cela s'explique par le fait que l'équipe ne comprend pas les processus de production de logiciels industriels , l'organisation de la livraison et le support produit.

Pour résumer

En préparant cet article, j'ai essayé d'aider les équipes intéressées par l'approche Agile à mettre en évidence et formaliser les défis auxquels elles devraient faire face d'une manière ou d'une autre, ainsi qu'à trouver des solutions possibles pour les surmonter. J'ai essayé de considérer le sujet aussi tolérant que possible, à la fois pour les apologistes pour l'introduction d'une ou plusieurs méthodologies de ce groupe, et pour les opposants qui veulent démystifier le halo de flexibilité et refusent raisonnablement de l'utiliser.

J'espère que l'analyse aidera les équipes utilisant d'autres méthodologies à tirer parti de l'approche Agile si nécessaire.