SlideShare une entreprise Scribd logo
Le développement logiciel
expliqué à votre patron
Yassine Chaouche
Décembre 2012
yacinechaouche@yahoo.com
http://ychaouche.wikispot.org/Planning
Combien de temps ça prends ?
Pour savoir combien de temps prends le développement d’un logiciel, il faut avoir
bien compris les besoins des utilisateurs;
Comprendre ce qu’on cherche à faire
• Il existe une méthode rigoureuse pour s’assurer que l’on a bien compris les
besoins des utilisateurs, c’est de spécifier de manière formelle leurs besoins dans
des spécifications fonctionnelles et de les faire valider par ces derniers;
Spécs fonctionnelles
• Une fois qu’on s’assure qu’on a bien compris le besoin et qu’on explique aux
utilisateurs rigoureusement et dans le détail à quoi le logiciel va ressembler à
travers des spécs. fonctionnelles, on peut maintenant se demander combien de
temps ça prends pour développer un logiciel répondant à ces specs.
Spécs techniques
• Une fois qu’on a les idées claires, pour savoir combien de temps est-ce que le
codage va prendre, il faut au préalable, à l’instar d’un architecte qui veut
construire une maison, dessiner les plans de manière rigoureuse et précise;
• De même, un analyste va écrire dans des spécifications techniques les plans du
logiciel à développer;
A quoi servent les spécs. techniques ?
• Les spécifications techniques vont permettre, par exemple, de savoir quelle seront
les tables à ajouter, quelles colonnes y mettre, comment seront-elles mises en
relation;
• Entre autre, elles permettent de savoir quelles seront les fonctions, classes et
méthodes à écrire ainsi que les procédures nécessaires pour répondre à une
fonctionnalité spécifiée dans le spécs. fonctionnelles;
Penser au maximum de choses
• En réalité, les spécs. techniques servent à beaucoup plus de choses que ça (fichiers
à importer, fichiers à exporter, données à indexer etc.)
• L’idée est de savoir de manière général et aussi exhaustive que possible : qu’est-ce
que nous devons techniquement faire ?
Identifier, quantifier, analyser
La réalisation d'un tel planning nécessite la mise en œuvre de technique de
planification :
• les tâches doivent être identifiées;
• les tâches doivent être quantifiées en terme de délais, de coûts et de ressources;
• la logique de l'ensemble des tâches doit être analysée.
Rien n’est parfait
• Une fois les spécifications techniques établies, on aura une idée beaucoup plus
précise de ce qu’on devra développer et les estimations de planning ne seront que
plus justes (mais pas assez justes malheureusement);
La réalité des choses…
Malgrès tous ces efforts
• Le planning d’un développeur comporte en général entre 10% à 20% d’erreur d’estimation;
• Le planning du commanditaire (hiérarchie, client...) comporte en général entre 10% et 300%
d’erreur d’estimation.
• L'expert dans le domaine c'est vous, le développeur, pas votre hierarchie ou votre client.
Réflechissez-y un instant : ce n'est pas le client qui fixe des délais pour la construction de sa
maison, c'est l'entrepreneur qui les lui donne. Ce n'est pas le patient qui fixe la durée de son
traitement, c'est son médecin ou son pharmacien qui la fixe. Ce n'est toujours pas le client
qui fixe des délais pour une réponse à un crédit bancaire, c'est le banquier qui les annonce.
C'est toujours l'expert qui donne les délais de ses préstations de services, jamais son client.
• Tenter de compresser les délais annoncés par le développeur aboutit forcément à un
dépassement de délais
Le cône d'incertitude
• En phase de démarrage, quand on n’a qu’une vague idée de ce qui est demandé, les erreurs
d’estimations sont de l’ordre de 300 %
• La marge diminue à 100% quand tout le monde se met d’accord sur le produit à développer
• 50% quand le cahier des charges est validé
• 25% quand on se met d’accord sur l’interface utilisateur.
• Les estimations ne deviennent appréciables qu’au moment où les spécifications détaillées
sont établies, la marge descend alors à moins de 20% d’erreur.
Le cône d'incertitude
Quand s'engager sur des délais ?
• Il est imprudent de s’engager sur une date dès le début du projet car les estimations sont
trop larges et peuvent être jusqu’à 4 fois inférieurs au temps réel.
• Par exemple, si une estimation est donnée en phase de démarrage à 3 mois, le projet
pourrait très bien prendre entre 6 et 12 mois.
• On ne peut donc s'engager sur des délais qu'après avoir validé les spécs et les interfaces
utilisateurs (taux d’erreur inférieur à 20%).
Répartition de l’effort
• Bien que, a priori, le codage peut vous sembler
la chose la plus importante pour vous, il ne
représente même pas 50% du temps total du
projet;
• Plus vous passerez du temps dans la phase
d’analyse, moins vous perdez du temps dans la
phase de codage. Si vous le jugez nécessaire,
vous pouvez y allouer 30% du temps total du
projet;
• Quelque soit votre expertise et votre
diversification, vous aurez une phase
d’apprentissage (nouvelles librairies, nouveaux
formats de données, nouveaux systèmes etc.);
• Ne négligez pas le recettage et la mise en
production de la version final qui peut prendre
environ 20% du temps total du projet.
25%
10%
45%
20%
Répartition de l'effort
Analyse Apprentissage
Codage Finalisation
Nous sommes des humains, pas
des robots
• Nous avons une famille, des parents, des enfants. Ces personnes naissent, meurent, se
marient, partent en vacances et tombent malades. Un planning qui ne prends pas en
compte ces points est par définition irréaliste.
• Nous avons un mental, des pressions psychologiques, des fatigues nerveuses et des
périodes de manque de sommeil. Ne forcez pas trop fort sur vos ressources humaines
pour pouvoir les garder frais et dispos on the long run.
• Nous ne sommes pas tous nés égaux en talents, compétences et motivations. Les
délais de réalisation dépendent en grande partie du potentiel de votre équipe. Prenez
ceci en compte lors de vos évaluations.
Adoptez une méthodologie de
développement
• Peu importe laquelle. Travaillez méthodiquement est toujours meilleur que de
travailler sans aucune méthode.
Méthodes iteratives
• Ce type de méthodologies ne
peuvent donner une estimation
sur la durée total du projet mais
uniquement sur l’itération
actuelle.
• La durée d’une itération diffère
selon les méthodes utilisées
(Extreme Programming, RUP,
SCRUM).
• Par exemple, dans XP, les
itérations sont de l’ordre de
quelques semaines.
Placez l'utilisateur au centre
C’est l’utilisateur qui doit mener le processus de développement en :
• Confirmant et affinant régulièrement ses besoins ;
• Priorisant les fonctionnalités à implémenter. Le chef de projet à aussi le rôle de
reprioser les tâches en fonction de l’importance de la fonctionnalité demandée, de
l’urgence, des délais demandés par les développeurs, et du retard ou avance pris sur
le projet.
• validant ce qui a été développé ;
Evitez les principales causes de
retards (1/3)
• Baisse de motivation : plusieurs études ont montré qu’aucun facteur n’était plus
déterminant que le manque de motivation de l’équipe (Bohem 1981 cité par Steve
McConnell)
• Ajouter une personne à un projet déjà en retard : Brooks compare cela à ajouter de
l’huile sur le feu.
• Expectations irréalistes : il est très difficile de faire vite dans le business du software
sans altérer sa qualité ou augmenter son coût.
Evitez les principales causes de
retards (2/3)
• Pas de retour utilisateur : comme dit précédement, l’utilisateur doit être au centre.
• Planification insuffisante : si on ne planifie pas comment atteindre rapidement
l’objectif, on ne peut s’attendre à l’atteindre rapidement.
• Certains projets qui doivent être terminés rapidement essayent de couper court à
toute activité non essentielle. L’analyse des besoins, l’architecture et la modélisation
sont les cibles favorites puisqu’elles ne produisent pas de code. Cette situation de
« sauter directement au code » a des conséquences facilement prédictibles : cette
partie du travail qui doit être faite en amont va de toute façon un jour ou l’autre être
faite en aval, mais coûtera 10 à 100 fois plus chère (Fagan 1976; Boehm and
Papaccio 1988). Si on ne trouve pas les 2 mois pour faire l’étude maintenant, allons-
nous trouver les 20 mois nécessaires par la suite ?
Evitez les principales causes de
retards (3/3)
• « Code-like-hell programming » : certaines organisations pensent que pour aller plus
vite il faut « coder-comme-un-fou ». Leurs raisonnement est le suivant : avec un bon
développeur, n’importe quel obstacle sera contourné. En réalité, c’est simplement du
« code-and-fixe » déguisé (code-et-répare) combiné avec des délais ambitieux. Cette
combinaison ne marche pratiquement jamais.
• Marchander sur les tests : prendre des raccourcis en voulant éliminer ou raccourcir la
durée des tests est une pratique courante dans des projets qu’il faut livrer au plus
vite. Des études de cas ont montré que lorsqu’un projet atteint sont stade « feature
complete », c'est-à-dire ou toutes les fonctionnalités ont été codées, sans avoir passé
du temps à écrire et implémenter des tests, il était tellement truffé de bugs qu’il
fallait encore 5 mois supplémentaires avant de pouvoir le mettre en production. Ce
résultat est typique. Enlever 1 journée d’assurance qualité en amont aura pour
conséquence de payer 3 à 10 jours de réparation en aval (Jones 1994).
Happy coding !
Chosen links
Software developement at top speed (Steve McConnell – Code Complete)

