Mois : juillet 2013

What’s new in Scala 2.10 ? avec Martin Odersky

Le par addinquydans Compte-renduLaisser un commentaire

Comme l’année dernière, Devoxx proposait cette année des “BOF” dont l’accès était libre moyennant une inscription préalable. J’ai vite arrêté mon choix sur celle de Martin Odersky. Scala est un sujet d’actualité pour moi, je suis au milieu du cours Functionnal Programming in Scala sur Coursera par le créateur du language !

Autant l’avouer tout de suite, ce n’est donc pas spécifiquement les nouveautés 2.10 qui m’intéressaient ici. J’espérais aussi grapiller un peu des “pourquoi” qui ont présidé aux options du language.

MartinOdersky01

Ca commence plutôt bien en ce sens.

La suite …

What’s new in Scala 2.10 ? avec Martin Odersky

Publicité

Note de lecture : Analyse et conception orientées objet 2ème édition, par Grady Booch

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Un grand classique, bien écrit, mais qui souffre de son âge.

Comme son édition précédente, ce livre souffre de l’arrivée de la trilogie UML C’est néanmoins un véritable livre méthodologique qui couvre les mêmes aspects que l’ouvrage de Rumbaugh. Son contenu informatif est plus faible et la notation plus éloignée d’UML que ne l’est OMT, mais le style de l’auteur est beaucoup plus agréable et vivant, ce qui en fait un ouvrage plus abordable pour les personnes encore peu familières avec les méthodes. La traduction Française qui figure dans ma bibliothèque compte 500 pages de texte principal, soit 12 chapitres (regroupés en 3 parties) auxquelles il faut ajouter 100 pages d’annexes. Il fut une époque où les traductions Françaises étaient particulièrement pitoyables, nous sortons juste de cette époque, mais cette traduction reste largement perfectible. Une troisième édition de cet ouvrage est sortie depuis, où vous ne trouverez hélas pas le plaisir des petits nuages de notation Booch (ce sera de l’UML) je vous la recommande cependant en lieu et place.

Mais voyons un peu ce que la bête a dans le ventre.

La première partie s’intitule « concepts », et ses 180 pages comprennent 4 chapitres. Le premier chapitre traite de la complexité, quelle est sa nature et comment se manifeste-t-elle dans un système logiciel, pour nous donner ensuite les clés de sa gestion : l’abstraction et les hiérarchies. C’est en quelque sorte une introduction aux chapitres suivants mais aussi une réflexion profonde particulièrement bien menée.

De l’abstraction au modèle objet, il n’y a qu’un pas. Et c’est de cela que traite le chapitre 2, en abordant la chose par l’histoire des langages, comment ils nous ont mené progressivement à ce concept. Le concept d’objet et de niveau d’abstraction (avec un curieux mélange entre abstraction et hiérarchies) est ensuite exploré et illustré.

Le chapitre 3 qui traite des objets et des classes est particulièrement important, en contenu comme en taille (65 pages). On y explores les différents aspects d’une classe : attributs, relations, états et interactions. Le tout abondement illustrés de diagramme Booch, mais aussi de fragment de code C++. Le parti pris de l’auteur se focalise en effet plus sur la conception que sur l’analyse.

La partie analyse, justement est abordée au chapitre 4, par les biais des classifications. Le traitement en est plus léger puisqu’il ne couvre que 25 pages !

La seconde partie du livre est consacrée à la méthode. On en prend pour 125 pages et 3 chapitres. Le premier d’entre eux (le chapitre 5, donc) est consacré à la notation. On y voit en détail les diagrammes de classes et leurs subtilités, les diagrammes d’état et les diagrammes d’interaction (ce sont ceux d’UML). Le chapitre se termine sur les « concepts avancés » : diagrammes de modules et sa variante en sous-systèmes et diagrammes de déploiement. Ils sont assez frustres et n’ont guère évolué après avoir été réutilisés tel quel dans UML.

Le chapitre 6 aborde la partie « processus » de la méthode. Grady Booch ne nous embête pas beaucoup avec cela car il évacue la chose en 37 pages ! L’approche de l’auteur est plus proche de celle d’UP que d’OMT en cela qu’elle identifie d’une part les principes généraux (approche itérative, vision architecturale) et un micro-processus lié à l’identification des objets, essentiellement à l’aide de cartes CRC. Vient ensuite l’identification des relations et de la dynamique. Le macro-processus reprends lui les grandes phases qui sont assez proches des phases d’UP mais pas complètement.

