Quels critères d’acceptances pour les projets agiles ?

Il est fréquent que dans les plans de transition agile figure des “critères d’acceptances” pour fixer si tel ou tel projet au sein de l’entreprise… pourra être géré (ou non) en agile. Par exemple, j’ai vu récemment, les critères suivant pour qu’un projet puisse être géré en agilité :

• les requirements sont flous ou manquent de clarté ou de detail
• le Product Owner peut liberer 80% au moins de son temps a l’equipe
• l’architecture doit être mature

Peu importe si ces critères sont justifiés ou non, ce qui est gênant c’est qu’on confond “critère de selection” et “contrainte d’application”.

Critère de sélection n’est pas contrainte d’application

Le problème est que ces critères sont définis à partir d’une culture et d’un cadre d’une organisation traditionnel. Si j’applique l’agilité sur ce projet dans mon organisation traditionnel, ça fait quoi ? mais justement … on veut faire de l’agile ou pas? ?

Disons qu’il est naturel de vouloir se fixer un cadre pour répondre aux projets : “ton projet ne corresponds pas, tous les risques sont cumulés pour appliquer correctement l’agilité”… Disons que tout n’est pas si simple.

Faisons une métaphore, imaginez que vous désirez vous rendre autonome dans vos déplacements de tous les jours… acheter une voiture ! oui certes mais vous n’avez pas le permis et en plus vous n’avez pas beaucoup d’argent !

Que faire … Tout d’abord passer son permis…! ça parait légitime car c’est investissement sur la durée, quasi indispensable… et ensuite acheter une voiture. Si vous n’êtes pas fortunés vous allez certainement acheter à crédit (surtout la première).

Si vous aviez à faire votre choix par rapport à des “critères d’acceptances”, comment cela aurait-il fait changer votre projet ? ça se serait certainement passé autrement, car vous auriez eu :

• critère no 1 : le véhicule doit se conduire sans permis
• critère no 2 : l’investissement du véhicule doit être très léger et correspondre à mon pouvoir d’achat

Pourquoi ce n’est pas cohérent ? car ces critères se basent sur votre capacité organisationnelle, financière, technique, culturelle actuelle. En plus tout le monde le sait les voitures sans permis coutent plus chère :-O

En fait il faut prendre en compte le changement nécessaire pour accéder à ce nouvel outils (formidable). Comme tout nouvel usage, il s’agit de prendre en compte les nouveaux modes organisationnels, et ainsi le nouveau paradigme cible. C’est ainsi que le changement de l’agilité s’opère.

Une fois le permis acquis et le financement obtenu, les nouveaux critères pourraient être :

• ne pas prendre une voiture trop puissante (car le funki’conducteur risque de rouler trop vite.)
• prendre un diésel (car le conducteur effectue de longues distances régulièrement)
• etc..

Je peux exprimer cette incohérence sur un autre axe : imaginez un chef de projet qui désire savoir si son projet peut être agile … vous passez votre moulinette agile et tout est négatif. Vous lui dites “impossible!, le PO n’est pas disponbile, les règles métiers sont compliqués, le projet est important, la technologie est cobol, … tout ça n’est pas très adéquat pour l’agilité. Mais si ce chef de projet a vraiment besoin de l’agilité ?  priorisation de la valeur, livraison fréquente … en dehors des contraintes structurel qui peut l’empêcher ? pourquoi ne pourrait on pas opérer ce projet en agilité ?

L’application de l’agilité sur un projet doit se baser sur des attentes et non sur des contraintes

Disons qu’il faudra plutôt mesurer l’attente, la motivation et pourquoi pas la capacité au changement de l’équipe à passer au nouveau mode opérationnel agile. ça serait plutot des critères subjectifs qu’objectifs ? certainement ! De toute façon il s’agit de comprendre l’agilité par l’équipe concernée et de déterminer elle-même si elle cela va lui apporter de la valeur.

L’application de l’agilité s’inscrit dans un décalage organisationnel, culturel, humain & technique, du coup nos critères habituels (issus d’un paradigme traditionnel) ne sont pas valables. Il s’agit de se fixer dans le contexte cible agile, et ensuite on vérifie si on peut atteindre cet objectif. 

