Savez-vous ce qu’est un registre de « Dette Technique » et comment bien l’utiliser dans les méthodes itératives #Agile ?

« Dettes et mensonges sont ordinairement ensemble ralliés » Rabelais dans Pantagruel.

Using a « Technical Debt Register » in Scrum

https://www.scrum.org/resources/blog/using-technical-debt-register-scrum par Ian Mitchell

En vieillissant, je me métamorphose en l’un de ces types nostalgiques et ennuyeux qui vit trop dans le passé. Les choses étaient mieux avant, mon enfant. Nous avions des standards et il y avait moins de « sur-simplification ».

Mais parfois au crépuscule, comme je me lève de mon fauteuil à bascule sous le porche et me penche en avant pour soulager mon dos, je reconnais qu’il y a une chose qui est en réalité meilleure maintenant qu’au début des années 2000 : De nos jours, un homme peut parler de la « dette technique » sans que les gens le prennent pour un fou.

La dette technique peut être définie comme les conséquences à long terme de faibles décisions de conception. À l’origine décrit comme une métaphore par la Ward Cunningham, à peu près tout le monde accepte maintenant que la dette technique est un risque réel qui peut réellement être encouru. Cette identification est bonne. Critiquer Java et en damner les conséquences n’est pas vraiment « Agile », c’est juste jouer au cow-boy. Mais la vérité est que pendant des années, cela n’a pas été compris, pas avant que les dettes de certains imbéciles soient si importantes qu’elles ne puissent perdurer.

Cela vaut cependant la peine de garder à l’esprit que pas tous les défauts et bugs ne constituent de la dette technique.

Écopez un peu de votre dette avant qu’elle ne vous noie.

C’est parce qu’ils ne reflètent pas toujours « des décisions de conception ». Ce sont souvent juste des erreurs, peu importe à quel point ils pourraient être irresponsables ou indignes. Ainsi quand une décision ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique. Une équipe peut souhaiter un nouvel environnement ou un module d’extension, mais ne pas les fournir n’est pas de la  » dette technique », puisque cela ne met pas en danger la qualité du produit lui-même. Cela pourrait très bien réduire la vitesse de développement, parce qu’ils doivent boitiller en utilisant une vieille plate-forme de développement, mais c’est un problème différent.

Dans Scrum, l’attente consiste en ce qu’une définition de DONE (fait) devrait être suffisamment robuste pour que des niveaux ingérables de dette ne puissent pas s’accumuler. De là, si on sait que la dette technique va augmenter, la définition de DONE devrait être revisitée. Il est essentiel de découvrir pourquoi la dette est encourue et comment cela peut être évité.

Il y a certain nombre d’autres contrôles qui peuvent être utilisés pour limiter la dette.

Par exemple, une équipe devrait tenir compte du « refactoring » (et bien d’autres tâches) en décidant de combien de travail ils peuvent embarquer dans un Arriéré de Sprint sans mettre en péril la qualité à long terme. Mais en dehors de ces contrôles et recherches d’équilibre, il n’y a aucune prescription sur comment la dette technique devrait être traitée une fois que vous l’avez. Ce n’est pas une inadvertance, puisque Scrum est délibérément aussi non-normative que possible. C’est une structure de travail qui laissent aux équipes la décision de comment elles la mettent en œuvre.

finiNotez cependant que mettre en œuvre « des sprints spéciaux » pour nettoyer la dette technique n’est pas une option. Des sprints techniques de dettes, aussi mentionnés comme des sprints de solidification ou renforcement, sont essentiellement un anti-modèle. Chaque Sprint doit apporter un incrément de valeur véritable. C’est pourquoi la Définition de DONE est le rempart primaire contre l’accroissement de la dette en premier lieu.

Ce que font certaines équipes est de maintenir un registre de dettes techniques

