15 Nov 2017, 00:05

The Phoenix Project

Cette année, il y a 2 contenus pour lesquels j’ai eu un effet “Whaou” :

  • Le hacker, ce héros : comment être un bon growth hacker : si le titre est plutôt mal choisi, la vidéo fait réflechir sur la tendance à l’over-engineering que l’on a tendance à appliquer vs “le juste ce qu’il faut quitte à améliorer plus tard” de la startup ou du hacker. Le code généré n’est peut être pas à l’image de l’état de l’art mais il est en production, permet de vendre le produit et d’avoir des retours. Quand on sort d’un grand groupe pour faire des missions dans des petites structures, cela fait définitivement réfléchir.
  • The Phoenix Project : sous la forme d’une fiction, le livre sensibilise à la transition d’une équipe IT puis d’une entreprise vers une démarche DevOps/Lean/Agile mais pas uniquement pour faire face aux défis que doit relever l’entreprise.

Il y a les 3 principes :

  • 1er principe : maitriser le flux de bout en bout depuis la phase de développement jusqu’à la mise à disposition à l’utilisateur. Pour optimiser ce flux, il faut des petites itérations et avoir en objectif un but global à l’entreprise (et non local à l’IT). Par ailleurs, on évite les retours en arrière dans le processus, cela est signe d’un dysfonctionnement. Il faut voir le flux comme uni-directionnel allant du développement vers l’utilisateur. Les pratiqes associées tournent alors principalement autour de l’intégration continue et du déploiement continu.
  • 2nd principe : avoir une boucle de feedbacks permanente permettant de faire de l’amélioration continue. Cela permet d’améliorer la qualité du code source et de créer/formaliser la connaissance autour du projet. La pratique consiste donc à mesurer/évaluer les différentes étapes et à les faire évoluer au fur et à mesure.
  • 3ème principe : créer une culture qui permet l’expérimentation en permettant la prise de risque & des apprentissages rapides d’une part et d’autre part en considérant que la répétition et la pratique sont requis pour avois plus de maitrise et de confiance dans le process.

Il y a 4 types de travail dans l’IT :

  • Les projets métiers,
  • Les projets internes à l’IT
  • Les changements
  • Le travail innatendu (incidents, activité non planifiée, etc)

Il y a alors 4 enjeux :

  • Identifier et rendre visible ces 4 types de travaux afin de pouvoir s’organiser, estimer son travail et planifier en conséquence,
  • Garder le contrôle / Maitriser le travail innatendu vu qu’il est le plus perturbateur et apporte le moins de valeur. Quand on travaille sur ce travail innatendu, on perd du temps sur les 3 autres types de travaux.
  • Identifier le “Work in process”, à savoir le travail en cours et qui mobilise alors tout ou partie de la chaine de travail. Les analogies avec la gestion d’une usine permettent d’avoir une meilleure vision des choses et rendre nos flux IT plus concrets.
  • Identifier les contraintes et faire en sorte de les réduire/lever.

On retrouve également le thème habituel des démarches Agiles/Lean/DevOps avec tout le travail autour de la notion de valeur pour l’entreprise et pas uniquement pour la partie IT. Il faut se concentrer sur des éléments apportant de la valeur, de petite taille pour ne pas bloquer la chaine et pouvoir être envoyer en production rapidement. Le livre montre également des contre-exemples comme des contraintes de sécurité que l’équipe cherche à s’imposer alors que le risque d’une part est géré par ailleurs (autres départements) et qu’appliquer des correctifs n’apporte aucune valeur à l’entreprise d’une part et d’autre part compromet sa capacité à avancer.

Une statistique intéressante est celle du temps d’attente d’une personne (time wait) : elle rapporte le temps d’occupation au temps de disponibilité d’une personne. Si une personne est dispo à 5050, le taux est de 1 et il faut attendre 1 unité de temps pour qu’elle fasse la tâche dont vous avez besoin. A l’inverse, une personne occupée à 90% a un taux d’attente de 9 unités de temps. Même si la réalisation de la tâche par cette personne est rapide, il vous faudra attendre 9 unités de temps pour qu’elle le fasse. On crée et identifie alors rapidement des goulets d’étranglements dans votre process de création de valeur qu’il faudra traiter. Pour bien donner l’idée, si un process requiert l’intervention de 7 personnes occupées à 90% du temps, il faudra alors 63 unités de temps pour réaliser l’action.

