ScrumDay 2013 (en images) 3/4

Je vous avez abandonné au milieu du tour de nos partenaires, après avoir parcouru quelques sessions de la matinée. Ce n’est pas bien ! Il est temps de reprendre notre bâton de pellerin.

Commençons d’abord le stand IBM. On y est clasique, mais on accueille bien.

ScrumDay2013-12e-IBM02

Chez Soat, on mise sur le goodies à tout va ! Et certains sont d’ailleurs franchement bien.

ScrumDay2013-12f-Soat01

Je vous disais tout à l’heure qu’il y avait du monde : pas très facile d’approcher de chez Coactiv, comme vous pouvez le constater.

ScrumDay2013-12g-Coactiv01

Je termine ce tour des partenaires avec Ippon. C’est toujours avec grand plaisir que je croise Bertrand Pinel et Alvin Berthelot !

ScrumDay2013-12h-CoeurVerre01

En observant la foule de nos participants, je constante que tout le monde est en train de converser, d’échanger. C’est aussi cela, le Scrum Day !

Pour le début de la seconde mi-temps, j’avais choisi de me poser dans l’atelier sur le Proxy Product Owner, animé par Eve Vinclair-Berkemeier. J’avais eu l’occasion de rencontrer Eve il y a peu lors du Printemps Agile à Caen, elle est l’une des animatrices de la communauté agile bas-normande.

ScrumDay2013-11-Vinclair01

Cet atelier était mené sous la forme d’un forum ouvert. Comme on pouvait s’y attendre, pas mal d’arguments contradictoires ont été avancés pour ou contre l’existence du rôle de Proxy Product Owner. Parmi les points qui ont été soulevés :

  • Le manque de temps ou de formation du Product Owner pour mener le travail qui doit être le sien.
  • Necessité d’une personne capable de faire le lien entre le PO “pur métier” et l’équipe.
  • Le concept de PO qui est une résurgence du concept de AMOA qui nous vient tout droit des anciennes pratiques projet.
  • Difficulté pour un PO selon Scrum à animer de très grosses équipes projets, parfois réparties.
  • Pourquoi nécessairement corréler le rôle de PO avec des tâches telles que l’écriture du backlog ou l’écriture de tests d’acceptance ?
ScrumDay2013-11-Vinclair05

Bref, un bon débat, même s’il s’agit d’un débat qui commence à dater. Visiblement, il n’est pas clos et continue à diviser. Pour ma part, je rejoins plutôt l’avis de Claude Aubry sur cette question.

Nous nous sommes offert une petite photo de groupe avant de remettre les tables et chaises en place.

ScrumDay2013-11-Vinclair08

Voilà, c’est de nouveau tout pour aujourd’hui, il faut bien faire un peu durer le plaisir !

A très bientôt pour la dernière ligne droite.

Publicités

ScrumDay 2013 (en images) 2/4

Je vous avais laissé en cours de matinée. Celle-ci n’est pas terminée. Des ateliers se déroulent ailleurs. Je n’ai pu les visiter tous.

ScrumDay2013-6-TCros01

Thierry Cros nous a gratifié d’un atelier très en profondeur autour des specifications agiles. Il vous fallait accorder un double créneau horaire si vous vouliez y participer.

Le thème de cet atelier fait suite à la parution du livre de Thierry sur le même thème.

ScrumDay2013-6-TCros03

J’ai fait un peu relâche sur le seconde tranche horaire, à part le time keeping dans quelques salles. J’ai bien essayé d’aller voir ce qui se passait dans la session d’Olivier Lafontan (Booster Scrum avec le Lean Startup), mais Lean Startup semble vraiment avoir le vent en poupe : il était à peine possible d’entrouvrir la porte tellement la salle était pleine !

ScrumDay2013-8-Lafontan01

Donc désolé, pas de feedback non plus sur cette session qui ne fait pas non plus partie des salles enregistrées.

ScrumDay2013-8-Lafontan02

Préparer son développement par des croquis : c’était le titre de la session de Sophie Freiermuth, et je m’étais promis d’y assister ! Promesse presque tenue, car si j’en ai raté le début, j’en ai quand même beaucoup profité ! Aussi serai-je un peu plus long sur cette session.

ScrumDay2013-10-Freiermuth03