http://www.stevemcconnell.com/articles/art04.htm
Classic mistakes enumerated (Steve McConnell – Code Complete)

http://www.stevemcconnell.com/rdenum.htm
How long would it take if everything went wrong ? (Jeff Atwood – coding horror)

http://www.codinghorror.com/blog/2006/06/how-long-would-it-take-if-everything-went-wrong.html
Epopée du développement logiciel

http://ychaouche.wikispot.org/PMHistoireVecue

Contenu connexe

Tendances

Kanban et Scrum : tirer le meilleur des deux
Kanban et Scrum : tirer le meilleur des deuxKanban et Scrum : tirer le meilleur des deux
Kanban et Scrum : tirer le meilleur des deuxFabrice Aimetti
 
Kick off de projet - Fiches pratiques en français
Kick off de projet - Fiches pratiques en françaisKick off de projet - Fiches pratiques en français
Kick off de projet - Fiches pratiques en français
Sylvain Loubradou
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
Samer EL SAWDA, Ph.D.
 
Gp 02 Phases d'un Projet
Gp 02   Phases d'un ProjetGp 02   Phases d'un Projet
Gp 02 Phases d'un Projet
Claude Michaud
 
Agile - DevOps : la boite à outils
Agile - DevOps : la boite à outilsAgile - DevOps : la boite à outils
Agile - DevOps : la boite à outils
Frantz Degrigny
 
