Lorsque l’on parle de sprint, on fait souvent référence à un numéro pour les identifier. On commence avec le sprint zéro pour aller vers des sprints où la vélocité devient de plus en plus précise. En maintenance logicielle, le développement d’une application peut s’étaler sur plusieurs années et comprendre de multiples versions. Dans ce contexte, donner un nom de version à chaque itération du cycle de développement présente certains avantages.

Les règles de nommage d’une version (technique) d’un logiciel sont définies par la personne en charge de l’application. Il est possible de définir une version technique (par exemple, une suite de quatre nombres séparés par un point) et une version commerciale (pour faciliter la communication autour d’un lot de nouvelles fonctionnalités par exemple).

Pour la version technique, certaines équipes adoptent le format A.B.C.D où chaque membre correspond à:
- A: la version majeure
- B: la version mineure
- C: la version de maintenance
- D: le numéro de build ou autre indicateur.

Utiliser le membre D comme incrément de sprint permet de faire le lien entre numéro de version technique, éléments compilés et numéro d’itération à laquelle est raccrochée de nombreux développements. Le membre D est réinitialisé à chaque fois que l’un des trois autres membres change.

Les avantages à adopter cette règle sont nombreux en maintenance.
1) Cette règle de nommage des itérations rend les développements sur les versions assez étanches. Lors d’un sprint, la version cible est évidente (2.10.0.5) et l’itération associée ne doit pas porter des éléments de travail d’un correctif à réaliser sur une autre version (2.8.0.0). Ce correctif sera à aménager dans le sprint par le responsable du projet.
2) En branche principale, les itérations sont assez courtes. En branche de maintenance, elles n’ont plus la même signification et peuvent s’étaler sur plusieurs mois (une itération peut par exemple accumuler des correction de bugs mineurs jusqu’à ce qu’un déploiement soit décidé).
3) Lorsqu’un bug se produit sur une vielle version d’un logiciel, il est assez facile de retrouver tous les éléments de travail de l’itération associée.

Ce procédé de nommage s’utilise assez bien avec la solution T.F.S où on pourra donner le même nom de version aux éléments compilés, aux branches de développements associées ainsi qu’aux “iteration path”.

CLT-Services a le plaisir de recevoir Laurence Philbrook  les 6 et 7 février prochains pour co-animer avec Lan LEVY une formation de 2 jours sur Participatory Strategic Planning. Nous profitons de sa présence pour organiser une rencontre. Si vous êtes intéressé par la facilitation, vous êtes cordialement invité à nous rejoindre à cette occasion. PAF: 50 € (diner inclut)

Laurence Philbrook est président de The Institute of Cultural Affairs internationale et l’un des fondateurs de l’International Association of Facilitateurs. Il nous apporte 40 ans d’expérience internationale et une personnalité exceptionnelle. C’est l’occasion de le rencontrer, d'échanger sur la facilitation et poser vos questions…

Le rendez-vous est à 19h, le 7 février 2012, chez CLT Services au 34 Boulevard Sébastopol 75004 Paris, M°/RER : Les Halles. Inscription impérative par Internet.

Merci de passer le message à vos contacts susceptibles d’être intéressés par la facilitation.

C’est le titre d’un excellent article (dont je m’inspire fortement), publié sur Agile Zone, qui montre que les pratiques agiles peuvent très bien s’appliquer dans un contexte de maintenance. Certes, la littérature abonde d’articles ou de retours d’expérience sur le lancement de projet Agile mais ces pratiques peuvent être déclinées à d’autres contextes, comme le support, le marketing et bien sûr la maintenance de logiciel.

Un logiciel, dés lors qu’il arrive en production, entre dans un cycle de maintenance dédié aux corrections de bogues et aux évolutions logicielles. Les méthodes agiles peuvent rentrer en jeu pour rythmer ce cycle, en lui donnant par exemple une dynamique de sprints et le faire avancer vite et sûrement grâce à des concepts comme l’intégration, la livraison et le déploiement continu.

