Discussion :

[skerdreux]

Bonjour,

Je travaille dans une petite SSII ou je suis le seul développeur face à 2 chefs de projets (voir 3 si on compte le Directeur technique).
Bref comme toute petite SSII qui se respecte les projets ne sont, en général, pas très gros et il y a souvent très peu d'analyse avant de commencer à programmer.
En général je me retrouve avec un power point expliquant ce que le client veut (donc 4-5 phrases par diapo sans vraiment de détail) et je dois donc coder à partir de ça (quand à discuter avec le client c'est galère...).
Mais force est de constater que cette méthode n'est pas vraiment géniale puisque je fonce à chaque fois droit dans le mur et les problèmes s'accumulent et je dépasse totalement les délais.

Je voudrais donc utiliser des méthodes/conseils pour éviter de faire un massacre continuellement.
Bien sur je ne dispose pas non plus d'un temps énorme pour faire ce qui m'est demandé et reprendre donc une analyse complète est impossible. Par contre en faire une partie est possible mais qu'est ce qui est le plus important à faire ?

je sais que la question est assez vaste mais des idées adaptés à la taille de notre structure serait vraiment génial !

merci d'avance !

[wiztricks]

Salut,

C'est pas une question de méthode, mais plutôt de tactiques de survie.

Regardez le passé:

• Est-ce que vos développements sont n'importe quoi ou y-a-il des points communs qui méritent de réutiliser quelque chose?
• Mieux pouvez vous dégager une architecture de cela et des variations autour?
• Est ce que vous êtes capable d'identifier à postériori les parties risquées de votre réalisation?

Pour le futur, on verra plus tard.
- W

[skerdreux]

les développements sont un peu n'importe quoi. disons que ça touche un peu à tout niveau language (C#, VB, actionscript) tout en restant sur les SIG (donc au final assez spécifique dans la thématique). Bref je ne réutilise pratiquement pas ce que j'ai déjà fait (même si je commence à tenter de faire des trucs génériques).
Pour l'architecture c'est pareil on peut pas dégager de choses spécifiques. ça reste un grand désordre.
Les parties risqués ça j'arrive un peu près à les voir.

[Straahd]

Concernant le temps, c'est un faux problème, je pense qu'il est toujours plus rapide, de passer du temps sur ce que l'on doit faire, poser les bonnes questions (cela vient avec l'expérience). Il est important d'identifier les utilisateurs clé et surtout de prévoir à l'avance des réunions fréquentes (quelques unes en présentielles et fréquentes au téléphone)

Très souvent les utilisateur finaux n'étant pas informaticiens ils veulent des applications irréalisable dans la vrai vie, et juste en discutant et en posant des questions, il comprenne que cela ne peut pas fonctionner et ils modifient leur demande.

Passer par des prototypes est aussi intéressant car les utilisateur aime voir quelque chose et pourvoir commenter dessus.

Pour finir comme l'a dit wiztricks il est important de pouvoir capitaliser sur les développements précédent, car finalement en tant que développeur ont passe notre temps à faire la même chose, et je suis persuadé que sur le code que l'on développe seulement 20 % est spécifique.

[wiztricks]

les développements sont un peu n'importe quoi. disons que ça touche un peu à tout niveau language (C#, VB, actionscript) tout en restant sur les SIG (donc au final assez spécifique dans la thématique). Bref je ne réutilise pratiquement pas ce que j'ai déjà fait (même si je commence à tenter de faire des trucs génériques).
Pour l'architecture c'est pareil on peut pas dégager de choses spécifiques. ça reste un grand désordre.
Les parties risqués ça j'arrive un peu près à les voir.

Je suppose que SIG est pour système d'information géographique.

La difficulté que je ressens est qu'ayant trop le nez dans le guidon, vous manquez de recul pour pressentir l'ordre qui se dégage de ce désordre.
Il faudrait que vous puissiez descendre du vélo pour vous regarder pédaler...

Vous ne pourrez consacrer que quelques heures par semaine à réfléchir à comment améliorer les choses et essayer de progresser sur certains aspects.

C'est une démarche "hasardeuse" au sens où elle se construira "sur mesure" avec vous, les chefs de projets, ... en fonction de vos possibilités, des opportunités,... qu'il faudra identifier.
S'il y a des résultats, ce sera sur la durée et cela peut être décourageant.