projet outils basiques version 2013
projet outils basiques version 2013projet outils basiques version 2013
projet outils basiques version 2013Rémi Bachelet
 
Management de projets (Cours Niveau 1) Généralités
Management de projets (Cours Niveau 1) GénéralitésManagement de projets (Cours Niveau 1) Généralités
Management de projets (Cours Niveau 1) Généralités
Joseph SZCZYGIEL
 
Gp 01 Genèse Des Projets
Gp 01   Genèse Des ProjetsGp 01   Genèse Des Projets
Gp 01 Genèse Des Projets
Claude Michaud
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
AgileCoach.net
 
Webinar - Gestion de projet
Webinar - Gestion de projetWebinar - Gestion de projet
Webinar - Gestion de projet
appvizer.fr
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
Pierre
 
Introduction à la Gestion de projets
Introduction à la Gestion de projetsIntroduction à la Gestion de projets
Introduction à la Gestion de projets
Clément Dussarps
 
Gp 03 Les Domaines De Gestion
Gp 03   Les Domaines De GestionGp 03   Les Domaines De Gestion
Gp 03 Les Domaines De Gestion
Claude Michaud
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
JEAN-GUILLAUME DUJARDIN
 
Gestion de projet sept 2016
Gestion de projet sept 2016Gestion de projet sept 2016
Gestion de projet sept 2016
Jean-Louis Gueroult
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
Echecs & Stratégie
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014
Rémi Bachelet
 
