Qu'est ce que c'est que cette journée Agile Open dans le Sud?

Comme son nom l'indique c'est dans le Sud que cela va se passer (vous savez, là où il fait toujours beau :), à Banyuls sur Mer plus précisement; à 38 km de Perpignan. Cette ville est réputée pour la couleur de son ciel et son vin légèrement sucré.

Une journée, à cheval sur le vendredi et samedi, pour prendre du temps et savourer la vue de l'Hotel *** des Elmes qui nous accueille, ainsi que sa cuisine qui nous enchantera.

Ce qui nous laissera largement le temps d'aborder tous les sujets que nous choisirons ensemble, pour peu qu'ils aient attrait à l'Agilité et au Craftmanship dans son ensemble ou dans ses moindres détours.

Des sujets de discussion mais aussi des ateliers improvisés, des serious games, du coding... au gré et aux envies de chacun et de tous.

Car c'est le format de l'OpenSpace Technology (ou Open Workshop) qui sera appliqué, dans le respect des 4 principes :

1. Les personnes qui se présentent sont forcément les bonnes personnes
2. Ce qui arrive est la meilleure chose qui pouvait arriver
3. Ça commence quand ça commence
4. Quand c’est fini, c’est fini

Avec une seule loi, la loi des 2 pieds : Utilisez les pour aller voir ailleurs dès que vous n’êtes pas en train d’apprendre, de contribuer ou tout simplement de prendre du plaisir.

Les sujets seront proposés en séance par les participants le vendredi après midi, et répartis suivant l’espace et le timing disponible, puis vous aurez jusqu’au samedi après midi  pour échanger et contribuer, et la restitution en groupe aura lieu à la fin.

Les inscriptions sont encore ouvertes et limitées à 31 places, dépêchez vous https://ticketlib.com/agileopensud

Le Forum ouvert est reconnu comme une méthode innovante qui permet de tenir des réunions dynamiques et productives. Cette approche de grands groupes a démontré qu’elle est efficace pour obtenir des résultats exceptionnels avec des groupes de plus de 2 000 personnes tout autant qu’avec un groupe de 5 personnes.
C'est une manière simple et pourtant étonnamment efficace d'organiser des réunions et d'améliorer la communication. Cette façon de faire permet d'aller plus en profondeur que la plupart des autres démarches d’animation de groupe. La technologie du Forum ouvert insuffle une nouvelle vie aux individus, aux réunions et aux organismes. Elle allie passion et responsabilité, créativité et réalisme.

La méthode Open Space Technology (Forum ouvert) a été élaborée au milieu des années quatre-vingts par Harrison Owen, auteur de plusieurs livres sur la transformation dans les organisations. Owen a appliqué ses travaux novateurs au sein d'organisations sur tous les continents, des grandes corporations aux groupes communautaires. De plus en plus connue, le Forum ouvert favorise la transformation positive au sein des organismes, augmente la productivité, inspire des solutions innovatrices, améliore la communication et accroît la coopération.
Dans les réunions, les structures peuvent faire obstacle aux choses qui importent vraiment. Il arrive souvent que ce soit au moment de la pause café que les gens discutent des vraies choses et qu'ils vivent les meilleurs moments. Le Forum ouvert, avec ses règles, ou plutôt ses principes peu nombreux mais efficaces, crée le même genre d'atmosphère où l'essentiel, c'est la communication franche et ouverte.

(tiré de http://www.agileopen.net/fr/node/119 )

tentative de définition: http://yfrog.com/z/nzsgg8j

le bien : http://yfrog.com/z/kgdb85j

le mal: http://yfrog.com/z/ocqdg2j

C'était Agile Innovation 2011, un évènement organisé par le CARA Rhone Alpes.

Comme la centaine de participants, j'en suis ressorti enthousiaste avec plein d'idées dans la tête.
C'est un point positif essentiel quand on participe à un évènement public de la sorte.
Forcément, la journée de la veille était plus classique, consensuelle
donc moins passionnante et moins enrichissante pour quelqu'un comme moi
qui a écumé déjà un certain nombre de ces rendez-vous (ce n'est pas une critique, juste pour dire que j'ai préféré ce qui suit).

http://agile-grenoble.org/start
http://agile-grenoble.org/2011/innovation

Le format était simple:  pas de sponsors, pas de grande salle, le tout
financé par la participation de chacun (50€),
pas de programme prédéfini
on arrive à 9h et Alexandre Boutin nous briefe:  préparez vous à être
surpris!

Cette conférence était organisée sous forme d’Open Space dans le
respect des 4 principes :
1) Les personnes qui se présentent sont forcément les bonnes personnes
(il n'y a pas de mauvaises personnes)
2) Ce qui arrive est la meilleure chose qui pouvait arriver
3) Ça commence quand ça commence
4) Quand c’est fini, c’est fini
Avec une seule loi, la loi des 2 pieds : Utilisez les pour aller voir
ailleurs dès que vous n’êtes pas en train d’apprendre, de contribuer
ou tout simplement de prendre du plaisir.

