Published by Luc Legardeur
Il y a 15 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, …) |
Commentaire
1 réponses pour " Agile Tip n°4: Critères de vigilance "
Published by Eric Hilly , Il y a 15 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.