Tout d’abord j’ai eu le plaisir de constater que Sophie a adopté le style Naked Presentation. C’est donc avec un paper board que l’oratrice nous a gratifié de ses conseils. Du fond de la salle, cela ressemble plutôt à des gribouillis informes, mais assez curieusement, ils semblent avoir du sens. En tout cas sur le moment. J’ai rarement eu l’occasion d’assister à des présentations où l’orateur a le courage de faire ainsi. Je me souviens juste de Jurgen Appelo qui avait procédé ainsi à Stoos Connect. Il m’avait avoué ensuite avoir voulu “faire un essai”. Dans un cas comme dans l’autre j’ai trouvé l’exercice convainquant !

ScrumDay2013-10-Freiermuth04

Quelques points que j’ai noté en vrac :

Le pouvoir de la réalisation en commun

Faire avec son interlocuteur est plus fort que lire un document ou faire la revue de son travail. C’est aussi l’opportunité de “comprendre le cerveau de l’autre.

On ne sait pas qu’on ne sait pas

Le besoin exprimé par le client représenta approximativement 1/3 de la connaissance. L’assertion "on sat ce qu’on veut”, même si elle est sincère, occulte beaucoup de choses.

Les croquis lancent la conversion

Plus que les mots, ils provoquent l’émotion de l’utilisateur. Il faut veiller à ôter tout ce qui pourrait faire obstacle à l’expression de cette émotion et à la réaction de l’interlocuteur:

  • Plutôt qu’utiliser un paper board, mettre un feuille à plat sur la table. Se lever pour aller au paper board est un acte intimidant, comme l’atait d’aller au tableau dans notre enfance.
  • Se mettre à la même hauteur que notre interlocuteur ; éviter de le dominer.

Afficher des choses le plus tôt possible

Dès les premiers stades de la reflexion, il ne faut pas hésiter à afficher au murs les croquis, même si la matière n’est pas finie. Surtout si elle n’est pas finie !

En passant devant, les personnes seront interpellées, réagiront. Il faut aussi éliminer des murs les croquis qui n’ont plus de sens car il vont perturber l’attention des visiteurs.

Descendre en qualité

Les croquis de qualité détournent l’attention du lecteur du fond vers les détails ! Il est aussi moins intimidant de s’engager et de participer sur des croquis de basse qualité, car tout le monde n’a pas des talents de dessinateur.

Il est important de convaincre que des croquis sont suffisants, ce n’est pas naturel ! Sophie modère toutefois ce point : dans le cadre d’une équipe distribuée ce n’est généralement pas le cas : dans ce cas elle produit des rock-up de qualité … mais à contre-coeur !

Penser aussi à utiliser de grandes feuilles et de gros marqueurs, cela aide à aller en ce sens. Dans le même ordre d’idées, Sophie semble éviter l’emploi de la couleur.

On arrive gentiement à la pose de midi. Le “coeur de verre” du centre de conférence IBM accueille le lunch et les stands de nos sponsors. En avant pour un petit tour.

ScrumDay2013-12a-ObjetDirect01

Objet Direct est un nouveau venu parmi les partenaires du Scrum User Group. Ce ne sont toutefois pas des inconnus. Nous leur souhaitons la bienvenue ! Ni pour moi, ni pour Laurent Bossavit apparemment.

Xebia affiche fièrement ses couleurs. Je dirais qu’à priori, c’est le violet.

ScrumDay2013-12b-Xebia03

Zenika joue la carte franchement relax. Ca me va bien, je les rejoins bientôt !

ScrumDay2013-12c-Zenika01

Chez Palo IT, on accueille même les membres du SUG qui souhaitent participer au concours.

ScrumDay2013-12d-PaloIT01

Nous n’avons pas fini notre petit tour et il nous reste les sessions de l’après-midi. Je ne voudrais pas vous mettre en overdose, nous allons donc en rester là pour aujourd’hui, mais nous poursuivrons très bientôt !

ScrumDay 2013 (en images) 1/4

Des mois de préparation, de la recherche du financement à la mise au point des détails en passant par le peaufinage des sessions. Des jours de stress à l’approche du “jour J” à la recherche du détail qui n’en est pas un et que l’on aurait oublié.

Voilà, nous y sommes.

Le Scrum Day a ouvert ses portes !

Malgré des transports capricieux, les premiers participants arrivent, café et viennoiseries sont les bienvenus

ScrumDay2013-1-Breakfast01