Les 25 pages du chapitre 7 « soyons pragmatiques » sont consacrées en fait à la gestion de projet : comment gérer les risques, quels sont les rôles, la gestion des versions, etc.. Sans être grandiose, ce chapitre contient quelques éléments intéressants, par exemple sur les métriques.

La 3ème partie, « applications » est longue de 90 pages et contient 5 chapitres. Au menu du premier d’entre-eux, donc au chapitre 8, un système de surveillance météorologique, qui va nous tenir éveillés 35 pages. L’exemple est un peu idéalisé. On le suit depuis la définition du contexte (et du contour du problème) jusqu’à l’implémentation. Disons que c’est une petite ballade sympathique.

L’exemple du chapitre 9 est très différent, on y suit sur 55 pages la construction d’une bibliothèque de classes, en l’occurrence une librairie de conteneurs. Si en suivre la conception progressive est en soi intéressant, l’apport de la démarche est ici au mieux en filigranes. Et en fait, même les diagrammes ne servent pas à grand chose.

Retour à un système plus classique au chapitre 10 : une gestion de stock en client-serveur. Si le diagramme de déploiement est bien utilisé au début, c’est surtout l’emploi des diagrammes d’interaction et le mapping objet-relationnel qui nous intéressent plus ici.

L’exemple du chapitre 11 est très loin d’être convainquant, car il a trait à l’intelligence artificielle (très en vogue à cette époque). Justement l’emploi d’une méthode paraît tout à fait artificielle ici, et cela ressemble plutôt à de la justification à postériori qu’une aide réellement délivrée par une approche structurée. Passons !

Le système de gestion de trafic du chapitre 12 ne semble pas apporter grand chose par rapport aux autres exemples. Ce qui est abordé ici ressemble beaucoup au chapitre 10. Passons également.

Grady Booch sait écrire et cela, lié aux réflexions qu’il soulève rend le livre intéressant. De mon point de vue, environ 70% du livre est aujourd’hui obsolète, de par UML d’une part et du fait de la montée des approches agiles d’autre part. Le texte consacre une majeure partie de la démarche à la conception, ce qui le place naturellement en complément (du moins en grande partie) d’OMT et rends une partie du propos toujours d’actualité et peut-être même à rapprocher de certains textes de Robert Martin. La traduction Française a grandement progressé sur cette édition mais reste largement perfectible, tandis que le texte de la première édition était lui parfaitement illisible ! Il existe une 3ème édition assez récente. Je serais assez curieux de voir comment le propos a évolué…

Analyse & Conception Orientées Objects

Référence complète : Analyse et conception orientées objet, 2ème édition – Grady Booch – Addison Wesley 1994 (V.O. : Object-Oriented Analysis & Design ; Benjamin-Cummings 1994 ; ISBN : 35340-2) – ISBN : 2-87908-069-X

Analyse et conception orientées objet


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

Le par addinquydans CitationsLaisser un commentaire

The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field, for folks like us who write books, it is positively tragic.

Tom DeMarco

En finir avec le Scrum Master ?

Le par addinquydans ArticlesLaisser un commentaire

Le quatrième volet de notre série va nous conduire du côté du Scrum Master. Dans l’épisode précédent (l’été dernier, donc) nous avons remis en cause le Product Owner, il semble justice d’en faire de même avec le Scrum Master, n’est-ce pas ?

Avant d’aller plus loin, rappelons l’avertissement désormais habituel : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

Scrum Master, ta mission si tu l’acceptes …

Mission impossible

Comme nous l’avons fait avec le Product Owner, il est bon de camper le paysage en synthétisant les missions du S.M. ; Nous avons de la chance, le terrain est mieux balisé aujourd’hui.

Le Scrum Master est souvent décrit comme le “chien de berger”, qui doit :

  • Veiller au bon suivi des cérémonies Scrum et âtre un agent du changement(1) (3)
  • Encourager l’équipe, l’aider à progresser et devenir autonome (1) , un rôle qui se prolonge envers les autres parties prenantes du projet (2)
  • Eliminer les obstacles (4)

Je note aussi que les écrits initiaux de Scrum donne un trait nettement plus fort au Scrum Master, le décrivant notamment comme un rôle de management, que ne le font les textes plus récents où il est plutôt décrit comme un facilitateur et un “servant leader”.

Pourquoi en faut-il un ?

image