Si le logiciel a été développé sur des bases agiles, la transition vers la maintenance logicielle agile se fait sans problème. En revanche, il est plus difficile d’introduire ces pratiques dans une équipe de maintenance rodée au cycle en V, qui s’est organisée pour produire une réponse rapide à un bug en production et minimiser le risque sur les évolutions. Dans ce dernier cas, on constate une évolution lente du logiciel car maintenir la stabilité du logiciel demande beaucoup d'énergie au détriment des évolutions. Basculer vers la maintenance agile apporterait beaucoup à cette équipe habituée au cycle en V: l’introduction de pratiques XP permettrait par exemple de minimiser les bugs en production, de redonner confiance à l’équipe et au management qui consacreraient plus de temps pour travailler sur les évolutions: la valeur ajoutée.

De manière générale, les méthodes agiles peuvent être appliquées à la maintenance logicielle mais chaque équipe devrait s’interroger sur la manière de les adapter à leur propre situation. Personnellement, j’apprécie l’approche ScrumBan; elle convient plutôt bien à la problématique de maintenance logicielle.

L’agile en maintenance logicielle

Le planning game

Cet exercice est un peu plus délicat pour une équipe de maintenance qui doit faire face à des perturbations plus importantes qu’une équipe dédiée au développement. Typiquement, on retrouvera des activités de corrections de bug plus ou moins urgentes, des mises en production, du support, etc. L’équipe de maintenance devra intégrer ces contraintes afin d’estimer au mieux le potentiel de valeur ajoutée qu’elle pourra produire durant la prochaine itération. Elle peut aussi agir sur son organisation en minimisant les perturbations unitaires, c’est à dire en réservant certains jours des personnes à du développement tandis que d’autres sont associées à du support et/ou de la correction de bug et vice-versa.

Les standups meeting

Ces petites réunions quotidiennes où chacun fait le point sur son avancement gardent leur intérêt en maintenance logicielle. L’équipe discute des activités de développement, de support, des correctifs de bugs et mesure la tendance de l’itération: un évènement peut avoir des conséquences importantes sur les objectifs fixés durant le planning game auquel cas, le product owner ou chef de projet devra définir de nouvelles priorités.

Des releases fréquentes de petites tailles

La gestion des versions logicielles est assez complexe en maintenance logicielle. L’équipe de maintenance peut être amenée à travailler sur plusieurs générations différentes du logiciel: la branche de développement courante (mainline) et les branches de maintenance des versions précédentes du logiciel.

Concernant la branche principale, elle héberge le code source de la prochaine release du logiciel. Les autres branches de développement servent aux mises à jour mineures des précédentes versions (correction de bug par exemple).

Durant le planning game, le focus est mis sur le contenu de la prochaine release tout en prenant en compte la charge de maintenance des précédentes versions. Fonctionner en itérations courtes permet à l’équipe et au client de s’organiser plus facilement, notamment sur les aspects tests. Le client accepte plus facilement la stabilité de l’itération puisque le “travail en cours” qu’il aurait re-priorisé immédiatement pourra être discuté dans quelques jours, lors de la prochaine itération.

Les itérations courtes permettent notamment d’éviter l’effet tunnel et de livrer fréquemment un logiciel de qualité à forte valeur ajoutée. Les défauts sont repérés et corrigés plus rapidement.

Les rétrospectives

Les rétrospectives sont importantes en maintenance logicielle pour discuter des problèmes rencontrés et motiver l’équipe à proposer des solutions, à aller dans le sens de l’amélioration continue.

Le binômage et la responsabilité de code

Le binômage n’est pas évident à installer dans une équipe qui s’est laissée aller à la spécialisation (les développeurs se sont entendus sur leur responsabilités vis-à-vis de certaines parties du code source). C’est pourtant un très bon exercice pour partager naturellement les connaissances et bénéficier d’un autre avis sur la solution à implémenter. Si le binômage est compliqué à mettre en place, une bonne alternative est la revue de code, où un développeur prend un peu de temps pour relire le code de son collègue.

