Bienvenue dans la mthodologie TenStep organise par domaine de gestion

Ce site web contient la Mthodologie TenStep de Management de projet, qui est une rfrence importante pour les chefs de projets et toutes les parties prenantes d'un projet. Cliquez sur la barre de menus situe gauche pour un aperu de haut niveau. Les utilisateurs inscrits et les clients disposant d'une licence d'utilisation peuvent accder plus de contenu.

La mthodologie TenStep de management de projet ("Mthodologie TenStep" ou "TenStep") a t conue pour aider les chefs de projets grer tout type de projet avec succs. La mthodologie TenStep de management de projet fournit tous les renseignements dont vous avez besoin pour devenir un chef de projet accompli. Cette mthodologie comprend une approche progressive, en commenant par les notions lmentaires et en progressant en fonction de vos besoins dans le cadre de la ralisation dun projet dfini. La mthodologie TenStep de management de projet vous permet de grer votre travail comme un projet. Elle a t conue pour tre aussi flexible que ncessaire dans la gestion de votre projet. Cela signifie, par exemple, quil nest pas logique de consacrer beaucoup de temps la gestion des risques dun projet qui ne demande que 500 heures deffort et qui est similaire dautres projets raliss auparavant. Cela nimplique pas que vous ignoriez les risques potentiels, mais vous ny consacrerez plus autant de temps que pour un autre projet (par exemple, un projet pour lequel vous implantez une nouvelle technologie). Cette approche flexible et progressive caractrise le processus TenStep et contribue le distinguer des autres mthodologies. Lexpression management de projet fait rfrence la dfinition et la planification, ainsi qu' la surveillance et au contrle qui en dcoulent jusqu la clture du projet. Avant mme de commencer, vous devez reconnatre que chaque projet ncessite un certain niveau de gestion. Si vous y rflchissez bien, vous constaterez quen fait, vous tes dj en train damorcer un projet, mme si cela se passe uniquement dans votre tte. Plus le projet sera important et complexe, plus vous aurez besoin dune mthode de gestion standard, formelle et structure. Il est possible que vous soyez capable de grer adquatement un petit projet de 200 heures au total et en ne faisant appel qu deux personnes, sans devoir appliquer une mthode complexe. En revanche, vous ne pouvez pas grer de la mme manire un projet de 1.000 heures. Un tel projet emploie cinq personnes et implique plus de formalits. Il faut dployer davantage defforts s'il s'agit d'un projet de 20 personnes, ce qui reprsente 20.000 heures deffort. Naturellement, il y a des cots lis la gestion d'un projet. Il faudra donc adapter le niveau de gestion la taille du projet pour que la valeur ajoute (par cette gestion) soit suprieure aux cots exigs. Pour mieux comprendre la Mthodologie TenStep, prenons d'abord connaissance des bnfices qui seront raliss, rvisons certaines hypothses et mises en garde, et parcourons le fonctionnement de la mthodologie TenStep de management de projet : A1 Les avantages d'une mthodologie de management de projet o A1.1 La modularit de la mthodologie un facteur-cl

A2 Le style dcriture de TenStep

A3 Comment utiliser la mthodologie TenStep A4 Le contexte de la mthodologie TenStep A5 Droulement de la mthodologie TenStep o o o A5.1 Modle CMMI de maturit des capacits A5.2 Management de projet par rapport au cycle de vie d'un projet A5.3 Management de projet par rapport la gestion de produit

A6 Comparaison de la mthodologie TenStep de management de projet, avec o o o A6.1 le Guide du Corpus des Connaissances en Management de projet de l'Institut du Management de Projet, PMI, " Guide PMBOK ", Quatrime dition A6.2 La mthode Agile de dveloppement de logiciels A6.3 ISO 10006

0.0 Dmarrage du projet

(0.0. P1)
La mthodologie TenStep de management de projet ("Mthodologie TenStep" ou "TenStep") vous enseigne comment grer (planifier et piloter) un projet de manire proactive. Cependant, cela suppose l'existence d'un projet grer. Chaque organisation dispose de procdures (ou processus) pour identifier et autoriser les projets. Ces processus comportent gnralement les caractristiques suivantes : Certains procds pour identifier tous les projets qui pourraient potentiellement tre entams. Un processus d'entonnoir pour simplifier l'ensemble des projets potentiels dans le plus petit nombre possible qui ont le plus de valeur et qui sont le plus centrs sur les objectifs et les stratgies d'affaires de lorganisation. Un moyen de documenter les cots et les avantages afin que le projet puisse tre compar d'autres projets. Ce document est gnralement appel analyse de rentabilisation . Identification d'un ensemble de renseignements requis pour obtenir l'approbation finale du projet.

