Discussion :

[elitost]

Bonjour,

Je souhaite écrire prochainement un article sur les bonnes pratiques à utiliser lorsque l'on travaille sur un projet informatique (quelque soit la technique utilisée).

Ce serait une sorte de "table des commandements" (ou de conseils) contenant des points essentiels pour réussir un projet.

Pour le moment, j'ai listé seulement ces quelques points :
- Documenter le code
- Gestion des versions / sauvegardes
- Audit du code
- Tests

Au final j'extraierai de vos réactions les thèmes les plus abordés et/ou qui semblent les plus interessants pour produire l'article.

Et pour vous, quelles sont ces bonnes pratiques ? Et pourquoi ?

Merci d'avance,

[mchk0123]

Tu peux rajouter aussi :

- conventions d'écriture (pour améliorer la lisibilité et la maintenance)
perso. j'utilise les conventions GNU (il existe un document bien fait)

- respect de métriques calibrées pour le projet (à une époque j'avais lu un
article de Grady Booch qui était extraordinairement clairvoyant dans le
cadre de la POO)

- conception & modélisation visuelle (UML, ...)

- bug tracking pour les grosses applications et/ou commerciales

- espace collaboratif et de diffusion d'informations (pas que pour le code
source, mais aussi pour la doc, les forums, les news, ...)

... la liste peut être trés longue

[elitost]

- conventions d'écriture (pour améliorer la lisibilité et la maintenance)
perso. j'utilise les conventions GNU (il existe un document bien fait)

Aurais tu le lien vers ce document ?

Sinon, oui la liste peut être longue, le but étant d'extraire les principales bonnes pratiques.

D'autres contributions ?

[mchk0123]

En anglais :

http://www.gnu.org/prep/standards/

Il existe surement une traduction française, ... à trouver sur google :
GNU coding standards (fr : conventions/standards de codage GNU).

[mhamedbj]

pour la modélisation UML faut il la faire a fure et a meusure qu'on avance? une fois fini (avec le reverse engineer)?, avant de commencer a taper du code ??,
pq si on le fesait avant de taper le code et qu'on se rend compte qu'on s'ait planter et qu'il faut revoir une certaine partie du programme(ce qui est frequent!!! ).... il refaire les diagrammes dans ce cas et c'est pénible !!!

[WolffN]

Il ne faut pas négliger la phase d'analyse du projet

il est important d'avoir en début de projet une documentation du but que l'application finale devrait atteindre

elle ne doit pas être précise car cela risque de bloquer le projet dans un carcan (un projet est toujours évolutif dans le temps)

la documentation de début de projet doit contenir une vue globale du processus métier à réaliser (courte description du projet, glossaire de termes technique, schéma illustrant globalement a quoi doit servir le logiciel)

autre point la communication avec le client

avoir si possible une liste de contacts des personnes concernées par le projet pouvant être contactées pour des précisions

prévoir des réunions "régulières" pour justifier de l'avancement des travaux et prendre en compte les nouvelles demandes

(ces réunions permettent également de justifier le planning et la facturation )

[mhamedbj]

les diagrammes précis style diagrammes de classes ça se fait par rétro engineering apres avoir fini le projet !!!! ça me tue a force de les refaire !

[WolffN]

je suis d'accord avec toi mais selon moi il est quand même preferrable d'avoir un diagramme illustrant a quoi doit servir le logiciel

[souviron34]

Moi dans les bonnes pratiques (pour les gros projets) je dirais principalement :

• 1) Avoir une PETITE équipe
  (aucun projet à grosse équipe (> 12 personnes) que j'ai vu n'a marché)
• 2) Avoir une "équipe de direction" à 2 têtes, avec un chef de projet/informaticien et un représentant utilisateur expert, en permanence tout au long du projet. Eventuellement y adjoindre un ergonome tout au long u projet. Sinon en prendre un au départ, en vue de la conception initiale.
• 3) Aucun protocole de "consensus parmi les utilisateurs" pour définir les fonctionalités et leur architecture..
  (le représentant expert des utilisateurs les interroge, normalement avec un ergonome, et c'est LUI qui tranche).
• 4) Avoir une équipe de gens venant d'horizons différents, d'expériences différentes
• 5) Avoir une analyse claire du besoin
• 6) SURTOUT ne pas se soumettre aux normes de documentation et d'architecture d'équipe à la lettre.
  En particulier pas de hiérarchie Chef de projet / Architecte fonctionnel / Architecte système / Analyse programmeur / Programmeur...
  A chaque étape du papier, à chaque étape une retraduction , à chaque étape on perd de l'information 'principe du "téléphone arabe"). De plus, à chaque étape on perd du temps, et le papier ne suit JAMAIS les modifications...
  En particulier il est ABSOLUMENT INUTILE de faire un dossier de maintenance de 500 pages. Personne ne le lira. Un maximum de 5 pages (et encore) sera le maximum qu'une personne chargée de trouver un bug passera avant d'aller fouiller dans le code....
  Même chose pour une doc d'installation (ai dessus d'une page c'est déjà trop, surtout si on s'adresse à des informaticiens)..
