L’Approche Agile, présentée par Grigori Melnick

Lieu: Québec - École Nationale d’Administration Publique (ENAP) - Salle 4114

Ce que nous connaissons, ce que nous pensons connaître, et ce que nous avons besoin de connaître sur l’approche Agile. Le conférencier nous partagera son expérience et discutera des preuves empiriques de plusieurs mises en pratique de l’Agilité.

Pour en savoir plus sur le conférencier : http://pnpsummit.com/queb2008presenters.aspx
Vous pouvez également consulter son blogue : http://blogs.msdn.com/agile/default.aspx

NOTE: Conférence présentée en ANGLAIS seulement.

http://www.agilequebec.ca/Events/CAQEvents/362.aspx

Au cours des ans, j’ai été amené à décrire le Test Driven Development en utilisant trois règles simples :
1. Vous ne devez écrire du code de production que pour faire réussir un test qui échoue.
2. Vous ne devez écrire que le test unitaire que nécessaire pour échouer; les problèmes de compilation sont aussi considérés des échecs.
3. Vous ne devez écrire que code de production nécessaire pour faire réussir un test unitaire qui échoue.

Vous devez commencer par écrire un test unitaire pour la fonctionnalité que vous voulez développer. Mais la règle numéro deux vous empêche d’écrire un long test. Dès que le code du test échoue à la compilation ou à l’exécution, vous devez écrire le code de production. La règle numéro trois ne vous autorise à écrire seulement le code nécessaire pour que le test unitaire puisse compiler ou s’exécuter, rien de plus.

Lorsque vous réfléchissez, vous réalisez que vous ne pouvez pas écrire beaucoup de code avant de compiler et d’exécuter quelque chose. C’est exactement l’effet désiré. Que nous écrivions des tests unitaires ou du code de production ou si nous faisons du refactoring, nous devons exécuter l’application à tout moment. L’intervalle entre l’exécution des tests doit se compter en secondes ou minutes. Même 10 minutes est un intervalle trop long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Au-delà de ces règles spécifiques et des approches agiles, en tant que développeur j’ai toujours aimé vérifier fréquemment mon code, ceci rend beaucoup plus facile la détection des mes erreurs ;o

R.I.P. (en latin “requiescat in pace”) est une phrase que l’on peut voir sur certaines pierres tombales. Les projets informatiques ont souvent le même sort. Après la livraison, ce qui peut leur arriver de mieux est une petite célébration pour l’équipe. Personne ne se préoccupe d’examiner formellement le déroulement du projet, de comprendre ce qui a bien ou moins bien fonctionné, de trouver les causes de ces résultats de manière à formaliser et transmettre l’expérience acquise aux prochains projets. Il existe néanmoins une activité pour analyser les projets après leur fin. Cette activité est appelée analyse “post-mortem” (d’où la référence aux pierres tombales) ou “rétrospective” dans les approches agiles. Vous ne devez pas avoir honte si vous ne connaissez pas cette pratique. Moi-même, je ne l’ai jamais vue mise en oeuvre. Même dans l’enquête sur l’agilité réalisée par Version One où une large majorité des participants se réclament des approches agiles, seulement 39% utilisent cette pratique. Pourquoi?

La première explication est que le temps est une ressource considérée comme rare dans les services de développement. Il existe donc un sentiment d’urgence qui incite les gens à utiliser le temps disponible pour les activités qu’ils jugent les plus essentielles et il est difficile de faire rentrer la rétrospective dans le haut de ce classement. Il est déjà parfois difficile de faire admettre qu’il faut penser un peu avant de coder. Dès lors, essayer d’avoir du temps pour réfléchir après avoir codé peut sembler une utopie ;o). Il est aussi difficile pour un chef de projet de proposer d’utiliser des jours/hommes après la fin du projet pour examiner ce qui pourrait être amélioré. N’êtes-vous pas censés faire les choses parfaitement du premier coup?

Il est également difficile de créer un contexte de critique constructive. Ceci provient principalement de notre difficulté à dissocier les problèmes des personnes qui sont concernées. Ceci est un élément important dans les entreprises où une partie de la rémunération peut être liée à la réalisation de certains objectifs professionnels. Seriez-vous prêts à parler des problèmes rencontrés dans un projet si vous (ou un collègue) avez à un bonus lié à des objectifs de qualité? Peut-être pas….

Il existe cependant des techniques qui peuvent vous permettre de profiter des expériences vécues dans un projet sans créer de conflits personnels. Les articles ci-dessous (en anglais) sont des ressources intéressantes dans le domaine de l’analyse post-mortem ou  pour la pratique de rétrospectives.

Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)

Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)

Plan of Action by Bas Vodde (HTML)

Project “Post Mortem” Review Questions by Michael Greer (HTML)

A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)

Agile survey by Version One

Le monde d’aujourd’hui vous oblige à être - donc à devenir - à la fois adaptables et proactifs face au nouvel environnement économique, politique et social.

• Comment manager une équipe, un projet, une organisation face à la turbulence ?
• Comment concilier turbulence et performance ?

Pour y parvenir, les entreprises doivent mettre en oeuvre un autre mode de management afin de vaincre les différents obstacles qui croisent leur route. Ce nouveau mode de management porte un nom: L’AGILITE.

Plus d’information et inscription sur http://www.hortis.ch/seminaire-de-lagilite-a-la-performance-par-hortis/

En assistant à cet après-midi, au sein de l’Atelier BNP Paribas, lieu de veille et d’analyse des nouvelles technologies, vous allez :

• Positionner ces outils innovants sur le marché du test logiciel, anticiper sur leur utilisation future dans votre entreprise et les bénéfices associés
• Comprendre comment une approche outillée, basée sur des modèles générateurs de tests, révolutionne ces métiers.
• Découvrir les nouveaux acteurs de la chaîne de la qualité logicielle et les rôles qu’ils peuvent jouer auprès de votre organisation
• Découvrir le témoignage d’une entreprise utilisatrice de ces solutions
• Débattre avec des acteurs indiens de la mutation des métiers du test

Plus d’information et inscription sur http://www.atelier.fr/applications-it/3/26022008/nouveaux-habits-usine-test-logiciel-36105-.html