Vos ennemis sont les fausses bonnes idées, l'impatience et le manque de focus.

Vous avez deux sortes de solutions:

1 - Faites vous aider, une sorte de coach ou un architecte senior pourrait passer quelques jours par mois avec vous, vous aider à trouver des axes d'amélioration, vous donner des indications sur comment les atteindre et surtout vous aider à persévérer...
Raisonnablement, si vos chefs de projets ou le patron de la boîte n'adhèrent pas - i.e. de leur côté tout va très bien - il sera difficile de sortir du trou.
Leur adhésion à 'il faut faire quelque chose' doit se traduire d'une façon ou d'une autre par des dépenses - c'est une des raisons pour lesquelles les consultations des psy sont chère -.
Note: L'aide extérieure est la moins mauvaise solution pour contenir les ennemis précédents.

2 - Changez de boîte! Les défauts d'organisation sont de la responsabilité de vos patrons, s'ils ne veulent pas investir un peu pour faire en sorte que les engagements qu'ils prennent vis à vis de leurs clients puissent être maîtrisés de façon un peu plus prédictible, saine,... profitable il sera difficile de "progresser". Et comme vous n'apprécierez pas indéfiniment d'y passer vos soirées et vos week ends, arrivera un jour où vous craquerez et irez voir ailleurs.

- W

[skerdreux]

Je suppose que SIG est pour système d'information géographique.

La difficulté que je ressens est qu'ayant trop le nez dans le guidon, vous manquez de recul pour pressentir l'ordre qui se dégage de ce désordre.
Il faudrait que vous puissiez descendre du vélo pour vous regarder pédaler...

Vous ne pourrez consacrer que quelques heures par semaine à réfléchir à comment améliorer les choses et essayer de progresser sur certains aspects.

C'est une démarche "hasardeuse" au sens où elle se construira "sur mesure" avec vous, les chefs de projets, ... en fonction de vos possibilités, des opportunités,... qu'il faudra identifier.
S'il y a des résultats, ce sera sur la durée et cela peut être décourageant.

Vos ennemis sont les fausses bonnes idées, l'impatience et le manque de focus.

Vous avez deux sortes de solutions:

1 - Faites vous aider, une sorte de coach ou un architecte senior pourrait passer quelques jours par mois avec vous, vous aider à trouver des axes d'amélioration, vous donner des indications sur comment les atteindre et surtout vous aider à persévérer...
Raisonnablement, si vos chefs de projets ou le patron de la boîte n'adhèrent pas - i.e. de leur côté tout va très bien - il sera difficile de sortir du trou.
Leur adhésion à 'il faut faire quelque chose' doit se traduire d'une façon ou d'une autre par des dépenses - c'est une des raisons pour lesquelles les consultations des psy sont chère -.
Note: L'aide extérieure est la moins mauvaise solution pour contenir les ennemis précédents.

2 - Changez de boîte! Les défauts d'organisation sont de la responsabilité de vos patrons, s'ils ne veulent pas investir un peu pour faire en sorte que les engagements qu'ils prennent vis à vis de leurs clients puissent être maîtrisés de façon un peu plus prédictible, saine,... profitable il sera difficile de "progresser". Et comme vous n'apprécierez pas indéfiniment d'y passer vos soirées et vos week ends, arrivera un jour où vous craquerez et irez voir ailleurs.

- W

Bonjour,

tout d'abord merci pour cette réponse. Vous ciblez en effet très bien mon problème avec cet aspect tête dans le guidon qui est assez complexe.
Je prends pour exemple mon dernier développement où on m'a demandé de réaliser une maquette pour établir les spécifications et ensuite de repartir de cette maquette pour finir le développement. Difficile dans ce cas d'avoir un peu d'abstraction (même si au final en y repensant après j'aurais bien voulu tester une approche plus objet que fonctionnel).
en regardant vos solutions la seconde n'est clairement pas raisonnable vu le context actuel (je ne veux pas prendre le risque de me retrouver au chomage)