Au final un livre rapide et agréable à livre. Vous pourrez avoir la sensation que le livre raconte votre project actuel (ou des projets passés) à de nombreuses reprises. Vous pourrez alors évaluer les progrès de votre entreprise au regard des transformations opérées dans le livre et voir si vous êtes en phase ou pas.

Plus que juste l’approche DevOps/Lean/Agile, ce que je retiens de ce livre, c’est surtout l’effort d’alignement de l’IT avec les besoins du reste de l’entreprise et que l’on oublie souvent d’une part et d’autre part les analogies avec le monde de l’usine. Nous considérons parfois à tort que l’IT n’a rien à voir avec une usine et l’on voit bien ces dernières années que cela est faux et que le monde industriel peut nous apprendre énormément de choses et nous faire gagner un temps précieux et ainsi être plus performant et au service des besoins de l’entreprise.

26 Nov 2015, 23:59

Retour sur Codeurs en Seine 2015

Aujourd'hui se tenait l'édition 2015 de Codeurs en Seine ; petit résumé de la journée :

  • Test Drive Infrastructure avec Docker (slides ; code):
    • L'idée est d'appliqué les principes du TDD sur la partie infrastructure (versionning, tests, intégration continue, etc).
    • Différents niveaux de tests possibles
      • Tests unitaires : tests au niveau de la fabrication du container en lui même
      • Tests d'intégration : tests du bon fonctionnement des composants de l'infrastructure
      • Mais aussi tests d'acceptance, tests de sécurité, tests de performance, etc.
    • Développement de docker-unit qui permet de tester la bonne exécution d'un docker build en testant le résultat du Dockerfile à chaque étape.
    • Le projet est basé sur dockramp, il est encore jeune mais l'idée est intéressante. L'auteur du projet doit contacter l'équipe Docker pour voir s'il doit continuer ou si cette dernière a déjà des choses dans les cartons.
  • 5 facteurs clés pour l'auto-organisation : l'auteur revient sur l'organisation d'Agile France qui s'est fait dans un contexte particulier. Il en retient 5 clés :
    • Ownership : il a fallu dépasser sa conception "égocentrique" de l'événement pour en faire l'événement de la communauté pour fédérer tout le monde autour du projet
    • Dialogue : passage de la discussion (bruit++) au dialogue (signal++) ; seules les personnes ayant un intérêt sur un sujet donné ont le droit de donner leur avis et de travailler ensemble. Le bruit ambiant généré par les autres est supprimé en les "excluant" du sujet (ou du moins en ignorant leur "moi je pense que...")
    • Leadership ; en prologement du point précédent, plutôt que de chercher un consensus mou, que les personnes intéressées par le sujet prennent le leadership du sujet et avancent. A noter qu'il n'y a pas d'opposition entre auto-organisation et leadership, c'est le passage d'avis vers des intentions.
    • Artefacts : il s'agit de produire des choses visibles et de s'organiser autour de ces artefacts (réunions, etc)
    • Vision : il faut définir un cadre et communiquer autour de ce cadre.
    • En reprenant de bas en haut, un moyen de se rappeler du mot via le terme VALDO.
  • HTTP/2, les bonnes pratiques du web évoluent ; une présentation rapide de HTTP/1.1 et des apports de HTTP/2 avec les principaux apports (push server, multiplexage, priorité des ressources, compression des entêtes, flux binaire plutôt que textuel et https quasi requis de part le support de http/2 dans Chrome/Firefox) et impacts sur nos pratiques actuelles (plus besoin de domain sharding, de concaténation, de sprites CSS ou d'inlining). Par contre, les optimisations d'images, la compression, la minification et l'optimisation des fontes et la gestion du cache restent de mise.
  • Bidouillabilité à l'ère du numérique : Tristan Nitot qui nous parle
    • des débuts de l'ordinateur où ils étaient bidouillables vs les modèles de plus en plus fermés de nos jours
    • des débuts du web s'appuyant sur des formats ouverts vs des sdk "fermés" où en gros on doit demander l'autorisation de...
    • du cloud (dans le sens des offres SaaS) qui n'est rien d'autres que l'ordinateur de quelqu'un d'autre et sur lequel vous n'avez aucun contrôle, dont le code source n'est pas disponible et qui n'est pas bidouillable.
    • Dans le SaaS, le client est celui qui paye pour les données, pas celui qui les fournit (contre un service "gratuit")
    • Tristan Nitot propose le SIRCUS : Système d'Information Redonnant le Contrôle Aux UtilisateurS et ses 7 principes
      • Pas de publicité ciblée
      • Utiliser du matériel que l'on contrôle (Raspberry, CubieTruck, etc en auto hébergement ou à la rigueur chez un hébergeur)
      • Utiliser du logiciel libre (CozyCloud, Owncloud, YunoHost, etc)
      • Utiliser le chiffrement
      • Une UX à la hauteur
      • Interopérabilité
      • Une killer feature que les offres SaaS ne peuvent fournir
        • A ce sujet, Cozycloud réfléchit à croiser les données qui seraient centralisées dans l'instance (ex afficher les noms des contacts en lieu et place de leur numéros sur la facture téléphonique en croisant la facture avec les contacts)
    • Mes enseignements :
      • Même en étant relativement sensibilité à la gestion des données personnelles, cette conférence donne une claque et montre le chemin à parcourir et les enjeux.
      • Toutefois la question de l'auto-hébergement reste un problème ; comment demander et permettre à Mme Michu d'avoir ses données de façon sécurisée ?
      • Par ailleurs, si CozyCloud arrive à tout concentrer en un seul lieu et à croiser les données, quid en cas d'intrusion sur le systmèe (via un hacker ou un cambrioleur ou des forces de l'ordre à la rigueur ?). Qu'est-ce qui est mieux entre une analyse partielle mais permanente des données chez les GAFA vs un risque faible mais un impact très fort si mon instance CozyCloud par ex est récupérée par un tiers, celle-ci contenant nos données ?
      • Il y a peut être des choses intéressantes à faire dans un contexte CozyCloud + VRM.
  • Apache Drill, le SQL pour Hadoop et plus... :
    • Drill permet de manipuler en SQL tout types de données issues d'un cluster hadoop, d'une base de données SQL/NoSQL, de fichiers CSV, JSON,XML, etc. Il permet même au sein d'une même requête de requêter sur plusieurs sources de données.
    • C'est donc du "SQL on everything" avec une logique de schema à la volée en fonction de la requête. Cela peut être distribué notamment dans un cluster Hadoop.
    • A intégrer dans les outils rapidement...
  • AngularJS, the good, the bad and the transition to Angular 2 :
    • Un talk qui présente les bons et mauvais côtés d'Angular V1, une rapide présentation d'Angular V2 et comment migrer
    • Un livre sur Angular2 est en cours de rédaction ; celui sur Angular V1 est dispo => books.ninja-squad.com ; j'ai la V1 mais toujours pas lu ;-)
    • The Good
      • ngHint
      • eslint + plugin Angular
    • The Bad
      • $scope-soup
      • Eviter les conflits de scope parents/enfants via les "ControllerAs"
      • Performances
        • Utliser les bindOnce pour réduire le nombre de watchers
        • Ajouter des "track by" pour éviter de reconstruire le dom d'une vue sur l'autre si on manipule les mêmes objets
        • Utiliser judicieusement ngIf vs ngShow
          • ngIf : détruit le dom et le reconsruit
          • ngShow : cache le bloc mais si celui-ci contient des instructions qui sont calculées, alors elles le seront quand même
        • ng-model-options pour conditionner le déclenchement du cycle de digest/watcher
      • Fuites mémoire ; rajouter des $scope.on("$destroy" ...) pour faire le ménage
    • Angular2
      • Prévoir de l'écrire en ES2015 ou TypeScript
      • Tout est composant
      • Nouveu modèle de template
        • Web Components compatible
        • Web Workers compatible
      • angular-cli
    • Migration vers NG2 dans le cadre d'un projet NG1
      • Utiliser la syntaxe ControllerAs
      • Utiliser les directives pour initier une approche composant ; Angular 1.5 apportera un début de syntaxe "component"
      • Commencer à écrire en ES6
      • ngUpgrade permettra d'utiliser une syntaxe orientée composant et de les "downgrader" en syntaxe Angular 1.
  • Ionic, le framework mobile hybrid carrément addictif :
    • Application hybride = WebView embarqué dans une application native
    • Ionic = AngularJS + Cordova
    • Plugins ng-cordova pour accéder au matériel et fonctionnalités du périphérique
    • Ionic fournit un ensemble d'outil pour aider au développement et au déploiement des applications avec un modèle économique en cours de définition
    • solution manquant encore un peu de maturité ?