Scrum édicte en règle la présence du Scrum Master : l’équipe doit pouvoir se concentrer à 100% sur le projet sans perdre de temps sur des considérations annexes, car le SM y veille. A la base, cette présence du Scrum Master repose donc sur  deux postulats:

  • L’équipe n’a pas la maturité pour prendre en charge sa discipline agile sans qu’un garant soit là pour y veiller.
  • L’environnement nécessite que quelqu’un joue le rôle de pare-feu, car les parties prenantes en contact avec celle-ci créent trop de perturbations.

Maintenant, imaginons un environnement favorable (donc ne nécessitant pas de “firewalling”) et une maturité affirmée de l’équipe, que reste-t-il de cette nécessité ?

C’est probablement le point qui a motivé la question posée en ce sens cet été sur Quora.

La question sur Quora

Is it possible to run Scrum without Scrum Master ?  

Les réponses que j’appelerais “bibliques” sont quand même majoritaires. Toutefois je constate qu’elles reposent sur deux fondements :

  • Le fait que les conditions d’un projets entrainent nécessairement la présence des deux postulats que j’ai cité plus haut.
  • Une croyance forte dans le bienfait de la présence des rôles.

Une autre partie des réponses affirme que cela est possible, généralement sur la base du niveau de maturité de l’équipe. Ma réponse préférée est celle de Xu Yi : “when you need to ask the question, no, you can’t. when you don’t need to ask the question, yes, you can.”.

Retour à la case départ : il est nécessaire du fait du manque de maturité de l’équipe et pour protéger des perturbations. Non seulement la réponse n’est pas satisfaisante, mais il y a plus : le SM peut s’avérer dommageable à l’équipe !

Protection ou isolation ?

Dans un excellent post qui a d’ailleurs devancé ma chronique, Tobias Meyer parle d’éliminer le Scrum Master ! Il avance plusieurs arguments à cela :

  • Le rôle tel qu’il est décrit ne peut être décemment endossé par quelqu’un se dénommant “master”.
  • L’idée même qu’une personne dédiée à être guide de l’équipe, à résoudre les problème pour elle est un non-sens, lorsque l’on considère le niveau de qualification des membres de cette équipe.
  • “protéger” l’équipe va à l’encontre de l’idée de responsabiliser celle-ci.
Bad Scrum Master

Ce troisième point plus particulièrement m’interpèle : l’un des principes de base de Scrum est de permettre à l’équipe de se concentrer à 100% sur son travail. Les rôles de PO et de SM sont là pour aider à atteindre cet objectif. Mais “protéger” peut rapidement devenir “isoler”. Le Scrum Master devient ainsi l’interlocuteur privilégié et parfois unique avec l’équipe. Certains développeurs y trouvent leur compte, qui préfèrent dialoguer avec leur machine qu’avec des utilisateurs. Au-delà de cette formulation ironique, n’oublions pas que nous avons tous tendance à nous replier sur notre zone de confort : programmer c’est être en terrain connu, donc dans la zone de confort, parler avec l’utilisateur à propos de son métier, c’est être dans l’inconnu, hors de la zone de confort.

Les valeurs agiles nous parlent de communication. L’équipe doit aller hors de sa zone de confort, elle doit aller au front pour comprendre et s’approprier la matière sur laquelle elle travaille. Scrum ne dit pas le contraire, mais la notion de “rôle” et de “protection” est tellement facilement assimilable au chef de projet à l’ancienne …

Une question de maturité d’équipe

Livrons-nous à un petit “remember the futur”. Tous les membres de l’équipe ont un niveau de maturité élevé en agilité, l’organisation a bien compris la nécessité de n’être pas intrusive. A quoi ressemble le fonctionnement de cette équipe ?

  • Le product owner vient aux stand-up. Il sait qui travaille sur quelle store. Il échange directement avec le développeur ou même le plus souvent, il lui envoie l’utilisateur le plus directement concerné.
  • Les améliorations du processus viennent de n’importe quel membre de l’équipe. Chacun évoque son idée au moment opportun (durant l’itération) et on n’attends pas l’itération suivante pour la mettre en oeuvre.
  • L’organisation n’interfère pas avec l’équille pour des questions politiques. Elle sait que la manière la plus productive d’obtenir un résultat est de laisser les personnes faire leur travail. Le comité de direction donne cependant du feedback lors des démos afin de réorienter le projet si nécessaire.

Dit comme ça, ça fait un peu bizounours. En fait, ça l’est bien un peu, hélas ! Nous n’avons pas terminé notre exercice, toutefois. Voyons comment on pourrait arriver ici en venant d’une situation standard.

Des rôles qui peuvent se répartir

