Bâtir une équipe F Lussier V1.2 Fra
Upcoming SlideShare
Loading in...5
×
 

Bâtir une équipe F Lussier V1.2 Fra

on

  • 2,867 views

Démontrer comment créer une équipe de projet hautement performante.

Démontrer comment créer une équipe de projet hautement performante.

Statistics

Views

Total Views
2,867
Views on SlideShare
2,074
Embed Views
793

Actions

Likes
1
Downloads
239
Comments
0

6 Embeds 793

http://coachingentreprise.wordpress.com 598
http://www.scoop.it 184
http://www.slideshare.net 4
http://www.linkedin.com 4
url_unknown 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • On ne peut pas être plus fort que le plus faible des maillons d’une chaîne.
  • Réactions négatives sont interdites
  • Ne prenez jamais un engagement sans un plan. Si vous ne pouvez pas prévoir précisément, prévoyez souvent. Prévoyez ce que vous savez et prévoyez à un niveau qui adapte le travail. ( Plan what you know and plan at a level that fits the job. )

Bâtir une équipe F Lussier V1.2 Fra Bâtir une équipe F Lussier V1.2 Fra Presentation Transcript

  • B âtir une équipe (Team Software Process tm / Personal Software Process tm ) Présenté par : Frédérick Lussier Novembre 2009, version 1.2 tm Personal Software Process, PSP and Team Software Process, TSP are service marks of Carnegie Mellon University ® Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
  • Agenda
      • Une équipe
      • Présentation du TSP/PSP
      • Bâtir l’équipe
      • Suivre une équipe
      • État du TSP/PSP
      • Questions and Discussions
    sm Personal Software Process, PSP and Team Software Process, TSP are service marks of Carnegie Mellon University ® Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. Team Software Process – TSP tm Personal Software Process – PSP tm Capability Maturity Model Integration – CMMI ® Software Engineering Institute – SEI
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Une équipe
  • Une équipe
    • À cause de la complexité du produit, plusieurs connaissances et savoir-faire sont nécessaires pour développer un produit technologique.
    • Souvent le nombre de connaissances et de pratiques dépasse un seul individu.
    • Pour développer un produit technologique, nous avons besoin de plusieurs personnes compétentes qui possèdent ensemble les connaissances et les pratiques nécessaires.
    • Voilà pourquoi, nous avons besoin d’une équipe:
      • Des personnes ayant des connaissances complémentaires travaillant ensemble à un objectif commun.
    • Cette présentation d é montrera comment le Team Software Process (TSP) permet de créer une équipe de projet.
  • Comme les équipes de sports
    • Comme dans le sport d’équipe, les produits sont développés par une équipe qui possède plusieurs rôles : Gardien de but, défenseurs, attaquants, etc.
    • La compétence, la discipline et l'engagement de chacun des individus et l'équipe dictent son résultat.
    • L’amélioration de la performance de l’organisation passe donc par l’amélioration des équipes qui elle passe par l’amélioration des individus.
    • Un coéquipier sportif:
        • se motive lui-même;
        • négocie ses engagements;
        • suit ses plans;
        • est dédié envers l’excellence et la haute qualité;
        • croit en ses capacités;
        • est rigoureux dans son travail;
        • A du fun dans ce qu’il fait.
  • Les travailleurs du savoir.
    • Développer un produit technologique est une activité intellectuelle qui nécessite des travailleurs du savoir.
    • Ce sont les travailleurs du savoir qui créent la connaissance, élaborent de nouvelles idées et développent de nouveaux produits.
    • Plus le savoir est spécifique, plus le travailleur devient un pilier dans votre organisation.
    • Perdre un travailleur du savoir c’est mettre en danger le capital intellectuel et social de l'organisation.
    • « La principale règle dans la gestion des travailleurs du savoir est la suivante: les managers ne peuvent pas les gérer, seuls les travailleurs doivent se gérer eux-mêmes. » - Watts Humprhey
    People as individuals. The knowledge worker knows the best way to get the work done. Management motivates, leads, and coaches. - Peter Drucker
  • Qu’est-ce qu’ une équipe autodirigée?
    • C’est une équipe qui:
      • effectue le meilleur travail;
      • est plus créative et innovatrice;
      • résout efficacement les problèmes complexes;
      • développe des produits de meilleure qualité;
      • est plus satisfaisante pour ses membres;
      • s’entraide, se motive et s’améliore;
      • optimise l’implication des managers dans le projet.
    Nous avons besoins d’équipes autonomes, engagées, et motivées ayant la capacité de s’autodiriger efficacement.
  • É quipe autodirigée
    • C’est une équipe qui:
      • possède des compétences complémentaires;
      • s’engage envers la vision et les objectifs d'équipe communs;
      • possède un degré élevé d’indépendance et « d’empowerment  »;
      • a le sens de l’adhésion et de l'appartenance;
      • développe la meilleure stratégie pour atteindre les objectifs;
      • prend ses propres engagements;
      • se partage les rôles et les responsabilités de leadership;
      • a l’habileté de résoudre activement des problèmes et les conflits;
      • accepte l’imputabilité mutuelle et individuelle;
      • dispose de leur processus et de leur plan;
      • est dédié à l’excellence et au succès;
      • dirige leurs projets;
      • communique ouvertement.
    S’unir est un début; Rester ensemble est un progrès;Travailler ensemble est un succès. Henry Ford Avoir la compétence pour faire un plan, la conviction pour le défendre, et la discipline pour la suivre;
  • De quoi a-t-elle besoin?
      • Être challengée par des objectifs;
      • Avoir un management qui met l’accent sur les objectifs;
      • Avoir un management transparent;
      • Avoir le support du management;
      • Avoir du feedback régulier de sa performance;
      • Avoir des coéquipiers compétents;
      • Avoir un environnement qui permet de progresser librement, une communication ouverte;
      • Avoir du fun.
  • Les raisons pour bâtir une équipe
    • Outre de développer un produit.
      • Améliorer la productivité;
      • Améliorer la communication;
      • Améliorer la coopération;
      • Mobiliser une équipe;
      • Apprendre à se connaître;
      • Mettre tous les équipiers sur le même diapason, incluant les objectifs;
      • Enseigner l'autorégulation d'équipe;
      • Apprendre à identifier et à utiliser les forces et faiblesses de ses coéquipiers.
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    TSP tm /PSP tm
  • TSP/PSP Historique
    • CMM v1.1 introduit par Watts S. Humphrey – Standard Engineering Institute (SEI) en 1991
      • Quelques questions entendues souvent:
          • Comment déployer le CMM dans ma petite organisation (ma crainte est que CMMI est trop « lourd » pour nous) ?
          • Comment garder la flexibilité et la réactivité de mon entreprise (ma crainte est d’écrire et implanter une série de processus qui transformera mon organisation en bureaucratie) ?
          • Comment puis-je déployer les principes de CMMI sur une plus petite échelle, projet par projet (ma crainte est qu’un budget d’implantation du CMMI à l'échelle de l'organisation va annihiler l'initiative) ?
      • Pour répondre à ces questions, Watts S. Humphrey a développé des processus et des méthodes pour qu’un individu se conforme au niveau 5 du CMMI tout en conservant son agilité et sa flexibilité. C’est la naissance du PSP.
    • Le PSP est introduit en 1994 puis le TSP en 2000.
    • Depuis ce temps plusieurs versions ont été développées pour satisfaire les contraintes d'affaires:
        • CMMI
        • Produit hautement sécurisé
  • Définiton du TSP/PSP
    • Le TSP guide une équipe autodirigée de développeurs disciplinés par le PSP, dans la réalisation d’un produit , en appliquant le coaching et le leadership .
    • Le PSP guide un individu à s’ organiser , s’ autocontrôler et s’ améliorer dans le but de devenir un coéquipier utile et efficace dans l’équipe .
    Combien de personne avez besoin pour développer un produit défectueux? La réponse est une seule.
    • Je ne fais pas de test, il y a déjà un testeur dans l’équipe;
    • Je n’ai pas le temps de faire de conception;
    • Bah! ce code est trop simple pas besoin d’inspection;
    • Oui j’ai fixé ce problème en quelques minutes qui me semblait sans impact.
  • Équipes performantes
    • Le TSP construit des équipes performantes à partir des individus
    Le TSP donne un environnement qui organise et supporte les équipes. Le PSP fournit la connaissance et les aptitudes dont un coéquipier a besoin pour travailler dans une équipe TSP. 1 à 10 équipes de 2 à 20 membres PSP : Individuel Compétences TSP: Équipe Organisation TSP : Équipe Gestion
    • Établissement des objectifs
    • Assignation des rôles
    • Ajustement des processus
    • Plans intégrés & nivelés
    • Communication
    • Coordination des ressources
    • Suivi du projet
    • Analyse des risques
    • Gestion des processus
    • Mesures de la performance
    • Estimation & planification
    • Gestion qualité
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Bâtir une équipe
  • Bâtir une équipe
    • Le TSP utilise des ateliers de planification stratégique du projet pour bâtir une équipe autodirigée.
    • Ces ateliers sont regroupés sous le thème : activité de lancement.
    • Tous les membres de l'équipe, participe aux ateliers : les développeurs, les non-développeurs, le(s) manageur(s) et le(s) client(s).
    • L’objectif communiqué à l’équipe est établir la meilleure stratégie et les processus pour accomplir les objectifs du projet.
  • Activité de lancement
    • Les ateliers accélèrent la fondation de l’équipe:
      • Une compréhension commune du travail à effectuer;
      • Un accord sur la façon d’effectuer le travail;
      • Un engagement au projet;
      • Un soutien du management sur le projet .
    • Le coach TSP guide l’équipe durant les ateliers.
    Il est plus facile d’obtenir un engagement et une motivation lorsque l’équipe a participé à la manière de faire le produit. Post Mortem
  • Atelier 1 - Objectifs et les exigences
    • La première étape de l’équipe est de comprendre ce qu’elle a à faire.
    • Équipe
      • Écouter sans intervenir
      • Poser des questions pour comprendre
      • Aucun engagement de l’équipe
    Dates Coûts Exigences Qualité
    • Managers et le client (représentant)
      • Communiquer les exigences critiques du produit
        • Nice-to-have
        • Priorisation des exigences
      • Communiquer les objectifs de l’organisation
    Une équipe est plus efficace et performante lorsqu’elle est challengée par des défis agressifs. • Quoi faire? • Pour quand est-il requis? • Quelles ressources sont disponibles? • Quelle flexibilité l’équipe a-t-elle? • Pourquoi ce projet est important? • Comment le management va mesurer le succès?
  • Ateliers 2 - 8
      • Définir les objectifs de l’équipe et les rôles des membres;
      • Définir la stratégie et les règles d’équipe;
      • Définir et adapter les processus pour chacun des produits livrables;
      • Produire un calendrier de travail pour chacun des membres selon leurs disponibilités;
      • Produire un plan réaliste du projet;
      • Produire un plan qualité du projet;
      • Identifier les risques, les opportunités et les hypothèses des plans;
      • Préparer la présentation pour la revue de direction.
    • Un plan prêt à l’exécution le lendemain.
    Il est plus facile d’obtenir l’engagement sur le projet, lorsque les individus prévoient eux-mêmes leurs projets.
  • Atelier 9 - Revue de direction
    • L’équipe présente à la direction et au client (représentant) la meilleure stratégie que l’équipe s’engage à réaliser pour atteindre les objectifs demandés.
    • Équipe
      • Présente sa stratégie;
      • Répond aux questions;
      • Montre les faits;
      • S’engage.
    • Managers et le client (représentant)
      • Challenge le plan:
        • L’équipe s’est-elle basée sur des méthodes saines d’estimation, données historiques et des processus;
        • L’équipe croit-elle à son plan;
        • Les objectifs sont-ils atteints.
      • Prend connaissance des risques;
      • Prend connaissance des besoins.
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement – Altelier 2
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Les objectifs d’équipe
    • L’équipe écrit les objectifs du projet
        • Avoir une compréhension commune des objectifs transmis par le client et le management
        • Établir les objectifs de l’équipe qui permettent d’atteindre les objectifs du projet.
    • Exemple : objectif du projet = Zéro défaut
      • L’objectif d’équipe et individuel serait d’avoir un Yield de 80%
        • Dans le TSP un Yield est le nombre de défauts fixés avant les tests unitaires.
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Les rôles
    • Les membres accompagnent et dirigent leurs pairs.
    • Un rôle permet de donner du leardership dans son domaine.
    • Le coach aide les rôles à opérer.
      • Renforce la communication et la collaboration
      • Des volontaires sont assignés aux rôles;
        • En plus de leurs tâches dans le projet.
      • Un membre peut jouer plusieurs rôles, mais pas tous.
      • Les rôles sont réassignés lors des relancements du projet
        • Cela permet une rotation.
    Chef de la planification Chef testeur Chef de l’implantation Chef concepteur Le représentant du client Chef d’équipe Chef des processus Chef de la qualit é Chef maintenance Membre d’équipe Coach Client Une équipe qui se partage les responsabilités est plus efficace. Les membres doivent s’engager et se motiver mutuellement. Le client est invité à jouer son rôle de représentant, s’il le désire.
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Rôles fixes Accompagne sur leur leadership
      • Met l’accent sur les objectifs
      • Communique et observer les objectifs;
      • Supporte l’équipe;
      • Donne du feedback.
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Sommaires des rôles (1/5)
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Sommaires des rôles (2/5) Le chef testeur n’est pas obligatoirement un testeur dans votre organisation. Il est préférable parfois d’avoir un « expert » dans les tests unitaires, cet expert peut être un développeur.
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Sommaires des rôles (3/5)
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Sommaires des rôles (4/5) Votre chef de groupe et trop préoccupé pour s’attarder à la qualité. Si personne n’est en charge de la qualité, alors personne ne prendra le temps de bien faire les choses.
  • Atelier 2- Objectifs d’équipe et assignation des rôles. Sommaires des rôles (5/5) Utilisez des titres qui veulent dire quelque chose pour vous.
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement – Altelier 3
  • Atelier 3- Établir les stratégies, les produits et les processus. Établir la stratégie
      • Dessiner un draft de l’architecture
      • Déterminer les livrables
      • Pour chacun des livrable, déterminer le processus
        • Le PSP donne cette compétence
      • Estimer la taille et la complexité des livrables
        • Le PSP donne cette compétence
      • Déterminer vos besoins
        • Outils
        • Formations
        • Matériels
        • etc.
      • Déterminer les cycles et leurs durées
        • Basé sur les priorités des exigences déterminées le contenu des itérations
    La meilleure manière de réaliser un travail est toujours la manière la plus rapide et la moins coûteuse. Développer n’est pas nécessairement la manière la plus rapide et la moins coûteuse pour réaliser les objectifs. Vous pouvez acheter, acquérir et/ou réutiliser, etc. Comment allez-vous me fournir mon truc?
  • Atelier 3- Établir les stratégies, les produits et les processus. Établir / adapter les processus
    • Pour différents genres de produit ou de livrable, employer différents processus;
        • Le PSP donne cette compétence
    • Guide pour la planification et le suivi des tâches;
    • Étapes pour développer correctement et entièrement un livrable;
    • Outil pour gérer la qualité des produits;
    • Outil pour accompagner et orienter;
    • Outil pour l’amélioration.
    Le développement cyclique est non seulement soutenu, mais encouragé même au niveau individuel . Il est plus efficace d’utiliser un processus simple pour d évelopper des produits et pour s’am é liorer. Comment allez-vous m’assurer que votre produit est de qualité? Il vous manque des étapes de revue. Test & Conception Code Post mortem Exemple d’un processus logiciel Exécution de tests unitaires Plan
  • Atelier 3- Établir les stratégies, les produits et les processus. Développement en cycle
    • Les cycles TSP peuvent être implantés en phase et/ou par itération.
        • Des cycles courts sont plus efficaces.
    • Les cycles TSP durent de quelques semaines à quelques mois.
    • Les cycles débutent par un lancement ou par un relancement et se terminent par un post-mortem.
        • Il est plus efficace d’analyser les faits une fois qu’une étape est franchie qu’à la fin du projet.
    Cycle de développement Cycle de développement Cycle de développement Dévelopment Leçons apprises Changements d’exigences Changements d’équipe Changements d’objectifs Risques Etc. Produit intermédiaire Spécifications du cycle, Stratégie, Estimation, Plans de projet, Processus, Engagement de l’équipe, Plan détaillé du cycle en court Produit final Préparation Objectifs organisationnels et techniques; Sommaire des exigences Reconnaître que les conditions du projet changeront dans le temps. Si vous ne pouvez pas prévoir, alors planifiez souvent. lancement relancement
  • Atelier 3- Établir les stratégies, les produits et les processus. Adaptation à Agile Test Exécution des tests d’intégration, de non-régression et fonctionnels Plan Test & Conception Revue et Inspection conception Code Revue et Inspection Code Analyse de code Exécution des tests PostMortem Guide PSP Exigences & Spécifications Exigences du client, Exigences techniques, Story, Test d’acceptation, ‘Backlog’ priorisé Conception et Architecture de haut niveau Modèle conceptuel, Ébauche des interfaces, Scénario, Cas d’utilisation... Relâche 1 Rel. 2 Rel. n Itération1 Itération 2 ... ... Rencontre périodique du statut du projet Validation Exécution des tests d’acceptation Intégration continue Déploiement Préparation, Démonstration et installation Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. Cycle Rencontre debout journalière Environnement Salle de travail, Serveurs,Intégration continue, Outils de développement, Machines de tests, Processus, standards, Formation... Itération 3 Architecture Vision de l’équipe de l’architecture Coach Relâche 0
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement – Altelier 4
  • Atelier 4- Estimer les tâches et la disponibilité des ressources
      • Assigner les livrables et les tâches aux coéquipiers;
      • Déterminer la disponibilité de chacun des coéquipiers et des ressources:
        • Pensez aux vacances et congés;
        • Pensez aux réunions organisationnelles;
        • Pensez que vous devez aller chercher le petit chez la gardienne.
      • Déterminer le temps nécessaire pour chacune des tâches;
        • Le PSP donne cette compétence.
    Les individus sont les mieux placés pour estimer précisément leurs tâches et prévoir la qualité. Les données historiques et l’ampleur des livrables permettent d’obtenir des plans exacts et précis. Savez-vous combien de temps vous passez à développer? a) 40 heures / semaine b) 32 heures / semaine c) Moyenne 12 heures / semaine Selon les études la réponse est C. Combien de temps vous faut-il?
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement– Altelier 5
  • Atelier 5- Établir le plan qualité
        • Le PSP donne cette compétence.
      • Déterminer si vous avez suffisamment d’étapes pour assurer un produit de qualité;
      • Estimer le nombre de défauts que vous allez injecter et le nombre de défauts que vous allez corriger par étapes;
      • Estimer le temps passé dans la qualité (Revue, inspection, analyse de code et exécution de tests).
        • Passez-vous assez de temps
    Les activités humaines sont sujettes aux défauts. Le moment le plus économique et le plus efficace de fixer les défauts est lorsqu’ils sont injectés. Il est plus efficace de prévenir les défauts que de les chercher et de les fixer. Les produits sont de meilleure qualité lorsque la qualité est considérée dès le début du projet. Vous prévoyez revoir 50 pages de code en 1 heure, pour y trouver 50% des défauts. Hum! c’est trop rapide. Comment allez-vous nous assurer d’un produit de qualité? Test & Conception Revue de conception Code Analyse code Revue de code Test unitaire
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement – Altelier 6
  • Atelier 6- Établir les plans personnels et le plan nivelé du projet.
      • Assigner les tâches de la prochaine phase/cycle/it é ration aux membres;
      • Négocier les tâches dépendantes et les tâches ayant multiples ressources;
      • Consolider les plans individuels dans un plan de projet;
      • Revoir les différents plans et niveler les charges de travail à travers tous les coéquipiers.
    Pierre comment peut-on t’aider? Les individus sont les mieux placés pour estimer précisément leurs tâches et prévoir la qualité. Les données historiques et l’ampleur des livrables permettent d’obtenir des plans exacts et précis. Quand vais-je recevoir mes trucs? Occupation de la semaine par ressource Semaine 23 Pierre 163% Jean 20% Jacques 60% Johanne 80%
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Lancement – Altelier 7
  • Atelier 7 - Identifier et évaluer les risques.
      • Identifier les risques;
          • Il y a un risque que…causé par…provoquant…
      • Mesurer l’impact;
      • Mesurer la probabilité;
      • Déterminer les éléments déclencheurs;
      • Mitiger les risques critiques;
      • Assigner un responsable (suivre le risque).
    Qu’elles sont les obstacles que vous prévoyez avoir en cours de route?
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Bâtir multiples équipes
  • Multiples équipes
    • Une équipe qui a trop de membres devient inefficace, la solution est de créer plusieurs équipes.
    • TSP a les scripts et la structure.
    • Les coaches le mettent en opération.
    Manager Client Le représentant du client Le testeur Le qualiticien Le chef des processus EPG QA Test Marketing Organisation Chef d’équipe Etc. Projet 1 Projet 2 Projet 3 Projet 4 Communication et collaboration Objectifs et exigences PMO Le planificateur
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    Application de la stratégie
  • Application de la stratégie
    • Une fois que vous avez l'appui du client et du manager pour appliquer la stratégie, vous devez soutenir cet appui.
      • Ceci exige que les coéquipiers :
        • Suivent le processus défini;
        • Maintiennent les plans individuels et de l'équipe;
        • Contrôlent la qualité du produit;
        • Régulièrement suivent et rapportent leur progrès;
        • Démontrent continuellement de la haute performance.
    • Le coach et le chef d’équipe sont l à pour vous aider, ils sont formés pour cela.
    Quand le plan ne vous guide plus, relancer le projet.
    • B âtir une équipe de développement (Team Software Process tm / Personal Software Process tm )
    État du TSP tm /PSP tm
  • État du TSP/PSP
    • Guide pour tous;
    • Atout dans description des postes;
        • Certified PSP deveoper
        • Microsoft IT, Intuit, etc
    • Outil Open source http://processdash.sourceforge.net/
    Graduation avec PSP ABB Adobe AIS Bechtel Boeing BlackBerry Census Bureau Davis Systems DFAS EDS-SDRC Erickson Fujifilm Helsana Hitashi Soft Engineering Honeywell IBM Intuit KPMG Lockheed Microsoft IT Motiva NASA Langley Northrop Gumman Oracle QuarkSoft Raytheon Samsung Softtek Sun Teradyne Toshiba USAF: Hill AFB USN: NAVAIR Vicarious Visions ...
  • Pour tous...
    • Le TSP/PSP est utilisé dans divers domaines, en voici des exemples:
        • Équipes de managers pour établir un plan stratégique de l’organisation;
        • Équipes de développement de produits logiciels;
        • Équipes de développement de produits matériels (Hardware);
        • Équipes de projet de jeux vidéo;
        • Équipes de testeurs;
        • Équipes de projets de système;
        • Équipes de recherche;
        • Équipes de services : maintenance, support, installation;
        • Etc.
    Everybody uses TSP, software developers, testers as well as artists and sound technicians. Do you know how to count defects made by an artist? Dan Wall, VP Production Methods & TSP Coach chez Vicarious Visions
  • Performance des équipes TSP /PSP The Team Software Process (TSP) in Practice: A Summary of Recent Results CMU/SEI-2003-TR-014 and CMU/SEI-2000-TR-015 We developed a 450 KLOC business operating system in 55 000 hours. We delivered it on time. The customer reported 17 bugs for a total defect density of 0.038 bugs/KLOC. Gerardo López, Towa, CEO & President TSP Symposium 2008 1/3 des projets n’ont pas de défaut Mesures AvecTSP Moyenne Min – Max Projet typique System test defects (defects/KLOC) 0.4 0 to 0.9 15 Released defects (defects/KLOC) 0.06 0 to 0.2 7.5 System test effort (% of total effort) 4% 2% to 7% 40% System test schedule (% of total duration) 18% 8% to25% 40% Duration of system test (days/KLOC) 0.5 0.2 to 0.8 5 1 to 7.7 Unit Test - cost of quality 17% 4% to 38% 50% Project schedule error 6% -20% to 27% 180% Mesures Moyenne Productivity improvement 78%
    • Mon objectif était de vous présenter cette approche pour bâtir une équipe hautement performante dans votre organisation, une méthodologie complexe, mais accessible à toutes vos organisations et entreprises…
    • et je peux vous aider à y arriver.
    Frédérick Lussier (frederick.lussier@mail.com) Senior Consultant ---> "SEI-Certified PSP Developer" ---> "SEI-Authorized Instructor for PSP“ ---> “Certified SCRUM Master”
    • Questions - Discussions
    Merci de votre attention
  • Références
    • http://www.sei.cmu.edu/tsp/
    • Mapping TSP to CMMI
      • CMU/SEI-2004-TR-014 James McHale & Daniel S. Wall
    • The Team Software Process (TSP) in Practice: A Summary of Recent Results
      • CMU/SEI-2003-TR-014 (see also CMU/SEI-2000-TR-015) Noopur Davis, Julia Mullaney
    • Relating the Team Software Process (TSP) to the Capability Maturity Model for Software (SW-CMM)
      • CMU/SEI-2002-TR-008 Noopur Davis, Jim McHale, with Strategy & Overview by Watts Humphrey
    • The Personal Software Process (PSP)
      • CMU/SEI-2000-TR-022
    • The Team Software Process (TSP)
      • CMU/SEI-2000-TR-023 Watts Humphrey