Comme l’an dernier, nous avons convié le Monde en “tique” à se joindre à l’évènement. De quoi repartir chez soi avec des idées plein la tête, mais aussi plein la besace !

ScrumDay2013-2-LMET

Ce n’est jamais facile de tenir l’horaire. Les aléas des transport ont rendu la chose encore plus difficile ce 11 Avril, c’est avec presque 30 minute de retard que nous avons commencé (mais nous avons réussi à les rattraper). Enfin bon, le grand amphithéâtre Descartes finit par voir ses 360 fauteuils se remplir.

ScrumDay2013-3-KeynoteMatin01

Robert Richman, “culture strategist” de Zappos a ouvert ce ScrumDay 2013 (bon, ce n’est pas complètement vrai : c’est Xavier Warzee qui a ouvert le ScrumDay en évoquant l’année écoulée) en traitant de la “culture hacking”. J’avoue que j’étais un peu circonspect sur cette intervention, ou du moins sans opinion. Je l’étais beaucoup moins après coup !

Robert Richman a réussi ce que j’attends d’une Keynote : Etre captivant, instructif et inspirant ! C’était aussi le cas pour la keynote de clôture, de Dominique Dupagne, mais j’aurais l’occasion d’en reparler.

L’orateur nous a proposé 5 “hacks” pratiques, que l’on peut essayer dès demain. Enfin, peut-être pas exactement, mais ça reste l’idée !

Hack #1 “la façon dont vous entrez dans une pièce peut faire basculer une culture !”.

Faire son entrée, selon la façon dont nous le faisons peut impulser de l’énergie, de l’optimisme ou au contraire du découragement. C’est une réminiscence de la fameuse “première impression”, il me semble…

Hack #2 “détruisez quelque chose”

Construire, c’est important. Mais c’est aussi long. Détruire est un acte rapide, presqu’instantané, d’avantage libérateur d’énergie que la construction. Prendre un virage, montrer que l’on veut faire quelque chose d’autres sont de bonnes occasions de “détruire quelque chose” qui nous raccroche symboliquement au passé !

ScrumDay2013-3-KeynoteMatin03

Hack #3 “votre entreprise n’est pas votre médication”

N’attendez pas que l’équipe soit le facteur qui vous booste ! C’est au contraire à nous de venir avec ce que nous voulons impulser : energie, optimisme, passion, etc… Ce n’est pas l’équipe qui doit nous alimenter en cela. Ressourcez-vous chez vous, revenez au travail avec une énergie renouvellée.

Hack #4 “La frustration c’est de l’or”

Si l’on est frustré, c’est que l’on est impliqué, c’est que la passion est toujours présente ! La frustration peut devenir le moteur pour accomplir des choses positives.

Hack #5 “utiliser des rituels pour l’énergie”

A ce moment de la présentation, Robert Richman nous a fait lever et fait faire des exercices physiques ! C’est là le message également : activer le corps pour activer l’esprit ! Cela a certainement rappelé à certains d’entre-nous l’intervention de Philippe Houssin et Ralph Hyppolite l’an dernier !

Bref, comme je l’ai dit : une très bonne keynote !

Une pause juste un tout petit peu plus courte que prévue et nous voici de nouveau dans le timing ! Les sessions suivantes du matin se répartissaient dans beaucoup de salles. Je n’ai guère suivie que la session de Sophie Freiermuth (j’y reviendrais) et joué au time-keeper sur quelques autres sessions !

Nous avons opéré des enregistrements sur 4 des salles du centre conférence. La meilleure couverture que nous ayons jamais faite ! Vous pouvez avoir le plaisir de voir ou revoir Robert Richman en vidéo.

Sur le premier créneau du matin, nous avions Laurent Bossavit qui nous proposait une session sur l’art d’avoir tort. Comme on peut s’y attendre de Laurent, un atelier s’appuyant sur une approche expérimentale bien étayée de fondements théoriques. Je n’ai guère eu le loisir de m’y attarder hélas. Trois fois hélas !

ScrumDay2013-4-Bossavit03

Je ne m’attarde pas, je fais le tour des salles histoire de voir si tout a bien démarré comme il faut. Stress inutile et stupide de ma part : la mécanique est bien huilée, les orateurs savent ce qu’il faut faire. J’ai l’impression de ressembler à un inspecteur des travaux finis. En fait, j’en suis probablement un …