Un coach m’a un jour affirmé qu’il voyait l’inutilité de sa présence comme l’accomplissement réussi de sa mission. C’est fort bien dit et aussi très juste.

La hiérarchie interfère avec l’équipe ? Certes, on peut faire rempart. Mais n’est-ce pas mieux de travailler avec la hiérarchie pour trouver un mode de fonctionnement équilibré et non intrusif ? Si le management intervient, c’est souvent qu’il a des craintes ou des insatisfactions.

Le mode de fonctionnement de l’équipe peut être amélioré, la productivité augmentée ? Oui bien sûr on peut montrer du doigt les voies d’amélioration … mais n’est-ce pas plus efficace d’enseigner à l’équipe à voir son propre gâchis, comme on dit en Lean ? Si un homme a faim, apprends lui à pêcher plutôt que de lui donner un poisson…

D’ailleurs, l’équipe étant auto-organisée, ne peut-elle dédier une personne sur chacun de ces fronts ? Pourquoi nécessairement tout ramener à une seule personne ? Que se passe-t-il quand elle n’est pas là ? Il est temps d’évoquer la sociocratie.

L’approche sociocratique

N’étant pas spécialiste du sujet, je ne vais pas m’y étendre. Ce mode de gouvernance est régit par 4 principes (5) :

  • Prise de décision par consentement: Les actions sont entérinées à moins d’objections.
  • Le cercle : c’est une entité autonome dans son travail et les décisions qui régissent son exécution.
  • Le double lien : en plus du lien hiérarchique traditionnel, chaque cercle choisit son représentant au niveau supérieur. Il participera aux décisions par consentement de ce niveau.
  • L’élection sans candidat: personne ne se porte volontaire pour un poste, les électeurs proposent des candidats qui sont libres d’accepter ou non le résultat du scrutin.

Pour une équipe ayant acquis une certaine maturité et une certaine conscience agile, l’évolution vers ce type de gouvernance semble une suite logique. Elle permet aussi au final de faire tourner le rôle de Scrum Master ou même s’y mettre fin.

Effets collatéraux

J’ai évoqué la “non nécessité du Scrum Master”. Mais allons plus loin : sa présence peut elle être nuisible, même si ce dernier est bien intentionné ?

Hélas la réponse est : oui ! Et sa présence paut avoir des effets de bord néfastes, jugez-en !

Effet colatéral

Enfin non, ce n’est quand même pas à ce point. Dans une équipe auto-organisée, l’agilité doit être l’affaire de tous. C’est déjà un peu antinomique de décider qu’une personne donnée sera porteuse de cette mission ! Passons.

Mais que peut-il se passer si une personne est en charge de la mise en oeuvre de Scrum ?

  • D’abord, les autres membres de l’équipe ne s’en préoccupent plus, jugeant que c’est l’affaire de “l’autre”.
  • Puis on arrive dans une situation de passivité où les choses ne se passent que si le SM s’en charge. Par exemple : avez-vous vu des équipes qui ne font pas le daily meeting un jour, car le Scrum Master est absent ? Oui, ça arrive !

Bien sûr, ce n’est pas toujours comme ça. Heureusement. Mais ça peut aussi être pire, si le Scrum Master n’est pas bien disposé.

Le chef de projet est de retour

Au secours ! Car oui, si Scrum décrit explicitement le rôle du SM comme n’étant pas un rôle de management, il n’est pas trop difficile de s’assoir dessus, surtout si tout le monde est bien disposé en ce sens. Retour au bon vieux commande-controle !

Chaplin, le dictateur

Alors quelle est la recette du désastre ? Elle n’est pas compliquée.

Prenez une bonne vieille équipe fonctionnant à l’ancienne. Ca ronronne bien. Les membres de l’équipe sont tranquillement en mode “ouvrier spécialisé”. Le chef de projet stresse un peu plus car tout repose sur ses épaules. Il distribue les tâches, car au moins c’est un mode de fonctionnement qu’il comprend.

Prenez une équipe managériale que l’on a fait mijoter dans un saladier-séminaire d’agilité. On l’a saupoudré d’épices exotiques lui faisant miroiter monts et merveilles : ils pourront changer d’avis tous les jours, la productivité sera multipliée par 100000 (je dois oublier un ou deux zéros), les utilisateurs auront des trucs mieux que ce qu’ils espèrent grâce à l’usage avisé de le télépathie. Les trucs standard, quoi.

Extrayez de l’équipe le chef de projet et faites-le revenir dans une poelle-formation Scrum Master. Les autres membres de l’équipes restent à la boite à bosser, car faut quand même pas exagérer.

