C'est le thème des "Présentations à la carte" proposée par Valtech Toulouse le 3 février prochain :
"3 Février 2009 - Présentations à la Carte - Toulouse
A vous de choisir.Et d'ici là, Joyeux Noël à toutes et à tous.
Rencontrons nous autour d'un sujet que vous choisissez!
Et d'ici là, Joyeux Noël à toutes et à tous.
La nouvelle "done"
L’article de Clinton Keith, « Beyond Scrum : Lean and Kaban for Game Developpers » explique pourquoi beaucoup d’équipes abandonnent les pratiques Scrum en fin de projet et reviennent à méthodes plus traditionnelles.
Il en explique d’abord les raisons, et propose ensuite une alternative en utilisant Lean Production et Kaban.
Article très intéressant et largement détaillé pour bien comprendre le contexte, le problème et la solution.
Le contexte est le développement de jeux, avec des contraintes de phases que nous n’avons pas dans les autres types de développement logiciel.
La notion de « done »
Un élément primordial de l’agilité (Scrum en l’occurrence) est la notion de « done ».
C’est en quelque sorte la définition de « comment considère-ton le travail fini ».
Elle doit être définie avant de démarrer une activité et être partagée et agrée par tous les intervenants.
C’est une hypothèse et en même temps un indicateur. Hypothèse pour les estimations, indicateur pour le suivi d’avancement.
En Scrum, l’équipe va estimer une tâche en fonction du done défini. De cette façon, et en fonction de la vélocité de l’équipe, on aura la liste des tâches qui sont envisagées à produire le temps d’une itération. Envisagée, donc pas sur d’y arriver.
La notion de « done »
Un élément primordial de l’agilité (Scrum en l’occurrence) est la notion de « done ».
C’est en quelque sorte la définition de « comment considère-ton le travail fini ».
Elle doit être définie avant de démarrer une activité et être partagée et agrée par tous les intervenants.
C’est une hypothèse et en même temps un indicateur. Hypothèse pour les estimations, indicateur pour le suivi d’avancement.
En Scrum, l’équipe va estimer une tâche en fonction du done défini. De cette façon, et en fonction de la vélocité de l’équipe, on aura la liste des tâches qui sont envisagées à produire le temps d’une itération. Envisagée, donc pas sur d’y arriver.
Même si Scrum est construit sur un enchainement d’itérations « time-boxées », la vélocité et la productivité des équipes peut entrainer une augmentation du nombre d’itérations afin de finir le produit demandé. C’est ce qui pause problème d’ailleurs dans nos modes de fonctionnement au forfait.
Dans le contexte du développement de jeux, la contrainte de deadline semble, aux vues de l’article, incontournable. La date de livraison du produit fini ne changera pas.
Dans ce cas, l’auteur remet en cause non pas la notion de done, mais la façon de la définir.
Le time boxing
Dans le chapitre Time-Boxing, l’auteur précise que ce n’est plus la notion de done qui entraîne l’estimation, mais l’estimation qui conditionne le done.
Dans le contexte du développement de jeux, la contrainte de deadline semble, aux vues de l’article, incontournable. La date de livraison du produit fini ne changera pas.
Dans ce cas, l’auteur remet en cause non pas la notion de done, mais la façon de la définir.
Le time boxing
Dans le chapitre Time-Boxing, l’auteur précise que ce n’est plus la notion de done qui entraîne l’estimation, mais l’estimation qui conditionne le done.
“We start time-boxing each stage of the value stream. For example, we might give the audio designers 10 days to add audio to a specific zone. This is different from tasks in Scrum where the audio designer would estimate their own work and tell the customers what they are willing to commit to”
…
“The input is the time-box (which is the cost we are willing to pay for the asset). The output is quality that the artist is able to provide within the constraint of time.”
…
“The input is the time-box (which is the cost we are willing to pay for the asset). The output is quality that the artist is able to provide within the constraint of time.”
C’est un changement assez radical dans le comportement d’une équipe Agile, mais qui finalement ne semble pas si incohérent et qui pourrait être une piste d’aménagement dans un projet au forfait. Pourquoi,
Parce qu’un forfait c’est un contenu fixe à une date fixe et un prix fixe.
Parce que je constate encore que pas mal de gens n’arrivent pas à faire des estimations. Du fait que cela les engagent, cela les effraie. Bien que je sois fortement favorable à cette façon d’impliquer tous les acteurs, au sens propre, d’un projet.
Parce que la notion de done, n’est jamais clairement définie dans les appels d’offre de nos clients. On le sait bien, ils veulent « tout ».
Enfin parce qu’un projet au forfait empêche la transparence et de ce fait, le client n’a souvent pas la vision détaillée de toutes les tâches nécessaires à accomplir pour atteindre cette notion de done et au final ne comprend pas les estimations que l’on lui donne. (tiens pour une fois j’ai mis 2 n ;-) )
De toute façon, comme toute adaptation, il faut l’évaluer avant de l’adopter ou la rejeter en fonction des contraintes de chaque projet.
AgileWashing
A l‘instar de l’EcoWashing, la capacité marketing d’une entreprise de laver son image en étiquetant ces produits « Eco ».
Genre les Renault Eco2, y a rien d’écolo dans une voiture ????
Claude Aubry a fait un remarquable encart dans 01Info où il évoque « l’opportunisme des grandes SSII » à l’égard de l’agilité.
Faudrait-il instaurer une sorte de charte, de label, de certification Agile ?
Je n’y crois pas.
Pas plus qu’un estampillage ISO prouve que l’on fait de la qualité.
Mais dans ce cas, comment feront les décideurs dans 1 ou 2 ans, lorsque tout le monde dira faire de l’Agilité ? Si c’est vrai tant mieux, cela prouvera que ce n’est pas qu’une mode.
Mais encore une fois, le mode contractuel au forfait cher à nos clients mais aussi aux SSII aura du mal à laisser place à une vrai souplesse opérationnelle prônait par l’Agilité.
Il y a encore du chemin à faire, mais on va les aider ;-)
Genre les Renault Eco2, y a rien d’écolo dans une voiture ????
Claude Aubry a fait un remarquable encart dans 01Info où il évoque « l’opportunisme des grandes SSII » à l’égard de l’agilité.
Faudrait-il instaurer une sorte de charte, de label, de certification Agile ?
Je n’y crois pas.
Pas plus qu’un estampillage ISO prouve que l’on fait de la qualité.
Mais dans ce cas, comment feront les décideurs dans 1 ou 2 ans, lorsque tout le monde dira faire de l’Agilité ? Si c’est vrai tant mieux, cela prouvera que ce n’est pas qu’une mode.
Mais encore une fois, le mode contractuel au forfait cher à nos clients mais aussi aux SSII aura du mal à laisser place à une vrai souplesse opérationnelle prônait par l’Agilité.
Il y a encore du chemin à faire, mais on va les aider ;-)
Google App va supporter Java,... pas si sûr
La blogosphère réagit vite aux annonces.
Didier Girard sur Application-servers relaie la rumeur d'une annonce par Google du support de Java dans son App Engine :
ici Google App Engine to Support Java
et là :Java support to Appengine to counter Microsoft’s cloud initiatives, Microsoft Strata?
Et l’origine est ici:
Google Developer Day Bangalore: Google App Engine to support Java, Android SDK release on Oct 22
relayant les propos de Prasad Ram, speaker à la conférence Google Developpers Day qui a eu lieu à Bangalore le 18 oct. et Directeur Google R&D à Bangalore
Quant à Google lui même, c'est moins clair :
Paul McDonnald, Google App Engine Product Manager d'écrire :
"While we don't have any immediate plans or announcements, we are working on other languages for App Engine" (thread complet)
Est-ce le "will now support" qui porte à confusion? will c'est futur, now c'est maintenant, donc c’est quand ?
Qui a raison donc?
En tout cas, on attend avec impatience ;-)
Agile Tour Toulouse
J’étais hier à l’Agile Tour pour son passage dans la ville rose.
Hormis une entrée en matière un peu difficile sur le manifeste agile (Parler devant 200 personnes n’est pas chose facile), nous avons eu un séminaire de grande qualité.
- Claude Aubry nous a emmenés faire un voyage dans le temps aux sources de Scrum. En présentant et commentant avec les arguments qui vont bien, le premier article de Ken Shwaber datant du siècle dernier introduisant le « Process Scrum ». Merveilleuse allocution recentrant sur les basiques (CMM, process, non prédictible) et teinté de quelques pointes ironiques.
- L’agilité en situation : Une approche construite et détaillée sur l’applicabilité des méthodes agiles nous a été présentée par Philippe Kruchten et Claude Aubry. Je dis présentée, mais il s’agissait plutôt d’une orchestration rondement menée entre ces deux moteurs de l’agilité, tant le discours était fluide et le dialogue intelligent. « Respect messieurs » ! Je vais faire un graphe de Kiviat sur nos projets existants, juste pour voir.
- Ensuite j’ai assisté à un atelier sur les « senteurs agiles ». En s’inspirant des codes smells et du planning poker, Thomas Lissajoux nous a présenté une façon originale d’effectuer une rétrospective. Une sorte de checklist sous forme de carte à jouer des « odeurs » susceptibles de poser problème dans un projet. Idée à retenir et à continuer d’instruire.
- Enfin, une présentation qui m’a ravi au plus haut point, qui redonne gout à la vie (informatique), qui me pousse à croire que tout n’est pas fini, qu’un jour on pourra sortir du forfait lorsque nos clients (au sens large) auront compris l’intérêt de ce type d’organisation, où les actions de la gouvernance et la production seront jointes vers un même objectif, le produit et sa valeur ajoutée.
Merci donc à Igeoss au travers de M. Desmarrest.
Encore un grand merci à l’organisation dans son ensemble et à chacun des orateurs en particuliers pour la qualité de cet évènement.
A force, ça va bien finir par rentrer ;-)
Hormis une entrée en matière un peu difficile sur le manifeste agile (Parler devant 200 personnes n’est pas chose facile), nous avons eu un séminaire de grande qualité.
- Claude Aubry nous a emmenés faire un voyage dans le temps aux sources de Scrum. En présentant et commentant avec les arguments qui vont bien, le premier article de Ken Shwaber datant du siècle dernier introduisant le « Process Scrum ». Merveilleuse allocution recentrant sur les basiques (CMM, process, non prédictible) et teinté de quelques pointes ironiques.
- L’agilité en situation : Une approche construite et détaillée sur l’applicabilité des méthodes agiles nous a été présentée par Philippe Kruchten et Claude Aubry. Je dis présentée, mais il s’agissait plutôt d’une orchestration rondement menée entre ces deux moteurs de l’agilité, tant le discours était fluide et le dialogue intelligent. « Respect messieurs » ! Je vais faire un graphe de Kiviat sur nos projets existants, juste pour voir.
- Ensuite j’ai assisté à un atelier sur les « senteurs agiles ». En s’inspirant des codes smells et du planning poker, Thomas Lissajoux nous a présenté une façon originale d’effectuer une rétrospective. Une sorte de checklist sous forme de carte à jouer des « odeurs » susceptibles de poser problème dans un projet. Idée à retenir et à continuer d’instruire.
- Enfin, une présentation qui m’a ravi au plus haut point, qui redonne gout à la vie (informatique), qui me pousse à croire que tout n’est pas fini, qu’un jour on pourra sortir du forfait lorsque nos clients (au sens large) auront compris l’intérêt de ce type d’organisation, où les actions de la gouvernance et la production seront jointes vers un même objectif, le produit et sa valeur ajoutée.
Merci donc à Igeoss au travers de M. Desmarrest.
Encore un grand merci à l’organisation dans son ensemble et à chacun des orateurs en particuliers pour la qualité de cet évènement.
A force, ça va bien finir par rentrer ;-)
Le burndown est mort, vive le burndown
Je constate depuis peu de temps une dérive dans l’application de Scrum dans le contexte des projets Franco-Français.
Est-ce un point de non retour sur l’acceptation par les équipes de développement de la méthode. De nombreux retours d’expérience vont dans ce sens où la non adhésion complète des principes remettait en cause le résultat de cette méthode.
Dans un séminaire Agile, Greg Hutchings avait évoqué les patterns/anti patterns de l’agilité, le premier anti pattern étant de ne pas appliquer complètement la méthode, mais par petit bout.
Le post de Claude Aubry remet en cause le burndwon au profit d’un suivi des tâches par état.
Pourquoi remettre en question les bases de Scrum et délaisser le burndown au profit d’un suivi par état. Le suivi par état en plus du burndown, je suis d’accord, mais pas en remplacement.
Scrum est basé (comme beaucoup) sur la notion de charge : estimée, produite, consommée, restante à faire,… en d’autres termes de productivité.
Est-ce un point de non retour sur l’acceptation par les équipes de développement de la méthode. De nombreux retours d’expérience vont dans ce sens où la non adhésion complète des principes remettait en cause le résultat de cette méthode.
Dans un séminaire Agile, Greg Hutchings avait évoqué les patterns/anti patterns de l’agilité, le premier anti pattern étant de ne pas appliquer complètement la méthode, mais par petit bout.
Le post de Claude Aubry remet en cause le burndwon au profit d’un suivi des tâches par état.
Pourquoi remettre en question les bases de Scrum et délaisser le burndown au profit d’un suivi par état. Le suivi par état en plus du burndown, je suis d’accord, mais pas en remplacement.
Scrum est basé (comme beaucoup) sur la notion de charge : estimée, produite, consommée, restante à faire,… en d’autres termes de productivité.
- Xébia rappelle que « Scrum a été conçu pour atteindre une productivité de 5 à 10 fois supérieure… »,
- Une itération en Scrum s’appelle un sprint, ce n’est pas pour rien.
Je préfère l’approche « complément » présentée par Mike Cohn. qui propose des solutions visuelles améliorant la lisibilité du burndwon par adjonction d’information sur la priorité, ou celle présentant le backlog produit avec une Treemap, une présentation surfacique relative aux poids de chaque user story.
Mais dans les deux cas, Mike garde la notion de charge : poids, estimation, reste à faire.
Je sais qu’il est difficile dans notre contexte très dirigé par les contrats au forfait de parler de charge. C’est quand même la base d’une gestion de projet, sans parler de leur conversion en euros.
Que l’on parle de jours, d’heures, ou de points (de toute façon représentation relative d’un temps), je ne vois pas comment suivre efficacement un projet sans se préoccuper du reste à faire, du consommé.
J’ai trouvé dans Scrum une manière particulière et innovante d’intéresser les développeurs à ce qu’ils font, par le fait des les responsabiliser. Non pas pour les culpabiliser, mais les rendre responsable au sens propre du terme.
Se passer du burndown et donc de ses données intrinsèques me parait un risque majeur sur la compréhension et l’adhésion des équipes, voir des clients à la méthodologie Scrum.
Google : Le Monde comme Product Owner
Je continue de mettre au point (pour ne pas dire débugger) le connecteur Mylyn Scrum Vision pour Google SpreadSheet.
Pour cela j’utilise l’API GData de google. Il m’est arrivé de poster une question sur le groupe Google dédié à cette API. Une des réponses fut « ce n’est pas encore implémenté, mais vous pouvez voter pour la fonctionnalité correspondante ».
J’ai donc pu influencer (certe qu’un peu) sur la priorisation du backlog de l’API GData.
Bien que le principe ne soit pas nouveau, certains projets sourceforge l’utilisent déjà, ça m’a simplement fait penser que le Monde entier est Product Owner chez Google.
On peut voir la liste des fonctionnalités triée par vote pour savoir si l’on a une chance d’avoir la fonction disponible une de ces jours. GData-issues
Y a même une vue grid. (qui me fait penser à Ice Scrum ! )
Malheureusement, pour l’instant je n’ai pas vue le burndown ;-)
Pour cela j’utilise l’API GData de google. Il m’est arrivé de poster une question sur le groupe Google dédié à cette API. Une des réponses fut « ce n’est pas encore implémenté, mais vous pouvez voter pour la fonctionnalité correspondante ».
J’ai donc pu influencer (certe qu’un peu) sur la priorisation du backlog de l’API GData.
Bien que le principe ne soit pas nouveau, certains projets sourceforge l’utilisent déjà, ça m’a simplement fait penser que le Monde entier est Product Owner chez Google.
On peut voir la liste des fonctionnalités triée par vote pour savoir si l’on a une chance d’avoir la fonction disponible une de ces jours. GData-issues
Y a même une vue grid. (qui me fait penser à Ice Scrum ! )
Malheureusement, pour l’instant je n’ai pas vue le burndown ;-)
Inscription à :
Articles (Atom)
