Chacun sa méthode, chacun son problème !

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Souvent lorsque les gens me parlent des méthodologies Agiles, ils font rapidement référence à SCRUM ou Extrem Programming (XP). Mais, il en existe beaucoup plus que cela.

Chacune des méthodes adressent une problématique, chacun son problème. Par exemple, SCRUM adresse la capacité de la livraison d’un logiciel en développement. Je sais, je résume de manière très simpliste. Mais, mon propos n’est pas de parler de SCRUM en particulier.

Mais, il existe plusieurs tâches ou problèmes qu’on peut adresser avec les méthodologies Agiles. À la base des méthodologies Agiles, c’est le Manifeste Agile et aussi de bonnes pratiques de développement logiciels.

Il ne faut jamais chercher à prendre une implémentation des principes du Manifeste Agile comme un couteau suisse, mais comme une lame ou un outil de celui-ci. Si vous prenez soin de bien identifier le problème que vous voulez résoudre.

Mais trop souvent, les gens cherchent une méthode qui va solutionné leur problème, sans vraiment le connaître. Lorsque mon auto a problème, je demande à mon mécanicien de faire un diagnostique, pas juste changé la batterie ou l’huile de la voiture.

Si vous ne savez pas exactement ce qu’est votre problème, faites comme avec votre voiture, demandé l’aide d’un ou de plusieurs spécialistes qui vous aidera à choisir la bonne méthode.

Il me serait facile de vous faire une liste de problèmes typiques avec leur solution, leur méthode qui pourrait le résoudre. Mais, ça irait à ‘inverse de ma philosophie et à l’opposer des principes des méthodologies Agiles. À besoin, fait comme je le recommande dans cet article « Un chef et son buffet de services, un buffet de services agiles» inventer la vôtre !

  1. goupils
    mai 26, 2011 à 1:40

    Bonjour,

    Je viens de découvrir ce blog à l’instant et je voulais juste profiter de ce billet pour faire part de mon expérience personnelle. Je travaille sur des projets multimédia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE.
    Et je dis: Attention car un effet de mode s’est emparé de notre industrie en vendant les bienfaits d’une méthodologie dont le nom semblait séduisant mais le retour d’expérience a été un peu cuisant pour plusieurs prestataires
    – Dans le cadre d’un projet au forfait avec des paiements liés aux livrables mensuels, continuer d’imposer une phase de spécification du projet (80%) pour garantir vos rentrées d’argent. En vendant le principe que client peut redéfinir ses besoins et les affiner à chaque itération, il trouve cela très plaisant et c’est très constructif pour l’équipe, mais il ne le fait pas pour les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être fait car le contrat n’est pas respecté à la lettre. Le Product Owner (client) que vous impliquez dans votre méthodologie n’est pas nécessairement le décisionnaire et cette méthodologie peut rapidement vous étouffer financièrement

    – Conservez la notion de Chef de Projet au SCRUM MASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une structure de lead technique, lead artiste, lead ergonome … avec des strates (de senior à junior). Un jour la problématique des responsabilités individuelles viendra sur la table et la notion d’équipe unifiée explose à ce moment.
    Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver un système d’évaluation des individus sur le long terme. Ce n’est pas le chef de projet, mais bien les leads qui vont évaluer les juniors ( en cas de primes ou de promotion)
    – ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement car le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme les notre, de formaliser un feedback et nous le communiquer) Entre temps l’équipe à avancer dans la mauvaise direction et c’est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et toujours le faire faire par écrit
    – Ne négliger pas la documentation, les réunions stand-up meeting ont la fâcheuse tendance de ne laisser aucunes traces. Réduisez les à l’essentielle et laisser les leads organiser des réunions métier avec un COMPTE RENDU à la clef … ce qui permet aux gens de s’y référer si un problème resurgit et une décision déjà prise

  1. mars 15, 2011 à 1:33
  2. avril 19, 2011 à 7:38

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

%d blogueurs aiment cette page :