Mixez l’ensemble, servez et voyez ce qui se passe.

Les membres de l’équipe ne comprennent pas trop ce qu’on attends d’eux et sont un poil déstabilisés (on vient de leur dire qu’ils sont enfin libre, mais bon ça reste un peu abstrait). Par défaut on va attendre les ordres, là on ne risque pas grand chose. Le chef de projet enthousiaste attends le démarrage de l’auto-responsabilité, l’allumette à la main. Pas grand chose n’arrive. Histoire d’amorcer la pompe, le chef de projet va distribuer les tâches (ou les user stories, ou ce que vous voulez) aux développeurs. Retour à la case départ. Enfin pas tout à fait, on a changé le vocabulaire.

Et si on ne trouve pas, on ne va pas ?

Le tableau que je dresse parait noir. Hélas il arrive. Et généralement on essaie alors de se voiler la face en se disant que non ce n’est pas comme avant. Pas tout à fait.

Mais que fait-on si on n’a pas de Scrum Master sous la main ? Ou que personne ne souhaites l’être.

  • On prends une victime au hasard ?
  • On roule sans ?

Clairement, sélectionner une victime n’est jamais la bonne approche. Surtout dans un rôle où la confiance est primordiale. Si l’équipe n’est pas non plus aguerrie à la pratique de l’agilité en générale ou de Scrum en particulier, il est aussi illusoire de penser que les choses se mettront en place tout seul. Il est préférable alors d’aller chercher un Scrum Master expérimenté en prestation. Mais oui.

Encore faut-il que ce Scrum Master ait bien compris son rôle et guide l’équipe dans le bon sens afin de ne pas faire tourner Scrum à la grosse farce !

Bon, alors le Scrum Master, c’est mal ?

“Scrum Masters, soyez les coaches de vos équipes agiles”. J’évite généralement dans cette colonne de faire la promotion de qui que ce soit. Mais ce slogan nous est asséné par Véronique Messager depuis maintenant un certain nombre d’années (6). Et elle a raison, c’est bien de cela dont on doit parler. Scrum n’évoque pas la chose, mais la véritable voie du Scrum Master est celle du coaching : être celui qui rends possible non pas Scrum, mais que l’équipe s’approprie Scrum !

Bref, le Scrum Master doit être un catalyseur, et pas le gars sur lequel on se décharge de l’agilité. Et dans ce cadre, son apport peut s’avérer décisif !

Références

(1) Scrum 2nd edition ;  Claude Aubry ; Dunod 2011 ; p. 44

(2) Scrum field guide : Mitch Lacey ; Addison Wesley 2012 ; p. 104

(3) Agile Software Development with Scrum ; Ken Schwaber & Mike Beedle ; Prentice Hall 2002 ; p. 31

(4) Essential Scrum ; Kenneth S. Rubin ; Addison Wesley 2012 ; p. 185

(5) Sociocratie : http://fr.wikipedia.org/wiki/Sociocratie ;

(6) Coacher une équipe agile ; Véroniue Messager ; Eyrolles 2012

Note de lecture : La qualité en C++, par Philippe Prados

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un excellent ouvrage regroupant règles, conseils et nombre d’idiomes.

On n’a pas l’habitude de chercher des livres allant au-delà du niveau initiatique chez les auteurs français. A juste titre, malheureusement. Celui-ci fait exception. Cet ouvrage à taille humaine (environ 300 pages), regroupe un ensemble de conseils et de règles en C++, intégrant des idiomes parfois créés par l’auteur. La bête se présente sous forme de 9 chapitres, donc en moyenne un peu plus conséquents que ce que j’escompte. J’oublie les 10 pages d’annexes.

Le premier chapitre parle de rappels. On y trouve pèle mêle des questions sur le partage d’objets pointés, d’ownership, de questions afférents à la destruction, à la notation ou au constructeur de conversion. Ca manque un peu de logique. On ne peut qu’espérer que le meilleur soit à venir.

Au chapitre 2, on trouve des conseils assez sibyllins sur la conception d’une classe. L’auteur ne développe pas les points, mais beaucoup sont pertinents au-delà du bon « bon sens intuitif » : pas d’attributs de type référence ou mettre à disposition la copie d’objet si aucun attribut ne stigmatise son identité (tout le monde ne sera pas d’accord là-dessus, mais je le suis).