Management de projet ccmp
Management de projet ccmpManagement de projet ccmp
Management de projet ccmp
Fabrice Thomas
 
La gestion d’équipe de projet informatique
La gestion  d’équipe de projet informatiqueLa gestion  d’équipe de projet informatique
La gestion d’équipe de projet informatique
Abdellah Riyahi
 

Tendances (20)

Kanban et Scrum : tirer le meilleur des deux
Kanban et Scrum : tirer le meilleur des deuxKanban et Scrum : tirer le meilleur des deux
Kanban et Scrum : tirer le meilleur des deux
 
Kick off de projet - Fiches pratiques en français
Kick off de projet - Fiches pratiques en françaisKick off de projet - Fiches pratiques en français
Kick off de projet - Fiches pratiques en français
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
 
Gp 02 Phases d'un Projet
Gp 02   Phases d'un ProjetGp 02   Phases d'un Projet
Gp 02 Phases d'un Projet
 
Agile - DevOps : la boite à outils
Agile - DevOps : la boite à outilsAgile - DevOps : la boite à outils
Agile - DevOps : la boite à outils
 
projet outils basiques version 2013
projet outils basiques version 2013projet outils basiques version 2013
projet outils basiques version 2013
 
Management de projets (Cours Niveau 1) Généralités
Management de projets (Cours Niveau 1) GénéralitésManagement de projets (Cours Niveau 1) Généralités
Management de projets (Cours Niveau 1) Généralités
 
Gp 01 Genèse Des Projets
Gp 01   Genèse Des ProjetsGp 01   Genèse Des Projets
Gp 01 Genèse Des Projets
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
 
Webinar - Gestion de projet
Webinar - Gestion de projetWebinar - Gestion de projet
Webinar - Gestion de projet
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 
Introduction à la Gestion de projets
Introduction à la Gestion de projetsIntroduction à la Gestion de projets
Introduction à la Gestion de projets
 
Gp 03 Les Domaines De Gestion
Gp 03   Les Domaines De GestionGp 03   Les Domaines De Gestion
Gp 03 Les Domaines De Gestion
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Gestion de projet sept 2016
Gestion de projet sept 2016Gestion de projet sept 2016
Gestion de projet sept 2016
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014
 
Management de projet ccmp
Management de projet ccmpManagement de projet ccmp
Management de projet ccmp
 
La gestion d’équipe de projet informatique
La gestion  d’équipe de projet informatiqueLa gestion  d’équipe de projet informatique
La gestion d’équipe de projet informatique
 

Similaire à Le développement logiciel expliqué à votre patron en 24 slides

Gestion de projet digital
Gestion de projet digitalGestion de projet digital
Gestion de projet digital
Abdoul Kafid Toko Koutogui
 
Etude de faisabilité et analyse de l'existant
Etude de faisabilité et analyse de l'existantEtude de faisabilité et analyse de l'existant
Etude de faisabilité et analyse de l'existant
Clément Dussarps
 
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
French Scrum User Group
 
Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ? Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ?
Concept Image
 
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
Clément OUDOT
 
Gp finale
Gp finaleGp finale
Gp finale
Salma Gouia
 
Lean Product Development
Lean Product DevelopmentLean Product Development
Lean Product Development
XL Groupe
 
Gestion de projets Niv 1
Gestion de projets Niv 1Gestion de projets Niv 1
Gestion de projets Niv 1
Ahmed SEMOUD
 
7. Du Design UX au Design de la collaboration
7. Du Design UX au Design de la collaboration7. Du Design UX au Design de la collaboration
7. Du Design UX au Design de la collaboration
Laurent Barbat
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
JEAN-GUILLAUME DUJARDIN
 
estimation de projets informatiques estimation de projets informatiques estim...
estimation de projets informatiques estimation de projets informatiques estim...estimation de projets informatiques estimation de projets informatiques estim...
estimation de projets informatiques estimation de projets informatiques estim...
mia884611
 
