Je vous invite tous à consommer sans modération les billets publiés régulièrement sur le site Ça Scrum !... rafraîchissants et énergisants.
Tag - Humeur
lundi, 23 mai 2011
Ca Scrum ! A consommer sans modération !
Par Fabrice le lundi, 23 mai 2011, 23:37 - Inclassables
vendredi, 20 mai 2011
Il est difficile de faire comprendre quelque chose à un homme...
Par Fabrice le vendredi, 20 mai 2011, 08:30 - Citations
Il est difficile de faire comprendre quelque chose à un homme lorsque son salaire dépend précisément du fait qu'il ne la comprenne pas
Upton Sinclair - Prononcée au début du siècle passé. Toujours d'actualité.
samedi, 12 mars 2011
On vend plus cher un mauvais chef de projet...
Par Fabrice le samedi, 12 mars 2011, 17:54 - Citations
On vend plus cher un mauvais chef de projet qu’un bon développeur avec de l’expérience.
Source : "Peut-on réussir un forfait ?" de Samuel Liard.
jeudi, 30 décembre 2010
Agilité et Aspirine
Par Fabrice le jeudi, 30 décembre 2010, 07:00 - Inclassables
Ce n'est pas facile en ce moment. Je travaille sur l'élaboration d'un Backlog Produit avec le client, mais dans l'idéal ça aurait dû être fait il y a plusieurs mois au démarrage du projet. Personnellement, je m'heurte aux classiques (mais douloureux) problèmes suivants :
- la granularité des fonctionnalités : elle exige de descendre au niveau de la user story (pour les fonctionnalités importantes) mais le client ne comprend pas pourquoi il doit encore reformuler sous une autre forme (historique documentaire du projet) et pourquoi il ne pourrait pas le faire dans le cadre des ateliers de spécifications déjà lancés et planifiés...
- la multiplicité des acteurs : mes collègues sont responsables de certains ateliers fonctionnels et/ou techniques ; ils n'ont pas forcément connaissance de l'Agilité et encore moins du Backlog Produit qui apparaît par conséquent comme un n-ième document de travail... alors que ce doit être le document maître !
- la définition des critères de priorisation : le client a plus de facilité à estimer une priorité qu'à associer une valeur métier et je commence franchement à m'y perdre : est-ce que le niveau de priorité estimée par le client peut finalement correspondre à sa perception de la valeur métier ? est-ce que que le niveau de risque estimé par le fournisseur peut finalement correspondre à sa perception de l'effort ? je commence déjà à tordre le modèle (tiens ça me fait penser à la présentation "Agilité sous contraintes" de David Brocard).
- la localisation des équipes : pour l'instant, les équipes se trouvent toutes sur le plateau du projet chez le client, mais ça ne va pas durer... la situation cible c'est que les équipes de développement réintègrent rapidement leurs villes d'origine (j'ai de la chance, ça reste en France) selon le fameux modèle Front/Back : un Front Office "fort" à proximité du client pour recueillir, qualifier, spécifier le besoin et le support à la recette (bon ben autant dire le haut du cycle en V), des Back Office "réactifs" à distance du client pour la conception, le développement, les tests et l'intégration (bon ben autant dire le bas du cycle en V).
J'ai un peu mal à la tête là, je vais aller prendre une aspirine 
N'hésitez pas à me laisser un commentaire (prière de ne pas tirer sur l'ambulance).
vendredi, 17 décembre 2010
Tableau avec des tâches, voilà :-(
Par Fabrice le vendredi, 17 décembre 2010, 21:28 - Inclassables
Je suis récemment tombé sur le taskboard suivant d'un projet dit "agile".
On trouve le temps sur l'axe horizontal, le trigramme du développeur sur l'axe vertical, la tâche affectée à l'intersection.
Ne cherchez pas la story...
Avez-vous des remarques ? Oui ? Laissez-moi un commentaire.
vendredi, 26 novembre 2010
Fin de mission
Par Fabrice le vendredi, 26 novembre 2010, 19:44 - Inclassables
Aujourd'hui, nous avons officiellement fêté ma fin de mission (18 mois) avec un repas collégiale et une corbeille bien pourvue : quelques terrines, un beau verre et un superbe Miyagikyo 12 ans !
J'en profite donc pour remercier plus particulièrement le plateau du projet : Hélène (la tête pensante), Laurence (ou pas), Marie-Christine (la douce), Fabrice (2h58!), François (118...), Frédéric (le gourmet), Frédéric (euhhhhhhhhhh), Gary (le nouveau marié), Nadir (chouchou), Nathalie (c'est pas passé loin), Paco (el Mejor de los 4), Teddy (...218), Thierry (l'hippopotame)... et tous les autres. Une belle page qui se tourne.
dimanche, 21 novembre 2010
La Vision du Produit
Par Fabrice le dimanche, 21 novembre 2010, 15:43 - Lecture
Vous posez des questions autour de vous sur le projet en cours... on vous montre des slides intéressants mais obsolètes, des cahiers dé(s )charges ou des spécifications de plusieurs centaines de page, mais personne pour vous donner les enjeux du client et du projet... ou en tout cas pas de façon claire et unanime. Beaucoup de réunionite et peu de visionite 
Et hop, j'en ai profité pour traduire ce billet intéressant de Roman Pichler : "The Product Vision".
Le Nord du Nord
Avez-vous déjà travaillé sur un projet Scrum, où l'objectif global n'était pas clair ? où vous disposiez d'un backlog du produit, mais où les personnes impliquées dans l'effort de développement ne comprenaient que vaguement le but de la release ? Cela arrive plus souvent qu'on le souhaiterait, même sur des projets de plusieurs millions d'euros ! Souvent, on interprète à tort l'idée que Scrum se concentre sur le fait de "terminer le travail" et donc qu'il s'agit d'une course au développement sans avoir préalablement suffisamment réfléchi à l'endroit où le projet devrait aller. Ne faites pas cette erreur. Tout projet Scrum a besoin d'une vision produit pour montrer la vraie direction du projet "le nord du nord", orienter et guider l'équipe Scrum. C'est l'objectif primordial que tout le monde doit partager : le Product Owner, le ScrumMaster, l'équipe, le management, les clients et les autres intervenants. Comme Ken Schwaber l'a dit : "Le plan minimum nécessaire pour démarrer un projet Scrum contient une vision et un backlog de produit. La vision explique pourquoi le projet est en cours et quel est l'état final recherché." (1)
Cinq questions
"La vision, c'est l'art de voir les choses invisibles", a noté l'écrivain anglais Jonathan Swift. La vision du produit dépeint une image de l'avenir qui attire les gens. Elle décrit qui sont les clients, ce dont les clients ont besoin, et comment ces besoins seront satisfaits. Elle saisit l'essence même du produit : les informations essentielles/critiques que nous devons connaître pour élaborer et lancer un produit gagnant. Développer une efficace vision du produit implique de bien répondre aux questions suivantes :
1. Qui va acheter le produit ? Quelle est la clientèle ciblée ?
2. A quels besoins du client le produit répond-il ?
3. Quelles caractéristiques du produit sont essentielles pour satisfaire les besoins identifiés, et donc pour le succès du produit ?
4. Comment se compare le produit aux autres produits existants, vis-à-vis des concurrents et dans l'entreprise même ? Quels sont les points de vente du produit ?
5. Quels sont le calendrier et le budget cibles pour développer et lancer le produit ?
Répondre à ces cinq questions nous donne aussi les informations nécessaires pour analyser la rentabilité. Cela nous permet de décider si et comment le projet devrait se poursuivre.
Créer la Vision du Produit
Puisque le Product Owner est responsable de la réussite du produit et du retour sur investissement (ROI), il ou elle devra diriger les activités de création de cette vision grâce à une collaboration étroite avec l'équipe (2). Pour les projets innovants, cette équipe peut inclure des profils métier et techniques; par exemple, des gens du marketing, des concepteurs du produit et des interfaces utilisateurs ainsi que des développeurs. Plus le produit est innovant et complexe, plus la vision est importante, et plus les efforts nécessaires seront importants pour la créer. Pour des projets de développement de nouveaux produits et des versions majeures de produits, des études de marché et des activités de prototypage sont généralement menées. Comme cela peut prendre plusieurs semaines voire plusieurs mois pour compiler les informations pertinentes, exécuter un ou plusieurs sprints est la meilleure façon d'effectuer le boulot nécessaire. Comparez cela avec la version mineure d'un produit où la création de la vision concernée ne prendra que quelques heures ou quelques jours.
Le cœur de la Vision du Produit
Au cœur de la vision du produit, on trouve la description des besoins clients identifiés et les caractéristiques nécessaires du produit qui y répondent. Pour atteindre ce niveau de vision, nous avons d'abord sélectionner notre clientèle cible, puis les besoins pertinents pour ces clients, décidant ainsi quel marché ou segment de marché nous allons aborder. Puis, nous identifions les caractéristiques du produit - autrement dit les exigences critiques de haut niveau - que le produit devra remplir pour satisfaire ces besoins.
Les caractéristiques du produit comprennent généralement à la fois des exigences fonctionnelles et non fonctionnelles. Les exigences non fonctionnelles incluent des exigences de performance, de robustesse et de facilité d'utilisation. Les exigences fonctionnelles décrivent des fonctionnalités particulières du produit, par exemple effectuer un appel ou envoyer un email. Les caractéristiques du produit servent de guide pour l'équipe, elles limitent le périmètre de solution, l'ensemble des solutions possibles.
Décrire les caractéristiques du produit au bon niveau de détail est un équilibre qui exige une collaboration étroite entre le Product Owner et l'équipe. Sous-spécifier ces caractéristiques peut produire une direction floue. Sur-spécifier les caractéristiques du produit peut se traduire par une prise de décision plus tôt que nécessaire et des répercussions négatives sur la créativité de l'équipe. Les techniques utiles pour décrire les caractéristiques du produit comprennent des personas, des scénarios, des cas d'utilisation et des user stories.
Qualités souhaitables
Comme tout objectif important, une bonne vision recours également à notre intelligence et nos émotions. Il convient de motiver et d'inspirer les gens. La vision du produit doit être claire et stable, globale et mobilisatrice, concise et pure.
Claire et stable
La vision du produit doit être claire et facile à comprendre pour s'aligner sur un but commun, et pour éviter toute mauvaise interprétation et de la confusion (3)(2). Le terme anglais "vision" est dérivé du latin "visio", qui se traduit par "voir, vue, notion, idée". La vision du produit devrait donc nous permettre de voir le futur produit. La vision ne doit pas être floue ou troublée.
Des changements dans la vision, en particulier en ce qui concerne les besoins des clients et les caractéristiques essentielles, peuvent causer de la confusion, de la dé-motivation, et l'échec du projet. De petits ajustements sont habituellement logiques et acceptables tant que la proposition de valeur du produit reste la même.
Globale et mobilisatrice
La vision du produit doit décrire un objectif global et mobilisateur : un objectif qui guide l'effort de développement, tout en laissant suffisamment de place pour la créativité; un objectif qui mobilise et inspire les gens, encourage la créativité et le soutien.
Concise et pure
La vision du produit doit être brève et concise (2). Elle ne doit contenir que des informations essentielles à la réussite du produit. Par exemple, les visions communiquées sur les produits phares traités par Lynn & Reilly (3) ne disposent pas de plus de six caractéristiques. La vision du produit n'est, par conséquent, pas une liste de fonctionnalités et ne doit pas fournir de détails inutiles.
Le test de l'ascenseur
La manière classique pour valider la vision du produit est de répondre au test de l'ascenseur : "Pouvez-vous expliquer votre produit dans le temps qu'il faut pour monter dans un ascenseur ?" (4). Passer ce test permet de vérifier que votre vision du produit est claire, engageante et concise (en supposant que nous montons au bon étage du bâtiment et qu'on ne va pas rester coincé dans l'ascenseur). Notez que le test de l'ascenseur ne nous dit pas si nous avons sélectionné de façon pertinente les bons besoins clients et les bonnes caractéristiques du produit; seuls de rapides retours clients peuvent le faire.
Les projets de tous les jours
Même nos projets courants devraient être guidés par une vision du produit. Par exemple, je gère mes activités de marketing à l'aide de Scrum. Je remplis mon backlog de marketing avec de nouveaux items régulièrement, aussi fréquemment que possible. Il serait inutile de procéder à des études de marché et des activités de prototypage avant de me décider sur quoi travailler. Je me fixe plutôt une vision marketing qui guide mon travail et concentre mes efforts. Ma vision est, de par sa conception, moins importante que la vision d'un projet de développement d'un nouveau produit mais il est quand même important que j'en ai une.
Résumé
Une vision produit efficace guide l'équipe Scrum et coordonne les parties prenantes et les clients. Passer du temps et de l'argent sur la création d'une vision est un investissement rentable. Comme l'a noté Robert G. Cooper : "Trop de projets de nouveaux produits passent directement du niveau idée au niveau développement avec peu ou pas de travail amont. Les résultats de cette approche "prêt, feu, touché" sont généralement désastreux. Une solide phase avant développement augmente les taux de réussite des nouveaux produits de manière significative et est fortement liée à la performance financière" (5). Cela ne signifie pas de tergiverser au début du développement, en utilisant un processus waterfall en amont pour créer un concept produit formidable ou de passer par un projet distinct. L'astuce consiste à passer le moins de temps possible mais autant que de besoin, d'utiliser Scrum pour créer la vision et de faire en sorte que le plus grand nombre possible de membres de l'équipe - impliqués dans la création de cette vision - participent également à sa transformation en un produit réel.
Références
(1) Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004.
(2) Roman Pichler. Scrum – Agile Projektmanagement richtig einsetzen. dpunkt.verlag. 2008.
(3) Gary S. Lynn & R. Reilly Richard. Blockbusters. The Five Keys to Developing Great New Products. HarperCollins. 2002.
(4) Geoffrey A. Moore, Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers. Revised edition. Collins Business Essentials. 2006.
(5) Robert G. Cooper. Doing it Right. Winning with New Products. Ivey Business Journal. July/August 2000.
Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.
mercredi, 17 novembre 2010
Etre un Client sur site ou un Product Owner efficace
Par Fabrice le mercredi, 17 novembre 2010, 23:32 - Lecture
Aujourd'hui, j'ai vraiment ressenti le besoin de traduire cet article de Simon Baker : "Being an effective Onsite Customer or Product Owner". Vous êtes un client qui pensez faire de l'Agile ? parce que l'équipe de développement est dans le bureau d'à côté ? parce qu'il y a des post-its affichés sur les murs de l'équipe de développement ? parce que la livraison du produit se fait en plusieurs lots ? lisez la suite...
Les projets Agile demande une Réelle Implication du Client. Pour être un Client sur site ou un Product Owner efficace, vous devez être soit un vrai client, soit être en mesure de représenter fidèlement le vrai client. Vous devez accepter le statut élevé que vous détenez et accepter les responsabilités qui l'accompagnent (Responsabilité Acceptée). Vous devez être un intervenant et un membre à part entière de l'équipe. Vous devez être accessible et vous devez participer au projet de manière proactive et continue. Vous devez reconnaître que grâce à vos actions - écrire des stories et des tests d'acceptation, prioriser des user stories selon la valeur métier, décider quelles user stories doivent être ensuite développées, fournir des retours rapidement, .... - vous pilotez effectivement le projet et vous êtes finalement le responsable de la valeur métier livrée. En tant que véritable force motrice du projet, votre présence doit être visible, verbale et objective.
La communication est une valeur "agile" et la collaboration est un comportement intrinsèque qui contribue à la réussite des équipes agiles. En tant que Client sur site, vous devez démontrer dès le départ que vous êtes un membre comme les autres de l'équipe. Respectez les rendez-vous de l'équipe. N'évitez pas les activités liées au métier, par exemple, écrire des stories pour les développeurs. Les développeurs peuvent vous aider dans cette activité particulière, mais en tant que représentant métier et décideur sur ce qui constitue de la valeur ajoutée pour l'entreprise, vous devez prendre les décisions métier et veiller à ce que les exigences soient clairement communiquées et comprises. Certaines des informations à forte valeur ajoutée sont transmises au travers de simples conversations qui se produisent tout le temps dans la War Room. Vous pouvez ramasser ces pépites par effet d'osmose si vous êtes au même endroit que l'équipe. Communiquez la vision du projet à l'équipe en utilisant des objectifs clairs et ambitieux (Larsen, LaFasto) afin que l'équipe soit mieux préparée pour les réaliser.
Vous devez avoir des ambitions élevées et demandez un code complet et démontrable à la fin de chaque itération. Insistez sur une grande couverture des tests (entre 80 et 100%), des tests unitaires et d'acceptation automatisés, des builds automatisés, une intégration continue et une visibilité claire sur l'état d'avancement. Présentez à l'équipe des défis qui dynamiseront leurs efforts. Ne fixez pas des objectifs irréalisables et soyez toujours prêt à écouter, à négocier et à accepter des compromis. Ne fixez pas des délais impossibles à tenir ou attendez-vous à ce que les développeurs réduisent la qualité de leur travail. Un développement qui est précipité devra inévitablement être débogué ultérieurement, donc le coût du projet sera plus élevé.
Définissez des priorités claires fondées sur la valeur métier et vous aurez une équipe qui saura livrer les stories de plus grande valeur ajoutée en premier. Mais comprenez et évaluez les risques avant de juger. Les priorités sont relatives, donc si vous dites que tout a une "priorité maximale", vous ne faites pas votre travail correctement. Dans cette situation, vous pouvez vous attendre à recevoir un ensemble arbitraire de user stories complètes et incomplètes à la fin. Insistez pour connaître le coût d'une story avant de la prioriser. Demandez aux développeurs d'estimer les user stories à l'aide d'une échelle d'unités telle que les points de story (cette technique fournit des estimations relatives rapidement, mais comprenez qu'il y aura une plus grande tolérance à l'inexactitude compte tenu de la taille et une ambiguïté potentielle sur les user stories à ce stade). Vous avez le droit de changer d'avis, mais prenez une décision et évitez de faire des changements aléatoires. Les changements se produiront pour de nombreuses et différentes raisons, donc réévaluez régulièrement et rapidement vos priorités.
Pour simplifier la planification, vous devez définir les fonctionnalités sous forme de user stories de sorte que l'équipe puisse les estimer. Apprenez à écrire des user stories correctement et pratiquez en les détaillant au fur et à mesure des discussions et des conversations avec les développeurs. Pratiquez et exprimez ces détails sous forme de tests d'acceptation.
Apportez du soutien, des encouragements et de la reconnaissance à l'équipe à la fois par vos paroles et vos actions. Saisissez toutes les occasions et ne vous économisez pas jusqu'à la fin du projet. Cela motivera les membres de l'équipe à faire de leur mieux pour vous au fur et à mesure que le projet progresse.
Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.
jeudi, 4 novembre 2010
PDCA
Par Fabrice le jeudi, 4 novembre 2010, 19:37 - Inclassables
Alors le PDCA, ce n'est pas "Je planifie, Tu déploies, Je contrôle, Tu améliores". Non mais !
mercredi, 17 mars 2010
Je ne résiste pas...
Par Fabrice le mercredi, 17 mars 2010, 10:22 - Inclassables
C'est toujours et encore la même image, mais que voulez-vous, c'est mon quotidien en ce moment, alors voilà :
Ça doit sûrement venir du cahier décharge ou du respect d'énorme 
Feedback :
- Project Cartoon, vu sur le billet de l'Institut Agile intitulé "Quarante ans de crise"