Bref .. Enter the matrix! :

Voici quelques idées (que je n’ai jamais appliqué tel quel). Un projet peut aborder l’agilité, si :

Attentes : 

• Le besoin en exploration/expérimentation fonctionnelle est forte
• Il y a un fort besoin de valeur opérationnelle rapide
• Il y a un fort besoin de réduction des risques techniques
• Il y a un fort besoin de piloter le projet par la valeur

Motivation:

• le responsable de projet maitrise les principes agiles et est très motivé à initier l’agilité
• Le manifesto et la philosophie agile sont compris et appliqués
• …

Capacité au changement :

• Le product owner / le scrum  master / responsable ont les capacités de faire face aux difficultés hierarchiques et politiques lié au changement
• Le travail en collaboration, en communautés au sein de l’entreprise sont déjà utilisés.
• …

Si vous avez des idées.. ?

Template de contractualisation agile open source.

Xebia (avec certains partenaires juridiques), ont eu l’initiative de publier, sous licence creative common, un template de contrat agile open source. Je me suis donc précipité  étant donné que c’est un sujet que j’estime, ayant travaillé sur la mise en place d’une contractualisation chez plusieurs clients (notamment pour le premier projet agile CNRS) , et dernièrement chez un grand équipementier technologique militaire.. ekito (boite dans laquelle je travail) étant tiers de confiance “agile”.

Effectivement l’idée d’un contrat agile générique est séduisante, pour moi la position en tant que prestataire/client/agiliste est la suivante :

Les formes de contractualisation agile sont très variables du contexte du client, du prestataire, et surtout de la relation entre les deux.. chaque contrat est donc (très) différent, cela dépend aussi fortement de la condition du projet au sein du client ! … en fait tout dépend de la manière dont chacun veut prendre et partager les risques. Chez un certain client, on ne voudra absolument tolérer un partage de risque , chez d’autre ce n’est pas un problème.

Voici donc mes remarques :

• je pense qu’il manque quand même les points essentiels d’un contrat agile : comment & par qui, est estimé l’effort (içi en points), comment est organisé le travail en équipe intégrée, le cérémonial.. et la disponibilité des personnes (par exemple si le Product Owner n’est pas du tout disponible et que les développeurs sont bloqués  que se passe t’il ? ), il manque aussi la définition du niveau des “spécifications” : comment et jusqu’a quel niveau les stories sont spécifiés ?

• l’engagement coté prestataire porte notamment sur la livraison minimal d’une partie du sprint backlog (appelée ici prédictibilité) et sur la productivité. Je pense que ces deux points ne sont pas l’idéal, car l’engagement est partiel sur le premier (75%). Pour le deuxième (engagement sur la productivité) cela amène souvent aux dérives qu’on connait sur les projets traditionnels, c’est à dire tout faire pour avoir une bonne productivité au détriment de la qualité.

• je trouve que le contrat parle (trop) des principes de développement (beaucoup de place à XP notamment) ce qui intéresse et rassure les équipes techniques, mais apporte de la confusion aux juristes et acheteurs.

• vu que le travail se fait en toute transparence et que le client connait les équipes, comment le prestataire estime le nombre de développeurs à positionner, c’est un point essentiel important pour le client.   la vélocité est elle utilisée pour calculer les effectifs?

• on ne parle nul part (sauf erreur) des points métiers au niveau des stories (business value/valeur commerciale), cela veux t’il dire que c’est la sauce du product owner uniquement et que le prestataire n’a pas connaissance ? comment est priorisé le backlog est ce le procut owner ? Mais que se passe t’il si un problème de cohérence amène le prestataire à revoir ce positionnement ?

• je trouve qu’il manque un exemple de backlog avec les stories.
• il n’est pas abordé la notion de confiance et de bon sens de chacune des parties (client/prestataire), “jouer le jeux de l’agilité” qui permet aussi de partager les risques … mais attention , souriez vous êtes filmé ! c’est-à-dire que si quelqu’un ne joue pas le jeu on peut préciser dans le contrat quels sont les points de sorties.
• je ne trouve pas claire la clause de réajustement, notamment avec l’intervention d’un médiateur