Au final, globalement une bonne journée avec une bonne organisation. La diversité des tracks (agile, technologies, web et Java) permettent de trouver son bonheur et d'avoir un programme à la carte. Une bonne formule en somme.

27 Jan 2013, 15:01

Des 'Feature Teams' à l'échelle de l'entreprise ?

Il y a quelques mois, le Gartner annonçait qu'en 2014, 25% des dépenses IT seront désormais pilotées par le Marketing. Pourquoi pas, après tout avec l'arrivée des solutions SaaS, même si les expériences actuelles montrent qu'elles sont besoin d'être accompagnées pour tout ce qui tourne autour des problématiques de SLA, Sécurité/Confidentialité, Réversibilité, Import/Export de données, Intégration avec le SI, etc.

Il y a quelques mois, j'ai lu "Scaling Agile @ Spotify" qui met en avant les "Feature Teams".

Pour ceux qui ne connaissent pas les Feature Teams :

  • contrairement aux organisations traditionnelles découpées par technologie/composant/expertise (Les architectes d'un côté, les développeurs d'un autre, etc), la feature team est organisée selon une logique fonctionnelle et en son sein toutes les compétences sont représentées/réunies ; le but étant qu'elle soit autonome et suffisante pour la création de la fonctionnalité dont elle a la charge.
  • En soit, je trouve ça fort pertinent dans la mesure où cela permet de maintenir une cohérence d'ensemble dans le développement de la fonctionnalité mais aussi une implication de l'ensemble de l'équipe projet.

