Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Kangoo's Blog

Le blog de Guillaume Belmas: Cloud Computing, Industrialisation
et Imagine Cup...

Actualités

  • Logo MVP


    View Guillaume Belmas's profile on LinkedIn


[PDC 2008] Agile Perspectives, Industry and Microsoft

<bla bla>
J'ai l'opportunité d'être présent cette semaine à Los Angeles pour la Microsoft PDC 2008 (merci Exakis et Microsoft). J'essayerai, en fonction du niveau de batterie de mon portable, du wifi disponible, de la pertinence du sujet, des conditions de rédaction d'un post et de ma motivation globale, de vous faire quelques retours de ce que je pourrai apprendre ici Smile
Premier edit : je sais, j'ai un train de retard puisque je parle des pré-conf alors que le keynote est déjà passé
</bla bla>

Aujourd'hui, par une belle journée ensoleillée, se déroulent les pré-conférences. Pour ma part, j'assiste à la pré-conférence sur l'agilité :

Sujet vaste et très intéressant, mais il m'est difficile ici de vous retranscrire l'intégralité de la journée. Je vais donc focaliser sur la matinée qui a été consacrée à un (gros) retour d'expérience (de plus de 2h) sur l'agilité et les méthodes de manière générale de la part de Mary Poppendieck (qui a débuté sa carrière en tant que développeuse en 1968, ce qui lui confère donc quelques années d'expérience).

Ce que je retiens de cette session : 

Certains principes méthodologiques et organisationnels que l'on peut croire "flambant neuf" sont en fait des principes relevés par l'industrie depuis des décénnies. Cependant, il y a toujours un gap plus ou moins important entre la théorie et la mise en pratique. C'est alors le pragmatisme et le bon sens qui rentrent en jeu.

Je vous livre ici certaines notes organisées en deux grandes catégories : Ce qui fonctionne et ce qui ne fonctionne pas. Je laisse volontairement certains termes en anglais.

Ce qui fonctionne

  • Les "Technical Practices"
    • Au travers d'un exemple concert (un projet mené en 1972 par le NY Times nommé "NY Times Information Bank"), nous avons pu parcourir quelques retours d'expérience qui ne seront pas sous vous rappeler quelques préceptes qui sont toujours d'actualité
      • "Quality by Design" : Etablir la qualité voulue avant le projet et non au moment de tester le projet. Chercher les bugs en fin de dev au lieu de les éviter pendant le dev est une sale habitude qui impacte la qualité des développements et la productivité des équipes
      • L'intégration continue (et oui déjà à l'époque) : Tester la qualité du logiciel en parallèle de la phase de développement. Tout ce qui est testable doit l'être le plus tôt possible.
      • Le concept de "Chief Programmer Team" (les amateurs d'eXtreme Programming vont apprécier !)
        • Un lead developpeur et son backup tous les deux impliqués dans le design et le développement de l'application
        • Chacun relit le code de l'autre et chacun et capable de prendre le relais de l'autre sur une tâche
        • Mise en commun du code source (au sein d'un référentiel central) : tout le monde connait le code produit et peut donc intervenir dessus
    • Conclusion sur ce projet : cela a été un succès. 21 bug trouvés lors de la recette et seulement 25 lors de la première année d'exploitation (le projet était important mais le volume de jour/homme n'a pas été précisé).
  • Le "Pull Scheduling"
    • Il faut Timebox-er et non Scopebox-er. J'ai bien apprécié cette slide car, même si elle ne fait que mettre en évidence une situation à laquelle on se retrouve confronté quotidiennement, elle exprime bien le fait qu'il faut être conscient (désolé pour la qualité de l'image).

PICT1438

    • Comme on le voit dans l'image ici, il faudrait, dans la mesure du possible, ne pas se demander combien de temps cela va nous prendre de réaliser une application mais plutôt, qu'est-ce que je peux faire pour une date donnée. C'est le fondement même du principe d'itération qui font constitue les méthodes agiles (MSF, SCRUM...)
    • La capacité de production d'une équipe est très souvent inférieure à la demande reçue en amont. De ce constat : ne croyez pas que vous pourrez tout faire car il y a forcément des choses qui "passeront à la trappe". Dans la pratique, cela consiste à prioriser les actions. Prioriser en permanence permet au final de s'assurer que tout ce qui est important en termes de fonctionnalités ou d'impératif technique n'est pas justement "passé à la trappe".

Ce qui ne fonctionne pas

  • Les worst practices (pour l'estimation et la planification de projets)
    • Faire les même choses encore et toujours et s'attendre à des resultats différents à chaque fois
      • Comprendre : "Faire un projet à l'arrache donnera invariablement un résultat à la hauteur du projet : un résultat à l'arrache".
      • J'ai beaucoup aimé la remarque du speaker par rapport à ça : "C'est exactement la définition qu'Einstein avait pour le mot "Démence"" Smile
    • Prendre des décisions sans avoir de données pour la prendre
      • Si le projet est représenté par un bateau, c'est un peu comme naviguer à vue en pleine brume...
      • Tellement évident, mais tellement vrai sur énormément de projets...
    • Perdre les connaissances du projet
      • Le fait de se dire : "on s'en souviendra la prochaine fois" signifie que vous referez la même erreur.
      • La pertes des connaissances vient le plus souvent du fait qu'on ne prend jamais le temps de formaliser cette connaissance, par exemple, en l'écrivant.
  • La complexité (les amateurs d'XP vont encore apprécier)
    • Idée n° 1 : le changement n'est pas l'ennemi d'un projet. Il en fait partie, il faut faire avec.
    • Idée n° 2 : la complexité EST le véritable ennemi
    • Idée n° 3 : Ne soyez pas dupes ! La complexité est VRAIMENT l'ennemi (ennemi des tests, ennemi de la maintenance...)
    • Exemple de complexité : les fonctionnalités supplémentaires d'un composant générique donné.
      • généralement seulement 20% des fonctionnalités sont systématiquement utilisées (c'est là on comprend qu'il faut prioriser sans cesse lors d'un projet)
      • Généralement 50% des fonctionnalités ne sont JAMAIS utilisées
      • Cela ne veut pas dire qu'il ne faut pas faire de composant générique : on peut penser une architecture générique sans pour autant implémenter l'intégralité des fonctionnalités qu'on imagine
    • Conclusion sur la complexité : Vous voulez être plus productif ? Codez moins ! Smile

Voilà, le post peut paraitre un peu indigeste mais la session était un bon constat qui permettait de poser les bases pour les discussion sur la fameuse agilité prônée par les méthodes du même nom.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: dimanche 26 octobre 2008 15:08 par Kangoo
Classé sous :

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- « Naviguer vers le haut » dans une librairie SharePoint par Blog de Jérémy Jeanson le 10-07-2014, 13:21

- PowerShell: Comment mixer NAGIOS et PowerShell pour le monitoring applicatif par Blog Technique de Romelard Fabrice le 10-07-2014, 11:43

- ReBUILD 2014 : les présentations par Le blog de Patrick [MVP Office 365] le 10-06-2014, 09:15

- II6 Management Compatibility présente dans Windows Server Technical Preview avec IIS8 par Blog de Jérémy Jeanson le 10-05-2014, 17:37

- Soft Restart sur Windows Server Technical Preview par Blog de Jérémy Jeanson le 10-03-2014, 19:43

- Non, le certificat public du CA n’est pas un certificat client !!! par Blog de Jérémy Jeanson le 10-03-2014, 00:08

- Windows Server Technical Preview disponible via MSDN par Blog de Jérémy Jeanson le 10-02-2014, 19:05

- Focus Sauvegardes SharePoint par Le blog de Patrick [MVP Office 365] le 10-02-2014, 13:11

- Technofolies, votre évènement numérique de l'année par Le Blog (Vert) d'Arnaud JUND le 09-26-2014, 18:40

- Xamarin : From Zero to Hero par Fathi Bellahcene le 09-24-2014, 17:35