• comment est gérée l’intégration continue, sujet souvent sensible, qui doit être le plus intégré possible chez le client, et en général le prestataire va vouloir utiliser ses propres outils de productivité.

• il n’y a pas de definition of done

• il est inscrit les engagements côté prestataire, mais il manque ceux du client. Par contre j’ai l’impression que cette proposition a tendance à favoriser le prestataire en terme de partage des risques.

• on ne parle pas du tout d’outil agile de partage du backlog, est ce que tout est par postit ? (sujet souvent abordé)

• je pense qu’il y a une bonne description des pratiques agiles, par contre cela peut porter à confusion, par exemple que veut dire la présence du manifeste agile ? disons qu’il vaudrait mieux faire un lien sur un site de référence agile plutôt que d’incorporer les éléments génériques agile de scrum ou xp.

• on ne parle par de l’amélioration continue, et comment la gérer ?

• au dela du contrat agile ce qui est intéressant aussi c’est le workflow global de la contractualisation : par exemple comment comparer les propositions de plusieurs prestataires (uniquement le prix ? )

sur la forme :

• 52 pages pour un template de contrat agile, je trouve ça beaucoup ! (par exemple l’appel d’offre finalisé du CNRS en comportait 50 avec les annexes)
• il faudrait un support plus collaboratif, comme un wiki
• et enfin … pour les prochaines versions! il pourra être abordé les contractualisations au niveau du secteur public par exemple, très différent (et beaucoup plus complexe) juridiquement.

Conclusion :

Alors un ”contrat agile open source” est-il légitime ?  Même si pour moi chaque contexte est tellement différent,  l’idée de partager un template est une excellente idée. J’approuve donc le sens de cette approche avec les réserves ci-dessus…  .. disons que la réflexion est grandement intéressante, et permet surtout d’avancer sur les principes, de manière collaborative.

Maintenant, appliquer “tel quel” ce contrat n’est pas possible bien entendu, pour moi. Donc si l’objectif de ce projet est d’apporter de la valeur “intellectuelle” & agile aux clients et aux prestataires, alors OUI.

Donc bonne continuation a ce projet, et dites-nous comment y participer (peut être autrement que par le mail fourni, notamment avec une plateforme plus collaborative ?)

Les Saas pourraient être le sas de la DSI vers l’information non structurée…

L’entreprise a bien du mal… Sa DSI a du mal à suivre les projets d’intégration et de stabilisation de son système d’information… alors que pendant ce temps, les directions métiers surfent sur le nuage de l’indépendance et réalisent de plus en plus eux-mêmes leurs propres infrastructures d’information web & mobile grâce au saas ou a des facilités leur permettant de mettre en place des systèmes indépendants du S.I.

Souvenez-vous de “terra incognita”, cet endroit où l’information est inconnue de la DSI, mouvante, émergente, non structurée… la DSI est bien incapable de la connaitre. Car la DSI n’innove pas, Monsieur, la DSI est dans l’opérationnel. Alors la solution ne proviendrait-t’elle pas de structures (jeunes) qui mettent à disposition des nouveaux services à forte valeur ajoutée, qui utilisent l’information non structurée du terra incognita…

C’est-à-dire que la structure idéale du Saas permettrait à ces entreprises innovantes de proposer des services de A…Z… en terme de processus métier. Par exemple une entreprise qui propose des services de réservation de voyage complets, entre la réservation de l’hôtel, de l’avion, du train…. tout ça grâce à terra incognita. Et cette entreprise Saas fournirait une interface à peut prêt stable aux entreprises… Dans un environnement sécurisé.

En effet, pourquoi pas sous-traiter la gestion de l’information mouvante, émergente, et non structurée  ?

Culturellement, la DSI ne pourra pas maitriser elle même ce milieu, car le risque est trop élevé. Alors disons que terra incognita sera bien un nouvel eldorado de l’information et ses ressources infinies pourraient rapportées très gros…

“Man Gave Names To All The Animals”… but also gave names to the internet

