Discussion :

[_vince_]

En faite, ça été découvert ainsi par le principal utilisateur. La phrase dit "Mais ! nous ne travaillons pas comme ça ". C'est tout les fonctionnels qui à été revus. C'est lié à un petit détails qui à tout changé.

J'ai eu un peu le meme genre de situation en phase d'acceptation/recette.
On s'est apercu que le logiciel etait utilise differemment "en operations" que pendant la recette et l'execution des tests fonctionnels.

Pour donner un exemple simplifie, le logiciel devait utiliser un fichier d'entree. L'operationnel lui en fournissait deux. Evidemment, le logiciel utilisait le premier fichier mais pas le deuxieme.
Les specs ne precisant pas un nombre maximal de fichiers d'entree, ce fut un bug pour les developpeurs. C'est un exemple de ce qui pourrait entrer dans la zone d'ombre, ou specs implicites.

[_vince_]

Aussi une chose très important prévoir un budget de refonte de code avant toutes évolution pour éviter que le code se dégrade en qualité.

Une fois le logiciel livre, si le code fonctionne comme l'utilisateur l'a demande, le logiciel est considere correct. Quel est l'interet du fournisseur du logiciel d'ameliorer la qualite du code qui ne se voit pas de l'exterieur? C'est une perte de profit. Le seul a voir la difference sera celui en charge de la maintenance du code. Mais qu'importe tant qu'il souffre en silence...

Blague a part je suis d'accord avec toi. Une fois en phase de maintenance, la qualite du logiciel/code doit s'ameliorer sinon on finit avec un code non maintenable suite aux multiples correctifs/palliatifs.

[jbarre]

bon on parle beaucoup coe mais pour avoir bossé sur de gros projets de changement de SI dans la grande distirb.

ne pas oublier la plannification... ca parait bete mais ca oblige a evaluer les charges , cadrer le projet

un comite de pilotage -> pour trancher les grandes decisions, faire une synthese de l'avancement

la conduite du changement -> tu peux te faire plaisir avec un super soft, si tu n as pas pensé ç le vendre , a construire le plan de formation c est mort

penser à la phase de delpoiement -> packager le deploiement, industrialiser les scenariis de demarrage ...

NE PAS OUBLIER LE SUPPRT; quand t as fii ton projet tu parts sur un autres et c est le service support voir la future TMA en N2 qui prennet tout dans les dents et se retrouvent à poil

comme cela ete dit ne pas s'appuyer sur la hierarchie mais nommer des chefs de chantier sur les gros projets ca peu etre sympas...

je pense que sur ce forum il y a assez d'experts technique, ce petit poste pour ne pas negliger l'aspect organisationnel qui est aussi important pour le bon deroulement de ton projet

voilou

[jbarre]

vi et j ai oublie , des livrables intermediaires validés par tout les acteurs tel que :

le cahier de concpetion generale
le cahier des charges,
les PV de recette

ca parait con, mais c est ultra important, surtout le jour vers la fin du projet ou l'utilisateur vient te dire bah j avais pas demandé excatement ca et la tu lui sorts son cahier qu'il a signé et lui explique gentillement que ce qui te demande est une evolution pas un bug donc une rallonge pour le faire en terme de budget, delai.....

[Fallen_Leaf]

La communication ?

Pour moi :

- Interne à l'équipe projet : Points réguliers et rapides de qui a fait quoi, qui fait quoi, qui fera quoi + exposé des problèmes (éventuels, mais il y en a toujours) de chacun ...

- Communiquer vers les VIP & utilisateurs "échantillons" du projet ... Comm. régulière, mais synthétique (métaphoriser, c'est l'pied).

- Informer les utilisateurs finaux (pas seulement ceux impliqués sur le projet) sur les grands jalons de l'avancée du projet. Comm. espacée mais régulière.

- Minuter toutes les réunions, rapidement, les faire tourner aux participants et les faire valider à la réunion suivante

Et je plussoie vigoureusement sur le périmètre. C'est la partie la plus importante AMHA ... et qui rejoins le point sur la communication. Le Cdp doit faire du périmètre du projet sa table de commandements, la rabâcher dès qu'il le peut, et la faire tatouer sur tous les intervenants du projet.
"Tu sors du périmètre : tu iras en enfer."

[nicorama]