Le processus dcrit ci-dessus est employ pour obtenir l'approbation prliminaire dun projet. Cependant, il peut y avoir un dcalage entre le moment o un projet est initialement approuv et celui o le projet commence rellement. Par consquent, lorsqu'un projet est prt dbuter, un certain nombre d'lments doivent tre valids pour garantir que le projet est prt dmarrer.

Dmarrer les projets de petite taille (0.0. P2)

Ce processus initial n'est pas ncessaire pour les petits projets.

Dmarrer les projets de taille moyenne (0.0. P3)

Ce processus initial est facultatif pour les projets de taille moyenne. Si le projet est assez grand, vous pouvez mettre en uvre le processus de dmarrage conu pour les grands projets. Sinon, le processus peut tre omis.

Dmarrer les grands projets (0.0. P4)

Les projets de taille moyenne et les grands projets ont suffisamment de masse critique pour justifier un processus formel de dmarrage avant le dbut du projet. Ce processus peut tre trs rapide ou prendre un certain temps, en fonction de la disponibilit du commanditaire et de l'organisation excutrice. Le travail ncessaire ce stade comprend les lments suivants :

Valider si l'analyse de rentabilisation est toujours valable Il est possible que la conjoncture conomique ait chang entre le moment o le projet a reu l'approbation prliminaire et le projet en cours. La valeur du projet et l'analyse de rentabilisatio

A6.2 Comparaison de la mthodologie TenStep avec la mthode Agile de dveloppement de logiciels

Ces dernires annes, un certain nombre d'ides ont t publies sur la manire de rendre les mthodologies de dveloppement de logiciels plus simples, plus faciles mettre en place, et plus adapts aux besoins du client. Extreme programming , Scrum et Crystal en sont trois exemples. Dix-sept des pionniers de cette pense se sont rencontrs dans lUtah, les 11, 12 et 13 Fvrier 2001 pour trouver des ides communes sur le dveloppement de logiciels. Le rsultat a t recueilli dans un manifeste comprenant un ensemble de principes de dveloppement et de conceptions qui sont reproduites ci-dessous. Alors que la majorit de ces conceptions traite des processus rels de dveloppement de logiciels, quelques points seulement abordent le management de projet. En gnral, La mthodologie TenStep de Management de projet est parfaitement complmentaire de ce processus de dveloppement dans la plupart des domaines. Dans d'autres domaines, il y a des divergences d'opinion. Vous pouvez lire ci-dessous le Manifeste Agile , accompagn des commentaires de TenStep France sur les rapports quil peut avoir avec la mthodologie TenStep. Manifeste pour le dveloppement du logiciel Agile Dix-sept anarchistes ont convenu : Nous dcouvrons les meilleures manires de dvelopper un logiciel en le ralisant, et en aidant les autres le faire. travers ce travail nous en sommes venus : Processus de management de projet TenStep

Mettre en relief des individualits et des interactions , plutt que des procds et des outils. Produire un logiciel entirement test et qui fonctionne , plutt qu'une vaste documentation. tablir une collaboration avec le client, plutt que de ngocier un contrat. Ragir aux modifications, au lieu de suivre un plan.

Daprs l'exprience de lauteur, les projets accomplis dans une organisation ont une chance de russite bien meilleure avec un ensemble cohrent de processus flexibles et volutifs. Si ces processus ont t utiliss auparavant avec succs, il y a une plus grande probabilit que les votre le seront aussi. Nous considrons que la mthodologie TenStep est trs lgre . Cependant elle reprsente le minimum des exigences ncessaires pour grer les projets avec succs. La plupart mais non toutes les philosophies de la mthodologie TenStep soutiendront un dveloppement prompt et rapide.