Dans ce registre les décisions de conception qui mènent à de la dette peuvent être rationalisées. Vous pouvez penser à ce registre comme un registre RAID (Risques, Assomptions, Issues & problèmes, et Dépendances) qui est sous le contrôle de l’équipe. L’équipe y détaille les conséquences techniques de décisions prises de manières opportunes sur la qualité de mise en œuvre du produit, souvent en termes de probabilité, d’impact et de remédiations envisagées. Il peut être possible de recommander de l’adresser pendant un Sprint, si l’équipe a une compréhension suffisante de l’Arriéré de Produit. Suppositions et dépendances peuvent aussi entrer dans le registre et bien sûr quelques risques peuvent finalement transformer en douloureux problèmes.

Un registre technique de dettes peut aider à informer des équipes de comment la dette encourue devrait être gérée. Ils peuvent prendre des décisions réfléchies et informées sur quand vraiment ajouter de la dette et quand au contraire la rembourser. L’utilisation d’un tel registre ne fait pas partie de Scrum, mais néanmoins cette technique peut aider une équipe à prendre en main la dette technique qu’ils décident d’accepter. Parfois, par exemple, la dette technique peut être réglée en mettant en œuvre des histoires de l’arriéré de produit. Dans d’autres cas pas, et la dette doit alors être adressée séparément.

Que faire ?

Certains cas de dette peuvent devoir être exposés au Propriétaire de Produit pour leur prise en considération et d’autres pas. Dans les cas sévères, de la dette technique peut avoir été accumulée qui excède la valeur du projet lui-même, probablement même de multiples fois. Dans de tels cas extrêmes, l’approche la plus pragmatique peut être de tuer le projet et repartir de zéro. Inutile de le dire, cette variation de « échouer maintenant plutôt que plus tard » nécessite un courage extrême.

remboursez graduellement votre dette

Une autre option quand on fait face à une dette technique substantielle est de la réduire graduellement, Sprint après Sprint. L’équipe peut devoir s’entendre avec le Propriétaire de Produit pour livrer quelque chose, à chaque itération, qui fournisse tout de même une valeur suffisante aux parties prenantes. Clairement ce n’est pas une excellente option. Elle peut se terminer en marchandages, où la magnitude et la propriété du problème de la dette ne sont pas reconnues ni rendues visibles des parties prenantes. La dette technique devient alors plus d’un cas de problème technique. Les parties affectées pourraient être encouragées à fermer les yeux tant qu’elles obtiennent quelque chose de valeur immédiate pour le business en retour, mais aucun de ceci n’est bon pour la franchise, la confiance ni la transparence.

Maintenant, bien qu’ayant comparé un registre technique de dettes à un registre RAID, je ne suggère pas qu’il doive prendre la forme « documentée » habituelle de celui-ci. Selon mon expérience, il est généralement meilleur d’utiliser un « Information Radiator ». Parfois, cela peut être aussi rudimentaire qu’une feuille de papier scotchée au dos de la chaise du ScrumMaster, mais je préfère proposer aux équipes d’utiliser un mur de cartes dédié à cette fin. Les statuts typiques sont : A faire, En cours, Fait et A escalader. Les articles sont Faits quand ils sont ou atténués ou acceptés.

Incidemment, cela marche aussi pour les registres RAID conventionnels au niveau du projet et du programme. L’escalade depuis un Registre de Dettes Techniques impliquerait sa promotion à un tel niveau. Les managers sont ainsi encouragés à prendre un intérêt actif dans ces registres et questionner tout problème non remonté qui semblent bloqué.

Cela peut être une excellente façon d’encourager le « gemba » chez les managers, où ils sortent du bureau, s’y promènent, mettent leurs liens hiérarchiques et filtres de côté et voient la réalité des choses par eux-mêmes.

CertYou est partenaire de DantotsuPM

Pour aller plus loin, relisez ces précédents billets sur ce sujet

 

19 Juillet – Montréal #PMI® – Comment gérer la dette technique ?

Les bonnes pratiques de l’Agile Alliance

