Post #500

Il me semble qu’il n’y a pourtant pas si longtemps que j’ai marqué d’une pierre blanche la première année de mon blog. Oui, c’était il y a à peine plus d’un an. Mon rythme est donc disons… honorable ! Revoyons tout cela en chiffres !

Mon blog en chiffres !

Il y a un an, je me réjouissais de mes 221 posts. Un an et deux semaines plus tard, ce sont donc 279 nouvelles entrées qui s’y sont ajoutées.
Au niveau rythme, après un petit creux de début d’année, je tourne à une moyenne d’un peu plus de 20 posts par mois. Considérez quand même qu’un post sur trois est une citation et cela rend la chose moins démente.

Histogramme posts tumblr

Plus intéressant à mon goût : l’évolution des Notes de lectures si je les compare aux autres billets (en excluant les citations). Sur les 12 derniers mois, la tendance s’est inversée par rapport à l’année précédente. Les billets dépassent en nombre les notes de lecture, parfois de beaucoup.

Stats billets vs Note de lecture

La fréquentation

Elle semble en augmentation !

Statistique de fréquentation 2012-2013

En fait, il faut la rapprocher de celle de l’année précédente. Toutefois comme je n’ai mis en place les analytics qu’en Mars 2012, il me faut “normaliser” les données sur les deux années. J’ai donc multiplié les données de la première année par 1,5 ; ce n’est pas tout à fait juste, mais disons que c’est une approximation acceptable.

Stats 1ère année vs 2nd année

Les chiffres font apparaitre une augmentation substantielle des visites, ou plutôt des visiteurs uniques (le chiffre que je préfère suivre). 

Les rebonds paraissent important (en baisse insignifiante), mais c’est plus probablement lié au fait que la plupart des visites viennent des liens Twitter. Malgré tout, deux chiffres me surprennent : la diminution très sensible des pages vues par visite : de 2,72 à 1,7 ! Cela se traduit de manière naturelle par une diminution du temps passé à chaque visite : de 2,72 mn à 1,77 mn. Normalisé à une page, cela fait 57 sec par page sur la première année et 1,13 min par page sur cette dernière année.
Qu’en est-il des browsers ? C’est assez stable, avec un poil de perte de terrain de Firefox et un poil de regain côté Safari, mais pas de gros changements à part ça…

Stats browsers 2nd année

See you next time

Déjà 500 posts. Peut-être devrais-je réduire le rythme ? Hélas, j’ai encore quelques sujets sur la pile. La prochaine synthèse est prévue pour mon millième post. Espérons que ce soit dans un bout de temps !

Note de lecture : SQL Server 2008 Integration Services, par Erik Veerman, Jessica M. Moss, Brian Knight & Jay Hackney

Note : 7 ; Un ouvrage vraiment fait pour bien utiliser SSIS et pas seulement l’expliquer

Pas facile de trouver un ouvrage sur SSIS en expliquant le fond, le bon usage et ne se limitant pas à la description de l’outil ! Ce livre est celui-ci. Il s’adresse au praticien déjà expérimenté de l’ETL de Microsoft et propose une série de patterns de mise en œuvre afin de bien architecturer un projet SSIS ! Franchement c’est tout simplement la seule source d’information (livres et Web inclus) que j’ai peu identifier faisant cela !

Le biais du livre, désavantageux du point de vue de ma propre utilisation, est qu’il est orienté solution BI. Ainsi les 12 chapitres de ce livre de 420 pages s’orientent-ils dans ce sens selon les étapes logiques de réalisation d’un projet SSAS. Mon intérêt direct d’arrêtant donc vers les chapitres 6 ou 7. Mais je ne doute pas que le développeur BI trouvera beaucoup d’intérêt au reste du livre.

Je dois bien aussi avouer que même si seule la première moitié du livre m’a intéressé (la seule que j’ai lu, en fait), j’ai considéré mon achat amorti sur cette seule partie !

Le premier chapitre évoque les architectures de déploiement possibles avec SSIS. Pour chacune d’entre elle, on évalue ainsi les bénéfices et les aspects négatifs. Tout ce qu’il faut pour arrêter un choix en connaissance de cause.

