Le livre «Pure Agile. Les bases de la flexibilité

Bonjour, habrozhiteli! Nous avons remis à l'imprimerie une autre nouveauté! Près de vingt ans se sont écoulés depuis l'apparition du Manifeste Agile. Le légendaire Robert Martin (oncle Bob) s'est rendu compte qu'il était temps de se débarrasser de la poussière des principes d'Agile et de parler de l'approche flexible non seulement à la nouvelle génération de programmeurs, mais aussi aux spécialistes d'autres industries. L'auteur des livres «Clean Code», «Ideal Programmer», «Clean Architecture», adoré des informaticiens, est à l'origine d'Agile. Pure Agile élimine les malentendus et la confusion qui, au fil des années d'existence d'Agile, ont rendu son utilisation plus difficile que le plan d'origine. Essentiellement, Agile n'est qu'une petite sélection de méthodes et d'outils qui aide de petites équipes de programmeurs à gérer de petits projets, ... mais conduit à d'excellents résultats,parce que chaque grand projet consiste en un grand nombre de briques. Cinq décennies de travail avec des projets de tous types et tailles imaginables permettent à Oncle Bob de montrer comment Agile devrait réellement fonctionner. Si vous voulez comprendre les avantages d'Agile, ne cherchez pas de moyens simples - vous devez utiliser Agile correctement. Pure Agile vous explique comment procéder pour les développeurs, les testeurs, les gestionnaires, les chefs de projet et les clients.

Extrait. La première chose à savoir

Quelle est la première chose que vous devez savoir sur le projet? Avant de connaître le nom du projet ou ses exigences, avant de faire des mouvements, vous devez obtenir plus d'informations. Bien sûr, ce sont les délais. Une fois les dates sélectionnées, elles doivent être fixées. Il est inutile de discuter des termes, car ils sont définis en relation avec des raisons commerciales objectives. Si septembre est dû, ce n'est pas seulement ça. Peut-être qu'en septembre une sorte d'exposition ou de réunion des actionnaires est prévue, ou peut-être que les fonds seront tout simplement épuisés. Quelle que soit la raison, il a des antécédents importants. Et la raison ne changera pas simplement parce que pour certains développeurs, le volume des tâches semble écrasant.

Dans le même temps, les exigences peuvent changer dans un flux continu qui ne peut pas être fixé.

Et il y a aussi une raison à cela - les clients ne savent souvent pas exactement ce qu'ils veulent. Ils semblent savoir quel problème ils doivent résoudre, mais traduire ces connaissances en exigences de projet est toujours difficile. Par conséquent, il y a une réévaluation et une révision constantes des exigences. De nouvelles fonctionnalités sont ajoutées.

Certains anciens disparaissent. L'interface utilisateur change rapidement - en semaines, voire en jours.

Voilà à quoi ressemble le monde du développement logiciel. Dans ce monde, les délais sont fixes et les exigences changent constamment. Et d'une manière ou d'une autre, dans le contexte de tout cela, les développeurs doivent réussir le projet.

Collection

Le modèle en cascade nous a prophétisé un moyen de contourner cette tâche. Pour expliquer à quel point elle était séduisante et inefficace à la fois, je citerai une réunion en exemple.

C'était le premier mai. Le grand patron a appelé des subordonnés à la salle de conférence.

Le patron a commencé: «Nous avons un nouveau projet. Il faut le terminer avant le 1er novembre. Nous n'avons pas encore d'exigences. Ils nous seront annoncés dans les prochaines semaines. Combien de temps faut-il pour analyser le projet? »

Nous avons commencé à nous regarder d'un air interrogateur. Tout le monde était silencieux, craignant d'en dire trop. Personne ne savait quoi répondre. Quelqu'un a marmonné: "Donc, nous n'avons pas d'exigences, par quoi devrions-nous commencer?"

