WizBlog

Ma boîte s'est tournée vers la "qualité" de la documentation. On est passé en deux ans, d'une équipe de développement de 4 personnes sans planning et avec des documentations purement archi-techniques pour techos et jamais à jour, à une équipe de 12 personnes avec un planning, des sous-traitants, des évolutions sur le seul projet de la boîte à 800JH. Et bien sans documentation viable... c'est dur ... Maintenant la documentation que l'on n'a pas réalisé depuis 10 ans se paye cher !

Donc, maintenant, j'ai la réflexion suivante. Si vous voulez un gros projet viable sur le long terme sans craindre qu'une personne critique de l'équipe ne s'en aille, investissez dans la documentation !

1. Écrire l'expression des besoins d'un programme c'est long
2. Écrire la documentation fonctionnelle c'est long
3. Écrire la documentation technique c'est long
4. Développer les tests unitaires des fonctionnalités c'est long
5. Développer des fonctionnalités c'est long
6. Écrire la recette d'un programme c'est long
7. Réaliser la recette d'un programme c'est long
8. Écrire la documentation utilisateur d'un programme c'est long
9. Corriger les bugs d'un programme c'est long
10. Faire évoluer un programme c'est long

Et surtout

1. Planifier la réalisation d'un programme c'est long
2. Encadrer les personnes qui réalisent un programme c'est long
3. Vérifier toutes les étapes d'un programme c'est long
4. Se mettre d'accord sur un programme c'est long
5. Communiquer au sein de l'équipe qui travaille sur le programme c'est long

Conclusion : réaliser un projet informatique est long et donc cher