Le chapitre 3 est nettement plus important : il adresse les « patterns de programmation », donc en fait les idiomes et taille 70 pages ! Ce chapitre, c’est un peu la trousse à outil de l’auteur avec son savoir-faire. Et ce savoir-faire est de bon niveau ! Il faudra ne pas être totalement néophyte toutefois pour en faire usage. D’abord parce que les explications, si elles tentent d’être didactiques sont plus empreintes du style IBM que du style Scott Meyers, disons… Ensuite, il faut garder un regard critique. Par exemple l’idiome sur le constructeur copie est erroné…

Au chapitre 4, on trouve quelques principes de codage orientés compilation qui ne sont pas sans rappeler le « large scale C++ design » de Lakos. J’aime bien le tableau sur l’usage des références, entre autre chose.

Le chapitre 5 nous parle de debug. On commence par les traces et l’auteur nous donne quelques conseils sur la surcharge de l’opérateur « >> ». Puis on aborde les choses sérieuses avec la surcharge de new pour traquer la mémoire. Là aussi la prudence s’impose car le programme peut ne plus se comporter à l’identique avec et sans debug (vous me direz que c’est déjà le cas…).

Les chapitre 6 et 7, c’est un peu le col du Galibier de ce livre. Du moins, le 7 est la première côte de l’ascension. L’auteur y énumère des règles de code « prêt à l’emploi » qui sont détaillées au chapitre au chapitre 8. Ce sont dans les 80 pages de ce chapitre que Philippe Prados déploie son expertise, et c’est ce chapitre qui justifie l’achat du livre. Si vous ne devez lire qu’un chapitre c’est celui-ci. J’approuve la plupart des règles, j’ai même parfois appris quelque chose (eh oui !) et les explications sont claires pour peu que vous ne soyez pas grand débutant.

Le chapitre 8 consacré aux tests accuse son âge. Il se focalise d’abord sur les notions de préconditions / postconditions et invariants tels qu’on les trouvent dans Eiffel. Puis l’auteur nous propose une implémentation de tests unitaires, qui n’a plus guère d’intérêt aujourd’hui avec des libraires telles que CppUnit.

Au chapitre 9, on démystifie certains mécanismes du C++. Bonne idée ! Au programme : les héritages simples, multiples et virtuels. Tout naturellement on voit dans la foulée le mécanisme des table vptr des méthodes virtuelles. La gestion des exceptions et des inlines complètent le tableau.

Les explications sont assez claires et l’auteur parvient tout à fait à faire passer son expertise (de niveau élevée) du langage. Les recommandations énoncées ont souvent un caractère subjectif, on y adhèrera ou pas mais même dans ce dernier cas on profite des raisonnements et de l’expertise de l’auteur. Disons le tout net, c’est le seul ouvrage d’un auteur Français sur le C++ qui soit d’un niveau honorable ! Un excellent livre, à classer dans la catégorie “manuels de référence”.

La Qualité en C++, par Philippe Prados

Référence complète : La qualité en C++ – Philippe Prados – Eyrolles 1996 – ISBN : 2-212-08917-1

La qualité en C++


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

AgileTour Brussels 2013

Le par addinquydans Compte-renduLaisser un commentaire

Comme l’an dernier, je me rendrais à l’Agile Tour Bruxelles ! Pas tout à fait comme l’an dernier, toutefois, car je m’y rends cette année sous les couleurs de Zenika !

Je vais me livrer à ce que j’appelle une “session participative”, une présentation entrecoupée de participations de l’assistance. Le titre en est inspiré d’un principe promu par Scott Meyers : Easy to use correctly and hard to use incorrectly.

En voici le teaser :

We are all seeking for good advices, recipes and rules of thumbs to make our designs better, our requirements strong and accurates, our user interfaces outstanding and more and more…

But there are as many set of rules our advices as there are gurus. And as smart as they are, their rules are only good advices, not final weapons usable in each and every situation. It’s because there is no final weapon. Human mind can’t be replaced and will not be.

Then I crossed Scott Meyer advice. Amazingly it help me to challenge my ideas in programming, design, user interfaces, even in the way I can mitigate user stories or make iteration priorities !

Agile teams are targeting excellence. Code, design and functionalities are not here forever : they are reused, refactored, improved or changed. We want functionalities deighting our customers and be handled without questions. This sessions will help you make a step in this direction by illustrating what it means to build things easy to use correctly and hard to use incorrectly. We will see that successively with code, design structures, requirements, user interfaces and even agile practices !

You will be invited to juge the examples against Scott Meyer’s principle and sometime to improve them and make them better.

