À lire : Scrum and XP from the Trenches

Dans mon post précédent sur Scrum, j'ai oublié de reparler du bouquin de Henrik Kniberg, « Scrum and XP from the Trenches ». Les opérationnels et les techniciens liront ce PDF gratuit comme un roman. Il s'agit d'une plongée passionnante dans le quotidien d'un Scrum Master.

Faites-vous de l'agile ?

Anecdote rapportée :

- Faites-vous de l'agile dans votre organisation ?
- Oui !
- Ah, et quelles pratiques avez-vous adoptées ? XP (eXtreme Programming) ?
- Non.
- Le pair programming ?
- Non.
- Euh... Vous faites du refactoring, alors ?
- Non plus.
- ... De l'intégration continue ?
- Non.
- ... Alors quoi ???
- On ne fait pas de documentation.

Formation Scrum Master à La Défense

J'ai eu l'occasion la semaine dernière, précisément les mardi 25 et mercredi 26 mars, de suivre une formation « Scrum Master » donnée par Jeff Sutherland en partenariat avec Xebia France, à Paris-La Défense.

Pour ceux qui ne connaissent pas Scrum, je dirais qu'il s'agit d'une boîte à outils méthodologiques pour mener des projets à bien.

Basiquement, ces projets sont :

• avec des objectifs « démontrables » : par exemple, un site web, un rapport rédigé, un gâteau...
• suivis de près par un « directeur de produit » (Product Owner)
  
• à équipe réduite : entre 5 et 9 personnes, avec une préférence pour des équipes de 5
  
• menés de façon itérative : à la fin de chaque itération, une version du produit est garantie testée, et est démontrable entre autres au directeur de produit ; cela assure que le feedback est reçu à intervalles rapprochés et réguliers, et qu'on vérifie que la trajectoire prise par l'équipe n'est pas déconnante
  
• menés sur des itérations courtes : de 2 à 5 semaines, avec souvent une préférence pour des itérations de 2 semaines (je n'en reviens toujours pas, car cela me semble bien court, mais plusieurs participants m'ont assuré travailler ainsi)
  

Une des grandes devises de Scrum est « inspect & adapt », c'est-à-dire qu'un projet mené avec Scrum améliore lui-même sa méthode de travail tout du long.

Scrum est une méthodologie « agile », au même titre que XP pour le processus de développement logiciel.

Pour de plus amples renseignements, je vous conseille le blog de Claude Aubry, et le livre Agile Project Management with Scrum, de Ken Schwaber (Ken Schwaber est le co-inventeur, avec Jeff Sutherland, de Scrum).

J'avais eu l'occasion de m'intéresser à Scrum par l'intermédiaire de lectures sur le web, et d'expérimenter avec enthousiasme deux ou trois principes portés par ce framework. Suivre la formation à Paris m'a permis d'équilibrer mes connaissances théoriques, et évidemment de rencontrer d'autres personnes impliquées dans Scrum.

Ce furent deux jours passionnants.

D'abord, Jeff Sutherland, l'homme. Il est à la fois brillant et précis dans son discours, très intelligent dans sa façon d'appréhender les choses, humble et... marrant. Je dirais qu'il apparaît que Scrum s'inscrit pour lui dans une démarche plus globale. Il a évoqué le bouddhisme zen par exemple.

Ensuite, Scrum. En anglais, « scrum » signifie « mêlée » : celle du rugby. À entendre Jeff Sutherland, il s'agit bien et prioritairement de permettre à une équipe d'être la plus efficace possible pour atteindre un objectif commun. Pour cela, il faut (et il suffit ?) de clarifier par tous les moyens (discussions, démonstrations suivies de feedbacks, échanges avec le client) l'objectif à atteindre, et de libérer l'équipe de tout ce qui pourrait gêner sa tâche.

À ce titre, la méthode invoque un rôle particulier dans l'équipe, celui du « Scrum Master » (c'était l'objet de la formation, vous suivez). Je dirais que celui-ci est principalement là pour régler les impediments, c'est-à-dire les obstacles que rencontre l'équipe, et pour favoriser les échanges et le feedback continuels, en organisant notamment, et en cadrant, des réunions quotidiennes d'environ un quart d'heure (daily scrums).