ScrumDay2013-5-TribalLeadership01

Petit tour en salle Concorde où Florent Lothon nous parle de Leadership Tribal. Le sujet intéresse, la salle n’est pas aussi grande que nous l’aurions souhaité, mais la passion est là ! Assis, debouts ou adossés au mur tout le monde suit avec intérêt cette session qui fait écho à celle de Robert Richman. Il me faudra attendre la mise en ligne pour suivre celle-ci.

ScrumDay2013-5-TribalLeadership03

Je ne connaissais pas Florent comme orateur, mais j’ai l’impression que nous avons fait un bon choix. Si vous aussi vous avez raté cette session, le FSUG a pensé à vous : l’enregistrement est accessible en ligne !

Poursuite de mon petit tour, j’arrive en salle Longchamps.

ScrumDay2013-7-Couturier01

Ici, c’est Romain Couturier qui évoque la notion de valeur ajoutée. Une notion qui peut être délicate à maniée car son appréhension change d’organisation en organisation et l’objectiver peut vite devenir une alchimie compliquée…

ScrumDay2013-7-Couturier02

Belle audience à cette session, dont le public est pas mal connoté “P.O.”, mais pas seulement. N’est-ce pas, Patrice Petit ?

La matinée n’est pas finie, mais j’en garde pour quelques posts futurs. A très bientôt.

Retours sur le printemps agile à Caen (2/2)

Je vous avais laissé en fin de matinée de ce premier Printemps Agile. Il est temps de faire une pause déjeuner bien mérité.

printemps-agile13-lunch1

Rien dans l’ostensibilité dans ce buffet, mais beaucoup en convivialité. J’avoue aussi que cette pause organisée dans une salle de TP a des allures plutôt inattendues !

printemps-agile13-lunch2

Il est temps de reprendre le collier, et pour commencer, la seconde présentation de Jurgen Appelo.

Jurgen Appelo : Let’s Help Melly

Quand on aime, on ne compte pas. Et on a vraiment beaucoup aimé la première intervention de Jurgen. C’est avec plaisir que je remets le couvert pour la seconde.

printemps-agile13-appelo01

Cette intervention était plutôt focalisée sur le thème de son premier livre (Management 3.0). Avec comme point de départ : comment rendre Melly (la persona qui servait de fil rouge) heureuse et productive à son travail ?

Aujourd’hui encore nous vivons majoritairement sous le joug de “l’organisation scientifique du travail”, le Taylorisme. Que nous appellerons ici “Management 1.0”. Il se traduit par un asservissement, une aliénation du travail.

Que faut-il pour dépasser cela ? Donner plus de sens à notre travail ?

Les initiatives qui vont dans ce sens sont le six sigma, Total Quality Management, Business Process Reengineering. Hélas ces initiatives n’ont jamais délivré leurs promesses. Sacrifier l’humain au profit de l’organisation ne semble pas la solution optimale.

Les cycles de changement s’accélèrent, les facteurs d’incertitude s’accroissent. Les systèmes prédictifs ne peuvent plus prétendre gérer cela.

La complexité est justement le terrain de jeu des courants de l’agilité" (Lean, Scrum, Kanban, etc…) . Si les pratiques proposées par les unes ou les autres diffèrent, il ne s’agit que de détails, et l’on retrouvera les mêmes buts et les mêmes valeurs dans différents courants de pensée :

  • Scrum
  • Kanban
  • Beyond budgeting : abandoner l’idée des budgets annuals prévisionnels mais rendre transparents dépenses et revenus.
  • Lean Startup : Créer un cycle vertueux de “validated learning”.
  • Design Thinking

D’un point de vue pratique, l’adoption de l’agilité se heurte à de nombreux obstacles, les principaux étant liés au management. Jurgen Apello nous propose quelques clés de mise en oeuvre

Se mettre à l’entrainement

Donner de l’énergie aux personnes

A l’image du “Kudo Box”, une façon pour les employés de manifester leur reconnaissance envers une autre personne de l’entreprise.

Redonner du pouvoir aux équipes. Mais comment garder la direction d’une équipe auto-organisée ? En agissant sur les contraintes du système ! Le management est en charge des contraintes.

Authority board