Au chapitre 2, on traite la mise en place d’un « Framework » dans lequel vont s’inscrire les intégrations. Cela recouvre les problématiques de configuration d’auditabilité, de logging et de gestion d’erreur. Là encore des domaines où sont plus détaillées les caractéristiques de SSIS que la façon intelligente de les mettre en œuvre. Comme ici. Oserai-je dire qu’à ce point, j’avais déjà de quoi être satisfait de mon achat ?

Le chapitre 3 est assez court, il traite des options de déploiement des packages SSIS. Il y en a plusieurs, mais jamais avant cela on ne m’avais expliqué les traits des différentes options. C’est chose faite, je comprend mieux et saurais désormais décider en connaissance de cause !

A partir du chapitre 4, on rentre dans l’usage des tâches de SSIS. Et pour commencer le traitements des fichiers. Les auteurs présentent ici leur approche encore une fois, pas seulement l’utilisation de l’outil. Même si j’ai moins appris que sur les chapitres précédents, il y a clairement du savoir faire à réutiliser…

Le chapitre 4 propose des « bests practices » pour les problématiques d’extraction et de stagging des données. Même s’il est d’usage général, ce chapitre s’inscrit plus dans une optique de projet BI.

Il en va de même pour les chapitre 6 (où j’ai arrêté ma lecture) qui s’attache aux problématiques de nettoyage des données.

Je reprendrais certainement cette lecture un jour, en fait les problématiques BI m’intéressent également. Quoi qu’il en soit, j recommande sans réserve ce livre pour le praticien déjà aguerri de SSIS : le savoir-faire qu’il propose n’existe pas ailleurs !

sql-server2008-IS-wrox

Référence complète : SQL Server 2008 Integration Services : problem, design, solution – Erik Veerman, Jessica M. Moss, Brian Knight  Jay Hackney – Wrox 2010 – ISBN : 978 0 470 52576 0

Microsoft SQL Server 2008 Integration Services: Problem, Design, Solution

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

Carnet de route : Agile Tour Bruxelles 2013 (2/2)

Lunch break

En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.

atbru13-06lunch02

De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.

atbru13-06lunch04

Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !

atbru13-06lunch03

Joanne Ho : Agile methodologies for research

Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.

atbru13-07joanne-ho02

L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe ! 

Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ?
Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:

  • Le client : c’est la société (au sens large).
  • Le produit : de nouvelles connaissances
  • La Définition de terminé : la pertinence sociale

Enfin oui, Joanne utilise un backlog. 

Un backlog très mouvant, il faut bien le dire, car :

  • Un item peut ne pas aboutir, nécessiter de nouvelles de nouvelles informations et donc être mis en suspens.
  • Il peut générer d’autres items.
  • Provoquer l’obsolescence d’items déjà présent dans le backlog.

Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog…
Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause.
Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !

IMG_0121

Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ?
Traditionnellement, la structure d’une telle équipe serait :

  • Le travail en silo est le standard.
  • Beaucoup de compétition interne.
  • Peu de transparence. Les revues de pair tournent vite aux critiques, voir aux insultes !
  • Les stakeholders sont des personnes imaginaires.
  • Une reconnaissance basée sur la quantité.

Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :

  • D’abord comprendre le problème, définir ce que l’on veut tester. Et donc faire l’expérience du stakeholder en allant sur le terrain.
  • Définir l’objectif, en définissant le critère de succès.
  • Une réflexion en binôme, pour modéliser toutes les facettes du problème. Ce travail doit produire des hypothèses.
  • Les tests unitaires, ce que Joanne appelle le “reality check”.
  • L’intégration continue : la mise en commun des éléments.
  • L’acceptance test : Une solution globale acceptable par le stakeholder.

En conclusion…

  • On peut utiliser l’agilité littéralement partout !
  • L’agilité est surtout une attitude.
  • Sans dialogue, on n’aboutit à rien.
  • Se déplacer pour aller réfléchir à différents endroits, sur le terrain.
  • Mettre toutes ses tâches dans un backlog.
  • Travailler en équipe est une chose nouvelle dans les université. ON n’a pas encore de modèle de fonctionnement pour cela.