«Imaginez qu'ils le soient! Hurla le patron. "Vous savez comment tout fonctionne." Vous êtes experts! Je n'ai pas besoin de dates exactes. J'ai juste besoin de remplir le programme d'une manière ou d'une autre. Gardez à l'esprit que si cela prend plus de deux mois, vous pouvez oublier le projet en toute confiance. »

Quelqu'un marmonna, interrogateur: "Deux mois?" Le patron a accepté les conditions: «Génial! Juste ce que je pensais. Maintenant, dites-moi combien le design prend? "

Et encore une fois, tout le monde se figea de perplexité, la pièce était remplie d'un silence de mort. Nous comptons. Et nous nous rendons compte que jusqu'au premier novembre seulement six mois. La conclusion se suggère. "Deux mois?" - tu demandes.

"C'est vrai! - le grand patron sourit radieusement. - Comme je le pensais. Et il nous reste deux mois pour la mise en œuvre. Merci à tous, vous êtes libre! "
Beaucoup de lecteurs se sont probablement souvenus que quelque chose comme ça leur était déjà arrivé. Qui n'a pas eu ça, eh bien, tu as de la chance!

Étape d'analyse

Supposons donc que nous ayons quitté la salle de conférence et que nous nous soyons dispersés dans les bureaux. Que faire ensuite? La phase d'analyse commence - cela signifie que vous devez analyser quelque chose. Mais comment appelons-nous exactement l'analyse?

Si vous lisez des livres sur le thème de l'analyse dans le développement de logiciels, vous constaterez que chaque auteur donne sa propre définition. Il n'y a pas de consensus sur ce qu'est l'analyse. Il peut s'agir de la création d'une décomposition structurelle des besoins. Ou peut-être - détection et spécification des exigences. Il peut s'agir de la création d'un modèle de données ou d'un objet fondamental, et ainsi de suite ... La meilleure définition de l'analyse est la suivante: c'est ce que font les analystes.

Bien sûr, il y a des choses évidentes. Il faut évaluer la taille du projet, prévoir les indicateurs des principales ressources techniques, économiques et humaines. Vous devez vous assurer que le calendrier de travail est réalisable. C'est le plus petit que l'entreprise attende de nous. Quel que soit le nom d'analyse, c'est exactement ce que nous allions faire au cours des deux prochains mois.

Il s'agit d'une sorte de phase favorable du projet. Tout le monde navigue tranquillement sur Internet, effectue de petites transactions, rencontre des clients et des utilisateurs, dessine de beaux graphismes, simplement, s'amuse.

Puis le premier juillet, un miracle se produit. L'analyse est terminée.

Pourquoi le pensons-nous? Parce que c'est déjà le 1er juillet. Si, selon le calendrier, l'étape d'analyse doit être achevée le premier juillet, cette étape est achevée le premier juillet. Nous ne sommes pas en retard, n'est-ce pas? Par conséquent, nous organiserons une petite fête avec des ballons et des discours enflammés, célébrons notre transition de la phase d'analyse à la phase de conception.

Phase de conception

Que faire maintenant? Bien sûr, nous allons concevoir. Mais qu'est-ce que le design ?

Nous en savons un peu plus sur la phase de conception logicielle. À ce stade, nous divisons le projet en modules séparés et concevons les interfaces entre ces modules. À ce stade, nous supposons également combien d'équipes nous aurons besoin et comment ces équipes seront interconnectées. En général, le calendrier des travaux doit être clarifié afin d'élaborer un plan de mise en œuvre plausible et réalisable.

Bien sûr, à ce stade, quelque chose change de façon inattendue. De nouvelles fonctionnalités sont ajoutées. Les anciennes fonctions disparaissent ou s'ajustent. Et ce serait bien de regarder en arrière et d'analyser à nouveau les changements, mais le temps c'est de l'argent. Par conséquent, nous essayons de toutes les manières possibles d'apporter des modifications à la conception.