Je travaille pour mon compte, donc je n'ai pas vraiment de Clients aux normes SSII (ceux qui seront contents achètent, pas les autres).
Je suis quand même un peu dègu de n'avoir quasiment aucune des 12 propositions dans mon projet.

Après est-ce nécessaire de faire un seul build en même temps ? Pas si sûr.

[Kognos]

Je suis consultant en informatique et j'ai de participer à nombreux projets, dans de nombreux environnements aux files des années. Selon mon expérience je séparais en trois principes de base pour que ça marche, bien loin des méthodes de travails (agile ou structuré) ou d'ajouter des commentaires...

Premier principe, la méthode KISS

KISS pour Keep It Simple and Stupide (Garde ça simple et stupide). Ça se passe d'explication, un petit truc pour garder le tout simple, découpe le projet en mini-projets.

Second principe, être de bonne volonté et être entouré de gens de bonne volonté.

Rien pire quand apparaît les sentiments de d'envies, territorialités, de dominance, défaitistes... ou des comportements comme le manque de respects, de prima donna, d'améniosité...

Ces comportements apparaissent souvent avec le facteur de stress, le seul truc que j'ai est de trouvé un chef de projets qui s'occupent de gérer le niveau de stress, pas trop élevé et pas trop bas... ils sont des denrées rares.

Troisième et dernier principe, savoir le pourquoi, quoi et comment.

Réponde à ces trois questions dans l’ordre.

Pourquoi? (Bref le besoin)
Quoi?
Comment? (Ici on parle de la technique, du choix du langage, de l'équipe...)

J'ai vu trop souvent, des analystes en besoins d'affaires demander à l'usager ce qu'il voulait et celui-ci répondre un truc comme je veux un Intranet. Sans jamais poser la question mais pourquoi veux-tu un Intranet? Certains plus vite que les autres posaient la question, c'est quoi qui va avoir dedans?

Regarder toute nos actions humaines est toujours fait en fonction de ces 3 questions, de façon inconsciente mais tout de même.

Exemple :

J'ai eu une grosse journée, j'ai besoin d'un peu de réconfort. (Le pourquoi)

Je fais quoi, j'appelle Jean-Marc pour aller prendre un verre, je vais au cinoche ça me fait toujours du bien, je m'achète du chocolat, je demande à mon conjoint de me faire un petit massage... hum... j'appelle Jean-Marc on va aller prendre un verre et regarder le match. (Le quoi)

J'appelle comment Jean-Marc, je lui envoie un sms, un courriel, j'utilise mon téléphone de maison, mon cellulaire, mon téléphone de travail.... et j'y vais comment prendre un verre, en metro, à pied, en voiture .... (Le comment)

Il est vrai que les méthodes ça a du bon, d'avoir un logiciel de contrôle de source ou d'avoir du code lisible mais bon...

Kognos

[JeromeBcx]

Des phases de développement les plus courtes possible.
Cela permet de dynamiser le développement, l'équipe et éviter les dérives.
En effet, si tu dis à un développeur :
"Fais moi cette fonctionnalité délais : 6 mois" Tu es sùr que dans 10mois, il n'y toujours rien de sorti.

Des objectifs clairs, abordables, court dans le temps, que l'on peut faire valider par exemple par le client.
Par exemple, pour une IHM, construire l'IHM sans la couche métier, faire jouer le client avec, vérifier l'ergo, ... puis après ajouter les couches métiers

[CinePhil]

Très intéressant tout ça...

De mes 5 années de cours du soir CNAM, j'ai retenu quelques trucs sur lesquels j'aimerais avoir votre avis. Je numérote ci-dessous mais c'est pas forcément dans l'ordre ; c'est juste pour repérer.

1) Cas normaux et cas limites
Pour éviter de laisser des bugs dûs à des situations non prévues par le programme, préparer des fiches pour chaque fonction et/ou module de programme décrivant :
- les cas normaux d'utilisation - Saisie d'une valeur entière comprise entre 1 et 100 ==> Il se passe X et le résultat retourné est Y
- les cas limites - Comment doit réagir le programme si on est aux bornes de l'intervalle prévu ?
- les cas hors périmètre - valeurs hors bornes, saisie d'un texte à la place d'un nombre, clic sur un lien en cours d'opération, arrêt inopiné du programme... Comment réagit le programme et/ou le système auquel il appartient dans son ensemble ?

