Personne ne parle en notre présence comme il en parle en notre absence. L’union qui est entre les hommes n’est fondée que sur cette mutuelle tromperie.
Blaise Pascal
Mois : février 2015
L’Impact Mapping s’invite au French SUG !
Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.
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.
Buying an Agile lifecycle management tool to learn Agile development is like using a calculator to learn math.
Jeff Patton
Agile Playground #19 : austèrement Kanban !
Je ne sais si ce début d’année est synonyme de démarrage en douceur, mais j’ai tendance à trouver nos premiers meetups doucement fréquentés…
Deux jeux au programme de cette 19ème édition et un ice-breaker !
La liberté de notre volonté se connaît sans preuve par la seule expérience que nous en avons.
René Descartes
Le bitcoin sous toutes ses faces !
En cette fin Janvier, le meetup Product Tank nous proposait un programme tout à fait prometteur : 3 invités venus pour nous présenter le bitcoin sous 3 perspectives différentes ! Sébastien Levaillant a fait un travail remarquable pour organiser cela. Travail mal récompensé par une participation plutôt faible : seulement 25 personnes présentes sur les 75 inscrits !
Bien sûr, le sujet est moins cliquant que lorsque l’on invite le Product Manager d’un commerce en ligne très en vue. Toutefois le sujet est au moins aussi intéressant, plus même dans ce cas précis, car on se situe là en pleine innovation économique !
Note de lecture : Architecting Enterprise Solutions, par Paul Dyson & Andy Longshaw
Note: 7 ; Un excellent “pattern language” d’approche très Alexandrienne. Dommage que l’aspect solution me laisse un peu sur ma faim.
Le titre de l’ouvrage est assez évocateur à cet égard: Il s’agit là de décrire le style architectural des systèmes d’information Internet à l’aide d’un pattern language, à la Christopher Alexander. Digne représentant de la « software design patterns series », cet ouvrage expose sur 290 pages découpées en 12 chapitres formant 3 parties des architectures de déploiement dédiées aux applications Internet. Bien sûr, vous allez me dire que le texte va accuser son âge, surtout dans le domaine où les plus grands progrès ont été faits au cours des 10 dernières années ! Si ce point est indéniable, il n’est pas aussi marqué que l’on pourrait le craindre car il se focalise bien plus sur les principes d’architecture que sur les solutions techniques !
Je passe sur le premier chapitre qui ne nous apprend rien pour aborder la première partie « Architecture, Patterns and Internet Technology » qui comprend 4 chapitres sur 60 pages. Le premier d’entre-eux (donc le second chapitre) « system architecture » mérite que l’on ne passe pas trop vite dessus. Ses 15 pages sont consacrées aux propriétés non-fonctionnelles des architectures. Intéressant. Le point sur les technologies de l’Internet que nous propose le chapitre 3 sur 17 pages est un peu superficiel, mais pas aussi démodé que l’on pourrait le croire. Mais il apporte peu. Le chapitre 4 est en quelque sorte la table des matières patterns du livre. C’est un incontournable pour ce genre d’ouvrage. Pour clore cette première partie, les auteurs présentent l’étude de cas fictive sur laquelle ils ont choisi de s’appuyer. On y fait le tour des propriétés non-fonctionnelles que l’on avait énumérées au chapitre 2. C’est bien fait.
Avec 167 pages, la seconde partie est le gros de la troupe du bouquin, et de loin ! Il faut dire que cette partie qui ne compte pourtant que 4 chapitres s’intitule « The Patterns ». Et l’on commence fort logiquement au chapitre 6 par un chapitre « fundamental patterns » de 18 pages. Il présente deux patterns, le très classique « application server architecture » encore largement majoritaire aujourd’hui et un moins convainquant « péripheral specialist elements » dont la symétrie est questionnable du fait de la BDD unique… Le chapitre 7 nous offre un gros morceau avec les « system performance patterns » qui couvrent 45 pages. Les patterns architecturaux de ce chapitre sont particulièrement intéressants et bien décrits dans leur essence (load balancing, redondance, failover, appliance, replication, resource pooling, cache, offlining), il ne manque guère que le sharding des bases NoSQL ! Les diverses variantes de ces stratégies sont abordées ainsi que des considérations d’équilibrage de charge CPU, etc… Bref un chapitre riche qui justifierai le livre à lui tout seul !
Leadership isn’t about having all the answers, it’s about creating conditions where everyone can contribute to solving problems
Esther Derby
Soirée « en finir avec… »
Cela faisait déjà un petit moment que je pensais à ma petite soirée mégalo à moi. Oh, surprise, elle a fini par avoir lieu ! Nous nous sommes donc retrouvé ce Jeudi 29 Janvier chez Zenika autour de ce thème. Cette fois, ce ne sont pas les intempéries, mais une grève inopinée des transports qui ont eu raison de l’enthousiasme de 2/3 des inscrits. Heureusement pour nous le format d’atelier que nous proposions se prêtait bien à un groupe plutôt restreint, une vingtaine de personnes.
Bon, c’est ma soirée, c’est donc à moi de faire l’ouverture !
Pas de répit pour les braves, on enchaines avec les propositions et les choix de sujets !
Software Freethinker 