Spotify Engineering Culture

Henrik Kniberg communique beaucoup autour de Spotify qui constitue aujourd’hui le gros de son activité !

1ère partie

J’avais partagé précédemment les papiers de Kniberg sur l’agilité à grande échelle et la manière dont Spotify construit ses produits.
Cette vidéo, ou plutôt cette animation nous explique à la fois le cheminement, l’organisation et la dynamique de cette “culture agile”.

Pour résumer plus brièvement cette vidéo, peut-être préfèrerez-vous la fresque ?

image

2nd partie

Ici, Kniberg évoque le « fail friendly environment » qui favorise l’apprentissage ! Ainsi les incidents ne sont clos que quand les laçons en sont tirées, pas à la résolution du problème. Accepter d’échouer, c’est aussi le faire sur une petite échelle afin de pouvoir s’en remettre, d’où les « Limited Blast Radius ».

Le développement des fonctionnalités suit le cycle Lean Startup. Là encore, ce sont des choses qui ont été évoquées dans « How Spotify Builds Products ». Lean Startup signifie aussi focus sur l’innovation, ce qui va à l’encontre de la vélocité trop souvent mise en avant !

100% predictability = 0% innovation

Pour favoriser l’innovation, il y a aussi le 10% « hack time ». La culture est résolument tournée vers l’expérimentation, les choix sont ainsi « data-driven » plutôt que « opinion-driven » !

Parmi les choses qui sont bannies sont les gros projets ! Gros projet signifie gros risques. Essayons donc de les transformer en petits projets !
Autre problème, celui de la croissance, et de la nécessité de trouver le bon équilibre entre bureaucracie et chaos ! Il y a donc des problèmes dans ce monde merveilleux. Mais la culture prévalente est de fixer ces problèmes rapidement. Ainsi :

Une culture saine sait soigner les processus boiteux.

Comme pour la première partie, la fresque est aussi disponible

image

Agilité et hospitalité Libanaise

J’attendais cela depuis un moment, depuis le milieu de l’été pour être plus précis. Car Pierre Hervouet nous avait invité à venir partager avec la communauté Libanaise pour cette seconde édition de l’Agile Tour Liban ! Nous étions donc 4 Français à nous envoler vers le moyen-orient le vendredi matin pour une conférence qui se déroulerait en week-end.

image

La Suisse du Moyen-Orient offre des rivages cernés de montagnes. Le soleil s’y couche vite. Notre premier contact avec Beyrouth se fait au crépuscule. Qu’il s’agisse de quartiers islamique ou chrétiens, la vie nocturne est intense, mais bel et bien quadrillée de militaires ou de policiers dont l’équipement (étrangement semblable) ne laisse aucune place au doute.

image

L’hospitalité Libanaise est réputée, celle de l’hôte de la conférence est plus encore infaillible. Non seulement avons-nous été pris en charge par Rima, l’épouse de Pierre, dès l’aéroport, mais il nous invite dès le soir même à un diner entre speakers étrangers. Bâtiment ancien (il y en a), petite cours intérieure et large parasols de toile, nous laissons la ville nous imprégner de ses charmes.

Bienvenue à l’Agile Tour Beyrouth !

La conférence accueille cette année 130 personnes. Finalement, tous les billets auront trouvé preneur, même si il aura fallu attendre les deux dernières semaines pour en placer la plus grande partie ! Je dis « preneurs », mais je devrais aussi dire « preneuses », car la conférence affiche à vue d’oeil pas loin de 50% de public féminin ! Un sacré changement par rapport à nos conférences Françaises…

image

Le début est prévu pour 9h30. C’est l’opportunité de faire connaissance avec le concept du « 9h30 inch Allah ». Autant dire que nous n’avons pas du tout commencé à l’heure. Pierre Hervouet ouvre la conférence avec le discours d’accueil.

Outre la présentation de la journée, il met cette journée sous le signe du « Shu Ha Ri » … voilà qui met un peu de pression sur ma propre session, qui porte de facto l’emblème de cette journée !

image