Mais je n’ai toujours pas répondu à la question que vous vous posez : Pourquoi Bruxelles ?

  1. Tout d’abord: la communauté Belge ! Elle n’est pas seulement très aguerri en matière d’agilité (ils ont été les pionniers d’XP en Europe), elle est aussi et surtout éminemment sympathique et accueillante !
  2. Une occasion d’entrainer mon Anglais ! Eh oui, nous sommes au pays du bi-culturalisme. Donc, la conférence se fait en langue neutre : l’Anglais !
  3. Enfin, quoi ! Nous sommes en Belgique ! Donc, il y a de la bière …

Me voici donc avec quelques travaux de vacances pour préparer cette session qui sera entièrement nouvelle !

Rendez-vous sur le site d’Agile Tour Bruxelles

Venez nombreux !

AgileTour Brussels 2013

Note de lecture : OMT, Modélisation et conception orienté objet, par James Rumbaugh & al.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un livre dense, presque indigeste (tout comme le style), mais bourré d’information. Book of the year 1996 !

OMT est LA méthode sur laquelle a été construit UML, et doit constituer environ 70% de cette notation. Ce livre est évidemment la référence sur le sujet. Les 500 pages qui le constitue sont très dense (aussi bien du point de vue informatif que du point de vue typographique) et traite les aspects méthodologiques sur un spectre très large : notation, analyse des besoins, conception, développement, mapping vers les bases de données, etc… Cette masse d’information est structurée en 20 chapitres regroupés en 4 parties. 50 pages sont consacrées aux annexes.

Une courte introduction nous remet dans le contexte de l’appréhension de l’objet en ce début de décennie 90 : elle accorde moins de place à l’analyse fonctionnelle et dissocie fortement modèle d’analyse et modèle de conception (l’implémentation, c’est encore autre chose) avec une prédominance pour le modèle d’analyse ! Bien entendu, sur les modèles objets, une importance ridicule était aussi portée aux arbres d’héritages : plus ils sont profonds, plus ça fait virile !

La première partie aborde les concepts de modélisation. Le tarif est de 5 chapitres et 130 pages. On commence par un chapitre 2 ultra court qui nous donne les définitions des différents modèles. Ce qui doit être dedans et ce qui ne doit pas l’être est très clair. Ca rigole pas. Au chapitre 3, on passe en revue la notation des diagrammes de classes, mais surtout toutes les subtilités concernant les associations (multiplicités, noms d’association et de rôles, agrégations, généralisations, qualifiers, attributs et associations n-aires). S’il est complet, le texte reste très touffu et pas réellement prévu pour être pédagogique. Mais comme c’est ainsi tout au long du livre, je vais arrêter de le dire. Le chapitre 4 prolonge le 3 avec des concepts avancés que l’on retrouvera plus tard dans UML : notions d’héritage disjoint, de contraintes, etc… On aborde enfin le modèle dynamique au chapitre 5. On s’y focalise sur les diagrammes d’état et on n’y va pas avec le dos de la cuillère ! On y trouve tous les trucs tordus qui ne servent qu’à quelques zombies du temps réel (et qui a fait les beaux jours de certains cours Valtech). Enfin le chapitre 6 vaut le détour car on n’y parle du modèle fonctionnel (modèle de traitements, mais surtout flots de données) qui n’ont pas été du tout (heureusement) retenus dans UML. A mon humble avis, c’est inexploitable.

La seconde partie va nous occuper sur 6 chapitre et couvre aussi 130 pages. Elle va traiter de méthode de conception. Comme pour la partie précédente, on commence par un chapitre 7 qui présente la méthode OMT dans ses grandes lignes. Car à cette époque, méthode et notation étaient deux concepts liés, tout le temps ! Le chapitre 8 aborde l’analyse, l’aspect le plus important d’OMT. Le recueil des besoins est balayé en 2 pages, pourtant on y trouve de petites remarques pleines de finesses mais qui ont disparu lors des mises en œuvre. La démarche est guidée et illustrée par une étude de cas : le guichet automatique de banque : on passe des classes candidates au modèle objet, que l’on raffine. Puis un modèle dynamique (un diagramme d’état) met en musique les scénarios évoqués. Et hop ! grâce à ça, on obtient les opérations que l’on n’a plus qu’à ventiler sur les classes ! Elle est pas belle la vie ? Le chapitre 9 parle de conception. En principe. On voit bien que ce n’est pas le trip des auteurs car ça part un peu dans tous les sens : sous-systèmes, partitionnement, couches, infrastructure matérielle ( ??). Bref, on s’est senti obligé d’y mettre quelque chose, sinon c’est pas crédible. Le chapitre 10 est un guide de conception des classes, pour les auteurs, c’est un retour en terrain connu, mais pour le lecteur c’est assez difficile d’emboiter cela avec le chapitre 8…  Le chapitre 11 résume les étapes de la méthode vu précédemment. C’est très clair et franchement une bonne idée. On conclu cette partie par une comparaison des méthodes. Je pensais voir un chapitre tarte à la crème, j’ai été (agréablement) surpris : les auteurs font un travail méticuleux de comparaison avec les approches structurées (SA/SD, Jackson), orientées entités (ER de Chen) et orientées objet (Booch, Yourdon, schlaer et Mellor). Ils mettent en avant chaque fois les atouts et les faiblesses, voir les complémentarité par rapport à OMT. J’ai rarement vu un travail de cette qualité.

