Organisation d’équipesGEF492A 2012

Référence: [HvV §5.2]

Capt Vincent RobergeCollège Militaire Royal du Canada

Génie électrique et génie informatiqueVincent.roberge@rmc.ca roberge.segfaults.net

PPL15-OrganisationEquipes.pdf

Aperçu• Organisation par secteur d’activité

• Structure d’organisation d’équipe logicielle

• Choisir la bonne structure d’organisation

2Automne 2014 GEF492

Organisation par secteur d’activité vs organisation de projet• la plupart des études en génie logiciel se

concentrent sur la structure organisationnelle de projet• C'est important mais ce n'est pas suffisant

• on doit reconnaître les fonction logicielles dans les hiérarchies par secteur d’activité de par le rôle important des politiques de l’entreprise et de la stratégie sur le succès des projets logiciels

• on doit avoir du personnel dédié au logiciel au niveau de l’entreprise, hors du projet "égoïste"• la vie d'un projet est trop courte

3Automne 2014 GEF492

Organisation par secteur d'activité (typique)

4Automne 2014 GEF492

Chef de la direction(CEO)

Instance processus en génie logiciel

-Définition et amélioration de processus

Instance de révision de projets logiciels

- Évaluation de projets

Instance environnement en

génie logiciel- Automatisation du processus

Infrastructure logicielle

- Entraînement e t support

Projet A Projet B Projet n...

4 Styles de gestionStyle relationnel

Les gens veulent être motivés, dirigés et entraînés. Les tâches sont reliées aux individus. Le travail n'est pas routinier mais innovateur, complexe et spécialisé. Les décisions sont prises par le groupe. La faiblesse est que ceci peut causer des réunions chaotiques qui n'en finissent pas

Mécanisme de coordination– Ajustement mutuel ou la standardisation des aptitudes ouvrières

Style d'intégration Situations où le résultat est incertain. Le

travail est de nature exploratoire et les tâches très indépendantes. Les décisions sont informelles, et vienne des ouvrier. La faiblesse est que les gens risque de devenir déconnecté des objectifs du projet.

Mécanisme de coordination - Ajustement mutuel

Style séparation Très efficace pour le travail routinier. Le

thème central est l'efficacité. La gestion applique des règles et procédures. La prise de décision est formelle, et basée sur l'autorité. La faiblesse est que bien que l'organisation soit stable, l'environnement n'est pas propice aux innovations.

Mécanisme de coordination– Supervision directe ou la standardisation des produit de travail.

Style engagement Très efficace si le travail doit être accomplit

sous pression. Le gérant doit pouvoir atteindre ses objectifs sans vexer les ouvrier. La prise de décision découle d'une vision partagée par l'équipe. La faiblesse est l'engagement envers la vision commune et l'inhabilité à répondre aux changements.

Mécanisme de coordination– Standardisation des aptitudes ouvrières ou des produits de travail

Basse HauteDirectivité vers la tâche

Attention vers les résultats et comment ils sont obtenus

5Automne 2014 GEF492

Dir

ecti

vit

é v

ers

les r

ela

tion

sA

ttenti

on v

ers

les

indiv

idus

et

leurs

rela

tions

dans

l'org

anis

ati

on

B

asse

Hau

te

Structures organisationnelles d'équipes logicielles

• Hiérarchique

• Matrice

• Équipe du chef programmeur

• Équipe SWAT

• Structure ouverte

6Automne 2014 GEF492

Organisation hiérarchique• Couches distinctes travailleurs /

gestionnaires• Convient à la production de logiciel• Souvent organisée selon la structure du

système• Comprend souvent des sous-équipes

responsables pour secteurs affectant tout le projet• E.g: gestion de configuration, test, AQ

• Coordination: au niveau de projet, habituellement selon un processus ou des produits de travails standardisés• Bien que certains sous-systèmes peuvent

requérir d'autre styles7Automne 2014 GEF492

Désavantage – Org hiérarchique• connaissances spécifiques et travail se trouvent

au plus bas niveau de la pyramide, alors que le pouvoir décisionnel est au haut• la transmission d'information entre le haut et le bas est

un processus de communication avec pertes (lossy)

• la séparation de l'évaluation du projet et de l'évaluation des individus est difficile à faire

• Le Principe de Peter – une personne est promue jusqu'à son niveau d'incompétence• des habilités différentes sont requises à chaque niveau• la promotion n'est pas toujours bonne récompense

8Automne 2014 GEF492

Organisation par matrice• le personnel est employés comme

consultants au niveau de l'entreprise, travaillant à plusieurs équipes simultanément

• une équipe de projet est formé d'un petit cadre propre à l'équipe et de consultants d'entreprise

• les groupes de la matrices sont habituellement formé selon des spécialisation commune• IUG, base de données, fiabilité, estimation

• coordination: la coordination des tâches de la matrice convient à la standardisation des aptitudes ouvrières

9Automne 2014 GEF492

Org par matrice - Désavantages• requiert beaucoup de confiance et de

coopération entre les gérant de la matrice et les gérants de projets• les objectifs du gérant de projet sont "égoïste"

et à court terme• les objectifs du gérant de la matrice sont à

long terme, pour le bénéfice de l'entreprise en entier

• les "ouvriers" peuvent avoir l'impression d'avoir plusieurs patrons, les tirants en de différentes directions• la loyauté n'est pas toujours évidente

• pour qui travaillent-ils vraiment?10Automne 2014 GEF492

Équipe du programmeur chef• Similaire à l'équivalent logiciel de l'équipe

chirurgicale [Bro]• très petites équipes• noyau de trois personnes

• Programmeur chef – chef d'équipe, architecte et programmeur principal (compétences techniques et de gestion)