2) Scénarios
Si possible pour chaque fonction du logiciel, écrire un scénario avec des étapes numérotées de ce qui se passe vu de l'utilisateur. Ca permet de préparer les tests pour vérifier que les scénarios sont respectés.
On nous avait demandé de faire ça dans le cahier des charges fonctionnel pour l'UE de projet.

3) Merise
Non, ce n'est pas dédié aux bases de données. Merise est une méthode complète pour la conception et le développement d'un système d'information. C'est une démarche par étapes avec des outils et des validations.
Il n'est même pas interdit de se servir des diagrammes UML en appliquant la méthode Merise.
Il y a sans doute d'autres méthodes (UML n'est pas une méthode mais un ensemble de diagrammes) mais c'est c'est qui nous a été présentée le plus en détail.


Ceci dit, je n'ai encore jamais participé à un projet informatique en équipe. Même dans le cadre de mon stage, l'application existante tourne et continue de recevoir quelques modifications pendant que j'en fais la rétro-ingénierie et une reconception plus normalisée. J'ai toujours développé tout seul des applications non critiques et relativement modestes.

Par contre, je souhaite ajouter ce que j'ai retenu de ma maigre expérience :
1) Concevoir avant de développer
A chaque fois que je me suis jeté dans un développement sans faire un minimum de conception préalable sur le papier, j'ai dû reprendre le truc pratiquement de zéro quelques temps plus tard. Que celui qui n'a jamais fait ça me jette la première pierre.

2) Commenter et documenter
Vous faites un petit schéma au brouillon pour décrire votre machin ? Gardez-le ! Quand vous voudrez compléter le machin dans un an, vous serez bien content de pouvoir vous remettre en mémoire en quelques minutes comment vous l'avez conçu.
Commentez votre code ! Quelle perte de temps à comprendre comment fonctionne ce foutu machin que vous avez développé il y a un an et qu'on vous demande de modifier d'urgence !

3) Tracez les versions
Indiquez toujours la version dans votre code. Y insérer aussi en commentaire l'historique des modifications est une bonne pratique. Vous pourrez plus facilement comprendre ce qui a changé, pourquoi ça a changé... et peut-être pourquoi vous venez de tomber sur un cas qui a tout fait planter !

[el_slapper]

Très d'accord avec Cinéphil - juste pour préciser qu'il faut une méthode; que ce soit Merise ou autre, ou même un truc interne, tant qu'il y a une méthode, on est sur les bons rails.

Et le diable se situe ne général aux cas limites et hors-limites.....

[_vince_]

Et le diable se situe ne général aux cas limites et hors-limites.....

Les cas ou on se dit: Ca n'arrivera jamais !

[jmmolina]

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.

Il ne faut pas confondre les méthodes de développement et des langages de modélisation comme UML. Par exemple les diagrammes UML sont largement utilisés par la méthode Processus Unifié : classes, états… Je ne vois pas trop ce qu'on peut faire de ces diagrammes sans méthode. Par contre on peut parfaitement suivre une méthode et développer sans se reposer sur UML. Ce dernier ne reste qu'un des nombreux outils qui permet de mener le projet à bien : Analyse des besoins, cas d'utilisation/étude ergonomique, tests (xUnit de la méthode eXtreme Programming)…

Pour moi UML est avant tout un formidable outil de communication. Il colle parfaitement à l'expression qu'une image vaut mieux qu'un long discours.

[jmmolina]

Moi du coté analyse avant de coder le projet, le pense que la réalisation de diagrammes des cas d'utilisation (en passant par la rédaction des scénarios qui seront effectués par le produit final).

Ça permet déjà de dégager une idée globale de ce que doit faire le produit fini,
de présenter sa propre réflexion/réflexion du groupe de travail aux différentes personnes à l'origine de la demande.

Analyse, cas d'utilisation… toutes ces étapes font partie de la méthode Processus Unifié que je recommande vivement, un livre très intéressant a été publié aux éditions Eyrolles.

Sinon une "bonne pratique" c'est de centrer son développement autour des besoins de l'utilisateur final. ça permet d'orienter les spécifications et définir un cahier des charges cohérent, et non pas dont les exigences sont définis selon le bon vouloir des développeurs.

La méthode d'extrême programming (quand c'est possible) permet également de bien gérer le déroulement du projet.

Extreme_programming

Les tests unitaires, le développement par pair… voir aussi du côté du Test Driven Development (TDD) de Kent Beck. Le prototypage rapide donne aussi de bons résultats pour les petits projets, pour le Web notamment, puis faut admettre que c'est assez fun à suivre.