Pour revenir à Spotify, l'intérêt du document est qu'il présente comment cela est implémenté _pour de vrai_ :

  • Niveau 1 - le "Squad" : elle ressemble à une Scrum Team classique avec son Product Owner et l'équipe en mesure d'assurer la fonctionnalité avec l'ensemble des expertises nécessaires. Chaque Squad est en charge d'une fonctionnalité sur le long term (Client Android, Player, etc) et développe une véritable expertise sur le sujet
  • Niveau 2 (en vertical) - la Tribu (Tribe) : c'est un ensemble de Squads qui travaillent sur des sujets connexes, regroupé dans un lieu commun et avec notamment des restitutions sur l'avancement de chaque squad et le partage d'expérience.
  • Niveau 3 (en horizontal) - Le "Chapter" : au sein d'une tribu, chaque "Chapter" regroupe des personnes ayant la même expertise/compétence afin qu'ils puissent s'entraider / partager entre eux : testeurs, développeurs, etc.
  • Niveau 4 (en horizontal et inter-tribus) - la guilde : sur le principe des communautés d'intérêt, elle rassemble toutes les personnes d'une ou plusieurs tribus qui sont intéressées par un sujet donné : les technologies web, la mobilité, etc. Une guilde rassemble par défaut les "chapters" lié au sujet de la guilde mais n'importe qui d'autre peut la rejoindre.

Ce qui se traduit par le schéma suivant :

Feature Teams : Guilde Squad Chapter Tribe

Si le product owner du squd définit le "quoi", on voit bien que le chapter et la guilde travaillent davantage sur le "comment" mais aussi et surtout permettent de partage les expériences, les bonnes pratiques et maintenir une cohérence d'ensemble sur un sujet/métier donné.

Je n'ai pas détaillé ici vu que ce n'est pas le propos mais il y a d'autres choses intéressantes : les "hack days", la pratique du Lean et du Minimum Viable Product, etc, etc etc. Je vous laisse lire les 15 pages en détail.

Pour revenir à notre propos de départ, extrapolons cette organisation de développement logiciel à l'échelle d'une entreprise :

  • Notre Squad pourrait être une équipe en charge d'un produit avec par ex une personne du marketing en tant que product owner. Dans son équipe, il y aurait une personne de la R&D, une personne du juridique, une personne de l'IT, et ainsi de suite avec chaque département requis.
  • La tribu serait assez similaire en regroupant un ensemble de squads travaillant sur des sujets connexes
  • Les chapters permettraient alors de maintenir la cohérence d'ensemble sur un sujet donné pour un profil donné ; si l'on compare avec nos organisations traditionnelles, notre expertise actuelle serait maintenue via les partages au sein des chapters.
  • Les guildes, sur le même principe, regrouperaient les chapters du domaine et toute autre personne intéressée par le sujet.

Du coup, plutôt que de ne voir que le budget partir de la DSI vers le Marketing, c'est un budget et une compétence/expertise qui rejoint une équipe centrée sur un projet donné. On met ainsi également fin aux guerres de chapelles (IT vs Marketing vs ...). Si nos organisations actuelles sont fondées sur un principe de rationalisation (excessive ?), ce mode d'organisation semble vouloir viser l'efficience, en étant à la fois plus agile au sein d'une squad, mais tout en maintenant la cohérence d'ensemble et des règles communes via les chapters et guildes.

Reste à voir si ce modèle est déployable et à quelle vitesse dans nos organisations...