Les impediments peuvent être de divers ordres : matériels, logiciels, environnementaux, voire budgétaires, mais aussi humains, politiques, ou managériaux. Le Scrum Master est concentré sur le travail que doit fournir l'équipe, pas sur la hiérarchie dans l'organisation.

Quand on se pose la question de cette façon simple, il n'y a pas grand-chose à penser :

• Le Scrum Master met de l'huile dans les rouages (daily scrums et tenue à jour des backlogs),
• et balaie les grains de sable de l'engrenage.
• L'équipe prend à sa charge la réalisation du produit,
• produit dont le Product Owner maintient une vision claire et compréhensible (accessible).

L'image qui me venait est celle d'une piste de bobsleigh : si la piste est constamment dégagée, l'équipe la descendra d'abord à pied (on n'est jamais trop prudent), puis en se laissant glisser individuellement (confiance), puis... en bobsleigh (confiance + équipe).

Les études menées sur l'utilisation de Scrum montrent paraît-il qu'une équipe de développeurs moyens est toujours meilleure à terme que des bons ou des très bons développeurs qui travaillent séparément. Cette émergence qui naît au sein d'une équipe est captée dans le « ba », terme japonais.

Le fait d'avoir son esprit vacant (no impediment) et concentré sur l'activité s'appelle le « kaizen ».

L'objectif de Scrum est de permettre au « ba » de s'exprimer dans une équipe composée de personnes en état de « kaizen » ;-)

Pour en revenir à la formation, nous étions 30 stagiaires. La formation et le support étaient en anglais, avec l'aide de Guillaume Bodet, directeur technique de Xebia France, présent pendant ces deux jours, dans le cas où des termes auraient nécessité une traduction (cela n'a finalement pas été le cas).

Deux exercices m'ont particulièrement intéressé :

• la réflexion en équipe et la rédaction collaborative d'une réponse à un problème donné, en trois itérations de 8 minutes, chacune précédée de 4 minutes de daily scrum. Je jouais le Scrum Master, et me bornais donc à organiser les daily scrums et à régler les problèmes de l'équipe. J'ai trouvé que le résultat, c'est-à-dire le document rédigé, malgré le caractère parfois désordonné du travail, et la vitesse demandée, était de bien meilleure facture que ce qu'on aurait pu composer chacun de son côté, ou de ce qu'on aurait pu organiser linéairement sans itérations. Pour la démo, l'équipe m'a demandé de présenter le document ! alors que je n'avais pas participé à sa matière. C'est le rôle du Scrum Master, si j'ai bien compris : être au service de l'équipe...
  
• un exercice de planification en fonction de la « valeur métier » des composants d'un produit à réaliser. Notre équipe n'a pas terminé l'exercice (!!!) car nous passions trop de temps en planification. La qualité de réalisation était évidemment très bonne (vu la planification), mais le projet a été planté, vu que nous n'avancions pas à un rythme suffisant. Cet exercice m'a montré l'importance primordiale du Product Owner, qui doit être clair dans ses demandes et exigeant quant au résultat, et celle, finalement secondaire, du cadrage apporté par le Scrum Master.

Quelques questions font débat :

