Guillaume Saint Etienne 's Blog

Lien: https://ticketlib.com/agileopensud

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 )

Via: Medical Billing And Coding

Il y a eu un sujet qui s'est présenté spontanément à Agile Innovation Grenoble:  certification(s) agile(s).

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

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

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

bonjour à tous
votre correspondant en direct de Grenoble qui vous parle, pour vous faire un bref topo de cette journée très particulière.

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.

Lien: http://www.agiletoulouse.org/

Lien: http://sigmat.fr/dotclear/index.php?form/inscription

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

permettez moi tout d'abord de vous inviter à parcourir la présentation que j'ai déroulée au SigmaT 14 , qui fut un peu mon appel du 18 Juin à moi
http://www.slideshare.net/guillaumeagile/to-test-or-not-to-test

"les informaticiens parlent aux informaticiens, venez rejoindre les partisants IT libérés, venez faire du Test Comportementaliste! (BDD)"

vous pouvez trouverez moultitude de références sur le sujet en anglais , comme par exemple (et pour faire court) http://jockeholm.wordpress.com/2010/02/14/combining-tddbdd-with-ddd/

ceux qui comme moi, aiment partir de la théorie et arriver rapidement à la pratique, et qui on fait le choix de .Net, ont surement eu à se poser beaucoup de questions quant au choix de l'outil/framework de BDD/ATDD .

Si le choix semble plus évident pour la communauté Java et Ruby, qui est beaucoup plus active et unanime sur le sujet (ils ont Cucumber et RSpec, eux!), ceux qui travaillent en .Net peuvent se sentir un petit peu perdu, pour ne pas dire découragés.

Alors, voici pour se mettre rapidement et efficacement en selle, quelques liens rapides vers de bons articles en Français (et un peu en Anglais) qui explorent ces technos en détails (et avec tutoriels bien fait):

GHERKIN (sachez avant tout, que tout est centré sur ce langage, qui n'est pas un langage de développement mais un DSL prêt à l'emploi):

http://ryanlanciaux.com/ryanlanciaux/post/Gherkin-style-BDD-testing-in-NET.aspx
http://wiki.github.com/aslakhellesoy/cucumber/gherkin

MSPEC:

http://blogs.developpeur.org/tja/archive/2010/02/05/tests-suite-des-tests-unitaires-avec-mspec.aspx

NBEHAVE:

http://blogs.developpeur.org/tja/archive/2009/12/08/tests-tester-votre-site-asp-net-mvc.aspx
http://blogs.developpeur.org/tja/archive/2010/01/22/tests-nbehave-et-asp-mvc-2-suite.aspx
http://blog.developpez.com/bruno-orsier/p8428/bdd/nbehave-a-la-cucumber/

http://pebblesteps.com/post/Behavior-Driven-Development-with-NBehave.aspx

Cucumber/IronRuby:

http://blog.developpez.com/bruno-orsier/p8440/bdd/cucumber-avec-ironruby-ca-marche/#more8440

Cuke4Nuke :

http://gojko.net/2010/01/01/bdd-in-net-with-cucumber-cuke4nuke-and-teamcity/
http://stackoverflow.com/questions/2113936/cuke4nuke-or-specflow

SPECFLOW:

http://blogs.developpeur.org/tja/archive/2010/01/25/tests-ma-qu-te-bdd-continue-tests-unitaires-avec-specflow.aspx
http://www.specflow.org/specflow/technical-concepts.aspx
http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/
http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspx

quant à moi, je vous donnerai bientôt mon avis détaillé sur celui qui me semble être le meilleur d'entre eux...

désolé messieurs-dames, je m'inscris en faux. Le seul fait d'utiliser et d'imposer l'Open Source est selon moi tout sauf efficace pour lutter contre le gaspillage, le réchauffement climatique, la réparatition des richesses, l'amitié entre les peuples, le green washin', le social Washin'.... et tout autre concept "bankable".

Depuis plusieurs mois, il y a un effet de mode consistant à associer miraculeusement, et sans prendre la peine de réflechir, logiciels libres et écologie ou développpement durable:

http://www.rue89.com/passage-a-lacte/2010/04/13/et-si-le-web-20-menait-la-lutte-contre-le-rechauffement-146724

http://www.a-brest.net/article2641.html

pour quelques références lues récemment.

Quitte à me faire lyncher par les apôtres de ce courant (ce ne sera pas la première fois), je le clame haut et fort: l'Open Source n'est pas une cure à lui tout seul!

Pour y voir plus clair, et pour calmer ce débat, si ancien et si houleux, il n'est pas superflu de revenir à quelques définitions.

Open Source: logiciel (ou produit) dont les secrets et la méthode de fabrication (procédés, brevets, code source) sont rendus disponibles à tout un chacun et dont l'utilisation ou la modification ne demande (en théorie) aucune contrepartie financière.

L'impact environnemental désigne l'ensemble des modifications qualitatives, quantitatives et fonctionnelles de l'environnement (négatives ou positives) engendrées par un projet, un processus, un procédé, un ou des organismes et un ou des produits (de sa conception à sa "fin de vie").  d'après Wikipédia.

Impact environnemental (ou trace carbone) généré par un logiciel: tout surplus de calcul (temps CPU), d'espace de stockage (Octets en Kilo, Mega, Giga, Tera, Zeta...) et de transfert de données (flux d'Octets par unité de temps) lors de l'utilisation du dit logiciel qui aboutit à la consommation d'électricité, au réchauffement (refroidissement des machines, des data centers), à la fabrique d'équipements (réseaux, serveurs, postes, écrans) à base de composants polluants (métaux lourds, arsenic, retardateurs de flamme et autres poisons) nécessaire à sa mise en oeuvre.

Ainsi posé, il m'apparait difficile de valider que Open Source => Réduction de l'Impact Environnemental de l'Informatique.

Je m'explique. Pour moi à l'origine de toute informatique, il y a un programme, un logiciel (même dans un micro-controleur il y a un micro programme, de la plus simple machine à laver au super-calculateur) et donc du code source.

Tout le monde devrait tomber d'accord sur ce point (du moins j'espère).

Mais le fait que ce code source soit "open", c'est à dire "ouvert à quiconque" ne va pas changer beaucoup la donne écologique.

Ouvrir le code n'est en rien une garantie que l'impact du logiciel a été étudié et minimisé. En rien!

Certes le fait de distribuer ce code va permettre à une personne extérieure de vérifier si ce dernier est de qualité et si on a cherché à minimiser les ressources, les défauts, les gaspillages.

Mais à quel prix peut-on réellement et réalistement effectuer une telle vérification?