Une bonne pratique serait d'ailleurs peut-être de mettre le plaisir au premier plan. Parfois un développement trop rigide et une méthode à suivre à la baguette peut briser le moral d'une équipe pourtant très motivée au départ. Quand des petits nuages gris apparaissent à l'horizon c'est que le projet commence à virer à la tempête et c'est jamais bon. Piocher à droite et à gauche pour prendre le meilleur des méthodes citées peut alors redonner un peu de couleurs…

[souviron34]

3) Tracez les versions
Indiquez toujours la version dans votre code. Y insérer aussi en commentaire l'historique des modifications est une bonne pratique. Vous pourrez plus facilement comprendre ce qui a changé, pourquoi ça a changé... et peut-être pourquoi vous venez de tomber sur un cas qui a tout fait planter !

Absolument. très bonne ligne de conduite. (même si on vous dit que l'outil de gestion de configuration le fait).

a) on peut changer d'outil
b) Souvent l'extraction auto des commentaires sert de "framework" à une certaine doc.
c) Il est plus facile de suivre une version relative d'une partie de code (version 1, version 2, etc etc) que la version globale (version 3.2.1.4.R.4.2.1.2.3)

Et le diable se situe ne général aux cas limites et hors-limites.....

+1

Pour moi UML est avant tout un formidable outil de communication. Il colle parfaitement à l'expression qu'une image vaut mieux qu'un long discours.

Il colle surtout parfaitement à une démarche administrative et marketing et commerciale (mais je suis biaisé ).

[jmmolina]

Premier principe, la méthode KISS

KISS pour Keep It Simple and Stupide (Garde ça simple et stupide). Ça se passe d'explication, un petit truc pour garder le tout simple, découpe le projet en mini-projets.

À lire, le Discours de la méthode de Descartes. Il parle notamment du découpage d'un problème complexe en problèmes plus simples à résoudre. Ce concept de macro et de micro peut d'ailleurs être appliquée à tous les domaines : Gestion de projet, mathématiques... ou tout simplement au quotidien pour rejoindre la méthode KISS

Troisième et dernier principe, savoir le pourquoi, quoi et comment.

Réponde à ces trois questions dans l’ordre.