Introduction Aux MéThodes Agiles
Introduction Aux MéThodes AgilesIntroduction Aux MéThodes Agiles
Introduction Aux MéThodes Agiles
Stanyslas MATAYO
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptx
OlyvierNzighou1
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
Manon Cuylits
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
Management de projet slide share
Management de projet slide shareManagement de projet slide share
Management de projet slide share
Emmanuel Urschel Villier
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
Michel Bruchet
 
Les clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entrepriseLes clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entreprise
Echecs & Stratégie
 
présentation sur l'étude d'un projet.pptx
présentation sur l'étude d'un projet.pptxprésentation sur l'étude d'un projet.pptx
présentation sur l'étude d'un projet.pptx
yassinetiaret
 
gestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthktgestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthkt
AbdelkarimAaziz1
 

Similaire à Le développement logiciel expliqué à votre patron en 24 slides (20)

Gestion de projet digital
Gestion de projet digitalGestion de projet digital
Gestion de projet digital
 
Etude de faisabilité et analyse de l'existant
Etude de faisabilité et analyse de l'existantEtude de faisabilité et analyse de l'existant
Etude de faisabilité et analyse de l'existant
 
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
 
Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ? Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ?
 
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
Évaluer un projet informatique (Challenge Entreprendre Telecom 2010)
 
Gp finale
Gp finaleGp finale
Gp finale
 
Lean Product Development
Lean Product DevelopmentLean Product Development
Lean Product Development
 
Gestion de projets Niv 1
Gestion de projets Niv 1Gestion de projets Niv 1
Gestion de projets Niv 1
 
7. Du Design UX au Design de la collaboration
7. Du Design UX au Design de la collaboration7. Du Design UX au Design de la collaboration
7. Du Design UX au Design de la collaboration
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
 
estimation de projets informatiques estimation de projets informatiques estim...
estimation de projets informatiques estimation de projets informatiques estim...estimation de projets informatiques estimation de projets informatiques estim...
estimation de projets informatiques estimation de projets informatiques estim...
 
Introduction Aux MéThodes Agiles
Introduction Aux MéThodes AgilesIntroduction Aux MéThodes Agiles
Introduction Aux MéThodes Agiles
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptx
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Management de projet slide share
Management de projet slide shareManagement de projet slide share
Management de projet slide share
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
 
Les clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entrepriseLes clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entreprise
 
présentation sur l'étude d'un projet.pptx
présentation sur l'étude d'un projet.pptxprésentation sur l'étude d'un projet.pptx
présentation sur l'étude d'un projet.pptx
 
gestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthktgestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthkt
 