En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir !
La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.

Facile à bien utiliser, difficile à mal utiliser

C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !

IMG_0234

La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…

atbru13-08easy-touse01

Domenico Musto : Event-Driven Architecture in Practice

Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée ! 

Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets.
Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.

atbru13-09eda04

Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :

  • Enregistrements d’une base de données.
  • Fichiers
  • Messages d’un MOM (quand même !)

Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :

  • Des évènements
  • Des commandes
  • Des doc-messages ; ce dernier type de message est auto-porteur. C’est un paradigme “push” dans lequel le message comporte tout ce qui est nécessaire au traitement par le composant cible. C’est le modèle vers lequel on souhaite se diriger.

L’architecture EDA implique aussi de nombreux corollaires :

  • Le cas des données de référence : Elles doivent être embarquées en partie dans le doc-message. Cela me rappelle un certain nombre de considérations autour du MDM…
  • La consistance (de l’ordre) des identifiants d’évènements : leur ordre est-il garanti ? S’il ne l’est pas, il peut y avoir nécessité de versionner les entités afin d’en reconsidérer l’historique depuis n’importe quel évènement.
  • L’idempotence, ou la capacité à rejouer un évènement. Cette propriété va de pair avec le versionning.

L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres.
La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0
Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…

Clôture et dernier verre !

Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.

atbru13-10cloture01

C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !

atbru13-10cloture03

Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…

Agile Tour Bruxelles 2013 : presenter gift

Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).

atbru13-11dernier-verre02

J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…

atbru13-11dernier-verre08

Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…

Carnet de route : Agile Tour Bruxelles 2013 (1/2)

Nous y étions tout juste 70 l’an dernier. Cette année, ce ne sont pas moins de 180 badges qui seront distribués aux participants ! L’Agile Tour Bruxelles a pris une nouvelle dimension pour sa seconde édition.

atbru13-01accueil04

Parti à 6h20 de Paris, on apprécie évidemment d’être bien accueillis. Cela semble se vérifier d’année en année en Belgique.

atbru13-01accueil07

Petit café et discussion habituelle entre frenchies avant le début de la première pleinière. Tiens, on se demande bien pourquoi on va jusqu’en Belgique si c’est pour continuer de discuter entre nous.

Un mot d’introduction

Pas de Keynote en Belgique, et donc du coup plus de sessions “au choix” auxquelles participer. On a quand même le mot d’accueil des organisateurs.

atbru13-02ouverture06

C’est Bruno Sbille qui, comme l’an dernier, est le maître de cérémonie. Un excellent choix qui nous permet de goûter son inénarrable “accent Anglais”. Il le précise d’ailleurs lui-même : “I am speaking English right now” !

atbru13-02ouverture04

Cette introduction présentait deux petites originalité. La première était de nous présenter à nos voisins. Sympathique, quoique j’avais un peu l’impression de me retrouver à l’église à souhaiter la paix du Christ au gars situé à ma droite…
La seconde originalité devient plutôt une tradition de l’Agile Tour Bruxellois : chaque orateur est invité à teaser sa présentation devant l’assemblée entière durant une minute ! Une bonne idée, je trouve, qui était déjà présente l’an dernier.
Il est maintenant temps de se diriger vers notre première session !

My Product is a James Bond Movie, par Pierre Neis

“My name is Neis, Pierre Neis” ! C’est ainsi que Pierre débute sa session. Avec lui, le show est assuré ! L’introduction est toutefois un peu longue. Pierre bosse dans une grande compagnie, qui est globale, qui fait de l’agile et améliore ses techniques, et… Mais Pierre n’est pas satisfait !

atbru13-03Neis02

Il manque quelque chose, des choses !

  • Le “fun”.
  • L’excitation
  • La relation directe au client.

Bref, il manque de quoi faire de bons produits. Et de bons produits ne sont pas des produits standards!
Pour Pierre Neis, les bons produits peuvent s’inspirer de la recette des films de James Bond :

  • De gros succès
  • Une trame facile à comprendre
  • Toujours la même recette, en fait.