• Scrum Master, n'est-ce pas simplement un rôle chef de projet ? Voire un sous-rôle de chef de projet ? Pour ma part je pense que le Scrum Master a notamment comme fonction de balayer les obstacles et de cadrer l'énergie collective, pas de se mettre en avant par rapport à l'équipe (d'ailleurs par moments ça gêne, si on se met en avant). Par ailleurs ce n'est en aucun cas un positionnement hiérarchique : les tâches ne sont pas affectées par le Scrum Master. Donc à chacun de se faire son idée.
• Le client final a-t-il plutôt besoin de bons Scrum Masters, ou de bons Product Owners ? La réponse de Jeff Sutherland est fortement et sans hésiter : de bons Product Owners. La vision du produit doit être portée, avec en permanence la visée de la maximisation de la valeur métier. C'est le Product Owner qui fixe les priorités de chaque itération et qui, en fonction des réalisations de l'équipe (et de la vélocité, dont je n'ai pas parlé dans ce post), gère les dates de livraison.
  

Au final, je vais appliquer Scrum sur tous mes projets. Outre le contact avec le Scrum Trainer, la formation Scrum Master permet de faire le tri dans les bases théoriques sur Scrum, largement disponibles sur le web ou dans la littérature, et de les confronter à la réalité à l'aide de quelques exercices pratiques.

Je ne peux que conseiller cette formation.

Google for Non Profits : plate-forme Les Fûts ?

C|net: Google launches tool portal for nonprofits.

Google communique sur sa palanquée d'outils auprès des organisations à buts non lucratifs :

• Gmail
• Checkout
• Docs
• Calendar
• Analytics
• Google Grants
• YouTube
• Blogger
• Maps&Earth
• Gadgets
• Groups
  

Il manque le wiki, je suis surpris.

Reste qu'avec les outils Google, et si on n'en sort pas, le concept d'identification numérique partagée d'association à association, concept qui est au cœur des Fûts (une personne qui fait partie d'une association appartient souvent à d'autres groupes), est fourni de base.

MindManager gratuit pour les blogueurs

Vu chez Cmicblog : MindManager gratuit pour les blogueurs

J'ai demandé ma clef, qu'on m'a fort gentiment envoyée. Puis j'ai installé cette application paraît-il surpuissante de mind mapping. On verra bien. En tout cas pour s'y mettre, d'après les habitués de la pratique, il faut prendre « au moins » MindManager.

YAML est au-dessus de XML

Développeur Java.

Des montagnes de fichiers XML pour la configuration, pour les tests, pour la sérialisation de données, parfois même pour les logs.

Une envie de penser plus vite.

Solution : adoption radicale de YAML.

Un exemple

Pour mes tests je joue beaucoup avec des descriptions de données au format XML. Ainsi, je peux manipuler des valeurs de référence (pour les tests) sous la forme suivante :

currentUser.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
<properties>
 <property name="firstName"
    class="java.lang.String">Dominique</property>
 <property name="lastName"
    class="java.lang.String">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</properties>
</DataBean>

Première discussion. On m'objectera qu'il vaudrait mieux avoir deux fichiers XML, un pour la description de la structure et un pour les valeurs. Cela donnerait éventuellement :

User.xml :

<DataBeanClass
 class="com.avcompris.model.User" alias="User">
<properties>
 <property name="firstName"
    class="java.lang.String"/>
 <property name="lastName"
    class="java.lang.String"/>
 <property name="birthDate"
    class="org.joda.time.DateTime"/>
</properties>
</DataBeanClass>

currentUser.xml :

<User name="currentUser" scope="request">
<firstName>Dominique</firstName>
<lastName>Vandrault</lastName>
<birthDate>1978-01-06</birthDate>
</User>

C'est un premier choix à faire. L'idée n'étant pas de faire de l'architecture mais bien de pisser du test, je n'ai aucune envie de me retrouver avec des fichiers de description dans tous les sens, qui deviendront impossibles à maintenir au bout de 30 refactorings. Pourquoi pas écrire des XML Schemas dès maintenant, aussi ?

Pour mes procédures de tests je conserve donc le principe du fichier unique, avec méta-données côte-à-côte avec les données.

Mon fichier de départ est bien le suivant :

currentUser1.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
<properties>
 <property name="firstName"
    class="java.lang.String">Dominique</property>
 <property name="lastName"
    class="java.lang.String">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</properties>
</DataBean>

Première idée, accepter les valeurs par défaut. Convention over configuration. Ainsi, je pourrais décider par convention que quand l'attribut @class est absent, la propriété est forcément de type java.lang.String. Et puis supprimons le tag <properties> qui ne sert à rien (il serait très utile si je souhaitais écrire un XML Schema validant mon XML, mais... ce n'est pas le cas pour le moment). Voyons ce que ça donne :

currentUser2.xml :

<DataBean name="currentUser"
 class="com.avcompris.model.User" scope="request">
 <property name="firstName">Dominique</property>
 <property name="lastName">Vandrault</property>
 <property name="birthDate"
    class="org.joda.time.DateTime">1978-01-06</property>
