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.

Lire la suite

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

Lire la suite

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