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 )

[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 ?

[el_slapper]

je dirais que peu importe la méthode, pour peu qu'on en aie une. UML est une méthode très efficace, pour peu qu'elle soit appliquée par des bons. Mais avec une méthode "faite maison", ils peuvent aussi avoir un bon résultat. La seule différence, c'est qu'une méthode standard comme UML est compréhensible plus facilement en dehors du projet - d'ou son succès. Par rapport à une bonne méthode maison, UML n'apprte rien - si ce n'est cette ouverture au monde extérieur. C'est suffisant à mon sens. Mais il faut des gens capables, de toutes façons.

et je suis d'accord pour "qui ne connait rien à l'informatique", voire qui s'en méfie, ou cherche à la planter parceque c'est son ennemi. un bon plan test commence par : "on cherche la faille", "cas non passants", et se termine par "cas exotiques pas prévus dans les specs".....(plus de la moitié des anomalies levées sur le dernier projet ou j'ai fait de l'homologation étaient hors-specs, ou implicites).

[osia1]

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

Il faut absolument respecter le cahier des charges, mais je ne comprends pas trop ce que tu veux dire "à partir des spécifications"...

[abdeslem]

Bonjour,
je sais que le poste est assez ancien, mais j'ai un peu cherché sur le forum, je n'ai pas trouvé un poste qui traite des "projets de développement web" (et je n'arrive a créer un nouveau poste .... je ne sais pourquoi!!! ).

en réalité, un "Projet web", n'est qu'un héritage de "projet de développement software"............ héritage oui, mais avec des surcharge de spécificités si vous voyez ce que je veux dire......

Ma question est plus spécifique, quel serait les "best practice" dans les projets de développement web (e équipe)??? les meilleurs outils??

[adrienfehr]

Salut où en es-tu de ton article, où peut-on le consulter ?

[B.AF]

C'est dingue qu'en 2009 on puisse encore se demander comment réussir un projet informatique...

Ok, je sors....

[lysiandad]

C'est dingue qu'en 2009 on puisse encore se demander comment réussir un projet informatique...

... encore plus "drôle" (ou est ce "plus triste" ?), j'ai souvent remarqué que certains CdP (voire DI... voire DSI...) sont encore plus "prudents" (ou devrait on dire "plus mal à l'aise" ?) et se posent (...nous posent) la question plutôt par l'autre "bout" :

"... comment faire pour ... ne pas échouer" (sic)

( *ahem* )

[B.AF]

Ah oui; comme j'ai dit à un client; je ne peux pas passer 90% de mon temps à développer des solutions dont le seul but est de s'assurer que l'utilisateur qui ne fait jamais d'effort pour apprendre à s'en servir fera le minimum de conneries avec.

J'exagére un peu, mais finalement, je crois que c'est ce qu'on a fini par appeller la couche métier dans les applications.

[Mister Nono]

C'est dingue qu'en 2009 on puisse encore se demander comment réussir un projet informatique...

Ok, je sors....

Ce n'est pas parce que tu sais : que tous les internautes savent.

En ce qui me concerne, j'ai plusieurs années d'expériences en gestion de projets informatiques et j'en apprends tous les jours.

La formation en continue est fortement conseillée pour garder un haut niveau de compétences.

Poser une question ne signifie pas que l'on ne sait pas.

A+

[B.AF]

oui..Enfin il était mauvais soit...Mais c'était de l'humour....

Moi je suis le pire exemple, je suis un fervent admirateur de l'agile manifesto.

En gros, peu m'importe la méthode, pourvu :
Que les clients soient heureux
Que le résultat s'inscrive à la livraison et dans le temps
Que je gagne plus d'argent à le vendre qu'à le faire

Là, j'suis super heureux !

[B.AF]

En fait à titre d'expérience personnelle une m'a marqué particuliérement.

J'étais chef de produit. Donc, toutes les semaines revue des dev en cours avec le chef de projet.

On avait un grand problème de fonds :
Il gérait pourtant super bien son planning, ses ressources, et donc il était toujours "full de chez full".

Après avoir retourné le problème dans tous les sens, la solution était que :

Il ne comprenait rien aux sujets, donc s'enfermait dans une prise de garantie couteuse (les 15 docs préalables à produire)

Par voie de conséquence, les clients trouvaient que les développements étaient trop chers, et que surtout, c'était lassant qu'on leur fasse valider 15 fois leurs demandes, et qu'après tout, en nous choisissant on leur avait vendu une expertise.

En terme de management, les développeurs gonflaient les charges, puisque le chef de projet n'était pas capable de vérifier la cohérence des charges annonceés. D'autant qu'il n'avait aucune compêtence technique forte.

Comme il ne comprenait pas les sujets, il ne pouvait pas faire de mutualisation (ou alors il fallait repartir dans les 15 documents, faire 12 réunions avec tous les clients ndlr : va foutre 45 DG autour d'une table le même jour à la même heure sur un sujet qui traine depuis 3 mois...)

Comme il s'intéressait autant à la réalité du marché (c-à-d que pour gagner un peu d'argent, il faut choisir les sujets d'actualité sur lesquels les clients ont un besoin à court terme et donc ne ferons pas de corrélation entre les jours et le prix) qu'a son premier doudou, aucun client ne voulait le voir.

En revanche, nous disposions d'une qualité de reporting indéniable :
Project plan
rétro planning
Consommation de charges

La conclusion c'est que dans l'empirique, les méthodes étaient respectées, dans la réalité, c'était un calvaire (et hop 20 jours pour faire une extraction format csv...) tant pour les clients que pour la boite (bonjour la réalisation de chiffre).

Cependant, passé le cap de la forme ; les analyses, je devais toute les relire voir les refaire, les points clefs (possibilité de distribuer le développement, etc,etc...) ce n'était même pas la peine ("J'ai fait le livrable spécifié")...

Bref depuis, une règle d'or :
Je bosse avec des gens qui aiment comprendre pourquoi il développe
Je bosse avec des gens qui ont envie d'entendre les commentaires du client
Je bosse avec des gens qui considére la méthode comme elle est, c'est à dire un outil et pas une finalité.

Voilà pour ma petit mauvaise expérience.