Il est temps de présenter le programme, c’est la moment des pitches des sessions ! Nous sommes 14 speakers, ce qui est peu comparé aux Agile Tours Français. L’agilité est encore très peu développée au Liban, aussi n’y a-t-il que 7 présentateurs locaux. Les « internationaux » présenteront 2 sessions. Pour ma part, il s’agira du « Scrum Shu Ha Ri » le matin, et d’un Carpaccio game l’après-midi. Je ne suivrais donc pas beaucoup de sessions de mon côté.

image

En apéritif de la Keynote d’ouverture, nous avons deux sessions au format Lightning Talk, ou plus exactement de Type Pecha Kucha, donc 20 slides avec 20 secondes pour chacun d’entre eux sur une durée totale d’un peu plus de 6 minutes (si vous faites le calcul).

Pierre ouvre le bal.

Agile the Origin, par Pierre Hervouet

Pierre réussit un petit tour de force : nous présenter en 6 minutes, non seulement un bref historique du mouvement agile, mais aussi sa vision de ce qui est important dans l’agile :

  • Les livraisons fréquentes
  • Le focus sur la valeur métier
  • La communication et la collaboration
  • Le « team empowerment »
  • L’amélioration continue
image

Pour conclure, Pierre nous donne un exemple concret et personnel de la mise en oeuvre de ces valeurs : la construction de sa maison !

La vidéo est courte, n’hésitez pas à la regarder en entier. Voici également le support de sa présentation.

Scrum At a Glance, par Joanna Khoury

Il s’agissait lors de ses deux Pecha Kucha de présenter des fondamentaux de l’agile. Ainsi si Pierre nous a présenté les concepts fondamentaux, il revenait à Joanna de présenter Scrum, l’approche agile emblématique.

image

Pas de fantaisies dans cette présentation de Scrum « by the book ».Mais c’est bien ce qu’il faut pour mettre le pied à l’étrier d’une assistance qui en grande partie découvre l’agilité !

The Best Way to Convey Information, par Kimberly Samaha

Quelle est la valeur d’un face à face par rapport à un échange informatisé ? Mais aussi : l’échange informatisé peut-il apporter une valeur que n’apporte pas le face à face ?

image

J’ai eu un peu de mal à relier les fils du propos de l’oratrice, aussi vais-je en livrer quelques uns de manière déstructurée :

L’importance du contexte et de la perspective : Kimberly fait le rapprochement avec l’art, ou comment une partie du vécu de l’artiste transparait dans ses oeuvres (Velasquez, Francis Bacon). Il en va de même pour nous : il y a des éléments de nos intentions dans nos créations !

Arrêter de penser aux personnes comme à des objets : le contact avec d’autres personnes doit plutôt être perçu comme le déclencheur d’une expérience. La notion d’objectivité en prend un coup. Pour Kimberly Samaha, la vérité n’est d’aucune aide contre les perceptions.

Extreme Ice breaking

Joumana nous avait concocté un petit jeu, ou plutôt un grand jeu permettant à de petits groupes de se rencontrer. Autant dire qu’organiser une telle chose, surtout sur un temps limité était le gage d’un beau bordel ! Jugez-en

A mon grand étonnement (mais aussi avec une belle dépense d’énergie), Joumana est parvenu à mener la chose à bien. Je ne pense pas que j’aurais su en faire autant.

image

Ma propre session commence bientôt. Enfin j’imagine, car j’ai complètement perdu le fil de l’horaire.

Scrum Shu Ha Ri

J’avais déjà donné cette session au Printemps Agile, à Caen. Je l’ai un peu modifiée pour l’occasion, mais surtout traduite en Anglais.

image

Je publierai prochainement la vidéo montée lors du Printemps Agile (donc en Français). En attendant, vous pouvez trouver ici mon support de présentation (toujours en Français) et l’article que j’avais rédigé suite à l’évènement de ce printemps !

Agility for Customer Delight, par Mehmet Yitmen

Je n’ai pas regretté d’être resté dans la salle pour la session de Mehmet. Notre orateur est le chef de file de l’agilité en Turquie.

image

A l’aide d’histoires, Mehmet vient nous partager les enseignements tirés des réussites disruptives d’entreprises : comment Fuji, sur la base de sa réussite dans la production de film photographique est devenu numéro un au Japon des produits cosmétiques. Comment Zara à l’aide d’expérimentation et de cycle de feedback courts est-il parvenu à la réussite que nous connaissons.

