Note de lecture : Software Configuration Management Patterns: Effective Teamwork, Practical Integration par Stephen Berczuk & Brad Appleton

Note: 8 ; Un “langage de patterns” bien construit, mais aussi une excellente référence sur la gestion de configuration.

On trouve deux types d’ouvrages sur la gestion de configuration : ceux développant des processus de gestion de configuration, souvent compliqués et éloignés des préoccupation quotidiennes des développeurs, et ceux traitant des outils, les détaillant en profondeur mais sans réellement expliquer comment les utiliser intelligemment. Cet ouvrage se démarque résolument de ces deux tendances en exposant les principes de la gestion de version et de configuration sous forme de « process patterns » qui sont autant de cas d’utilisation. Des cas d’utilisation résolument tournés vers le développeur, afin de l’aider dans ses tâches quotidiennes.

Une courte première partie introductive recadre la place de l’outil de gestion de versions et de configuration dans l’environnement de développement. Il présente également la structure des patterns et l’image globale de ce langage de patterns. On y distingue deux sous-ensembles : les patterns orientés « codeline » c’est-à-dire purement gestion de version, et les patterns liés à la gestion de l’espace de travail.

La seconde partie, forte de 120 pages, forme 16 chapitre, chacun présentant un pattern (donc, une moyenne de 7 pages par patterns). Je ne saurais tous les présenter, mais en voici quelques uns :

Active development line : Comment gérer une branche de développement suffisamment utilisable et stable à tout moment, afin de satisfaire les besoins de développement

Private build : Pensez de façon globale, et construisez localement. Ou comment, avant de soumettre des changements, construire et tester de manière identique au build d’intégration, mais sur l’espace privé de développement

Intégration build : Pour s’assurer que toutes les changements injectés dans le repository central sont construits et testés par un processus centralisé.

Task level commit : Pousser dans le gestionnaire de versions à chaque changement de faible granularité mais indissociable (résolution d’un problème, mise en conformité avec une évolution d’interface, etc.).

Comme c’est le cas avec les bons patterns, un bon nombre nous donne un goût de déjà-vu. D’autres moins. L’approche « patterns » est réellement utilisée à bon escient : le problème est évoqué, souvent étayé par une expérience vécue, pour déboucher ensuite sur le développement de la solution, soutenus par des références extérieures. On appréciera aussi, mine de rien, de voir relevé en vis-à-vis des patterns, les points non résolus ! Que vous soyez expérimentés ou débutant, vous devriez vous régaler à la lecture de ces patterns : on bénéficie réellement de l’expérience et de la qualité de synthèse et d’expression des auteurs. Connaître les commandes de votre outil de gestion de version n’est pas tout (bien que cela soit nécessaire), il faut savoir utiliser et organiser son travail au quotidien afin de travailler de façon efficace, coopérative et rigoureuse afin d’éviter les problèmes inhérents au travail en équipe. Ce langage de pattern est sans nul doute la réponse pragmatique, efficace et opérationnelle. Le tout en moins de 200 pages. Last but non least, les appendices si succincts soient-ils fournissent d’excellents liens Web et une ébauche d’évaluation des outils existants. Vous aurez compris : j’ai aimé.

Les DVCS ont certainement ajouté leur lot de patterns également, même si ceux évoqués ci-dessus restent d’actualité. J’adorerais voir une seconde édition de l’ouvrage intégrant cela. Une autre avancé possible est la prise en compte de la déliverie en continue (le devops) dans le cycle logiciel abordé.

Les auteurs travaillent à une seconde version de l’ouvrage, toutefois celle-ci est encore à l’état de projet. Il n’est d’ailleurs pas dit qu’elle sorte un jour.

soft-conf-mgt-patterns

Référence complète : Software Configuration Management Patterns: Effective Teamwork, Practical Integration – Stephen P. Berczuk & Brad Appleton – Addison Wesley / SP series 2002 – ISBN : 0-201-74117-2

Software Configuration Management Patterns: Effective Teamwork, Practical Integration

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

Note de lecture : Manage Your Project Portfolio, Increase your capacity and finish more projects, par Johanna Rothman

Note:6 ; Pas aussi bien qu’espéré

Voilà un sujet qui m’intéresse au premier chef : comment gérer, non pas un projet, mais un ensemble de projets organisés en un « portefeuille ». La grande qualité de cet ouvrage est certainement de ne pas chercher midi à quatorze heures, et de rester simple et pragmatique. D’ailleurs le format du livre reflète cette concision : 11 chapitres couvrant 160 pages.

Les deux premiers chapitres nous font découvrir ce qu’est un portefeuille de projets, comment le structurer et comprendre le cycle de vie de ses projets.

Dans les chapitres 3 et 4, on apprend tout d’abord à organiser ses projets : quel doit être leur granularité ? Les projets doivent-ils être structurés en programmes ? On y voit finalement quoi envisager de l’avenir d’un projet commit, kill, transform) en fonction de sa nature.

Prioriser et travailler en groupe pour décider du devenir du portefeuille sont l’objet des chapitres 5 et 6. L’auteur y propose plusieurs techniques à cet égard.