C'est--dire que pendant que nous valorisons les articles du ct droit, nous valorisons davantage les articles du ct gauche. Nous suivons les principes suivants: La philosophie Agile encourage le dveloppement itratif, avec les premires exigences imposes par le code du travail, suivies par plus dexigences, Notre plus grande priorit est de satisfaire le client travers la livraison rapide et et ainsi de suite. Cela est bien, mais le continue de logiciels valables. dveloppement itratif n'est pas la meilleure approche pour tous les projets de logiciel. Nanmoins, quand il peut tre mis en place, on devrait lessayer. Les changements de spcifications sont les bienvenus, mme sils interviennent tardivement dans le dveloppement. Le processus Agile met le changement au service de l'avantage concurrentiel du client. Dans le cadre dun dveloppement itratif gnral, les spcifications n'ont pas besoin d'tre dfinitivement arrtes trs tt. Cependant, mme avec le dveloppement itratif traditionnel, un certain point, les spcifications doivent tre bloques pour fournir quelque chose. ce stade, le management du contenu du projet entre en jeu. Dans le dveloppement Agile, les spcifications peuvent changer nimporte quel moment. Lide est que le client peut continuer effectuer des modifications aussi longtemps quil donne la priorit ces changements au cours de litration approprie. Par exemple, si le client a demand trois rapports et quil en veut, plus tard, un quatrime, ce dernier rapport peut tre ajout la liste des demandes, sans problme. A ce stade, le client donne la priorit au nouveau rapport, et sil en est ainsi, le rapport doit tre crit. Si le budget du client est ouvert, alors il ny a pas de processus formel de changement de contenu, et tout ce que le client veut et tout ce quil considre comme une priorit doit lui tre livr. Si le budget du client est fixe, alors la priorit accorde laccomplissement

dun changement, dans son essence, signifie quune autre partie du travail ne sera pas ralise. Dans ce genre de scnario, le client veut forcer la gestion de modification du contenu, en assurant que la priorit nest accorde quaux modifications les plus urgentes. Lapproche TenStep affirme que lorsque des modifications interviennent, lquipe doit tre prpare y rpondre. Cependant, les modifications de spcifications ont des consquences, en termes de budget et de dates de livraison, qui doivent tre approuves par le commanditaire. Si lquipe agit ainsi, elle pratique le management des modifications du contenu du projet. Le processus TenStep recommande que les grands projets soient dcomposs en une srie de projets plus petits, qui peuvent tre livrs plus rapidement et de manire rptitive. Tous les projets nont pas cette flexibilit, mais, lorsque cela est possible, la prfrence doit aller aux trs petits projets. Les processus Agile peuvent pousser lextrme le cycle court de livraison. Certains projets de programmation extrmes livrent selon des cycles trs courts, trs souvent dune semaine. Bien que cela puisse tre difficile grer, cette dmarche nest pas foncirement mauvaise. Les hommes d'affaires et les dveloppeurs travaillent ensemble quotidiennement tout au long du projet. C'est la meilleure approche pour rester en contact avec les besoins des clients.

Dlivrez frquemment les travaux sur logiciel, toutes les semaines ou tous les mois, avec une prfrence pour les chelles de temps brves.

Construisez vos projets autour dindividus motivs. Donnez-leur l'environnement et le Parfois, des personnes trs motives ont du mal soutien dont ils ont besoin, et faites-leur confiance pour quils puissent raliser leur livrer les projets temps (Deming a reconnu cela il travail. y a un demi-sicle). Elles peuvent se concentrer un

peu trop sur les dtails de dveloppement et pas assez sur la gestion du budget et des dlais. Si des personnes motives arrivaient toujours livrer leurs projets l'heure, il y aurait un pourcentage plus lev de projets russis. Parfois, vous avez besoin de placer les personnes motives dans un environnement plus structur o elles pourront tre plus efficaces. L'auteur croit que la meilleure approche est d'tablir des projets autour de personnes motives, et de sassurer quelles ont les outils, processus et qualifications qui conviennent pour raliser le travail. Il ny a aucun doute que la communication directe est la meilleure formule dans beaucoup de circonstances. Cependant, il y a des priodes o d'autres moyens de communication sont trs valables, par exemple, le-mail pour lenvoi de mises jour 20 personnes. Certaines informations pertinentes ont galement besoin dtre notes par crit pour le cas o on en aurait besoin plus tard, alors que tous les dveloppeurs originaux seront absents. Cette documentation devrait seulement contenir les informations importantes. La documentation est rarement tenue jour par l'quipe de soutien et pourrait perdre de la valeur au fil du temps. Dans le cadre dun dveloppement itratif, le fait de disposer de logiciels fonctionnant la fin de chaque itration est un bon moyen de mesurer les progrs. Cependant, tous les projets ne peuvent tre raliss selon une mthode de dveloppement itrative, la mise en uvre de packages par exemple. Aussi, dans la plupart des projets, vous pouvez continuer surveiller le plan laide des jalons majeurs de l'chancier, pour