Il me reste donc la solution 1 mais le coach en moins. J'ai eu la chance d'avoir un intervenant sur le dernier projet ce qui m'a permis de réfléchir (après coup mais bon c'est déjà ça) sur une conception plus objet, mais ce qui me manque c'est juste le lien à faire entre les spécifications légères et la conception sans perdre trop de temps (sachant qu'à ce moment là on a déjà vendu X jours qui ne prennent pas en compte une analyse importante et pas questions d'en rajouter après).
Bref quelle méthode où quelle analyse est à effectuer avant de se lancer dans le dev ?

je pensais à quelque chose du genre :

1. Clarifier les attentes et spécifier les points pouvant portant à confusion avec le client

2. Dégager une architecture globale d'application sans prendre trop de temps à spécifier chaque partie

3. Essayer d'orienter le développement vers une approche Orienté objet et métier (peut être via des Cas d'utilisation et diagramme des classes pour clarifier le système d'information).

4. Découper le développement en sous partie qui seront à chaque fois testé avant de continuer le développement

5. une fois le développement finit bien tester avant de livrer au client.

J'ai par ailleurs aussi acheté un livre sur "coder proprement" pour améliorer les lacunes qui apparaissent quand on code seul et surtout à la va vite

est ce qu'un telle méthode est intéressante ou est ce que j'ai tout faux ?

en tout cas merci à tout ceux qui ont déjà répondu !!

[bretus]

Bonsoir,

Pour les différentes façon d'aborder les architectures de SIG, je vous conseillerais de jeter un oeil aux applications existantes.

1. Clarifier les attentes et spécifier les points pouvant portant à confusion avec le client

2. Dégager une architecture globale d'application sans prendre trop de temps à spécifier chaque partie

3. Essayer d'orienter le développement vers une approche Orienté objet et métier (peut être via des Cas d'utilisation et diagramme des classes pour clarifier le système d'information).

4. Découper le développement en sous partie qui seront à chaque fois testé avant de continuer le développement

5. une fois le développement finit bien tester avant de livrer au client.

Ca semble plutôt proche de ce qui se fait dans la vrai vie. Pour le 3), je suis un peu septique dans la mesure où j'ai l'impression que ces diagrammes permettent plus de discuter d'une architecture que de la concevoir.

Pour le 4), s'inspirer de l'existant dans le domaine permet de trouver quasi à coup sûr un découpage acceptable au moins au niveau équivalent aux packages.

J'ai par ailleurs aussi acheté un livre sur "coder proprement" pour améliorer les lacunes qui apparaissent quand on code seul et surtout à la va vite

Si vous perdez du temps lorsque vous devez modifier un aspect du projet, je pense que c'est un problème d'architecture.

Pour ma part, me faire "botter" par un architecte qui m'a conseiller de lire "Tête la première dans les design patterns" a été une révélation en matière de programmation orienté objet.
La connaissance des anti-patterns m'a aussi fait remarquer des erreurs de conception que je commettais à tour de bras (peut être plus encore que leurs opposés me guide parfois sur la voie d'une solution)

Ensuite, en plaçant quelques tests unitaires sur les parties "délicates" au moins, on limite bien souvent les risques d'explosions en cas de modification...

Pour ma part, une fois que j'ai pris un peu goût à l'architecture, j'ai eu un grand bénéfice à parcourir les javadoc, doxygene, pdf de certaines API type SIG lourd, client SIG et bibliothèques traitements géométriques en temps mort...

Mais après, tout dépend du domaine d'application de vos programmes. Les SIG restent un monde assez vaste.

++

[souviron34]

Si les applis sont dans le domaine des SIG, et que c'est à peu près la seule constante, alors il faudrait penser fonctionnel et pas objet...


Points communs :

• Transformations de lat-lon en x-y (éventuellement suivant les projections)
• Affichage d'une carte/image géo-référencée
• Zoom et déplacement d'une telle carte
• Affichage d'objet géo-référencé sur cette carte/image
• Délimitation d'un polygone défini par une distance métrique et/ou lat/lon

Pour le début


Tout ceci est récurrent et peut se programmer indépendamment de l'outil utilisé plus tard (dans un langage facilement interfaçable avec tous les langages d'IHM utilisés)


D'autre fonctionalités que vous avez déjà rencontrées peuvent subir le même sort..

En gros, l'attitude à avoir est qu'en ce qui concerne les SIGs, il y a 3 sphères logicielles qui devraient être bien séparées :

1. l'accès aux données (BD)
2. les calculs/fonctionalités de géo-référence et associés
3. Les affichages / l'IHM