J’ai pensé à ce titre de post en écoutant la chanson de bob Dylan “man gave names to all the animals “… Effectivement au départ je ne voulais pas parler d’animaux, ou de cochon… mais plutôt d’internet, et surtout de l’information… le jour ou Time Magazine nome un jeune boutonneux de 26 ans, l’homme le plus influant de la planète.

Alors, oui… “in the beginning, long time ago”*.. l’homme a bestialement tué, élevé, manger ces bêtes sauvages …  l’homme a reconnu “Un visage réellement sale et une queue frisée*” , qu’il a fallu ensuite nommé, car ces sales bêtes à quatre pattes vivaient auprès des hommes…. elles devenaient de plus en plus familières…. “je pense que je vais l’appeler cochon”*.

Si l’homme a dû nommer les animaux, et qu’il a réussi à dresser la bête, grâce aux progrès technologiques,  il est passé à l’internet directement : – ) ; il a alors essayé de nommer l’internet… enfin de nommer l’information qu’il trouvait sur l’internet.

Au début c’était un peu difficile, et comme l’information n’a pas de nom, il a fallu trouver un moyen de l’éduquer pour l’élever, de l’appeler, de la transmettre … Dans un premier temps Il a dû se contenter d’utiliser des “mots clefs” pour appeler ces pages webs.

Le problème des mots clefs et qu’il obtient des dizaines de résultats. Et en plus ces résultats sont issus d’une vision un peu arriérée (hier) et surtout d’une page statique … une genre de page (déjà) morte. alors qu’à l’homme on lui demande de savoir ce qui se passe à coté de lui, maintenant, par exemple quand il utilise son instrument de déplacement appelé “voiture”. Quoi bon d’avoir des pages mortes.?

Il a donc eu l’idée de nommer l’information par rapport à ses envies, ses amis , sa situation … c’est alors que “man gave name to all his activities” … bon disons que l’homme a donné un nom a ce qu’il fait, tous les jours, avec qui et comment , et où… c’est ainsi que l’homme obtena plus facilement l’information qu’il désira, en temps réel.

J’espère que vous vous retrouverez… In the beginning, long time ago… google search nous a aidé à trouver l’information, maintenant facebook ou twitter ou tout autre réseau social va nous aider à obtenir l’information, sans la chercher. De plus elle aura un sens par rapport à ce que vous vivez… amis, envies, occupations: là, maintenant.

Oublions les mots clefs… et surtout gardons les noms uniquement pour les animaux.

Si vous voulez la suite, écoutez la chanson de bob…

*reprises de la chanson

Gérer son backlog avec Greenhopper, [vidéo]

J’ai présenté Greenhopper à l’agile ch’tour de Lille, voici la vidéo (20mn). Merci à Proxiad (notamment à Pascal Leclercq) pour avoir filmé.

Les ruptures du S.I. qui nous mènent à l’agilité …

Dans mon livre agilité & scrum (en cours d’écriture) , j’introduis le sujet de l’agilité du pourquoi on en est arrivé là… à faire de l’agile. Pour déplier les différentes phases de l’informatique, j’ai tenté de décrire les grandes ruptures qu’elle a rencontré depuis son existence dans l’entreprise (c’est à dire depuis les années 60) :

Première rupture : Le Gros système

Deuxième rupture : La Direction du Système d’Information

Troisème rupture : La modélisation du besoin métier & l’éclatement des compétences informatiques

Quatrième rupture : Externalisation & Gouvernance du SI

Cinquième rupture : L’agilité

Sixième rupture : ?

Peu importe ce que définit chacune de ces ruptures, (tout est dans le titre), ce que je voudrais essentiellement, c’est orienté le lecteur pour qu’il réalise à quel point l’informatique a régulièrement présenté des palliatifs pour les problèmes qu’elle a rencontré… par exemple, externaliser les développements pour être plus agile en ressource … ou modéliser le métier par des concepteurs pour mieux définir le besoin…  ces palliatifs peuvent sembler une bonne idée à ce moment-là, mais avec du recul peuvent se révéler être d’une certaine incohérence, voir dans le mauvais sens par rapport à ce qu’il est voulu.