La mthode la plus efficace et la plus rentable pour transmettre des informations l'quipe de dveloppement et la diffuser en son sein, est la conversation de vive voix.

Des logiciels qui fonctionnent sont le premier facteur de progrs.

vous assurer que vous respectez bien ce dernier. Le dveloppement Agile met laccent sur une semaine de travail de 40 heures et un rythme qui peut tre maintenu indfiniment. Naturellement, avec la planification et la gestion appropries, c'est la meilleure approche. L'excellence technique et lanticipation de bonnes dcisions relatives la conception sont essentielles pour que le processus Agile puisse fonctionner. Daccord. Les dveloppeurs de logiciels et les clients devraient se concentrer d'abord sur la livraison du noyau des exigences. Ceci maximise le travail non effectu . Cela permet galement au logiciel d'tre livr plus rapidement. La mthodologie TenStep suit aussi ce modle simple. Les projets devraient tre grs selon la taille et la complexit du travail, en tenant compte du fait que le tout le management de projet doit donner de la valeur. Si chaque quipe tait trs performante et techniquement suprieure, il serait facile de se mettre daccord ce point. Cependant, certaines quipes de projet ne sont pas assez mres et n'ont pas le niveau ncessaire de comptence pour dvelopper les meilleures conceptions et architectures. Il est important que les bonnes personnes soient choisies pour ce type de projets. Daccord. Les quipes doivent constamment essayer de comprendre leurs forces et leurs faiblesses, et de comprendre comment les processus peuvent tre amliors. TenStep pense

Le Processus Agile favorise un dveloppement durable. Les commanditaires, les dveloppeurs et les utilisateurs devraient tre capables de maintenir constamment un rythme constant.

Une attention continue lexcellence technique et la bonne conception augmente la flexibilit.

La simplicit lart de maximiser l'effort de travail non fait -- est essentielle.

Les meilleures architectures, spcifications et conceptions mergent des quipes auto- organises.

intervalles rguliers, l'quipe rflchit sur la faon de devenir plus efficace, puis ajuste son comportement en consquence.

que ces changements recommands devraient galement se faire jour dans l'entreprise, de telle sorte que des ides d'amlioration puissent tre bnfiques pour tout le personnel. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agileAlliance.org

7.8.6

Matrise des contrats

Sassurer que les performances du 3.0 Grer lchancier et le sous-traitant remplissent les budget exigences du contrat. Indique comment lentreprise source du projet et celle qui lexcute aspirent apprendre, partir du projet. Indique comment mesurer, recueillir et valider les donnes en vue de lamlioration continue.
9.0 Grer la qualit et les mtriques

8 Mesurer, analyser et amliorer

8.1 Processus lis lamlioration

8.1

Amlioration

8.2 Mesurer et analyser

8.2

Mesurer et analyser

9.0 Grer la qualit et les mtriques

8.3 Amlioration continue

8.3.1

Les activits que lorganisation Amlioration continue source devrait effectuer visant au niveau de lamlioration continue du lorganisation source processus du projet.

9.0 Grer la qualit et les mtriques

8.3.2

Informations fournir par Amlioration continue lorganisation qui excute le projet 9.0 Grer la qualit et les de lorganisation du lentreprise source, afin de mtriques projet permettre une amlioration continue.
4.0 Grer les problmes majeurs 5.0 Grer le contenu 6.0 Grer les communications 9.0 Grer la qualit et les mtriques

Pas spcifiquement trait dans ISO 10006 Pas trait de manire adquate dans ISO 10006 Pas trait de manire adquate dans ISO 10006 Pas trait de manire adquate dans ISO 10006 Le modle cit ci-dessus est soumis la norme IS0 2003.