Déjà plusieurs fois, communiquant avec des collègues lors de conférences et de conférences, j'ai eu cette question:
Il semble qu'il est temps de fixer quelque part la réponse et de s'y référer à l'occasion :)
Alors, la gestion des connaissances Agile est-elle nécessaire, où les informations sont transférées de personne à personne? En fait, c'est le cas lorsque la réponse est contenue dans la question elle-même. Les informations sont transmises de personne à personne, c'est-à-dire qu'il y a un échange de connaissances . La tradition orale est l'un des outils de gestion des connaissances. Très peu fiable, mais certainement le plus populaire. La tâche du responsable de la gestion des connaissances est de créer un environnement propice au partage des connaissances. Bien sûr, dans les équipes agiles, l'environnement sera différent des structures organisationnelles classiques. Mais, fondamentalement, la réponse est bien sûr «oui, c'est nécessaire». Comprenons plus en détail.
Commençons par le manifeste Agile lui-même. Ses auteurs disent directement que
«C'est-à-dire, sans nier l'importance de ce qui est à droite, nous apprécions toujours plus ce qui est à gauche»
Le Manifeste Agile ne nous dit pas de "ne rien documenter"! Il dit que le client paie de l'argent pour un produit fonctionnel. S'il l'a reçu, alors en l'absence d'une belle documentation, il peut fermer les yeux, mais pas l'inverse. Le manifeste aide à établir des priorités, mais n'interdit pas. Et même si vous n'avez pas le temps pour les grands quais, au cours du travail, un grand nombre d'artefacts de gestion des connaissances sont créés, que vous pouvez ensuite utiliser lors de la prise de nouvelles décisions: tickets, journaux des modifications, etc.
«Les gens et l'interaction sont plus importants que les processus et les outils.»
Dans une étude menée auprès des informaticiens, il est clair que les professionnels de l'informatique placent le partage des connaissances (c'est-à-dire l'
interaction ) au deuxième rang des défis existants dans le développement de logiciels.
Dans l'ensemble, les résultats de cette étude confirment la première thèse du manifeste. Il me semble que les jambes de la question se développent du fait que la gestion des connaissances par beaucoup en développement est comprise comme une documentation, et non comme une interaction entre des personnes pour transférer des expériences.
Oui, au fait, dans l'un des postes précédents, j'ai déjà dit que la connaissance n'est pas de la documentation, mais de l'expérience acquise dans la mise en œuvre d'un projet spécifique par un employé spécifique . Même si vous n'avez pas créé de documentation produit, vous avez définitivement acquis une certaine expérience au cours du projet. De plus, les outils Agiles contribuent indirectement au fait que cette expérience est constamment fouillée.
Par exemple, rétrospectives . Qu'est-ce que c'est sinon un processus de partage des connaissances? L'équipe rassemble, partage les problèmes existants (dans le domaine de la GC, on parle de «leçons apprises» ) et élabore un plan de changement afin de résoudre ces problèmes. C'est-à-dire que les gens ont fouillé leur expérience les uns avec les autres, en ont discuté, ont développé une stratégie pour surmonter les inconvénients dans un proche avenir et ont fixé quelque part ce plan même de changements (artefact de gestion des connaissances). Habituellement, les résultats de ces réunions sont stockés quelque part. Je ne suis pas sûr qu'il existe des commandes efficaces qui, après avoir terminé l'itération, suppriment les données sur tous les rétro passés.
Ou la programmation en binôme . Même Wikipédia nous parle de cet outil comme suit:
Avantages:
***
Le mentorat
Tout le monde, même un programmeur novice, sait quelque chose que les autres ne savent pas. La programmation par paires est un moyen indolore de diffuser ces connaissances.
***
La formation
Les programmeurs échangent constamment leurs connaissances.
Deux programmeurs expérimentés se pompent mutuellement, utilisant leur propre expérience. Le seigneur pompe la juna, agissant en tant que mentor. Le mentorat d' équipe est généralement l'une des incarnations les plus populaires de la gestion des connaissances dans le développement de logiciels. Le même Yandex a même commencé à enseigner cet art extérieurement.
Ou prenez la situation lorsque vous utilisez le kanban. Supposons que les testeurs testent 10 fonctions par mois et que les développeurs parviennent à en implémenter 20. Cela conduit à l'accumulation de travail chez QA, et donc à des risques pour la qualité de leur travail. Dans ce cas, vous pouvez, par exemple, redistribuer les ressources et connecter les développeurs à la création d'autotests. À la suite de l'itération, l'équipe a reçu une expérience de planification négative et, sur cette base, peut élaborer un nouveau plan de manière à assurer un débit maximal du pipeline avec les mêmes ressources. Autrement dit, dans le processus de développement, des connaissances ont été acquises (= expérience), après avoir analysé lequel, l'équipe est arrivée à l'optimisation du processus.
Eh bien, il y a une question très posée: l'équipe n'utilisera-t-elle pas l'expérience acquise en travaillant sur le projet lorsqu'elle travaille sur d'autres projets? Autrement dit, à titre expérimental pour le projet en cours, ils ont découvert qu'ils peuvent implémenter avec des tests une moyenne de 15 fonctions par mois. Ne feront-ils pas partie du nouveau projet initialement prévu à 20 ans?
La connaissance est tout ce qui s'est passé autour du projet. Le processus de développement ne se déroule pas dans le vide. Coordination, liens utiles, interaction avec d'autres équipes, intégration des débutants, etc. Toute équipe passe par là. Avec un ensemble d'expérience, divers artefacts apparaissent, tels que des listes de contrôle d'adaptation pour les débutants ou une base de données de liens utiles. Il s'agit de connaissances fixes ou du résultat de la compréhension de l'expérience acquise.
Nous participons tous chaque jour à des processus de partage des connaissances (enfin, vraiment, nous communiquons constamment les uns avec les autres!), Et travailler sur la méthodologie Agile ne nous exclut pas de ce processus. De plus, il comprend déjà des outils de gestion des connaissances très efficaces. Il ne reste plus qu'à organiser le travail de l'équipe pour que ces outils donnent un maximum d'échappement.
Dans un article, je n'ai donné que quelques exemples. Voyons dans les commentaires ce que les autres outils Agile sont également des outils de gestion des connaissances. Eh bien, ou discutez pourquoi je me trompe :)