Je vous invite à regarder cette intervention très inspirante !

Pause déjeuner

Elle sera assez courte, une heure seulement pour savourer l’excellente cuisine Libanaise. Nous aurons néanmoins l’occasion d’y revenir ce soir !

image

Une petite pause pour dévorer des yeux aussi.

image

La salle ouvre sur un balcon, un oasis de fraicheur.

image

Et voilà, c’est déjà fini ! Je vais rejoindre la session de Fadi Jeanbart.

Improve your Public Speaking Skills, par Fadi Jeanbart

Fadi est chanteur d’opéra. Il nous a d’ailleurs fait une petite démo à la fin : il est vraiment chanteur d’opéra, aucun doute ! C’est à la technique Alexander qu’il va nous initier aujourd’hui. Technique que lui-même applique et enseigne pour le chant.

image

Avoir une conscience aiguë de notre corps et comment celui-ci influe sur notre respiration et par voie de conséquences sur notre capacité à maitriser les sons, voilà l’objectif. Nous arriverons juste à prendre conscience de la difficulté du chemin à parcourir. Mais un chemin commence avec un premier pas.

Carpaccio Game

Le temps file à toute vitesse et voici pour moi la dernière session de l’après-midi. Dernière session, car le Carpaccio Game qui j’anime occupe un double créneau.

image

Il nous fallait de nombreuses machines pour l’atelier le plus « geek » de l’après-midi, car il s’agit bien d’un atelier de programmation. Grace à Pierre et aux bonnes volontés des participants, nous y sommes arrivés. Je vous parlais en début de post de la proportion de femmes à la conférence. Je vous laisse constater ce qu’il en fut à mon atelier.

image

Malheureusement, le timing déjà court s’est trouvé raccourcis par les retards pris et la contrainte de la keynote de cloture qui, elle, ne pouvait être décallée !

Keynote de clôture : Ken Schwabber

C’est via Skype que le co-créateur de Scrum a partagé avec nous cette fin d’Agile Tour. Une liaison Internet hélas pas toujours optimale.

image

Je vous laisse découvrir son propos. Il reste assez classique par rapport à ce qu’il nous a habitué. J’ai noté qu’il écornait SAFe au passage. On sait qu’il n’éprouve pas un grand amour pour le framework de Dean Leffingwell. Il défend plus que jamais son approche non prescriptive en regard des pratiques à adopter. Je ne saurias le lui reprocher, et c’est hélas mal compris par beaucoup de praticiens. Au fond, Scrum c’est un peu l’agilité pour les grandes personnes !

Pierre Neis avait hacké le Lean Kanban France pour saluer l’Agile Tour Beyrouth. L’agile Tour Beyrouth tenait à rendre la politesse à l’Agile Tour Brest qui se déroulait peu après.

image

Vous avais-je parlé du charme des Libanaises ?

En finir avec l’Agile Tour

Quand c’est terminé, ce n’est pas encore tout à fait fini : Pierre avait invité son collège de speakers goûter l’excellente cuisine Libanaise. On commence par se chauffer dans un bar en ville, on se croirait en France !

image

Soirée chaleureuse entre speakers. On échange nos impressions, nos expériences.

image

Comme si cette splendide hospitalité ne suffisait pas, nous avons aussi eu droit à des souvenirs : un petit livre édité par Rima et la série de sous-verres « Shu Ha Ri » ! Et je ne parle même pas du régal pour les yeux et le palais que fut ce dernier repas…

image

En attendant le retour…

Nous étions quelques uns à choisir de rester une journée supplémentaire sur place. Nous n’avions juste pas prévu le marathon de Beyrouth qui se déroulait ce dimanche. Début des hostilités à 5 heures du matin avec la musique à fond ! En regardant par la fenêtre, ça n’a pas l’air de courrir des masses. En fait, on semble plutôt se balader !

image