Une solution complètement portable consiste alors à se définir une API graphique d'utilités (style "trace-segment, trace_texte, set_couleur, etc") avec vos paramètres à vous, et une structure définie par vous, et quand vous changez de langage vous vous faites juste une biblothèque correspondant à cette API..

[Nebulix]

Si tu ne sais pas ce que veut le client, il sera difficile de le satisfaire.
Si le client ne sait pas ce qu'il veut, idem.
"quand à discuter avec le client c'est galère..."
C'est pourtant là que les efforts seraient les plus utiles.
J'ai suggéré ailleurs de commencer le développement par le manuel utilisateur. Si le client et le programmeur sont d'accord dessus, le reste devrait suivre relativement simplement. (Je n'ai pas eu l'occasion de vraiment tester ce procédé, ce n'est qu'une suggestion)

[hegros]

J'ai suggéré ailleurs de commencer le développement par le manuel utilisateur. Si le client et le programmeur sont d'accord dessus, le reste devrait suivre relativement simplement. (Je n'ai pas eu l'occasion de vraiment tester ce procédé, ce n'est qu'une suggestion)

C'est assez surprenant comme proposition et je n'ai jamais vu un client s'intéresser à un manuel utilisateur avant que le produit soit fini.


En fait dans le cas de produit standard que fourni une entreprise le manuel utilisateur existe déjà dans les grandes formes et ce n'est plus qu'un détail pour l'adapter à une spécificité cliente


En même temps je pense un peu que la documentation comme approche de développement est un anti-pattern avec le développement "moderne" et c'est surtout assez coûteux pour le peu de retour à avoir dessus