Il y a différents niveaux de maturité du management sur la façon dont il peut manifester son autorité. L’autority Board permet de visualiser cela et même de le partager avec l’équipe.

  1. Demander : C’est le niveau de base, du type contrôle / commande.
  2. Vendre : C’est chercher à convaincre le collaborateur que ce que l’on souhaite est désirable.
  3. Consulter : Le manager demande l’avis de ses collaborateurs avant de prendre une décision.
  4. Donner le consentement : Le management n’engage l’action que lorsque les collaborateurs marquent leur accord.
  5. Suggérer : Le manager va laisser les collaborateurs décider de leurs actions, sur la base de conseils prodigués.
  6. Investiger
  7. Déléguer : Le management fixe les objectifs et laisse les collaborateurs fixer le plan d’action.

Aligner les contraintes

Les outils pour cela peuvent être:

  • Donner le sens de la finalité.
  • Permettre aux personnes de s’identifier dans l’entreprise, par exemple en leur donnant la possibilité de se choisir un nom d’équipe !
  • Leur donner l’opportunité d’être fiers de leur produit !

Développer les compétences

En permettant aux personnes de s’aguerrir en continu:

  • Exploration days
  • Brown bag lunches (là, c’est moi)

Faire grandir la structure

S’améliorer, ce n’est pas seulement améliorer les connaissances individuelles, mais aussi améliorer les pratiques et le corpus de connaissance des groupes dans l’entreprise.

Jurgen préfère parler de “guildes” que de “communautés de pratiques” … essentiellement parce que c’est plus sexy !

Améliorer l’ensemble

C’est être en quête d’amélioration continue, mesurer le plaisir des personnes à accomplir leur travail, ou plutôt de contribuer à l’entreprise !

Alors que la présentation du matin abordait les thèmes du dernier livre (ou livret, devrais-je dire) de Jurgen Appelo “How to change the world”, celle-ci traitait des thèmes de son désormais célèbre “management 3.0”. J’ai quand même préféré l’intervention du matin, dont le message était plus simple.

Management 3.0 reste une brique de connaissance ardue, difficile à rendre en seulement 1 heure !

Retour d’expérience SAP

Un retour d’expérience, ça peut être très bon ou très mauvais. Voir très très mauvais. En fait, les niveaux intermédiaires existent aussi. Qu’en est-il de celle-ci ? Le suspens est à son comble …

printemps-agile13-public01

J’ai plutôt bien aimé ce retour d’expérience. Je n’y ai pas appris grand chose, mais c’est interessant d’observer ce qui a été fait, lorsque c’est exposé avec honnêteté et simplicité, ce qui était le cas ici.

La division Caennaise de SAP est en fait l’acquisition d’une société nommée Highdeal. Le passage vers l’agilité y a débuté en 2009 sous l’impulsion de la maison-mère, avec un focus sur le Lean Software Developpement, donc avec une attention particulière portée sur l’élimination du gâchis ! la déclinaison des différents principes agiles s’opère comme suit :

  • Flow principle : PCP (Product Creation Process)
  • Takt principle : ce sont les sprints
  • Pull principel : Scrum, avec un backlog prioritisé
  • 0 defect : C’est la mise en oeuvre de la roue de Deming.

Voici les points ont attiré mon attention :

Le product owner

Un vrai PO pour chaque équipe, c’est un vrai plus ! L’expérience du “PO partagé” s’étant avéré non concluante.

Il porte la vision, mais fait aussi le lien avec les interlocuteurs, et ils sont nombreux : équipes distantes, parties prenantes, partenaires SAP solution.

J’ai ressenti beaucoup de satisfaction par rapport à ces PO et au fait qu’ils s’approprient les projets et se sentent partie intégrante des équipes.

Difficultés sur la mise en oeuvre de l’agilité

Le projet est gros : il nécessite un “chief Product Owner” pour encadrer les POs !

SAP est une grosse mécanique, et cela signifie beaucoup (trop) de niveaux pour atteindre le client réel … si jamais on parvient jamais à le toucher directement !

Les items du backlog semblent aujourd’hui très gros : il faut souvent plus d’une itération pour les achever ! Cela a bien sûr un impact sur la fréquence des releases : 3 à 4 par an, ce qui reste un gros progrès par rapport à l’unique release annuelle qui était le standard précédent !

Teamwork

Chaque équipe dispose d’une “war room” qui sert aux réunions et à l’affichage de tout ce qui a besoin d’être affiché. L’équipe a d’ailleurs abandonné la gestion de tickets avec Jira au profit du tableau de tâches avec les post-it.