L’agilité est l’une de ces ruptures (elle paraitra peut être décalée à l’avenir : certainement) en tous cas ce qui compte c’est comprendre pourquoi elle est une solution aux problèmes actuels. (Pour la sixième rupture, j’ai des idées… si vous en avez, je suis preneur !)

Agile ch’Tour 2010

power flower! ça colle bien à l'agilité ça

Jeudi 4 novembre s’est déroulé l’agile tour de Lille, ou j’ai présenté une conf : “Gérer son backlog avec Greenhopper”. C’est la deuxième session agile tour que je présente cette année, en tant qu’ekito.

La journée avait très mal débuté pour moi, car j’ai été dès 5H pris en blocage par un barrage (manif retraite) à l’entrée de l’aéroport Blagnac, en discutant un peu j’ai pu passé le barrage, mais j’ai du laissé ma voiture en plan … heureusement je l’ai récupéré sans PV ni sabot, mais je n’ai pas le seul. OUF.

Et me voici arrivé à la ville des chtis que j’ai quittée il n’y a pas si longtemps…, distante de 1000km de toulouse, un autre monde quoi. En tous cas c’est avec joie de retourner au pays des chti !

A 14H le public arrive, beaucoup d’amis et d’anciens collèges… D’ADEO (leroy merlin) : Christian Verlinde – Responsable CMMi & Méthodes, Frederic Lebail – Architecte, Olivier Hesdin - Architecte) et d’Oxylane (Stéphane Fasquel – Responsable des dev , Alexandre Godin – Coach Java & Agile, Pierrick Durrand - Chef de projet & responsable produit, Bastien Roger - Chef de projet & responsable produit d’un PLM), Mais aussi des personnes très sympathiques venant des SSII (notamment Pascal Lecercq - Architecte à Proxiad)

Voici les présentations auxquels j’ai assisté:

Céline STAUDER – Optimiser le ROI de votre produit avec une bonne priorisation de votre backlog

La présentation de Céline fait le focus sur l’un des points essentiels de scrum : la création des user stories et leur priorisation. Il y a un point que j’ai retenu (parmi d’autres), c’est la possibilité de faire diminuer la granularité d’une user story lorsqu’on passe d’un backlog à l’autre … du product backlog au sprint backlog. En gros la granularité s’affine pour arriver à un élément idéal dans le sprint (pas trop gros biensur). Cela correspond donc à l’affinement de la profondeur fonctionnelle de la user story. Intéressant. (pour ma part j’ai pour habitude de créer la user story avec une certaine granularité, et n’y bouge plus pendant son cycle de priorisation).

D. Thouvenin – Trois clés pour intégrer les retours de bugs dans Scrum

Scrum fait l’impasse sur les bugs, a chacun de trouver une solution, l’idée ici est de définir un protocole de priorisation, et en fonction de la”criticité”/”facile à corriger” le bug est soit traité à chaud, soit réintroduit dans le backlog. Exposé intéressant.

Pierre Pezziardi – L’informatique conviviale: libérez les énergies de la DSI !

J’ai fait le déplacement sur Lille “aussi” pour participer à son intervention, Pierre Pezziardi est l’un des fondateurs d’octo, DSI de la bred maintenant. Le thème “informatique conviviale” me tenait à coeur, car elle correspond à une vision SI (Management du SI) de l’agilité, et notamment d’une approche Lean de la chose. Ce qui est intéressant dans la démarche de Pierre est le coté “organisationnel”, c’est à dire purement humain lié à l’organisation de l’entreprise et à sa restructuration en petites équipes : pour éviter les silos entre les équipes, il souligne en quelques sorte, que la seule issue est bien basée sur l’humain. Le deuxième point que j’ai retenu est l’importance des tests, même dans un système legacy. Effectivement avec l’agilité, le goulot est bien les tests, seule solution : les automatiser. Présentation extrêmement intéressante, d’autant que Pierre est un excellent orateur. Il donne la vision d’un DSI éveillée.

Gildas Le Nadan – Le mouvement devops : synergie développement/exploitation et plus encore