Ward Cunningham, un des auteurs du manifeste agile, a comparé l’ensemble des problèmes dans le code à une dette financière, et l’a appelé dette technique.

Qu’est que la dette technique ? Comment l’évaluer ? Comment prendre des décisions rationnelles et comment gérer la dette technique ? Il y a-t-il d’autres types de dette à prendre en compte ?

L’initiative “Technical Debt” de l’Agile Alliance a été lancée pour répondre à ces questions. La présence à Montréal des membres de ce programme est l’occasion de présenter des bonnes pratiques, le modèle A2DAM et d’organiser une session du jeu “Dice of Debt”.

Pour cette session, seront présents :

  • le livre de Chris Sterling

    Declan Whelan, un des membres à l’origine de cette initiative. Il est coach agile et membre du board de l’Agile Alliance.

  • Jean-Louis Letouzey, leader de l’initiative, il est l’auteur de la méthode SQALE pour manager la dette technique.
  • Tom Grant, auteur du jeu “Dice of Debt game” a été le directeur de la pratique agile du Cutter Consortium. Il a participé à l’Analyst Panel d’Agile 2015 – En plus de son expertise agile, il est expert en serious games.
  • Jean-Pierre Fayolle est consultant en qualité des logiciels. Il est l’animateur du blog “Qualilogy”
  • Dan Sturtevant, chercheur étudiant la qualité des logiciels  et son impact financier à la Harvard University, et CEO de Silverthread, Inc.
  • Thierry Coq, consultant principal et directeur de projet pour les systèmes industriels, pétrole et gaz et maritimes chez DNVGL

réservation

PMI is a registered mark of Project Management Institute, Inc.

April 5 – Webinar – Scrum Teams Don’t Think About Architecture

Dispelling this Myth with ScrumPulse

Upcoming Webcasts

Many groups developing software products wonder how Scrum Teams build products that don’t devolve into an architectural mess. How do we prevent the re-work that comes from teams hacking bits together all the time? How do I keep multiple teams from building the same thing in different areas that I now have to maintain? How do teams keep their architecture structurally sound when the systems are continuously evolving? How do we plan for scaling and the cloud if we don’t design our architecture up front?

Join the panel of Professional Scrum Trainers (Peter Gotz, Gary Pedretti, Fredrik Wendt and Rich Visotcky) as they discuss their real world experience and advice for building an architecture that evolves over time with purpose in its design and value creation at its core.

They’ll share patterns and tips for making your current architecture transparent with minimal investment so that Development Teams can keep the quality of their work high and stay focused on delivering valuable products to consumers.

Register

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Les enregistrements des ScrumPulse Webcasts sont accessibles gratuitement pour aider les débutants #Scrum et permettre aux plus expérimentés de s’améliorer !

Les initiateurs, experts et formateurs sur la méthode Scrum et surtout sur les attitudes Agile y partagent leurs expériences.

En sus de ces webcasts, le site Scrum.org vous permet de visionner des vidéos et lire des papiers d’étude et articles de blog sur l’agilité et plus spécifiquement sur Scrum.

Scrum and Upcoming Agile Webcasts
Scrum and Upcoming Agile Webcasts

#22 – Management 3.0 & Scrum:  How to Become a Next Generation Leader

#21 – Women in Agile: Empowering the next Generation of Influencers

#20 – Software Craftmanship in Professional Scrum

#19 – Role of a Scrum Master (Special Spanish Edition)

#18 – Software Ethics Panel Discussion

#17 – Transforming a 25,000+ Person Consulting Company to Become More Agile

#16 – Multicultural Scrum the Impact of Culture on Living the Scrum Values

#15 – Myths, Misconception & Mysteries of Product Ownership

#14 – Scrum Guide Refresh July 2016

#13 – Scaling Professional Scrum with Visual Studio Team Services

#12 – Cage Fight:  Product Owner vs. Product Manager

#11 – The Core Protocols

#10 – We’re Moving to Agile:  What Are Our Testers Going to Do?