Qui d'entre vous a le temps d'aller regarder les dizaines de milliers de lignes (quand ce ne sont pas des millions) de tel ou tel logiciel (ou système d'exploitation).

Qui en a la compétence? Quel est le coût d'inspection de lignes de codes?

Combien d'heure de travail, d'heures d'utilisations d'ordinateurs et de serveurs pour déchiffrer un code qui certes est "libre" mais le plus souvent abscon quand il n'est pas, à l'extrême, bon à jeter à la poubelle.

la source de tous les maux?

Code ouvert n'a jamais été une garantie de facto de qualité et de lisibilité.

C'est là qu'il ne faut pas confondre "logiciel libre" et "liberté réelle"... le fait d'avoir accès à une chose ne veut pas dire qu'on la possède.

J'irai même plus loin en osant affirmer que posséder la source du logiciel peut dans certains cas être une formidable source de gaspillage, et donc d'élévation de l'empreinte écologique.

Se lancer dans l'exploitation de sources, passer du temps à les déchiffrer, les analyser, corriger un nombre important de bugs à postériori est du pur gaspillage de temps et d'énergie (réparer après conception et encore plus après construction coute des centaines de fois plus cher, c'est un fait maintenant admis).

Se dire que parce qu'on est en train de faire un logiciel ouvert, on peut laisser n'importe quel bug, puisque la communauté sera là pour les corriger est pour le moins hasardeux.

J'estime que la valeur et la fiabilité (logiciel durable) sont déterminées par des facteurs aussi intransigeants que la couverture de code par les tests unitaires, et qu'un code ouvert sans cela est absolument inutile et dangereux!

Ce serait comme si on vous livrait une voiture avec accès intégral au moteur, complètement ouvert, et que les centaines de pièces et micro-pièces que celui-ci renferme vous sautent au visage dès que vous ouvrez le capot alors que vous comptiez juste vérifier le niveau d'huile.

Comme si pour effectuer cette simple vérification il fallait déposer le carter et chacune des pièces pour trouver les éléments qui font jauge. Et bien sur, le tout sans manuel d'instructions, puisque l'accès au moteur est entièrement libre (vous n'avez qu'à vous débrouiller ou apprendre, ou payer les services d'un vrai expert... à chaque vérification d'huile! c'est ce que j'appelle un modèle économique bien senti).

Comme tout automobiliste moyen, je préfère un moteur bien étanche et fermé. Je n'ai pas la compétence pour démonter une bièle ou vérifier des roulements à billes (et je n'ai pas le temps de le faire, ni de l'apprendre; chacun son métier). Par contre je veux disposer d'un moyen simple et accessible (mot clef!) pour visualiser le niveau (métrique) d'huile, et d'un conduit accessible et sécurisé (ce qui s'appelle une Interface de Services ou API pour les logiciels) afin de rajouter l'huile qui manque ou de vidanger.

(pour ma part, étant plus motard qu'automobiliste, je m'en tiendrais plutôt à cette petite illustration :)

Pourquoi en serait-il autrement avec le logiciel?

Les seules personnes qui montent au créneau de l'ouverture du code sont bien souvent celles qui n'en ont jamais lu car elles n'en ont pas la compétence. Et c'est bien dommage de voir une fois de plus ceux qui prennent de grandes décisions (pour l'administration française notamment) tenir des propos aussi irresponsables.

Peut-on se satisfaire d'un logiciel sur la seule base de la disponibilité de ses sources, et d'une gratuité qui n'est ni le corolaire de l'ouverture des sources, ni garantie dans le temps?

Je n'ai jamais pu être convaincu que la qualité découlait automatiquement de l'ouverture du code, mais je reste ouverts aux arguments qui iraient dans ce sens.

En d'autres termes, on ne peut pas sérieusement réclamer la disponibilité des sources sans d'autres critères beaucoup plus précis, stricts et contraignant vis à vis des éditeurs et fournisseurs de solutions logicielles (SSII pour la plupart).

Ces autres critères sont interessants à explorer dans l'optique justement de la réduction de l'empreinte sur l'environnement.

Vous ne pouvez pas imaginer combien il est difficile d'obtenir des critères explicites reconnus par des "experts", tant le sujet est vaste, vague, animé de toutes les passions et des intentions les plus antinomiques.

Une fois de plus, Wikipedia m'a été bien utile (source: http://en.wikipedia.org/wiki/Sustainable_design )

Principes de conception durable (et application au génie logiciel)

Bien que d'un domaine d'application à l'autre, certains concepts ne puissent pas être translatés, voici quelques principe généraux applicables au logiciel:

• Low-impact materials:
  choisir des composants et des sous-systèmes qui ont eux même mesuré la réduction de leur impact (malheureusement je ne connais aucun logiciel qui le propose à ce jour) (1)
  
• Energy efficiency:: efficacité énergétique
  
  • efficacité en SLOC: moins de ligne de code = moins de risque de bugs mais aussi de fonctions inutilisées (moins de stockage pour ces fonctions et moins de CPU pour des calculs dont le résultat n'est pas exploité in fine). C'est aussi un facteur indiquant qu'il y a eu refactoring et que les algorithmes sont certainement optimisés (à vérifier avec ce qui suit).
    
    
  • efficacité en cycles CPU: pour chaque feature, mesurer le nombre de FLOP consommé pour une action (utiliser la base des User Story) donnée.
    
    
  • efficacité en stockage: mesure en Octects de la quantité de stockage nécessaire à une feature ou une opération.
    
    
  • efficacité de la persistence et du rappatriement de données: calculer les cycles CPU pour faire une requête, et calculer l'encombrement mémoire (ou sur les flux) des informations remontées depuis le mécanisme de stockage (objectif avoué: bannir le "select * from"). Penser aux atouts (et faiblesses) du NoSql.
    
  • optimisation l'encombrement sur le réseau: calcul du nombre d'informations en transit entre le client et le serveur (web ou autres) en terme de débit moyen en fonction de l'usage (une fois de plus les User Story sont un bon point d'entrée). Format condensé des données (préférez JSON à XML). Pertinence des données échangées (supprimez le superflu). Penser "Just In Time" (la bonne information au bon moment): l'utilisateur n'est pas une machine, pas la peine de lui afficher des tonnes d'informations qu'il ne lira pas.
• Quality and durability:
  • qualité: absence de bug prouvée: mesure du taux de couverture du code par des tests unitaires qui ont échoué mais qui n'échouent plus.
  • durabilité:  présence de tests unitaires ayant un rôle évident dans la surveillance de la non-regression et couvrant l'ensemble des fonctions.
• Design for reuse and recycling: c'est la fameuse ré-utilisabilité du logiciel, qui est trop souvent soit un voeux pieux, soit un graal jamais atteint
  • Interfaces Publiques Documentées: soit des APIs, soit des Web Services, soit une interface REST, mais toujours documentées avec des exemples concrets d'utilisation (guide sous forme de HOW-TO)
  • Ergonomie des API (ou Services): les parties d'inter-communications (interfaces) doivent être très sérieusement pensées dans un souci de non-gaspillage de ressources et de facilité d'utilisation. Pour être viables, elles doivent pouvoir être utilisées (consommées) sans dépenser de surplus d'énergie, c'est à dire sans avoir à passer 3 heures à comprendre comment ca marche, ou à devoir fournir au moment de l'appel des tonnes d'informations qui ne seront peut être même pas exploitées (penser au coût de récupération des données).
  • voir mon article sur l'érgonomie des API http://docs.google.com/Doc?id=dhp3ggmx_38f58b3d
  • commercial 'afterlife'. ^{dans 10 ans, votre bout de logiciel devrait encore pouvoir servir à d'autres, même s'il n'a plus vocation d'être commercialisé}
• Pérénité: votre système ou sous-système doit pouvoir être adapté à tout changement de l'environnement (évolution des échelles, les mesures, conversions, valeurs fluctuantes...).
• Sustainable Design Standards : on peut espérer (ou rêver) dans un avenir proche voir l'émergence d'un éco-label pour le développement logiciel durable. Celui-ci énoncerait des métriques précises et des niveaux de seuil en dessous desquels on peut considérer que le développeur du logiciel a fait des efforts significatifs visant à améliorer la qualité de son produit et la réduction de l'empreinte énergétique.
• Biomimétisme: inspirez vous de ce que la nature fait quand vous devez inventer un algorythme ou un processus. Ce qui a survecu pendant des millénaires est forcément viable (principe de Darwin).
• Service substitution:  être capable de changer le mode de consommation des services sous jacents (stockage, services bancaires, services de transaction, d'authentification, de sécurité, de cache...) et se tourner au fur et à mesure qu'ils apparaissent vers des systèmes offrant les même services mais avec une utilisation des ressources minimisée par unité de consommation (par User Story par ex.) Ceci requiert d'avoir mis en place une solide architecture de couches découplées dans le produit logiciel.
• Renewability: Renouvelement du système: votre code devrait pouvoir se renouveler lui-même et offrir de nouveaux services plus efficaces et moins cher quand ceux-ci seront disponibles.
• Eliminer le concept de déchet: le déchet dans le logiciel ce sont les fonctions (features) qui ne servent à rien. Et le code mort (unreachable code). Et bien sur, pas une ligne de code sans tests!
• Recherche de l'amélioration constante par le partage de la connaissance: encourager la communication directe entre les clients (consomm'acteurs) et développeurs (producteurs) du logiciel, mais aussi entre les responsables d'équipes, de projets, d'entreprises, les DSI, permettra de lier développement durable sur le long terme , responsabilité éthique et satisfaction des clients.
  
• Connaitre et comprendre les limites de son propre design (vertu de la sagesse).

(1) quant au choix des sous-systèmes sur lesquels va se reposer tout ou partie de votre solution, qu'il s'agisse de bouts de code récupérés, d'objets ré-utilisables, APIs, services tiers, Frameworks ou librairies, Open Source OU PAS!!! soyez intransigeant et évaluez les points suivants auprès de votre fournisseur:

• niveau d'abstraction: la vision que l'on peut extraire à la lecture des contrats de service
• style d'apprentissage: le niveau de connaissance requis et le temps d'apprentissage pour être efficace en utilisant ces services/interfaces/objets
• étapes de travail: combien de taches de programmation sont accomplies en une étape d'appel d'opération
• évaluation progressive: est-il possible de (mieux) comprendre comment marche le service au fur et à mesure de son utilisation.
• portée des engagements: le nombre de décisions que le développeur doit prendre dans un scénario impliquant l'utilisation de ce service, et leur portée.
• pénétrabilité:  comment l'exposition du service permet d'explorer, analyser et comprendre le métier sous-jacent et l'effort qu'a à faire le développeur pour récupérer les informations dont (le service) a besoin pour fonctionner correctement.
• viscosité: les barrières rencontrées et les changements (dans votre conception initiale) que va induire l'utilisation de ce service.
• consistance:  voir en détail l'article http://docs.google.com/Doc?id=dhp3ggmx_38f58b3d
• expressivité du modèle: comment apparaissent les relations entre les opérations entre elles, et les services entre eux également.
• alignement avec le domaine/métier:  évidement un aspect essentiel dans l'évaluation d'un service.
• résilience: capacité à fonctionner en mode dégradé et à se remettre en état de fonctionnement
• découplage (visibilité des dépendances): la nature et la complexité des systèmes externes (objets, librairies, services, framework) nécessaire au fonctionnement de ce système, et la capacité à les changer sans toucher au code source (c'est à dire  laisser le choix de la dépendance  au consommateur du système et non à l'imposer).

Qui se soucie de l'empreinte environnementale d'un logiciel?

aujourd'hui, je crois à peu près personne. Et pourtant, si on convertit (cycle CPU + espace de stockage + débit réseau) x (cout énergétique kWh) en équivalent d'arbres sacrifiés ou mètres cubes d'eau déplacés, on commencerait peut être à refléchir que le tout numérique est aussi une source de pollution non négligeable.

Mais tant que nos sociétés ne sont pas encore passées au tout numérique, voila qui ne passionnera pas les foules, ni les responsables d'un tel gachi... faut-il pour autant attendre de faire beaucoup de dégâts  avant d'agir?

 

Lien: http://bit.ly/aX5vsU

pour ceux qui veulent mettre en place des tests rapidement et efficacement sur une application Asp.Net MVC... voici une version courte de mon précédent article.

A l'essentiel cette fois ci, ou comment mettre en oeuvre une politique de tests unitaires qui marche, et qui fait des vrais tests!

1) choix des fra mework

2) tests des vues

3) tests des contrôleurs

4) isoler (mock) les contrôleurs de leur partie métier (domaine)

