La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Organisation d’équipes GEF492A 2012 Référence: [HvV §5.2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique.

Présentations similaires


Présentation au sujet: "Organisation d’équipes GEF492A 2012 Référence: [HvV §5.2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique."— Transcription de la présentation:

1 Organisation d’équipes GEF492A 2012 Référence: [HvV §5.2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL15-OrganisationEquipes.pdf

2 Aperçu Organisation par secteur d’activité Structure d’organisation d’équipe logicielle Choisir la bonne structure d’organisation 2 Automne 2014GEF492

3 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 3 Automne 2014GEF492

4 Organisation par secteur d'activité (typique) 4 Automne 2014GEF492 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 AProjet BProjet n...

5 4 Styles de gestion Style 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 Haute Directivité vers la tâche Attention vers les résultats et comment ils sont obtenus 5 Automne 2014GEF492 Directivité vers les relations Attention vers les individus et leurs relations dans l'organisation Basse Haute

6 Structures organisationnelles d'équipes logicielles Hiérarchique Matrice Équipe du chef programmeur Équipe SWAT Structure ouverte 6 Automne 2014GEF492

7 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 styles 7 Automne 2014GEF492

8 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 8 Automne 2014GEF492

9 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 9 Automne 2014GEF492

10 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? 10 Automne 2014GEF492

11 É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 11 Automne 2014GEF492

12 É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 12 Automne 2014GEF492

13 É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 13 Automne 2014GEF492

14 É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 14 Automne 2014GEF492

15 É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 15 Automne 2014GEF492

16 É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 16 Automne 2014GEF492

17 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 17 Automne 2014GEF492 Le facteur humain est plus important que les éléments techniques

18 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" 18 Automne 2014GEF492

19 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 19 Automne 2014GEF492

20 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. 20 Automne 2014GEF492

21 Skunk Works ® 14 Basic Operating Rules 1.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. 21 Automne 2014GEF492

22 Skunk Works ® 14 Basic Operating Rules 7.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. 22 Automne 2014GEF492

23 Skunk Works® 14 Basic Operating Rules 11.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. 23 Automne 2014GEF492

24 Référence supplémentaire 24 Automne 2014GEF492 Royce, Walker, Software Project Management - A Unified Framework, Addison-Wesley, ch. 11

25 GESTION DE RISQUES Prochaine séance 25 Automne 2014GEF492


Télécharger ppt "Organisation d’équipes GEF492A 2012 Référence: [HvV §5.2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique."

Présentations similaires


Annonces Google