Note de lecture : Managing Software Requirements, par Dean Leffingwell & Don Widrig

Note : 7 ; Les exigences selon RUP, avec beaucoup d’éléments sur les pratiques, mais aussi un manque de matière sur la mise en œuvre.

Ce livre traite de la gestion des exigences vue par Rational Unified Process. Les auteurs ont d’ailleurs travaillé sur l’outil Requisit Pro. La lecture en est plaisante, le découpage en nombreux chapitres assez découplés bien que complémentaires y aide beaucoup. Comptez 385 pages pour ce volume qui comprend en sus près de 90 pages d’annexes ! Les 35 chapitres que les auteurs ont concoctés sont divisés, non en parties mais en 8 « skills », une petite subtilité, mais assez intelligente !

En une trentaine de pages comptant quand même 3 chapitres, la première partie fort opportunément appelée « introduction » est vite passée ! Si on s’intéresse aux grands classiques du « pourquoi » des exigences, c’est à dire le coût des exigences erronées, on arrive vite à la définition de ce qu’est une exigence au chapitre 2. C’est ici aussi que l’on introduit la pyramide problème / besoin / solution que j’aime tant ! L’auteur n’oublie pas que le développement logiciel, même dans l’ingénierie des exigences, est une affaire d’hommes et de femmes, il consacre le chapitre 3 à l’équipe et aux compétences. Bref, une première partie tout à fait sympathique.

Ce sont 3 chapitres (sur environ 40 pages) qui sont également consacrés à la seconde partie « Analyser le problème » qui est le premier « team skill » du livre. Nous voilà rentrés dans la matière. L’auteur nous propose 5 étapes pour définir le problème. Les choses sont rarement aussi simples que l’on puisse suivre une telle séquence de manière immuable, mais nombre d’analystes devraient s’inspirer de ce que l’on trouve ici : identification des acteurs, définition du périmètre du système et de ses contraintes et surtout, surtout : l’analyse causale ! La matière proposée concernant l’analyse métier est bien moins convaincante, mais on peut bien excuser de petites faiblesses… Le dernier chapitre de cette partie met surtout en musique ce que nous avons vu avec l’étude de cas du livre : HOLIS. Fort intelligemment, il ne se contente pas de reprendre la matière du chapitre 4, on y ajoute quelques petits éléments comme l’elevator statement.

La 3ème partie, comprendre les besoins utilisateurs, c’est vraiment du sérieux : pas moins de 9 chapitres ici ! De petits chapitres toutefois, car ils totalisent moins de 80 pages. Identifier les besoins utilisateur, ce n’est pas si simple et le chapitre 7 est consacré à ce challenge, même si c’est seulement sur quelques pages. Quelle est la différence entre « feature » et « requirement » ? La plupart du temps, on s’arrête à une bonne zone de flou. Dean Leffingwell nous propose une articulation claire entre besoin / feature et requirement. Savoir questionner est un art essentiel dans l’ingénierie des exigences. Si le sujet n’est pas aussi puissamment investigué que dans « exploring requirements » de Weinberg et Gauge, au moins est-il évoqué de manière non anecdotique. Les workshops sont un complément naturel à cette activité et là encore une matière intéressante et exploitable nous est proposée. Le chapitre qui suit sur le storyboarding est là pour servir d’introduction à celui sur les Use Cases qui va suivre. Il est vrai qu’aujourd’hui, en ingénierie agile, on s’appuiera d’avantage sur le Story Mapping. Oui, bien sûr les cas d’utilisation sont évoqués, c’est forcé ! En fait, ils le sont plusieurs fois dans l’ouvrage, ici on s’arrêtera à la vision d’ensemble. On ne peut évoquer les cas d’utilisation sans parler de rôles, l’occasion pour l’auteur pour évoquer brièvement les cartes CRC, une brièveté certainement frustrante mais il est certainement possible de se reporter sur l’ouvrage de Bellin et Simone si le cœur vous en dit… On termine cette partie très riche par l’évocation des prototypes, à titre d’introduction.