Pour répondre grossomodo à la question de départ, une bonne pratique pour éviter des massacres, c'est de lister les risques et de les atténuer le plus rapidement possible. Par exemple le temps tu n'en as pas il faut donc traiter en priorité ce risque et trouver des solutions (limitation de la phase d'analyse, extreme programming, découpage en plus petite release, zapper la documentation, réutiliser du code existant...)

[Nebulix]

C'est assez surprenant comme proposition et je n'ai jamais vu un client s'intéresser à un manuel utilisateur avant que le produit soit fini.

C'est pourtant là que doit être répertorié tout ce que l'utilisateur peut demander à son programme.

[hegros]

C'est pourtant là que doit être répertorié tout ce que l'utilisateur peut demander à son programme.

Oui certes mais comment déjà dis en général une entreprise a déjà un manuel utilisateur pour chaque produit de son catalogue. Un fabricant de machine à café, qui va sortir une v3, ne va pas commencer par écrire un manuel utilisateur car il existe déjà c'est simplement une mise à jour de quelques spécificités mais 95% est existant.


En plus cela reste une vison utilisateur donc cela n'est d'aucune utilité pour l'équipe de développement car dans le manuel utilisateur on ne te dit pas que la machine à café quand elle transmets une information sur le réseau (exemple domotique) elle utilise le protocole x qui enveloppe les données selon telle et telle façon ou quand la pression interne est inférieure à 2mbar alors le clapet interne se ferme cela l'utilisateur s'en moque d'ailleurs il n'y comprendrait rien et n'est pas lié à l'utilisation mais au fonctionnement interne du programme. Le manuel utilisateur ne générera pas non plus la structure de ta base de données et ce genre de chose


Sans compter que la majorité des utilisateurs ne lisent pas les manuels de 999 pages, ils touchent un peu partout et cherche à deviner comment cela marche


Mais rien ne t'empêche de tester la technique..mais à mon avis face à face avec le client cela risque d'être court trop court...

[Nebulix]

Oui certes mais comment déjà dis en général une entreprise a déjà un manuel utilisateur pour chaque produit de son catalogue. Un fabricant de machine à café, qui va sortir une v3, ne va pas commencer par écrire un manuel utilisateur car il existe déjà c'est simplement une mise à jour de quelques spécificités mais 95% est existant.

Je ne comprends pas de quoi tu parles : Si le produit et le manuel existent déjà, il n'y a rien à faire, mais le sujet c'est quand on part de zéro, non ?

En plus cela reste une vison utilisateur donc cela n'est d'aucune utilité pour l'équipe de développement car dans le manuel utilisateur on ne te dit pas que la machine à café quand elle transmets une information sur le réseau (exemple domotique) elle utilise le protocole x qui enveloppe les données selon telle et telle façon ou quand la pression interne est inférieure à 2mbar alors le clapet interne se ferme cela l'utilisateur s'en moque d'ailleurs il n'y comprendrait rien et n'est pas lié à l'utilisation mais au fonctionnement interne du programme. Le manuel utilisateur ne générera pas non plus la structure de ta base de données et ce genre de chose

Je persiste à penser naïvement que le but est la satisfaction de l'utilisateur. C'est en inversant les priorités que l'on aboutit à faire de l'objet le plus simple une "usine à gaz" où j'ai l'impression que les équipes de développement se noient elles mêmes

Sans compter que la majorité des utilisateurs ne lisent pas les manuels de 999 pages, ils touchent un peu partout et cherche à deviner comment cela marche

Et en plus penser le manuel en amont et pas en dernier augmenterait très certainement la qualité dudit manuel

[hegros]

Je ne comprends pas de quoi tu parles : Si le produit et le manuel existent déjà, il n'y a rien à faire, mais le sujet c'est quand on part de zéro, non ?

On part rarement de zéro, il y a toujours un projet assimilé qui s'en rapproche. Une entreprise fournie un type de produit et de service donc elle repart pas de zéro à chaque fois.

Je persiste à penser naïvement que le but est la satisfaction de l'utilisateur. C'est en inversant les priorités que l'on aboutit à faire de l'objet le plus simple une "usine à gaz" où j'ai l'impression que les équipes de développement se noient elles mêmes

Beh non le but d'un projet ce n'est pas la satisfaction utilisateur mais la satisfaction client plus précisément la satisfaction que son business marche.

Et en plus penser le manuel en amont et pas en dernier augmenterait très certainement la qualité dudit manuel

Je ne dis pas qu'il ne faut pas commencer à écrire le manuel très tôt mais pas complètement au tout début surtout pas car rien n'est fixé, c'est sur la fin du projet lorsque tout est ok que l'on peut en toute tranquillité rédiger complétement le manuel sans prendre le risque qu'il y a du changement. Parce que l'écrire complètement au tout début sur un projet qui dure 6 mois cela va forcément changer et il faudra de toute façon réécrire pleins de morceaux


Mais bon tu défends quelque chose que tu n'as jamais testé hors si toi même tu ne le testes pas c'est que tu n'en est pas convaincu sinon cela ferait un bail que tu le ferais et cela ferait un bail que tout le monde ferait ainsi

[souviron34]

@ hegros :

tu devrais lire ce fil :

Spécifications fonctionnelles vs manuel utilisateur

[hegros]

@ hegros :

tu devrais lire ce fil :

Spécifications fonctionnelles vs manuel utilisateur

J'y est apporté ma contribution

Pour ma part je sépare complètement les spécifications fonctionnelles (tâches d'ingénierie logicielle) avec la documentation d'un manuel utilisateur (tâche de gestion de projet)

Quand on regarde les standards ou modèle de développement les plus connus le manuel utilisateur n'est pas associé spécifiquement aux spécifications fonctionnelles c'est un document qui est plutôt transversale. Il est créé au début puis remplis au fur et à mesure des autres phases jusqu'à la transition finale. Donc sa place est plutôt minimisée.

Maintenant effectivement tout le monde est libre de construire son modèle de développement comme il l'entends et un développement orienté manuel utilisateur pourquoi pas mais je n'y crois pas c'est tout


A moins que le client soit très exigeant avec cela sinon pour les clients ne l'exigeant que lors d'une release stable beh on le fera plutôt quand la version sera stable donc cela dépend des clients.

[souviron34]

ça s'appelle "approche centrée utilisateur"

Key priciples of user centered design

Tu peux aussi, en français, chercher ce qu'a écrit Christian Bastien...

[hegros]

ça s'appelle "approche centrée utilisateur"

Key priciples of user centered design

Tu peux aussi, en français, chercher ce qu'a écrit Christian Bastien...

Il me semble qu'il y a plusieurs appellations parfois avec des sens identiques et parfois différents. la conclusion dans mon précédent message est clairement une approche orientée et centrée sur le client pas l'utilisateur

Il y a aussi la théorie des centres qui est intéressante pour le logiciel.