Pourquoi ne pas y aller dans ces conditions ? Pierre Neis et moi-même nous sommes donc joins à la fête. Fête est le mot approprié : tous les 200 mètres, il y a un podium avec de la musique à fond et des pom-pom girls. En fait, le marathon, c’est juste une autre occasion pour faire la fête.
Je vous laisse admirer vos serviteurs en pleine souffrance dans cet exercice…

image

Amr et Mohamed nous ont accompagnés dans une balade sur la côte offerte par Pierre Hervouet. car vous savez, on est peut-être en Novembre, mais au Liban…

align=“center”image

Une petite ballade dans les grottes de Jeita (avec Marc Cerrone que Pierre Neis a reconnu !). Un dernier diner ensemble. Il est temps de rentrer à la maison. Goodbye Liban, ce fut une conférence et un séjour exceptionnel !

image

La résistance contre l’ISO 29119 s’organise !

Au départ…

Les agilistes ne sont guère friands de normes et autres standards. Généralement, nous nous contentons de les ignorer. Néanmoins ils sont souvent utiles.

C’est en proclamant l’utilité des standards, de la plupart des standards que James Christie commence sa présentation lors de la conférence CAST 2014, celle par laquelle tout a commencé. Car c’est contre les standard de test que s’élève le présentateur. Son propos rappelle celui de Dominique Dupagne dans La revanche du rameur qui clame que standardiser les processus n’assure en aucun cas la qualité du produit, qu’en fait il s’agit même d’une bonne occasion pour s’en désintéresser !

La question de considérer l’activité de test comme un « commodité » tend à donner une dimension directement économique à ce travail, ce que l’orateur juge trop simpliste (il a lui-même un diplôme en économie). De manière générale, il est d’ailleurs toujours possible de trouver une théorie économique correspondant à ce que l’on cherche à prouver ! James Christie nous ramène lui à Adam Smith, le père du capitalisme et ses 3 facteurs économiques : le travail, le capital, la propriété.

En alignant les processus de tests, les organismes de normalisation servent les cabinets de conseils qui pourront ainsi vendre du conseil sur ces processus normalisés. Les éditeurs devront eux dépenser de l’argent pour se conformer aux normes. Finalement, le consommateur y perdra aussi, car le focus des éditeurs se déplacera de la qualité du produit vers le respect des normes de processus !

La standardisation de l’activité de test nous amènerai vers une « licence » de testeur qui ne serait en aucun cas gage d’efficacité, ce que l’orateur trouve effrayant ! Imaginez un chirurgien : elles-vous jugez de sa qualité du fait du suivi d’un standard ou du nombre de personnes qu’il tue ? Le focus de ces standard est la documentation plutôt que le test réel !

Un autre point soulevé par James Christie est celui de l’asymétrie de la connaissance : plutôt que de communiquer la connaissance à celui qui en a besoin, le standard masque celle-ci par un écran de fumée. Il se réfère aussi aux pratiques d’audit : celles-ci disent qu’il n’y a pas 2 contextes IT semblables, ce qui rend caduque toute idée de checklist générique (institute of internal auditors). Les standards promeuvent plutôt une idée de « sauver ses fesses » en suivant celui-ci à la lettre afin d’être irréprochables !

Finalement l’orateur exhorte le publique à garder ouvert ce début contre l’ISO 29119, car l’absence de consensus seulement permettra de le remettre en cause.

Au fait, c’est quoi l’ISO29119 ?

Tout d’abord, la parole à l’avocat de la défense, Stuart Reid, avec cette introduction à l’ISO 29119

L’ISO 29119 se veut un consensus sur la manière de procéder des tests, c’est une démarche normalisée comprenant définition des processus et de la documentation. Elle est déjà mise en oeuvre par certains cabinets de conseil.

La résistance s’organise

Tout d’abord avec un manifeste, initié lors de cette même conférence CAST 2014 !

image

Une pétition fait suite à cet acte de foi. Difficile toutefois de s’opposer au corporatisme, mais cette communauté a choisi aujourd’hui de ne pas se laisser faire !

Je voulais saluer ce mouvement, bien que n’étant pas testeur, non seulement pour leur courage de défendre leurs idées, mais surtout parce qu’ils ont raison !

Autres ressources

Note de lecture : Building Web Applications with UML 2nd edition, par Jim Conallen