La « team skill 3 », c’est définir le système, on a 3 chapitres pour cela. Comptez 3 chapitres et un peu moins de 30 pages. Oui, un moment, on parle documents et organisation de ceux-ci. Ce n’est pas le plus passionnant, mais au moins le sujet est-il abordé avec une certaine intelligence. Un chapitre est même consacré au document de Vision (avec un template, s’il vous plait), si cher à Philippe Kruchten. Retour à l’aspect humain pour clore le chapitre, avec le Product Champion. Ce qu’on y évoques recoupe pas mal ce qu’aujourd’hui on appelle un Product Owner.

Gérer le périmètre, c’est le sujet de « team skill 4 », qui couvre 4 chapitres sur un peu plus de 40 pages. On commence par le « pourquoi » de cette problématique de périmètre : en quoi est-ce important et dimensionnant. Pour aborder cette question du périmètre, Leffingwell s’adosse aux dimensions suivantes : des priorités qui se ventilent sur des releases, une gestion des risques et de l’effort, le tout illustré avec HOLIS. On trouve là les prémices de SAFe… L’engagement des utilisateurs dans cette gestion de périmètre est évoqué, mais guère convaincante. Personnellement j’ai bien aimé le chapitre 22, non pas parce qu’il évoque RUP (dans lequel l’approche de l’auteur s’inscrit), mais parce qu’il évoque aussi comment la gestion du périmètre a évolué entre le modèle en cascade, le modèle en spirale de Boehm et finalement le modèle itératif.

