En finir avec …

Mare du dogmatisme ? Besoin de fraicheur ?

Cet été je vais me métamorphoser en grand sacrilège du Scrum ! Non que je ne crois plus en Scrum, mais plutôt que je voudrais m’insurger contre une utilisation un peu mécanique de la méthode qui va à l’encontre même de l’agilité

En finir avec les zombies !

Je vais intitulé ma série d’article “en finir avec …”. Pour l’instant je n’en ai écrit aucun, j’espère que j’arriverais à tenir ce que je dis. Je ne m’engage pas sur un nombre d’article, vous verrez bien ce qui arrivera, mais ça arrivera entre maintenant et la mi-spetembre, qu’on se le dise. Ca vous oblige aussi à rester à l’écoute, du moins ceux qui pensent que je peux les intéresser.

Mais pourquoi “en finir avec” ?

Par provocation, d’abord !

Ensuite pour stigmatiser que rien n’est coulé dans le béton. Les éléments constitutifs de Scrum ne sont ni une fin en soi ni une justification. Ce sont juste des moyens, un guide pour faire des projets agiles. Si je dois choisir, je préfère un projet agile sans Scrum, qu’un projet déguisé qui s’auto-proclame agile (mais qui ne l’est pas) sous couvert de backlog, product owner, stand-up, etc…

Pensez plutôt que d’appliquer !

Je constate, et hélas je ne suis pas le seul, une augmentation des projets Scrum Canada Dry. Peut-être est-ce le prix à payer pour cette extension rapide de Scrum que nous observons aujourd’hui ? Beaucoup d’organisation dépourvue d’ADN agile tentent l’agilité en mimant ses rituels. C’est le “cargo culte”.

Mon but est de réagir, de nous éloigner de l’aspect rituel afin de nous concentrer sur l’aspect fondamental et initial de l’agilité. Je ne le ferais pas en citant une nouvelle fois le manifeste agile, bien que j’avoue que ce soit un bon moyen mais en faisant oeuvre active de déconstruction !

Attention, ça commence bientôt …

Action !

Ce prologue va me forcer à entrer en action, car je n’ai encore rien rédigé. Voici donc l’agenda :

  • A partir de la semaine de cet été jusqu’à la mi Septembre, une série de posts sur ce thème ! Je ne sais pas encore combien, cela va dépendre de mon courage et de mon inspiration.
  • Une proposition de Lightning talk pour l’agile tour nantes ! Ca c’est pour très bientôt, mais les délibérations pour l’acceptation des sessions ne seront connues que le 17 Septembre. J’ai horreur du travail à la chaine, je ne soumet donc mon sujet qu’à un seul évènement, avec l’espoir qu’il sera retenu. Nous verrons bien.

A très bientôt !

Vie artificielle épisode 13 : l’émergence

En écho ou plutôt sur le même sujet que mon Lightning Talk, cet épisode du Podcast “Vie Artificielle” propose quelques reflexions sur l’émergence par rapport au déterminisme comme mécanisme fondamental de l’évolution.

Vie artificielle épisode 13 : l’émergence

Note de lecture : The Usability Engineering Lifecycle, par Deborah J. Mayhew

Note : 8 ; Book of the year 2000! Un processus complet et à l’ancienne pour l’interface homme machine, complété d’un matériel prêt à l’emploi.

L’ergonomie fait, partie du recueil des besoins est rarement intégrée au processus de développement logiciel. C’est là une grande part du mérite de cet ouvrage: proposer un processus complet de gestion des exigences ergonomiques intégré à la capture des besoins fonctionnels par le biais des Use Cases. Oui, c’est vrai je viens de parler de processus et cela a une odeur pas très agile. Et effectivement dès les premières pages l’auteur propose un « usability lifecycle » qui ferait facilement froid dans le dos. Nous pouvons nous y arrêter un peu car ce cycle de vie structure le livre lui-même.

  • La première étape est le recueil des besoins. Elle est couverte par 6 chapitres sur 160 pages. Elle couvre les 4 facettes identifies de cette étape : l’analyse des profils utilisateur, l’analyse des tâches, les objectifs d’utilisabilité et les principes généraux de l’IHM.
  • La seconde étape est bien plus dense car le schéma du processus nous montre pas moins de 7 sous étapes regroupés en 3 cycles internes. C’est presque une surprise de voir cela couvert en seulement 180 pages, sur 10 chapitres ! Les activités proposées vont du modèles conceptuel à la reconception des tâches en passant par la conception d’écrans.
  • La dernière étape a trait à l’installation. Il n’y a qu’un seul chapitre, mais il fait 50 pages ! Cette partie couvre le feedback utilisateur.
  • Enfin une dernière partie de l’ouvrage est consacrée aux aspects organisationnels. Elle est longue de 100 pages sur 4 chapitres avec en plus des aspects strictement organisationnels, l’évocation de la planification de projet ou la justification des coûts (une des spécialité de l’auteur).