Le développement logiciel expliqué à votre patron en 24 slides

  • 1. Le développement logiciel expliqué à votre patron Yassine Chaouche Décembre 2012 yacinechaouche@yahoo.com http://ychaouche.wikispot.org/Planning
  • 2. Combien de temps ça prends ? Pour savoir combien de temps prends le développement d’un logiciel, il faut avoir bien compris les besoins des utilisateurs;
  • 3. Comprendre ce qu’on cherche à faire • Il existe une méthode rigoureuse pour s’assurer que l’on a bien compris les besoins des utilisateurs, c’est de spécifier de manière formelle leurs besoins dans des spécifications fonctionnelles et de les faire valider par ces derniers;
  • 4. Spécs fonctionnelles • Une fois qu’on s’assure qu’on a bien compris le besoin et qu’on explique aux utilisateurs rigoureusement et dans le détail à quoi le logiciel va ressembler à travers des spécs. fonctionnelles, on peut maintenant se demander combien de temps ça prends pour développer un logiciel répondant à ces specs.
  • 5. Spécs techniques • Une fois qu’on a les idées claires, pour savoir combien de temps est-ce que le codage va prendre, il faut au préalable, à l’instar d’un architecte qui veut construire une maison, dessiner les plans de manière rigoureuse et précise; • De même, un analyste va écrire dans des spécifications techniques les plans du logiciel à développer;
  • 6. A quoi servent les spécs. techniques ? • Les spécifications techniques vont permettre, par exemple, de savoir quelle seront les tables à ajouter, quelles colonnes y mettre, comment seront-elles mises en relation; • Entre autre, elles permettent de savoir quelles seront les fonctions, classes et méthodes à écrire ainsi que les procédures nécessaires pour répondre à une fonctionnalité spécifiée dans le spécs. fonctionnelles;
  • 7. Penser au maximum de choses • En réalité, les spécs. techniques servent à beaucoup plus de choses que ça (fichiers à importer, fichiers à exporter, données à indexer etc.) • L’idée est de savoir de manière général et aussi exhaustive que possible : qu’est-ce que nous devons techniquement faire ?
  • 8. Identifier, quantifier, analyser La réalisation d'un tel planning nécessite la mise en œuvre de technique de planification : • les tâches doivent être identifiées; • les tâches doivent être quantifiées en terme de délais, de coûts et de ressources; • la logique de l'ensemble des tâches doit être analysée.
  • 9. Rien n’est parfait • Une fois les spécifications techniques établies, on aura une idée beaucoup plus précise de ce qu’on devra développer et les estimations de planning ne seront que plus justes (mais pas assez justes malheureusement);
  • 10. La réalité des choses…
  • 11. Malgrès tous ces efforts • Le planning d’un développeur comporte en général entre 10% à 20% d’erreur d’estimation; • Le planning du commanditaire (hiérarchie, client...) comporte en général entre 10% et 300% d’erreur d’estimation. • L'expert dans le domaine c'est vous, le développeur, pas votre hierarchie ou votre client. Réflechissez-y un instant : ce n'est pas le client qui fixe des délais pour la construction de sa maison, c'est l'entrepreneur qui les lui donne. Ce n'est pas le patient qui fixe la durée de son traitement, c'est son médecin ou son pharmacien qui la fixe. Ce n'est toujours pas le client qui fixe des délais pour une réponse à un crédit bancaire, c'est le banquier qui les annonce. C'est toujours l'expert qui donne les délais de ses préstations de services, jamais son client. • Tenter de compresser les délais annoncés par le développeur aboutit forcément à un dépassement de délais
  • 12. Le cône d'incertitude • En phase de démarrage, quand on n’a qu’une vague idée de ce qui est demandé, les erreurs d’estimations sont de l’ordre de 300 % • La marge diminue à 100% quand tout le monde se met d’accord sur le produit à développer • 50% quand le cahier des charges est validé • 25% quand on se met d’accord sur l’interface utilisateur. • Les estimations ne deviennent appréciables qu’au moment où les spécifications détaillées sont établies, la marge descend alors à moins de 20% d’erreur.
  • 14. Quand s'engager sur des délais ? • Il est imprudent de s’engager sur une date dès le début du projet car les estimations sont trop larges et peuvent être jusqu’à 4 fois inférieurs au temps réel. • Par exemple, si une estimation est donnée en phase de démarrage à 3 mois, le projet pourrait très bien prendre entre 6 et 12 mois. • On ne peut donc s'engager sur des délais qu'après avoir validé les spécs et les interfaces utilisateurs (taux d’erreur inférieur à 20%).
  • 15. Répartition de l’effort • Bien que, a priori, le codage peut vous sembler la chose la plus importante pour vous, il ne représente même pas 50% du temps total du projet; • Plus vous passerez du temps dans la phase d’analyse, moins vous perdez du temps dans la phase de codage. Si vous le jugez nécessaire, vous pouvez y allouer 30% du temps total du projet; • Quelque soit votre expertise et votre diversification, vous aurez une phase d’apprentissage (nouvelles librairies, nouveaux formats de données, nouveaux systèmes etc.); • Ne négligez pas le recettage et la mise en production de la version final qui peut prendre environ 20% du temps total du projet. 25% 10% 45% 20% Répartition de l'effort Analyse Apprentissage Codage Finalisation
  • 16. Nous sommes des humains, pas des robots • Nous avons une famille, des parents, des enfants. Ces personnes naissent, meurent, se marient, partent en vacances et tombent malades. Un planning qui ne prends pas en compte ces points est par définition irréaliste. • Nous avons un mental, des pressions psychologiques, des fatigues nerveuses et des périodes de manque de sommeil. Ne forcez pas trop fort sur vos ressources humaines pour pouvoir les garder frais et dispos on the long run. • Nous ne sommes pas tous nés égaux en talents, compétences et motivations. Les délais de réalisation dépendent en grande partie du potentiel de votre équipe. Prenez ceci en compte lors de vos évaluations.
  • 17. Adoptez une méthodologie de développement • Peu importe laquelle. Travaillez méthodiquement est toujours meilleur que de travailler sans aucune méthode.
  • 18. Méthodes iteratives • Ce type de méthodologies ne peuvent donner une estimation sur la durée total du projet mais uniquement sur l’itération actuelle. • La durée d’une itération diffère selon les méthodes utilisées (Extreme Programming, RUP, SCRUM). • Par exemple, dans XP, les itérations sont de l’ordre de quelques semaines.
  • 19. Placez l'utilisateur au centre C’est l’utilisateur qui doit mener le processus de développement en : • Confirmant et affinant régulièrement ses besoins ; • Priorisant les fonctionnalités à implémenter. Le chef de projet à aussi le rôle de reprioser les tâches en fonction de l’importance de la fonctionnalité demandée, de l’urgence, des délais demandés par les développeurs, et du retard ou avance pris sur le projet. • validant ce qui a été développé ;
  • 20. Evitez les principales causes de retards (1/3) • Baisse de motivation : plusieurs études ont montré qu’aucun facteur n’était plus déterminant que le manque de motivation de l’équipe (Bohem 1981 cité par Steve McConnell) • Ajouter une personne à un projet déjà en retard : Brooks compare cela à ajouter de l’huile sur le feu. • Expectations irréalistes : il est très difficile de faire vite dans le business du software sans altérer sa qualité ou augmenter son coût.
  • 21. Evitez les principales causes de retards (2/3) • Pas de retour utilisateur : comme dit précédement, l’utilisateur doit être au centre. • Planification insuffisante : si on ne planifie pas comment atteindre rapidement l’objectif, on ne peut s’attendre à l’atteindre rapidement. • Certains projets qui doivent être terminés rapidement essayent de couper court à toute activité non essentielle. L’analyse des besoins, l’architecture et la modélisation sont les cibles favorites puisqu’elles ne produisent pas de code. Cette situation de « sauter directement au code » a des conséquences facilement prédictibles : cette partie du travail qui doit être faite en amont va de toute façon un jour ou l’autre être faite en aval, mais coûtera 10 à 100 fois plus chère (Fagan 1976; Boehm and Papaccio 1988). Si on ne trouve pas les 2 mois pour faire l’étude maintenant, allons- nous trouver les 20 mois nécessaires par la suite ?
  • 22. Evitez les principales causes de retards (3/3) • « Code-like-hell programming » : certaines organisations pensent que pour aller plus vite il faut « coder-comme-un-fou ». Leurs raisonnement est le suivant : avec un bon développeur, n’importe quel obstacle sera contourné. En réalité, c’est simplement du « code-and-fixe » déguisé (code-et-répare) combiné avec des délais ambitieux. Cette combinaison ne marche pratiquement jamais. • Marchander sur les tests : prendre des raccourcis en voulant éliminer ou raccourcir la durée des tests est une pratique courante dans des projets qu’il faut livrer au plus vite. Des études de cas ont montré que lorsqu’un projet atteint sont stade « feature complete », c'est-à-dire ou toutes les fonctionnalités ont été codées, sans avoir passé du temps à écrire et implémenter des tests, il était tellement truffé de bugs qu’il fallait encore 5 mois supplémentaires avant de pouvoir le mettre en production. Ce résultat est typique. Enlever 1 journée d’assurance qualité en amont aura pour conséquence de payer 3 à 10 jours de réparation en aval (Jones 1994).
  • 24. Chosen links Software developement at top speed (Steve McConnell – Code Complete)  http://www.stevemcconnell.com/articles/art04.htm Classic mistakes enumerated (Steve McConnell – Code Complete)  http://www.stevemcconnell.com/rdenum.htm How long would it take if everything went wrong ? (Jeff Atwood – coding horror)  http://www.codinghorror.com/blog/2006/06/how-long-would-it-take-if-everything-went-wrong.html Epopée du développement logiciel  http://ychaouche.wikispot.org/PMHistoireVecue