01 Oct 2015, 21:16

Agile, expertise et expérience

Ce matin, lors d'une formation interne aux méthodes agiles, un propos a particulièrement retenu mon attention ; je vais essayer de ne pas le galvauder et le retranscrire le plus justement possible. Il a été dit :

l'agile ne valorise pas les experts mais l'expérience.

L'idée étant qu'au bout de 2 à 3 ans,nous pouvons devenir expert sur un sujet donné ; la personne est très compétente mais sur un périmètre restreint (la modélisation de base de données, le framework X, etc). On retrouve ici la figure du spécialiste.

A contrario avec l'expérience qui arrive plus tard, nous avons certes nos expertises mais nous avons surtout vu d'autres choses (dans le même domaine ou dans des domaines connexes) mais aussi nous avons vécu différents projets avec leurs contextes. Toute cette expérience permet alors d'avoir une vision plus globale / avec plus de recul d'un projet. On obtient alors la figure du généraliste que je défends. Seulement, je n'avais pas fait explicitement cette liaison lors de ma conférence.

Alors peut être que la personne expérimentée ira moins vite que l'expert pour résoudre un problème donné mais on peut sourtout espérer qu'il le résolve mieux. Rappelons que les valeurs agiles ont notamment pour objectif de fournir un logiciel fonctionnel et de qualité.

Si l'agilité valorise / favorise une attiude généraliste via l'expérience, une raison de plus d'en faire !

 

27 May 2015, 09:30

Around the Web - May 2015

API

Misc

  • A day at Devoxx France (in French) : a summary from Xebia about the Devoxx France conference (Java based but not only) and their findings.
  • Mix-IT Web was in Lyon in April, and the M6 Web tech team wrote a feedback in French - Day 1 - Day 2 ; it deals both with tech and agile topics.

Browsers

PHP

UX

  • The Apple Watch: User-Experience Appraisal : a review on how you app should behave (or not behave) on the new Apple IWatch ; transition with iPhone is also managed and the way to dealt with content and how you should manage your interactions.

Web performance

NoSQL, ElasticSearch

  • Elastic released a new (commercial) plugin for ElasticSearch caled "Watcher" and which aims to raise "alerts" when some events occured and according to some conditions, it may generate an action (email being sent, interaction with another system, etc).
  • M6 Web Tech team published a video (in French) about an introduction to Cassandra.

Geolocation

  • Indoor geolocation technology : article (in French) about indoor geolocation technology, describing and comparing Wifi vs NFC vs Beacon vs Magnetic field to provide geolocation.

25 Mar 2015, 09:30

Around the Web - March 2015

Browser

Responsive Web Design (RWD)

HTML5/CSS/Javascript

  • This API is so Fetching : fetch API is to be used for asynchronous actions and is to be more resilient than a XHR (ie ajax) call. Some exemples are given in the blog post ; it can be used from Firefox 39 and Chrome 42 (currently in dev status) but a Fetch Polyfill exists to start using this API from now.
  • CSS Reference which introduces itself as an extensive CSS reference with all the important properties and info to learn CSS from the basics ; this article gives a more introduction on its purpose and how to use it.
  • Meteor, develop faster than a rocket (in French) : an introduction to Meteor  a full stack and isomorphic javascript framework in which you use Javascript both on client and server side. It also uses MongoDB (NoSQL Document Oriented database & schemaless) to store data and it's based on Node.JS. A second article will show how you can create a mobile app easily.

Thoughts

  • Your job is not to write code : Engineers' job is not to write code, Project Managers' job is not to manage project and so on. Our job is to make a better product.
  • A Bug Hero to fight against bug invasion (in French): in an agile team, in each sprint, a developper is commited to do the 1st level support, fix bug and manage incident to avoid disturbing the whole team and sacrifice the sprint. If no bugs, developer is aimed to fix small tasks that are not on the critical path for the sprint dlivery. Interesting both for the disturbing management effect and as it enforces developpers to have a global knowledge of the system, not only his own part.  

SQL

  • Understanding SQL's null : because querying null is not as easy as it may be and also null may not mean null in the way you expect.
  • PoWa (Postgresql Workload Analyser), released as a 2.0 version, provides a better (from what it is said, not tested) monitoring and performance tools on your Postgres 9.4 cluster.

Virtualisation

Compose is a way of defining and running multi-container distributed applications with Docker. Back in December we opened up its design to the community. Based on the feedback from that, Compose will be based on Fig, a tool for running development environments with Docker.

Machine takes you from “zero-to-Docker” with a single command. It lets you easily deploy Docker Engines on your computer, on cloud providers, and in your own data center

Swarm is native clustering for Docker containers. It pools together several Docker Engines into a single, virtual host. Point a Docker client or third party tool (e.g., Compose, Dokku, Shipyard, Jenkins, the Docker client, etc.) at Swarm and it will transparently scale to multiple hosts. A beta version of Swarm is now available, and we’re working on integrations with Amazon Web Services, IBM Bluemix, Joyent, Kubernetes, Mesos, and Microsoft Azure.

  • so now you can orchestrate all your process from zero to production using docker (based) solutions. Even if some products are still in beta so far, a very interesting move !

 

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...