#9 – Organizational Improvement: Using a Framework to Guide Your Change

#8 – Challenges in the Development Team

#7 – How to Ship Your Software with Confidence and Speed

#6 – Psychological Models in Scrum

#5 – Agile Metrics

#4 – Self Managing Teams: 4 Building Blocks and an Evidence Based Approach

#3 – Scaling Scrum and Agility

#2 – Transparency in the Trenches

#1 – Dealing with Technical Debt

CertYou est partenaire de DantotsuPM
CertYou est partenaire de DantotsuPM

Enregistrer

bonne résolution de fin d’année: remboursez votre « dette technique » !

Nous sommes devenus une société de débiteurs, dans nos vies comme dans nos projets informatiques !

Technical Debt : No penalty for early payment posté Par Jon sur le blog de Cast Software

empty pocketsNous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.

Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.

Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »

bonhom-boulet
Le boulet de la dette technique peut vous empêcher d’avancer.

Derek remarque aussi que tout comme toute dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre : Elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement l’équipe de support technique ou quelqu’un d’autre en aval.

Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui jetterait les dés pour décider de votre taux d’intérêt. Alors, si vous n’êtes pas obligés de prendre ce risque, ne le prenez pas.

Mais la dette technique est-elle vraiment une proposition de type tout ou rien, blanc ou noir ?

Combien est assez ?

bonhom-calculator-business
Calculez le coût de votre dette technique

Quand elle considère la Dette Technique, une société doit déterminer combien devrait être investit pour y  remédier. La meilleure façon de le faire est en donnant une valeur monétaire à la dette technique pour allouer une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques à rembourser cette dette par rapport aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant de contracter cette dette.

Le but de monétiser la dette technique est de limiter le nombre de violations de la qualité structurelle, ou ce qui est plus important, le coût de les réparer, bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Un plan d’action pour la Dette Technique

Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.

Bill Curtis
Bill Curtis

La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.

technical-debt-software-qualityUne fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.

bonhom-travaux-roadworks
Le remboursement de la dette technique demande parfois des travaux importants

La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite de devoir payer plein d’intérêts.

De plus, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.

Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Le rapport CRASH de CAST Software révèle les réels impacts du développement Agile

impact objectif des méthodes agiles, de l’externalisation et de l’offshoring: des évidences mais aussi de l’inattendu !

Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.

Télécharger le rapport CRASH

L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.

Crash Report 2015

Les principales conclusions sont pour certaines évidentes, d’autres bien plus surprenantes.

  • l’intégrité architecturale d’une application affecte sa sécurité,
  • les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
  • la maturité des processus (niveau CMM) affecte la qualité générale du code,
  • les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
  • les équipes internes et externalisées fournissent la même qualité de code,
  • l’offshoring impacte la robustesse et l’évolutivité des applications.
Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Précédentes éditions:

ne vous précipitez pas sur la dette (technique) par Jeff Ball

Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.

facturesMS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.

Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.

La Dette Technique peut prendre les formes suivantes:

  • developer womanDocumentation ou manuel d’utilisation inexistants
  • Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
  • Bases de données mal structurées (données redondantes, erreurs de données)
  • Mauvaise conception (mauvaise architecture, non modulable)
  • Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)

Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.

Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.

Plusieurs facteurs peuvent être source de dette :

  • Image courtesy of ambro / FreeDigitalPhotos.net
    Image courtesy of ambro / FreeDigitalPhotos.net

    La vitesse: la précipitation est probablement la première cause de Dette Technique

  • Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
  • Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
  • Innovation de pointe : apprentissage sur le tas
  • Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.

Pourquoi s’en inquiéter?

La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.

Ne vous précipitez pas sur la dette.

le livre de Chris Sterling
le livre de Chris Sterling

La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.

Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.

Pourquoi utiliser Agile?

APMG-AgilePMLes méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).

Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.

Jeff Ball
Jeff Ball

Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :

  1. Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
  2. Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
  3. Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).
Partenaire de DantotsuPM