Note : 6 ; Pas les progrès espérés de cette seconde édition considérablement étoffée, mais avec une notation qui continue à se rapprocher de Rational plus que de UML / MDA

Seconde édition d’un ouvrage paru en 2000, ce volume considérable (450 pages), dont un tiers est consacré aux annexes. La première édition montrait une ébauche de profile UML pour les applications Web. Depuis un certain nombre de spécialisations ont vu le jour, notamment dans le monde JEE. Voyons ce qu’il en est.

Comme je l’ai dit, le corps principal du livre compte 300 pages, repartis en 2 parties et découpé en 12 chapitres. La première partie est consacrée à la modélisation des technologies relatives au Web et rassemble les 5 premiers chapitres. Le premier chapitre sert d’introduction et couvre 3 pages, n’en parlons pas. Le chapitre 2 est en fait la réelle introduction. Sur 20 pages, il fait le point sur les principales technologies et protocoles qui sont le quotidien des applications Web à la date de l’ouvrage. C’est plutôt bien écrit mais on y apprend pas grand chose.

Le chapitre 3 s’intitule « dynamic client ». On y évoque tout ce qui tourne autour du DOM, et ce n’est pas particulièrement superficiel. Il y a quelques tentatives timides de modélisation. Il est dommage qu’elles soient timides, car elles sont plutôt originales et bien pensées. C’est un chapitre court de 10 pages.

Les 20 pages du chapitre 4 s’intéressent à ce qu’il y a au-delà de http et HTML. En l’occurrence RMI, DCOM et SOAP. Plus de focus sur la technologie que sur la modélisation. Mais l’auteur nous gratifie quand même de quelques schémas d’architecture à la sauce UML.

Enfin, le chapitre 5 clôt cette première partie. C’est de sécurité qu’il est question sur 22 pages, avec à la clé encryptions, firewalls, etc. Là encore le soutiens UML est éparse. Pourtant Jim Conallen est le seul auteur que j’ai vu faire usage des collaborations paramétrées, intelligemment qui plus est !

La seconde partie est consacrée à la modélisation d’applications Web. Elle débute par le chapitre 6, probablement celui que je juge le plus hors-sujet. On en prend quand même pour pas loin de 40 pages. On y parle de processus de développement, et de métamodèle de processus. Le tout très emprunt d’Unfied Process. Guère passionnant.

La définition de l’architecture, sujet du chapitre 7 qui accuse un peu plus de 25 pages, utilise la représentation 4+1 vue de Philippe Kruchten. On y est moins hors sujet qu’au chapitre précédent. Mais le sujet aurait pu être mieux traité. D’autant qu’il révèle peu de spécificités Web.

C’est de requirements et donc de cas d’utilisation qu’il est question au chapitre 8. Les 25 pages de ce chapitre nous permette d’asseoir l’étude de cas, mais n’offrent aucun élément nouveau par rapport aux approches classiques. A contrario, on ne peut reprocher au chapitre 9 consacré à l’UX d’être classique ! Ce sont 25 pages également qui traitent essentiellement de « navigational maps » représentées en UML !

La vingtaine de pages du chapitre 10 consacrées à l’analyse font le pendant du chapitre 8. Là non plus rien de neuf sous le soleil. Ce qui est dit ici se retrouve dans la prose de Doug Rosenberg. Les 30 pages du chapitre 11 dédié à la conception montrent bien d’avantage de créativité dans l’utilisation d’UML dans un contexte Web, notamment dans l’usage de composants stéréotypés. Le chapitre « conception avancée » qui lui fait suite est de la même veine.

Le corps de l’ouvrage se termine sur un chapitre « implémentation » qui apporte bien peu au paysage UML dressé par l’auteur.

Enfin, les annexes forment un solide manuel de référence au profil développé par l’auteur.

J’attendais donc de cette nouvelle édition qu’elle converge d’avantage vers le métamodèle UML et qu’elle fédère la notation Web commune aux différentes technologies Web (HTML, XML, .Net et J2EE, notamment, mais aussi PHP et autres technologies spécifiques). Au lieu de cela, l’auteur a choisi de se rapprocher d’une notation orientée analyse s’appuyant sur Rational Rose et convergeant graduellement vers le processus « Iconix » de Doug Rosenberg, même si cela reste inavoué. Cela signifie bien sûr que l’on ne voit ni le signe d’une approche fédératrice des annotations UML pour le Web, ni d’un support MDA pour les applications Web.

