OSGi en mode natif et ployglotte

Parlons net : aujourd’hui OSGi est la seule alternative qui marche à la pantalonnade “Java Modules” qui ne cesse d’être repoussée de version en version de Java. On ne saurait affirmer que nous les auront pour la version 9, mais on sait déjà que les développeurs n’auront pas accès à l’écriture de modules.

OSGi marche et depuis longtemps. Par le biais de la RFP156, cette “SOA ina JVM” n’entends pas rester cantonnée à un rôle de faire-valoir par rapport à Java Module, mais à s’étendre à d’autres environnements et langages. Sont principalement visés: C, C++ et Javascript ; mais les autres environnements sont évidemment bienvenus.

Les participants à cette RFP font tous partie des mondes C et C++; en l’occurence Celix ©, CTK plugin framework (C++), NOSGi (C++) et CppMicroServices (C++).

Cette RFP est assez sommaire, voir superficielle. Elle fait le point sur les travaux des différentes équipes et s’en sert comme base pour les requirements listés à partir de la page 9.

Et sur les autres fronts

Il y a aussi un projet sur GitHub mais il ne semble pas bouger depuis au moins un an.

Mais on n’en reste pas là. Le Polyglot OSGi fait son chemin, comme nous le démontre cette présentation

Et après le RFP 156 centré sur C++, cet article fait le point sur OSGi pour Javascript, incarné par la RFP 159 (mais celle-ci reste un brin creuse).

Le choses bougent avec une réelle volonté côté OSGi ; Elles bougent au moins aussi vite que ne s’enlise ces java Modules, pas encore là et déjà vidés de leur substance…

L’agilité à grande échelle chez Spotify, par Henrik Kniberg & Anders Ivarsson

Dans cet article, les auteurs décrivent la façon dont Spotify est parvenu à maintenir une dynamique agile malgré une montée en taille importante et rapide sur les 6 dernières années. Elle s’appuie sur un petit nombre de concepts organisationnels

Les squads

A mi-chemin entre la Scrum Team et la Feature Team, le squad est doté d’une mission sur le long terme, possède un espace de travail en propre et regroupe toutes les compétences nécessaires à sa mission. Son mode de travail s’inspire du Lean Startup, mais ici on appelle cela “think it, build it, ship it, tweak it”. Les squads bénéficient aussi des 10% hack days inspirés des 20% ou des exploration days de Jurgen Appelo (c’est la même chose).

L’objectif, sinon la clé est d’avoir des squads autonomes.

Les tribus

Les squads sont nombreux : il y en a 30 chez Spotify. Ils sont regroupés en tribus. Une tribu est focalisée sur une problématique métier particulière est fonctionne un peu en “incubateur de startup”. Elles sont de taille variées mais ne dépassent pas 100 personnes.

Les tribus organisent leur propres rassemblements et partagent outils, idées, etc… 

Les chapitres

Ce sont des regroupements “transverses” de personnes de même domaine d’expertise. Ils se rencontrent régulièrement pour partager outils, expérience, challenges, etc.. Chaque chapitre est géré par un manager qui est de fait le responsable hiérarchique de ses membres … mais est lui-même membre d’un squad avec des responsabilités opérationnelles ! Les chapitres sont locaux aux tribus.

Les guildes

Ce sont des communautés d’intérêt, plus informelles que les chapitres. Elles sont transversales à l’entreprise et regroupent souvent les chapitres correspondant des différentes tribus. L’animateur d’une guilde l’est à temps plein. 

Là aussi, la lecture du Management Workout de Jurgen Appelo peut être instructive…

L’organisation dans son ensemble

Elle est en quelque sorte matricielle. La dimension dominante est celle du “quoi”, l’axe opérationnel, donc les squads et les tribus. Il y a une seconde dimension, celle du “comment” qui correspond aux chapitres et aux guildes.

Et bien d’autres choses…

Voilà, il s’agit juste de l’apéritif pour vous encourager à lire cet article par ailleurs fort bien écrit et illustré. Il y a de nombreux éléments que j’ai passé sous silence, comme la gestion des dépendances entre les squads.

Spotify est une entreprise dont la structure dominante est tournée vers l’opérationnel. Elle rompt avec les structures traditionnelles orientées compétences qui fragmentent l’organisation en silos, obligeant les projets à franchir les obstacles entre ces silos, consommant temps et énergie et souvent aussi hélas, vidant les projets de leur substance !

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

De l’agilité pour mon projet, pour quoi faire ?

J’avais évoqué lors de mon teasing de la DevFest 2013 la présentation que Martin Mouterde et moi-même y ferions. Vous trouverez le support de cette présentation ici.
Préparer une présentation à quatre mains n’est pas un exercice facile. Comme j’ai des idées tranchées et personnelles (mais pas nécessairement bonnes, toutefois) de ce à quoi devraient ressembler des présentations, il reste improbable que je sois réellement satisfait du résultat. Ne comptez toutefois pas sur moi pour dire qui a engendré quoi.
J’ai hésité à modifier cette présentation avant de la poster. Finalement je me suis dit qu’elle devrait figurer telle qu’elle a été jouée () . Même si je la modifie de manière substantielle si je sui amené à la rejouer…

Les fondations de l’approche waterfall

L’article qui suit, écrit en 1970 par Winston Royce, le père d’auteur du Software Project Management dont j’ai écrit la note de lecture est réputé comme l’article original décrivant le processus en cascade.
Il est aussi pointé du doigt comme dénigrant en fait cette approche en cascade !
La vérité est entre les deux, car Winston Royce dit bien qu’il croit dans le fameux diagramme de la figure 2, mais qu’il le trouve “très risqué”. Le reste de l’article est une description de ce que l’auteur propose pour dé-risquer cette approche. Cela comprends :

  • Des documentations à différentes étapes.
  • L’injection de simili-itératif entre étapes adjacentes.
  • L’implication des utilisateurs

Bien sûr les concepts sont passés de mode et l’article n’est pas non plus extrêmement facile à lire. Mais ça se fait quand même…

Andy Hunt: Uncomfortable with Agility: What has Ten+ Years got us?

La propriété fondamentale de l’agilité est l’aptitude au changement, la capacité d’évoluer en utilisant le feedback comme moteur de cette évolution.

Nous découvrons de meilleures façon de travailler … tels sont les premiers mots du manifeste agile. Ils ne disent pas “nous connaissons”. Alors pourquoi l’agilité a si peu évolué ces 12 dernières années ? Nous restons ancrés sur XP et Scrum, peut-être un peu mâtiné de Lean…

Andrew Hunt revient sur ce que signifie être agile, et non “faire agile”. Une présentation qui retourne au coeur de l’état d’esprit agile, par l’un des auteurs du manifeste.

Facile à bien utiliser, difficile à mal utiliser, la présentation

En attendant que j’ai le courage de la terminer sous forme d’article, voici les slides de ma présentation à l’Agile Tour Bruxelles.
Cette présentation est directement inspirée d’un conseil de conception de Scott Meyers : “Make your interfaces easy to use correctly and hard to use incorrectly”. Sur ce, je vous laisse vous essayer aux quizz contenus dans cette présentation !