© Copyright QRP International 2011. Reproduction in full or part is prohibited without prior consent from QRP International

Pour aller plus loin:

10 Octobre – Paris – Matinée CIO de CAST avec le CRASH Report 2014

Dans l’étude 2014 de CAST sur la qualité logicielle des applications (CRASH), les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises montrent l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.

Cast 10 Octobre 2014
Enregistrez-vous

L’étude montre notamment que:

  • Téléchargez le rapport
    Téléchargez le rapport

    l’intégrité architecturale d’une application affecte sa sécurité,

  • les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
  • la maturité des processus (niveau CMM) affecte la qualité générale du code,
  • les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
  • les équipes internes et externalisées fournissent la même qualité de code,
  • l’offshoring impacte la robustesse et l’évolutivité des applications.

L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.

Pour télécharger les principaux résultats de l’étude (en anglais), cliquez ici.

Les résultats de cette étude seront également présentés lors de la Matinée CIO de CAST le 10 octobre prochain, parmi d’autres interventions de DSI et d’experts.
— Programme détaillé et inscription —

August 14 – Webinar – Dealing with Technical Debt: Avoiding Technical Bankruptcy

A free monthly webcast by Scrum.org Professional Scrum Trainers addressing common challenges faced by the software profession.

Scrum and Agile Webcasts
Scrum and Agile Webcasts

with Mark Noneman on August 14, 2014 10am-11am EST 16:00 CET/FRANCE

The phrase “technical debt” has become a commonly used phrase in software development.

technical debtTechnical debit is analogous to financial debt; build up too much and you’ll start paying more in “interest” and “principle” than you can invest in future value. This webinar will discuss what technical debt is, what causes it, and how to deal with it. Both management and engineering techniques in an agile development environment will be reviewed.

These sessions are broadcast live, completely free, and available to anyone around the world – though space in each session is limited!

SAVE MY SPOT

23-24 Mai – Paris – Agile France 2013

conf agile france 2013Agile France aura lieu les jeudi 23 et vendredi 24 mai 2013 au Chalet de la Porte Jaune

Le but : permettre aux praticiens avancés de se réunir et d’échanger pour apprendre en dehors des sentiers battus.

Consultez le programme.

Une petite intro vidéo de Olivier Soudieux, notre ami explorateur Agile !

Encore une fois, Agile France va marquer les mémoires. Au vu de la sélection, 2013 sera un grand cru ! N’oubliez pas de réserver vos places.

Encore une fois, Agile France va marquer les mémoires. Au vu de la sélection, 2013 sera un grand cru ! N’oubliez pas de réserver vos places.

Un avant-goût de ces sessions!!!

Jeudi 23 Mai

Un produit qui déchire, une équipe qui déchire… un leader qui déchire

David Alia
David Alia

David Alia (@davidalia)
Découvrez les principes qui permettent à un leader de créer pour son équipe un environnement propice à l’innovation, une culture d’amélioration continue et de confiance mutuelle. Comment l’aider à se mettre dans une succession permanente d’équilibres instables entre challenge et stabilité, entre enjeux et plaisir, à conserver un sens aigu de l’initiative, une motivation à toujours faire mieux, individuellement et collectivement ?

Le Respect en Action

Jonathan Scher (@jonathan_scher) et Cyrille Deruel (@CyrilleDeruel)
Vous connaissez ces équipes dans une spirale descendante : les seules phrases qui sortent viennent du désespoir. Encore un bug, ça ne marche toujours pas, je n’arrive pas…

Travaillant comme consultants, ce cas nous est arrivé plusieurs fois. Nous avons maintenant une méthode : nous remettons en place les bases du respect. En moins de 6 semaines, l’équipe est à nouveau pleine d’espoir, productive. Nous vous présenterons notre vision du modèle des trois CO – communication, considération, et coopération, ainsi que notre démarche inspirée de celle de Kotter pour sa mise en application.

Indiana Jones et le temple du Legacy Code

