640 likes | 827 Vues
La Gestion de projets (informatiques) et la question de la collaboration. G. Beauvallet Octobre 2007. Pourquoi ce cours ?. Eclairer la diversité des pratiques et des vocabulaires Eviter les pièges basiques Tenter de repérer quelques principes organisateurs
E N D
La Gestion de projets (informatiques)et la question de la collaboration G. Beauvallet Octobre 2007
Pourquoi ce cours ? • Eclairer la diversité des pratiques et des vocabulaires • Eviter les pièges basiques • Tenter de repérer quelques principes organisateurs • Comprendre les représentations dominantes que vous rencontrerez dans le cours de vos projets • Rôle de la métaphore dominante (framing, Lakoff) • Repérer des points d’incertitude, voire de crise • leviers possibles d’une transformation
Déroulement • I. Introduction aux théories de la gestion de projet • II. Conférence « VIP » sur le mode coopératif de gestion de projet • III. Exploration détaillée de trois facettes • 1. Gérer un projet, de la théorie à la pratique • 2. La modalité « libre » de coopération • 3. L’Evolution des outils numérisés de coopération • Etude de cas finale • N’hésitez pas à ouvrir le débat
Validation et exigences • Notation • Exposé collectif (50%) • Etude de cas finale [1h] (50%) • Modalités • Une réflexion collective et ouverte • Sur la base d’une littérature que vous ne connaissez (peut-être) pas (encore) • Exemples informatiques, portée générale • Qui vous soit utile en pratique par la suite • Vous travaillez pour vous
Plan • 0. Qu’est-ce qu’un projet informatique ? • I. Le mode classique de gestion de projet • II. Remise en perspective • III. Pratiques contemporaines • N’hésitez pas à ouvrir le débat
Un Exercice de création ? « The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. » Frederick P. Brooks, Jr.
La Malédiction du projet informatique x3 x3 F. Brooks, The Mythical Man Month, 1975
Le Triangle de la gestion de projet… Qualité Satisfaction j.h Coût Charge Répartition Délais Risque
Notion d’équipe optimale « Loi de Brooks » « Comment s’organise-t-on ? »
Décomposition en tâches élémentaires • La méthode « Waterfall » : • Distinction d’étapes et de livrables • Séquence figée d’étapes • Responsabilités définies • Compétences distinctes • Estimation des charges possible • Suivi par les délais à chaque étape • Jointures entre étapes adjacentes
Program Evaluation and Review Technique (1958) 1910’s Les Outils de gestion mis en œuvre
Un Bilan globalement positif… A Survey of more than 352 companies reporting on more than 8,000 software projects stated that: • 31% of all software projects are canceled before completion • 53% of projects cost at least twice their original estimate • 9% of projects are on time and within budget (large companies) • 16% of projects are on time and within budget (small companies) The CHAOS Report, The Standish Group, 1994
Les Choses se sont-elles améliorées ? Evolution du taux de succès des projets informatiques
Gaspillages dans les projets • Gaspillages : • attente budget, • attente test et • validation utilisateurs • Quelques exemples réels : • “Lead time” : 7 mois • Temps d’attente : 2 à 3 mois • Temps de valeur ajoutée (design, développement, formation) : 3 mois C. Chabiron, Faurecia, février 2007
Raffinements méthodologiques Renforcement de la discipline Remèdes à ces problèmes
La Méthode en V Vise à préparer les étapes aval lors des étapes amont pour éviter les mauvaises surprises
La Méthode en Y Vise à éviter les temps d’attente technique
Le Modèle en spirale Barry Boehm, 1980
ISO 9000 CMMI Ingénierie contractuelle du risque Fiabiliser la cascade ?
Les Origines du développement informatique • 50’s : logiciel « sans valeur », produit en interne • 1950-1960’s : taille et durée croissante (SAGE, SABRE) • Invention FORTRAN/COBOL : émergence de la société de service en développement informatique Semi-Automatic Ground Environment (SAGE) Air Defense System, 1954
L’invention de la « Cascade » • 1965-69 : boom de l’industrie du logiciel • Formalisation de méthodes reposant sur la notion de « flow chart » et les outils adéquats • Importée du développement de système d’armes
Formalisation : « Royce’s Waterfall » SYSTEM REQUIRE- MENTS « Managing the Development of Large Software Systems », W. Royce, 1970 SOFTWARE REQUIRE- MENTS
L’Essor de la cascade • « If men define situations as real, they are real in their consequences. » (W. Thomas, 1928) • Succès fulgurant (malgré Royce) • Une mode chez les acheteurs publics confrontés au problème de la contractualisation • Department of Defense • OTAN (internationalisation) • NASA • Un Outil de suivi des sous-traitants • Qui a fini par structurer le marché • A partir des outils/documents qu’il mentionne • Ce succès par « contamination métaphorique » est-il légitime ?
Polaris : la véritable histoire The Polaris System Development, H. Sapolsky, Harvard University Press, 1972
Une nouvelle optimisation • Processus déterministe : • « minimiser le temps et le coût nécessaire pour parcourir l’ensemble des étapes nécessaires. » • Organiser un voyage collectif • Processus empirique : • « maximiser les apprentissages des besoins utilisateurs et des technologies utilisées dans un temps et un coût défini. » • Organiser une exploration collective
Conceptual integrity Master Developers Developers Excellent detailed information flow Operators Analysts & Testers Maintainers Apprentissages et intégrité(s) Perceived integrity Subject Matters Expert Excellent detailed information flow Users Customers & Process Or Product Owners Poppendieck (2003) Et dans la pratique réelle, à quoi cela correspond-il ?
Le Développement chez Google • Gestion multi-projets • Projets officiels pour 80% • Projet personnel pour 20% • « Wish lists »de chaque projet officiel pouvant faire l’objet de travaux personnels • Flux d’innovation considérable • Tentatives d’écarts : difficultés et échecs (« Google Check-Out »)
Le Développement chez Microsoft Tech Assistant Data Admin Développeur Sys Admin Rep fonctionnel Logiciel Rep Commercial Testeurs Office Assistant Testeurs
Les nouvelles conditions du développement • L4G, Objets, AGL, etc. • Vers une substitution des « objets » aux méthodes de développement ? • « Codeless Software » : rêve des années 1990 • Le Renouveau des langages structurés sur le web • HTML, XML… • PHP… • Modularité et empilement
Un nouveau problème… • Il ne s’agit pas de remplacer la cascade • Mais de ne pas la suivre aveuglément • Ce que d’ailleurs à peu près personne ne faisait plus • Et de prescrire des méthodes de management complémentaires assurant la maximisation des apprentissages • C’est l’origine des avancées méthodologiques contemporaines • Logiciel libre • Méthodes agiles
Le Logiciel libre • En 1953, le logiciel était « libre » • Et le partage de code la règle (SHARE) • Séparation hard/soft à IBM (1969) • Montée des enjeux de propriété intellectuelle • Free Software Foundation • La Cathédrale et le Bazar (Raymond, 1997) • « Given enough eyeballs, all bugs are shallow. » (Linus’s Law) • Gestion de projet fondée sur l’abondance de main d’œuvre et la redondance des travaux R. Stallman L. Torvalds
Qu’est ce que le développement agile ? «Les méthodes de développement de type Agile suivent un mode de développement itératif et incrémental, une planification de projet évolutive et encouragent les retours d’expériences fréquents du client. Elles incluent également toute une série d'autres valeurs et pratiques qui encouragent l'agilité et une réponse aux changements. » Craig Larman, 2003 Deux pratiques fondatrices : • l’itération comme modalité d’apprentissage • La recherche d’erreur « à la source » (jidoka)
Représentation de la gestion de projet R. Pierquin, CVF, février 2007
Notion de Vélocité R. Pierquin, CVF, février 2007
Jidoka : Test-Driven Development Métier à tisser automatique, Sakichi Toyoda, 1890’s Grant McLean, juin 2006