• Adjoint• libraire – administrateur du projet et responsable pour la

documentation, peut être un nouveau programmeur (stagiaire)

• Coordination: parce que l'équipe est petite, et que le programmeur chef est prédominent, la coordination prend habituellement la forme de supervision directe

11Automne 2014 GEF492

Équipe. du programmeur chef - Désavantages• élitiste

• risques de friction enter l'équipe du programmeur chef et les autres types de projets dans l'entreprise

• trouver assez de "bons" programmeurs chefs• il arrive souvent que les bon programmeurs

font de mauvais gestionnaires

• frictions si des membres de l'équipe défient les compétences/décisions du programmeur chef 12Automne 2014 GEF492

Équipe SWAT- “Skilled With Advanced Tools” • pour projets itératifs ou évolutionnaires• équipes relativement petites (4-5 personnes)• bâtît des incréments de systèmes logiciels

• utilise techniques "tableau blanc" ou "remue-méninges", construction par composantes, langages de haut-niveau et générateurs de code

• souvent supporté par outils collecticiel (groupware) ou de gestion de processus

• le chef d'équipe SWAT est plutôt un contremaître• Les membres de l'équipes ont habituellement

plusieurs habilités

• Coordination: un mélange de standardisation de processus (associé aux outils) et d'ajustement mutuel

13Automne 2014 GEF492

Équipe SWAT - Désavantages• hautement influencé par le niveau de

motivation et de coopération des membres de l'équipe• nécessite la motivation de tous• Nécessite que tous s'entendent

• Deux chose difficiles à maintenir pour longtemps

• peut être difficile de mettre à l'échelle• problèmes de coordination de plusieurs

équipes SWAT envers un but commun• requiert beaucoup d'homogénéité dans les

outils

14Automne 2014 GEF492

Équipe à structure ouverte• combinaison de style de gestion ouvert

(pour encourager l'innovation) avec des structures de contrôle (pour assurer le respect des délais)

• Gestion ouverte• les décisions internes sont obtenues par

consensus• le chef technique est responsable pour les

contrôles extérieurs et le décisions contentieuses

• les membres de l'équipe font rotation aux autres rôles

• Structure• le chef technique assure la progression• tous les produit, processus et décisions sont

documentés

15Automne 2014 GEF492

Équipe à structure ouverte - Désavantages• décisions prises par vote majoritaire

• peut scinder l'équipe• les groupes minoritaires peuvent se distancer

des décisions

• le choix du chef technique est très sensible• on choisit cette équipe lorsque le besoin pour

l'innovation est très important;• choisir un chef technique qui n'est pas

supporté par les membres de l'équipe nuit à l'innovation

16Automne 2014 GEF492

L'importance de l'équipe• la recherche montre que les capacités de

l'équipe ont beaucoup plus qu'un impact proportionnel sur la productivité du projet• la composition et la gestion de l'équipe sont

donc critiques

• les facteurs comme le morale, les normes de groupes et le style de gestion sont donc des indices de productivité plus importants que d'autres comme les langages de haut niveau ou la complexité du produit

17Automne 2014 GEF492

Le facteur humain est plus important que les éléments techniques

Choisir la "bonne" structure organisationnelle (1)

• utilisez moins de personnel, mais choisissez de bonnes personnes• les grandes équipes ont besoins de plus de

communication, entraînant une productivité individuelle plus basse, et plus d'erreurs

• les petites équipes sont plus productives

• Visez l'équilibre et l'harmonie• choisissez une équipe complémentaire• ne choisissez pas une équipe "d'étoiles"

18Automne 2014 GEF492

Choisir la "bonne" structure organisationnelle (2)• facilitez la croissance personnelle – ne

faites pas ceci:• le principe de Peter inverse – un employé

demeure en place jusqu'à ce qu'où elle devienne indispensable

• le principe de Paul – un employé monte au point où ses habilité deviennent obsolètes

• débarrassez vous de ceux qui ne s'intègre pas• il faut vite retirez ceux qui ne conviennent pas

à l'équipe, avant qu'il ne gâche celle-ci

19Automne 2014 GEF492

Lockheed Martin's Skunk Works®

• Fondé en 1943• Formé d'un petit groupe de mécaniciens et

d'ingénieurs spécifiquement sélectionnés• Produit des aéronefs des plus

révolutionnaires• F-104 Starfighter• SR-71 Blackbird• F-117A Stealth Fighter-Bomber

• Beaucoup de succès parce que:• On sait ce dont les ouvrier talentueux ont

besoins• Comment les motiver• Comment s'assurer que le produit final est créé

aussi vite et aussi économiquement que possible. 20Automne 2014 GEF492

Skunk Works® 14 Basic Operating Rules1. The Skunk Works® manager must be delegated practically

complete control of his program in all aspects. He should report to a division president or higher.

2. Strong but small project offices must be provided both by the military and industry.

3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books ninety days late and don't surprise the customer with sudden overruns.  

21Automne 2014 GEF492

Skunk Works® 14 Basic Operating Rules7. The contractor must be delegated and must assume more

than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

8. The inspection system as currently used by the Skunk Works®, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.

9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.

10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works® practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended. 22Automne 2014 GEF492

Skunk Works® 14 Basic Operating Rules11. Funding a program must be timely so that the

contractor doesn't have to keep running to the bank to support government projects.

12. There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

23Automne 2014 GEF492

Référence supplémentaire

24Automne 2014 GEF492

Royce, Walker, Software Project Management - A Unified Framework, Addison-Wesley, 1998. ch. 11

25GEF492

GESTION DE RISQUES

Prochaine séance

Automne 2014