</DataBean>

Ah, mieux. Beaucoup mieux !

Deuxième idée, passer à des éléments qui ont le nom de la propriété. On élimine donc, par convention, l'attribut @name (et parallèlement, on s'éloigne de plus en plus de la possibilité d'écrire un XML Schema validant non trivial).

currentUser3.xml :

<currentUser
 class="com.avcompris.model.User" scope="request">
 <firstName>Dominique</firstName>
 <lastName>Vandrault</lastName>
 <birthDate
    class="org.joda.time.DateTime">1978-01-06</birthDate>
</currentUser>

Ça avance. Je ne me pose pas la question des sous-DataBeans, car je sens que ça me ferait reculer dans ma joie simplificatrice.

Continuons. Passons maintenant en tant qu'attributs de leur parent les éléments uniques qui n'ont pas d'attributs.

currentUser4.xml :

<currentUser
 class="com.avcompris.model.User"
 scope="request"
 firstName="Dominique"
 lastName="Vandrault">
 <birthDate
      class="org.joda.time.DateTime">1978-01-06</birthDate>
</currentUser>

OK. C'est un peu mélangé, ce n'est pas uniforme, mais j'y gagne.

Chouette.

...

Allez, j'arrête le cinéma. Ce XML est immonde, il n'est pas évolutif, il n'est pas validable, et il est moche. Moche comme du... XML.

Dites-moi que vous n'y avez pas cru...

L'approche YAML

YAML est un format de données qui est abondamment utilisé dans le monde de Ruby on Rails.

Quand je choisis YAML pour décrire mes données, je ne me dis pas « comment être sûr que je pourrai écrire un XML Schema validant plus tard », mais « comment ai-je envie d'écrire mes données ».

Le parsing, les transformations et la validation viendront bien plus tard. En fait, le plus souvent en passant par une étape XML intermédiaire.

En premier lieu je me contente d'une utilisation ad hoc du format.

Ainsi, mon fichier currentUser4.xml deviendrait :

currentUser4.yaml :

currentUser:
 class: com.avcompris.model.User
 scope: request
 value:
   firstName: Dominique
   lastName: Vandrault
   birthDate:
     class: org.joda.time.DateTime
     value: 1978-01-06

Beaucoup mieux que l'équivalent XML.

Mais on peut aller plus loin :

currentUser5.yaml :

currentUser:
 com.avcompris.model.User:
   firstName: Dominique
   lastName: Vandrault
   birthDate:
       org.joda.time.DateTime: 1978-01-06