Pourquoi? (Bref le besoin)
Quoi?
Comment? (Ici on parle de la technique, du choix du langage, de l'équipe...)

J'ai vu trop souvent, des analystes en besoins d'affaires demander à l'usager ce qu'il voulait et celui-ci répondre un truc comme je veux un Intranet. Sans jamais poser la question mais pourquoi veux-tu un Intranet? Certains plus vite que les autres posaient la question, c'est quoi qui va avoir dedans?

Regarder toute nos actions humaines est toujours fait en fonction de ces 3 questions, de façon inconsciente mais tout de même.

Il manque encore beaucoup de questions auxquelles il est pourtant impératif de répondre. Qu'en est-il du quand par exemple ? Voir la méthode QQOQCCP dont quelqu'un a parlé précédemment.

[souviron34]

... ou tout simplement au quotidien pour rejoindre la méthode KISS

Oui sauf que comme l'a dit je ne sais plus qui, "le bon sens est la chose du monde la moins partagée"..

Ce que je vois tous les jours depuis de nombreuses années...

C'est pour ça que c'est "Simply Stupide".

Le nombre de gens qui suivent "pourquoi faire simple quand on peut compliqué" est effarant !!!!

Donc oui, résolument, à fond , tout le temps KISS.....

Voir la méthode QQOQCCP dont quelqu'un a parlé précédemment.

Contradictoire avec le précédent : est-ce KISS d'avoir quelque chose qui s'appelle QQOQCCP ???????????????????????????

[jmmolina]

Des phases de développement les plus courtes possible.
Cela permet de dynamiser le développement, l'équipe et éviter les dérives.
[…]

Des objectifs clairs, abordables, court dans le temps, que l'on peut faire valider par exemple par le client.

En effet, fixer des objectifs réalistes permet de motiver son équipe. Le découpage du travail permet aussi de mieux tenir les délais et de ne pas dépasser le budget.

Par exemple, pour une IHM, construire l'IHM sans la couche métier, faire jouer le client avec, vérifier l'ergo, ... puis après ajouter les couches métiers

On parle de prototyper l'application. Il me semble que PHP a une assez bonne réputation dans ce domaine car il reste suffisamment simple et accessible, comme bon nombre de langages scripts d'ailleurs (Python, Ruby...). Le prototypage a aussi ce redoudable avantage d'être vraiment fun, quand on a une idée en tête il ne faut pas attendre longtemps pour la réaliser. Certes l'utilisateur se retrouve devant une coquille vide mais au moins le feedback est immédiat.

Fun Driven Development™ (FDD)

[joseph_p]

Et ne pas oublier cette phrase d'un de mes meilleurs profs de l'époque :
"Un modèle simple est faux, un modèle compliqué est inutilisable."

Phrase un peu choc disant que quand c'est simple c'est généralement au moins incomplet et donc faux.

De même à trop vouloir en mettre cela devient incompréhensible. Il y a donc un compromis à trouver (ou :"pourquoi modéliser n'est pas simple").

lol

De plus, et là je dirai surtout ça pour les différents décideurs : "choisir c'est renoncer !"

-> ça vaut tant pour les utilisateurs (qui ont tendance à demander la lune le le beurre, le tout gratuit et pour hier) que pour les chefs qui prioritisent tout en voulant que tout soit fait.

Sur ce 2eme point je dirai qu'il est super important de lotir (ou définir le périmètre des évolutions) une application. Ca permet d'avoir un résultat sans dire non à tout mais "ce sera un 2eme lot".

[Elverion]

Quelque chose que je considère comme vitale pour les projets que je fait, est de ne SURTOUT PAS se contenter de répondre simplement au besoin comme il est si simple de faire : il faut préparer le programme à son évolution.

Il y a pas mal de livre sur le fait de bien ecrire un code facilement reprennable et repiquable, je posterai les noms une fois que je les aurait récupérés.

Pour reprendre ce qui à été dit, je suis d'accord avec : "Un modèle simple est faux, un modèle compliqué est inutilisable.".

Pour moi, le modèle d'un projet n'est jamais achevé, il est sans cesse en évolution. La phase de conception est incontournable et le but principale n'est pas de pouvoir rendre notre code compréhensible aux autres. Le premier but d'une conception est d'avoir soi-même une idée claire de ce à quoi il faut répondre et ce que ce implique.

Voila en ce qui me concerne

[mogwai162]

Bonjour.

Il y a des choses très interessantes dans tout ce qui a été dit plus haut. Cependant d'autres dépendent tellement de l'e,vironnement de travail qu'il est impossible d'y influer, comme par exemple du calme pour les programmeurs ou l'appui de sa hiérarchie : ce sont des voeux pieux.

Moi ce que je fais :

Grosses discussions avec les uitilisateurs qui m'expriment leurs besoins.
A partir de ça je leur fais une proposition. Les deux parties s'engagent sur cette propopsition : l'utilisateur en l'acceptant et moi en la respectant.

faire des maquettes : parfois un dessin sur un bout de papier libre peut etre suffisant a l'utilisateur pour comprendre ce que vous luis proposez.

Votre analyse du problème doit etre claire et les besoins de l'utilisateurs ne doivent pas changer tous les deux minutes d'ou importance de la définition de besoins.

La relation avec l'utilisateur doit se faire sur de bonnes bases : ils ne doivent pas avoir l'impression que vous cherchez à en faire le moins possible mais que vous voulez leur batir le programme dont ils ont besoin.

Votre analyse et votre programmation doivent etre rigoureuses : le respect des lois normales et une programmation claire, (comme ne pas empiler les if et almigner le code), commentée mais pas trop (inutile d'ecrire que vous affichez un message d'erreur si la valeur est nulle : ça se voit en lisant le test), n'est pas un luxe.

Souvenez vous d'une chose : il est simple d'ecrire un programme, il sera beaucoup plus difficile de le modifier six mois plus tard si il est ecrit n'importe comment. J'en ai même vu impossibles à modifier parce que totalement incompréhesibles meme en sachant ce qu'ils faisaient.

Et enfin, vous avez besoin de testeurs parce que le pire des testeurs c'est celui qui a ecrit le programme.

Au sujet de la compexité de la chose il faut que vous tranchiez, ou que lze chef de porojet ait les billes pour le faire : il ne faut pas accepter tout sous pretexte que ça servira un jour ou qu'une évolution pourrait se produire : c'est le l'utopie.

La moitié des evolutions que je prévois dans mes programmes ne se produit pas. La moitié des evolutions qui se produisent n'ont pas été prévues.