La visibilité a grandement progressé, mais il reste encore des problèmes telles que les “tâches non identifiées” qui apparaissent en cours de sprint et ne sont pas répertoriées sur le tableau. Cela impacte de manière non mesurable la vélocité.

La taille des équipes (environ 12 personnes) me semble trop importante ! Je serais curieux de voir comment cela fonctionne concrètement : il y a-t-il de petits groupes informels qui se sont formés ? Les membres des équipes travaillent-ils de manière isolée ? Curieusement, il y avait initialement 3 équipes plus petites et ce sont les équipes qui ont choisi de se réorganiser en 2 grandes équipes !

En conclusion

Beaucoup de progrès semblent avoir été effectués en 3 ans ! Cette société vient d’une culture “waterfall” très solidement ancrée et il me semble y voir de nombreuses réminiscences. Elle mettront du temps à partir !

Les Scrum Masters mesurent la maturité de leurs pratiques agiles en utilisant l’Agile Alliance Subway : je trouve cela assez futé et très pratique. C’est la première fois que je le vois utilisé ainsi !

Agilité 2.0

Durant cette dernière session de la journée, Sylvain Saby nous a présenté sa vision du “modèle étendu” de l’agilité. Il repose sur 3 piliers

printemps-agile13-agile2_0

Pour bien le comprendre, Sylvain évoque le modèle water-scrum-fall Evoqué par Dave West dans un rapport Forrester !

En effet, si le modèle est itératif dans la partie développement, il ne l’est souvent pas en amont dans les activités de définition de produit, pas plus qu’il ne l’est en aval dans les activités de production !

Devops !

Commençons par la parie aval.

Le passage en production casse la livraison itérative en lotissant les mises en production. On perd la boucle de feedback avec le client final et donc une importante part des bénéfices de l’agilité.

Là où les cellules d’opérations se focalisent sur le MTBF, donc des pannes les moins fréquentes possibles, ce qui exige de longues qualifications et un rythme réduit de passages en production, devops se focalise sur le “MTTR”, ou le temps nécessaire pour réparer !

Les conséquences du passage au devops sont :

  • Nécéssité d’utiliser des technologies adéquates : des serveurs qui s’installent vite et simplement, des serveurs d’application qui démarent rapidement, etc…
  • Intégrer dans la conception des “switeches” permettant d’activer ou désactiver des fonctionnalités à chaud.
  • Lotir les évolutions par petits incréments de changements.
  • Faire évoluer le concept de “done” pour le faire aller jusqu’à la production : “done”, c’est une feature déployée en production et utilisée par des utilisateurs !

Au final, devops lisse les passage en production (lorsque le mouvement a démarré chez Flickr, on en comptait en poyenne 10 par jours !).

Lean startup

Les cycles business se raccourcissent : on compte aujourd’hui en moyenne 7 ans entre la naissance d’une startup, son apogée puis son déclin (ou son pivot) ! Des plans projets couvrant des années ou même des mois ne sont plus de mise.

La définition du produit elle-même doit être agile. L’approche Lean Sartup avec son MVP et son cycle de “validated Learning” couvre bien cet aspect.

La technologie et le rôle de l’architecte

Sylvain a beaucop insisté sur le rôle de la technologie dans ce paysage. On voit que le sujet lui tient à coeur ! Il a évoqué 3 volets plus particulièrement.

NoSQL

Les différentes moutures de bases de données NoSQL offrent plus de flexibilité pour stocker les données et surtout permettre de faire évoluer la structure des données qui y sont stockées, car elles sont “sans schéma” pour la plupart d’entre elles.

Sylvian résume leurs caractéristiques par rapport aux bases de données relationelles : elles ne sont pas faites pour classer les donnés, mais sont fortes pour retrouver ! Ou de synthétiser leurs propriétés par les “3 V”: Volume, Variété, Vélocité !

Cloud computing

L’un des freins aux évolutions logicielle est le déploiement, la gestion de la compatibilité ascendante, l’hétérogéneité des configurations et versions déployées.

Pour se débarasser de ces freins, la solution est de déployer son soft en SaaS, donc en service hébergé. Les problématiques de configurations et de déploiement se trouvent immédiatement simplifiées. Bien sûr le prix à payer est de convaincre les clients de ne plus avoir ces services en local chez eux et aussi de suivre les évolutions de version qui leur sont imposées.