5) inversion de contrôle pour fonctionner en test et hors test sans rien toucher

le détail est à lire ici:

http://bit.ly/aX5vsU

Lien: http://docs.google.com/View?id=dhp3ggmx_168c5md3p52

Lien: https://twitter.com/guillaume_agile

finalement, Tweeter s'avère parfait pour les reflexions instantannées, je vous invite donc à me suivre aussi là bas

https://twitter.com/guillaume_agile

et ici, toujours des articles de fond et/ou pratiques ; comme le prochain sur le Test avec Asp.Net MVC

je m'amuse souvent (et pas forcement innocement)  à faire le parralèle entre mon métier actuel de "faiseur de logiciel" et mon passé d'étudiant en cinéma et audio-visuel  (passé trop court, mais les contraintes matérielles de ce bas monde et quelques autres paramètres en ont décidé autrement).

Comme ils nous cassent tous les oreilles avec ChromeOS (ok, j'aime Android et j'assume), n’oublions pas que MS va aller beaucoup plus loin qu’un simple Linux revampé et des WebApps (même si c’est l’avenir) tournant sur un omni-navigateur (Chrome+Gears)

Un article de référence pour soutenir mes propos:

http://www.sdtimes.com/MICROSOFT_S_PLANS_FOR_POST_WINDOWS_OS_REVEALED/About_CLOUDCOMPUTING_and_MOBILEDEVELOPMENT_and_NET_and_SOASAAS_and_SOFTWAREDEVELOPMENT_and_WINDOWS_and_MICROSOFT/32627