Une conception simple et la refactorisation

Les équipes de maintenance sont tributaires de conceptions et d’architectures souvent complexes et anciennes. Il est alors risqué d’ajouter de nouvelles fonctionnalités dans de tels systèmes dont le périmètre n’est pas bien connu de l’équipe. Cette dernière aura tendance à minimiser le risque en évitant de toucher à l’existant et créera des traitements particuliers pour chaque nouveau développement. Malheureusement, cela éloignera encore plus l’équipe de la maîtrise du système.

Il est important que l’équipe connaisse l’architecture du logiciel car elle sera capable d’identifier si un nouveau besoin client remet en question la conception actuelle et proposera dans ce cas un scénario de transition. Cette transition se traduira par un ensemble de taches de refactorisation et l’adaptation des tests unitaires liés.

Le développement piloté par les tests

Disposer de tests unitaires est indispensable en maintenance logicielle: l’équipe intervient sur un système complexe qu’elle ne maîtrise pas forcement => risque important de régression.

Le développement piloté par les tests est une pratique qui incite à écrire des tests unitaires avant d’écrire le code source de la fonctionnalité. Une équipe de maintenance qui souhaite utiliser cette approche pourra commencer par écrire des tests unitaires pour les nouveaux développements et sur les bugs rapportés. Elle peut également s’interroger sur les composants critiques sur lesquels il est bon d'invertir quelques tests. L’équipe peut s’appuyer sur un outil de couverture de code afin mesurer les parties non testées du programme et se donner des objectifs de couverture au fil des itérations.

L’intégration continue

Cette technique est idéale pour une équipe de maintenance logicielle. Elle permet de détecter les régressions de l’application à chaque modification de code. Pour travailler en intégration continue, l’équipe devra se doter d’un serveur d’intégration (comme CruiseControl par exemple) et s’imposer d’intégrer quotidiennement les modifications (tests unitaires compris) sur la même branche de développement. Le serveur sera en charge de la compilation, du lancement des tests unitaires, de la création de rapports (qualité du code, couverture de test, etc.), de la création de la documentation et du test de l’application dans un environnement de production. Cette dernière tâche est associée aux tests de non régression automatisés qu’un autre serveur peut opérer afin de soulager le serveur de build.

L’avantage est de pouvoir confronter très rapidement le nouveau code source de l’application à l’environnement de production. Les problèmes sont visibles immédiatement et une version de l’application est toujours disponible pour démonstration ou distribution.

Pour résumer

Les méthodes agiles peuvent apporter beaucoup à une équipe de maintenance logicielle. Même si le contexte est diffèrent du modèle projet (itérations inégales, perturbations plus importantes), il y a de bonnes choses à aller piocher parmi les pratiques agiles.

L’équipe est amenée à travailler sur plusieurs branches de développement en même temps: la mainline qui héberge le code de la prochaine release, la ou les branche(s) de maintenance de précédentes versions de l’application et les branches d’exploration dédiées aux évolutions complexes qui s’étalent sur plusieurs itérations. Les itérations courtes permettent de rythmer les développements et livraisons des versions de release et de maintenance.

Travailler en intégration continue permet à l’équipe de maintenance de se concentrer sur le développement puisque les bugs de production se raréfient. Elle peut aussi s’accorder du temps pour peaufiner ses tests de non régression automatisés.

Pour conclure, une équipe de maintenance à tout à gagner à basculer vers l’agile, notamment sur les aspects organisation, qualité et livraison.

J'ai été amené récemment à assister un Product Owner à préparer une réunion de priorisation de backlog (outre la personne en question, à la réunion y assistaient trois autres pour leur première priorisation de ce type). Deux façons se présentaient à nous: prioriser sur 100 points ou démarrer par une priorisation MoSCoW.

Pour rappel MoSCoW est un acronyme et permet de découper les priorités en 4 parties:

Must have: Priorité maximale pour un besoin ou une fonctionnalité absolument indispensable sans quoi le produit est inutile

Should have: La fonctionnalité a une très haute valeur ajoutée et doit absolument être incluse si le temps le permet. Cependant, si ce n'est pas le cas, on peut répondre au besoin d'une autre façon

Could have: Le petit plus Periglioni comme dirait Elie Semoun, le besoin n'est pas absolument nécessaire mais n'est pas négligeable car il peut permettre de faire la différence.

Won't have but Would have: La réponse à ce besoin est pour le moment hautement secondaire et ne doit pas passer avant le reste (la fonctionnalité n’est pas à développer dès la première itération).

Nous avons donc décidé de commencer par MoSCoW quitte à affiner avec la méthode des 100 points. Pourquoi ? Parce qu’il est difficile de prioriser d’autant plus lorsqu’on est nombreux. On limite le nombre de possibilités offertes. Au lieu d’avoir 100 possibilités, on en a 4 ce qui restreint les ardeurs des plus pointilleux d’entre nous.
Le but de la manœuvre est qu’une fois qu’on a fourni nos priorités sur 4, on peut définir des fourchettes sur 100.

La plupart du temps, en MoSCoW les hésitations se feront sur les combinaisons Must/Should ou Should/Could et Could/Would, peu de chance d’avoir une hésitation sur Must/Could (et sur une hésitation Must/Would… on ne sait jamais mais quand même…)

Quelles questions se poser lorsqu’on hésite entre deux priorités ?

Must/Should : Une des premières questions à se poser est « A quel point, le client a mis en avant cette fonctionnalité? », quel est le niveau d’importance pour le client.
Nous savons que la plupart du temps ce dernier mettra une grande partie des fonctionnalités au niveau d’importance le plus haut mais il est assez facile de dégager quel est le point névralgique, ce autour de quoi tourne le projet, si la fonctionnalité est au centre c’est bien sur un Must.
Si ce n’est pas le cas mais qu’un doute persiste, on peut se demander « est-ce que cette fonctionnalité peut être remplacée par une version plus légère dans un premier temps? ». Si la réponse est non c’est un Must, si oui un Could.
Le besoin du client peut être très précis et amener à des choses compliquées à développer. Ces éléments peuvent parfois être simplifiés dans un premier temps (pour un site de restauration, l’utilisation d’un google map interactif pour situer un lieu pourra être remplacé par une image dans un premier temps)

Should/Could : Plus difficile, il faut là savoir si ce besoin est primordial pour le business « que se passerait-il si on ne mettait ça pas en place ? ». S’il a été décidé que la fonctionnalité n’était définitivement pas un Must mais que le fait de ne pas la développer pourrait handicaper le chiffre d’affaire ou l’image du produit c’est que c’est un Should. Si par contre, ce développement permet une amélioration et que son « non-développement » n’est pas impactant, c’est que c’est un Could (ajouter un google map permet mieux situer un lieu en regardant l’espace alentour mais mettre une image avec l’adresse n’empêchera pas aux utilisateurs de trouver le lieu).

Could/Would : Comme l’a très bien posé le Product Owner durant la réunion « si on n’a pas le temps de tout faire, quel serait l’impact si on faisait ce développement par rapport à celui-là (précédemment priorisé en Could) ? ». La réponse a été vite vue, « Would » tous en cœur (en l’occurrence, le « Would » en question était un gadget graphique mais pouvait être estimé utile, d’où l’hésitation).

Il peut être assez simple de débloquer des situations avec les bonnes questions, le fait de n’avoir que 4 possibilités est aussi un atout pour accélérer les décisions.

Après ce découpage, la possibilité offerte est d'apposer aux 4 priorisations une fourchette sur la base 100.

Un exemple simple mais ensuite à vous de voir :

20 items en tout:

• Priorisation MoSCoW
  • 5 items en Must
  • 8 items en Should
  • 4 items en Could
  • 3 items en Would

