La Gestion de projets (informatiques) et la question de la collaboration

1. La Gestion de projets (informatiques)et la question de la collaboration G. Beauvallet Octobre 2007

2. 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

3. 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

4. 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

5. 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

6. 0. Qu’est-ce qu’un projet informatique ?

7. Données, traitements, objets, méthodes…

8. 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.

9. La Malédiction du projet informatique x3 x3 F. Brooks, The Mythical Man Month, 1975

10. Le Triangle de la gestion de projet… Qualité Satisfaction j.h Coût Charge Répartition Délais Risque

11. Notion d’équipe optimale « Loi de Brooks » « Comment s’organise-t-on ? »

12. I. Le Mode classique de gestion de projet

13. 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

14. Program Evaluation and Review Technique (1958) 1910’s Les Outils de gestion mis en œuvre

15. L’Insertion dans des méthodes formelles MERISE

16. Difficultés de mise en place

17. 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

18. L’Effet « Perte en ligne »

19. L’Effet « Qui peut le plus… »

20. Les Choses se sont-elles améliorées ? Evolution du taux de succès des projets informatiques

21. 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

22. Raffinements méthodologiques Renforcement de la discipline Remèdes à ces problèmes

23. La Méthode en V Vise à préparer les étapes aval lors des étapes amont pour éviter les mauvaises surprises

24. La Méthode en Y Vise à éviter les temps d’attente technique

25. Le Modèle en spirale Barry Boehm, 1980

26. ISO 9000 CMMI Ingénierie contractuelle du risque Fiabiliser la cascade ?

27. II. Remise en perspective

28. 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

29. 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

30. Formalisation : « Royce’s Waterfall » SYSTEM REQUIRE- MENTS « Managing the Development of Large Software Systems », W. Royce, 1970 SOFTWARE REQUIRE- MENTS

31. 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 ?

32. Le Projet Polaris (1957-1960)

33. Polaris : la véritable histoire The Polaris System Development, H. Sapolsky, Harvard University Press, 1972

34. Le Cœur du problème

35. 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

36. 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 ?

37. Une nouvelle métaphore du projet…

38. Takeuchi et Nonaka

39. III. Pratiques contemporaines

40. 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 »)

41. Le Développement chez Microsoft Tech Assistant Data Admin Développeur Sys Admin Rep fonctionnel Logiciel Rep Commercial Testeurs Office Assistant Testeurs

42. 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

43. 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

44. 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

45. Le Développement agile (2001)

46. 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)

47. Itération : Fixed-Box Development

48. Représentation de la gestion de projet R. Pierquin, CVF, février 2007

49. Notion de Vélocité R. Pierquin, CVF, février 2007

50. Jidoka : Test-Driven Development Métier à tisser automatique, Sakichi Toyoda, 1890’s Grant McLean, juin 2006