12/01/2006 La Gestion de projets (informatiques) et la question de la collaboration G. Beauvallet...

12/01/2006

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

G. Beauvallet

Octobre 2007

- Une (Petite) Histoire de la gestion de projets informatiques Mars 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


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


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


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

A

Program

A Programming

System

(interfaces, intégration)

A Programming

Product

(généralisation, test,

documentation, maintenance)

A Programming

Systems Product

x3

x3

F. Brooks, The Mythical Man Month, 1975


Le Triangle de la gestion de projet…

QualitéQualitéSatisfactionSatisfaction

CoûtCoûtChargeChargeRépartitionRépartition

DélaisDélaisRisqueRisque

j.hj.h


Notion d’équipe optimale

« Loi de Brooks »

« Comment s’organise-t-on ? »« Comment s’organise-t-on ? »


I. Le Mode classique de gestion de projetI. Le Mode classique de gestion de projet


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


Les Outils de gestion mis en œuvre

Program Evaluation and Review Technique (1958)

1910’s


L’Insertion dans des méthodes formelles

MERISE


Difficultés de mise en place


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


L’Effet « Perte en ligne »


L’Effet « Qui peut le plus… »


Les Choses se sont-elles améliorées ?

Evolution du taux de succès des projets informatiques


Gaspillages dans les projets 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

Gaspillages :•attente budget, •attente test et validation utilisateurs

C. Chabiron, Faurecia, février 2007


Remèdes à ces problèmes

Raffinements méthodologiques Renforcement de la discipline


La Méthode en V

Vise à préparer les étapes aval lors des étapes amontpour éviter les mauvaises surprises


La Méthode en Y

Vise à éviter les temps d’attente technique


Le Modèle en spirale

Barry Boehm, 1980


Fiabiliser la cascade ?

CMMI

ISO 9000

Ingénieriecontractuelledu risque


II. Remise en perspectiveII. Remise en perspective


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

SOFTWAREREQUIRE-

MENTS

« Managing the Development of Large Software Systems »,

W. Royce, 1970


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 ?


Le Projet Polaris (1957-1960)


Polaris : la véritable histoire

The Polaris System Development, H. Sapolsky,

Harvard University Press, 1972


Le Cœur du problème


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


Perceived integrity

Subject Matters Expert

Users

Customers & ProcessOr Product Owners

Apprentissages et intégrité(s)

Conceptual integrity

Excellent detailed information flow

Maintainers

Analysts & Testers

MasterDevelopersDevelopers

Operators

Poppendieck (2003)

Excellent detailed information flow

Et dans la pratique réelle, à quoi cela correspond-il ?


Une nouvelle métaphore du projet…


Takeuchi et Nonaka


III. Pratiques contemporainesIII. Pratiques contemporaines


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

Développeur

Testeurs

Testeurs

RepCommercial

Repfonctionnel

Sys Admin

DataAdmin

OfficeAssistant

Tech Assistant

Logiciel


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 Il ne s’agit pas de remplacer

la cascadela cascade

Mais de ne pas la suivre Mais de ne pas la suivre

aveuglémentaveuglément

Ce que d’ailleurs à peu près Ce que d’ailleurs à peu près

personne ne faisait pluspersonne ne faisait plus

Et de prescrire des méthodes de management complémentaires Et de prescrire des méthodes de management complémentaires

assurant la maximisation des apprentissagesassurant la maximisation des apprentissages

C’est l’origine des avancées méthodologiques contemporainesC’est l’origine des avancées méthodologiques contemporaines

Logiciel libreLogiciel libre

Méthodes agilesMé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


Le Développement agile (2001)


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)


Itération : Fixed-Box Development


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

Grant McLean, juin 2006

Métier à tisser automatique, Sakichi Toyoda, 1890’s


Quelques noms de méthodes

eXtreme Programming

Scrum

RUP (Rational Unified Process)

FDD ( Feature Driven Development)

Etc.


eXtreme Programming : les « valeurs »

Communication Dans l’équipe Avec le client

Feedback Du client De l’équipe

Simplicité « You’re not gonna need it » Economies Précisions

Courage Confiance en XP Remise en cause des méthodes


Cycle de vie d’un projet XP


Les 4 phases d’un cycle de livraison XP


SCRUM

Principes : Plus orienté sur la gestion des ressources humaines Très complémentaire de la méthode XP Très peu formalisé: privilégie le management par rapport au

développement

Pratique : Identification rapide des changements Donner/Faire confiance aux développeurs Réunion d’avancement tous les jours


Cycle de vie Scrum


Conclusion

0. Le Projet logiciel

Mode « cascade » dominant

Critique et apport « empirique »

Méthodes contemporaines

Et la Coopération dans tout ça ?

Appréhender le groupe• Conférence JM Cornu

Travail préparatoire de réflexion • sur un groupe de votre choix

Et maintenant ?

Conférence JM Cornu

Puis exposés d’approfondissement

3 séries• Sujets : cf. recueil d’articles• Matière : recueil + allez au-delà

20’ d’exposé + 10’ Q&A

Principe : • vous allez explorer une question pour la promotion• vous en rapportez une synthèse pour tous• Vous pouvez distribuer une fiche « mémoire »

Répartition des exposés pour demain 16h45

- La Gestion de projets (informatiques) et la question de la collaboration - Octobre 2007


DiscussionDiscussion

Bibliographie sommaire

Boehm, B. (1981) Software Engineering Economics, Prentice Hall

Brooks, F. (1975) The Mythical Man Month, Addison Wesley Longman

Campbell, M. (2003) From Airline Reservations to Sonic the Hedgehog: A

History of the Software Industry, MIT Press

Koskela, L. (2002) « The Underlying Theory of Project Management is

Obsolete », Project Management Institute

Poppendieck, M. & T. (2003) Lean Software Development, Addison-Wesley

Professional

Raymond, E. (1997) « The Cathedral and the Bazaar »

Schwaber, K. & Beedle, M. (2002) Agile Software Development with Scrum,

Prentice Hall

Takeuchi, H. & Nonaka, I. (1986) « The New New Product Development

Game », Harvard Business Review, January

12/01/2006 La Gestion de projets (informatiques) et la question de la collaboration G. Beauvallet...

Documents

Transcript of 12/01/2006 La Gestion de projets (informatiques) et la question de la collaboration G. Beauvallet...