• Découpage sur 100 points
  • Must => 75 à 100
  • Should => 50 à 75
  • Could => 25 à 50
  • Would => 0 à 25

On limite ainsi le champ des possibles, 5 items à répartir sur 25 points est plus rapide et moins imposant que de tout faire d’un coup sur 100

Petit bonus pour la détente (et mine de rien, bon moyen de ne pas oublier la méthode)
Dschinghis Khan - Moskau

J’ai été interrogé ce matin par une personne extérieure aux équipes Scrum, dans la mission sur laquelle j’interviens en ce moment. “Pourquoi est-ce que vous parlez de rugby et de mêlée : en rugby il y a deux équipes qui s’affrontent, ici on doit normalement collaborer”.

Petit cours d’histoire (c’est la minute pédante): à l’origine de Scrum il y a un article de deux universitaires japonais, Messieurs Takeuchi et Nonaka.

Dans ce papier (“The new new product development game”,  paru en 1986 dans la “Harvard Business Review”) les auteurs constatent que “les règles du développement d’un nouveau produit changent. De nombreuses entreprises ont découvert qu’il faut maintenant plus que les standards de qualité élevée, coûts bas et différenciation pour exceller dans le marché compétitif d’aujourd’hui. Il faut aussi de la flexibilité et de la vitesse. Plus...

Ça me trottait dans la tête depuis un moment et il fallait que je fasse un retour d’expérience et tant qu’à faire autant que ce soit la mienne… d’expérience.

Je suis actuellement en mission dans un grand groupe où la gestion de projet dite classique est profondément implantée, dans une équipe qui n’a pas été biberonnée au Scrum. Comment alors amener l’outil dans un tel environnement ? Pas simple…

Cet article sera découpé en plusieurs billets que je posterai régulièrement dans le déroulement de la mission.

D’abord décrivons l’équipe en question :

·         1 premier MOA peu intéressé par les méthodes agiles puis un 2^nd MOA très curieux des méthodos et prêt à tenter

·         1 MOE rôdé aux méthodes (normal il est de CLT !)

·         4 développeurs :

o   1 dev formé et déformé au Scrum, moi-même

o   1 autre non formé mais flexible donc bon candidat

o   1 dev non formé plutôt rôdé au cycle en V

o   1 dernier désirant une assignation totale de chaque tâche

Voilà une équipe bien disparate mais n’est-ce pas ce qui rend la chose intéressante ?

1^ère difficulté

Nous avons mis en place directement la totale, scrum board, burndown chart, post-it qui piquent les yeux, nous n’avons pas poussé le vice jusqu’à utiliser le planning poker mais pas loin. Notre première difficulté fût le refus de l’affichage du burndown chart aux passants.
Un trop de plein de transparence avait créé un malaise dans l’équipe de peur que la première réaction des managers voyant une courbe qui ne voulait décidément pas descendre fût cinglante. Selon moi, une bonne communication à l’intérieur de l’équipe et de façon montante permet d’éviter justement une mauvaise interprétation du burndown chart. Nous avons tout de même décidé de ne pas l'afficher.

2^nd difficulté

Difficile de créer un backlog quand le MOA ne semble pas convaincu par l’outil scrum ? Les nombreuses tentatives d’explication et d’implication n’ont pas suffi à lui faire changer d’avis, obligés de faire sans… Nous avons donc tenté de créer des sortes de backlogs virtuels (non pilotés par le client et le PO) qui volaient en éclat à chaque changement dans le planning.

Résume très bien l'agile dans notre environnement

Points positifs et ce qui a rapidement fonctionné

Dans tous ces obstacles, il faut bien voir les points positifs qui ont été amenés.

Tout d’abord et l’un des plus importants, le test unitaire provenant de l’extrême programming lui-même faisant partie des méthodes agiles. L’équipe est aujourd’hui totalement indépendante sur les tests. Chaque développement fait l’objet d’un ou plusieurs tests unitaires. Notre couverture de code a explosée.

