Lequel est le plus « agile » ? Blog ou wiki ??

Par défaut

Petite réflexion sur les outils en vogue sur le web 2.0 et sur la contribution de la communauté agile.

Le nombre de blogs sur la toile va croissant, y compris dans le monde agile. Chacun y va de son apport avec sa logique éditoriale, certains favorisant les retours d’expérience, d’autres les notes d’humeur, une vision de l’avenir, une philosophie du SI, un rapprochement avec les logiques héritées de l’industrie nippone… On peut s’abonner aux articles de plusieurs blog, suivre les flux RSS au travers d’un agrégateur style netvibes, commenter et noter les articles, commenter les commentaires … faire un article sur son blog en citant l’article d’un autre blog… sans oublier de twitter vers tout et réciproquement 😉

Effectivement le web 2.0 donne la main aux rédacteurs de tout poils et la toile se tisse avec des liens qui se croisent dans tous les sens. De sorte qu’il devient fastidieux, chronophage voire impossible de suivre tout ce qui est publié sur un thème, commentaires compris… Le coût pour se maintenir au courant des dernières publications devient prohibitif !!! Cela rappelle ce qui est advenu de l’informatique des grands comptes après des années d’empilage d’applications de toutes technologies, avec redondances fonctionnelles, interfaces multiples en entrée et en sortie… Quand la complexité devient exponentielle, le coût de maintenance devient prohibitif… il devient nécessaire d’urbaniser le SI. Alors, faut-il urbaniser l’édition on-line ?? Le wiki n’est-il pas en ce sens une préfiguration de solution ?

En ce qui concerne la communauté agile, je suis surpris de voir que les blogs pullulent et non les wikis qui me semblent beaucoup plus proches des valeurs agiles, deux d’entre elles en particulier :

  • L’interaction avec les personnes : est plus féconde dans le wiki (on écrit ensemble comme en pair programing) que dans le blog (j’écris un article, vous commentez mais l’article ne s’améliore pas…, vous pouvez aussi écrire un « contre-article » sur votre propre blog pour réagir et exposer un propos complet)
  • Davantage un produit opérationnel qu’une documentation pléthorique : de même, un wiki permet de consolider les apport et offre une vision complète, là ou une somme de blogs, commentaires et forums apporte une liste pléthorique de documentation électronique sans qu’aucune synthèse ne soit faite…

Cette vision se retrouve également au niveau des principes du manifeste agile :

  • Notre première priorité est de satisfaire le client (LECTEUR) en livrant tôt et régulièrement des logiciels (POSTS) utiles : l’avantage du wiki est qu’il est publié et évolue en permanence, alors que pour un blog, on édite un post quand il est bien ficelé, complet… on livre donc potentiellement moins souvent. Twitter ou un wiki semblent plus adaptés.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client : de même, dans un blog, une fois le post écrit, plus de changement… seulement des commentaires. Un wiki évolue en permanence…
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte : rejoint les points précédents
  • Les experts métier et les développeurs doivent collaborer quotidiennement au projet : l’aspect collaboratif me semble beaucoup plus évident sur un wiki que sur un blog, même un blog muti-éditeurs (où chacun publie ses billets).
  • La méthode la plus efficace pour transmettre l’information est une conversation en face à face : ce qui se cache derrière le « face à face » est sans barrières… or il y a moins de barrières et frontières dans un wiki que dans un blog (entre l’éditeur et les lecteurs, l’article et les commentaires)
  • Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment : c’est l’une des problématiques des blogs individuels : cela consomme un temps pour chacun pour avoir l’idée, la formaliser, la publier… un wiki par les contributions des autres apporte stimulation, idées croisées… et à la fois réduit la contribution à une idée, quelques mots, au lieu d’avoir un article complet à écrire.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité : en matière d’idées, il est plus facile de viser l’excellence à plusieurs (on se corrige, pense mieux…) et en pouvant retoucher, améliorer l’article (wiki) que sur un article mono-rédacteur figé (blog)
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle : la simplicité est très difficile à atteindre en particulier en un seul coup. Plus facile de tendre vers la simplicité en remettant l’ouvrage sur le métier… en prenant du recul, remettant en cause régulièrement ce qu’on considérait comme acquis… qui mieux que le wiki permet de revenir en arrière, de simplifier ? Quant au fait de maximiser la quantité de travail à ne pas faire, on peut faire le parallèle avec l’idée de maximiser la quantité de texte à ne pas lire : le wiki synthétise les idées contrairement aux blogs et forums où il faut lire le propos puis toutes les questions réponses, certaines étant souvent redondantes, incomplètes…
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent : il s’agit ici de l’architecture du wiki, l’organisation des idées… avec des liens internes et externes. Wikipédia me semble avoir une structure et une conception plus intéressante qu’une collection de plusieurs milliers de blogs…
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens : le travaille d’équipe me semble plus propre au wiki qu’au blog même multi-rédacteurs (mais rédacteurs individuels derrière un blog commun).

Aussi, pour aller au bout de la logique, j’ai eu l’idée de lancer un wiki pour contribuer à plusieurs à l’écriture d’un retour d’expérience consolidé et vivant permettant à des internautes qui aimeraient basculer en agile de comprendre comment y aller… Je l’ai baptise TRANSITION AGILE. Déjà 4 contributeurs m’ont proposé de confronter nos idées et écrire à plusieurs. Vos contributions sont les bienvenues. Pour l’instant, la contribution est sur login / mot de passe pour pouvoir être régulée. La lecture du wiki est ouverte au public. Cela pourra évoluer avec le temps selon l’usage et ma maîtrise de l’outil.

Bonne lecture.

Jean

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s