Peut être vous saviez déjà que ca s’appelle Midori, mais le modèle de programmation va changer :

The Midori programming model will tackle state management, which Microsoft admits in its documentation is a challenge in Windows, by migrating APIs, applications and developers to a constrained model.

Là où ca devient palpitant (pour les développeurs):

Other objectives are eliminating dynamic loading and in-process extensions; developing a failure model based on reliable transactions, so the system understands exactly which processes are impacted by a cascading failure and how to restart the computation; and having a standard way of dealing with latency, asynchronous behavior and cancellation, throughout the stack.

Un OS intelligent qui se protégé tout seul des plantages et qui arrête de faire confiance aux programmes qu’il execute ? comme par hasard, c’est aussi l’idée de Google dans ChromeOS

Mais, plus de protection, et donc plus de contrôle = moins de souplesse

restricting dynamism at the OS level will not impact dynamism at the programming level.”
ouf, on est sauvés!

Et OSLO pourrait revennir sur le devant de la scène :)

In a possible link to Microsoft’s Oslo composite application initiative, the programming model will have a dependence on metadata, with the aim of allowing the system to more reliably manage applications.

the proposed OS would have a non-blocking object-oriented framework API. This would have strong notions of immutability—in the sense of objects that cannot be modified once created—and strive to foster application correctness through deep verifiability by using .NET programming languages.