Architecture des applications

Le standard d’architecture de applications actuelles est le modèle en couche. Pour rendre le SI plus agile, il faut passer à une architecture plus “verticale” où les services sont modulariés sous formes d’applications indépendantes, communiquant potentiellement par les API implémentées sous forme de Web Services REST.

Une telle architecture devient plus facile à opérer et les évolulutions y ont un moindre impact. Sylvain milite sur ce plan pour un rôle accru de l’architecte (qui n’existe pas dans Scrum) par rapport au Product Owner.

La modularité permet aussi de basculer plus facilement vers de nouveaux frameworks ou des langages plus adaptés à telle ou telle technologies au fur et à mesure de leur apparition ! Ceci a des conséquences par rapport à notre appréhension des technologies:

  • Des appliations qui deviennent “jetables”.
  • Pas d’investissement “longue durée” sur des technologies, mais un usage qui se limitera aux “fonctionnalités centrales” faciles à appréhender et ne demandant pas un niveau d’expertise poussé.
  • Un shift vers le “monkey développer”, allant très vite sur une nouvelle technologie ou un nouveau frameworks via un “copier-coller” de code issu d’une recherche Google !

Le constat peut sembler dur, je ne suis pas certain de le partager complètement, mais surement en partie toutefois.

En conclusion

L’agilité 2.0 vue par Sylvain Saby a plusieurs corollaires:

  • Une manière d’opérer les systèmes “à la devops”, selon l’adage “you build it, you run it !”.
  • La fin des architecture monolithique et la nécessité mettre l’architecture au même niveau d’importance que le travail fait sur le produit.
  • La nécessité de tirer les profils vers le haut : travailler avec moins de personnes, mais des personnes plus solides, productives et capables d’appréhender très vite de nouvelles technologies, de nouveaux langages…

Partir revenir

C’est pour cette première édition du printemps agile !

Bien sûr le gros coup, c’était d’avoir fait venir Jurgen Appelo : encore bravo aux organisateurs pour ce tour de force !

Le reste du programme était tout à fait honorable, à la hauteur d’un agile tour, dirais-je. J’ai pu échanger un peu avec la communauté agile Caennaise et suis donc extrêmement heureux qu’elle existe !

Cette première édition du printemps agile est un succès, aucun doute là-dessus. Tout le monde semble motivé pour remettre le couvert l’an prochain. Moi aussi !

Note de lecture : Scrum and XP from the Trenches, par Henrik Kniberg

Note : 9 ; Du vécu, rien que du vécu ! Book of the Year 2009 !

Le titre à lui seul résume la direction du livre : « comment nous pratiquons Scrum ». Pas de descriptif de Scrum ici (l’auteur renvoie pour cela à d’autres références), ni de longue dissertation sur la théorie. Sur chaque pratique l’auteur décrit de la manière la plus concise possible la façon dont il pratique cela dans son équipe et le bénéfice qui en est retiré. La concision et la valeur du texte sont tout simplement impressionnantes ! Que n’ai-je lu ce livre avant ! D’ailleurs, avec un petit format, une quantité honorable d’illustrations et seulement 130 pages, il se lit très rapidement. Une seule journée m’a suffit.

Le livre compte quand même 15 chapitres, donc forcément très courts, ce qui est un plus. On couvre ici toutes les pratiques : Le product backlog, le sprint planning, la communication, le sprint backlog, l’organisation de l’espace, le sily scrum, démos et rétrospectives. Les pratiques XP combinées à Scrum ne sont pas oubliées : Scrum et XP et TDD ont droit à leur chapitres ! L’auteur s’offre même le luxe d’aborder les sujets « avancés » : les contrats au forfait, les équipes géographiquement dispersées et laa pratique de Scrum sur plusieurs équipes.

Le livre existe en version reliée, mais aussi en PDF librement téléchargeable qui offre l’avantage d’avoir les illustrations en couleur ! Si vous pratiquez Scrum ou vous y interessez, il n’y a vraiment aucune raison de ne pas lire cet ouvrage !

scrum-from-trenches

Référence complète : Scrum and XP from the Trenches, how we do Scrum – Henrik Kniberg – InfoQ 2007 – ISBN : 978 1 4303 2264 1

Scrum and XP from the Trenches

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

ScrumBeer, ScrumBeer !