Dix ans après, l’ouvrage mériterait un 3ème édition. Tout d’abord, le talent de Jim Conallen pour développer un profil UML créatif et pertinent est réel. Cet ouvrage pourrait laisser tomber l’aspect process qui apporte bien peu et se pencher sur les nouveaux aspects des architectures Web modernes : si le MVC reste important de nouvelles approches existent, utilisant les approches réactives, le REST et les librairies JavaScript avec HTML 5 !

image

Référence complète : Building Web Applications with UML, second edition – Jim Conallen – Addison Wesley 2002 – ISBN: 0-201-73038-3; EAN: 978-0-201-73038-8

Building Web Applications with UML


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

The SCRUM Development Process

Cet article est réellement le premier à présenter Scrum, c’était en 1995. Petit détail que j’ignorais, Ken Schwaber l’a mis en oeuvre pour le développement de Delphi ! Déjà l’auteur présente son approche comme étant « boite noire » et empirique, bien adapté au développement de systèmes complexes. Et oui, Scrum est bien en rapport avec le Rugby !
Bien sûr, à cette époque, il n’était pas encore question du mot « agile ». Ken Schwaber situe Scrum comme une évolution des procesus itératifs, non comme une disruption.

Quand il parle du développement logiciel, c’est toujours à la notion de complexité que revient l’auteur. Il la définit comme suit :

Complexité = f(dev. environnement var. + target env. var.)

Toutes ces varaibles changeant par ailleurs au cours du projet.

Quand il compare Scrum aux procesus classiques, Ken Schwaber ne se contente pas de le comparer au cycle en cascade, déjà il met en évidence que la nature intrinsèque du modèle en spirale de Boehm est identique au cycle en V en cela que l’approche reste linéaire par essence ! Il pousse même ce raisonnement vers les processus itératifs dont il met en évidence qu’ils restent aussi « linéaires ». Une démarche qui reste incomprise de beaucoup plus de 20 ans après ! Car toutes ces méthodes sont basées sur l’illusion que le processus de développement peut être défini !

La méthodologie Scrum

Dans cet article, Ken Schwaber présente Scrum comme structuré en 3 phases

  • Planning et architecture système
  • Sprints
  • Clôture

Une structure que l’on ne retrouvera guère par la suite. Si la 1ère et la dernière sont des phases « définies », l’auteur qualifie la phase des sprints « d’empirique ». Notons aussi que l’auteur inclut dans la phase de clôture un « pré-release testing »… qui va à l’encontre du « potentially shippable » dont on parle aujourd’hui (et dont il ne parlait pas à l’époque) ! Par contre la durée des sprints est présentée simplement comme allant de 1 à 4 semaines, et non 30 jours (ou moins) ! Bref, comme on dit, c’était mieux avant !

A cette époque, on ne parle pas non plus encore « d’inspect and adapt » et donc encore moins de rétrospective !

Au niveau de la structure d’équipe, on ne reconnait guère la description actuelle : un management et des équipes de 3 à 6 personnes (donc l’équivalent de feature teams), responsables de sous-ensembles du backlog ! On ne parle pas encore de Product Owner.

Une emphase importante est mise sur l’utilisation des technologies objet, qui apportent la flexibilité nécessaire à une mise en oeuvre réussie de Scrum.

Les estimations se font en utilisant les points de fonction. Mais … Ken Schwaber met en garde sur la productivité qui est au moins le double du standard ! Sacré garnement !

Scrum an tant que processus

Dans cette partie, l’auteur rentre d’avantage dans la théorie des méthodes de développement, comment elles se définissent par le biais de métamodèles et en quoi il est important de reconnaitre si elles sont définies ou empiriques. Cela permet à l’auteur de revenir sur l’inadéquation des processus théoriques par rapport aux systèmes complexes sous un autre angle.

Et de conclure cet article !