Didier Girard m’avait parlé de devOps sujet intéressant pour rendre l’infrastructure de l’entreprise plus “agile”. Gildas nous a merveilleusement éclairé sur ce principe émergent : c’est à dire liée l’exécution (le run, la prod) des applications à de la valeur… en général on fait l’impasse sur l’importance de ce lien. En gros il s’agit de créer une agilité entre les études et la prod (d’ou le terme dev – ops) enfin parlant même entre l’entreprise et la prod, car elle apporte autant de valeur que les études. Merci à Gildas, ce sujet va m’intéresser, car il correspond à une des clefs de ma vision “labs” de l’informatique (cf prez innovation et DSI ) .

Voilà, excellente succession de conf donc!

un peu d'art brut dans un monde d'agiliste

Concernant la mienne, Gérer son backlog avec GreenHopper, je suis plutôt satisfait, la salle était comble, pas mal de questions et un intérêt pour le produit. Le challenge de faire une présentation en 20′ a été réussi et j’attends avec très grand plaisir vos commentaires (possibles ci dessous) ! Maintenant j’ai peut être été vite sur certains sujets, d’ou une frustration. Mais l’essentiel était d’abord avoir une première idée.

Les organisateurs (Julien Jakubowski - Octo, François Wauquier - Sfeir, Jérémie Hattat – Proxiad) ont été très brillants et on réussit leur journée. Bravo à eux !

La soirée s’est suivi avec un after, et on a pus disctuer avec Guillaume Duquesnay - consultant chez octo, Ignacio Lizarralde – Consultant octo en mission chez ETO. Laurent Bossavit, Agiliste fondateur de l’institut agile. (j’oublie d’autres personnes autour du bar, si quelqu’un pouvait m’aider.)

J’ai longuement discuté avec Guillaume Lours, agiliste et architecte Java de proxiad Rouen, très intéressant et je compte le rencontrer au futur agile tour de rouen!

Et c’est à ce moment précis que la plus belle récompense et révélation de la journée apparue : il s’agissait d’une découverte venant des Ardennes belges : LA CHOUFFE (il devait être 21H00 … très tard pour ce genre de rencontre)

agile ch'tour: la révélation de la journée!

