Réunion 7 février chez Planbox
Posted by: denis in Notes de réunion on February 19th, 2011
Une 15 zaine de participants … une rencontre sympathique avec une présentation d’outil.
Merci à nos hôtes Alexandre et Martin de Planbox
J’ai pris finalement très peu de notes ce soir là … aussi je compte un peu sur tout le monde pour m’aider à compléter ce post 
Nous avons pris l’exemple d’une application iPhone pour le SUG Mtl pour illustrer la planification agile via Planbox.
Nous avons identifié les besoins suivants que Planbox devrait couvrir :
- possibilité de mettre une business value sur les stories
- les temps doivent pouvoir être gérés pour chaque tâche
- la notion de reste à faire est nécessaire pour effectuer le suivi quotidien
- point / heure
- lier les stories/tâches à un gestionnaire de sources
- outil de planning poker incorporé au produit (http://www.planningpoker.com/)
Quels sont les outils utilisés au niveau de la planification dans votre entreprise / sur vos projets ?
- excel +++
- jira ++
- clarity +
Tout le monde peut-il être “agile” ?
Posted by: denis in Notes de réunion, Réflexion, suggestion débat on December 23rd, 2010
Notes de la réunion du 7 décembre 2010 chez INM.
Présents: Vahé, François, Eric, Etienne, Denis
Tout le monde peut-il être “agile” ? tour de table et expérience de chacun requise
Non, beaucoup de gens ont des difficultés à travailler en équipe, pensent que les autres sont des nuisances, n’ont pas d’habilité sociale, parfois certaines personnes sont en mode “papillon” et ne sont donc pas agiles (communiquent mais ne collaborent pas). Les liens affectifs peuvent jouer un rôle négatif au niveau de la collaboration.
La base du profil agile est la collaboration. Tout le monde ne sait pas collaborer.
Qu’est ce qui marche finalement ? La capacité à faire des compromis est une bonne base pour identifier un profil agile.
Co-dépendance : l’intérêt pour le groupe doit être + fort que l’intérêt individuel.
Est-ce que l’agilité est un facteur individuel ou de groupe ?
Les phénomènes générationnels sont-ils à prendre en compte ?
Quelles sont les qualités/aptitudes requises pour être membre d’une équipe agile, d’une organisation agile ? une extension sur le sujet de Richard : critères et qualités recherchés d’un scrum master.
- bonne écoute / communiquant (mesurable)
- ouverture à la critique (mesurable) confiance en soi (mesurable)
- courageux et honnête
- donne de la valeur au groupe (contribue positivement au groupe)
- respect d’autrui
Etienne nous livre quelques lectures intéressantes :
“How to Protect Your Open Source Project From Poisonous People” donnée par des développeurs de Subversion. Elle traite d’un sujet qui n’est pas directement relié, mais on peut en tirer des réponses pertinentes. La prémisse de départ est : “l’attention et la concentration du groupe sont des ressources précieuses et on doit les protéger”.
Hors sujet, mais plusieurs lui ont demandé le lien pour ce vidéo : The Known Universe
Eric nous livre aussi une lecture abordée durant la rencontre :
The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t (Robert I. Sutton)
Une des sections du livre comporte une série de questions pour déterminer notre niveau de “assholeness”.
Ce test, poliment appelé “Asshole Rating Self-Exam (ARSE)” par l’auteur, se retrouve aussi online
Au tour de Vahé de vous fournir les références promises :
Le dernier livre de Dan Ariely: The Upside of Irrationality dont le chapitre 2 traite de l’importance du sens de l’accomplissement au travail.
Un texte qu’il avait écrit au sujet de “Traits de personnalités et synergies d’équipes SCRUM” sur qui motive le besoin de méthodes objectives de sélection de membre d’une équipe SCRUM.
L’équipe produit en remplacement d’un seul product owner
Posted by: alain in Notes de réunion on July 14th, 2010
Résumé de la rencontre du 15/06/2010
L’équipe produit en remplacement d’un seul product owner…
…Ou comment gérer de nombreux intervenants avec Scrum sans perdre d’efficacité
Souvent en entreprise, on doit avoir une « équipe produit », pour compenser au fait qu’on n’a pas tous les intervenants à l’intérieur de l’équipe…
- Types d’intervenants / tâches
- Systèmes connexes / projets reliés
- Sécurité
- Ergonomie / Expérience utilisateur
- Architecture
- QA
- Conformité (ISO)
- Qui gère la valeur ?
Gestion des intervenants en AMONT
a) Intervenants fonctionnels / plusieurs stakeholders :
En début de projet :
- Identifier les PO !! On met un proxy, on explique les règles de priorisation…
- Identifier les différents intervenants (communauté de projet) responsables des différentes tâches
b) Pour les autres « groupes »…
- On fait 2 backlogs ?
- On en fait un seul (car sinon comment gérer les types de tâches ?) ET le PO doit avoir les droits (et la compétence) de faire la priorisation.
Gestion des intervenants en AVAL : Intervenants Qualité / acceptation
- Faire un plan de livraison (release plan)
- Validation du hors fonctionnel en fin de livraison (release). Par exemple : Sécurité, performance, intégration autres systèmes…
- « Architecturer » les parties « mission critical » VS ce qui ne l’est pas
- Chargé de projet qui serait responsable de l’arrimage entre les différents groupes / types de tâches…
Pour les exigences de conformité :
Les définir le plus tard possible : un document UML (qui permettra la conception de l’application) sera facile à modifier par rapport à un document de conformité. Le document une fois rédigé collera au projet livré ! (Se rapproche d’un document utilisateur !).
Comment vendre SCRUM aux clients?
Posted by: vahe in Notes de réunion on May 1st, 2010
Notes de la réunion du 13 janvier 2010.
La session s’ouvre sur “Que veut dire vendre?” et “A qui se fait la vente?“. On clarifie rapidement qu’il s’agit de persuasion dans sa définition la plus large et que le public visé est autant interne à une organisation (”les patrons”) qu’externe (des clients qui ont le choix d’acheter ailleurs).
Quels projets se qualifient typiquement à la méthode SCRUM? Les projets innovants, qui contiennent des facteurs inconnus et/ou incertitudes. Également les projets qui doivent être itérativement “modelés” à un parc d’utilisateurs qui n’a pas l’expérience ou le consensus nécessaire à s’engager sur des requis clairs au démarrage de projet.
La durée du projet n’est pas un facteur déterminant: petits et grands projets s’exécutent très bien en mode SCRUM.
Certains clients pensent que l’idée de procéder par itérations ouvertes (c-à-d sans engagement sur un ensemble précis de spécifications à une date de livraison précise) est due à un manque de compétence, d’expérience ou d’engagement (commitment) de l’équipe d’exécution. Bien que ces cas puissent exister, c’est habituellement les clients inexpérimentés qui pensent qu’un projet significatif en informatique soit entièrement prévisible. Ce sont habituellement des gens qui n’ont pas vécu les problèmes et échecs des méthodes classiques.
Un autre obstacle occasionnel est que certains managers, aussi persuadés soient-ils de SCRUM, ne peuvent pas adopter la méthode parce qu’ils sont eux-mêmes soumis à des méthodes spécifiques de travail. Dans certains cas, la méthode de travail est laissée libre mais la conformité à des normes (ex: ISO) est nécessaire. Dans ce cas, SCRUM peut quand même être appliqué.
Une façon de persuader un client d’adopter SCRUM est de démontrer (1) des succès du passé par des histoires vécues, de préférence en comparaison avec les méthodes alternatives; (b) intégrer SCRUM progressivement au projet, selon les résistances, limites et appréhensions du client, et de bâtir ainsi progressivement la confiance. Il est, par exemple, tout à fait envisageable de débuter par un projet pilote.
Il est important que le client (soit-il interne ou externe) entre dans le mode SCRUM et en voit les bénéfices pour lui ainsi que pour l’ensemble du projet (progrès visible, restitutions d’étapes qu’il peut mettre au défi, flexibilité, droit mais pas obligation au changement, etc.)
Par ailleurs, il est important de démontrer constamment l’engagement de l’équipe. Éviter l’ambiance “je travaille autant que je peux et je livre ce que je peux“. L’équipe doit démontrer une compréhension non-équivoque des objectifs ultimes du client.
Il est souvent souhaitable que le client devienne lui-même PO (product owner). C’est un objectif très louable, mais s’il ne veut pas aller aussi loin, il peut intervenir à travers un PO Proxy. Par contre, le client doit toujours rester engagé dans les sign-off (approbations d’étapes).
On rappelle que XP (Extreme Programming) impose un représentant du client sur place, constamment disponible à l’équipe de développement. C’est une méthode souhaitable mais parfois trop coûteuse et irréaliste.
Références d’industrie:
- Scott Ambler a conduit une enquête sur les méthodes classiques vs SCRUM.
- Un nombre très significatif de grandes sociétés ont désormais adopté SCRUM et s’en déclarent satisfaits. Ce n’est donc pas le propre des hippies et des marginaux. Par contre, il nous faut là une liste relativement fournie pour que les divers publics de “clients” s’y identifient.
- Microsoft propose la notion de Stories directement dans Visual Studio 2010
- Le SPA (Software Publishers Association) a probablement des données de benchmark sur les méthodes classiques versus SCRUM (point soumis par Etienne Beauchesne).
Clôture de la réunion:
- Etienne Beauchesne organisera la prochaine rencontre
- Denis Lemarchand créera un groupe LinkedIn qui facilite les communications en groupe.
Comment gérer les conflits dans une équipe Scrum
Posted by: eportelance in Notes de réunion on April 22nd, 2010
Notes de réunion de la rencontre du 21 avril 2010
Plusieurs types de conflits peuvent survenir dans une équipe scrum.
- Conflits entre les membres de l’équipe de développement
- Conflits impliquant le PO et/ou le SM
- Entre le PO et le client
Quel est le rôle et les responsabilités de chacun pour gérer les conflits?
Est-ce vraiment différent de gérer les conflits dans une équipe Scrum vs équipe traditionnelle?
Conflit entre les membre de l’équipe de développement
Si le problème est simple et clairement identifié par l’équipe, cette dernière devrait avoir la maturité et la responsabilité de régler le conflit. Le SM devrait ici faciliter la discussion pour qu’une solution soit trouvée par l’équipe.
Dans le cas où l’équipe n’est pas consciente du conflit ou si personne de l’équipe prend la responsabilité de le régler, le ScrumMaster doit d’abord soulever le problème et s’assurer qu’une discussion a lieu pour trouver une solution. Il peut aider à proposer des solutions, mais devrait éviter d’en imposer une.
Le ScrumMaster peut par exemple organiser des rencontres individuelles avec tous les membres de l’équipe et des rencontres de groupe.
Comme il n’y a pas de chef officiel dans une équipe Scrum, les leaders naturels de l’équipe devraient se manifester.
Voici les étapes de résolutions proposées:
- Voir si le problème peut être résolu automatiquement par l’équipe
- Le SM s’implique pour aider l’équipe à trouver des solutions
- Aller chercher l’aide d’un médiateur si le problème persiste
- Escalader le problème au higher management
Si le SM (ou le PO) fait parti du conflit
Le problème peut avoir un impact important sur le projet et il est important que cela soit réglé rapidement.
Le SM devrait avoir certaines qualités interpersonnelles et de leadership pour arriver à éviter de se mettre dans cette situation.
Toutefois si cela se produit, une solution envisageable est de faire intervenir un médiateur. Si une compagnie possède plusieurs Scrum Master, un Scrum Master d’une autre équipe pourrait alors agir en tant que médiateur. Sinon, la tâche peut revenir à un gestionnaire, une personne des RH ou n’importe quelle personne qualifiée.
Pour tous les conflits, la communication est bien souvent la meilleure source de solution!
QA et QC avec Scrum
Posted by: bruno in Notes de réunion on November 23rd, 2009
Il ne faut pas confondre assurance qualité (AQ) et contrôle qualité (CQ). Voir cet article sur le sujet.
AQ/CQ est perçu comme une tâche inintéressante.
- Scrum aide à développer une “culture qualité” grâce au concept de “done”, ce qui intègre implicitement certaines activités AQ/CQ dans le processus de développement.
- Ajouter des colonnes “test”, “intégration”, etc. sur le tableau Scrum permet de sensibiliser les équipes débutantes à leur responsabilité par rapport à la qualité.
Les tâches AQ/CQ dérangent le travail de l’équipe de développement
Car elle ne sont généralement pas (ou mal) planifiées/planifiables (ex: correction d’anomalies). L’interprétation simpliste de Scrum est de privilégier le développement de features, au détriment de tout ce qui ne livre pas directement de la valeur.
- Un stream distinct peut prendre en charge les activités AQ/CQ pour que l’équipe dev puisse se concentrer sur le développement.
- Une équipe dédiée ou des personnes spécifiques au sein de l’équipe peut prendre en charge certains aspects AQ/CQ, telle que la spécification qualité (partie de AQ) et la validation (partie de CQ).
- Alternativement, l’équipe de dev peut faire les analyses pour les stories du sprint suivant.
- Le AQ/CQ peut être placé au niveau du release plan, et pas dans les sprints (risque que les anomalies sont trouvées bien plus tard, mais plus facile à gérer)
Les divergences de définition de “done”
- Elles constituent un sujet de malentendu entre l’équipe de dev et les personnes responsables d’approuver les livrables. Finalement, on en revient à discuter de la définition de “qualité”. En effet “done” est supposé correspondre à “de bonne qualité”, mais pour qui? Sur base de quoi? L’un des problèmes à la source de ce conflit est que les personnes qui spécifient la qualité et les personnes qui contrôlent la qualité sont généralement en dehors de l’équipe de développement et communiquent peu.
- Avoir des responsables qualité au sein de l’équipe est une solution, mais cela va à l’encontre du caractère polyvalent (càd pas de rôles attribués formellement) de l’équipe Scrum.
- Suite dans les deux sujets suivants.
Qui spécifie la qualité
- PO: il détermine ce qu’il y a à faire, mais le niveau de détail (ex: démo) ne comprend pas toutes les spécifications fonctionnelles (ex: scénarios alternatifs etc.) ni les spécifications non fonctionnelles (ex: ergonomie, performance, sécurité, etc.). Je reprends un commentaire dans le débat: “ce n’est pas la responsabilité du PO de définir les requirements car il n’a pas nécessairement les compétences; il n’est pas analyste.”
- SM: il inculque un esprit qualité dans l’équipe mais ne peut faire office que de guide; il ne formalise pas la qualité.
- Équipe: elle peut établir un objectif de qualité technique (le comment, par ex: code, architecture, etc.) mais pas fonctionnelle (le quoi).
- Analyste d’affaires (AA): c’est la personne la plus indiquée pour prendre en charge l’AQ des aspects fonctionnels. Le AA devrait faire partie intégrante de l’équipe, avec comme rôle de spécifier le quoi (par ex use cases etc.) et s’assurer que le développement va dans ce sens.
Qui contrôle la qualité?
- La qualité technique peut être contrôlée par l’équipe Scrum. La qualité fonctionnelle ne le peut pas car il y aurait un conflit d’intérêt (càd l’équipe ne peut pas valider son propre travail).
- La démo (aka review) de fin de sprint permet au PO d’avoir un aperçu de la qualité mais n’est pas assez détaillée pour valider les livrables. Par ex souvent on ne parcourt que les scénarios de base rapidement.
- Il faut donc un rôle supplémentaire qui passe après le PO pour contrôler la qualité formellement en évaluant les livrables par rapport aux spécifications établies par les AA. Ce contrôle se fait sur base de plans de tests fonctionnels établis avant de développer.
Il se passe trop de temps entre le développement et le contrôle qualité
La responsabilité de AQ/CQ est floue lorsqu’on travaille en impartition
À quoi s’appliquent les critères de qualité?
- Il est difficile de définir les critères de qualité à plusieurs niveaux: projet et story par exemple.
- Un sprint zéro permet d’établir des standards de qualité indépendants des stories. En effet de nombreux critères (ergo, perf, UI, etc.) sont communs à toutes les stories.
- Ensuite, pour chaque story on doit établir la liste des critères d’approbation (définition détaillée de “done”). Idéalement ces critères devraient être préparés avant le sprint planning.
Que faire quand il est difficile d’établir des spécifications?
Techniques aidant à viser la qualité
- tdd
- test unitaire
- intégration continue
- test intégration syst
Intégration UX/UI dans Scrum
Posted by: denis in Notes de réunion, Réflexion on October 18th, 2009
Le groupe s’interroge sur l’intégration de l’expérience utilisateur (UX) et de la conception graphique des interfaces (UI) dans une équipe Scrum.
Problèmes soulevés
- Problème de l’engagement des projets au forfait
- Les développeurs ne sont pas sensibles à UX/UI
- Les users ne sont pas impliqués (les utilisateurs ne sont pas le client !)
- Approbation UX souvent requise implique bien souvent une source de blocage lors du développement des stories
Plusieurs idées pour intégrer UX/UI dans Scrum sont discutées
- UX dans une phase exploratoire - avant les sprints
- Introduire les contraintes UX dans les stories
- Introduire UX dans les tests d’acceptation
- Faire au préalable quelques “story board” pour guider - faire le reste dans les stories
- Définir des utilisateurs types pour noter les stories (usability value par story …)
- Implémenter des tests usability pour un feedback rapide
- Posséder un Backlog UX
- Intégrer un spécialiste UX à l’équipe qui défendra les standards UX
- Avoir une équipe UX séparée, qui travaille en // et livre à l’équipe Scrum les prototypes
- L’UX est générateur d’innovation …. il faut explorer auprès des users pour sortir le guide UX du projet (recherche UX)
- Faire la recherche UX pour le sprint + 2, faire le dev UX/UI pour le sprint + 1, implémenter les tests UX dans le sprint courant
- Se rapprocher du cas des équipes de jeux vidéo ! Comment font-ils ?
Solutions
- UX = innovation = coût = à faire payer au client
- UX travaille avec le PO
- UX + Developpeur doivent collaborer
- Faire la recherche UX pour le sprint + 2, faire le dev UX/UI pour le sprint + 1, implémenter les tests UX dans le sprint courant
- Utiliser des outils de scénarisation pour la recherche UX
- Uiliser des outils tel que Balsamiq Mockups pour le UI des stories
- Faire du sketching papier avec le client pour le dev UX
Quels sont les outils pour Scrum ?
Posted by: denis in Notes de réunion on August 5th, 2009
Réunion du 3 Août 2009
Voici une liste, non exhaustive, des outils de gestion Scrum à explorer
- Excel/Gapps (gratuit)
- IceScrum (gratuit)
- ScrumWorks (version gratuite et pro payante)
- GreenHopper - plugin JIRA (payant)
- Agilo (version gratuite et pro payante)
- Pivotal Tracker (payant)
- Mingle (Payant)
- Banana Scrum (Saas payant)
- TargetProcess (payant)
- VersionOne (payant)
- Confluence ?
- E Scum de Microsoft ?
Qu’est-ce qui fait qu’un outil de gestion Scrum est un bon outil ? Quelles sont les fonctionnalités requises ? Doit-on réaliser un couplage avec les outils de développement ?
- On souhaite tout de même conserver le mode papier
- l’outil doit s’intégrer à l’existant (bug tracking, suivi roadmap, SVN, …)
- l’outil doit contrôler le respect de la méthode en terme des artefacts Scrum
- il doit aussi permettre le suivi des tâches et montrer les dépendances entre tâches
- on doit pouvoir le “customiser” (nouveaux champs par exemple, changement de libellés)
- ce doit être un outil collaboratif
- il doit permettre une documentation interne et libre
- il doit permettre une recherche rapide en mode “plein texte” sur tous champs
- l’outil doit fournir un portail pour le client
- il doit permettre le suivi des items des retrospectives + “impédiment list” : tracking des impediments et des solutions …
- une gestion des feuilles de temps restants + passées serait bien vu (pas très Scrum mais pratique tout de même)
- l’accès à l’information doit être simple et efficace en fonction du rôle
- un reporting envoyé par email (programmation des rapports que l’on souhaite) serait bien
- une annotation des stories par le PO (fil de discussion RSS des annotations) serait un plus
- unjournal de bord des daily meeting (blog) serait un plus
- une gestion intégrée avec le QA - tests plan serait un atout
Quid de l’interactivité et de la convivialité du tableau ?
- selon les protagonistes, il faut conserver le papier !
Certains de nos membres utilisent
- Tableau de bord + postit
- Trac : garder les tickets (ticket pour les stories + ticket pour les tâches)
- Excel pour le burndown chart
Le côté papier est très important … il y a une dynamique que l’on ne peut pas avoir avec le mode électronique.
L’inconvénient est la manipulation des 3 sources de données.
Test Agilo : pas concluant, effet de bord sur TRAC.
- selon les protagonistes, il faut conserver le papier !
Certains de nos membres utilisent
- product backlog + sprint backlog : Sheet sous Google Apps
- blog pour le suivi des daily meeting
Comment favoriser l’autonomie de la team et sa responsabilité d’un projet
Posted by: Frank in Notes de réunion on August 5th, 2009
Travailler sur les Stories, pas sur les tâches.
Décomposer une Story en tâche, c’est excellent pour ne rien oublier et pour la planification. Le risque, c’est d’oublier que l’on travaille pour une Story : les tâches n’ont aucune valeur pour le Product Owner et le client qu’il représente - ce sont les Story qui compte. Il est donc permis de critiquer, modifier et adapter les tâches en conséquence, en cours de route. Le but ultime, c’est la Story!
Partager et régler les problèmes maintenant.
Seuls les problèmes qui sont rapidement rapportés au Scrum Master peuvent être réglés rapidement par ce dernier, si c’est possible. Dans certains cas, il vaut même le coup d’impliquer immédiatement le Product Owner. De suivre cette bonne pratique permet de trouver en équipe des raccourcis et de cibler ses efforts sur les défis qui valent quelque chose pour le client. Parce que tout le monde est au courant des problèmes rencontrés et des solutions apportées, on évite des frustrations d’incompréhension du temps investis (entre les membres de l’équipe, ou plus probablement entre le Product Owner et l’équipe).
Impliquer l’équipe dans la planification et le design.
Idéalement, les développeurs sont aussi les designer de l’interface de l’utilisateur et des interactions - ceci suscite la créativité et la motivation. Même pour certains projets plus complexes où l’intervention d’un designer pourrait être requit, il est important d’impliquer l’équipe de développement dans la prise de décision, l’ébauchage et le design. C’est cette collaboration qui permet de trouver le bon rapport “qualité/prix” sur chacune des fonctionnalités et qui préserve l’intérêt (et la créativité) des intervenants du projet.
Définir ce qu’est un bon développeur.
Un bon développeur n’est pas seulement celui qui code bien, vite et qui ne laisse aucun problème ou bogue derrière. C’est d’abord celui qui pense à l’utilisateur, communique avec son équipe, trouve les raccourcis et les solutions les plus simples aux problèmes et qui respecte ses engagements face à l’équipe et au Product Owner.
Marquer les bons coups et les mauvais coups.
Amenez les développeurs à se féliciter entre eux, se parler de leurs problèmes et à critiquer le plan. Responsabilisez les sur tous les plans sur projet en les impliquant dans toutes les décisions. Faites les vivre face au client, succès et échecs.
Éliminer la démotivation avant d’améliorer la motivation.
S’il y a des tabous, des tensions entre les membres ou des problèmes de motivation grave, il faut intervenir rapidement: une équipe saine est une équipe qui communique beaucoup. C’est lorsque toutes les frustrations sont éliminée qu’il faut renforcer l’esprit d’équipe.
Laissez à l’équipe le choix de la méthode.
La méthodologie peut-être critiquée. Donnez leur le choix d’en suivre une autre ou de retourner en gestion de projet en cascade. Soyez certain d’appliquer la méthodologie et tous ses artifacts et évitez surtout de prendre des décisions pour l’équipe ou des les forcer à en prendre. Prenez le temps de vous assurer que la méthodologie est bien comprise par tous les membres de l’équipe, incluant la non-hiérarchie de l’équipe, du Scrum Master et Product Owner, la responsabilité de chacun et leurs engagements face aux autres.