Quel est le principal problème dans le développement de logiciels (ou peut-être dans n'importe quel travail)? Lorsque j'ai posé une question à mes collègues, j'ai reçu différentes réponses: changements d'exigences, inadéquation des attentes, qualité du code, interaction avec les autres équipes ... pour résumer - la communication est l'un des problèmes les plus importants.
Pendant la communication, chacun comprend tout à sa manière, l'interprète différemment de ce qui a été dit. Le client garde dans sa tête une certaine image qu'il essaie de convertir en mots et en images, le développeur, en entendant ces mots, les convertit dans sa tête en une sorte de sa propre image. Et dans cette chaîne, il peut y avoir de nombreux maillons.
En essayant de résoudre ce problème, les gens rédigent un mandat détaillé. Mais cela résout-il le problème? Les mêmes questions, selon moi, ont été posées par Bob Martin et Martin Fowler avec ses collègues lorsqu'ils ont écrit le Manifeste Agile en février 2001. Essayons de le comprendre ensemble sur cette question, et dans le manifeste Agile lui-même.
L'histoire
Au cours de l'hiver 2000, il y a eu une réunion des dirigeants de la soi-disant programmation extrême, ils ont discuté des méthodologies de développement et ont donc commencé à proposer des méthodologies légères. Peu de gens étaient intéressés (je ne veux offenser personne), très probablement ils ont fait plus de blagues sur ce sujet. Cependant, plusieurs personnes extérieures à cette réunion ont organisé la leur un an plus tard. Tout a commencé avec le fait que Bob Martin (il a écrit le célèbre livre sur la qualité du code), a fait un bulletin aux dirigeants de la dernière réunion - réunissons-nous et parlons. En fait, rien de concret. Pendant quelque temps, ils se chamaillèrent sur le lieu et l'heure. En conséquence, ils se sont réunis le 11 février 2001, dans l'Utah, dans une station de ski. 17 personnes du secteur du développement, dont Bob Martin, Martin Fowler et d'autres. Ils ont bu, Fowler est allé skier et après des discussions, le
Manifeste Agile a vu le jour.
En principe, tous les plus importants peuvent être traduits littéralement par une page de texte, qui peut être lue
ici .
Mais comme tout court et méticuleusement pensé, comprendre cela simplement en le lisant n'a pas été facile pour moi personnellement. Par conséquent, considérons en détail ce que ces personnes qui ont signé le manifeste Agile avaient à l'esprit.
Principes agiles
Autrement dit, sans nier l'importance de ce qui est juste,
néanmoins, nous apprécions davantage ce qui se trouve à gauche.
Il s'agit d'un aspect très important qui doit toujours être gardé à l'esprit lors de la lecture d'un manifeste, et même chaque jour au travail. Discutons des principales déclarations manifestes.
Les gens et l'interaction sont plus importants que les processus et les outils
À première vue, cela peut sembler être un appel à jeter tous les projets Jira, les suiveurs de bogues, les enregistreurs de temps et autres outils et tous les processus configurés. Ce qui pourrait être plus facile, c'est de discuter verbalement avec des collègues ce que quelqu'un fait. Si seulement tout le monde était content. Mais ça a l'air un peu utopique, non?
Ce principe suggère que lors de la construction du processus de développement de quoi que ce soit, il est important de se rappeler pourquoi il est fait, pour qui et dans quel but. Cela n'a pas de sens de créer un processus pour le plaisir du processus lui-même. Parce que le travail sera finalement effectué par des personnes, vous et moi. Que se passera-t-il si toute l'étincelle, tout l'intérêt à nos yeux est remplacé par une tâche dans le yutrek ou des bugs dans le jir? Il ne vaut rien pour un processus bien organisé qui offre une sécurité complète devant le client, mais ne résout pas de vrais problèmes de développement. Les détails bureaucratiques (formels) peuvent facilement entraîner la perte de personnes sur un projet. J'ai tendance à penser qu'il en va de même pour la planification. À quand remonte la dernière fois que vous avez fait la planification, qui au final au moins 60 à 70 pour cent s'est avérée exacte?
À mon avis, ce principe du manifeste pourrait ressembler à ceci:
Des processus pour les personnes, pas des personnes pour les processus
Comment le manifeste suggère-t-il que nous nous rapprochions de la mise en œuvre de ce principe?
- Des professionnels motivés devraient travailler sur le projet.
- La communication directe est la plus pratique et la plus efficace.
- Les meilleures exigences et solutions architecturales proviennent d'équipes auto-organisées.
- L'équipe doit constamment analyser son travail et optimiser le processus.
Qu'est-ce que l'équipe développe en général? Produit pour le client.
Un produit fonctionnel est plus important qu'une documentation complète
Si interprété tel quel, sur le front, je pense que beaucoup seront d'accord. Mais que voyez-vous d'autre ici? Personnellement, je vois ici qu'un produit qui fonctionne et qui fonctionne à
temps est plus important qu'un code parfaitement écrit. Ce sont des mots cruels et effrayants à bien des égards, donc je ne devrais pas dire cela. Mais toute ma carrière, en apprenant de différentes personnes, je suis devenu de plus en plus convaincu de la pensée - si je choisis entre un projet idéal en termes de code et d'architecture, et un projet qui n'est pas très beau à l'intérieur, mais qui profite au monde, je choisirai le second. Et oui, je vais l'améliorer au mieux de mes capacités et capacités.
Et ici, vous devriez réfléchir un instant. Mais que peut-on faire pour rendre ces problèmes moins courants? Pour ne pas avoir à choisir entre refactoriser un module et développer une nouvelle fonctionnalité?
- Un produit fonctionnel doit être publié le plus souvent possible.
- Un produit fonctionnel est un indicateur clé de progrès.
- Une attention continue à l'excellence technique et à la qualité améliore la flexibilité du projet.
- La simplicité et la minimisation sont nécessaires.
Faites attention au point sur l'excellence technique. En maintenant le code de bonne qualité (nécessaire) et suffisante, nous tolérons beaucoup plus facilement les modifications des exigences et, par conséquent, les modifications du code.
Tous les principes, je vous le rappelle, ne sont pas négatifs. L'un n'exclut pas l'autre. Il s'agit de prioriser. Tout est important - le produit, la qualité du code et la documentation. Mais que choisir, quand choisir? Travaillant dans un certain équilibre entre qualité et produit, le produit est plus facile à mettre en priorité, sans nier la qualité.
Comme exemple de ma vie, je me souviens du travail sur un projet bancaire pour un client russe. Le travail a été réalisé avec la participation d'analystes et strictement sur les savoirs traditionnels volumétriques. Tous les six mois, le responsable se rend au siège social du client et présente les résultats du travail. Il est facile de deviner qu'en règle générale, les résultats étaient sensiblement différents des attentes du client. Le comptable du client, qui a vu le nouveau système pour la première fois et savait généralement qu'il était en cours de création, était dans un état d'horreur - rien de tel que son processus de travail habituel dans le nouveau système. Ce qui nous amène au sujet suivant.
La collaboration avec le client est plus importante que la négociation des termes du contrat
Vous devez être très prudent avec cette déclaration. Et encore une fois, rappelez-vous que le côté droit de la déclaration n'est pas nié. Au contraire, nous disons que le contrat est important. Juste au moment où nous pesons les termes du contrat et de la coopération, les bons partenariats à long terme, alors la relation sera plus importante. Sans renier le second. J'attire une telle attention à cela car nous vivons dans le monde réel et parfois nous devons travailler avec des clients très différents. Il y a des cas où le client pour ses propres fins égoïstes peut profiter de la naïveté et, au détriment du contrat, battre des conditions inacceptables pour les développeurs.
Néanmoins, si nous parlons d'un certain bon client abstrait
dans le vide , il est plus important de maintenir une relation à long terme qui conduira à de nouveaux projets.
Comment parvenir à la compréhension et au respect des attentes tout au long du projet?
- Tout au long du projet, les développeurs et les représentants de l'entreprise personnalisée doivent travailler ensemble quotidiennement.
- La communication directe est la plus pratique et la plus efficace.
Dans le même temps, il ne faut certainement pas oublier de confirmer les accords pour leur propre sécurité. Il y a d'ailleurs (heureusement rarement) des clients qui refusent généralement de payer après les accords.
Quel que soit le client, l'activité du développeur est toujours utile.
J'ajouterais moi aussi que cela devrait fonctionner dans les deux sens.
Cela nous amène à une suite logique - des changements dans le travail et les plans. Peu de gens aiment faire des changements, c'est dans la nature de l'homme, si vous y réfléchissez. Tout système vise un certain point d'équilibre et d'immuabilité. Mais c'est le développement qui est toujours associé au mouvement et au changement.
La préparation au changement est plus importante que de suivre le plan d'origine.
L'existence d'un plan en tant que tel n'est pas niée. Au contraire, le plan est important. Mais il est encore plus important d’être prêt à le changer si, à un moment donné, nous réalisons que ce plan ne fonctionne plus dans l’environnement actuel.
Un exemple tiré de la pratique de mes collègues est un projet de contrôle fiscal d'un des pays de la CEI. Le projet d'État, en substance, les savoirs traditionnels, la législation, il n'a pas été question d'agilité. Mais l’équipe a dû faire preuve de souplesse au moment où l’État du pays du client modifiait sa législation fiscale afin que le projet n’ait aucun sens sous la forme dans laquelle il était prévu. J'ai dû modifier les spécifications techniques et refaire le projet presque terminé pour que le client puisse l'utiliser. Sinon, le travail ne servirait à rien, sauf peut-être pour les gains en tant que tels.
Ce n'est peut-être pas l'exemple le plus révélateur, car les changements ont été provoqués par des facteurs externes. Et d'autre part, le client peut, encore une fois en raison de facteurs externes, venir à la nécessité de changer les exigences. Sinon, il n'obtiendra pas d'avantage concurrentiel.
Tout cela touche à un sujet légèrement douloureux pour moi. Mais que se passe-t-il si nous faisons un projet pendant une année entière, puis un an plus tard, le client dit - d'accord, vous êtes génial, et maintenant nous allons mettre tout cela dans les archives, nous ne l'utiliserons pas et nous commencerons un nouveau projet. Je suis plutôt pénible à ce sujet, j'ai eu une expérience similaire. Mais vraiment - que s'est-il passé? Le travail effectué a aidé le client à comprendre que le chemin choisi était incorrect. Ou inefficace. Pour obtenir un avantage concurrentiel, vous devez travailler différemment, faire un autre projet. Et il a reçu cette connaissance avec notre aide.
Quels aspects de notre travail aideront à lisser ces coins et à rendre la flexibilité moins effrayante?
- Livraison régulière et précoce des logiciels.
- Les modifications sont les bienvenues même aux stades ultérieurs.
- Les changements aident à fournir au client un avantage concurrentiel.
En même temps, nous vivons dans le monde réel, avec de vraies personnes, où aucun jugement, y compris celui-ci, ne devrait être porté à l'absolu. Oui, les modifications sont les bienvenues lorsqu'elles conduisent à une valeur ajoutée au produit final. Mais il est important de maintenir l'équilibre. Si nous apportons des modifications à l'infini, nous ne publierons jamais un produit en production. Par conséquent, à un moment donné, vous devriez dire - arrêtez, nous publions le produit, vérifions tout dans la pratique et commençons à faire la version deux, qui contiendra ces modifications. Clarifier chaque fois avec le client - quelle valeur il voit dans tel ou tel changement.
J'ai récemment lu la phrase sur Facebook,
si vous n'avez pas honte de votre produit, vous êtes entré trop tard sur le marché
Reflète assez précisément l'essence de ce qui précède. Nous devons rechercher un certain point d'équilibre, dans lequel le produit sera suffisamment prêt pour la prochaine version en termes de changements, et dans lequel nous n'avons pas encore commencé à consacrer trop d'efforts à des changements mineurs.
Au lieu de résumer
Les créateurs du manifeste Agile ne prescrivent aucune règle, et même vice versa. Mais ils soulèvent des questions importantes dans notre travail - l'interaction des personnes, des développeurs et des clients, la volonté de changement. Ces principes sont importants par nature. Avec l'importance indéniable de la documentation, des contrats, des processus et de la planification, l'interaction humaine, la préparation à des changements précieux et l'apport de quelque chose d'utile au monde sont d'autant plus importants.