Innover, ce n’est pas avoir une nouvelle idée mais arrêter d’avoir une vieille idée.
Edwin Herbert Land
En Finir avec le Planning meeting ?
Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !
Autopsie du planning meeting
Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :
- Une présentation des fonctionnalités souhaitées pour le prochain sprint
- Une planification de l’execution de ces fonctionnalités pour la durée du sprint
Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]
Note de lecture : High-Speed Windows Applications, par Bruce E. Krell
Note : 2 ; Beaucoup de lourdeurs et de formalisme, mais peu d’idées intéressantes.
Ce livre traite de la gestion multitâche sous Windows 3.1, donc en s’appuyant sur les messages Windows. On en prend pour plutôt cher : un peu plus de 330 pages hors annexes. Celles-ci sont elle-même volumineuses : 130 pages ! L’approche pédagogique est pour le moins sujette à caution, le formalisme est lourd et guindé. Le titre de section de la page 7 est assez symptomatique : « Turn off your PC ! ». Mais voyons ce que ce volume a dans le ventre. En l’occurrence, ses entrailles sont divisées en 10 chapitres.
Le premier chapitre se compose d’une douzaine de pages pour décrire l’approche générale de la méthode (car en fait, c’est une méthode). On a vite compris que l’on va s’appuyer sur les message Windows centré sur la logique utilisateur.
Le chapitre 2 est aussi une introduction, mais cette fois au SDK. C’est très descriptif et donc assez abstrait. Je ne pense pas que j’aurais pu aborder la programmation Windows avec ça (merci Charles Petzold !). Les exemples de code des fameux « WinMain » et « WndProc » n’aident guère.
Continuer à lire « Note de lecture : High-Speed Windows Applications, par Bruce E. Krell »
Your quote here.
Bjarne Stroustrup in The C++ Language (about templates)
Agile Playground #15
Un conflit d’agenda m’a fait raté le 14ème rendez-vous, c’était donc une bonne surprise de voir un Agile Playground programmé en cette première quinzaine de Juillet, alors que je croyais nos rendez-vous interrompus jusqu’en Septembre !
Au programme de cette soirée, un ice-breaker sans prétention mais amusant proposé par Frank Beulé et une traditionnelle expérimentation de jeu.
Note de lecture : Le génie logiciel orienté objet, par Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Övergaard
Note : 3 ; Trop théorique et trop volumineux
Voici un livre qui traite vraiment de méthodologie. Jacobson est le créateur des use cases, il était donc logique que son livre se focalise sur l’analyse. Au delà de ceci, il traite bien entendu des aspects processus et conception, cependant son propos reste souvent de très haut niveau. Mais voyons plus précisément ce que recèle l’ouvrage. Tout d’abord, il est volumineux, avec plus de 500 pages sur 16 chapitres regroupés en 3 parties.
La première partie traite des concepts objet. On en prend pour 5 chapitres sur 110 pages. Le premier chapitre est représentatif du livre : de bons vieux concepts « industriels », avec un processus en phase et une grande croyance dans la réutilisation sortie des cartons… Le second chapitre est une variation de celui-ci et ne nous apprend pas grand chose. C’est avec le chapitre 3 que l’on aborde l’orientation objet. Une vue très conceptuelle et analyse de l’objet, qui fait écho à ce qui est développé dans OMT (mais sans être aussi bien formalisé). Le chapitre 4 est le prolongement « conception » de ce chapitre. J’avoue avoir du mal à distinguer en quoi il apporte quelque chose au propos. En toute logique, le 5ème chapitre traite de l’implémentation orientée objet. C’est une nouvelle illustration de l’incapacité des ouvrages méthodologiques de cette époque de traiter décemment d’implémentation !
La seconde partie parle des « concepts », c’est à dire en fait des grands domaines d’ingénierie. Ce sont 7 chapitres qui constituent cette partie, la plus longue du livre avec près de 240 pages. Et l’on commence par évoquer l’architecture. En fait d’architecture, les auteurs développent plutôt une représentation en vues du système, ce qui permet d’introduire chemin faisant les cas d’utilisation. Mais tout ceci est bien abstrait. C’est de modèle d’analyse qu’il est ensuite question, en quelque sorte une reprise des chapitres 3 et 4. Puis c’est au tour de la « construction ». Pas plus que le chapitre 5, celui-ci n’est convainquant. Mais c’est l’occasion de présenter quelques diagrammes : diagramme d’interaction, d’activité et d’état-transition. Les auteurs tentent aussi de décliner quelques spécialisations , comme le temps réel avec un focus particulier sur les stimuli et la communication entre objets. On s’occupe également des bases de données, sujet mal traité qui semblait plutôt facile à aborder pourtant. On parle aussi de composants, on en parle toujours. Et c’est toujours aussi peu convainquant. Viennent finalement les tests, dont on se dit que le chapitre ne sert qu’à occuper le terrain…
Success is not final, failure is not fatal: it is the courage to continue that counts.
Winston Churchill
What to do when Scrum doesn’t works
Et d’abord, c’est quoi Scrum ?
Oui, je sais, on peut faire référence au Scrum Guide et à toute ces sortes de choses, mais pour Henrik Kniberg, ce sont :
- De petits morceaux de fonctionnalités
- Des équipes subdivisées en petites équipes
- De petites tranches de temps.
- Une valeur métier optimisée
- Avec un processus optimisé !
Et c’est tout !
Pourtant, visiblement, tout ça peut mal se passer. Voyons comment et comment y remédier. Avec 5 cas de figure.
Mal utiliser le processus
S’en prendre à Scrum alors qu’il faudrait plutôt penser à notre façon de l’utiliser est le premier symptôme. Le grand classique est le temps consacré aux cérémonies : s’il est exagérément long, il s’agit simplement d’un avertissement, nous essayons de pratiquer Scrum comme une méthode classique !
Note de lecture : La bibliothèque standard STL du C++, par Alain-Bernard Fontaine
Note : 0 ; A éviter à tout prix !
Si vous cherchez dans cette sélection un livre à éviter à tout prix, vous venez de le trouver. L’auteur est probablement un bon programmeur, d’ailleurs il nous vomit des pages de code pour expliquer des choses qui seraient mieux mises en valeur sur 4 ou 5 lignes, mais il est sans aucun doute un exécrable pédagogue. Sans compter que l’auteur semble imaginer que l’on utilise les STL que pour stocker des entiers ou des flottants : les exemples se cantonnent exclusivement à cela ! Les explications sont souvent confuses et incomplètes.
Le livre ne commence sérieusement qu’avec le chapitre 3. Les deux précédents nous ont surtout servi à appréhender la pauvreté de l’expression écrite que nous aurons à subir durant le reste de l’ouvrage. Donc ce chapitre 3 sert de base pour le reste du livre, bases qui sont sans connexion directe au sujet (l’auteur pense que nous sommes assez suicidaires pour nous servir de ce texte comme base de notre savoir en C++). On y évoque de manière décousue les templates, les exceptions et surtout la bibliothèque iostream. Le tout décousu à l’envie.
Le chapitre 4 est curieusement appelé « organisation de la librairie C++ : il s’agit d’un listing des headers de la librairie C++ et d’une pseudo-description sur 3 pages de la classe string, avec un magnifique diagramme de Booch dont les éléments sont positionnés avec une précision d’un demi-centimètre !
It is said that power corrupts, but actually it’s more true that power attracts the corruptible.
the sane are usually attracted by other things than power.
David Brin