De ce fait, nous avons mis rapidement en place l’intégration continue. Nous travaillons avec ClearCase pour le versioning, Hudson pour l’intégration continue. Chaque stream ClearCase possède sa chaîne d’intégration et sa base de données (les tests cependant, codés dans les règles de l’art ne laissent aucune donnée dans la base). Ce fonctionnement convient actuellement à tout le monde et a permis d’éviter bon nombre de bugs lors des phases de test voir de production.

Conclusion

Ce que je retiens de ces deux premières difficultés est qu’il faut faire très attention à ne pas arriver avec une gestion clef en main car les gens avec qui on travaille ne sont pas forcément sensibles à une méthode nouvelle. De même, vérifier que tout le monde est à l’aise avec les aspects de la méthode

Le Scrum est une méthode où toute partie doit adhérer du développeur au client ou tout du moins le MOA sous peine d’essuyer quelques plâtres.

Lorsque le Scrum Board explose et ne tiens pas la route, trouver une autre méthode de gestion des tâches et des sprints

Le 30 Mars dernier se tenait le premier “Scrum Day” organisé, chez Microsoft, par le French Scrum User Group sous l’égide de Xavier Warzee, son président.

La vidéo du micro trottoir  vient d’être publiée : http://www.facebook.com/video/video.php?v=10150198547436366

Agile France est un évènement attendu par la communauté agile, le programme des conférences a été publié il y a quelques jours. Vous pouvez le consulter ici. L’Agile France se déroulera les 26 et 27 mai prochains à la porte Jaune à Vincennes

Cette année encore des conférences qui semblent prometteuses !Plus...

Voici le second billet issu de la réunion de notre groupe de travail sur l’évangélisation de Scrum, et plus particulièrement sur les réponses possibles à apporter aux objections couramment  levées contre la pratique de Scrum.

Aujourd’hui nous allons vous proposer quelques réponses/remarques possibles pour répondre à un interlocuteur qui vous dirait : “Scrum, c’est trop de réunions!”. Derrière cette objection se cache en réalité bien souvent l'idée que la réunion représente une perte de temps et/ou de productivité. 

Répondre objectivement à une telle objection n’est pas, de prime abord, simple. Nous ne pouvons en effet nier que la pratique de Scrum engendre un certain nombre de réunions, et que ces dernières mobilisent toute l’équipe. Nous allons donc recenser quelles sont ces réunions et présenter quelques un de leurs intérêts à la fois pour l’équipe et pour le client.Plus...

L'association DotNetHub, a décidé de mettre en place un grand évènement agile francophone.L'objectif est simple : Offrir aux spectateurs, en Belgique, et en français, une série de conférences et d'ateliers sur le thème de l'agilité. J’y animerai une session sur les bonnes et mauvaises pratiques du Daily meeting.

L’intégralité du programme est disponible ici.

Encore une bonne occasion d’échanger autour des pratiques agiles !

Une fois encore le French Scrum User Group nous a préparé un programme très attrayant avec de nombreux speaker de qualité pour cette nouvelle session dédiée à Scrum et à l’agilité ! Vous pouvez consulter le programme de la journée ici.

Damien Thouvenin animera à la fin de cette journée, une table ronde sur le thème ‘Manager d’une équipe agile’.

CLT Services est heureux de soutenir cette édition en tant que sponsor platinium

Vous pourrez également nous retrouver sur notre stand où nous serons ravis d’échanger autour de vos problématiques. A cette occasion nous lancerons également  un jeu concours pour gagner une formation ‘Réussir et s’affirmer  dans son rôle de Scrum Master’.

Pour assister à cet événement, il vous suffit de vous inscrire ici.

Nous vous proposons une série de billets, issus d'ateliers menés auprès de collègues et d'amis, et dont le but est de proposer des réponses simples à un certain nombre de critiques et lieux communs que vous pouvez régulièrement entendre ou avoir vécu lorsque vous souhaitez parler de Scrum.

