| Respecter | Savoir | Communiquer | Reconstruire | Partager | Assurer | Documenter |
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.
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.
Distribution rapide, sans stress, plus de réactivité face aux bogues de dernière minute.
Détection des bogues au plus tôt.
Seuls les testeurs peuvent décider si un bogue est fixé. Seule une base de données permet une vraie gestion des traces.
Donner la priorité aux bogues empêche de rajouter du code par dessus (ce qui impliquerait une correction de bogues beaucoup plus longue).
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.
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.
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.
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.
Moins chers qu'un développeur, meilleurs pour tester, ils augmenteront significativement la qualité du logiciel et réduiront le temps de développement.
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.)
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.
Une interface utilisateur représente 10% du travail. 90% étant les fonctions "invisibles". En estimant que la correction des bogues représente la moite du temps de développement d'un logiciel, l'interface utilisateur représente en fait 5%.
Implications :
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.
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 coutent, 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 : http://cutest.sourceforge.net/, En Java : http://www.junit.org/index.htm)
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