Et cette recette Pierre nous la décode ainsi : Boom ! => Yeah ! => Yeah ! => Boom !

  • Le premier “Boom” corresponds à l’avènement de la roadmap.
  • Les “yeah” suivants correspondent aux démos (amazing sessions !)
  • Le dernier “Boom” est la release vers le client.

C’est un peu long pour arriver à l’idée finale, mais celle-ci mérite d’être creusée.

Pause du matin

Parmi les petites originalités de cet Agile Tour figurent les pauses: elles ne font pas moins de 30 minutes. Les organisateurs ont en effet acté que beaucoup d’échanges s’y passent qui font la valeur de l’évènement. Ils ont donc rallongé les pauses !

atbru13-04pause-matin06

Produits bio et développement durable au menu de ces interludes.

atbru13-04pause-matin02

Et aussi, bien sûr, échanges entre participants et orateurs.

atbru13-04pause-matin10

Lean Startup for Developers : you can do it to ! Par Sébastien Arbogast

Je me suis tout bonnement trompé de salle ! Ce n’est pas cette session que j’avais sélectionné dans le programme ! Bien m’en a pris, ce fut ma session préférée.

Sébastien nous évoque sa propre expérience de Startuper. Une expérience qui a fini par s’arrêter d’ailleurs, mais qui ne signifie pas que l’orateur n’ait rien appris de valable à nous partager. Bien au contraire. Son expérience commence lors d’un startup week-end en 2011 auquel il s’était inscrit tardivement et qu’il avait préparé à la va-vite. A sa propre surprise … il a gagné ! Ainsi est né Kodesk, l’idée d’un service de partage de bureaux. Une idée qui n’a jamais pris l’ampleur escomptée car Sébastien avait sous-estimé la crainte fondamentale d’accueillir des étrangers au sein des bureaux d’une compagnie ! Mais de cette expérience a germé une autre idée : Peer Trust.
Mais ceci n’était que l’introduction. L’objet de cette présentation est à venir : Est-il possible de créer une startup pour n’importe qui ? Comment faire en appliquant le “lean startup” ?

atbru13-05leanstartup02

Sébastien veut nous convaincre et nous rassurer : NOUS pouvons le faire !

  • On a les compétences : pas besoin d’avoir un MBA !
  • Nous avons les opportunités : il suffit de regarder autour de nous.
  • Nous pouvons avoir les moyens : il existe de nombreuses initiatives destinées à aider.
  • Trop vieux ! Mais non, on n’est jamais trop vieux.
  • Mon idée n’est pas assez bonne. En fait le concept de “l’idée originale” est plutôt surévaluée. Allons même plus loin : l’idée n’a pas de valeur intrinsèque, tout est dans l’exécution.

L’une des choses qui nous effraie le plus est de perdre notre boulot … pour obtenir quoi ? En fait, il n’est pas utile de quitter son travail, en tout cas pas tout de suite. Sébastien nous conseille même d’attendre le plus possible, chose que lui-même n’a pas faite.

Votre produit n’est pas votre produit ! Votre produit est un business model. Et qui dit “business model” dit “business plan”, n’est-pas ? Erreur !

atbru13-05leanstartup05

Mais l’entrepreunariat n’est pas une loterie. En vérité, on commence en ne sachant rien sur nos clients potentiels et il faut avoir le courage de l’admettre. Et d’en admettre aussi le corollaire : on ne fera pas bon du premier coup. C’est un peu comme si on allait rater sa démo Scrum.

C’est tout l’objet du cycle Lean Startup : construire quelque chose pour le valider par le biais d’une mesure. Mais pas n’importe quelle mesure. Plutôt qu’une mesure quantitative (aka l’étude de marché, vous savez, celle avec laquelle le Paic Citron n’aurait jamais vu le jour…) on va chercher une mesure qualitative, donc en fait un (ou plusieurs, mais pas beaucoup) utilisateur avec un problème, et l’on va chercher à le rencontrer en personne !
Pour illustrer la démarche, Sébastien nous introduit la démarche Lean Startup sous forme de pseudo-code. Je ne saurais me livrer au même exercice que l’orateur (il est préférable d’aller voir sa présentation), mais cela donne des choses de ce genre :