Au total, le livre est quand même très lourd, car il totalise 560 pages ! Sa structure est entièrement guidé par le processus proposé par l’auteur ce qui tend à rendre la prose très longue, je l’ai déjà constaté. Ce fil extrêmement rigide est tout sauf agile. Mais le contenu est loin d’être inintéressant. En effet le texte est méritoire par le fait qu’il accompagne chaque activité proposée du processus de gestion des exigences d’artéfacts (plans types, questionnaires, etc…) et de guidelines immédiatement applicables. J’ai rarement vu des livres donner autant de matière directement utilisable.

Chaque chapitre traite des aspects de la spécificité des applications Web dans une section et propose des “activités alternatives” si le processus a besoin d’être abrégé.

Outre que le livre reste très lourd (même en considérant le matériel inclus) et qu’il est structuré par un processus très rigide, il prend aussi un sérieux coup de vieux avec la seconde vague du Web. Mon conseil ? Prenez du recul par rapport au texte, démontez les morceaux du processus. N’utilisez pas le processus, mais réutilisez les morceaux, les idées et la matière première d’une manière plus légère et plus agile. L’auteur a beaucoup d’expérience et de savoir-faire dans son domaine qu’il serait dommage de snober.

Un très bon ouvrage que je recommande fortement, surtout si vous n’avez pas de connaissances préalables dans le domaine de l’ergonomie.

usability-engineering-lifecycle

Référence complète : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman publishers 1999 – ISBN: 1-55860-561-4; EAN: 978-1-558-60561-9

The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design


http://www.goodreads.com/book/add_to_books_widget_frame/1558605614?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Evaluation des compétences et suivi de carrière

Comment évaluer et donner un sens au suivi et à l’évolution de carrière en informatique ? La traditionelle approche de l’escalade de l’échelle hiérarchique n’a pas réellement de sens et n’intéresse généralement pas les informaticiens. De plus il n’y a pas de place pour tout le monde sur cette foutue échelle.

Cette présentation date d’il y a 8 ans (déjà…) et propose une approche inspirée du SWEBOK et du “Professionnal Software Development” de Steve McConnell au sujet duquel j’avis déjà posté une note de lecture.

Note de lecture : Practices of an Agile Developer, par Venkat Subramaniam & Andrew Hunt

Note : 3 ; Le petit frère simplet du « pragmatic programmers »

Tout a-t-il été dit sur le développement agile ? Si l’on est en droit d’en douter, la lecture de ce livre nous laisse penser le contraire. Car, franchement, à la lecture de cet opuscule on ne voit rien de neuf. Donc, je suis déçu, et étonné d’être déçu en ayant constaté qu’Andrew Hunt avait cosigné ce livre ! Au-delà d’une introduction et d’une conclusion destinés à parler de la migration vers l’agilité (mais sans propos utiles, je dois dire), le texte se compose de 7 chapitres :

  • Begining agility : Donne des pistes sur le « par où commencer », et comment se comporter au sein de projets agiles.
  • Feeding agility : Aborde les points sensibles, les « accélérateurs agiles », destinés à faire passer les projets à la vitesse supérieure.
  • Delivering what users want : Aborde le point crucial de la réalisation du projet par rapport à la demande utilisateur ; comment prioriser et comment obtenir du feedback.
  • Agile feedback : Aborde spécifiquement l’aspect retour d’expérience, comment mesurer les progrès et estimer la qualité et la pertinence de ce qui est réalisé.
  • Agile coding : Traite des pratiques liées au codage. Ces pratiques se rapprochent de celles de l’extrême programming.
  • Agile debugging : Ce chapitre se focalise sur la recherche des anomalies, mais aussi sur la façon d’en garder trace et de les capitaliser.
  • Agile collaboration : Donne des indications sur les façons d’interagir au sein d’une équipe de développement, mais aussi hors de cette équipe de développement.

L’ouvrage, bien Que découpé en chapitres est essentiellement constitué d’un ensemble d’items, traités de façon similaires : tout d’abord les auteurs énoncent l’anti-pattern (illustré d’une icône représentant un diable). Il s’en suit une discussion sur le sujet pour expliquer le bien fondé d’opérer différemment. Les auteurs énoncent ensuite une contre-proposition (illustré d’une icône d’ange). L’item se termine par deux paragraphes : le « what it feels like » expose les conséquences du changement opéré, tandis que le « keeping your balance » donne les pours et contres de l’item, en mettant l’accent sur les facteurs défavorisant qui peuvent être rencontrés.

En conclusion, ce court opuscule de 170 pages n’est guère une lecture indispensable. Bien au contraire, on lui préfèrera son grand frère, le « Pragmatic Programmer ».

practices-agile-dev-pragprog

Référence complète : Practices of an Agile Developer – Venkat Subramaniam & Andrew Hunt – Pragmatic Bookshelf 2006 – ISBN : 0-9745140-8-X

Practices of an Agile Developer: Working in the Real World

http://www.goodreads.com/book/add_to_books_widget_frame/097451408X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

http://www.goodreads.com/book/add_to_books_widget_frame/1934356816?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Reducing Requirements to EIS Specifications Gap using RM-ODP Viewpoints

Oui, je peux assumer ce que j’ai écrit là ! Il s’agit d’un modèle de traçabilité entre expression du besoin et modèle d’architecture. Have fun !

Voici également le lien vers ce papier dans Issuu