La partie consacrée au raffinement des spécifications est l’autre grosse partie du livre : 6 chapitres sur un peu plus de 80 pages. On commence par évoquer en profondeur la nature des exigences : comment on différencie le domaine du problème de celui de la solution, ou encore les différents types d’exigence. Le chapitre 23 est particulièrement affuté sur le sujet. S’en suit une introduction sur la spécification des cas d’utilisation. Bel exercice, même s’il ne saurait concurrencer les livres dédiés au sujet (je pense particulièrement à celui de Géri Schneider. Quand on parle de requirements à l’ancienne, on parle souvent de SRS et du fameux IEEE 830-1998. Le sujet n’est pas esquivé. Ambiguïtés et précision font parties des pratiques que doit développer tout analyste. Le sujet n’est qu’effleuré, même s’il l’est plutôt bien. Mais « exploring requirements » ou Tom Gilbs avec Planguage vont au moins un cran plus loin. La question des critères et de la mesure de qualité des spécifications est la mesure de la rigueur de l’analyste. Leffingwell aborde honorablement le sujet, même si je préfère la prose des Robertson dans « Mastering Requirements » à cet égard. On referme cette partie avec une revue des formalisations plus ou moins funkies des exigences : pseudo-code, diagrammes d’état-transition, etc.

La dernière partie « building the right system » reste imposante avec 6 chapitre et plus de 70 pages. Le chapitre consacré à la transition des exigences à la réalisation n’est pas mon préféré et apporte je pense assez peu. La traçabilité est un grand classique. S’il a cessé d’être un centre d’intérêt pour moi, le sujet existe, dommage qu’il soit abordé sous l’angle des outils, tout comme le sera le volet sur le change management. Par contre le test et la validation sont des points d’importance. Ils ne sont peut-être pas traités avec l’importance qu’ils devraient mais ils sont là. J’aurais par contre du mal à cautionner l’approche d’effort de validation par le ROI…

Le point fort de cet ouvrage est l’importance du tour d’horizon qu’il nous imprime sur l’activité d’ingénierie des exigences. C’est probablement l’ouvrage le plus complet à cet égard, et il faut bien avouer que l’on ne s’ennuie jamais. Nombre sinon tous les sujets peuvent nous amener sur des textes plus complets, et c’est très bien.

Au delà de ceci, on regrettera toutefois que le livre se cantonne souvent à la présentation des techniques de capture d’exigences, et que les véritables “guidelines” soient par trop absents, de même qu’un véritable processus de gestion d’exigences capable de cimenter l’ensemble des techniques présentées. Ceci fait que je préfère l’ouvrage de Suzanne et James Robertson, et que je considère celui-ci à la fois comme un complément et un texte embrassant plus large sur les différents volets de l’ingénierie des exigences.
Ce texte a connu deux éditions depuis celle-ci, dont la dernière markettée en agile.

image

Référence complète : Managing Software Requirements, a unified approach – Dean Leffingwell & Don Widrig – Addison Wesley / O.T. series 1999 – ISBN: 0-201-61593-2

Managing Software Requirements: A Unified Approach


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

Taylorisme et travailleurs du savoir

Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

image

Le modèle Cynefin [2] est une illustration de la théorie de la complexité. Ce n’est pas le seul modèle développé à cet égard. L’usage premier de ce modèle est de montrer le dynamiques de transition entre les différentes zones. Pourtant, ce n’est pas ce à quoi il va nous servir aujourd’hui. Nous allons l’utiliser pour catégoriser nos contextes projet !

Le domaine simple (évident)

La relation de causalité est directe, évidente. Dès lors la solution s’impose d’elle-même. C’est pourquoi nous sommes dans le domaine des « best practices » : on peut déterminer la meilleure solution à un problème donné. La déclinaison la plus connue de cette approche de « bonnes pratiques » est le management scientifique du travail, qui se traduit par la décomposition d’un travail en tâches élémentaires optimisées. Nous reviendrons bientôt sur ce sujet.

Le domaine compliqué

Toujours sur la base de la relation de causalité, on estime ici que cette relation de causalité nécessite une analyse ou une expertise pour pouvoir être établie à priori. C’est le domaine des « bonnes pratiques ». La solution au problème n’est donc pas nécessairement unique ! On s’offre un éventail d’options restreintes pour traiter notre problème. Cette déclinaison correspond assez bien à Unified Process qui supporte une forme de customisation [5] par rapport au contexte, permettant cette notion d’options.

Le domaine complexe

Il est en rupture avec les deux précédents, car ici, le lien de causalité ne peut être établi à priori, mais seulement observé à postériori. Nous sommes donc dans le domaine de l’approche empirique et des phénomènes emergents utilisant une boucle de feedback.

Nous sommes dans le « sweet spot » de l’agilité : les territoires inconnus se prêtant à une approche exploratoire.

Le domaine chaotique

Ici, il n’y a aucune corrélation entre cause et effets. Ce domaine induit de purs comportement de réponse aux situations. Nous sommes dans des environnements type « guérilla urbaine » qui ne sont plus le domaine de prédilection de l’agilité.

Le cadre du management scientifique du travail

Le « management scientifique du travail », vous en avez tous entendu parler. Mais peut-être pas sous ce nom. Peut-être êtes-vous plus familier avec le terme « Taylorisme » ?

Dans les grands traits, le management scientifique du travail [3] divise les responsabilités entre deux groupes :

  • Les managers dont le rôle est d’analyser et de dicter la façon de faire le travail
  • Les ouvriers qui doivent suivre à la lettre les instructions (selon le propos de Taylor « ils sont trop stupides pour savoir comment bien travailler » !)

Replacé dans le contexte de la fin du XIXème siècle, à une époque où le travail des ouvriers avait une nature hautement mécanique, cela a du sens. Je vous choque ? Pourtant le Taylorisme fut une avancée majeure pour permettre la production de masse (qui n’existait pas avant) et a permis la révolution industrielle. Aujourd’hui même, les biens de consommation que nous ne saurions nous passer sont presque là grâce au Taylorisme !

image

Quelle place le Taylorisme occupe-t-il dans le modèle Cynefin ? De mon point de vue, il s’agit indubitablement du quadrant « simple » (évident). On est réellement dans le domaine des « best practices, d’ailleurs Taylor parle bien de selection du « best movement » (p. 57) !

Toutefois, et cela a été ignoré par les successeurs de Frederick Taylor, il y a bel et bien des postulats au Management Scientifique du travail

Les postulats du Taylorisme

Ma lecture du texte de Taylor m’amène à penser que les postulats de base sont au nombre de 3. Allons-y !

Le travailleur est trop stupide pour savoir organiser son travail lui-même !

Vous êtes surpris (ou de nouveau choqués) ? En fait, je ne fais que répéter les propos même de Frédérick Taylor ! En fait il répète même cela à plusieurs reprises dans son livre. Il faut dire que l’humain n’était pas forcément le soucis principal de cet ingénieur.

Si le respect des personnes ne semble pas tellement présent, le texte ne laisse pas non plus penser que les travailleurs en question sont des genies…

Le besoin du travailleur se situe au niveau de la sécurité

Certes, on n’avait pas encore la pyramide de Maslow à l’époque, mais un point méconnu est pourtant tout à fait explicite dans le texte de Frederick Taylor : le partage des gains opérés entre le détenteur du capital, le travailleur et le consommateur !

Il faut se replacer dans le contexte de l’époque. Les travailleurs manuels luttent pour nourir leur famille, se loger et s’habiller. L’accomplissement de soi n’est pas leur problème du moment. Ils e situent bien au second niveau de la pyramide de Maslow

image

Ce que propose Taylor est une augmentation très importante de leur revenu [3], p. 46 allant de 80% à 100% avec une réduction significative de leur temps de travail (de 10,5 heures à 8,5 heures). Ce qui, chemin faisant, fait du travailleur un consommateur !

Curieusement, cette contrepartie a progressivement disparue chez les successeur de Taylor !

Le domaine adressé est celui du travail répétitif

Ce postulat n’est pas explicite. Mais il est implicitement présent tout au long du livre. Car l’auteur parle bien de « mechanical shops ». Il n’est fait mention nul part d’expérimentation portant sur du travail non répétitif ou du fait qu’un travail de reflexion puisse être assimilé à un travail répétitif. On trouve cependant une référence au travail de chirurgien, dont il est dit à juste titre que les opérations simples peuvent tomber dans le cadre du « management scientifique du travail ». Un raisonnement que l’on peut accorder à l’auteur … en gardant à l’esprit que l’on parle de chirurgiens du 19ème siècle !

La nature intrinsèque des méthodes classiques

Que l’on parle de cycle en « V » ou d’Unified Process, ces processus sont toujours abordés de la même façon : sous l’angle de ce qui est produit, par qui, comment … En fait tous ces processus peuvent être décrits par le biais d’un métamodèle ! C’est déjà ce que Ken Schwaber mettait en lumière en 1995 [1] !

Voici justement, à peine simplifié, celui d’Unified Process.

image

Même avec un processus accordant certains degrés de liberté, la logique reste bien là : on définit qui produit quoi, comment est-ce produit et dans quel contexte. Intrinsèquement, nous faisons la même chose que Taylor, il y a 130 ans, mais sans respecter aucun de ses postulats. Aucun !

Les approches agiles : une nature disruptive

Ce qui distingue les approches agiles (j’évite le terme « processus » à dessein) des autres, c’est justement de ne pas être construites sur un métamodèle, mais sur ce que nous appelons souvent la pyramide agile. Vous la connaissez très certainement, pardonnez-moi de la refaire figurer ici (et de l’expliquer).

image

Les valeurs : Ils figurent dans le manifeste agile et nous montrent la direction. C’est ce que j’appelle la « boussole agile ».

Les principes : Mise en musique du manifeste, les principes donnent des axes concrets sur les règles à suivre.

Les pratique : Boite à outil infinie (ou presque) à utiliser tel quel pour réaliser les logiciels, les pratiques nous donnent des aides, des façons de faire.

Point de métamodèle ici : on ne peut être émergent et prescriptif. On peut seulement fournir un cadre pour nous aider à aller dans la bonne direction !

Et alors ?

Retour au modèle Cynefin. Le Taylorisme n’est pas mauvais en soi. Il ne l’était surtout pas à l’époque. Mais justement le contexte doit être pris en compte : aucun des 3 postulats, ni le domaine d’application ne sont adaptés au développement du logiciel. Cela devrait nous laisser froid s’il n’existait pas une incarnation directe de celui-ci dans le monde informatique : c’est le micromanagement !

Las, les méthodes classiques s’éloignent quand même au moins un peu du micromanagement. Néanmoins, l’observation sous l’angle du métamodèle nous montre que le paradigme est le même !

Une approche moderne du développement logiciel doit satisfaire :

  • Les besoins des personnes, qui se situent aux niveaux 3 à 5 de la pyramide aujourd’hui.
  • La nature émergente, non prédictive du travailleur du savoir qui a d’avantage besoin d’une boussole que d’un marionnettiste !

Et vous, vous ai-je convaincu ?

Ressources

[1] : The Scrum Development Process – Ken Schwaber – OOPSLA 1995

[2] : The Cynefin model : http://en.wikipedia.org/wiki/Cynefin

[3] : The Principles of Scientific Management – Frederick Winslow Taylor

[4] : Agile and iterative development, a manager’s guide – Craig Larman

[5] : The Rational Unified Process, an introduction, third edition – Philippe Kruchten

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

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

Note de lecture : Software Development for Small teams: A RUP centric approach, par Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur

Note: 2 ; « J’écris un programme avec 3 potes, et j’en profite pour écrire un bouquin là-dessus ».

On pourrait presque s’écrier : à l’arnaque ! On n’en est pas loin, et une note de « 2 », c’est plutôt bien payé. Mais commençons par le commencement. Le livre ne porte pas sur l’adaptation d’UP aux petites équipes, mais d’un seul et unique projet sur lequel les auteurs ont essayé UP, c’est donc d’avantage une étude de cas qu’une synthèse d’experts. D’ailleurs, en fait de projet, il s’agit plutôt d’un développement fait en marge de l’activité professionnelle des auteurs, on est donc très loin des conditions normales d’un projet, mais par contre très proche des conditions de développement en « open source », ce qui n’est malheureusement pas identifié, et devrait être valorisé dans le titre. Il y a bien peu de chose à retirer de cet ouvrage ; les conditions de projet ne sont pas là, l’utilisation d’UP est plus expérimentale qu’autre chose, l’outillage employé (et éhontément promu dans le texte) inapproprié n’était-ce le fait que les auteurs les connaissent parfaitement et en disposent gratuitement. Une fois que l’on a lu cela, on peut à juste titre se dire que l’on peut tous se mettre à écrire son livre.

Les 2 seuls points intéressant sont la description du développement de type open source / distribué et l’aspect « post mortem » particulièrement bien abordé. En bref : ne perdez pas votre temps sur ce bouquin.

soft-dev-small-teams-RUP

Référence complète : Software Development for Small teams: A RUP centric approach – Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur – Addison Wesley / O.T. series 2004 – ISBN: 0-321-19950-2

Software Development for Small Teams: A Rup-Centric Approach


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

Note de lecture : Adopting the rational Unified Process, par Stephan Bergström & Lotta Raberg

Note : 4 ; Une demarche qui a le mérite d’exister … mais la faiblesse de ne fonctionner que dans un environnement idéal !

Cet ouvrage complète la vision du RUP, non pas en abordant son utilisation, mais son déploiement au sein d’entreprises. A cette fin, les auteurs ont développé un processus d’adoption, dont les étapes servent de fil rouge à la structure de l’ouvrage. Si cette démarche est bien aboutie et forme un ensemble logique, il n’en reste pas moins que sa mise en œuvre semble se confiner aux grands groupes dont les moyens sont conséquents, capable de dédier un projet juste-comme-il-faut en tant que poisson pilote de l’organisation, et tout et tout…

Bref, il y a du bien et du moins bien dans ce livre, mais il est improbable que l’on ait souvent l’occasion de dérouler le processus tel qu’il est décrit. Il est plus probable que l’on ait la possibilité d’en exploiter des morceaux. Un autre point faible (et gênant) de l’ouvrage est qu’il est très abstrait quand au RUP lui-même ! J’aimerais d’avantage d’exemple plus concrets que des phrases telles que « sous ensemble de la discipline de tests ». En fait d’exemple, d’ailleurs, le style de l’ouvrage aurait été plus vivant si il avait été illustré tout au long par un exemple d’organisation fictive au sein de laquelle RUP doit être déployé.. Et ce, même si 2 références de déploiement sont décrites en annexes.

adopting-RUP

Référence complète : Adopting the rational Unified Process: Success with RUP – Stephan Bergström & Lotta Raberg – Addison Wesley / O.T. series 2004 – ISBN: 0-321-20294-5

Adopting the Rational Unified Process: Success with the Rup


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