et comme les grands esprits se rencontrent on a pu trinquer avec Laurent Evain – fondateur d’iLove-web et de diiink.tv et Thibaut Bayart – Entrepreneur, qui sortaient tous de l’apéro entrepreneur (dans le bar d’a coté … ça partait mal, car on commençait à refaire le monde, heureusement que le bar fermait, on y serait encore. ça nous a pas empêché de finir par un welch cérémonial (au regrets de Didier Girard qui n’était pas là) au resto “Les Moules” qui ne ferme pas de la nuit.

Le lendemain a été très très dur après une nuit de 4H et des problèmes d’avions 1H30 de retard, le pire c’est que le contrôle de sécurité n’a pas permis d’importer dans le SUUUD ma Chouffe emportée, destinée à faire un cadeau à Claude Aubry… dommage.

je suis arrivé chez mon client pas du tout agile (le client final, pas l’équipe avec laquelle je travaille), où je suis scrum master. La dure réalité quoi, les illusions et utopies de la veille n’ont qu’a bien se tenir !.

innovation pour une DSI plus agile

J’ai présenté Jeudi à l’agile tour 2010 de toulouse une session sur l’innovation et la DSI. Voici le slide.

Le thème a suscité beaucoup de réaction (commentaire sur ce post).

Industrialiser ses projets innovants pour une DSI plus agile

Je démarre aujourd’hui l’écriture de la présentation que je donnerai à l‘agile tour, le 21 octobre à Toulouse. Il s’agit d’un thème important pour moi, car il englobe plusieurs principes de rupture pour l’informatique  :

• Les DSI actuelles doivent changer pour faire face à de nombreux nouveaux défis
• Les DSI doivent accepter la mutation pour se rapprocher des métiers et de ses clients.

Comment mettre en place une organisation qui permette l’émergence de l’innovation… sur la durée ? Il s’agit de comprendre comment est-il possible pour la DSI de proposer une industrialisation pour les projets innovants. L’entreprise innovante est-elle simplement une entreprise plus agile ?

Au-delà de l’aspect contextuel, je m’efforcerai de présenter une vision possible pour mettre en place une organisation permettant d’introduire des sujets innovants au sein d’une DSI. Mais l’innovation peut elle s’y inscrire ? il s’agit probablement d’un paradoxe, car pour être innovante, une DSI doit être industrialisée.

Voici quelques titres de thèmes que je compte aborder (en cours d’écriture) :

1. 2010: L’odyssée de la D.S.I. (ou en est la DSI ?)
2. L’écosystème IT est perturbé, CARL ne peut plus contrôler. (les métiers prennent le contrôle)
3. bienvenue dans l’empire du partout, de la profusion… mais surtout de l’éphémère ! (émergence de nouveaux modèles)
4. Organisation innovante : pas besoin d’inventer ! (entreprise 2.0, entreprise plateforme ?)
5. everywhere, everybody, everything (l’innovation n’est pas une direction)
6. naitre et  (souvent) mourir
7. téléphone maison (industrialisation des projets innovants)
8. l’humanité sauvée : la sécurité, enfin pas si sur… (sécuriser le S.I.)
9. La guerre froide (le financement)

Je suis bien sûr attentif à vos commentaires !

résumé de la présentation :

L’entreprise a de plus en plus besoin d’avoir un rôle d’anticipation, en terme technologique, mais surtout en terme d’usage. Les DSI sont au coeur de cette innovation. L’iPhone, la géolocalisation, les réseaux sociaux , l’ubiquité, l’ergonomie… sont des exemples qui ne peuvent être traités de manière traditionnelle. Le client final va être amené à pouvoir accéder concrètement à ces nouveaux concepts pour permettre de valider les nouveaux usages, ou pourquoi pas, lui même participer à l’innovation. Cela impose de mettre en oeuvre une infrastructure adéquate où les applications pourront être testées rapidement dans des conditions réelles.

L’image est issue du film “2001: L’odyssée de l’espace” de Stanley Kubrick.

Livre agilité, Table des matières

Je suis en cours d’écriture d’un ouvrage sur l’agilité et la méthode scrum, voici la table des matières (qui est une première version) envoyée aux éditions ENI :

Chapitre 1 : Émergence des nouveaux défis
Chapitre 2 : Réponses apportées par l’agilité
Chapitre 3 : Utiliser scrum comme méthode opérationnelle
Chapitre 4 : Déroulement itératif d’un projet scrum
Chapitre 5 : Planifier une stratégie agile
Chapitre 6 : Sous traitance d’un projet agile
Chapitre 7. L’usine de développement logiciel
Chapitre 8 : Gouvernance du S.I. Agile
Chapitre 9. Retours d’expériences
Chapitre 10. : Bibliographie & Webographie

Une première partie, assez importante, permet de présenter les nouveaux défis des DSI ou des petits projet et le pourquoi des méthodes agiles.

Globalement le positionnement de l’ouvrage est axé sur la mise en place d’une méthode agile adaptée pour l’entreprise, avec les problématiques de sous traitance, de communication, d’adhésion par les différentes organisations de l’entreprise, mais aussi de ressource humaine. La partie plus opérationnelle scrum est traitée sur deux chapites (3 & 4). La partie Gouvernance du S.I. Agile permettra d’avoir une vision globale de l’agilité par rapport à plusieurs projets agile (scrum ou non) et j’introduirai l’agilité en terme d’innovation du S.I. J’aimerai aussi aborder de manière importante le rôle du Product Owner.

J’essaye sur tous les aspects abordés d’expliquer le pourquoi de tel ou tel règle, pour que le lecteur l’applique en la comprenant, ce qui essentiel pour la réussite d’un projet agile.

Je suis en ce moment en train d’écrire une première partie de 10 pages (début du chapitre 4) que je dois envoyer à ENI le 4 août. Comme ce qui est préconisé dans les méthodes agiles, je soutiens fortement le feedback utilisateur des lecteurs, ce qui permet de s’améliorer. Ainsi n’hésitez pas à réagir

Merci!