«Tout est poison, tout est médicament; les deux sont déterminés par la dose. "
Paracelse
Il est de coutume de raconter l'histoire d'
Agile à partir de février 2001, date de naissance d'un document assez étrange -
Agile Manifesto . Dans l'ensemble, le texte du document est composé de preuves philosophiques (par exemple, «simplicité - l'art de ne pas faire trop de travail») et de déclarations controversées (par exemple, «les meilleures exigences techniques, la conception et l'architecture sont obtenues auprès d'une équipe auto-organisée»). Mais ce document est étrange non pas tant dans son contenu (on ne sait jamais ce qui pourrait venir à l'esprit dans une station de ski), mais dans la nature épique des changements ultérieurs dans l'industrie du logiciel. Dans les plus brefs délais, de nombreuses techniques sont apparues qui mettent en œuvre la méthodologie de développement «flexible», qui marche solennellement à travers le monde, capturant l'esprit des entrepreneurs et les portefeuilles des clients. Les adeptes présentent ce mouvement comme une sorte de pilule magique qui décide de tout. Il est arrivé au point où un
noble donateur, un honnête programmeur, est déjà devenu indécent d'admettre son implication dans le développement de logiciels selon l'
orientation traditionnelle
de la méthodologie. Essayons de comprendre les causes et les conséquences du phénomène, en utilisant
Scrum comme la manifestation la plus courante d'Agile.
Tout d'abord, essayons de comprendre ce que nous avons vraiment de nouveau dans le wrapper Agile en général et Scrum en particulier.
Scrum dans l'Egypte ancienne
Je me permettrai d'affirmer qu'une méthodologie flexible en général, et la méthodologie Scrum en particulier, ont toujours existé, bien qu'elles n'aient pas été appelées. Ils n'ont pas été appelés du tout, mais étaient simplement le moyen le plus naturel et le plus efficace pour mener à bien leurs projets internes (le mot clé ici est «interne»).
Par exemple, l'ancien pharaon égyptien prévoyait de construire une pyramide et ... cela a commencé. Discuté de l'idée avec les prêtres (intervenants) et assigné son majordome à la responsabilité du projet (propriétaire du produit). Le greffier a trouvé un maçon compétent (maître de mêlée). Le maçon a embauché des assistants (équipe Scrum), et ils sont allés au marché des esclaves et ont marqué des esclaves (outils de travail: PC, serveur, logiciel de développement, etc.).
Depuis que le pharaon lui a commandé un rapport mensuel sur l'avancement de la construction, le maçon (avec des assistants) a commencé à mener une démonstration de construction mensuelle (démo) pour le majordome. Pendant le spectacle, non seulement ce qui avait déjà été fait (rétrospective) a été discuté, mais aussi un plan pour le mois suivant (sprint) a été fait. Afin de ne rien manquer, l'échanson a passé tout le mois à discuter de ses histoires avec les prêtres (user stories) et à les enregistrer dans un parchemin spécial (backlog), dont la liste de souhaits est tombée dans le plan du mois prochain. Eh bien et ainsi de suite. Je ne sais pas à quoi ressemblaient les autocollants, le tableau de mêlée et les diagrammes de dégradation. Tout leader compétent sélectionne les outils les plus pratiques pour gérer et suivre le projet. Les détails ne sont pas importants ici, l'essentiel est que la technique fonctionne.
C'est-à-dire Je pense que tous les managers ont toujours utilisé une technique flexible pour créer leur produit interne (à leurs risques et périls) car:
- suffisamment compétent pour concevoir le résultat final;
- suffisamment compétent pour contrôler le processus;
- avoir suffisamment de pouvoir sur les participants subordonnés au processus;
- le rapport durée, coût et qualité du travail n'est pas un dogme pour eux et peut être révisé si nécessaire (car «il est son propre maître»);
- et surtout, le résultat final et le processus pour y parvenir sont entre les mêmes mains et poursuivent un intérêt commercial.
Mais pour le Client externe, aucun des éléments de cette liste n'est applicable; par conséquent, pour les projets externes (personnalisés), une technique flexible n'a jamais été utilisée (des exceptions ne font que confirmer la règle). Après tout, les gens étaient simples et intolérants, pour un excès flagrant de délais et d'estimations, ils auraient pu raccourcir la tête.
Scrum de nos jours
La seule nouveauté de Scrum moderne est le fait de son utilisation pour la mise en œuvre de projets externes (personnalisés). Essayer de ne pas dépasser ce côté du problème, car tirer une ficelle peut faire ressortir la véritable motivation des acteurs du marché. En fait, le manifeste Agile et tous les arguments de Scrum sont de la pure propagande des intérêts de l'Entrepreneur, par souci de décence, voilé sous la lutte pour tous les bons contre tous les mauvais. C'est le génie de la solution, qui nous permet de convaincre le Client de sacrifier le résultat au nom du processus!
Alors, qu'est-ce qui change si le propriétaire du produit est un employé d'une autre entreprise et non la sienne? La principale différence est que le résultat final et le processus de sa réalisation se situent désormais de part et d'autre de la «barricade» et chacune des parties ne poursuit que son propre intérêt commercial. Le résultat est important pour le client et le processus est important pour l'entrepreneur. Il ne peut en être autrement - après tout, "rien de personnel, ce ne sont que des affaires".
Agile est bénéfique pour les acteurs du marché informatique, car il leur offre la possibilité:
- faire de l'argent sur le processus et ne pas être responsable du résultat;
- réduire le coût du personnel de gestion compétent (ils sont chers, mais vous n'avez rien à concevoir maintenant et vous n'avez pas besoin d'écrire des savoirs traditionnels, et le processus contrôle désormais le propriétaire du produit du client).
Et puisque cela est rentable, sous nos yeux, des équipes de programmation avec l'épine dorsale de professionnels hautement qualifiés et soucieux du système peuvent se transformer en fermes d'encodeurs loués de la main du milieu.
Essayez de vous mettre à la place d'une personne qui engage une équipe de constructeurs pour réparer son appartement et essaie d'obtenir les conditions et le coût des réparations du chef d'équipe, et en réponse, il entend:
- nous sommes des gens créatifs, donc nous travaillerons «comme ça va», mais vous payez pour chaque heure de travail de l'équipe et des matériaux;
- nous ne ferons pas un projet et un plan communs, nous le déterminerons en cours de route (si nous faisons quelque chose de mal, nous le refaireons pour le temps que vous avez payé et du matériel supplémentaire);
- nous montrerons les résultats de notre travail toutes les deux semaines et parlerons de nos problèmes, puis ensemble nous planifierons les deux prochaines semaines.
Il est peu probable que quiconque soit d'accord avec une telle offre, et les clients des informaticiens sont d'accord! C'est ce que fait la propagande vivifiante!
Non seulement les clients sont convaincus d'accepter des dates et des coûts imprévisibles, mais ils y transfèrent également toute responsabilité en cas de défaillance. En règle générale, la qualification du client ne permet pas de formaliser les exigences pour le résultat final et de contrôler professionnellement le processus. Par conséquent, il peut toujours être confus et distrait (en l'absence d'un savoir traditionnel) de résoudre de nombreux problèmes secondaires (qui surviennent le plus souvent en raison du manque de planification à long terme).
Les conséquences d'un culte agile
Ne pensez-vous pas que la qualité des produits logiciels diminue proportionnellement à la large distribution d'Agile dans l'industrie? D'où vient la qualité si tout le processus est affiné en résolvant les problèmes de la manière la plus simple et la plus rapide possible? Et anticiper est officiellement interdit par la méthodologie!
Ne pensez-vous pas que les produits logiciels se transforment de plus en plus en «patchworks patchwork» lorsque vous êtes surpris de constater que différentes sections du même logiciel semblent être fabriquées par des personnes complètement différentes? Et même sur un écran de programme, différents styles de conception, différentes approches ergonomiques et différents algorithmes pour le fonctionnement de commandes similaires peuvent se mélanger. Mais il n'y a pas de savoirs traditionnels et de style pour le produit, donc celui qui est plus familier le fera! Et le personnel QA, comme tout le monde, est limité par les délais de sprint.
De quoi s'agit-il?
De tout ce qui précède, il peut sembler que je suis un ardent haineux Agile. Mais ce n'est pas du tout! Et je n'ai essayé d'offenser personne! Il a juste essayé d'illustrer plus clairement les mots du grand Paracelse mis dans l'épigraphe.
Une méthodologie flexible est tout à fait adaptée aux petits projets internes et même de taille moyenne. La taille du projet n'est limitée que par la capacité d'un leader particulier à «ne pas perdre la forêt derrière les arbres», c'est-à-dire la possibilité de garder à l'esprit tous les détails et le résultat souhaité sans le systématiser «sur papier».
Une méthodologie flexible est peu adaptée aux projets externes. Dans ce cas, les mêmes exigences s’appliquent au propriétaire du produit du client qu’au chef de projet interne, c’est-à-dire que cette personne doit être un véritable professionnel de l’informatique et non une secrétaire qui se charge à temps partiel d’une charge temporaire. Il doit être en mesure de vérifier les qualifications de l'équipe embauchée et de contrôler en permanence la qualité du produit en cours de développement. De plus, le produit en cours de développement devrait permettre (en cas de force majeure) le remplacement de l'équipe de développement. Ce n'est que dans ce cas que nous pouvons nous attendre à ce que ce ne soit pas «insultant et douloureux pendant des années sans but».
Comme vous pouvez le voir, Agile a sa place au soleil, mais il est très limité dans le domaine du développement informatique sous contrat. Que faire si votre projet ne fait pas partie de la catégorie Agile-convient?
Ne vous semble-t-il pas suspect qu'une méthodologie flexible n'ait pas pris racine ailleurs que dans le développement de logiciels sous contrat? Eh bien, ils ne font pas de sous-marins, d'avions ou de voitures sur Scrum. La sagesse de nos ancêtres nous enseigne que même une niche normale ne peut pas être montée sans une étape de conception (croquis au crayon avec des dimensions) et la préparation d'un ToR (liste de matériaux et d'outils). Tout ce que vous voyez autour (du tabouret au vaisseau spatial) a été créé selon la bonne vieille
«cascade» . Pourquoi tu ne fais pas pareil? Et rappelez-vous - tout ira bien!
PS
Tout ce qui est dit est basé sur mon expérience personnelle considérable (19 ans) dans le développement de contrats Web en utilisant des approches traditionnelles (Waterfall) et progressives (Scrum). Le motif de la rédaction de l'article était l'angoisse morale de la contemplation du prochain «miracle de la technologie hostile», bricolé sous les alliances du grand Frankenstein pour une entreprise occidentale respectée.