Les chapitres 7 à 9 s’avèrent moins originaux : ils traitent de la vie et de l’évolution itérative du portefeuille. Ce qu’on y lit, bien qu’intéressant, ne diffère guère de ce que l’auteur a pu dire de la gestion de projets dans « Manage It ». Même si le propos sur l’approche agile en général, et le Lean en particulier sont clairement intéressants, ils n sont pas spécialement originaux dans le contexte de ce sujet en particulier.

Le chapitre 10 sur les mesures peut également aussi bien s’appliquer au niveau d’un portefeuille que d’un projet. Je pense quand même qu’appliquer ces métriques au niveau de l’itération relève d’une granularité trop fine. Simple question d’appréciation personnelle.

Fort heureusement, on termine avec une note plus originale : définir sa mission, en tant qu’équipe ou en tant que manager. C’est un exercice à la fois simple et dans le principe et difficile dans la mise en œuvre. Mais il éclaire beaucoup dans la ligne de conduite et la façon d’évaluer son portefeuille de projets.

En bref, voici un livre qui donnera un certain nombre de clés pour réussir à gérer son portefeuille de projets. En fait, j’ai déjà utilisé une partie de ce que l’auteur propose pour travailler mon propre portefeuille de projets, avec succès. Je suis toutefois un peu déçu par ce que j’y ai trouvé, mais certainement parce que mes attentes se situaient assez haut, eu égard à ce que l’auteur nous a livré jusqu’ici.

Ma note reflète surtout mon niveau d’exigence par rapport aux textes écrits par Johanna Rothman : il est bien plus élevé que pour le commun des auteurs. Malgré une notation qui peut paraître modérée, c’est un livre que je recommande sans réserves.

manage-project-portfolio-pragprog

Référence complète : Manage Your Project Portfolio, Increase your capacity and finish more projects – Johanna Rothman – The Pragmatic Bookshelf 2009 – ISBN: 978 1 93435 629 6

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects


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

De la sécurisation du SI à la sécurisation de la prise en charge

De la sécurisation du SI à la sécurisation de la prise en charge

De son émission au prescripteur, l’information sur le médicament suit une longue chaine de traitement et de mise à disposition. Chaque étape requiert un niveau particulier de vérification, de sécurisation et d’auditabilité afin d’assurer au professionnel de santé une totale fiabilité de cette information.

Quand mon produit est un système d’information (Scrum Day 2011)

Scrum évoque implicitement, dans les différentes descriptions qui en sont faites, la réalisation de systèmes fermés, qu’ils soient logiciels ou applications Web.

Lorsqu’il s’agit d’informatique interne, il s’agit le plus souvent, non plus de réaliser une application isolée, mais de faire grandir un système d’information constitué de plusieurs composants applicatifs collaborant ensemble.

Dans ce contexte, la dimension projet est généralement dissociée de la dimension produit (le système d’information). Comment gérer une telle dichotomie avec Scrum ?

Les différents projets d’informatique interne s’adossant et faisant croitre un même système d’information, comment gérer les interactions et les synergies entre ces projets ?

Est-il nécessaire de penser et faire des plans sur l’évolution de l’architecture du SI indépendamment du cadre imposé par chaque projet ? Si oui, est-il possible de faire cela tout en restant dans Scrum ?

C’est à ces différentes questions et bien d’autres encore que nous tentons de répondre ici.

Note de lecture : Software Estimation, Demystifying the Black Art, par Steve McConnell

Note : 8 ; Steve McConnell frappe encore!

Les ouvrages de Steve McConnell sont parmi les seuls que j’achète sans les ouvrir : quand je vois un nouveau titre, je ne cherche même pas à savoir ce qu’il y a à l’intérieur, j’en fais juste l’acquisition ! Celui-ci, colle à l’accoutumée (ou presque) et ne m’a pas déçu.

McConnell différencie l’art de l’estimation et la science de l’estimation. La « science », ce sont les méthodes d’estimation permettant, à l’aide de formules, d’euristiques et de facteurs d’ajustement d’obtenir des chiffrages de projet ; les approches telles que FPA et Cocomo II se rangent dans cette catégorie. Ce livre traite de l’autre partie : l’art de l’estimation.

La première partie est consacrée aux concepts de l’estimation. Cette partie est particulièrement précieuse pour comprendre et justifier les facteurs d’incertitude, les facteurs influençant les estimations et les sources d’erreur.

La seconde partie constitue le cœur du livre, puisque l’auteur y livre son approche des estimations. Celle-ci est basée sur un simple processus : compter, calculer et juger. Autour de cette approche, Steve McConnell développe plusieurs techniques, telles que l’utilisation de données historiques, le jugement d’experts, l’estimation par analogie ou en groupe.

La dernière partie se focalise sur les challenges particuliers de l’estimation : estimer la taille, évaluer l’effort associé et estimer une planification. Au-delà des estimations elle-mêmes, le problème le plus souvent rencontré est la présentation des résultats et le traitement des problèmes politiques entourant les estimations.

Les estimations sont un problème épineux, peu d’ouvrages traitent ce problème. Ceci fait de ce livre un ouvrage particulièrement précieux sans être inutilement compliqué. C’est pour cela que je conseille ce livre sans réserves aucune.

mcconnell-software-est

Référence complète : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1

Software Estimation: Demystifying the Black Art


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