Pour moi être agile c’est savoir s’adapter, éviter les mauvais coups. Un boxeur agile ne frappera pas nécessairement plus fort ou précis mais il recevra moins de coup. Un joueur de hockey agile ne comptera pas nécessairement plus de but mais il pourra se rendre plus souvent dans la zone pour le faire.

Un développeur agile n’est pas vraiment plus rapide qu’un autre, il sait juste éviter les récifs comme s’il descendait les rapides en kayak. Le développeur agile voit venir les coups et sait les éviter. Il sait même se mettre dans une situation où il sera en meilleure posture pour les éviter.

S’adapter c’est développer ses forces pour contrer les problèmes rencontrés. S’adapter c’est aussi laisser de côté ce qui ne fonctionne pas et utiliser ce qui fonctionne. La nature a évolué depuis des millions d’années comme ça. Il faut arrêter de faire ce qui ne fonctionne pas pour ne pas se faire déclasser pas les autres.

Démontrer

Un des préceptes des méthodologies agile est de produire des résultats démontrables à la fin de chaque cycle, ou sprint si on utilise la méthodologie SCRUM. La démo est une façon de présenter le travail accompli. J’insiste sur le terme accompli pour apporter la notion de done. Le donene veut pas dire que l’on peut le démontrer, ça veut dire que tous les critères que l’on s’est donnés sont respectés. La démo peut faire partie de ces critères.

L’objectif d’un sprint n’est pas la démo. L’objectif du sprint est de terminer les stories sur lesquels on s’est commis.

Trop souvent j’ai participé à des sprints où les priorités étaient dirigées par le désir de satisfaire les besoins de la démo sous prétexte que le VP allait y être. Les priorités doivent être dirigées par la valeur d’affaire. Le DDD ne veut pas dire Demo Driven Design mais bien Domain Driven Design mais ça c’est une autre histoire.

L’événement débutera à 8 h, pour une durée de 2 heures. Un petit déjeuner sera servi.

Inscrivez-vous maintenant, les places sont limitées.

Au plaisir de vous y voir!

Les rôles à pourvoir sont les suivants :

• Scrum Master;
• Coach d’équipe Agile;
• Coach organisationnel Agile.

En vous joignant à notre équipe Agile, vous découvrirez des gens passionnés de l’Agilité qui ont à coeur la réussite des projets de développement auxquels ils participent. Vous allez vous surpasser, relever des défis et guider des équipes de développement.

Au cours des 10 dernières années, Pyxis a été un acteur dans la mise en place de l’Agilité à Montréal et à Québec. Pyxis étant fondateur du groupe Agile Montréal et partenaire actif d’Agile Québec, vous avez sûrement déjà rencontré un Pyxissien lors d’une conférence Agile. Pyxis offre aujourd’hui une gamme complète de services de coaching et de formation Agile pour bien répondre aux besoins des équipes de développement Agile.

Faites partie du mouvement Agile avec Pyxis!

Ce que j’ai aimé dans cette expérience:

• binômer avec Xavier
• avoir un fil rouge parmi une foule d’autres activités

Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de “gagner la propale” dans le future rend-elle meilleure l’expérience passée ?

Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui

C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.

La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire “construire un logiciel par incréments successifs”. Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…

Saviez-vous que Pyxis a collaboré à ce projet?
Pyxis est très fière des résultats de la mise en place de Scrum pour la réalisation de ce projet. Trois collaborateurs ont participé au projet. Marc-André Filion-Pilon occupait le rôle de Scrum Master, veillait à la gestion du projet et agissait à titre de facilitateur. Erik Lebel et Éric de Carufel ont agi à titre de développeurs .NET. Leur expérience a permis d’aider l’équipe dans l’application de pratiques Agiles d’ingénierie logicielle.

Ce que Scrum a permis à l’équipe de CAE Santé
L’emploi de la méthode Scrum pour la réalisation du projet a permis d’atténuer plusieurs risques, notamment en favorisant des cycles courts de développement (sprints de 2 semaines). Ceci a permis la révision en continu des priorités et l’adaptation du processus en fonction des succès et problèmes rencontrés. De plus, nous avons utilisé plusieurs artefacts simples et efficaces de Scrum pour assurer la visibilité relativement à l’avancement du projet (carnet de tâches du sprint et de la livraison, graphiques d’avancement, etc.).

Au niveau des besoins, il était essentiel de les clarifier et de les prioriser conjointement avec le client et les utilisateurs finaux. Le rapprochement avec les utilisateurs et une plus grande implication de leur part ont permis de gérer les attentes tout en assurant une grande transparence.

Défis techniques
Un des plus grands défis d’un projet de développement ayant un délai très court et un important périmètre est de ne pas couper dans la qualité (perçue ou interne). Or, ce risque a été pris en compte en favorisant des déploiements rapides, ce qui a permis de faire des tests et de recevoir du feed-back rapidement. De plus, l’utilisation de patrons et de cadres transversaux dans l’application permet du développement plus rapide, uniforme et fiable.

Bravo à toute l’équipe qui a réalisé ce beau projet!

Voir le système en action

PM: If the velocity increases, the remaining work will decrease
PO: No, new work could be added at the same time

PM: I don’t like when the Team updates an item with a smaller effort estimation because the velocity could decrease
PO: I like when the Team updates an item with a smaller effort estimation because the remaining work decreases

PM: You don’t track the velocity in a velocity chart?
PO: No, I track the remaining work in a release burndown chart