Les obligations d´un projet :

Voici les règles qui vont conditionner la réussite, la stabilité face aux évènement imprévus et la rapidité de développement d´un projet.

• Existe-t-il une gestion globale de version du projet ?

  Un outil tel que "cvs" ou "subversion", couplé a une sauvegarde journalière avec externalisation de copies régulières (autre lieu que le lieu développement) est indispensable . Un gestionnaire de version, local à chaque développeurs, est un plus.

• Pouvez-vous faire une distribution à partir des sources en une seule commande ?

  Distribution rapide, sans stress, plus de réactivité face aux bogues de dernière minute.

• Effectuez-vous une compilation globale automatique journalière du projet complet ?

  Détection des bogues au plus tôt.

• Avez-vous une base de données de bogues ?

  Seuls les testeurs peuvent décider si un bogue est fixé. Seule une base de données permet une vraie gestion des traces.

• Est-ce-que la priorité est toujours donnée aux bogues ?

  Donner la priorité aux bogues empêche de rajouter du code par dessus (ce qui impliquerait une correction de bogues beaucoup plus longue).

• Avez-vous un calendrier des réalisations à jour ?

  En plus d´aider à une gestion globale, un calendrier fait par les développeurs, avec un découpage des fonctionnalités le plus précis possible, permet au programmeur de limiter les embourbements dans des fonctionnalités auxiliaires, et de se rendre compte qu´il a besoin d´aide.

• Avez-vous un cahier des spécifications à jour ?

  Le cahier des spécifications doit être confirmé au moins une fois par semaine. En effet, spécifier ne coûte pas cher par rapport au développement de code inutile.

• Les programmeurs travaillent-ils au calme ?

  Chaque coupure dans le travail équivaut à une perte de 15 mn au moins, le temps de se remémorer les variables... Quand elle ne provoque pas un oubli, qui induirait plusieurs heures de débogage.

• Avez-vous les meilleurs outils de développement possibles, sans considération de prix ?

  La rapidité de développement est en liaison directe avec les outils, et le salaire d´un programmeur sera toujours plus coûteux qu´un achat de logiciel sur une année.

• Avez-vous des testeurs ?

  Moins chers qu´un développeur, meilleurs pour tester, ils augmenteront significativement la qualité du logiciel et réduiront le temps de développement.

• Pendant les entretiens de recrutement, posez-vous des questions techniques, ou demandezs-vou d´écrire du code ?

  Un seul programmeur qui n´est pas à niveau, et/ou qui n´est pas identifié comme tel, limite obligatoirement une équipe de développement à son niveau à lui : Il faut absolument connaître les niveaux des programmeurs, même approximativement. Sans être un examen inflexible (les erreurs de noms de fonction ou de syntaxe ne sont pas discriminatives), cet examen devra surtout montrer la démarche de développement (phase d´analyse, découpage du problème, code, taille des fonctions, nom de variable, documentation du code, etc.)

• Utilisez-vous la programmation par paire, les tests unitaires ?

  Seule la programmation par paire limite la perte ou l´isolation de la connaissance dans un projet.

  Seuls les tests unitaires peuvent assurer de façon formelle la qualité du code.

Ce que vous devez savoir à propos du développement logiciel

• Les codeurs doivent être les décideurs de leurs stratégies. Vous leur donnez juste vos besoins.
• Les clients ne savent pas ce qu´ils veulent. Ne pas attendre qu´ils le sachent. Ça n´arrivera JAMAIS. Il Faut s´y faire...
• Ne pas jeter de code pour repartir à zéro. Des années de correction de bogues seront perdues, et à refaire. Un code murit, de par les situations qu'il a rencontré et qui n´étaient pas prévu au cahier des charges.
• Si un programme représente le noyau de votre activité d´entreprise, codez-le vous-même, quoiqu´il arrive.
• Si vous commercialisez un outil logiciel, faites un plan sur plusieurs années. Soyez sûr de pouvoir survivre les premières années par d´autres moyens, car les logiciels sont rarement à maturité et parfaitement adaptés dès leur première version. Ne vous attendez pas a un succès phénoménal instantané. Les bons logiciels, comme les bons vin, prennent du temps.

Comment parler, décrire, expliquer aux non-informaticiens, du commercial au client

Une interface utilisateur représente 10% du travail. 90% étant les fonctions "invisibles". En estimant que la correction des bogues représente la moitié du temps de développement d´un logiciel, l´interface utilisateur représente en fait 5%.

Implications :

