GES800 M03 Stratégie, approches et cycles PDF

ÉTS - GES800 M03 STRATÉGIE, APPROCHE ET CYCLES GES800- Contextes d’application de la gestion de projet 44 Diapos – Said BARAOUI Stratégie de réponse aux besoins Approche de développement Cycles de vie de projet...

ÉTS - GES800 M03 STRATÉGIE, APPROCHE ET CYCLES GES800- Contextes d’application de la gestion de projet 44 Diapos – Said BARAOUI Stratégie de réponse aux besoins Approche de développement Cycles de vie de projet 1 STRATÉGIE DE RÉPONSE AU BESOINS 2  LE PROJET… Existe afin de répondre à des besoins ou afin de saisir une opportunité. Il faut donc bien comprendre les besoins avant de définir, de choisir une solution Exemples: Je voudrais une crème glacée Le processus comptable de fin de mois est trop long Je dois déménager à Montréal pour mon travail 3  LA STRATÉGIE DE RÉPONSE AUX BESOINS Suite à la compréhension profonde des besoins (et jamais avant), nous devons: Élaborer une liste d’options, d’alternatives pouvant répondre aux besoins Élaborer une grille d’analyse, de facteurs d’évaluation et analyser les options Recommander l’option qui répond le mieux aux besoins en tenant compte des facteurs d’évaluation pondérés 4  DANS LE PLAN DE MANAGEMENT DE PROJET… Nous ferons un sommaire de la démarche, une liste de participants, des résultats De cette façon, l’ensemble des parties prenantes comprendra pourquoi c’est cette solution qui a été retenue pour ce projet. Il est impératif que l’ensemble des parties prenantes soit en accord avec le besoin de réaliser le projet, et de la solution choisie. 5 APPROCHE DE DÉVELOPPEMENT 6  APPROCHE DE DÉVELOPPEMENT Maintenant que nous avons défini la solution optimale dans le contexte du projet, nous devons définir le plan de réalisation, les phases/étapes. L’approche de développement est en fait un sommaire de l’échéancier du projet. C’est de décrire les grandes étapes du développement du projet. 7  APPROCHE D’IMPLANTATION ( ou de mise en service / de transfert aux opérations ) C’est la description de la façon dont on implantera la solution En bloc Par module Par département Par phase … 8  RECOMMANDATIONS Il est impératif que l’approche de développement et de livraison soit connue et approuvée par les principales parties prenantes De cette façon, notre projet démarrera sur une bonne note. 9  CYCLES DE VIE DU PROJET Cycle classique Quelques cycles de développement Quelques approches agiles Recommandations 10  LE CYCLE DE VIE DU PROJET La sélection du bon cycle est la décision la plus importante pour le succès d’un projet. La première fonction d’un cycle de vie de projet est d’établir l’ordre des phases du projet: spécification, prototype, design, développement, test, implémentation… Le cycle établit les critères qui permettent d’avancer dans le projet. 11  POURQUOI CHOISIR UN CYCLE ? Pour améliorer: La vitesse de développement. La qualité. Le suivi et le contrôle Les relations client. Minimiser les charges indirectes (« overhead »). Minimiser l’exposition au risque. 12  CRITÈRES DE SÉLECTION La connaissance et la stabilité des besoins. La connaissance de l’architecture et de la technologie. La robustesse désirée pour produit. La complexité de la réalisation. La possibilité d’avoir à faire des changements à mi-chemin. Besoin de démontrer le progrès. Les risques du projet. La possibilité de faire des améliorations futures. 13  QUELQUES CYCLES DE VIE DE PROJET « Pure Waterfall » ( classique ) « Staged Delivery » « Design-to-Schedule » « Evolutionary Delivery » « Spiral » 14  L’APPROCHE CLASSIQUE - CASCADE Définir les besoins. Acceptation. Définir les plans et devis, les coûts et échéanciers. Acceptation. Planifier les travaux en détail. Acceptation. Exécution et livraison Acceptation finale. 15  CASCADE « PURE WATERFALL » Charte de projet Analyse des besoins Design haut niveau Design détaillé Développement Test Livraison 16  L’APPROCHE EN CASCADE (SUITE) Pour: Le plus familier de tous les modèles. Le plus facile à comprendre et à contrôler. Modèle robuste, bien documenté. Donne une structure qui minimise le gaspillage d’effort. Contre: Vous ne serez pas au fait des problèmes majeurs avant que le système soit près de la mise en production. Difficile de faire des changements Il implique que chaque étape du processus doit être complétée avec succès, du premier coup. Demande beaucoup de documentation. 17  L’APPROCHE EN CASCADE (SUITE) Pour quels projets? Grands projets où les besoins sont connus, stables et compris. Projets où la technologie est connue et éprouvée. Pour créer une amélioration à un produit existant. Pour assurer la migration d’un produit existant sur une nouvelle plateforme. Les besoins en qualité dominent sur les contraintes de coûts et d’échéanciers Si votre équipe est inexpérimentée ou techniquement faible. 18  « STAGED DELIVERY » Charte de projet Analyse des besoins Design haut niveau Lot 1 Design détaillé, développement, test, livraison Lot 2 Design détaillé, développement, test, livraison Lot 3 Design détaillé, développement, test, livraison Lot n Design détaillé, développement, test, livraison 19  STAGED DELIVERY MODEL (SUITE) Pour: Le retour sur investissement est plus rapide. La relâche de versions par incrément facilite l’adaptation aux changements demandés par le/la client(e). Contre: Le/la gestionnaire de projet doit s’attendre à multiplier les efforts de coordination. Entre autres pour les tests et l’intégration. Il y a beaucoup de dépendances techniques entre les incréments 20  STAGED DELIVERY MODEL (SUITE) Pour quels projets?: Pour les grands projets dont les besoins sont connus, stables et compris. Lorsque des relâches rapides de certaines parties du produit seront bénéfiques à l’organisation. Lorsque le projet peut se réaliser avec des équipes qui travaillent en parallèle sur différentes relâches. 21  « DESIGN TO SCHEDULE » Charte de projet Analyse des besoins Design haut niveau Haute priorité - Design détaillé, développement, test Haute/moyenne priorité - Design détaillé, développement, test Moyenne priorité - Design détaillé, développement, test, livraison Lot n Design détaillé, développement, test, 22  DESIGN TO SCHEDULE (SUITE) Pour: Bonne stratégie pour vous assurer que vous aurez un produit pour une certaine date. Particulièrement utile pour une partie du développement que vous ne voulez pas sur le chemin critique. Contre: Si vous ne réalisez pas l’ensemble du produit, vous aurez perdu du temps à faire de la planification inutile (Spécification, architecture, design). Vous ne savez jamais si vous vous rendrez au dernier «release» Si les priorités ne sont pas établies correctement, vous risquez peut- être de ne pas développer des fonctions importantes. 23  DESIGN TO SCHEDULE (SUITE) Pour quel projet: Lorsque vous n’êtes pas convaincu(e) de pouvoir respecter votre échéancier. Lorsque les contraintes de temps et d’argent sont les plus importantes. Lorsque vous pouvez planifier vos itérations de sorte que les premières livraisons contiennent les fonctionnalités les plus importantes. 24  « SPIRAL » https://www.tatvasoft.com/blog/top-12-software-development-methodologies-and-its-advantages-disadvantages/ 25  SPIRAL MODEL (SUITE) Pour: Son éventail d’options lui permet d’émuler les meilleures composantes des autres modèles. Son approche des risques l’aide à éviter les difficultés des autres modèles. Permet aux client(e)s et aux ingénieur(e)s de réagir aux risques à chaque «révolution». Accroît la créativité. Contre: Demande considérable pour faire la gestion des risques. Difficile de définir des jalons. Demande beaucoup de maturité et d’expérience de la part des gestionnaires, car c’est un modèle compliqué. Chaque itération rend le projet plus imposant. 26  SPIRAL MODEL (SUITE) Pour quels projets? Lorsque l’usage de pratiques de gestion du risque est anticipé, tel que le prototypage, les simulations, l’étalonnage, l’administration de questionnaires aux utilisateur(trice)s… Lorsque les client(e)s et les ingénieur(e)s n’ont pas bien saisi les besoins d’affaires et l’architecture du projet. 27 PRATIQUES DE DÉVELOPPEMENT INCRÉMENTAL Il s’agit de pratiques qui permettent de développer et de livrer un produit par étapes. Il y a réduction du risque lorsque le projet est scindé en une série de plus petits projets plus faciles à gérer. Ces pratiques augmentent la visibilité du projet auprès des groupes opérationnels et des autres intervenant(e)s. Ces pratiques permettent aussi de faire évoluer le produit plus facilement, à chaque version. 28  « EVOLUTIONARY DELIVERY » Charte de projet Analyse des besoins Design haut niveau Développement d’une version Livraison finale Incorporation de Livraison d’une la rétroaction version Rétroaction du client 29  EVOLUTIONARY MODEL (SUITE) Pour: Livraison de certaines fonctionnalités alors que certaines ne sont pas encore définies. Permet l’usage des premières livraisons pour identifier les besoins d’affaires. Bénéfices rapides de certaines fonctionnalités. Contre Difficulté de prédire le coût et le temps requis sans avoir au préalable identifié tous les besoins… Le projet pourrait être plus long dans son ensemble. Plus de temps sera requis pour faire l’intégration des incréments. 30  EVOLUTIONARY MODEL (SUITE) Pour quels projets: Lorsque l’ensemble des besoins n’est pas bien connu, mais qu’une sous catégorie est connue, stable et comprise. Pour des solutions achetées. 31 APPROCHES AGILES - INTRODUCTION 4 valeurs 12 principes SCRUM EXCITE 32  LES 4 VALEURS DE L’AGILITÉ 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/la client(e) plutôt que négociation de contrat L'acceptation du changement Réagir au changement plutôt que suivre un plan 33  LES 12 PRINCIPES DE L’AGILITÉ 1. Notre première priorité est de satisfaire le/la client(e) en livrant tôt et régulièrement des logiciels utiles 2. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le/la client(e) 3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte 4. Les gens de l'art et les ingénieur(e)s doivent collaborer quotidiennement au projet 5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail 6. La méthode la plus efficace pour transmettre l'information est une conversation en face à face 34  LES 12 PRINCIPES DE L’AGILITÉ 7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet 8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, Ingénieur(e)s et utilisateur(trice)s devraient pouvoir maintenir le rythme indéfiniment 9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité 10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle 11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent 12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens 35  SCRUM Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée. Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe d’une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. Pendant ce temps, le/la ScrumMaster a la charge de minimiser les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe. 36 SCRUM SCRUM SCRUM 39 LE CYCLE AGILE DE BELL: EXCITE! TM 40  EN PRATIQUE Le cycle classique est le plus facile, le plus répandu. Peu de projets ne suivent pas le cycle «standard de l’entreprise» car le PMO l’impose souvent (plus facile à mesurer et à comparer les projets. Beaucoup de projets utilisent les modes agiles/itératifs comme justification à la mauvaise planification et à un comportement de girouette… 41  RECOMMANDATIONS Aucun cycle ou approche n’est « meilleur »… Il faut choisir ce qui convient le mieux aux caractéristiques du projet, de son contexte et de ses parties prenantes. La bonne marche du projet dépendra en grande partie de ce choix. Vous pouvez être créatif… Fin du module 42