Travaillez votre AGILE IT!
Kesako ?
Agile englobe un ensemble de méthode de gestion de projet et de conception logicielle qui se veulent plus impliquantes et plus réactives vis-à-vis du client que les méthodes traditionnelles. Le but est d’obtenir un produit focalisé sur la satisfaction du client plutôt qu’un produit focalisé sur des engagements contractuels.
Les 4 valeurs fondamentales d’agile sont l’équipe (« Personnes et interaction plutôt que processus et outils »), l ‘application (« Logiciel fonctionnel plutôt que documentation complète »), la collaboration (« Collaboration avec le client plutôt que négociation de contrat ») et l’acceptation du changement (« Réagir au changement plutôt que suivre un plan »).
La méthode la plus répendu en France est SCRUM, souvent couplée avec XP (eXtrem Programming)
Huile sur toile (c) Olivier Morin
Méthodes agiles versus méthodes classiques
Je ne vous fais pas l’affront de vous présenter le cycle en V ou en Y (2TUP). Ces méthodes sont aujourd’hui bien connues par les chef de projets, des indicateurs de ROI et de performances sont intégrés, les projets maitrisés. De plus ces dernières années nous avons vu fleurir de « nouvelles méthodes » de gestion de projet bien adaptées à ces cycles (ITIL, CMMI, COBIT, …) et qui permettent de maîtriser aussi les projets dans la durée.
Le problème est que dans ce cycle, on implique le métier et la MOA en début et en fin uniquement. Du coup, plus le projet est long, plus l’effet de tunnelisation est important.
De plus les équipes sont cloisonnées : Métier <-> MOA <-> MOE ( <-> prestataires ).
Du coup, le métier désigne un responsable pour dialoguer avec la MOA, qui va mettre quelqu’un en face et va à son tour désigner un responsable pour dialoguer avec la MOE, … et ainsi de suite. Autant d’interfaces qui peuvent déformer l’information, faire goulet d’étranglement, … Et si on saute une étape, on crée des tentions et des frustrations.
Agile propose au contraire d’impliquer tous les acteurs ensembles et tout au long du projet. Dans Scrum, par exemple, on découpe le projet en sprint de 1 à 4 semaines. Lors de chaque sprint MOA et MOE décident ensemble de ce qui sera développer pendant le prochain sprint. Chaque jour du sprint, le chef de projet anime un « stand up meeting » avec ses équipes et chacun décide des tâches qu’il prend à sa charge. L’information est donc sensé remonter, dans le pire des cas chaque jour en interne MOE et à chaque sprint entre MOA et MOE. C’est aussi un process fortement impliquant pour les équipes de développement. Enfin, pour des projets avec « deadline » cela garantie que c’est bien les fonctionnalités les plus importantes qui seront développées.
Le problème est que cela demande une disponibilité beaucoup plus importante des MOA, il s’agit d’un pré-requis indispensable. Si la MOA attend un développement exhaustif du périmètre les risques de dérivent sont important. Enfin on peut se retrouve à casser et refaire souvent.
AGILITE = VITESSE + CAPITALISATION : il faut continuer à documenter ses projets sinon passé quelques runs ou un renouvellement partiel de l’équipe, le projets n’est plus viable.
Pourquoi attendre?
On se rend assez vite compte que les méthodes agiles ne sont pas des méthodes miracles. Finalement, si elles sont intéressante pour des projets innovants, elles le sont assez peu pour des projets très long ou des projets en exploitation.
De plus, les freins existent : les chef de projets ne peuvent plus appliquer leurs indicateurs traditionnels, du coup la comparaison entre un projet agile et un autre n’est pas aisée, pourtant les décideurs souhaitent toujours pouvoir mesurer leur ROI (pourquoi pas avec un indicateur gain/satisfaction utilisateur?)
Enfin pour les sociétés de services doivent mettre en face de ces projets un nouveau modèle commerciale : il serait suicidaire de vendre un projet agile comme un forfait classique et leur apport est moindre si elles se contentent de fournir des ressources agiles en régie.
Cependant, crise aidant, les sociétés qui ont du cash ont tout intérêt à investir dans l’innovation maintenant pour être leader en période de reprise. Je prends le paris qu’elles seront de plus en plus demandeuses de ce type de méthodes. Dans le même temps, on devrait voir un regain d’intérêt pour le MDA qui permet de contourner le problème du « faire et refaire ».
Everland (c) Martin Vidberg
La souplesse du chef de projet
Le chef de projet doit maintenant connaître différent mode de projet pour offrir le meilleur service possible à son client…
Et si la vraie agilité c’était l’adaptabilité, plutôt que l’évangélisation théorique?
👨🏻🌾 Aventurier à l'Opinel, Paddle guy, mono-maniaque à temps partiel le reste du temps.
je découvre la méthode agile avec cet article; merci Thomas !
juste une remarque : ITIL et CMMI ne sont pas des méthodes de gestion de projet ; ce sont au contraire des approches opérationnelles des organisations informatiques (faire que ça marche bien, alors que la gestion de projet c’est plutôt de créer de nouvelle choses)
CMMI permet de mesurer la maturité de l’organisation informatique, qui estime si les process existent et sont utilisés de manière uniformes, conformes à la documentation, et s’ils sont maîtrisés, contrôlés et améliorés.
ITIL est un référentiel de bonnes pratiques (basés sur l’expérience des organisations informatiques) qui organise les process opérationnels pour délivrer et supporter les services informatiques à la hauteur des attentes des utilisateurs et clients.
byz++
roland
Merci mon Roland 🙂
Tu joues sur les mots : « ce sont au contraire des approches opérationnelles des organisations informatiques » => c’est bien de la gestion de projet
mais tu montres toi même avec tes définitions que ces outils paraissent naturellement adaptés au projet de « run »… par contre je me pose la question pour les projets de « build » effectivement
Pour avoir reçu une certification CMMi je plusoie la remarque de Roland :-).
Sinon pour moi la méthode AGILE ressemble beaucoup à la très célèbre méthode « à l’arrache ». Et au final c’est ce qui est le plus utilisé soyons honnêtes.
Ça ne veut pas dire que c’est la moins bien adaptée, au contraire !
Sur des systèmes existants qu’il faut faire évoluer (ce que je connais le mieux) ça permet le plus important : l’adaptabilité !
Bonjour Thomas
J’ai lu avec intérêt ta description de SCRUM ainsi que ta réponse à Roland.
Etant moi-même certifié Red Badge pour ITIL , PMP du PMI Institute et également Scrum Master , permet-moi de rectifier.
Il n’existe pas de projet RUN , par définition un projet à un début et une fin. Ce qui n’existe pas dans l’opération.
ITIL est comme le souligne Roland un ensemble de bonnes pratiques destinées à la gestion opérationnelle (Service Desk , Gestion des Incidents , des Problèmes, de la disponibilité des systèmes , etc …).
CMMI est une échelle de mesure de la maturité d’une organisationa maturité d’une organisationqui mesure le degré auquel celle-ci a déployé de façon cohérente des processus qui sont documentés, gérés, mesurés et continuellement améliorés.
SCRUM est typiquement une méthodologie de gestion de projet AGILE originellement inventée pour le développement de logiciels qui possède également une partie introspective (amélioration continue).
Voilà j’espère avoir été clair