• 7) conséquence du 6 : avoir une équipe de gens compétents, mais autonomes, en qui on a confiance, et à qui on délègue l'ensemble conception préliminaire / détaillée / réalisation / documentation.
• 8) Avoir le soutien de sa hiérarchie en cas de problème (dépassement), mais aussi mise en avant de l'équipe par la hiérarche en cas de réussite.
• 9) Mettre des commentaires dans le code
• 10) Coder en pensant que 1) ce sera repris par d'autres, 2) personne n'est irremplaçable, mais aussi 3) quand même chacun est un peu irremplaçable..

Pour le reste, je laisse le soin aux autres, avec ce qu'ils ont dit ci-dessus et diront plus loin..

Mais ceci est basé sur mon expérience de 23 ans, dont 5 très très gros projets industriels (ce qui s'appelle pudiquement "mission critical software")...

[souviron34]

je rajouterais comme point fondamental :

avant tout avoir et garder du bon sens

c'est à dire :

• ne pas choisir une techno et s'y maintenir alors que d'autres permettraient de faire la même chose plus simplement
• ne pas choisir une techno en fonction du "buzz" à la mode
• ne pas utiliser un marteau pour écraser une mouche (exemple prendre OracleTM pour gérer une BD à 4 clés)
• ne pas utiliser tout un tas d'algos sophistiqués alors qu'une simple réflexion peut amener une solution simple (et donc compréhensible et maintenable facilement)
• ne pas continuer à dire "c'est dans la spec on fait comme ça" si on s'aperçoit que la demande/la conjoncture a évolué
• ne pas dire dans une réunion d'avancement "on discute pas de ça mais de la proposition machin truc" alors que le "ça" résout peut-être le problème
• ne pas utiliser une lourde gestion de projet pour une équipe de 5 personnes
• ne pas oublier que ce qu'on veut faire, c'est ce qui est demandé (eh oui, ça a l'air évident, mais dans la plupart des gros projets, au fur et à mesure du temps qui passe, on oublie ça..) pour les utilisateurs auxquels s'est destiné...
• si un utilisateur ne comprend pas un mot, une fonction, etc... c'est qu'il faut réviser sa copie. Ce n'est pas à lui de s'adapter, mais à l'info. de l'aider..
• ........

En bref être souple et avoir du bon sens...

C'est ce que je voulais dire sur l'application des normes, qu'elles soient de gestion ou de programmation.

NOTE : je chercherais dans mes docs pour scanner, j'ai quelques références explicites, y compris dans des compilations de normes.. Mais sans doute quelque part d'ici la semaine prochaine...

[elitost]

...avoir du bon sens...

Ce sera sûrement une des principales bonnes pratiques en effet.

[mchk0123]

Gérer un projet informatique c'est avant tout gérer une équipe (petite ou grande) ; on est donc forcé de prendre en compte le côté humain.

Dans cette tâche un manager de projet expérimenté peut être un plus (par forcément celui qui à tout réussi, mais plutôt celui qui à sut tirer le maximum d'expériences des erreurs passées, qui réagit vite et bien, et surtout, surtout, surtout, celui qui sait faire passer le mieux le meilleur message ...
... et là je parles pas de celui qui fait les présentations techniques powerpoint les plus claires ou qui sait le mieux tirer les oreilles ... il y en à qui comprendrons ...).

[mhamedbj]

si j'ai bien compris il faut préciser ses objectifs dés le début et ne rien changer en cours de chemin ? parce que si c'est le cas ...... c'est vraiment difficile !!!! en plus les modules que les équipes (dans les quelles je suis) sont en train de développer en ce moment... c'est vrai que notre objectif est clair, mais il ya constamment des changements (que ce soit des améliorations dans le code, l'ajout d'autres fonctionnalités, fusion de fonctionnalité.... etc. et un changement dans un module entraîne pas mal de pagaille dans les autres et ça c'est !!!! et la perte de temps je ne vous raconte pas, et je pensais que vous aviez la solution... du moins un moyen de réduire (je vous avoue qu'on est une équipe de 12 personnes (ingénieurs), 4 groupes et on débute c'est notre première expérience professionnelle.

[souviron34]

si j'ai bien compris il faut préciser ses objectifs dés le début et ne rien changer en cours de chemin ?

Euh !!!! Me suis-je si mal exprimé que ça ?? c'est le contraire que j'ai dit (comme je l'ai redis ci-dessus)...

Avant toute chose, du bon sens et de la souplesse.

Ensuite, oui il faut qund même une idée claire et précise de ce qu'on veut faire (rajouter une sous-sous fonctionalité plus tard n'est pas mortel, par contre oublier une fonctionalité principale (et même une sous fonctionalité) au départ peut s'avérer dramatique , au point d'avoir à tout casser et refaire..

Mais au vu de ce que tu dis, vous devriez d'abord (visiblement vous avez déjà commencé à coder, et c'est une grave erreur) lire différentes normes de développement, et vous imprégner de ce qu'on a besoin de faire à chaque étape du cycle normal.

Une fois ça fait, vous pouvez commencer le cycle de développement , avec une analyse et une spécification globale, succinte mais complète.

A partir de là, pour moi, on rentre plutôt dans ce qui maintenant s'appelle "les méthodes agiles", mais que j'ai toujours utilisées et vu utiliser autour de moi (et les cas où c'était pas utilisé ont foiré... ).

Mais sans en savoir plus sur le projet, il me semble d'après la description que tu en fais que vous allez vers l'échec, si vous partez dans tous les sens et que vous n'avez pas les bases du cycle en tête....

Donc le seul conseil en l'état est de dire : arrêtez vous tout de suite. Prenez le temps (une semaine, 2, 1 mois) de bien lire et vous pénétrer des différentes normes de développement (en gros bien sûr) mais du cycle en V en entier...

Et ensuite, surtout ne codez rien......

Réunissez vous si c'est collégial, sinon juste le chef, doit "pondre" une spécification.... c'est à dire au moins l'arborescence ordonnée des fonctionalités et le genre de paramètres/ressources nécessaires à chacune.

[mhamedbj]

merci infiniment !!!!!!!

[elitost]

Merci pour vos contributions, je suis toujours preneur si vous avez d'autres bonnes pratiques à faire partager.

Merci d'avance.

[jpelaho]

Bonjour,
Pour le moment, j'ai listé seulement ces quelques points :
- Documenter le code
- Gestion des versions / sauvegardes
- Audit du code
- Tests

Ceci ne vas s'appliquer qu'au projets ou il y'a des développements. Quand tu dis "Projets informatiques" c'est beaucoup plus général.

MS préconise aussi pour la bonne conduite d'un projet de toujours considérer ces trois principaux facteurs :

- Le nombre de ressources
- Le nombre de fonctionnalités
- La durée du projet

Il faut toujours expliquer au client l'impact que pourrait avoir sur les autres facteurs la modification de l'un de ces trois.

1) Avoir une PETITE équipe
(aucun projet à grosse équipe (> 12 personnes) que j'ai vu n'a marché)

Ce qui est dit plus haut prouve que l'ajout de fonctionnalités peut dans certaines circonstances impliquer un ajout du nombre de ressources.

[elitost]

Merci encore pour ces informations.

[osia1]

Pour bien gérer un projet informatique il faut avant tout une bonne analyse, donc passer par le QQOQCP, l'étude freins-moteurs, la gestion des risques, le brainstorming, et ensuite la modélisation du projet avec MCD-MLD pour les sites web, ou de l'UML pour tout ce qui est application (JAVA, C, C++, ...), la répartition des tâches, création du cahier des charges, création du GANTT ou du PERT (voir les 2). Et une fois que le projet est bien défini on peut enfin passer au codage selon le cahier des charges...
Le code doit être propre, commenté pour une évolution future...
Ne pas oublier que vous êtes avant tout des utilisateurs, donc se placer au niveau utilisateur basique qui ne connait rien à l'informatique pour éviter toutes sortes de bug...

[elitost]

Pour bien gérer un projet informatique il faut avant tout une bonne analyse, donc passer par le QQOQCP, l'étude freins-moteurs, la gestion des risques, le brainstorming, et ensuite la modélisation du projet avec MCD-MLD pour les sites web, ou de l'UML pour tout ce qui est application (JAVA, C, C++, ...), la répartition des tâches, création du cahier des charges, création du GANTT ou du PERT (voir les 2). Et une fois que le projet est bien défini on peut enfin passer au codage selon le cahier des charges...
Le code doit être propre, commenté pour une évolution future...
Ne pas oublier que vous êtes avant tout des utilisateurs, donc se placer au niveau utilisateur basique qui ne connait rien à l'informatique pour éviter toutes sortes de bug...

Es tu bien sûr de coder à partir du CDC ? et non à partir des spécifications ?