Mathieu Gandin (@octomga)
Selon The Economics Of Software Maintenance In The 21 Century, nous passons 80% de notre temps à maintenir du code existant et pénible à modifier. Dans cette situation nous devenons des archéologues du code, tandis que les contraintes de temps se font plus fortes. On parle alors de code Legacy.

A l’issue de cette session vous repartirez avec :

Une longue séance de livecoding pour présenter des techniques pour tester et remanier du code en profondeur
Une introduction à une démarche pour avoir une vue d’ensemble de votre gros code legacy
Une présentation de la matrice de gestion du temps de Covey pour vous organiser sur le long terme dans la reprise de votre code legacy

Clean Code Game

cleanMichel Domenjoud et Mathieu Gandin (@octomga)
Maintenir une base de code propre et bien testé est un facteur clé de succès de la réalisation d’un produit. Mais avant d’en arriver là, il convient, en tant que développeur, d’adopter une certaine discipline en terme de refactoring de code.

Pendant cet atelier de 3h nous aurons l’occasion de vous faire coder et reprendre du code existant pour en faire du beau code en suivant des principes énoncés par Robert Martin dans le livre Clean Code. Et vous verrez que plus votre code sera propre, plus vous serez productif.

Vendredi 24 mai

Communautés de pratique en pratique

Cyrille Deruel (@CyrilleDeruel)
Vous rêvez d’avoir des réunions où les développeurs échangent leurs techniques, présentent leurs dernières trouvailles, les derniers frameworks utilisés, où les testeurs partagent leurs douleurs et leurs solutions, où des personnes échangent autour de différentes problématiques ?

Ne cherchez plus : Créez des communautés de pratique.

Découvrez à travers cette session comment créer des communautés de pratique auto-organisées, quels outils j’utilise pour garantir l’auto-organisation et surtout quelles règles de communication j’utilise.

Les paradoxes du leadership

Marc Cherfi (@reporter4change) et Thomas Lissajoux
CB103557Vous êtes un manager, un coach ou un leader. En tout cas vous êtes un agent de changement et vous faites de votre mieux. Pourtant, parfois, la résistance et les frictions semblent inévitables et les résultats sont au mieux passables, quand la situation ne dégénère pas ou se verrouille.

Nous analyserons les forces en jeu et présenterons les leçons que nous en avons tiré, en essayant de proposer des pistes pour débloquer ces situations.

A l’issue de cette session, vous aurez :

  • découvert des exemples concrets de situations où rien ne semble marcher,
  • appris à identifier ce genre de situations et de comportements paradoxaux,
  • compris les forces en jeu pour prendre du recul,
  • des options à votre disposition pour essayer de les débloquer.

Des métaphores qui nous transforment

Microsoft Project
Partenaire de DantotsuPM

Christophe Thibaut (@ToF_)
Dans notre domaine il semble qu’il y ait un process pour tout, et même l’agile, en dépit des proclamations, est l’occasion d’un retour sempiternel au process, aux outils, aux recettes.

Dans cette session j’aimerais vous inviter à quitter le règne conceptuel afin de découvrir le surprenant pouvoir des métaphores. Plus qu’une simple figure de discours, la métaphore structure notre pensée et nos actions, elle définit notre réalité. En (re-)découvrant dans leur portée et leur profondeur les métaphores qui nous gouvernent, pouvons nous transformer nos projets ?

Tester autrement : Le Guide du Testeur Intergalactique

Rémy-Christophe Schermesser (@El_Picador)
Vous connaissez déjà TDD, votre couverture de code frise les 80 %, jUnit n’a plus de secret pour vous ? Mais vous sentez que vous pourriez faire plus de vos tests, que les outils que vous utilisez ont des limites. Ou alors vous en avez marre du train train assertEquals ?

Pas de panique ! Nous allons voir ensemble comment faire des tests unitaires autrement. Nous traiterons entre autres :

  • Le Mutation Testing
  • Le BDD, Behaviour Driven Development
  • Le Property Testing.