Et puis un nouveau miracle se produit. Le premier septembre, nous terminons soudainement la conception. Et pourquoi? Oui parce que. Le premier septembre. Selon l'horaire de travail, nous aurions déjà dû terminer. Pas besoin d'hésiter.

Donc encore une fête. Ballons et discours. Et nous passons à l'étape suivante - la mise en œuvre.

Ce serait formidable de lancer à nouveau un tel système. Oh, si de la même manière il serait possible d'achever la phase d'implémentation! Mais cela ne fonctionnera pas de cette façon. Parce qu'à la fin de la mise en œuvre, il est nécessaire de terminer l'ensemble du projet. L'analyse et la conception ne portent pas leurs fruits sous forme binaire. Ils n'ont pas de critères sans ambiguïté pour l'exhaustivité.

Il n'y a aucun moyen objectif de savoir si elles se déroulent dans la réalité. Par conséquent, il s'est avéré terminer ces étapes à temps.

Phase de mise en oeuvre

Mais la mise en œuvre a juste des critères distincts d'exhaustivité. Ici, il n'est plus possible de jouer avec précision, donnant le résultat imaginaire comme valide.
Au stade de la mise en œuvre, l'ambiguïté des tâches est totalement absente. Nous écrivons simplement le code. Et nous devons écrire le code à la hâte, en tirant la langue, car quatre mois ont simplement été jetés dans le vent.

Pendant ce temps, les exigences du projet continuent de changer. De nouvelles fonctionnalités sont ajoutées. Les anciennes fonctions disparaissent ou s'ajustent. Il faudrait revenir en arrière, procéder à une nouvelle analyse et apporter des modifications à la conception, mais ... il ne reste que deux semaines. Et à un rythme accéléré, nous introduisons tous ces changements dans le code.

En regardant le code et en le comparant avec le résultat de la conception, nous nous rendons compte que nous avons dû être hors de propos au stade de la conception, car le code lui-même n'a pas grand-chose à voir avec ce qui était à l'origine représenté sur les merveilleux graphiques. Mais il n'y a pas de temps pour réfléchir, car le temps presse et les heures supplémentaires deviennent de plus en plus.

Vers le 15 octobre, quelqu'un dit: "Hé, quelle est la date d'aujourd'hui?" Quand le prendre? " Et ici, nous comprenons qu'il ne reste que deux semaines et que d'ici le premier novembre, nous ne finirons jamais. Et soudain, pour la première fois, nos clients découvrent qu'il y a des problèmes avec le projet.

Imaginez leur indignation. «Et au stade de l'analyse, il était impossible de dire à ce sujet? N'était-ce pas alors que vous auriez dû estimer la taille du projet et soigneusement calculé le calendrier de travail? Et pourquoi ne l'ont-ils pas dit au stade de la conception? N'était-il pas alors nécessaire de diviser le projet en modules, de répartir le travail au sein de l'équipe et de calculer les ressources humaines? Pourquoi découvrons-nous tout deux semaines avant la date limite? »

Et ils ont raison, n'est-ce pas?

Marathon de survie

Et le marathon de survie commence. Les clients sont en colère. Les parties prenantes sont arrivées à l'extrême. La pression monte. Nous faisons des heures supplémentaires. Quelqu'un quitte le projet. Juste l'enfer!

Et déjà vers mars, nous pleurons de moitié avec pour résultat que seulement la moitié répond aux exigences des clients. Tout le monde est bouleversé. Tout le monde abandonne. Et nous nous jurons que la prochaine fois cela n'arrivera pas. La prochaine fois, nous ferons tout sagement. La prochaine fois, l'analyse et la conception seront effectuées de bonne foi.

Je l'appelle le processus de ballonnement hors de contrôle. Nous allons travailler encore mieux la prochaine fois en utilisant une méthode qui ne fonctionne pas.

»Vous pouvez pré-commander sur le site de l'éditeur.

Lors du paiement de la version papier du livre, le pdf est envoyé par e-mailavec les 105 premières pages du livre.