IMG_0041

Ou pour résumer de manière plus sibylline:

  1. Revenir au problème (prendre de la distance avec la solution)
  2. Identifier les clients potentiels
  3. Identifier 3 clients potentiels. A priori les plus prometteurs, mais en définitive on fait un peu confiance à la chance…
  4. Pour chaque client, établir un Lean Canvas, celui décrit dans Running Lean (https://freethinker.addinq.uy/post/39835584866/note-de-lecture-running-lean-2nd-edition-par-ash)
  5. Trier les clients par :
  6. “pair level” c’est à dire votre alter égo, celui qui vous donnera donc le plus de feedback
  7. Facilité à atteindre. C’est à dire : puis-je facilement lui parler en direct
  8. Capacité à payer : Ou plus exactement : combien ce client est prêt à payer.
  9. Taille de marché. C’est en fait le dernier critère !

Lister les hypothèses. Attention il ne faudra tester qu’une hypothèse à la fois. En s’aidant, par exemple, du “validation board” (http://leanstartupmachine.com/validationboard/). Attention aux hypothèses ! Les clients potentiels ne paieront pas pour quelque chose qu’ils trouvent simplement “bien”, mais pour quelque chose dont ils ont vraiment besoin ! Sortir du bâtiment, pour aller faire des interviews. Le mieux est de pouvoir faire les interviews à deux, avec un observateur concentré sur la communication non-verbale. Travailler le MVP et le pricing Evaluer la solution proposée ; itérer si nécessaire Obtenir un signup et un paiement

Alors seulement, vous pouvez envisager de quitter votre travail. Mais pas avant : se sentir menacé alors que l’on a pas commencé le business est la meilleure façon de prendre de mauvaises décisions !

See you soon

Vous n’êtes probablement pas encore rassasié de ce Agile Tour Bruxelles ? Nous non plus. En fait, il est l’heure de se rendre au buffet de midi. Nous nous retrouverons très bientôt pour la suite de cette journée !

Note de lecture : Software Project Management, par Walker Royce

Note : 6 ; La gestion de projets selon Unified Process.

Un ouvrage un peu dense et un peu difficile à lire, mais dont le contenu est indéniable, notamment sur les métriques de suivi de projet. Walker Royce porte un fardeau assez difficile : son père, Winston, est en effet l’auteur d’un article décrivant le cycle en cascade qui est à l’origine du « cycle en V »… à son corps défendant !

Les 4 parties constituées de 17 chapitres de la partie principale du livre couvrent un peu plus de 250 pages. Il faut y ajouter les très conséquentes 5 annexes de la 5ème partie qui totalisent à elles seules 150 pages !

La première partie « software management renaissance » comprend 4 chapitres et un peu moins de 70 pages. Bien entendu, le premier chapitre traite du modèle en cascade présenté dans l’article de 1970 de papa Royce. Plutôt que de critiquer son géniteur, Walker fustige, à juste titre je dois dire la manière dont le modèle a été mal compris. Le second chapitre, s’il est court avec sa dizaine de page, n’est pas une ballade de santé. Il présente l’évolution de l’économie du logiciel en terme de ROI, coût par SLOC, etc. En comparaison le 3ème chapitre qui présente logiquement l’amélioration de cette économie est nettement plus accrocheur. L’auteur y évoque l’influence de différents paramètres tels que le langage de programmation, l’utilisation de la conception orientée objet ou la pratique du peer review. Cette première partie se conclut par la comparaison des « anciens principes » contre les nouveaux (ceux de l’auteur). J’ai trouvé l’énoncé des 30 principes de Davis bien plus intéressante (même si certains sont clairement erronés), en regard des 10 principes de Royce.

La seconde partie « a software management process framework » rentre dans le dur de UP. 65 pages sur 5 chapitres y sont consacrés. Le chapitre 5 se focalise sur le concept de phase (vous savez, celui que l’on a abandonné avec agile…). Bien entendu ce sont les 4 phases d’UP qui y sont évoquées. C’est sans surprise que l’on aborde le chapitre 6 qui s’avère consacré à la question des artéfacts projet, les 25 pages de se chapitres évoque l’existence de nombre d’entre eux en les ventilant sur 5 pratiques d’ingénierie. Un chapitre que j’ai du mal à trouver passionnant, bien qu’il soit central dans les méthodes prescriptives et finalement bien abordé ici, y compris la discussion sur l’usage et l’apport d’artefacts formels. Les deux chapitres suivants sont étrangement courts. D’abord le chapitre 7 sur les modèles n’évoque que l’existence de 5 modèles (qui rappellent les 4 + 1 vues de Philippe Kruchten), mais sans aller plus avant parce que hors du sujet de l’ouvrage probablement. Ensuite le 8 chapitre 8 nous parle du workflow de l’itération, décrivant celle-ci comme un mini waterfall. Beurk ! Le dernier chapitre de cette seconde partie est plus ésotérique en évoquant les jalons majeurs et mineurs.

La troisième partie « software management disciplines » couvre 85 pages sur 5 chapitres. Il commence avec le chapitre 10 qui aborde la planification itératif et son outil phare : le WBS (Work Breakdown Structure). Encore un truc que l’on ne fait plus en agile. Toutefois si vous voulez rentrer dans le sujet, vous avez là une référence de première main. Non seulement il donne une méthode de découpage, mais évoque les répartitions budgétaires relatives et leur évolution en fonction des phases du projet ! Le chapitre 11 lui traite de l’organisation de projet, au sens « administratif ». C’est donc à des organigrammes qu’il nous faut faire face, avec des listes de responsabilités et tout et tout… Le chapitre 12 focalise sur l’automatisation du processus et notamment du change control. Bref, pas mal d’outillage « projet ». Fort logiquement, au chapitre 13, ce sont les indicateurs de management qui sont à l’honneur et principalement le fameux Erned Value Tracking (EVT). Le chapitre 14 aborde la customisation du processus (car UP se customise). Walker Royce aborde cela en classant les types de projet en 2 dimensions : la complexité technique sur un axe et la complexité de management sur l’autre. Chaque axe nécessite une emphase particulière sur certaines disciplines et certains artefacts. Il n’y a plus qu’à combiner les deux, hein ?

La dernière partie du corps du livre « looking forward » ne compte que 3 chapitres et se contente donc d’une trentaine de pages. Elle débute par le chapitre 15 qui évoque les projets dits « modernes ». C’est finalement là que l’on retrouve des choses qui se rapprochent le plus des projets agiles : des exigences qui évoluent, de l’intégration continue, mais le tout encore et toujours dans les fourches caudines d’XP aux forceps. Au chapitre 16, on tente de tourner notre regard vers un nouveau modèle économique des projets. Il s’agit en partie d’une remise en cause partielle des postulats de Boehm dans le cadre des développements actuels. La partie textuelle de cet ouvrage se conclu par un chapitre 17 assez courts évoquant les problèmes de transition vers ces processus…

La 5ème partie du livre est consacrée aux annexes. Comme je l’ai dit, elle est franchement volumineuse. L’annexe A évoque l’état des pratiques en s’appuyant sur des rapports. Hélas tout ce ceci n’est plus d’actualité, mais cette partie est au moins courte ! L’annexe B rentre dans le modèle COCOMO 2 de Boehm, et on s’en tire pour une vingtaine de pages. Une dizaine de pages sont consacrées à des métriques de changement qui à mon avis ne servent à rien. L’annexe D est un cas d’étude et franchement il faut être motivé pour s’en taper les 60 pages. Enfin, même si l’annexe D compte 30 pages, il est plus facile de s’y intéresser : challenger UP face à CMM peut s’avérer instructif.

Le livre est dense, très dense. Il traite de processus semi-prescriptif est déballant beaucoup de matériel, beaucoup de concepts et un niveau de technicité, en processus, en métriques et un petit peu dans tout, il faut bien le dire, qui est très élevé. Le vrai risque est d’être un peu noyé à force d’en vouloir pour notre argent. L’erreur de l’auteur est d’essayer d’augmenter le niveau de technicité, de finesse dans la maitrise et la gestion de projet, là où la clé serait plutôt la simplification.

software-proj-mgt-unified-framework

Référence complète : Software Project Management: A Unified Framework – Walker Royce – Addison Wesley 1998 – ISBN: 0-201-30958-0

Software Project Management: A Unified Framework

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

Forum ouvert et agilité

Ce 22 Septembre (oui, un dimanche), Christine Koehler nous a proposé de nous rassembler afin de réfléchir ensemble aux convergences entre forum ouvert et agilité. C’était aussi une opportunité d’échanger avec des orateurs du Scrum Gathering que Christine avait contacté pour l’occasion: Dan Mezick, Suzanne Daigle et Jasmina Nikolic. Suzanne nous a d’ailleurs gratifié d’un post pour l’occasion.
Zenika hébergeait ce rassemblement, je ne saurais trop remercier Carl Azoury d’être venu spécialement nous ouvrir les locaux ! Par contre l’aménagement spécifique à cette réunion nous était dû à Christine et entre la tenture d’affichage électrostatique, les posters répartis dans notre zLocalhost et la signalétique des points de rendez-vous, c’était de la mise en musique élaborée.
Parmi les appointés, quelques habitués des rendez-vous agiles.

Forum ouvert et Agilité 2

Sur 22 inscrits, nous étions finalement 17, ce qui n’est finalement pas si mal. Le nombre ne fait pas la qualité de toute manière.

Forum ouvert et Agilité 3

Christine et Suzanne ont ouvert la séance en rappelant le fonctionnement du forum ouvert. Je ne le rappelle pas ici, on trouve pas mal d’information sur le Web à ce sujet.
La première étape, c’est de proposer les sujets, bien sûr. Il n’y a pas de limite. On l’écrit sur un grand format…

Forum ouvert et Agilité 11

… et on le présente devant tous.

Forum ouvert et Agilité 12

Impact hub ? Cela ne me parle pas trop. L’occasion pour moi d’en apprendre plus…

Forum ouvert et Agilité 20

Lorsque qu’on a fait le plein, on vient faire son marché.

Forum ouvert et Agilité 22

D’ailleurs le lieux s’appelle bien la “place du marché”.

Dan Mezik et Jasmina Nikolic semblent assez pensifs devant les sujets. Le temps donné au groupe s’il est alloué ne veut pas dire que l’on s’y limite: Comme le dit Suzanne, la passion et l’énergie n’arrivent pas sur la base de la contrainte du temps.

Forum ouvert et Agilité 24

J’en sais un peu plus maintenant sur l’impact hub ; le tout me laisse encore un peu dubitatif, bien que je sois à priori convaincu sur l’idée de croiser des champs d’activité différents pour faire germer des idées nouvelles. Mais pourquoi et comment ? L’idée fera peut-être son chemin avant de vraiment m’interpeler.

Forum ouvert et Agilité 25

D’autres sessions en cours. pas très facile pour moi de m’insérer en cours de route, je passe.

Forum ouvert et Agilité 26

Je passe aussi celle avec Dan Mezik !

Forum ouvert et Agilité 27

Finalement je reste un peu sur une session consacrée au respect des règles et à la cohésion d’équipe !

Forum ouvert et Agilité 28

Je ne suis pas sûr d’accrocher à la direction que prends la discussion. Assimiler les “valeurs agiles” à une spiritualité, c’est peut-être trop fort pour moi. Et oui, en bas de la feuille, c’est bien marqué “sexualité”.

Forum ouvert et Agilité 29

Pour le coup, j’ai aussi manqué la discrète discussion menée par Jasmina autour du “oscrumban” ! Donc, je ne sais toujours pas ce que c’est !

Forum ouvert et Agilité 31

Au risque de vous frustrer, je ne vais pas retranscrire les discussions. Un forum ouvert, ça se vit plus que ça ne se restitue. Même si le “grand journal” essaie de se faire l’écho de notre après-midi !

Forum ouvert et Agilité 32