Qu’est-ce que l’on fait généralement devant une bière ? On refait le monde ! Nous autres agilistes ne sommes guère différents : on se réunit, sans agenda précis, pour parler de ce qui va, ce qui va moins bien ou de ce que nous voudrions ou aurions dû faire !

ScrumBeer2013-Avr02

La ScrumBeer, au départ, c’est une initiative d’Arnaud Villenave (au fond à gauche, sur la photo suivante). Nous sommes loin de tenir le rythme d’une rencontre par mois que nous nous étions fixé au départ, mais nous sommes quand même passé de deux (Arnaud et moi) à une petite poignée de passionnés au fil du temps.

ScrumBeer2013-Avr04

Parfois notre GO (donc Arnaud, vous l’aurez compris) ou quelqu’un d’autre vient avec un truc à essayer. Cette fois, c’était un “delegation poker”.

ScrumBeer2013-Avr05

J’ai fait l’impasse, mon naturel indolent a pris le dessus. En fait, je n’ai pas parlé agilité ce soir-là, mais des mérites comparés des langages de programmation ! C’est ça aussi, les ScrumBeer !

ScrumBeer2013-Avr06

Voilà, c’est tout pour aujourd’hui. Vous trouverez le lien sur cette rencontre sur Meetup.

Ah si, une dernière chose comme aurait Steve : Il me faut “remercier” Arnaud (décidément, encore lui) pour cette prise de vue !

ScrumBeer2013-Avr07

Note de lecture : Pro SQL Server Disaster Recovery, par James Luetkehoelter

Note: 7 ; Un bon cocktail de technique, gestion des risqué et process, le tout fort bien écrit !

Décidemment APress propose une collection complète et de qualité pour couvrir SQL Server (2005 et maintenant 2008..). Cet ouvrage dédié au disaster Recovery, malgré sa publication récente couvre SQL Server 2005, avec un addendum évoquant SQL Server 2008.

Bon bouquin, disons-le tout de suite. Le cursus particulier de l’auteur (études de philosophie) n’est probablement pas étranger à la qualité rédactionnelle. Le style est vivant, voir intimiste. Même pour un livre technique (surtout pour un livre technique), cela compte ! Comme le DRP n’est pas seulement de la technique mais plutôt une alchimie entre technique et process, l’auteur aborde les deux aspects avec bonheur.

Bien entendue, le backup est la pièce maîtresse du DRP. Impossible d’échapper au traitement en profondeur de celui-ci. Le premier chapitre est purement introductif, mais les chapitres 2 à 5 (soit pratiquement les 100 premières pages) sont entièrement dévolues à cet aspect ! Après cela, on sait pratiquement tout ce que l’on a à savoir sur la réalisation des backups, leur restauration et la relation entre filegroups et backups ainsi que les stratégies possibles et conseillées.

Le chapitre 6 fait charnière en présentant les recovery plans possibles mettant en œuvre les techniques vues précédemment.

Les chapitres 7 à 10 constituent vraiment à mon avis le « plus » de ce livre en présentant les différentes fonctionnalités de SQL Server pouvant être utilisées pour le DRP, la façon de les utiliser et leur utilité dans un DRP d’un point de vue subjectif. Dans l’ordre, nous avons : le « log shipping » qui est clairement le préféré de l’auteur, le clustering, le miroring et enfin le snapshot. Une mention particulière pour le chapitre 10 qui traite de l’infrastructure matérielle : chapitre intéressant au point qu’il m’a laissé sur ma faim !

Les chapitres 11 et 12 traitent l’aspect purement processus du DRP. Le chapitre 12 est particulièrement étonnant (et intéressant) car il traite exclusivement de l’aspect humain. Il pourrait prendre place dans un livre traitant de toute autre technologie ou même d’aucune technologie !

Enfin, une annexe évoque les évolutions qu’apporte la version 2008. Cela ne couvre qu’une dizaine de pages, ce qui est plutôt succinct, mais il est vrai que l’on n’a aucun recul sur cette version. Pourtant n’est-elle pas « all about availability » ?

Pour conclure : je recommande vivement !

pro-disaster-recovery-sqlserver-2005

Référence complète : Pro SQL Server Disaster Recovery – James Luetkehoelter – Apress 2008 – ISBN : 1-59059-967-5 ; EAN : 978 1 59059 967 9

Pro SQL Server Disaster Recovery

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