Blog de Bruno Orsier

Un article de Bruno Orsier    4 Commentaires

Dans ce billet j’examine comment nous pourrions développer notre capacité à générer de la connaissance afin d’améliorer notre pratique de Scrum (voir billet précédent sur la conception de produits Lean).

Pour commencer, je pense qu’il faut distinguer connaissances publiables (par exemple sur le Web) et connaissances confidentielles (relatives au coeur de métier de votre entreprise). Vous pouvez être tentés de considérer que tout ce que vous faites dans votre entreprise est strictement confidentiel. Je n’en suis pas certain. Justement la pratique des méthodes agiles nous encourage à être beaucoup plus ouverts qu’auparavant, et à chercher à collaborer avec l’extérieur de l’entreprise. Il me semble donc qu’il faut être très sélectif sur ce qui doit rester confidentiel.

De plus les connaissances confidentielles seront consultées par un groupe très restreint (un petit sous-ensemble de l’entreprise), et maintenues par un groupe encore plus réduit. Elles courent donc un fort risque d’obsolescence. Par contre les connaissances publiées seront consultées par bien plus de personnes, et seront plus vivantes, car elles pourront être maintenues, commentées voire critiquées ou réfutées par plus de gens. D’autre part vos connaissances publiées pourront être indexées par  les moteurs de recherche, et deviendront ainsi facilement accessibles pour… vos collègues ! Ainsi, en choisissant d’aider la communauté, nous nous aidons nous mêmes !

Pour illustrer ce propos sur l’accessibilité de la connaissance, je viens de taper « développement dirigé par les tests » dans Google, et on trouve facilement le tutoriel que j’avais imaginé pour former mes collègues en interne ; ainsi un de mes collègues découvrira sans doute plus facilement ce document public que les supports de TP que j’ai stocké sur notre  serveur ! De même, tapez « pratiques équipe agile » et vous trouvez tout de suite l’excellent article d’Emmanuel Chenu, qui est un bon exemple d’un document qu’une entreprise pourrait conserver en interne (pour combien de lecteurs ?), mais qui permet à une plus large communauté de progresser (voir mon exemple d’utilisation dans un dojo).

Reconnaître l’existence de connaissances publiables est utile pour apporter une réponse à la question que je posais dans le billet précédent : comment matérialiser la connaissance ? Je ne suis pas certain que le moyen traditionnel (des simples documents) soit très viable. Nous avons souvent des difficultés à les maintenir, et les documents internes deviennent vite obsolètes.

Voici les supports publics existants que j’utilise régulièrement : blogs, forums (typiquement ceux de developpez.com), wikis (essentiellement wikipedia, mais aussi StackOverflow), videos, podcasts. La liste n’est pas très originale bien sûr. Par contre je commence à imaginer que tous ces supports pourraient être mis à profit en interne pour les connaissances confidentielles. Vous le faites peut-être déjà, mais nous en sommes encore loin, sans doute parce que nous n’avons pas encore conscience de l’importance de la génération de connaissances sous de multiples formes plus vivantes.

D’autre part, admettre ces nouveaux supports possibles, qu’ils soient publics ou confidentiels, ouvre d’intéressantes perspectives pour l’évaluation de la capacité de génération de connaissances des membres des équipes (il faudra bien les évaluer, si on met la génération de connaissances en avant). Voici comment un employé pourrait expliquer comment il génère de la connaissance :

• j’ai posté x billets sur …
• j’ai répondu à plusieurs questions sur StackOverflow ? D’ailleurs mon niveau de réputation est monté à …
• J’ai fait une petite vidéo pour expliquer à des collègues comment …
• j’ai traduit en français l’article de …
• j’ai complété l’article … sur wikipedia
• j’ai créé une nouvelle page sur le wiki interne sur …

En fait il y a certainement des gens qui sont déjà évalués en ces termes ! Les développeurs qui postent sur divers blogs d’équipe comme Ask the Performance Team ou Microsoft Advanced Windows Debugging and Troubleshooting parlent forcément de ces contributions dans leurs évaluations. Et ces blogs sont un autre bon exemple de connaissances (très pointues, mais très utiles) fournies à la communauté.

A nouveau, donc rien d’original – ca existe déjà. Par contre est-ce qu’il ne serait pas intéressant de pratiquer cela systématiquement, et avec tous les membres des équipes Scrum ? Au moins tous ceux qui voudront bien faire l’expérience ! Toutefois il est possible que cela suscite certaines difficultés, étant donné qu’il semble se dessiner une sorte de fracture entre ceux qui maîtrisent déjà les nouveaux supports et ceux qui s’en tiennent à l’écart.

Enfin cela nous donne de nouvelles possibilités d’actions à décider lors des rétrospectives :

• publier un billet sur le bug mystérieux X, sur leque nous avons trouvé très peu d’informations, et que nous avons reproduit sur un cas très simple
• rédiger un article sur les divers points que nous avons récemment dû approfondir sur la gestion de mémoire sous Windows. L’article comprendra des exemples de code pour …
• publier sur le blog interne la conclusion de notre étude sur les trois algorithmes possibles pour …
• créer une nouvelle page sur le wiki (ou forum, ou équivalent de stackoverflow) interne au sujet de … pour susciter des commentaires sur …

Qu’en pensez-vous ? Avez-vous déjà des blogs, wikis, etc. internes à votre entreprise ? Etes-vous encouragés à publier sur des supports publics ?