Les participants ont écrit sur des bristol A4 les sujets qu'ils
aimeraient voir débattus;
Il ne s'agissait pas d'improviser une présentation ou une keynote sur
un sujet dont untel était l'"expert":
celui qui proposait le sujet allait animer une discussion sans en prendre le leadership. (voir la charte du facilitateur de sessions Open Space http://www.qualitystreet.fr/2011/11/29/charte-du-facilitateur-de-sessions-open-space-technology/ )

Il devait en être le rapporteur, c'est à dire prendre la
responsabilité de retranscrire sur un paperboard les éléments que les
participants allaient s'échanger entre eux.
Pour faciliter ce "reporting", l'animateur d'un sujet pouvait
distribuer des post-it et des feutres, afin que chacun marque ses
idées et réflexions avant les exposer à l'auditoire. Ces post-it se
retrouvant sur des radiateurs d'informations, qui ensuite allaient être
tous exposés dans la salle de réunion principale, quelques clichés ici
http://flic.kr/s/aHsjwZQgnr

(je mettrai en ligne mes photos en début de semaine prochaine)

Il y a eu bien une cinquantaine de sujets, ce qui prouve que l'inspiration était au rendez vous. Les sessions
ont été réduite à 40mn avec jusqu'à 8 sessions en //
Elles se sont déroulées soit dans des petits salles (entre 5 et 20
participants selon les sessions et les différents horaires),
soit dans des coins de couloir, des petits espace improvisés,  le seul
matériel nécessaire étant le paperboard et quelques chaises.

Cela a vraiment bien fonctionné. Et à la fin de la journée, une rétro pour
l'ensemble, et une salve d'éloges . Tout le monde était comblé, ravi, peut-être même un brin frustré de n'avoir pu participer à tous les échanges, mais tous sont unanimes pour remettre ça le plus vite possible.

Voila le genre d'évènement qui remotive, qui donne le smile, et qui est
riche en enseignements, car c'était vraiment de l'échange et les idées
ont fusé; les débats étaient là, tout le monde n'étant pas forcément
d'accord; on a pu faire un état de ce qui se passe dans les autres
entreprises ou chez les consultants.
Bref, c'est vraiment une communauté qui s'est exprimée dans son tout et dans ses spécificités.

Pour ma part j'ai animé une discussion sur le BDD et sur le "craftmanship" (dont on est tombé d'accord sur le fait que la traduction en "artisanat logiciel" n'est pas satisfaisante).

Sur ce dernier point, tous les participants étaient ultra motivés pour que naisse "quelque chose" à l'échelle nationale (voire francophone),
dont je vous tiendrai informé sous peu.

comment abandonner le projet et embrasser le produit

(ou finalement quelque chose qui pourrait s’apparenter à un désenvoutement)

INTRODUCTION

Changer? Mais pourquoi faire ??

disait un jour le slogan d’une marque d’automobiles française.

Bonne remarque!

Tout le monde vous parle de “méthodes” Agiles, oh pardon, de pratiques agiles.

Vous pensez que c’est une nouvelle façon de gérer un projet logiciel?

Cet article vous convaincra (j’espère) que c’est avant tout une série de renoncements. Et que la transition n’est sûrement pas facile, ni miraculeuse.

Pour reprendre goût à la réalité, voici le palmarès de ce qui vous attend....

Frein #1: abandonner le cahier des charges

Laissez tomber ce bon vieux cahier des charges, rempli de besoins exprimés souvent maladroitement, toujours de manière incomplète, imprécise et hautement soumis à toutes les interprétations et variations. Il est la voie assurée vers l’échec.

C’est lui qui sert à produire les cotations les plus hasardeuses et les plus fausses; tout cela mène à la faillite du “projet” et à au retard, voir à l’abandon, de la livraison du produit.

L’abandonner sans regret, oui vous devrez!

difficultés à prévoir:

● transformer ce cahier des charges en expressions de comportement attendu, elles même transformables en tests exécutables.

● Pour cela vous devrez reprendre les exigences vaguement formulées dans le CC et les transformer en User Story ou Features.

● Vous devrez ensuite vous armer d’un bon outil de BDD (Behaviour Driven Development) comme Fitnesse, Cucumber, RSpec, Specflow... et traduire ces éléments en fonctionnalités (appelées "features" au niveau BDD) et scénarios exécutables, et donc vérifiables tout au long  de la construction du produit.

avantages: avec des spécifications clairement exprimées, non ambiguës, et vérifiables par un programme et non par un humain, c’est la garantie de ne plus passer des heures à éplucher et à tergiverser sur un cahier des charges (puis de recette) imprécis par nature, et se fier ENFIN à des mécanismes rationnels de vérification et de preuves que l’on peut constamment (et de manière répétée) mettre en route.

Frein #2: abandonner MS Project et les diagrammes Gantt

pour les irréductibles, ce sera dur!

Le diagramme de Gantt est une utopie. Vouloir prédire avec exactitude comment les choses vont s'enchaîner sur plusieurs mois, voire plusieurs années, avec une précision à la demi-journée, en sachant qui travaillera sur quoi et à quelle heure, c’est totalement irréaliste.

Oubliez cet outil qui vous fait perdre de précieuses heures, que dis-je? de précieuses journées à la mise au point d'un vain planning "classique".

Avec une approche Agile, remplacez le par un planning de Release.

difficultés à prévoir:

• La peur de croire que sans planning Gantt, il n’y a plus de projet.
• D’abord il faut penser “produit” et non plus “projet”.
• Arrêter de croire que le pilotage du projet c’est le contrôle des dates et des phases.
• Le vrai pilotage c’est le contrôle de la qualité.
• Il faut changer la gestion du temps par la gestion de la qualité et de l’alignement du produit avec les attentes fonctionnelles (et/ou les attentes du marché).
• Cela demande d’autres compétences que de regarder sa montre ou juste mettre de la pression inutile sur les équipes. Tout le monde n'appréciera donc peut être pas.

avantages:

● Avec une approche Agile (et SCRUM en particulier) la date de sortie (release) du produit est connue à l’avance. Il n’y a plus à se soucier du planning puisque que celui-ci est fixé à priori.

● Les itérations et les fins de sprints sont elles aussi fixées dans le temps. Le planning ne bouge pas et on a pas besoin de passer son temps à le ré-ajuster. Il est connu et accepté sans appréhension par toute l’équipe.

● Plus la peine de perdre son temps à rectifier un Gantt qui bouge sans cesse, dont les estimations sont par nature éloignées de la réalité, et qu’il faut constamment réajuster.

Frein #3: abandonner le papier et les documentations à outrance

cela fait partie des éléments du manifeste agile, mais c’est un point bloquant pour beaucoup de professionnel de l’IT.

Comme ils n’ont pas confiance (et ils avaient de bonnes raisons à cela) dans les développeurs, ils compensent par un maximum de documentation en imaginant que qualité = documentation.

difficultés à prévoir: comme toute habitude solidement ancrée dans le milieu du travail, s’arracher de la lecture d’interminables documents qui occupaient de longues nuit d'hiver sera un obstacle difficile à surmonter.

Plus que tout, c’est la translation de la valeur de la confiance qui va poser problème.

Pour ceux qui n’ont jamais testé la pratique du test driven developpement, il y a carrément une incompréhension , voir une aversion à croire que la documentation peut se remplacer par quelque chose de bien plus efficace et rationnel.

avantages:

● gain de papier, gain de temps, gain d’énergie à ne plus consulter ces satanés documents; c’est bon pour la planète (et pour vous, votre famille, vos proches).

● les tests et les spécifications formelles sont des formes de documents bien plus exhaustifs et fiables que la documentation écrite en langage naturel.

● Aucune ambiguïté n’est permise, là où l’on pouvait chercher pendant des heures la signification de tel ou telle phrase ou schéma.

● Les tests remplacent la documentation, car ils expliquent par l’exemple ce que la documentation “human-made” essayer d’exprimer par des circonvolutions littéraires.

● Ces éléments sont en plus compréhensible par un programme de tests, donc utilisables tels quels pour valider une recette. C’est un temps immense gagné en phase de validation de projet.... pardon, de produit!

Frein #4: oublier la recette et être obnubilé par les tests

pas facile de renoncer à ces bonnes vieilles habitudes. Surtout les plus contraignantes. Etonnant, n’est ce pas?

C’est très difficile à la fois pour l'exécutant, qui veut tellement bien faire son travail et satisfaire son client qu’il ne voit dans le cahier de recette que le seul moyen de faire approuver son travail (et se “sortir” du projet).

Également pour le client, qui ne voit dans la recette que le seul moyen d’exprimer son mécontentement et d’expliquer ce qu’il attend vraiment du produit qu’il a commandé.

J’ai même vu des clients qui se servaient du cahier de recette pour ré-inventer le cahier des charges, et rajouter tout ce qu’ils avaient oublié comme fonctionnalités attendues (pour le même prix, évidement). Il est naturel de vouloir ajouter ou changer des fonctionnalités, c’est le faire en fin de projet qui pose problème.

Alors pourquoi mettre cette phase en fin de planning si elle tellement cruciale????

Et pourquoi ne pas l’intégrer dès le début du projet et tout au long du développement.

Si les tests étaient le cahier de recette (tout autant que le cahier des fonctionnalités), ne serait-ce pas plus simple?

difficultés à prévoir:

• Avoir peur de perdre le contrôle.
• Arrêter de penser  que la recette est une fin en soi.
• Arrêter la politique de l’autruche.
• Avoir envie de ne plus perdre ni de temps, ni d’argent.
• Anticiper, plutôt que de reporter les problèmes à la fin du projet.
• Avoir peur des tests automatisés ou penser qu’ils sont une perte d’argent (!!!) ou qu’on a pas les moyens de les faire.

avantages:

● Immense temps gagné sur la phase de recette qui est remplacée par l’écriture des tests en continu pendant tout le développement et dès les premières lignes de code écrite (avant même).

● Phénoménal temps gagné sur les corrections habituellement faites après une recette ratée (80% de projet et +30 à +50% de temps supplémentaire nécessaire pour finir le projet), puisqu’il ne peut pas y avoir de corrections à faire, car les tests garantissent AVANT la recette que tout est OK.

● Les tests sont non-ambigus et vérifiables par une machine. Ils sont infaillibles  (alors que l’humain l’est) si ils sont bien écrits et en quantité suffisante .

● On ne passe plus du temps à vérifier chaque points du cahier de recette (et de specs), les tests sont exécutés automatiquement.

● Les tests s’écrivent de manière progressive, au fur et à mesure de l’avancée des Sprint et la constitution du baklog

● Les tests suivent le backlog, ils sont donc l’expression formelle des spécifications posées et arrangées avec le client (ou son product owner)

● puisque les fonctionnalités sont ajustables, les tests le sont aussi. Ils dérivent de l’expression des besoins, et permettent d’assurer la conformité du produit aux attentes, à tout moment de la construction du produit.

● Les tests anticipent toute erreur, et comme ils sont permanents, ils empêchent toute nouvelle erreur de s’introduire dans le produit (non-regression).

Frein #5: arrêter de penser que tout est prioritaire

là aussi, pas facile de changer. Comme dit l’expression populaire: vouloir le beurre, l’argent du beurre....

difficultés à prévoir:

● ne plus pouvoir “presser le citron” (ou autre expression à la mode).

● abandonner les relations de force et conflictuelles

● faire confiance à son prestataire

● devoir prendre conscience de ce qui est faisable et de ce qui ne l’est pas

● s’impliquer dans le projet et suivre (de très près) le développement du produit.

● accepter de renoncer (à ce qui n’est pas important).

avantages:

● la re-prioritisation permet d’avoir un produit qui marche avant tout! (sans défaut)

● la re-prioritisation permet d’avoir une meilleure vision de son propre produit

● évite de produire des fonctions qui seront au final inutilisées

● favorise l’ergonomie (simplicité d’utilisation) du produit

● rend le produit adapté au strict nécessaire, évite le superflu, donc fait faire des économies substantielles

● avoir l’incroyable souplesse de redéfinir les contours (fonctionnels) de son produit au fur et à mesure qu’il se construit

● pouvoir s’adapter aux besoins d’un marché soumis à des changements perpétuels.

● gagner en productivité et en compétitivité

● tenir la “deadline” (date de release/livraison du produit) de façon certaine

● s’assurer d’un Time To Market (temps de mise à disposition sur le marché) du produit adapté à un marché ultra-concurrentiel (ceci est critique pour de nombreuses sociétés).

Frein #6: abandonner l’ultra contrôle et la MOA (à l’ancienne)

pour les irréductibles, ce sera dur!

Le client qui donne des ordres, qui planche sur un cahier des charges pendants des mois ou des années, et qui laisse l’équipe de développement se débrouiller, pour ensuite se revoir le jour de la recette, ou lors des ces horribles réunions d’avancement, ou des interminables comités de pilotage:  c’est fini!

difficultés à prévoir: pour le client / MOA

● changer la façon de travailler

● sortir de la réunionite aiguë et des comités de pilotage,  pour enfin participer activement à la construction du produit

● rétablir la confiance avec son prestataire

pour le prestataire (“MOE”):

● supporter son client toute la journée

● ne plus pouvoir “imaginer” (ou même fantasmer) le produit seul dans son coin avec son équipe

● ne plus pouvoir balancer des diaporamas powerpoint en guise de démo au client

● ne plus pouvoir faire 3 ou 4 projets (ou plus!!!) en parallèle en jonglant avec les dates et en basculant d’un projet à l’autre selon les coups de pression des clients (très dur quand on est une SSII classique)

avantages: pour le client être assuré du succès du produit, et de sa livraison à la date convenue.

pour le prestataire : pouvoir passer à un autre mode de facturation, et ne plus être payé aux calendes grecques.

Frein #7: impliquer le client du début jusqu’à la fin

sans doute un des freins majeurs de l’adoption d’une d”marche Agile.

Vote client, le passeur d’ordre, et même ceux et celles qui sont les utilisateurs “pour de vrai” du produit-logiciel que vous devez livrer, devraient être avec l’équipe. Ou au moins se faire représenter, mais pas par n’importe qui et dans n’importe quelle condition.

difficultés à prévoir:

● que le client s'intéresse à son produit

● qu’il trouve du temps

● qu’il devienne ou qu’il nomme un vrai Product Owner

● qu’il évalue les livraisons intermédiaires (appelez les “releases”, “previews”, “beta” comme il vous plaira) successives du produit en cours de construction

● si le client opte pour la solution de se faire représenter (Product Owner); que son représentant se mettent vraiment à sa place, qu’il ait des échanges fréquent avec celui-ci non pas sous forme de comité de pilotage, mais par des sessions d’essai avec les éléments du logiciel en cours de construction (feedback nécessaire).

avantages:

● tout simplement prendre une forte option sur le succès du produit auprès des utilisateurs et du client (ou autrement dit, si le client n’est pas impliqué, ça sera passera très mal).

Frein #8: arrêter de penser que l’architecture des SI est une fin en soi

<<comment osez vous toucher à l'hégémonie des architectes?!>>

Après tout le temps qu’il a fallu pour faire reconnaître ce métier (je me rappelle encore l’époque où l’on nous traitait de danseuse...).

Pourtant, une architecture n’est pas un produit. C’est trop souvent une vue de l’esprit. Certes les POC sont des livrables, mais malheureusement ils ont une durée de vie très courte et ne sont pas intégrés dans le projet/produit.

Pour que l’architecte trouve sa place dans une équipe agile, il doit collaborer très fortement avec l’équipe. A tel point qu’il en perde son sceptre de pouvoir et redevienne le développeur sénior qui sommeille en lui (voir plus loin).

L’architecture n’étant plus une finalité, elle doit abandonner ses artefacts, et revenir dans le produit.

difficultés à prévoir:

● limiter (voir abandonner) les diagrammes UML et autres

● embrasser la conception émergente (ennemi juré des architectes) http://agilitateur.azeau.com/post/2007/08/10/Conception-emergente

● ne pas jeter le bébé avec l’eau du bain: DDD et BDD ont toute leur place dans la construction du produit.

avantages: xx

● fini les documents d’architectures ques les développeurs ne comprennent même pas

● passage à une diffusion du savoir par le contact directe entre développeurs et ex-architectes

● les développeurs repsecteront enfin les avis et conseils techniques et qualités des ex-architectes

Frein #9: abandonner l’architecte pour un développeur expert

ca va faire mal pour certains “architectes”. Il va falloir les redescendre de leur piédestal.

Mais que ceux qui ont peur pour leur salaire se rassurent: leurs compétences et connaissances ne sont pas remises en cause. Bien au contraire. C’est l’approche dans le travail qui change.

difficultés à prévoir:

● l’architecte ne donne plus des ordres et n’est plus un utopiste.

● Son rôle se transforme. Il ne travaille plus dans son coin ou avec ses autres copains architectes. Il n’est plus dans sa bulle et ne travaille plus hors du projet.

● Il ne fait plus des grands schémas théoriques. Il arrête de vouloir tout modéliser.

● Il arrête de concevoir des usines à gaz dans son coin.

● Il arrêt de croire que les tests ne font pas partie de l’architecture.

avantages:

● il revient à son premier métier: coder.

● Il se remet à travailler avec les développeurs. Il est leur référent, leur soutien indéfectible.

● Il les aide et les forme en permanence. Il leur explique par l’exemple et dans le cas du développement en cours, comment appliquer tel pattern ou comment utiliser telle ou telle forme de programmation (par contrat/interface, déclarative, impérative, en style fluent avec des lambas expressions, etc...).

● Il est le gardien de la “beauté” et la lisibilité du code. Il est le désigner et l’érgonome des API et des interfaces (voir mon article sur l’ Utilisabilité et l’  Ergonomie des Interfaces de Programmation).

● Il est aussi le gardien des règles de codages et des métriques de qualité.

● Il garde le lead sur les epic techniques (retrouvant là son rôle d’ancien architecte).

● Par ses connaissances, c’est souvent lui qui est amené à faire des prototypes rapides, du refactoring sévère, et la mise en place d’outil d’automatisation de certaines taches du développement (Intégration Continue, Tests automatiques, outils de BDD....).

● Il discute ses choix avec l’équipe de développement.

● Il (re)devient un développeur sénior. Ce rôle n’est pas réducteur, bien au contraire.

Frein #10: abandonner la séparation testeur/développeur

très difficile aussi. Pour autant, certaines organisations peuvent garder leur département QA, particulièrement chez les éditeurs logiciels. Il s’en trouvera alors renforcé par des compétences de développement, car le testeur doit aussi être un développeur. Le testeur dans un QA travaillera avec les équipes de dev, sera intégré dans les Sprint SCRUM, le planning poker, le daily scrum meeting, les rétrospectives...

difficultés à prévoir:

● faire aimer les tests aux développeurs. Leur faire comprendre que ce n’est pas une punition, ni un rétrogradage.

● Former ceux qui ne faisait que du test au développement. Les intégrer à l’équipe de développement. Accepter que l’on puisse changer de rôle et de casquette constamment.

● Travailler en pair programming entre anciens testeurs et codeurs purs.

avantages:

● appliquer l’approche Test First (TDD).

● Le développeur est autant un testeur qu’un codeur. Il vérifie à l’avance ce qu’il produit (et non plus à posteriori).

● Les tests sont nombreux et fiable. Le logiciel est ultra-robuste.

● Le plus nombreux les tests sont , le plus d’assurance sur la non régression du produit l’on obtient.

● Les testeurs vont diffuser leur expérience et leur savoir-faire aux développeurs et vice-versa.

Frein #11: mettre tout le monde au travail

Un peu polémique comme sujet mais en gros, voici un des points clé: l’équipe doit être soudée et solidaire dans l’effort. Les pratiques agiles repartissent les efforts de tel façon que tout le monde a ni trop ni trop peu de tâches à accomplir.

La transparence est également de mise: lors du dailing meeting, chacun s’explique sur son travail accompli, les difficultés rencontrées.

Grâce au tableau (façon Scrum ou Kanban), tout le monde connaît le reste à faire.

difficultés à prévoir:

● ceux qui pensait avoir un rôle mineur dans le projet, ou pouvoir travailler sur plusieurs projets en même temps se retrouveront d’une manière ou d’une autre exclu du projet.

● ceux qui culturellement, ont envie de sortir leur revolver quand ils entendent le mot “transparence” auront du mal à s’intégrer à l’équipe

● ceux qui pensait remporter en fin d’année une prime sur objectifs car ils ont devancé leur petits camarades ne se sentiront pas très à l’aise dans cette organisation

● si l’entreprise est hostile à toute forme d’auto-organisation et d’autonomie de ses équipes, cela se passera mal.

avantages:

● avoir une équipe soudée et solidaire

● partager l’envie de réaliser un beau produit pour un client satisfait

Frein #12: travailler sans pédale d’accélérateur

C’est la même chose qu’abandonner la voiture au profit du train.

Le projet était une voiture de formule1, dans laquelle on avait un accélérateur nerveux, qui pouvait propulser le bolide très vite... sur un mur! (ou une sortie de piste)

Avec le développement Agile, c’est un train que vous avez, et qui est sur des rails (le train de la release). Il n’y a donc plus de pédale d'accélération, mais un régulateur de vitesse.

difficultés à prévoir: ne plus pouvoir mettre la “pression” sur l’équipe. Ne plus pouvoir espérer rattraper son retard par de longues (et inutiles) nuits de travail. Être obligé d’anticiper et jouer sur le re-prioritisation plutôt que sur l’acharnement.

avantages: Le rythme de travail est constant et soutenable.

L’ambiance de travail est meilleure.

Les équipes sont productives

Frein #13: Admettre que seuls les tests automatisés sont fiables

et également que les tests manuels sont une pratique comparable à l’esclavagisme et devrait être fermement condamnés par la déclaration universelle des droits et devoirs du développeur.

difficultés à prévoir:

● ne plus pouvoir faire des petits “arrangements” (genre des slides powerpoint en guise de démo du produit)

● ne plus pouvoir minimiser les défauts.

● adopter la démarche TDD, c’est à dire écrire les tests avant le code.

● se parer du bon outil de tests automatisé

● apprendre le bon usage des tests ( Arrange / Act / Assert )

● s'intéresser au BDD (Behavior Driven Development) fait également partie de l’effort à fournir

avantages:

● fiabilité

● qualité

● diminution drastique du nombre de défauts dans les logiciels livrés

● sérénité de l’équipe et du client

Frein #14: faire du management visuel

Corollaire de l’abandon de Microsoft Project et des diagrammes de Gantt, les grandes feuilles de papiers (boards) collées aux murs vont sûrement envahir vos bureaux.

C’est aussi cela la communication et la transparence.

Vous pouvez aussi doubler ces informations avec une solution logicielle (comme http://www.icescrum.org/ ).

difficultés à prévoir:

● acheter du papier

● convaincre des employeurs allergiques à la présence de posters sur les murs

avantages:

● simplicité

● clarté

● accessibilité (information disponible 24/24 même en cas de coupure de courant)

● transparence (on voit ce qui avance et ce qui n’avance pas dans les Taches A Faire)

Frein #15: trouver la (bonne?) définition de ‘fini’

Qui dit afficher son TAF(Taches A Faire), dit savoir précisément quand une de ces taches arrive à son terme.

Toute l’équipe doit s’entendre sur une notion fixe de fini, et c’est un contrat qui est tacitement passé entre tous les intervenants.

Il n’y a pas de définition universelle du “fini”, cela dépend de l’équipe, de sa culture, de ses habitudes, des outils à disposition, du niveau d'exigence que l’on se donne, etc.

http://blog.octo.com/limportance-du-definition-of-done/

difficultés à prévoir:

● tâtonnements

● hésitations

● points de vue divergents

● non respect de la définition de fini

● glissement hasardeux de cette définition au cours de l’avancée du projet (parce que le temps se fait pressant)

avantages:  une fois le consensus obtenu, tout le monde c’est ce qu’il a à faire

et le travail exécuté est de qualité constante pour tous les membres de l’équipe.

Frein #16: mettre en place une intégration continue

c’est vraiment un outil technique dont on ne peut se passer.

Se référer (entre autres) à l’article de Laurent Carbonnaux à ce sujet

http://lolcx.blogspot.com/2010/11/integration-continue.html

difficultés à prévoir:

● temps de mise en oeuvre

● intégration de différents outils (tout n’est pas pré-intégré, c’est à vous à constituer le process qui vous va, avec les composants qui vous plaisent)

● mise au point (rodage)

● différences de technologies parfois (passerelles entre plusieurs monde et plusieurs outils)

avantages:

● que du bonheur

● des longues nuits de sommeil réparateur... (par contre se préparer à des lendemains de travail)

● tout est automatique, fiable et … enregistré! (suivi, historique....)

Frein #17 : mettre le Model Driven Development à la poubelle et penser produit avant tout.

je vais encore me faire plein d'amis chez les Merisiens, mais voici mon constat:  les applications "Data Centric" ont vécu, et elles nous on coûté trop d'emm**** pour pouvoir continuer comme ça.

Je fais partie de ceux qui pensent que les données, la base de données, représentent  rien de plus qu'une couche de persistance; qu'elle est un outil à notre service, et que nous ne devons plus en être esclaves.

Donc, exit les schémas de données (les affreux MCD) en début de conception (malheureusement quand le modèle de données devient important, un tel schéma sera utile en exploitation pour le DBA).
Le modèle de persistance de données ne doit pas être le modèle de l'application. On ne pense plus en terme de données mais en terme de comportement (de l'utilisateur sur le produit, et tout naturellement cela induira des données qui sont en mouvement sur les différentes étages de l'architecture de notre construction logicielle).

Difficultés à prévoir:

• abandonner une pratique ancestrale.
• Se mettre le DBA à dos (dans un 1er temps).
• Avoir confiance en un ORM (beaucoup de gens y sont encore réfractaires).
• Abandonner les procédures stockées qui contiennent toute la logique applicative.

Avantages:

• impliquer le DBA dans autre chose que de la modélisation de données (i.e. l'intégralité du projet)
• Vivre en 2010 ( i.e. utiliser un mapping ORM ou un No-Sql).
• Abandonner les procédures stockées qui sont un enfer à debugger
• Rétablir la logique applicative dans l'application et pouvoir utiliser des vrais patterns de programmation
• Pouvoir tester, et tester en isolation tout ce qui implique la persistance de données
• Etre indépendant du SGBDR choisi
• Faire "sauter" tout un tas de limitations que l'on avait quand on était "data centric".

Frein #17.0: être capable d’évaluer un ROI

Return Of Inverstissment, voila qui devrait faire adopter votre démarche agile par tout non-informaticien

Mais attention, un ROI n’est pas forcément que quantitatif, il peut être qualitatif aussi.

Ceci dit, se focaliser sur le ROI n’est pas une bonne idée: http://www.pragmaticmarketing.com/publications/topics/08/why-prioritizing-your-agile-backlog-for-roi-doesnt-work

Ce paragraphe est donc peu utile....

Difficultés à prévoir:

trouver la mesure du ROI.

Avantages:

connaitre le ROI.

Frein #18: penser comme un “marketeux”

Ligne de produit, offres, cibles, plus produit, Time To Market, market volatiliy, market adoption, Early adopters, Eco-design, burn out, Folksonomie , ...

http://lexicom.free.fr/index.html

tout va nous pousser à embrasser la façon de travail des gens du marketing afin de penser toujours plus le PRODUIT

difficultés à prévoir:

● jargon abscon

● risque de vouloir aller trop loin dans cette démarche

avantages:

● être proche du client et du marché du logiciel

● sortir de la vision 100% technique

● changer de stratégie, c’est adopter une stratégie oblique http://bit.ly/3lXY

Frein #19: changer de métier

gérer un Produit, ce n’est plus de la gestion de Projet.

Il s’agit bien et bel d’opérer un changement dans son métier et accepter d’abandonner l’idée d’être chef de projet pour devenir chef de produit, ou bien développeur sénior pour ceux qui ne veulent pas perdre leur expertise technique.

difficultés à prévoir:

● comme tout changement dans sa vie professionnelle, il faut d’abord que ce soit un choix, une envie personnelle et motivée

● passer par de l’auto formation, car aucune formation officielle n’existe.

● Prendre du temps pour soi.

avantages:

● Faire une transition en douceur, au fur et à mesure des développements agiles sur lesquels on peut travailler.

● Evoluer, changer, s’adapter.

● Adhérer à une association Agile est un bon moyen d’échanger et de discuter avec d’autres personnes concernées (autres que dans sa propre boite).

Frein #20: adhérer aux valeurs agiles

At last, but not the least!

Les quatre valeurs fondamentales Agiles sont :

Préférer

● Davantage l’interaction avec les personnes que les processus et les outils.

● Davantage un produit opérationnel qu’une documentation pléthorique.

● Davantage la collaboration avec le client que la négociation de contrat.

● Davantage la réactivité face au changement que le suivi d'un plan.

difficultés à prévoir:

ces valeurs ne sont peut-être pas les vôtres...

avantages:

ces valeurs sont sûrement les vôtres!

Guillaume Saint Etienne