Archives par étiquette : SCRUM

Après le slow food, le slow computing ?

Depuis l’ouvrage “The Lean Startup” qui promeut l’amélioration et l’innovation en continue au coeur de l’organisation des start-ups grâce à l’adoption d’une démarche itérative, depuis l’explosion de l’adoption de la méthode SCRUM qui propose un découpage itératif du développement, une organisation destinée à améliorer l’autonomie de l’équipe de dév. et à améliorer la vélocité et donc le rythme d’ajout/livraison de nouvelles fonctionnalités, l’industrie informatique a réellement et profondément changé de rythme.

image

Alors qu’il y a quelques années, mettre en place des builds afin d’avoir une nightly build destinée à vérifier la validité/cohérence du code présent dans un repository était “hype” et synonyme de démarque qualité, nous sommes à présent nombreux à avoir mis en place de l’intégration continue, à compiler et à tester de manière automatisé dès qu’une modification est commitée.

De même que cela soit via la mise en place de Continuous Delivery ou encore de Continuous Deployment, le rythme de livraison s’est effectivement accéléré dans de nombreux projets.

Les utilisateurs ont donc le grand bonheur de bénéficier d’un plus grand nombre de nouvelles fonctionnalités, plus pertinentes, et ceci beaucoup plus rapidement !

Achievement unlocked !

Tout cela est positif, mais cette course vers la nouveauté a malheureusement un coût et de plus en plus de personnes commencent à se plaindre.

Exemple le plus récent, le projet Docker qui, que cela soit via ce post de blog controversé (lire les commentaires, et les posts de blog en réponse, cité par l’auteur), ou alors encore via ce feedback récurrent d’avoir un rythme d’évolution plus lent afin d’être en capacité de faire évoluer son infrastructure tout en bénéficiant des derniers correctifs.

Autre exemple d’impact bien plus mineur, le Bot Framework dont la V1 a été rendu disponible le 1er Avril 2016 et qui moins de 6 mois plus tard contient plusieurs nouvelles versions et une V3 contenant des breaking changes et nécessitant donc une migration de code (migration qui au passage ne fonctionne pas correctement et qui impose donc la réécriture de ses bots à partir d’un nouveau projet “from scratch”). Exemple de changement : On vient de changer le nom de ces classes, désolé, on n’avait pas assez réfléchi au nommage de nos classes, et avec le recul on trouve que les nouveaux noms sont plus pertinents.

Inimaginable dans le monde Microsoft il y a quelques années, avec une stratégie basée sur une compatibilité maximale de l’ensemble des produits, ce type d’évolution est en train de devenir de plus en plus courant.

Il est donc important de bien réaliser que le gain apporté par des itérations rapides peut se transformer en coût pour le développeur ou l’utilisateur final.

On parle ici de coût induit par du travail supplémentaire nécessaire pour supporter les nouveautés/évolutions on peut également évoquer les pertes sèches causées par l’achat de produits hardware.

Alors qu’auparavant acheter des produits et services de grandes sociétés renommées permettait d’être à peu près à l’abri de l’abandon de ceux-ci et de bénéficier d’une durée de vie plus longue que d’autres produits de sociétés moins établies, il est nécessaire d’oublier ce vilain reflexe.

Les grands éditeurs et constructeurs se placent en effet de plus en plus tôt sur la courbe d’adoption afin de maximiser les chances de prendre une part conséquence de marchés qui sont régulièrement de type “the winner takes all”, et le risque d’abandon ou d’échec est donc beaucoup plus important qu’auparavant.

Il n’y a qu’à juger la stratégie Hardware de Microsoft décrite au sein de cette excellente interview de Mary Jo Foley. Terry Myerson y indique clairement que la stratégie de Microsoft est d’essayer d’ouvrir, animer, dynamiser différents marchés hardware, et de montrer à leurs potentiels partenaires qu’ils sont sérieux sur ces différents marchés, en construisant lui-même des devices sur chacun de ces marchés.
Les casques/lunettes de réalité virtuelle sont cités en exemple dans cette interview mais on peut citer plusieurs exemples à ce sujet : les tablettes et notebook Surface destinés à montrer aux constructeurs qu’il est possible de faire des devices sous Windows d’aussi bonne qualité et aussi beau qu’Apple, Microsoft Band destiné à montrer ce qu’il est possible de faire de lien d’un point de vue hardware et software avec Microsoft Health d’un point de vue des objets connectés (wearables) lié à la santé.

Votre côté geek vous incite à acheter certains de ces nouveaux devices, et vous râlez sur le fait qu’ils ne soient commercialisés qu’en petit nombre et uniquement dans certains pays ? Peut-être que vous devriez y réfléchir plus longuement avant de potentiellement jeter votre argent par la fenêtre Clignement d'œil