• Si vous montrez à un non-programmeur un écran une interface inachevée a 90%, il pensera que le programme est inachevée a 90%
• Si vous montrez a un non-programmeur un écran une interface finie a 90%, il pensera que le programme est bientôt prêt.
• Quand la politique demande à ce que des non-techniciens (clients, commerciaux ou managers) décident d´un projet, proposer toujours plusieurs versions du design graphique.
• Lors des démonstration, le point le plus important est ce que vous montrez. Faites des captures d´écrans les plus belles possible. Passez-y du temps, à plusieurs, avec des personnes d´horizon différents.

Comment reconstruire du code

(optimiser ou mettre à jour du vieux code)

• N´ajouter AUCUNE nouvelle fonctionnalité.
• A tout moment, avec tout les tests, le code doit marcher comme avant.
• Tout ce qu´il y a à faire doit être logique et irréfutable, presque mécanique, en aucun cas pour valider une théorie ou pour tester une idée.

Programmation par Paire (Pair programming)

• C´est contre- intuitif, mais 2 personnes travaillant à un ordinateur simple ajouteront autant fonctionnalités que deux fonctionnant séparément, et ajoutera une qualité beaucoup plus conséquente, donc des économies en temps de correction de bogues, donc en coût du projet.
• De plus la programmation par paire limite la perte de connaissance du codage au sein de l´entreprise. Si seulement une personne sur votre équipe peut travailler dans un secteur donné et cette personne part, votre projet sera en danger.
• La formation est une considération importante aux compagnies essayant d´éviter les îlots de la connaissance, qui sont si susceptibles d´être perdus. La programmation par paire fera la formation toute seule.

La meilleure manière d´appareiller le programme est de se poser juste côte à côte devant le moniteur. Une personne dactylographie le code et pense à la méthode étant créée, alors que l´autre pense stratégiquement à l´insertion de la méthode dans le projet et surveille le code généré. Il faut échanger les places dans la paire souvent et changer les paires de programmeurs régulièrement.

Tests Unitaires

• Les tests unitaires doivent être codes avant la fonctionnalité, et doivent être intégrés au code. Ainsi ils aident a spécifier le champ d´application du code et permettent de tester tout le long du développement le code.
• Les Test unitaires permettent aussi une meilleur lecture du code, comprendre le test, c´est comprendre le champ d´application de la fonction. Recoder une fonction avec un test unitaire est beaucoup plus facile, et peux être fait par une personne étrangère a la création du code de la fonction.
• Seuls les tests unitaires permettent d´assurer de façon sure l´intégrité collective du code.

La plus grande résistance à consacrer une quantité de temps aux test unitaires est une date-limite d´approche rapide. Mais pendant la vie d´un projet un essai automatisé peut vous sauver cent fois le coût de le créer en trouvant et en prévenant les bogues. Plus l´essai est dur a écrire, plus que vous avez besoin de lui, car il vous en protégera d´autant. Les tests unitaires automatisés économisent bien plus qu´ils ne coûtent, même pour des petits ou courts projets.

Une autre idée fausse commune est que des essais d´unité peuvent être écrits durant les derniers instants du développement. Malheureusement, sans test unitaire, le développement traîne déborde sur les derniers instants du calendriers. Même si le temps est disponible, les bons tests unitaires sont ceux qui prennent le temps d´évoluer, de murir en découvrant tous les problèmes qui peuvent se produire. Afin d´avoir une suite complète de tests unitaires, il faut les développer le plus tot possible.

(En C, en Java)

Documentation et style de code

• Une convention de nommage des variables, fonctions et types (notation hongroise, convention de casse java, ex : préfixer avec "p" pour indiquer un pointeur. Ou rajouter un "_" devant une donnée membre privée)
• Pour la lisibilité d´un projet, respecter une indentation de façon homogène dans tous les fichiers sources du projet aide a la lecture du code (indent)
• Outil de documentation automatique (doxygen, javadoc)

Conclusion

Cette page essaye de lister des conditions nécessaires mais non-suffisante pour espérer maîtriser votre projet :

Méfiez vous des méthodes , des programmeurs et des gestionnaires qui vous assurent tout maîtriser avec une seule méthode, un seul outil ou grâce a un "génie" du code.

En effet, les choix de conceptions, le marche fluctuant, la bonne interprétation des désirs des clients, l´équipe marketing et commercial, la concurrence et bien d´autres facteurs vont influer sur votre projet...

Mais si votre coeur de business, c´est le logiciel, il faut commencer par être sur de pouvoir maîtriser le développement de code au sein d´un projet.

Merci a Joel, et a l´Extreme Programming