bâtir une équipe f lussier v1.2 fra

53
Tous droits réservés © 2008 Frédérick Lussier Bâtir une équipe (Team Software Process tm / Personal Software Process tm ) Présenté par : Frédérick Lussier Novembre 2009, version 1.2 e Process, PSP and Team Software Process, TSP are service marks of Carnegie Mellon University ity Model, Capability Maturity Modeling, Carnegie Mellon, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

Post on 21-Oct-2014

2.899 views

Category:

Business


1 download

DESCRIPTION

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

TRANSCRIPT

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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?

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

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.

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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.

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

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.

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

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

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

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?

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

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

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

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

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

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

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

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

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

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?

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

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

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

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é?

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

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

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

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?

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

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

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

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?

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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”

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

Tous droits réservés © 2008 Frédérick Lussier

Questions - Discussions

Merci de votre attention

52

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

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