Voici le premier de cette série de billets. Il vous propose quelques réponses à apporter à quelqu'un qui vous dit : "Scrum c'est pas sérieux". Les éléments de réponse ci-dessus ne constituent en rien une liste exhaustive et ne sont pas nécessairement purement objectives.

Vous qui pratiquez le Scrum, n'avez vous jamais eu affaire à une personne quelque peu critique voire moqueuse sur la méthode?

• Tout d'abord en réponse à une remarque du type "Scrum c'est pas sérieux" il est important de savoir si la personne en face de vous a déjà eu l'occasion de pratiquer Scrum et/ou si elle s'est déjà renseignée un minimum. Nous partirons du postulat de base que notre interlocuteur connait un minimum la méthode.

• Une de ces premières objections pourrait être : "Je ne comprends pas pourquoi vous faites du Scrum, personne n'en fait" insinuant que le Scrum est une méthode ou une pseudo-méthode applicable sur certains types de projets bien particuliers et qu'elle ne peut être appliquée partout et à tous. Votre réponse peut se résumer en citant quelques références dans le monde informatique: Google, Microsoft, Yahoo, Adobe, Nokia... (n'hésitez pas à en rajouter si vous en avez sous la main). De grands noms de l'informatique ont effectué une transition vers l'agilité et utilisent Scrum.

• Face au Scrum board et à tous ses post-its multicolores, ses cases et le burn down chart, il n'est pas rare d'en voir certain se poser des questions ou encore de vous faire remarquer que "vous avez un peu trop de rose et pas assez de bleu". Pourquoi des post-it? Parce que c'est visuel et clair et que le côté physique du tableau et du papier humanise la méthode.
  
  De même le fait que les membres de l'équipe déplacent les tâches à la vue de tous, offre plus de transparence, un suivi clair et partagé par l'équipe à tout moment et donc une meilleure communication.
  Par expérience, nous nous sommes aperçu que le daily meeting derrière un écran n'offrait pas la même visibilité qu'un grand tableau.
  
  De plus cela rend la méthode ludique. Qui a dit que l'on devait forcément s'ennuyer au travail ?

• "Ce sont les développeurs qui chiffrent? Pas la MOA ou le commercial?" ou bien "Vous laissez les développeurs chiffrer? Mais ils vont vous multiplier par trois ou quatre les coûts!" Ce type d'affirmation sera d'ailleurs bien souvent prononcé par la MOA ou le commercial ou encore le client.
  Le développeur reste tout de même la personne la plus apte à estimer le coût de son propre travail.
  
  De plus, il n'y a pas que les développeurs qui chiffrent, tout le monde peut participer à la réunion de planning permettant ainsi un consensus et de la discussion autour d'une tâche. L'estimation n'en sortira que plus réaliste et transparente pour tout le monde.
  
  Le planning effectué par les développeurs peut créer un cercle vertueux entre les notions de responsabilisation de l'équipe, d'engagement et de prises de responsabilité sur les tâches à effectuer.

Merci à toutes les personnes qui ont permis de constituer cet ensemble de réponses

Flash news: ma collègue Céline a été retenue comme speaker (speakeuse ?) pour la journée Agile 2011, le 7 avril à Bruxelles.

Tout le programme ici: http://www.journeeagile.be/page/Programme.aspx#dailymeeting

Deuxième numéro de ma revue du web Agile, avec un focus sur le test et la gestion d’exigence et une nouvelle rubrique (outils). Je signale également que le dernier numéro (2010-4) de la revue Methods & Tools est sorti : http://www.methodsandtools.com/PDF/mt201004.pdf; à noter, entre autres, un article sur “Non-Functional Requirements: Do User Stories Really Help?”

Agenda

