Benoit Grégoire Directeur Général, Savoirfaire Linux...

Preview:

Citation preview

   

Réaliser les bénéfices des méthodes agiles

Benoit GrégoireDirecteur Général, Savoir­faire Linuxbenoit.gregoire@savoirfairelinux.com

 

 

Pourquoi cette conférence

L'informatique, une famille de professions encore en devenir.

 

 

Les méthodes agiles pour le web?

Qu'est­ce qui est particulier au web

Taille des projets

La phase « sans interface usager » est très courte

Omniprésence des bases de donnée

Les besoins sont souvent subjectifs

Cycles de maintenances particuliers

Déploiement facile

Des délais impossible et des spécifications vagues

 

 

À qui elle ne s'adresse PAS

One man show

Et je n'ai rien contre les one man show

 

 

Pourquoi choisir les méthodes agiles

Bien appliquées, les méthodes agiles permettent de maximiser la valeur obtenue pour les ressources que l'on choisit d'investir

L'investissement comprends les ressources internes.

Les méthodes agiles permettent de dormir le soir

 

 

Les méthodes agiles: Grands principes

Individus et interactions vs. Processus et outils

Logiciel qui fonctionne vs. Documentation exhaustive

Collaboration du client vs. Négociation de contrat

Réponse au changement vs. Suivi d'un plan prédéfini

 

 

Les méthodes agiles

Des mythes ayant la vie dure

Les méthodes agiles ne doivent pas servir de rationalisation pour faire n'importe quoi, sinon...

 

 

Sinon...

On doit plutôt parler d'excuses agiles...

 

 

Éviter les processus complexes

Au moins au début

Peut­être toujours avec la rotation de personnel

Un processus que tous peuvent comprendre est supérieur à n'importe quel système complexe.

 

 

À partir de quelle taille une méthodologie agile complète est­elle souhaitable?

Certains éléments devraient être appliqué dans tous les cas (ne serais­ce que pour garder l'habitude).

3 personnes (incluant le client), 3 itérations méritent le processus complet.

 

 

La méthode Scrum

 

 

Le vocabulaire est un obstacle à l'adoption efficace.

Itération, et non Scrum

Appel quotidien et non Daily Scrum meeting

Éliminer les titres

Estimés en heures, et non en points

Se concentrer sur les similitudes, et non les différences

 

 

Les « réunions » quotidienne

3 ou 5 questions

Pas de discussion

 

 

Les cinq questions

Qu'est­ce que j'ai fait hier?

Qu'est­ce que je compte faire aujourd'hui?

Quelles difficultés est­ce que je rencontre?

Des tâches à ajouter à la liste de l'iteration courante?

Est­ce que j'ai appris ou décidé quelque chose d'intérêt pour les autres membres de l'équipe?

 

 

La réunion d'itération

 

 

Les artéfacts

Backlogs (incluent les estimés)

Liste de tickets pour le produit

Liste de tickets pour l'itération

Burndown (ce n'est pas une courbe en S)

 

 

La présence du client dans le processus

Une personne représentant le client, et ayant une autorité suffisante est essentielle pour les pleins bénéfices.

Pas nécessairement à temps plein, mais doit être disponible au quotidien (selon la taille du projet) 

 

 

Comment choisir quoi faire à chaque itération

D'abord les tâche les plus critiques

En résumé, toujours choisir comme si c'était la dernière itération

Personne ne peux faire un estimé précis sur une très longue période

 

 

Impacts

Analyse

Design

 

 

Adapter les outils

Mais surtout ne pas tout changer

Lorsque l'on a un marteau, tout a l'air d'un clou!

Et alors?  Si votre employé est productif, laissez lui son marteau

Ce qui ne veut pas dire qu'il faut standardiser sur le marteau

 

 

Spécifiquement

Éviter les micro­ticket

Mettre à jour les estimés constamment est un facteur de succès.

 

 

L'implication du client et du fournisseur est essentielle

Responsabiliser les individus

L'honnêteté est essentielle

Une discipline essentielle à maintenir

Il est possible de s'adapter à une équipe et à un environnement physique inhabituel

 

 

Vaincre l'insécurité du gestionnaire

Mon client voit toutes mes gaffes

Mon client voit mon taux horaire réel

Je perds la gestion du projet.  Dans un sens oui, mais vous y gagnez énormément en ayant une idée réaliste de ce qui se passe, et où c'en est

 

 

Vaincre l'insécurité du client

Plus difficile la première fois

 

 

Vous (ou votre patron/client) n'est pas convaincu?

Non, je n'ai jamais rencontré M.Larman, et je ne reçois pas de commission...

 

 

La réalité: appels d'offre et vision traditionnelle des projets

Sert surtout à donner aux gestionnaires une impression de contrôle

Ou reformulé:  Ma méthode agile n'entre même pas sur le formulaire

 

 

Estimés

Pas de diagramme de Gantt?  Quelques nuances, mais en général, enlève le projet informatique du chemin critique.

Le client veux trois chose:

Respecter le budget

Respecter les échéanciers

Avoir un système qui réponds à ses besoins

Les deux premières sont normalement garantie, reste à savoir si votre méthode vous aide à avoir la dernière

 

 

C'est bien beau, mais comment je remplis une soumission

Estimation agile

Pas toujours applicable

Sinon, l'expérience et l'instinct sont bonne conseillère:  le temps à investir pour arriver à quelque chose de plus précis est il payant?

Soyons honnêtes, le prix sur votre soumission n'est pas une résultat direct de votre estimation

 

 

Contrats

Forfaitaire

À l'heure

Éviter d'avoir des requis non­agiles 

 

 

Les difficultés:  S'assurer de ne pas tomber dans la paperasse

 

 

Facteurs de succès

Adoption à la grandeur de l'organisation

Pratiquement impossible si on essaie de tout définir dans le détail

Qu'en est­il de la qualité technique du code

Scrum s'intéresse d'abord au cadre de travail.

Il ne remplace pas à lui seul l'expérience des développeurs, ou le développement orienté test.

Au moins, il est assez facile à comprendre pour un développeur junior

 

 

Quelques mots sur les tests

 

 

Qu'en est­il de la qualité technique du code

Scrum s'intéresse d'abord au cadre de travail.

Il ne remplace pas à lui seul l'expérience des développeurs, ou le développement orienté test.

Recommended