(En passant, je supprime l'attribut @scope, en décidant qu'il vaut "request" par défaut. J'aurais aussi pu le faire dans le cas du XML).

Voici les « équivalents » YAML des autres fichiers XML :

currentUser3.yaml :

currentUser:
 class: com.avcompris.model.User
 scope: request
 value:
  firstName: Dominique
  lastName: Vandrault
  birthDate:
     class: org.joda.time.DateTime
     value: 1978-01-06

currentUser2.yaml :

- DataBean:
   name: currentUser
   class: com.avcompris.model.User
   scope: request
   properties:
    - name: firstName
      value: Dominique
    - name: lastName
      value: Vandrault
    - name: birthDate
      class: org.joda.time.DateTime
      value: 1978-01-06

currentUser1.yaml :

- DataBean:
    name: currentUser
    class: com.avcompris.model.User
    scope: request
    properties:
     - name: firstName
       class: java.lang.String
       value: Dominique
     - name: lastName
       class: java.lang.String
       value: Vandrault
     - name: birthDate
       class: org.joda.time.DateTime
       value: 1978-01-06

Ou le « degré zéro » de YAML :

currentUser0.yaml :

- DataBean:
    name: currentUser
    class: com.avcompris.model.User
    scope: request
    properties:
     - property:
           name: firstName
           class: java.lang.String
           value: Dominique
     - property:
           name: lastName
           class: java.lang.String
           value: Vandrault
     - property:
           name: birthDate
           class: org.joda.time.DateTime
           value: 1978-01-06

« currentUser5.yaml », propre, intelligent, lisible, fait 6 lignes.

Le dernier fichier, « currentUser0.yaml », d'une structure digne d'un fichier XML validable, pour ne pas dire d'une base de données relationnelles, en fait 17. Quasiment 3 fois plus.

YAML :

• ne demande pas d'indiquer les fins d'éléments (ouf !), car il se base sur l'indentation
• n'a pas de notion de sous-élément ou d'attribut : on se débrouille avec l'arborescence. Disons qu'il y a bien la notion de maps et de lists, qui correspondraient à peu près aux attributs (noms uniques) et aux sous-éléments (noms éventuellement répétés), mais les maps peuvent avoir des sous-arborescences, contrairement aux attributs du XML.
• est... lisible.
• il n'y a pas de guillemets dans tous les sens
• l'indentation fait partie de la syntaxe
  

YAML n'a rien à voir avec JSON. Je dirais grosso modo que YAML est orienté lisibilité des fichiers par des humains, tandis que JSON est orienté transfert de données entre machines. Mais surtout, JSON est fortement similaire à XML, tandis que YAML a une autre logique.

La place de YAML dans le processus de développement

J'utilise YAML pour les données de tests, la configuration, et les fichiers sources de génération.

Comme les composants côté serveur ou côté plugins savent surtout ingérer du XML, j'opère toujours une première phase de sérialisation de YAML vers un XML « neutre » équivalent.



La bibliothèque Java que j'utilise pour le parsing de YAML est JvYAML.

Voir aussi la bibliothèque JYaml.

La page de Wikipedia sur YAML : YAML.

Pour une check-list de productivité

À mon sens, la productivité et l’efficacité sont avant tout une affaire de détermination.

1. De déterminations extérieures :
   1.1. L’environnement doit faciliter l’activité
   1.2. L’environnement ne doit pas gêner l’activité
   
   
2. De déterminations propres :
   2.1. Il faut avoir envie de bosser
   2.2. Il faut que ce soit le bon moment
   2.3. Il faut savoir ce qu’il y a à faire
   2.4. Il faut être « motivé » par le feedback qu’on reçoit
   

Je vais décliner chacun des points pour mon cas personnel, en ne parlant que de ce qui concerne le développement J2EE / web.

1.1. Un environnement qui facilite l’activité

Par environnement, entendons au sens large tout ce qui m’entoure, avec qui je bosse, avec quels outils, et où je suis installé.

Le meilleur type d’endroit dans lequel j’ai pu faire du développement a été :

• un bureau dédié qui ne soit pas partagé avec des collègues,
• disposant d’une grande fenêtre — en fait une baie vitrée sur deux niveaux donnant sur l’Océan Atlantique,
• travaillant avec une équipe de « smart guys », jeunes ou moins jeunes,
• dans des locaux donnant accès à une bibliothèque interne, à une salle de repos, à des lieux informels de relaxation et de discussion (poufs bienvenus),
• donnant accès à un tableau partagé où chacun peut noter ses idées,
• avec une connexion internet haut débit (si, si, il faut le préciser),
  
• et un réseau local performant (ou une solution « on the cloud ») pour le partage occasionnel de fichiers — la grande majorité des échanges se faisant par le SCM.

Toujours à titre personnel, le meilleur poste de travail comprenait :

• un fauteuil de qualité (Markus, anyone?),
• une immense table (enfin, à l’époque elle me paraissait immense…),
• deux machines puissantes avec écran et clavier, dont une avec un ecran plat 20’’,
• pour le choix des systèmes d’exploitation, dans l’ordre : MacOS X, Windows 2000, Windows XP, Ubuntu,
• et un téléphone fixe avec haut-parleur, avec accès au national et à l’international.
  

On peut aussi faire son marché dans la liste de Calacanis : How to save money running a startup (17 really good tips)

Divers outils en coulisses qu’on ne présente plus :

• un SCM propre, comme Subversion,
• un wiki propre, comme Confluence,
• une plate-forme de blogging interne (en général, la même plate-forme offre le wiki et le blogging ; c’est le cas de Confluence),
• un bug tracker propre, comme Jira,
• une solution interne de messagerie instantanée, comme Jabber,
• et une plate-forme d’intégration continue propre, comme Continuum.
  

Parmis les outils logiciels, toujours pour ma partie, citons les plus importants :

• Java 5 ou ultérieur,
• Maven 2
• un IDE, comme Eclipse 3.3.2
• une panoplie de navigateurs web, dont Firefox 2.0.0, Mozilla et Opera
• un éditeur de textes, comme TextWrangler, Crimson Editor ou UltraEdit
• YAML, XML, XSLT
  

De plus, il est important de savoir investir dans des outils maison. Un bon outil maison est un outil qui n’est pas indispensable techniquement (surtout pas d’adhérence à la technologie !) et qui fait gagner des jours de charge.
Les contre-exemples bien connus sont :

• les framework maisons monolithiques auxquels le legacy est fortement couplé
• les outils maisons difficiles d’utilisation : mal documentés, qui gèrent mal les erreurs, pas ergonomiques, etc.

Le summum étant je pense les outils développeés en interne qui se révèlent moins bons que les solutions gratuites strictement équivalentes.
Attention, ce genre d’initiative freine la productivité non seulement en terme d’outillage pur, mais également en minant la motivation des équipes, car l’image de la boîte renvoyée en interne n’est pas bonne.

Je cite mes outils maison préférés jusqu’ici :

• plugins Maven de génération de code
• outil de rendu dynamique de JSP/JSF sans déploiement (et ne me parlez pas de Tomcat dans Eclipse, ou de JBoss qui redéploie en autonome)
• plugins Maven de tests de design web
  

Et la décoration du bureau ? Et la musique ? Et le Feng Shui ? À creuser…

1.2. Un environnement qui ne gêne pas l’activité

Il faut laisser la place aux bons points qu’on a vus précédemment d’être utiles.

Ainsi, on évitera, et je parle là de seuils d’acceptabilité :

• le bureau où on est 5 dans lequel parle à voix haute (je rappelle que je parle de développement. De tels bureaux peuvent être utiles pour d’autres choses),
  
• les open spaces,
• le bureau sans lumière extérieure,
• l’équipe de neuneus (oui, je sais, on est toujours le neuneu de quelqu’un),
• la société qui n’affiche pas un intérêt évident à investir dans des livres, dans des serveurs ou dans des formations,
• l’absence ou la restriction d’accès à internet,
• le poste de travail sous-dimensionné,
• la société où l’on ne peut pas capitaliser la connaissance dans une base ouverte, partagée, pratique d’utilisation et indexée,
• la société où l’on ne communique pas librement (oui, je sais, c’est le Moyen Âge, mais ça existe encore),
• les projets techniques sans phase d’investissement dans l’outillage technique : il faut savoir gérer les effets de seuil.
• les projets Java en-deçà de Java 5
  

En termes d’outils, je ne peux que souscrire à la liste de Pierre-Olivier Carles : 10 conseils pour conjuguer Innovations, Internet & Efficacité, en retenant pour ma part :

• Bloquer les e-mails entre 8 h 00 et 14 h 00
• Trier ses flux RSS
• Bloquer Skype et Twitter (très difficile) sur certaines plages temporelles
  

Souffrant d’électro-hyper-sensibilité (EHS), l’absence de téléphone portable et de Wi-Fi est cruciale pour moi si je veux pouvoir réfléchir normalement. Cela me restreint d’emblée l’accès à un bon nombre de locaux, mais ce type de discernement est tout le sujet de ce post.

Et la décoration du bureau ? Et la musique ? Et le Feng Shui ? À creuser également…

2.1. Avoir envie de bosser

Bah, ce n’est pas compliqué : il faut et il suffit d’être convaincu du résultat.

2.2. Le bon moment

Entre quatre heures et huit heures du matin, je suis en général trois fois plus rapide et efficace qu’après neuf heures du soir…

À huit heures, c’est le journal…

À midi, la faim se fait sentir, donc je réfléchis mieux…

Après le repas, sans sieste je passe trois heures à ne pas démarrer…

À 18 h 00, ça stagne… Pour baisser en général vers 19 h 00…

À environnement idéal (en dormant au boulot, donc !), je pourrais donner la courbe de productivité suivante :



Noter que je passe sur les problématiques de fatigue installée, de stress, etc. Tout ce qui constitue la moitié basse de la Pyramide de Maslow doit évidemment être réglé.

Cela étant dit, dans une journée la productivité n’est pas constante. Il faut connaître et utiliser les bons moments.

• Il est inefficace de travailler quand le moment « n’y est pas »
• Il est inefficace de ne pas travailler quand c’est le moment

Pour un article radical sur le bon emploi de son temps, et qui va bien plus loin que le bête sujet de la productivité, lire chez Paul Graham : Good and Bad Procrastination.

2.3. Savoir ce qu’il y a à faire

La concentration (notions de focus et de flow) est indissociable de la productivité.

À ce titre, il est crucial que la TODO-List, la liste des tâches à faire (par extension, l’ensemble des backlogs de Scrum par exemple) soit claire et affichée. Utiliser un outil informatique ou un cahier ne suffit pas. Pour les tâches du quotidien, un affichage mural est bien plus efficace.

2.4. Être « motivé » par le feedback qu’on reçoit

C’est un point important dans l’efficacité.

D’abord, comment savoir qu’on maintient le cap ? Qu’on a le sens des priorités ? On peut en effet être très concentré, très « productif » sur des menus détails, et laisser tomber des pans de l’activité. Pour cela, la TODO-List, ou les fameux backlogs de la méthode Scrum sont utiles.

En parlant de Scrum, les dailys scrums, lors desquelles toute l’équipe se réunit debout une demi-heure pour présenter les choses faites, le reste à faire et les problèmes rencontrés, représentent un gain redoutable tant pour la productivité individuelle que collective (notion de gel). La productivité en équipe n’est cependant pas le sujet de cet article.

Ensuite, il faut savoir juger ce qu’on produit. C’est aussi une façon de maintenir le cap. Et c’est encore une question de priorités : savoir identifier ce qui est important dans le produit réalisé, afin de se concentrer dessus.
Il s’agit d’un ensemble d’indicateurs, dont aucun n’est à négliger. Ils devraient même à mon sens avoir le même coefficient, avec seuils planchers éliminatoires :

• Les feedbacks des utilisateurs (organiser des démonstrations)
• Les feedbacks des « pairs » (peer reviews) (idem, et rédiger des bilans)
• La qualité interne du produit (audits automatisés réguliers)
  

Ces différents feedbacks, backlogs et indicateurs, sont bien des moteurs de « motivation », au sens où sans eux il est très facile de rester enkysté dans un axe de développement donné. Même s’il produit du code, et semble rassurant par certains aspects, cet immobilisme est forcément nocif, et au niveau de la productivité sera à terme destructeur. La remise en question, donc l’écoute des avis extérieurs, est un élément indirect mais fondamental de la motivation.

Enfin, il y a un feedback capital dans la productivité, c’est celui qu’on apporte soi-même. Passer du temps à bloguer en interne ce qu’on a fait dans la journée, à formaliser telle procédure, tel outil, telles spécifications même incomplètes… Bloguer ses pratiques, bloguer ses configurations, alimenter les bug trackers et les backlogs… On en retire :

• une capitalisation du savoir (non ? Sans blague ?),
• une pratique de la formalisation
• une réflexion en tâche de fond, et une habitude de communiquer,
• un recueil incrémental des problèmes et des solutions
  

Passons rapidement sur l’aspect évidemment pratique de faire vivre une telle base de connaissance.

En terme de productivité de développement, c’est utile car on y gagne en recul, donc d’acuité, donc de pertinence… donc de productivité.

On a vu l’importance de la concentration (focus) : il faut donc éviter le trop-plein de feedbacks qui mènent à la distraction voire à la dispersion. C’est tout l’objet de ce point : à mon avis le feedback doit être motivant, bien qu’il soit parfois laudateur ou critique. Motivant, c’est-à-dire qu’on ne doit pas le chercher pour lui-même mais pour l’effet qu’il aura sur l’activité.

C’est aussi pour cela que je parle de « détermination propre » au lieu de « détermination extérieure » pour le feedback : ce qui compte pour la productivité c’est ce que j’en fais moi.

Bonus : 3. Ce qui n’apporte rien

Grande question : que fait-on des outils suivants ? Sont-ils des facilitations de productivité pour le développement ?

• Twitter
• Blogs publics (via des flux RSS)
• Comptes publics de messagerie instantanée (Skype…)
• Facebook (que je ne connais pas assez)
• E-mail
  

À mon sens, ces outils, dont j’aurais bien du mal à me passer, notamment Twitter avec twhirl, maintiennent un certain éveil, une certaine acuité. Ils nous permettent d’apporter, de recevoir, de nous ouvrir, ils participent de la confiance et de l’estime.

Seulement, en terme de pure productivité, l’élément important est l’acuité. Ainsi, se concentrer quatre heures sur un bouquin ou une doc en ayant éteint tous ces outils, sera plus profitable à un moment donné que fureter sur le même sujet sur internet. Il ne faut pas gérer sa productivité uniformément, mais selon les caps à franchir.

Conclusion

La productivité s’appuie sur un environnement, des outils et des pratiques, et est liée par feedback à la motivation (feedback dans les deux sens). Elle peut être favorisée ou handicapée par la nature de ces différents éléments. Les éléments en gras ci-dessus constituent une check-list empirique d’éléments à prendre en considération.

La productivité se jauge continuellement. Outre la quantité de travail abattue, un signe de bonne productivité et d’efficacité est l’agilité.

Encore une fois, tout cela vaut comme mon avis personnel. Si vous avez des réflexions ou des pointeurs sur le même sujet, je serai heureux d’en discuter.

Simplicité, deuxième

Que voit-on à l'entrée de votre entreprise ?





À ma gauche, 1, Infinite Loop (Apple). À ma droite...

Je trouve ça excellent.

Via Sanji.

Blog sur Garonne, 4 mars 2008

Bon ben oui, j'y étais, à l'édition de mardi dernier de Blog sur Garonne.

C'était évidemment à Toulouse, au « Sur Mesure », anciennement appelé le « Chez Nous ».

On était quoi ? 20 ? 25 ? Dans le petit espace, c'était assez chaleureux. L'ambiance était cool et... jeune.

Allez, un peu de name dropping...

J'y ai discuté avec plusieurs personnes, mais pas tous les présents ! On a pas mal parlé avec Xavier, qui semble très actif sur tel blog politique (UMP). Adresse = ?. J'ai pu revoir avec plaisir Maxime Garrigues (rencontré au Déjeuner sur web 2.0) qui comme d'hab' déchire. Cédric Giorgi. Benoît Ramus, de NetOcéan, m'a parlé des deux versions de sa boutique Boatiful, version e-commerce et version vraie boutique toulousaine. J'ai trouvé la démarche logique et excellente. Bien, de voir des projets qui grandissent. Guillaume Beuvelot (PME Performance), était là aussi... Ah, et je n'ai fait que croiser Pierre-Olivier Carles, de FoolInvest.

Cette soirée était vraiment sympa. Les gars ont un très bon état d'esprit. Conquérant, positif, beaucoup d'écoute. On sent très bien le côté « ce que tu m'apprends m'enrichis ». Et le respect. La pratique des blogs est civilisatrice, par définition.

Côté réseautage, je pense que sans téléphone portable / iPhone / Wi-Fi / MacBook Air en poche, je vais encore avoir à échanger quelques cartes de visite papier. C'est d'ailleurs parfois ce qui convient le mieux, car dans l'histoire de la relation ça fait un point d'entrée fixe pour se retrouver, contrairement au nuage de blogs / recherches Google / profils Ziki / MyBlogLog / CopainsDavant / groupes Facebook, etc.

C'est marrant, après ce genre de rencontres on va davantage faire du Follow sur Twitter, éventuellement du lien sur FaceBook (pas mon truc cependant), que faire des mises en relation Viadeo ou LinkedIn. Et suivre directement les liens RSS avec un agrégateur ? It's so 2004... Pour le suivi live de la présence numérique au sein de cette génération, Twitter gagne haut la main. Enfin, disons que c'est vrai pour 2008 Q1 ;-)