• Petit rappel. Le ScrumDay Paris a lieu le 31 mars. Si vous voulez proposer des sujets, la deadline c’est le 25 février. http://www.scrumday.fr
• Agile 2011: L’Agile Alliance a annoncé sa conférence annuelle ; dix ans après la publication du manifeste Agile c’est “back where it all began” à Salt Lake City au mois d’Aout prochain: http://agile2011.agilealliance.org/

Pratiques

• Je suis tombé cette semaine sur un blog intéressant “thoughts from the test eye” alimenté par une équipe Q&A Plus...

Je démarre aujourd’hui une série dans laquelle je signale les articles, billets, tweets et autres publications relevées sur nos sujets préférés: Lean, Agile, Scrum… etc.

Cette semaine j’ai noté – entre autres – une réunion à Lyon sur le Lean, deux billets sur Scrum appliqué au marketing et une pres sur l’analyse Agile. Bonnes lectures. Plus...

L’équipe a récemment changé l’organisation des sprints afin de rendre le rythme plus soutenable et devenir plus productive. Voici un retour sur la mise en place de cette nouvelle organisation:  les problèmes rencontrés, les changements et les résultats concrets obtenus Plus...

Depuis quelques semaines, L’équipe interne s’est lancée dans une nouvelle expérimentation : Faire les revues directement avec les clients au lieu de les faire avec le PO délégué. La revue consiste à faire une démonstration de ce qui a été réalisé pendant le sprint et à démontrer que les fonctionnalités sont conformes aux ‘how to demo’ définis en début de sprint lors du sprint planning. Plus...

J’avais posté il y a quelques temps la vidéo de ma conférence à l’Agile Tour de Lille sur notre façon de prendre en compte les bugs dans Scrum.

Un billet de Nicolas Lemay (Pixys, Canada) raconte les réflexions similaires de leur équipe sur le même sujet. Complémentaire et intéressant.

http://nicholaslemay.blogspot.com/2010/12/finally-solution-for-bug-free-backlog.html

(Jolie illustration en plus !)

Le Centre des Jeunes Dirigeants (CJD) est une organisation patronale créée en 1938 qui regroupe plus de 4000 chefs d’entreprises et dirigeants.

Pour plus d’information, voir http://www.jeunesdirigeants.fr/

Le CJD souhaite se doter d’un outil informatique afin de créer du lien et de la proximité entre les 111 sections locales.

Le CJD a interrogé ses adhérents et constitué une cartographie hiérarchisée des besoins mais souhaite s’appuyer sur le savoir-faire des prestataires pour identifier les solutions les plus pertinentes pour répondre à ces besoins (logiciels « sur étagère », intégration d’outils multiples, développement sur mesure…etc.) Plus...

Samedi dernier je suis allé chercher un recommandé pour CLT-Services dans mon bureau de poste; j’arrive à midi alors que la Poste ferme à 12h30 mais je suis confiant car j’ai une carte Pro qui donne accès à un guichet prioritaire. Las, le guichet pro est fermé le samedi et la file d’attente s’étend à travers toute le hall qui est pourtant immense. J’interpelle un postier et il m’explique que cette nouvelle organisation est impressionnante mais rapide et que ça ne prendra “pas plus de 10 minutes”.

Je prends donc mon tour dans l’immense serpentin et me prépare mentalement à râler sur mon blog à propos de La Poste qui a le culot de diffuser sur ses écrans des publicités “gagnez du temps avec la carte pro” tout en me faisant faire la queue pendant des heures.

En fait, c’est bien mon postier qui avait raison ; 12 minutes plus tard me voici servi. D’ailleurs le postier m’a reconnu, s’est enquis de mon temps d’attente et s’est excusé pour les 2 minutes de débord. Apparemment j’étais arrivé à la pire heure de la matinée, juste avant la fermeture. J’en ai profité pour lui demander si l’amélioration était patente par rapport à l’ancienne organisation. “Vous auriez attendu plus d’une heure et demie” me répondit-il.

Alors, quelle est l’explication de cette progression fulgurante ?

Le Lean.  Plus...