Un OS orienté objet et transactions? On en rêvait….

Mais la concurrence est là:

“A lot of these problems are being solved, at least partially, by the ideas of store-and-forward and message synchronization,” Hammond noted. “Google Gears, Adobe AIR, even the mobile OSes with things like SMS can handle occasional connectivity. Why shouldn’t this be built into core OS communication protocols, especially if they are asynchronous by default?” he asked.

Qui sera le vainqueur des OS de demain ? non pas de savoir quel éditeur car il s’agit d’une guerre commerciale… mais quelle technique ?

Y-a-t-il un futur pour la recherche sur les OS tels que nous les connaissons aujourd’hui, et donc pour les suites de Windows… (ou MacOs)

Ou bien l’OS va-t-il devenir le grand perdant de cette bataille, et toutes les nouveautés ne seront-elles pas reportées sur les omni-navigateurs (ou plateforme applicatives virtualisées comme pourra le devenir Air ou même Eclipse), sur les interpréteurs et sur les petits moteurs de synchronisations comme Gears. Mais qui laisseront l’OS à une place dérisoire, et qui n’intéressera plus aucun développeur…

A lire : Une très intéressante présentation des principes de Singularity (mais vieille de 2006 !) :

http://research.microsoft.com/en-us/um/redmond/events/fs2006/presentations/23_Hunt_071706.ppt

http://research.microsoft.com/en-us/projects/singularity/

la guerre continue: http://blogs.zdnet.com/microsoft/?p=4650&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+zdnet/microsoft+(ZDNet+All+About+Microsoft)&utm_content=Google+Reader

mais Microsoft fait toujours office de suiveur... dommage