Publié par

Il y a 12 ans -

Temps de lecture 1 minute

Agile Tip n°4: Critères de vigilance

L’objectif de ce billet est de mettre en perspective les habitudes liées à la gestion de projet traditionnelle avec les principes structurants des méthodes agiles.
Il n’est certainement pas exhaustif et nous comptons sur la diligence des vos commentaires pour faire avancer le débat et compléter cette liste.
Nous consoliderons vos données et rédigerons un autre billet plus complet.

Nous avons scindé les impacts en deux catégories : Culture & Organisation.

Culture

Impact pressenti Habitude Principe Agile structurant
Relations MOE/MOA Relation client/fournisseur Négociation, priorisation, gestion collaborative, transparence
Relations MOE/MOA Etablir un plan et faire exécuter Confiance en l’équipe, autonomie
Responsabilités Etudes/exploitation Tester à la fin Test Driven Develoment
Implication du Management La DG ne s’implique pas ou peu sur les projets Besoin de la DG pour suppression des obstacles quels qu’ils soient
Relations MOE/MOA Formalisation/protection/justification Suppression de la documentation inutile
Relations MOE/MOA Se voir en cadrage de projet, moins après Disponibilité du Product Owner
Direction Générale/
Contrôle budgétaire
Piloter les projets par les coûts Piloter les projets par les fonctionnalités et la qualité à budget contraint
Relation avec les intégrateurs Forfait/contrat Achat d’une capacité à produire
Relation avec les intégrateurs Relation client/fournisseur Recherche de solutions en commun et non trouver le responsable

Organisation

Impact pressenti Habitude Principe Agile structurant
Rôles au sein des équipes projet Séparation des rôles Polyvalence, collaboration
Articulation Etudes/exploitations Tester quand c’est possible Test Driven Develoment
Codage, architecture Architecture élégante, pérenne Simplifier au maximum, revue de code
Documentation projet Documentation exhaustive et formelle Documentation strictement nécessaire
Management de projet Etablir un plan et faire exécuter Confiance en l’équipe, autonomie
Organisation au sein des projets Phase de maintenance post projet Absence de rupture entre développement et maintenance
Conduite de projet Comité de pilotage, réunions projet StandUp meetings, oral plutôt qu’écrit
Conduite de projet Répartition sur plusieurs sites Adapter les outils (wiki,skype,Jira,référentiel de code, …)

Publié par

Commentaire

1 réponses pour " Agile Tip n°4: Critères de vigilance "

  1. Publié par , Il y a 12 ans

    Deux commentaires : je vais jouer un peu le mauvais esprit, mais j’aimerais éviter un discours qui apparaît souvent « naïf » aux yeux de certains interlocuteurs (qui n’ont pas forcément tord) sur les méthodes agiles :

    – Confiance en l’équipe.
    La confiance dans une relation n’est pas donnée, elle se construit. Un client ne peut donner du jour au lendemain, surtout pour des projets ayant certains enjeux, sa confiance les yeux fermés. Il faut créer celle-ci. C’est un processus qui peut être contractualisé et qui définira des étapes, des jalons, des outils de contrôles, ou chacun mesurera la confiance qu’il peut accorder. Voici, ici ( http://erichilly.blogspot.com/2008/01/dfinir-un-nouveau-mode-de.html ), un exemple de processus contractuel. Il doit créer la spirale d’un « dialogue » constructif, où aucune partie ne fait de promesses invérifiables et où chacun pourra se retirer du « jeu » quand il considèrera prendre trop de risque.

    – Architecture élégante, pérenne vs Simplifier au maximum, revue de code.
    Aïe ! je pense que ce que vous avez voulu signifier, c’est que certains projets font beaucoup d’études (de conception) pour pondre une architecture « parfaite » avant d’écrire la moindre ligne de code.
    Architecture « parfaite » qui en l’occurrence peut être compliquée, couteuse sur le terrain. Elle n’est donc ni élégante et encore moins pérenne, c’était seulement une intention initiale. L’élégance et la pérennité (mais aussi l’évolutivité) sont d’ailleurs les qualités d’une architecture simple.
    Faire une architecture compliquée, c’est facile, c’est naturel, on tombe tous dedans.
    Faire une architecture simple, c’est difficile, cela demande un effort continu. D’où le Test Driven, le refactoring, l’intégration continue, le « pair »…et des principes conceptuels simples.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.