\n<\/p>\n
Agile, voil\u00e0 bien un mot qui est dans l’air du temps en ce qui concerne la gestion de projet web, mobile ou applicatif. Sous l’impulsion du web notamment o\u00f9 les notions de ROI et d’exp\u00e9rience utilisateur sont devenues centrales, la gestion de projet a donc connu une r\u00e9volution dans sa pratique. Deux tendances se d\u00e9gagent que l’on peut r\u00e9sumer ainsi :<\/p>\n C’est presque une r\u00e9p\u00e9tition de ce qui est \u00e9nonc\u00e9 plus haut mais dans une perspective historique cette fois-ci. Cette \u00e9volution peut-\u00eatre r\u00e9sum\u00e9e par l’affirmation suivante : C’est la cl\u00e9 de voute de la m\u00e9thode Agile, en effet fort du constat que + de la 1\/2 des fonctionnalit\u00e9s d\u00e9velopp\u00e9s ne sont pas utilis\u00e9es et + de la 1\/2 des d\u00e9fauts sont li\u00e9s \u00e0 un mauvais recueil des besoins. Pourquoi est-ce si difficile de recueillir les besoins du client. Plusieurs raisons \u00e0 cela, incommunicabilit\u00e9, absence de culture commune, ignorance… Bref \u00eatre agile, c’est pratiquement faire oeuvre d’ethnologue. Il s’agit de vaincre les maux suivants :<\/p>\n Un besoin n’est pas seulement une fonction mais la capacit\u00e9 du syst\u00e8me \u00e0 assurer cette fonction. Pour dire les choses de mani\u00e8re prosa\u00efque, si le client ne peut lui m\u00eame op\u00e9rer la fonction donc \u00e0 la reproduire quand bon lui semble, cela ne sert \u00e0 rien. <\/p>\n Quelques-unes des valeurs agiles :<\/p>\n C’est donc choisir le plus court chemin pour l’obtention d’un r\u00e9sultat avec en ligne de mire la satisfaction du client et de ses besoins. Le mantra ROiste du chef de projet agile<\/p>\n Le feedback, c’est le retour utilisateur\/client. C’est sans doute la dimension la plus chronophage mais la plus efficiente puisque elle offre au client la possibilit\u00e9 d’\u00eatre entendu et compris.<\/p>\n Il existe moult mani\u00e8res de recueillir les besoins d’un client, il est toujours possible de faire un panach\u00e9e des m\u00e9thodes suivantes.<\/p>\n Une fois les besoins recueillis, il est imp\u00e9ratif de : N’avoir aucune d\u00e9perdition d’information<\/strong>, Assurer la tra\u00e7abilit\u00e9 n\u00e9cessaire des informations<\/strong>. Voil\u00e0 donc la raison d’\u00eatre des Toutefois, en mode agile, la fonctionnalit\u00e9 livr\u00e9e constitue le meilleur support de discussion. Voir et exp\u00e9rimenter la fonction est toujours plus convaincant, cela privil\u00e9gie le langage utilisateur (UX) compr\u00e9hensible par tous (clients, d\u00e9veloppeurs, marketing….etc.), reste \u00e0 \u00eatre en mesure de fournir la fonctionnalit\u00e9 au terme d’une it\u00e9ration (AKA Exemples de \n\tLes \u00e9tudiants peuvent acheter un passe de stationnement mensuel en ligne. Si la taille du projet est estim\u00e9 \u00e0 100 story points et la v\u00e9locit\u00e9 de l’\u00e9quipe est estim\u00e9 \u00e0 10 points pour une it\u00e9ration (sprint) de 2 semaines. Le projet prendra donc (2×100)\/10 = 20. Ce qui fait que le projet prendra 20 semaines.\n<\/li>\n<\/ul>\n Ces 3 approches peuvent \u00eatre combin\u00e9es, elles vont constituer le PRODUCT BACKLOG (PB)<\/strong><\/p>\n Le PB regroupe l’ensemble des besoins\/exigences ou des livrables \u00e0 r\u00e9aliser. C’est la “file d’attente” ou le portefeuille des fonctionnalit\u00e9s dont certaines seront s\u00e9lectionn\u00e9es au cours des it\u00e9rations (sprint).<\/strong><\/p>\n D\u00e9finition du “product owner”<\/b><\/p>\n A Scrum project is driven by a product vision compiled by the Product Owner, and expressed in the Product Backlog.<\/p><\/blockquote>\n Source : Scrum Handbook de Jeff Sutherland<\/i><\/p>\n Bien que le “Product Backlog” puisse \u00eatre mis \u00e0 jour par “product owner” afin de refl\u00e9ter l’\u00e9volution des besoins en raison de nouvelles id\u00e9es, de mouvements de la concurrence, des obstacles techniques qui apparaissent bref ce qui est constitutif de la vie d’un produit, il est imp\u00e9ratif de hi\u00e9rarchiser les besoins.<\/p>\n La hi\u00e9rarchie des besoins se fait selon :<\/p>\n Estimer le b\u00e9n\u00e9fice surtout \u00e0 l’aune de la satisfaction du client.\n<\/li>\n Etre dans l’enveloppe globale ou ne pas \u00eatre.<\/p>\n Il faut enfin int\u00e9grer le degr\u00e9 de satisfaction du client. Un des mod\u00e8les les plus connus pour qualifier ces exigences du client et leurs satisfactions, c’est la nomenclature du Mod\u00e8le de MoSCoW dont la terminologie sans forc\u00e9ment en connaitre l’origine, s’est impos\u00e9e.<\/p>\n Une mention est \u00e0 pr\u00e9ciser, c’est que le web reste quand m\u00eame le r\u00e8gne du “Good-enough”. On peut donc additionner \u00e0 ce Mod\u00e8le de MoSCoW, une notion d’exigence suffisante ou satisfaisante (le “Good-enough”).<\/b> Les abr\u00e9viations d’origine du Mod\u00e8le de MoSCoW<\/b><\/p>\n Source : MoSCoW Method<\/a><\/em><\/p>\n En abandonnant une approche pr\u00e9dictive, qui consiste \u00e0 tout planifier au d\u00e9but<\/b>, on privil\u00e9gie l’agilit\u00e9 c’est \u00e0 dire une approche adaptative afin d’int\u00e9grer l’incertitude<\/strong>. Toutefois, l’objectif est la satisfaction du client enfin cela doit \u00eatre le but affich\u00e9 ! Aussi est-il toujours profitable de penser au produit fini.<\/p>\n Si pour chaque projet, il est d\u00e9fini une enveloppe globale. Avec la m\u00e9thode Agile, quand l’enveloppe globale est consomm\u00e9e, les d\u00e9veloppements certes s’arr\u00eatent mais il y a fort \u00e0 parier que le client obtient un produit fini avec au moins les fonctionnalit\u00e9s les plus importantes, les fameux C’est l’aspect financier qui ne dit pas son nom. En effet de cette enveloppe globale sortira la En rationalisant un peu, l’enveloppe globale peut-\u00eatre d\u00e9finie \u00e0 la louche mais au moins \u00e0 l’aide de 3 \u00e9tapes : estimation de la taille du projet, prise en compte des sp\u00e9cificit\u00e9s, estimation de la charge.<\/p>\n Il y a 5 niveaux de planification dans la d\u00e9marche agile :<\/p>\n \n Agile, voil\u00e0 bien un mot qui est dans l’air du temps en ce qui concerne la gestion de projet web, mobile ou applicatif. Cet article… <\/p>\n
\nCet article n’a pas vocation \u00e0 faire de vous un “Scrum Master” mais l’objectif simple de pr\u00e9senter les points essentiels de la m\u00e9thodologie agile<\/code> en se concentrant essentiellement sur les mots-cl\u00e9s et les notions de base qui sous-tendent l’approche agile.<\/p>\nThings Have Changed<\/h4>\n
\n
\nLe d\u00e9veloppement web ou logiciel pr\u00e9sente une \u00e9volution majeure : on est pass\u00e9 d’un mod\u00e8le de direction de projet pr\u00e9dictif<\/strong> \u00e0 un mod\u00e8le it\u00e9ratif<\/strong>.\n<\/li>\n
\nCes deux affirmations sonnent comme des \u00e9vidences mais bon, c’est agile !<\/p>\n\n
Cascade vs Agile<\/h4>\n
\nD’un d\u00e9veloppement encascade = pr\u00e9dictif<\/code>, on passe \u00e0 un d\u00e9veloppement enagile = it\u00e9ratif<\/code><\/i>. Pour m\u00e9moire, une d\u00e9finition des deux m\u00e9thodes :<\/p>\n\n
\nUn d\u00e9veloppement en cascade se fait \u00e0 partir d’un cahier des charges complet, qui aboutit \u00e0 la livraison d’un produit \u00abfini\u00bb\n<\/li>\n
\nUn d\u00e9veloppement agile se fait par versions successives (it\u00e9rations) o\u00f9 le prestataire livre, sur plusieurs mois, des versions qui s’enrichissent progressivement.\n<\/li>\n<\/ul>\nLe graal : information & communication<\/h4>\n
\nEtre agile, c’est comprendre ce que le client a en t\u00eate, “l’accoucher” sans perdre de temps donc d’argent tout en lui transf\u00e9rant la responsabilit\u00e9 du rendu via le product backelog<\/code> car c’est avec ses mots que le produit sera d\u00e9fini via des user stories<\/code> par exemple et bien sur loin de toute exhaustivit\u00e9, ne sera pris ne compte que ce que le client \u00e9nonce ! Agile et Habile.<\/p>\n
\nLe but est de recueillir les besoins, sans viser l’exhaustivit\u00e9 afin de trouver un langage commun<\/strong>. C’est cette ma\u00efeutique que vise la m\u00e9thode agile vis \u00e0 vis du client afin qu’il exprime ses besoins et les hi\u00e9rarchisent.\n<\/li>\nRecueil des besoins<\/h4>\n
\n
Faire \u00e9merger les besoins<\/h4>\n
\n
\nSortir tout ce qui est implicite<\/strong>. En effet, il est question de ma\u00efeutique, c’est donc que tout doit pouvoir \u00eatre dit et \u00e9nonc\u00e9.\n<\/li>\n
\nLe recueil des besoins et la hi\u00e9rarchisation s’inscrit dans une d\u00e9marche it\u00e9rative. Le d\u00e9marche it\u00e9rative est dangereuse d’un point de vue strictement financier en effet il est fort \u00e0 parier que le projet tombe dans l’histoire sans fin, le client renouvelle en permanence l’expression de ses besoins, l’it\u00e9ration produit du d\u00e9sordre en lieu et place de l’efficience.\n<\/li>\n<\/ul>\nPourquoi nous “agilons” ?<\/h4>\n
\n
bienveillance du produit<\/code>)<\/li>\nLa boucle du feedback<\/h4>\n
\n
Les techniques de recueil<\/h4>\n
\n
Formaliser les besoins<\/h4>\n
redmine<\/code>, wiki<\/code> qui historisent et sont le principal canal de communication vers toutes les parties prenantes du projet.<\/p>\nsprint<\/code>).<\/strong><\/p>\nLe recueil des besoins : les 3 approches<\/h4>\n
\n
\nUne approche qui d\u00e9finit les exigences essentielles (fonctions, performances, contraintes de conception, attributs de qualit\u00e9).\n<\/li>\n
\nC’est la m\u00e9thode utilisant des cas d’utilisation (UC), les User-Case<\/code>.\n<\/li>\n
\nUne exigence est formul\u00e9 avec le langage utilisateur, en 1 ou 2 phrases pour servir un but.
\nC’est souvent sur cette base que s’appuie la m\u00e9thode agile
\nL’estimation sur la base des User Stories<\/code> permet de d\u00e9finir des User Story points<\/code>.<\/p>\nUser Stories<\/code><\/strong><\/p>\n
\n\tLe passe de stationnement peuvent \u00eatre pay\u00e9s par carte de cr\u00e9dit.
\n\tLe passe de stationnement peuvent \u00eatre pay\u00e9s via PayPal ™.
\n\tLes professeurs peuvent donner des notes aux \u00e9l\u00e8ves.
\n\tLes \u00e9tudiants peuvent obtenir le calendrier des cours en ligne.
\n\tLes \u00e9tudiants peuvent commander relev\u00e9s de notes officiels.
\n\tLes cours seront disponibles en ligne via un navigateur standard.<\/p>\n<\/blockquote>\n<\/li>\n<\/ul>\nUser Story, User Points, V\u00e9locit\u00e9<\/h4>\n
\n
\nChaque User Story se voit attribuer un nombre de points.
\nOn prend la User Story la plus petite et on lui affecte le poids de 1, ensuite on cherche le poids relatif des story par rapport \u00e0 cette premi\u00e8re Story.\n<\/li>\n
\nC’est le nombre de Story points que l’\u00e9quipe est capable de parcourir en une it\u00e9ration (sprint)\n<\/li>\nLa pi\u00e8ce ma\u00eetresse : le “Product Backlog”<\/h4>\n
\n
Hi\u00e9rarchiser les besoins<\/h4>\n
\n
\nLa m\u00e9thode Agile permet de ne pas brider la cr\u00e9ativit\u00e9 d’une \u00e9quipe toutefois il faut pouvoir mesurer la courbe d’apprentissage d’une \u00e9quipe, \u00e9l\u00e9ment d\u00e9terminant dans sa velocit\u00e9.\n<\/li>\n
\nEn d’autres termes, quelles risques y-a-t-il \u00e0 se lancer dans le d\u00e9veloppement de telle ou telle fonctionnalit\u00e9.<\/li>\n<\/ul>\nLe degr\u00e9 de satisfaction du client<\/h4>\n
\n
\nSource : http:\/\/en.wikipedia.org\/wiki\/Principle_of_good_enough<\/a><\/em>
\n<\/i><\/p>\n\n
Planifier agile, c’est penser produit fini<\/h4>\n
\"Must-have\"<\/code> et puis c’est \"Good-enough\"<\/code>.<\/b><\/p>\nD\u00e9finir une enveloppe globale<\/h4>\n
quotation<\/code>, le pricing<\/code>, en clair le fric que le client va devoir l\u00e2cher :):) Pour l’occasion, la m\u00e9thode agile est aussi d\u00e9pourvue que toutes les autres m\u00e9thodes !<\/p>\n\n
\nC’est la quantification des composantes du projet \u00e0 d\u00e9velopper : nombre de pages, d’\u00e9crans, de fonctionnalit\u00e9s, de tables… On donne \u00e0 chacun de ces composantes des points.
\nLes usages veulent que un \u00e9cran = 3 jours<\/code> alors une base de donn\u00e9es…\n<\/li>\n
\nIl faut penser aux facteurs d’influence \u00e0 prendre en compte comme faisant parties du contexte. Doux euph\u00e9misme ou pur exemple de novlangue<\/code> pour d\u00e9signer tous les al\u00e9as li\u00e9s \u00e0 notre incapacit\u00e9 \u00e0 pr\u00e9dire le futur avec un plan ou pas. Une sorte de talon d’agile en quelque sorte.\n<\/li>\n
\nElle est exprim\u00e9 en jours\/homme, ind\u00e9pendant de la dur\u00e9e du projet. C’est le prix…\n<\/li>\n<\/ol>\nPlanifier avec une d\u00e9marche agile<\/h4>\n
\n
\nC’est l’enveloppe globale + le PB (product backlog)\n<\/li>\n
\nC’est la livraison de versions successives en fonction des priorit\u00e9s d\u00e9finies par le client. Chaque livraison constitue une \u00abrelease\u00bb.\n<\/li>\n
\nUne \u00abrelease\u00bb se d\u00e9finit par une date de d\u00e9but et de fin, un th\u00e8me et une s\u00e9lection de fonctionnalit\u00e9s \u00e0 impl\u00e9menter. A l’int\u00e9rieur de la \u00abrelease\u00bb, on d\u00e9finit des it\u00e9rations auxquelles sont affect\u00e9s les diff\u00e9rentes \u00abstories\u00bb.\n<\/li>\n
\nC’est le daily stand-up meeting<\/code> en clair motiver ses troupes m\u00eame si personne ne veut travailler.\n<\/li>\n<\/ul>\n
\nCe que Agile est d’\u00e9vidence, c’est une m\u00e9thode o\u00f9 la pr\u00e9dictibilit\u00e9 est exclue, c’est bannir l’adage tout est d\u00e9fini \u00e0 l'avance<\/code>, Beurk ! Certes, il est possible de s’appuyer sur une batterie de documents (cahier des charges, diagramme de gantt… etc.) qui peuvent au final rendre totalement indigeste la vision du produit mais l’\u00eatre humain est ainsi cela le rassure ! Car en mode pr\u00e9dictif, l’objectif deviendrait presque de suivre le planning co\u00fbte que co\u00fbte ind\u00e9pendamment de la r\u00e9alit\u00e9 de ce qui est produit. La m\u00e9thode agile, c’est une planification macroscopique initiale, puis d\u00e9taill\u00e9 au fil de l’eau, bref la gestion de l’incertitude, reste \u00e0 savoir si on est risk-adverter<\/code> ou risk-lover<\/code> ?
\n<\/strong><\/p>\nEn savoir plus<\/h2>\n
\n
http:\/\/scrum.jeffsutherland.com\/<\/a><\/li>\n
http:\/\/jeffsutherland.com\/scrumhandbook.pdf<\/a><\/li>\n
http:\/\/www.amazon.com\/Enterprise-Scrum-Ken-Schwaber\/dp\/0735623376<\/a><\/li>\n
http:\/\/scrumfoundation.com\/<\/a><\/li>\n
http:\/\/assets.scrumfoundation.com\/downloads\/1\/scrumprimer20.pdf<\/a><\/li>\n