La troisième partie nous parle d’implémentation, et sur 5 chapitres et 120 pages. Comme à l’accoutumée, le chapitre 13 sert d’introduction. On parlera d’implémentation par des langages de programmation, sur des bases de données et même au-delà des ordinateurs ! Le chapitre 14 va parler de style de programmation et je m’attends au pire. Et c’est le choc, car on n’y trouve rien de moins que ce que l’on trouvera bien des années plus tard sous la plume de Robert C. Martin ! Bravo ! Le chapitre 15 évoque la transformation de modèles vers des langages objet tels que C++, Eiffel et Smalltalk. Tout ce ci ne m’apprends rien, mais les auteurs ne prennent pas les chemins de traverse et font remarquablement bien le boulot ! C’est au tour des langages non objet au chapitre 16, en l’occurrence C, Ada et Fortran. Là aussi, un grands coup de chapeau pour la qualité du travail, qui est ici plus difficile. On se tourne vers les bases de données au chapitre 17. J’ai moins été impressionné ici, mais le boulot est fait.

La quatrième partie est plus courte, elle ne compte que 3 chapitres sur moins de 50 pages. Le chapitre 18 traite d’une application développée chez GE (où travaillait alors James Rumbaugh) : un compilateur de diagramme. J’avoue ne pas avoir été convaincu. Au chapitre 19 on voit rapidement un système de conception d’animation, l’occasion pour les auteurs de parler rapidement de la mise en œuvre de la méthode sur la partie analyse. Enfin, au chapitre 20, c’est une petite étude de cas sur la distribution d’électricité. Cette dernière partie ne m’aurait pas manquée si elle n’avait pas été là.

De nombreux aspects de ce livre sont d’un autre temps, comme le couplage indissociable entre méthode et notation, ou l’emphase exagérée sur le modèle d’analyse, un traitement grotesque du recueil des exigences et un quasi mépris pour la conception. Tout ceci ne me manquera pas, je n’ai jamais été en phase avec cette façon de voir. Pourtant le livre mérite l’intérêt à plusieurs égard. D’abord parce qu’il est simplement le meilleurs représentant de cette époque. Ensuite car de nombreux sujets sont traités avec finesse, rigueur et profondeur. Les auteurs ne mégottent pas sur la qualité de l’information. Enfin, OMT constitue la majeure partie de la notation UML. Et si des livres (de nombreux livres) couvrent la notation, cette seconde vie a en quelque sorte prolongé la pertinence de celui-ci. Toutefois, c’est surtout l’aspect historique qui nous retiendra aujourd’hui.

OMT, par James Rumbaugh

Référence complète : OMT, Modélisation et conception orienté objet – James Rumbaugh, Michael Blaha, Frederick Eddy, William Premerlani & William Lorensen – Masson 1995 (V.O. Prentice Hall 1991) – ISBN : 2-225-84684-7

Omt, Tome 1: Modélisation Et Conception Orientées Objet

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

Le par addinquydans publicationLaisser un commentaire

DSDM Adapté à Scrum

DSDM continue d’intéresser son microcosme, mais celle que je considère comme la moins agile des méthodes agiles a échoué à mon avis à se répandre de manière majeure, contrairement à Scrum. “si tu ne peux vaincre ton ennemi, embrasses-le !”. C’est ce que fait Andrew Craddock, chairman de DSDM en proposant ce framework DSDM adapté à Scrum !

Un article complémente le propos de l’orateur, que je vous propose ici.

Retrouvez cet article et d’autre sur le site du DSDM.

(Source: https://www.youtube.com/)