Le développement logicielexpliqué à votre patron

Yassine ChaoucheDécembre 2012yacinechaouche@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 linksSoftware 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