Bien évidemment la solution pour ne pas tomber dans ces écueils n’est pas de ralentir le rythme d’innovation comme pourrait le sous-entendre le titre de ce post.

Il existe différentes pistes, et je suis convaincu qu’un ensemble de bonnes pratiques seront prochainement publiées en ce sens :

  • Etre clair sur sa communication
  • Proposer différentes cadences de livraison afin que chacun puisse s’adapter en fonction de son souhait (ex : Windows avec le programme Insiders et les fast/slow rings, .net où l’on peut récupérer des packages nuget de versions récentes ou utiliser le framework .net livré avec Windows, etc.)
  • Développer des correctifs pour plusieurs versions supportées en parallèle
  • Proposer un outillage de plus haut niveau qui facilite la gestion de tous ces changements. Exemple : solutions de management d’APIs
image

Ce que SCRUM nous apporté : Gestion des problèmes

Qu’est-ce que t’as apporté SCRUM depuis que tu l’as mis en place ?

Cette question m’a été posé lors d’un des derniers évènements auquels j’ai pu participer et je dois bien avouer que j’ai eu du mal à formuler une réponse exhaustive tant le nombre d’avantages apporté par notre mise en place de SCRUM est important.

Au lieu de faire un post à rallonge indiquant tous les bénéfices que nous avons pu tirer de cette mise en place, je vous propose une série de posts sur différentes thématiques.

Première thématique abordée :

La gestion des problèmes

C’est une problèmatique simple qui doit être la base de toute démarche d’amélioration, mais qui m’a géné et ennuyé dans la plupart de mes expériences passées.

Chacun d’entre nous a probablement vécu le “syndrome du poisson pourri”. Tout le monde a consience qu’il y a un ou des problèmes bien puant(s) mais personne ne le(s) remonte.

image

Plusieurs raisons peuvent expliquer cela, je vais citer ici ceux qui m’ennuient le plus, le “c’est pas à moi de dire ça” autrement dit le “je ne veux surtout pas prendre la responsabilité de dire ce que je pense”, ou une autre raison (plus excusable sauf d’un point de vue management) le sentiment de ne pas avoir la parole.

SCRUM propose un artefact particulier pour cette gestion des problèmes : les obstacles.

Le principe est très simple : l’équipe doit durant chaque sprint lever les obstacles rencontrés qui empêchent le bon déroulement du projet (ou son meilleur déroulement).

Chaque création d’obstacle doit être signalée lors des scrum quotidiens et sont discutés avec toute l’équipe lors de la rétrospective.

D’un point de vue progression de l’équipe, et amélioration de son autonomie, on peut citer les phases de maturité suivantes : dans un premier temps, le ScrumMaster détecte les obstacles et trouve la solution à ces obstacles, l’objectif étant par la suite (et assez rapidement) que l’équipe lève elle-même les obstacles en les identifiant et en les formulant correctement pour arriver ensuite à à la fois identifier les obstacles mais également à les résoudre seule.

La gestion des obstacles dans TFS 2012

Depuis TFS 2012, Microsoft recommande l’utilisation de SCRUM (il s’agit en effet du process template par défaut des team projects), et propose une gestion d’obstacle simple mais efficace. Le plus compliqué est de trouver le point d’entrée de cette gestion :

image

Les obstacles (impediment en anglais) sont exposés sous la forme d’un type de Work Item particulier qui permet de gérer cette liste avec des obstacles ayant deux états (ouvert et résolu).

image

Conséquences sur l’équipe

Conséquence inattendue lors de la première rétrospective, un des membres de l’équipe avait préparé une liste longue comme le bras avec l’ensemble des problèmes non pas qu’il avait rencontré durant le sprint, mais plutôt des problèmes qui lui courraient sur le ciboulot depuis quelques temps.

Plus sérieusement, chaque membre de l’équipe se sent plus impliqué et sait qu’il a la parole pour remonter et discuter ouvertement des problèmes rencontrés.

Il ne reste plus qu’à arriver à trouver régulièrement ensemble les solutions à ces problèmes afin d’avoir une équipe qui progresse régulièrement et qui ne stagne pas.

image

L’Agile Tour 2012 à Pau le 24 Octobre

image

L’agile tour 2012 fera étape à Pau le 24 Octobre.

L’association Pyrénées Agile organise en effet une journée entièrement consacré au développement agile dans les locaux de l’école EISTI.

Si vous souhaitez découvrir les pratiques agiles et les pratiques d’ingénieries associées cette journée est faite pour vous !

Introduction à l’agilité, Mise en place de tests et de l’intégration continue, Montée en compétence grâce aux coding dojo seront quelques-un des sujets qui seront abordés à cette occasion.

Les inscriptions sont gratuites et ça se passe par ici :

>>INSCRIPTIONS<<

image

 

En savoir plus :
Inscriptions à l’évènement
Twitter de l’Agile Tour Pau
L’association Pyrénées Agile