Date post: | 21-Oct-2014 |
Category: |
Business |
View: | 2,898 times |
Download: | 1 times |
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe(Team Software Processtm / Personal Software Processtm)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.
Tous droits réservés © 2008 Frédérick Lussier
Agenda
o Une équipeo Présentation du TSP/PSP o Bâtir l’équipeo Suivre une équipeo État du TSP/PSPo 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 – TSPtm
Personal Software Process – PSPtm
Capability Maturity Model Integration – CMMI® Software Engineering Institute – SEI
2
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Une équipe
3
Tous droits réservés © 2008 Frédérick Lussier
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:o 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.
4
Tous droits réservés © 2008 Frédérick Lussier
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.
5
Tous droits réservés © 2008 Frédérick Lussier
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
6
People as individuals. The knowledge worker knows the best way to get the work done. Management motivates, leads, and coaches. - Peter Drucker
Tous droits réservés © 2008 Frédérick Lussier
Qu’est-ce qu’ une équipe autodirigée?
C’est une équipe qui:o effectue le meilleur travail;o est plus créative et innovatrice;o résout efficacement les problèmes
complexes;o développe des produits de meilleure
qualité;o est plus satisfaisante pour ses membres;o s’entraide, se motive et s’améliore;o 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.
7
Tous droits réservés © 2008 Frédérick Lussier
Équipe autodirigée
C’est une équipe qui:o possède des compétences complémentaires;o s’engage envers la vision et les objectifs d'équipe communs;o possède un degré élevé d’indépendance et « d’empowerment »;o a le sens de l’adhésion et de l'appartenance;o développe la meilleure stratégie pour atteindre les objectifs;o prend ses propres engagements;o se partage les rôles et les responsabilités de leadership;o a l’habileté de résoudre activement des problèmes et les conflits;o accepte l’imputabilité mutuelle et individuelle;o dispose de leur processus et de leur plan;o est dédié à l’excellence et au succès;o dirige leurs projets;o 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;
8
Tous droits réservés © 2008 Frédérick Lussier
De quoi a-t-elle besoin?
o Être challengée par des objectifs;o Avoir un management qui met l’accent sur les objectifs;o Avoir un management transparent;o Avoir le support du management;o Avoir du feedback régulier de sa performance;o Avoir des coéquipiers compétents;o Avoir un environnement qui permet de progresser librement, une
communication ouverte;o Avoir du fun.
9
Tous droits réservés © 2008 Frédérick Lussier
Les raisons pour bâtir une équipe
Outre de développer un produit.o Améliorer la productivité;o Améliorer la communication;o Améliorer la coopération;o Mobiliser une équipe;o Apprendre à se connaître;o Mettre tous les équipiers sur le même diapason, incluant les
objectifs;o Enseigner l'autorégulation d'équipe;o Apprendre à identifier et à utiliser les forces et faiblesses de ses
coéquipiers.
10
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
TSPtm/PSPtm
11
Tous droits réservés © 2008 Frédérick Lussier
TSP/PSP Historique
CMM v1.1 introduit par Watts S. Humphrey – Standard Engineering Institute (SEI) en 1991
o 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é
12
Tous droits réservés © 2008 Frédérick Lussier
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.
13
• 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.
Tous droits réservés © 2008 Frédérick Lussier
Équipes performantes
Le TSP construit des équipes performantes à partir des individus
14
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é
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 équipesde 2 à 20 membres
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Bâtir une équipe
15
Tous droits réservés © 2008 Frédérick Lussier
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.
16
Tous droits réservés © 2008 Frédérick Lussier
Activité de lancement
Les ateliers accélèrent la fondation de l’équipe:o Une compréhension commune
du travail à effectuer;o Un accord sur la façon
d’effectuer le travail;o Un engagement au projet;o 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.
PostMortem
17
Tous droits réservés © 2008 Frédérick Lussier
Atelier 1 - Objectifs et les exigences
La première étape de l’équipe est de comprendre ce qu’elle a à faire.
18
Équipe• Écouter sans intervenir• Poser des questions pour
comprendre • Aucun engagement de l’équipe
Équipe• Écouter sans intervenir• Poser des questions pour
comprendre • Aucun engagement de l’équipe
Dat
es
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
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?
Tous droits réservés © 2008 Frédérick Lussier
Ateliers 2 - 8
o Définir les objectifs de l’équipe et les rôles des membres;o Définir la stratégie et les règles d’équipe;o Définir et adapter les processus pour chacun des produits livrables;o Produire un calendrier de travail pour chacun des membres selon leurs
disponibilités;o Produire un plan réaliste du projet;o Produire un plan qualité du projet;o Identifier les risques, les opportunités et les hypothèses des plans;o Préparer la présentation pour la revue de direction.
Un plan prêt à l’exécution le lendemain.
19
Il est plus facile d’obtenir l’engagement sur le projet, lorsque les individus prévoient eux-mêmes leurs projets.
Tous droits réservés © 2008 Frédérick Lussier
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.
20
Équipe• Présente sa stratégie;• Répond aux questions;• Montre les faits;• S’engage.
É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.
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.
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement – Altelier 2
21
Tous droits réservés © 2008 Frédérick Lussier
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éfauto 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.
22
Tous droits réservés © 2008 Frédérick Lussier
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
o Des volontaires sont assignés aux rôles;• En plus de leurs tâches dans le projet.
o Un membre peut jouer plusieurs rôles, mais pas tous.
o 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
23
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.
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Rôles fixesAccompagne surleur leadership
o Met l’accent sur les objectifso Communique et observer les
objectifs;o Supporte l’équipe;o Donne du feedback.
24
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Sommaires des rôles (1/5)
25
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Sommaires des rôles (2/5)
26
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.
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Sommaires des rôles (3/5)
27
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Sommaires des rôles (4/5)
28
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.
Tous droits réservés © 2008 Frédérick Lussier
Atelier 2- Objectifs d’équipe et assignation des rôles.
Sommaires des rôles (5/5)
29
Utilisez des titres qui veulent dire quelque
chose pour vous.
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement – Altelier 3
30
Tous droits réservés © 2008 Frédérick Lussier
Atelier 3- Établir les stratégies, les produits et les processus.
Établir la stratégie
o Dessiner un draft de l’architectureo Déterminer les livrableso Pour chacun des livrable,
déterminer le processus• Le PSP donne cette compétence
o Estimer la taille et la complexité des livrables• Le PSP donne cette compétence
o Déterminer vos besoins• Outils• Formations• Matériels• etc.
o Déterminer les cycles et leurs durées• Basé sur les priorités des exigences
déterminées le contenu des itérations
31
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?
Tous droits réservés © 2008 Frédérick Lussier
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.
Test & Conception
Code
Post mortem
Exemple d’un processus logiciel
Exécution de tests unitaires
Plan
Comment allez-vous m’assurer que votre
produit est de qualité?
Il vous manque des étapes de revue.
32
Tous droits réservés © 2008 Frédérick Lussier
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éveloppementCycle de
développementCycle de
développement
Cycle de développement
Cycle de développementDévelopmentDévelopment
Leçons apprisesChangements d’exigencesChangements d’équipeChangements d’objectifsRisquesEtc.
Leçons apprisesChangements d’exigencesChangements d’équipeChangements d’objectifsRisquesEtc. Produit
intermédiaireProduit intermédiaire
Spécifications du cycle, Stratégie, Estimation, Plans de projet, Processus, Engagement de l’équipe, Plan détaillé du cycle en court
Spécifications du cycle, Stratégie, Estimation, Plans de projet, Processus, Engagement de l’équipe, Plan détaillé du cycle en court
Produit finalProduit final
PréparationPréparation
Objectifs organisationnels et techniques; Sommaire des exigences
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.
33
lancement
relancement
Tous droits réservés © 2008 Frédérick Lussier
TestExécution des tests
d’intégration, de non-régression et fonctionnels
Atelier 3- Établir les stratégies, les produits et les processus.
Adaptation à Agile
Plan
Test & Conception
Revue et Inspection conception
Code
Revue et Inspection Code
Analyse de code
Exécution des tests
PostMortem
Gu
ide
P
SP
Exigences & SpécificationsExigences 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
ValidationExécution des tests
d’acceptation
Intégration continue
DéploiementPré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.
Cyc
leRencontre debout
journalière
EnvironnementSalle de travail, Serveurs,Intégration continue, Outils de développement,
Machines de tests, Processus, standards, Formation...
Itération 3
ArchitectureVision de l’équipe de
l’architecture
Coach
Relâche 0
34
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement – Altelier 4
35
Tous droits réservés © 2008 Frédérick Lussier
Atelier 4- Estimer les tâches et la disponibilité des ressources
o Assigner les livrables et les tâches aux coéquipiers;
o 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.
o Déterminer le temps nécessaire pour chacune des tâches;• Le PSP donne cette compétence.
36
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?
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement– Altelier 5
37
Tous droits réservés © 2008 Frédérick Lussier
Atelier 5- Établir le plan qualité
• Le PSP donne cette compétence.
o Déterminer si vous avez suffisamment d’étapes pour assurer un produit de qualité;
o Estimer le nombre de défauts que vous allez injecter et le nombre de défauts que vous allez corriger par étapes;
o Estimer le temps passé dans la qualité (Revue, inspection, analyse de code et exécution de tests).• Passez-vous assez de temps
38
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.
Test & Conception
Revue de conception
Code
Analyse code
Revue de code
Test unitaireVous 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é?
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement – Altelier 6
39
Tous droits réservés © 2008 Frédérick Lussier
Atelier 6- Établir les plans personnels et le plan nivelé du projet.
o Assigner les tâches de la prochaine phase/cycle/itération aux membres;
o Négocier les tâches dépendantes et les tâches ayant multiples ressources;
o Consolider les plans individuels dans un plan de projet;
o Revoir les différents plans et niveler les charges de travail à travers tous les coéquipiers.
40
Pierre comment peut-on t’aider?
Occupation de la semaine par ressourceSemaine 23
Pierre 163%Jean 20%Jacques 60%Johanne 80%
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?
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Lancement – Altelier 7
41
Tous droits réservés © 2008 Frédérick Lussier
Atelier 7 - Identifier et évaluer les risques.
o Identifier les risques;– Il y a un risque que…causé par…
provoquant…
o Mesurer l’impact;o Mesurer la probabilité; o Déterminer les éléments
déclencheurs;o Mitiger les risques critiques;o Assigner un responsable (suivre
le risque).
42
(3) * (4)
Impact T. élevé (5)
Impact élevé (4)
Impact modéré (3)
(1) * (5)
(1) * (3)
(1) * (4)
(4) * (5)
(4) * (4)
(4) * (3)
Impact T. faible (1)
(1) * (1) (2) * (1) (3) * (1)
Impact faible (2)
(2) * (2)
(5) * (5)
(5) * (4)
(5) * (3)
(5) * (2)
(2) * (3) (3) * (3)
(2) * (5) (3) * (5)
(2) * (4)
Probabilité T. faible (1)
(4) * (2)
(4) * (1)
Probabilité T.élevée (5)
(5) * (1)
Probabilité élevée (4)
(3) * (2)
Probabilité faible (2)
Probabilité modérée (3)
(1) * (2)
Impacts
Probabilités
Qu’elles sont les obstacles que vous prévoyez avoir en cours de route?
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Bâtir multiples équipes
43
Tous droits réservés © 2008 Frédérick Lussier
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.
ManagerClient
ManagerClient
Le représentant du client
Le testeur
Le qualiticien
Le chef des processus EPGEPGQAQATestTest
MarketingMarketing
OrganisationOrganisationChef d’équipe
Etc.
Projet 1
Projet 2
Projet 3
Projet 4
Communication et collaboration
Objectifs et exigences
PMOPMOLe planificateur
44
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
Application de la stratégie
45
Tous droits réservés © 2008 Frédérick Lussier
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.
o 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.
46
Quand le plan ne vous guide plus, relancer le projet.
Tous droits réservés © 2008 Frédérick Lussier
Bâtir une équipe de développement(Team Software Processtm / Personal Software Processtm)
État du TSPtm/PSPtm
47
Tous droits réservés © 2008 Frédérick Lussier
État du TSP/PSP
Guide pour tous;
Atout dans description des postes;
• Certified PSP deveoper• Microsoft IT, Intuit, etc
Outil Open sourcehttp://processdash.sourceforge.net/
48
ABBAdobeAISBechtelBoeingBlackBerryCensus BureauDavis SystemsDFAS
EDS-SDRCEricksonFujifilmHelsanaHitashi Soft EngineeringHoneywellIBMIntuitKPMG
LockheedMicrosoft ITMotivaNASA LangleyNorthrop GummanOracleQuarkSoftRaytheonSamsung
SofttekSunTeradyneToshibaUSAF: Hill AFBUSN: NAVAIRVicarious Visions...
Graduation avec PSP
Graduation avec PSP
48
Tous droits réservés © 2008 Frédérick Lussier
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.
49
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
Tous droits réservés © 2008 Frédérick Lussier
Performance des équipes TSP/PSP
Mesures AvecTSPMoyenneMin – Max
Projet typique
System test defects (defects/KLOC)
0.40 to 0.9
15
Released defects (defects/KLOC)
0.060 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.50.2 to 0.8
51 to 7.7
Unit Test - cost of quality 17%4% to 38%
50%
Project schedule error 6%-20% to 27%
180%
The Team Software Process (TSP) in Practice: A Summary of Recent Results CMU/SEI-2003-TR-014 and CMU/SEI-2000-TR-
015
7.5
6.24
4.73
2.28
1.050.06
0
1
2
3
4
5
6
7
8
Def
ects
/KL
OC
CMMLevel 1
CMMLevel 2
CMMLevel 3
CMMLevel 4
CMMLevel 5
TSP
Defect Density of Delivered Software
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 & PresidentTSP Symposium 2008
Mesures Moyenne
Productivity improvement 78%
50
1/3 des projets n’ont pas de défaut
Tous droits réservés © 2008 Frédérick Lussier
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.
51
Frédérick Lussier ([email protected])
Senior Consultant
---> "SEI-Certified PSP Developer"
---> "SEI-Authorized Instructor for PSP“
---> “Certified SCRUM Master”
Tous droits réservés © 2008 Frédérick Lussier
Questions - Discussions
Merci de votre attention
52
Tous droits réservés © 2008 Frédérick Lussier
Références
http://www.sei.cmu.edu/tsp/
Mapping TSP to CMMIo CMU/SEI-2004-TR-014 James McHale & Daniel S. Wall
The Team Software Process (TSP) in Practice: A Summary of Recent Results
o 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)
o CMU/SEI-2002-TR-008 Noopur Davis, Jim McHale, with Strategy & Overview by Watts Humphrey
The Personal Software Process (PSP)o CMU/SEI-2000-TR-022
The Team Software Process (TSP)o CMU/SEI-2000-TR-023 Watts Humphrey
53