Discussion :

[Garulfo]

[...]Rien d'intuitu personae.[...]

Je ne le prenais pas de manière aggressive. Je me demandais simplement ce que tu voulais dire par là

[souviron34]

Bon alors ça y est je m’y colle….

Tu ne serais pas en train de faire l'apologie des méthodes agiles ?
Personnellement, je crois beaucoup en cette méthode !

Comme je l’ai déjà dit, d’une part il n’y a pas UNE méthode (d’ailleurs tu l’écris toi-même), et de plus moi j’utiliserais beaucoup plus volontiers « User-Centered ».

« Agile » inclus une « structuration » de l’équipe et une manière de concevoir le développement.. Ce qui est hautement variable (et qui à mon avis est une fois de plus l’écueuil de ces « méthodes »).

La bonne veille méthode : Etude du besoin -> Spécification/Conception -> Réalisation (d'une traite) a montré ses limites et tu l'illustres très bien ! Qui peut penser que les besoins n'évoluent pas en 14 ans ?

Non, on a toujours besoin de la « bonne vieille méthode ». C’est juste que le développement est conçu d’une part dans un cycle, et avec la « plasticité » (et la modestie) d’admettre que l’on n’aura pas toute l’analyse d’un coup.

Mais fondamentalement, il y a 2 différences majeures : l’importance relative des tests, et l’ergonomie (au vrai sens, y compris visuel).

Alors que dans les méthodes traditionnelles (et malheureusement j’en vois trop y compris en Agile) les test unitaires sont la règle, et les tests systèmes sont l’aboutissement ultime, et leur échec signifie l’échec du projet (et à contrario leur succès implique le succès du projet suivant les critères informatiques), dans l’approche « User-Centered » les tests systèmes sont en permanence, et l’échec d’un de ces tests n’implique pas du tout l’échec du projet, mais au contraire le raffinement (ou la modification) d’une fonctionalité ou d’une contrainte.

Dans ce cadre, les test unitaires ne sont qu’une technique parmi d’autres (entre autres revue de code) pour vérifier le bon fonctionnement d’un élément élémentaire de la chaîne logicielle, mais dans tous les projets que j’ai vu quasi jamais utilisé systématiquement, au contraire des méthodes traditionnelles.



L’autre différence, et on en a parlé, est que la phase d’analyse ne se fait pas, en général, comme dans les méthodes traditionnelles (y compris visiblement l’implantation actuelle des « méthodes agiles ») par des Analystes (informaticiens), faisant partie de l’équipe Technique et produisant un sous-document pour les Programmeurs, mais par des gens plus « généralistes », qui vont produire plutôt une « specification détaillée» , qui plus est orientée ergonomiquement (arborescence de la fonctionalité, et description précise du flux d’information). Ce qui a une influence déterminante sur l’architecture.

C’est à mon avis là que pêchent y compris les méthodes agiles. Au vu de la discussion ci-dessus, il semblerait que peu de gens comprennent fondamentalement que l’essentiel du travail de construction intellectuelle (arborescence et contraintes, c’est à dire pratiquement directement architecture globale et logicielle) est déterminée par l’ergonomie et non par une « analyse froide » sans tenir compte de l’ergonomie : pour revenir à un des exemples cités plus haut, dans le cas du Dossier Médical, deux exemples de contre-usage :

• l’équipe en place avait inclus dans son design d’origine l’exigence « Informatique et Liberté » du gouvernement (c’est à dire les droits d’accès à l’information), ce qui les avaient amenés à concevoir une application « ressemblant » à une application normale, sauf que la barre de menus était séparée de la partie « fenêtre » en dessous (car elle était différente suivant les droits des usagers). Cette approche non seulement mettait le doute chez les usagers, car les fenêtres ne faisaient que « ressembler » à des applis traditionnelles, la limite de séparation entre les 2 parties étant visible, mais de plus était complètement inverse par rapport à la réalité des urgences, par exemple (personne ne s’occupe aux urgences de savoir qui aurait droit ou non… Dans un bloc opératoire avec 15 personnes et une vraie urgence, ceux qui en ce moment sont plus ou moins dispos exécutent ce qu’il faut exécuter.. Un anesthésiste peut aller cherchr des résultats de labos et une infirmière tenir en place un scalpel). Cela amenait donc une arborescence de la fonctionalité qui n’était pas naturelle.
  
  
• Deuxième exemple, l’analyse non-ergonomique des besoins avait produit la nécessité d’avoir, pour la recherche ultérieure d’nformations, un écran de prescription où tout était très détaillé (du style « fracture membre supérieur gauche première partie 2ième os », et qui entraînait à peu près une série de 55 popups consécutifs pour tout saisir (diagnostic, presciption, forme (cachets, IV, suppos, etc)) alors que la pratique était franchement plus simple… Tout ça pour permettre à des chercheurs ou des épidémiologistes d’avoir accès aux infos dans la BD. Mon argument fut « de toutes façons, pour qu’il y ait des infos dans la base, il faut que les toubibs les y mettent. Si ils passent 8 fois plus de temps avec l’info que sans, ils se passeront de l’info, et vous n’aurez jamais aucun élément dans la BD »…. Une analyse ergonomique a amené à remplacer les 55 écrans par 1 seul, une prescirption compliquée est passée de 43 minutes à 11, et une spécification d’un traitement « batch » offline de la BD a été écrite (à tourner en background).

Avec l’approche traditionnelle, tous les documents d’analyse produits par les analystes lors de ce projet contenaient par exemple les tables BD touchées et les modifications. TOUS ceux produits par mon équipe ne contenaient RIEN de technique. Juste des ébauches d’écrans, avec la description en texte clair des flux de données, contraintes, limites, etc…. AUCUN à-priori sur l’implémentation (et d’ailleurs justement cela a provoqué une grande souplesse d’implantation, avec usage de BDD (avec Corba), de protocoles, etc ).


Enfin, dernier point essentiel, j’avais demandé l’intervention d’un graphiste pour rendre les écrans « esthétiques ». En effet, entre un Kart et une voiture, de fond il n’y a pas beaucoup de différences. Mais on préfère en général utiliser une voiture dans la vie de tous les jours…

La croyance fondamentale des méthodologies traditionnelles (et de ce que je vois des méthode agiles, ça joue encore dans le même registre), c’est qu’en ayant la fonctionalité, on a le produit… C’est faux….

Il est beaucoup plus facile de s’y retrouver, les besoins de formation sont bien moindres, et la satisfaction d’autant plus grande que c’est joliment présenté… Or , à moins d’avoir fait les études pour, personne dans le milieu nformatique n’est formé au graphisme, au vrai.. (comme les pubs). Il faut donc faire appel à un professionnel… Dans le projet ci-dessus, je me suis heurté à un moment donné au Directeur Technique, qui refusait que le graphiste modifie les écrans… De plus, il me demandait d’exiger de lui des règles à adopter… Je lui avais répondu qu’à ce compte-là il devait payer des formations de graphisme à ses employés… La règle est simplement l’esthétisme.. Dans cet écran-là, avoir le fond d’une liste blanc et l’écriture en bleu est esthétique, mais dans cet écran-ci, avoir le fond de la liste en gris et l’écriture en noir l’est plus…

Pour les projets que tu cites, tu as utilisé (à la lettre) une méthode telle que eXtreme Programming, 2TUP (même si, l'agilité de 2TUP est sujette à débat) (ou autre implémentation du processus unifié), SCRUM, etc ou tu as pioché des idées (consciemment ou non) dans chacune d'entre elles ?

Comme je l’ai dit, je n’ai jamais utilisé de méthodes ou méthodologies agiles ni pioché des idées dedans (elles n’étaient pas encore nées), mais une approche « user-centered ».

Cette approche que j’ai eu était d’une part innée, provenant sans doute du fait que j’étais physicien, mais aussi de mes premiers boulots en médecine, où il est évident que l’informatique est au service des usagers et non l’inverse. D’autre part, dans ce domaine, j’ai eu la chance de faire partie d’un projet très novateur, mais très risqué (petite boîte de 15 personnes, avec 5 concurrents géants (du style GE et Toshiba)). Vu l’intoxication commerciale dans les salons internationaux par ces géants, la seule chance dont nous disposiions était d’attraper et convaincre le passant dans le salon en moins de 5 minutes… D’ou une réflexion intense sur l’ergonomie…. Et comme j’étais responsable de l’interface usager….

Enfin je ré-itère que AUCUNE méthode n’est à prendre à la lettre…

Je ne comprends pas cet entêtement de tous les métiers de l'informatique à ne jamais mettre le métier au milieu de la réflexion. au final, l'informatique ce n'est qu'un moyen de ...
Pourquoi accorder si peu d'importance à la réalité du terrain..

Pour ça, je suis 100% d’accord, mais j’avoue ne pas comprendre avec le reste.. En tous cas je te trouve très contradictoire dans ce que tu dis…

Je ne me prononcerai pas sur le terme artisanat parce que je ne sais pas ce que tu veux désigner. Je veux juste préciser que je crois beaucoup à l'industrialisation du développement (d'ailleurs c'est déjà le cas ! L'utilisation d'un framework est une étape de l'industrialisation du développement). Sachant, que cette industrialisation n'est pas du tout incompatible avec les valeurs des méthodes agiles (pour peu qu'on fasse les bons choix).

Pour prendre un exemple pragmatique : si tu vas voir un ébéniste pour te faire faire une table en marquetterie, tu ne lui demandes pas ni le détail de son plan de travail, ni le détail et l ‘ordonnancement de ses tâches… Sa formation l’a amené à être un spécialiste. Tu t’y fies.
Si par contre tu vas voir une usine, il lui faut un plan détaillé, et si tu veux vérifier que ça correspond bien à ce que tu veux, il faut que tu puisses suivre la production pas à pas…

En gros, ce que pour moi je considère de l’artisanat, c’est que, contrairement à la société en général, l’enseignement et les entreprises en particulier, je considère que l’informatique est un métier spécialisé, au même titre que l’ébénisterie ou l’encadrement d’art, ou la musique…..

L’industrialisation suppose « une masse » d’ouvriers… A ce compte-là tu fais IKEA, et tu fais une commode qui se déboîte sinon au premier, du moins au second déménagement…. L’illusion fondamentale de l’industrie informatique et de gros clients, et des méthodologies, c’est qu’en prenant des ouvriers et en leur donnant un manuel, ils vont produire une table en marquetterie de même qualité qu’un ébéniste… Ou qu’en donnant une console Midi à tout le monde, ou Guitar Hero, 80% des gens vont devenir des Paco Di Lucia ou Manitas de Plata…

C’est évidemment faux…

Sauf que l’illusion est là, et également du coup chez les gens qui travaillent dans le domaine…

Là par contre où je ne te suis pas, c’est l’utilisation d’un framework… Tu viens de biaiser le résultat par 2 côtés : d’une part tu utilises quelque chose de commun, qui n’est peut-être pas adapté à ton problème (voir les fenêtres créées avec le premier menu comme étant « fichier », y compris pour des applications ne s’occupant pas de fichiers, et contenant par exemple un élément « Sortir » qui n’a rien à voir avec un fichier) . D’autre part, tu viens de t’interdire toute souplesse et violation des « règles » traditionnelles du milieu informatique.. Or encore une fois nous devons produire quelque chose qui satisfait le besoin (et l’usage) de l’utilisateur… Et il est plus que souvent le cas où les règles d’usage de l’utlisateur violent les règles d‘usage de l’informatique….

L'agile n'est pas une méthode mais une philosophie de développement.

La méthode, c'est ce qui reste à ceux qui n'ont pas la créativité.

Absolument d’accord…

La méthode, c'est du reporting. Rien de plus.
Il n'y a pas de sueur, pas de talent, pas d'exception, pas d'équipe.
Des process, des boites où on pose les "ressources", des gabarits de documents.

Quand je lis tout ça, on arrive pas à se défaire de l'académisme, on arrive pas à faire autrechose que ce que d'autres écrivent dans des livres.

re
Je crois que tu te méprends sur ce que j'ai dis plus haut. Une méthode agile n'existe pas pour avoir du reporting !
…
Sinon, je ne vois pas vraiment le rapport entre méthodes et reporting Je ne vois pas, non plus, en quoi ça nuit à la créativité ?

Ce qu’il veut dire, c’est que le fait même d’imposer (ou de conseiller) des écritures, des documents, de types de documents , etc etc…. rejoins les anciennes méthodologies, c’est à dire produire du papier avant tout…

Et que l’académisme, c’est que d’une part c’est devenu une mode et une croyance, et non une « sensation réelle », et que d’autre part justement la publicité et l’usage des noms de telle ou telle méthode, et non du concept sous-jacent, font croire que cela se définit, se circonscrit, et qui si on suit telle règle ça marche….

Ce qu’il veut dire, c’est que ce qui devrait être enseigné ET demandé par les entreprises c’est un état d’esprit, et non une technique.. En philo, on t’apprend à réfléchir contradictoirement, et sur de grands problèmes insolubles. Mais on t’apprend la démarche. Que tu sois pour Kiergegaard, Nietsche, Socrate, ou n’importe qui, on s’en fiche…. De même en informatique, se focaliser sur telle ou telle méthode ne sert à rien, si tu ne possèdes pas l’esprit sous-jacent et les concepts….

En bref, je suis partisan des méthodes agiles(codifiées ou pas, c'est juste une question de style) dans l'absolu, mais il est à mon sens contre-productif d'y passer si l'ensemble de la chaîne n'est pas dans le circuit

On en revient au problème : ce n’est pas une « méthode », c’est un « état d’esprit » de l’ensemble du projet…

Pour agile, les fondamentaux sont :
Individuals and interactions over processes and tools
(Personnes et interaction entre les personnes avant les process et les outils)
Agile remet clairement le développeur et l'équipe au coeur du principe, partant du principe que dans sa construction et dans sa gestion, les process et les outils seront utilisés comme support d'amélioration plutôt que comme base de travail.

Working software over comprehensive documentation
(Produit efficient prioritaire à une documentation)
La culture du résultat est plus important que la documentation

Customer collaboration over contract negotiation
(Collaboration client plutôt que négociation commerciale)
Culture du fair deal, le résultat n'est pas le fruit d'un engagement contractuel mais d'une relation avec le client.

Responding to change over following a plan
(Adaptation aux changements plutôt que Suivi de plan projet)
Croire davantage à la capacité d'adaptation de l'organisation qu'à la capacité de l'organisation à gérer un projet.

Agile, c'est une philosophie de développement orienté client et résultat.
Etre agile, cela veut dire avoir une vision globale du projet et de l'utilité du projet pour le client; se poser en tant qu'acteur et assumer sa responsabilité dans l'avantage compétitif que peu apporter le projet au client.
Baser sur cela, l'organisation de l'équipe se fait autour de personnes impliquées, responsable en ayant recours au débat d'idées et en mettant en oeuvre un environnement dans lequel les développeurs peuvent atteindre leurs objectifs.
Cela mis en place, l'équipe doit être capable de détecter les ajustements ou les changements à réaliser pour améliorer la productivité, en faisant la promotion de la simplicité (efficience over convention).
Le travail constant entre les experts métiers et les développeurs, doivent permettre aux développeurs de pouvoir faire évoluer et améliorer constamment le design et l'architecture et réduire les temps d'adaptation aux évolutions.
La seule mesure d'éfficacité est un soft qui fonctionne.

Absolument d’accord avec tout ça…

Mais voir plus haut, je pense que la formalisation en «méthodologie » a d’ores et déjà biaisé et diminué le propos….

Mais à partir du moment où les ressources sont identifiées à priori des hommes, ce n'est déjà plus "Agile" compliant.

J’avoue ne pas comprendre totalement cette phrase, en particulier par rapport à :

La réussite d'un projet, c'est l'implication des hommes, la dimension d'équipe et la perception d'un objectif.

Cependant, pour moi, si les hommes sont au centre de l’approche, ce qui me choque profondément, pour y revenir encore une fois, c‘est la croyance (impliquée d’ailleurs par la notion de « méthodologie ») que n’importe qui peut le faire..

Je vais re-citer ce que j’ai déjà cité du projet médical. L’illusion de l’enseignement et des entreprises est ce que m’avait dit le Directeur Technique « je veux faire quelque chose d’extra-ordinaire avec des gens ordinaires »… C’est bien évidemment perdu d’avance… Il faut des gens doués dans leurs domaines à chaque niveau… Et à mon avis c’est ça le facteur humain d’une approche agile, et non « que l’équipe s’entend bien ». C’est nécessaire, mais pas suffisant.


Mais après on se fait traiter d’élitiste !!!! (voir autre discussion)

J'aime beaucoup le premier paragraphe de la page wikipédia consacrée aux méthodes agiles

• Pragmatisme
• Implication du client
• Réactivité
• Satisfaction

Tu peux développer dans ce sens ? Organisation ? Processus de développement, découpage en plusieurs petites itérations (avec livraison) ?

Bon, je l’ai déjà dit, mais je vais m’efforcer d’être succinct et complet…

Organisation :

pour ma part , je préconise un binôme comme Chefs d’Equipe : un utilisateur, reconnu par ses pairs, ayant de nombreux contacts, et une grande expérience (et pratiquant, pas un « retraité » ou quelqu’un ayant migré vers un bureau), et un « généraliste », ayant déjà été dans divers projets et diverses équipes, connaissant l’informatique, mas surtout généraliste.. Chacun des deux est 100% responsable de l’arbitrage des décisions pour son domaine de compétence.. Pour le reste, les décisions se prennent en commun. Si l’un d’eux a besoin d’un avis extérieur, il est seul reponsable pour trouver les interlocuteurs (par exemple l’utilisateur trouvera seul les personnes ressources métier dont il a besoin).

Ensuite, dépendamment de la taille ou complexité du projet, une équipe technique à mon avis d’un grand maximum de 15 personnes… Je n’ai jamais vu une équipe de plus de 15, et à fortiori de 100 personnes, marcher.. (trop de réunions, de temps perdu, de documents à produire pour chaque échelon). A priori tout le monde est au même niveau dans l’équipe, et chacun est responsable à 100% de sa partie (après agrément des Chefs d’2quipe sur la fonctionalité et en gros la technique) : analyse, conception, programmation, tests.

Enfin, pour tout problème technique d’envergure, réaliser des « groupes » de réflexion avec des gens d’horizons différents (par exemple quelqu’un qui était auparvant technicien, quelqu’un qui était auparavant ingénieur, un autodidacte, etc etc..). Plus il y a de points de vue, plus la solution sur laquelle ils sont d’accord sera robuste…..



Processus de développement :

Identiifier la fonctionalité la plus importante, et ce qui lui est nécessaire. Se concentrer là-dessus. Démarrer par des ébauches. Ne pas se fixer de choses contraignantes (par exemple une BD.. La structure ou l’outil pourront (devront ?) varier au cours du temps. A la limite démarrer avec un flat-file). Partant de là, réfléchir prodondément aux parties pas encore définies, aux possibilités d’extension, et démarrer.

De manière générale, programmer en pensant général. Prévoir dès le départ que les nombres de choses seront évolutives, les possibilités très grandes.

De manière générale aussi, ne pas avoir peur de tout recommencer…. Le code.. Par exemple si des tableaux dynamiques étaient prévus, et que les variations des nombres sont trop grandes, ne pas hésiter à tout transformer en liste, même si pour cela il faut ré-éditer 80% des fichiers. Si une modification s’impose dans une API ou dans un protocole, ne pas hésiter…
Si l’outil utitilsé semble poser des problèmes (charge mémoire, limitations, etc) ne pas hésiter à en changer (par exemple, dans le projet médical, au bout de 4 mois nous avons basculé de VB à Delphi).

Egalement ne pas hésiter à admettre que tel ou tel point n’est pas encore au point… (par exemple certaines structures, ou autres choses : la bonne solution peut venir au bout d’un certain temps). Au pire il y aura un « blitz » de modifications lorque la « bonne » solution sera conçue.

Enfin le passage d’un graphiste ou en tous cas de quelqu’un ayant une perception « artiste » pour la mise au point finale de l’apparence.

L’objectif de base devrait être « zéro formation ». Si le logiciel est fait pour les utilisateurs avec les utilisateurs, son utilisation devrait être instrinctive…..


Fondamentalement, 3 écarts principaux avec les techniques et méthodologies usuelles :

• Acceptation que tout n’est pas et ne sera pas défini dès le début
  
  
• La vraie documentation (y compris technique) ne se fera qu’après-coup, quand on saura que cela marche conformément aux attentes.
  
  
• Les réunions ou guidelines ou méthodes ne sont que des moyens, pas des buts. Le respect du processus en tant que tel n’est pas important. La seule chose importante est le produit. (un exemple qui m’est arrivé : un groupe de travail se réuni 1 fois par semaine pour trouver la solution à un problème de fond. A un certain moment, une proposition de solution est faite, et est discutée. Les réunions suivantes continuent à discuter cette solution. Au cours d’une de ces réunions, une nouvelle idée est émise, plus simple, et qui a l’air de tout solutionner. Plutôt que de respecter le processus et d’attendre la fin de l’examen complet de la solution en cours (qui visiblement n’est pas si satisfaisant que ça, sinon il y aurait eu accord assez vite), démarrer la discussion sur la nouvelle solution..)

Découpage en plusieurs itérations :

Ça ça dépend du projet, du contexte, etc..

Le découpage peut être un raffinement de telle ou telle fonctionalité, ou l’ajout de telle ou telle fonctionalité, ou les 2….


Je rajouterais un point pour terminer, et qui est en lien avec l'ensemble de tout ça : les normes ISO, CMM, etc etc... ne garantissent qu'un processus.. pas un résultat. Or on vient de dire que justement une approche "User-centered" garanti un résultat, et non un processus...

Ce qui signifie (et malheureusement je l'ai vécu, mais je suis certain que plein d'entre vous le vivent aussi) que , quelque soit la méthodologie utilisée, y compris dite "Agile", suivre ces normes revient quasiment à suivre un WaterFall : passer 80% du temps de temps à faire de la documentation et 20% du temps au produit, et non l'inverse..... Encore une fois pour satisfaire l'illusion dont il est fait mention plus haut.....





Bon, je ne suis certainement pas complet, mais là pour l’instant je cale…


Ouuuuuufffffffffff……

[B.AF]

Mais voir plus haut, je pense que la formalisation en «méthodologie » a d’ores et déjà biaisé et diminué le propos….




J’avoue ne pas comprendre totalement cette phrase, en particulier par rapport à :



Cependant, pour moi, si les hommes sont au centre de l’approche, ce qui me choque profondément, pour y revenir encore une fois, c‘est la croyance (impliquée d’ailleurs par la notion de « méthodologie ») que n’importe qui peut le faire..

Justement, c'est l'inverse que je prône. Quand je dis mettre les ressources à priori des hommes, c'est tenir le raisonnement du "n'importe qui peut le faire".
ALors que je suis plutôt convaincu de l'inverse : il faut trouver la personne qui peut vraiment le faire.

Quand je parle du développement, j'ai un principe de base qui me viens de mes plus jeunes années : le core - satellite.

On doit constamment avoir suffisamment de compréhension du métier du client pour :
Avoir un core fiable et robuste (eg. : moteur de calcul, etc,etc...)
Avoir une flexibilité d'utilisation (d'où le satellite)
Car là où je te rejoins, c'est que le logiciel n'a pas que comme intérêt de faire du traitement mais de présenter ces traitements de façon intelligente.

Je prends un exemple simple :
J'ai un portefeuille de 200 positions (quelles que soient les positions) sur lesquels je réalise environ 40 Contrôles divers.
Comme résultat, j'ai une classification qui est 'Ko','Warning','Ok'

Pour des raisons d'audit, tout est gardé. Le moteur dans le core est capable de produire les résultats, et de les auditer. Donc la partie traitement est bonne.

La partie satellite c'est penser à comment un contrôleur va vouloir visualiser.
Le bon sens serait de dire : Uniquement les portefeuilles présentant des erreurs puis Les Ko en priorité, par ordre d'écart avec la norme croissant et sous forme synthétique au niveau du portefeuille.
A quoi cela servirait de contrôler un portefeuille qui n'a pas de défauts ?
A rien.

C'est là qu'est la valeur ajouté de la conception. Non seulement elle se doit d'offrir le traitement, mais aussi la possibilité à l'utilisateur d'exploiter la donnée en modélisant son workspace, sans pour autant devoir faire un projet client spécifique.

Et ça vaudrait vraiment le coup que tu développe encore plus ton sujet. IMO.

En tous cas, je l'ai lu avec beaucoup de plaisir.

[yann2]

Salut

Eh ben ! Quelle réponse

Comme je l’ai déjà dit, d’une part il n’y a pas UNE méthode (d’ailleurs tu l’écris toi-même), et de plus moi j’utiliserais beaucoup plus volontiers « User-Centered ».

Je pense que c'est vrai. Il y a plusieurs méthodes dîtes Agiles et un Manifeste Agile. Disons que c'est l'article de Wikipédia France qui est mal nommé ("La méthode agile").

C’est à mon avis là que pêchent y compris les méthodes agiles. Au vu de la discussion ci-dessus, il semblerait que peu de gens comprennent fondamentalement que l’essentiel du travail de construction intellectuelle (arborescence et contraintes, c’est à dire pratiquement directement architecture globale et logicielle) est déterminée par l’ergonomie et non par une « analyse froide » sans tenir compte de l’ergonomie : pour revenir à un des exemples cités plus haut, dans le cas du Dossier Médical, deux exemples de contre-usage :
[...] de protocoles, etc ).

J'ai coupé, non pas parce que je veux mettre l'accent là dessus. C'est juste pour pas que l'ascenseur verticale ne souffre de trop

Je pense que l'ergonomie est très importante. C'est surtout la première chose que va voir l'utilisateur (et on connaît l'importance de la première impression). Et, une IHM qui va à l'encontre de toutes les règles établies ne peu qu'apporter de la confusion. Toutefois, je ne pense pas que ça se limite à ça. Dans ce que tu dis, j'ai l'impression que c'est l'IHM qui dirige le travail d'analyse et de conception d'un logiciel. Ce qui de mon point de vue, revient à penser un logiciel en termes d'écrans (c'est peut être ça que j'ai mal compris d'ailleurs tu nuances un peu : "c’est à dire pratiquement directement architecture globale et logicielle") ! Alors, qu'un tas d'autres choses sont aussi importantes que l'IHM. Je pense qu'il faut choisir au mieux comment on va aborder telle fonctionnalité (ou comment répondre à tel besoin). Pour ça on dispose de plusieurs outils/artefacts : Use Case avec scénario, diagrammes UML, prototype d'écrans, texte en langage naturel... il suffit de choisir les bons outils au bon moment (et, là, encore une fois, je ne pense pas qu'il y ait une recette).
Voilà, pour moi, ce qui peut faire qu'un logiciel est boudé par les utilisateurs

• Mauvaise ergonomie : je ne vais pas détailler, c'est déjà très bien fait
• Mauvaise performance : si c'est plus long à gérer avec le logiciel que sans, aucune utilité
• Trop de bugs (technique) : Si l'utilisateur est obligé d'utiliser 15 000 contournements pour arriver à ses fins, il risque de vite être découragé !! Et, il va même crier de joie quand le logiciel réagira avec succès.
• Bugs fonctionnels (le logiciel ne fait pas ce qu'il devrait faire) : si l'utilisateur ne s'en rend pas compte, il continue à travailler avec des données fausses (pas bien ). Si il s'en rend compte, il risque de ne plus avoir confiance au logiciel et va passer son temps à vérifier que les données sont correctes.

Pour moi, cette liste représente la qualité d'un logiciel du point de vue utilisateur (en admettant que le logiciel propose les solutions aux besoins de l'utilisateur, sinon, ce n'est même pas la peine de commencer à parcourir la liste un téléphone avec lequel on ne peut pas téléphoner, il aura beau être joli, performant, bug proof, je doute qu'il soit énormément utilisé). Ca serait pas mal de continuer la liste ("évaluer la qualité d'un logiciel d'un point de vue utilisateur", je pense que ça peut faire partie du topic, non ?). On peut ajouter : pas cher et fait le café, par exemple !

Non, on a toujours besoin de la « bonne vieille méthode ». C’est juste que le développement est conçu d’une part dans un cycle, et avec la « plasticité » (et la modestie) d’admettre que l’on n’aura pas toute l’analyse d’un coup.

J'ai pas compris tu veux dire que la phase développement est comprise dans des itérations ? En fait, je pensais qu'une itération était gérée avec une méthode en cascade (sauf que ça dure que de 3 à 6 semaines au lieu de plusieurs mois (en considérant qu'un gros développement sera de toutes façons découpés en lots)) : Conception (l'analyse a été faite avant, pas complètement au début du projet, juste qu'elle a été faite avant ) du contenu de l'itération --> Développement (pour moi, développement, ça comprend les tests unitaires et de démonstrations (tester d'un point de vue utilisateur... pour s'éviter de mauvaises surprises ). D'ailleurs quand on me demande de chiffrer du dev, ça comprend toujours les tests. Ca n'a pas vraiment de sens de séparer les deux) --> Livraison. Puis on enchaîne sur une nouvelle itération. Bon, ce n'est qu'un exemple, hein ? Je crois qu'on s'accorde tous à dire qu'il n'y a pas de recette (ce que vous appelez méthode, enfin je crois).

La croyance fondamentale des méthodologies traditionnelles (et de ce que je vois des méthode agiles, ça joue encore dans le même registre), c’est qu’en ayant la fonctionalité, on a le produit… C’est faux….

Tout à fait d'accord (et avec le reste du message). Et, embauché un graphiste c'est très classe ! Je pense que beaucoup croient qu'un développeur ça sait faire de jolies choses ! En fait, bien souvent, les jolies choses réalisées par les développeurs ne sont pas visibles par l'utilisateur final


Juste un petit retour sur l'industrialisation. Je n'ai pas compris ta remarque par rapport l'utilisation d'un framework Framework == Cadre d'application. Si on a besoin de quelque chose qui sort de ce cadre, on doit aussi sortir du cadre (il faut donc qu'il le permette). Si tout ce qu'on fait sort de ce cadre, je pense qu'on s'est trompé de Framework. Là, je pense que tu te focalises trop sur l'IHM L'utilisation la plus "brute" d'un framework est de simplifier la plomberie technique d'une application (pour se concentrer sur le métier de l'application), pas forcément imposer une charte graphique. J'ai fais des recherches sur le sens du mot industrialisation. Il en est surtout ressorti qu'il s'agit d'augmenter la productivité (pas forcément aux dépends de la qualité pour reprendre la comparaison avec IKEA qui, d'ailleurs, n'est pas si mauvaise malgré tout). D'ailleurs, j'ai même tendance à penser que l'utilisation d'un Framework augmente la qualité et la réduit uniquement si il est mal utilisé ou pas approprié. D'autre part, pour augmenter la productivité (oui, j'ai poussé mes recherches) il apparait qu'il est nécessaire d'avoir plein de mesures/reporting et là je rejoins l'avis qui semble ressortir de ce débat (à savoir, pas forcément utile (même si quelquefois ils le sont)). A ce propos, une anecdote sur WTF : http://thedailywtf.com/Articles/Stat...t,-Please.aspx

Et merci d'avoir pris le temps de répondre aux questions ! D'ailleurs les réponses confortent mes idées.

Une petite note spéciale sur celle là :

De manière générale aussi, ne pas avoir peur de tout recommencer…. Le code.. Par exemple si des tableaux dynamiques étaient prévus, et que les variations des nombres sont trop grandes, ne pas hésiter à tout transformer en liste, même si pour cela il faut ré-éditer 80% des fichiers. Si une modification s’impose dans une API ou dans un protocole, ne pas hésiter…

Ca m'est déjà arrivé Et prendre la décision de tout casser n'est pas chose aisée. En fait, le plus dur, c'est d'aller voir le chef pour dire : "Je casse tout, je me suis trompé !" Mais, c'est clair que c'est important. Il faut même recommencer au plus tôt, si on ne fait rien... le retour de flamme peut être violent (à mon avis)

yann

[souviron34]

ALors que je suis plutôt convaincu de l'inverse : il faut trouver la personne qui peut vraiment le faire.

Si c'est ça que tu voulais dire, nous sommes parfaitement d'accord.. Mais j'avais du mal à suivre .. entre les négations et les négations de négations

Et ça vaudrait vraiment le coup que tu développe encore plus ton sujet. IMO.

Dans quel sens ??

(si tu veux, je peux venir faire une conférence (payée ) vers chez toi )

...
Toutefois, je ne pense pas que ça se limite à ça. Dans ce que tu dis, j'ai l'impression que c'est l'IHM qui dirige le travail d'analyse et de conception d'un logiciel.
..
Voilà, pour moi, ce qui peut faire qu'un logiciel est boudé par les utilisateurs

• Mauvaise ergonomie : je ne vais pas détailler, c'est déjà très bien fait
• Mauvaise performance : si c'est plus long à gérer avec le logiciel que sans, aucune utilité
• Trop de bugs (technique) : Si l'utilisateur est obligé d'utiliser 15 000 contournements pour arriver à ses fins, il risque de vite être découragé !! Et, il va même crier de joie quand le logiciel réagira avec succès.
• Bugs fonctionnels (le logiciel ne fait pas ce qu'il devrait faire) : si l'utilisateur ne s'en rend pas compte, il continue à travailler avec des données fausses (pas bien ). Si il s'en rend compte, il risque de ne plus avoir confiance au logiciel et va passer son temps à vérifier que les données sont correctes.

Mais tout ça est de l'ergonomie du logiciel !!

L'ergonomie ne consiste pas seulement en écrans. La fonctionalité, l'utilisabilité (donc points 3 et 4), temps de réponse, y compris configuration matérielle, et autres... sont des éléments d'ergonomie, c'est à dire où l'outil est adapté au travail...

Pour ça on dispose de plusieurs outils/artefacts : Use Case avec scénario, diagrammes UML, prototype d'écrans, texte en langage naturel... il suffit de choisir les bons outils au bon moment (et, là, encore une fois, je ne pense pas qu'il y ait une recette).

Là tu tombes (un peu ) dans ce que dénonçait B.A.F. ..

dire "diagrammes UML" est déjà associer une technique... d'informaticiens...

Use Case est par contre (mais en langage naturel, non formalisé) quelque chose d'essentiel.

J'ai pas compris tu veux dire que la phase développement est comprise dans des itérations ? En fait, je pensais qu'une itération était gérée avec une méthode en cascade (sauf que ça dure que de 3 à 6 semaines au lieu de plusieurs mois (en considérant qu'un gros développement sera de toutes façons découpés en lots)) : Conception (l'analyse a été faite avant, pas complètement au début du projet, juste qu'elle a été faite avant ) du contenu de l'itération --> Développement (pour moi, développement, ça comprend les tests unitaires et de démonstrations (tester d'un point de vue utilisateur... pour s'éviter de mauvaises surprises ). D'ailleurs quand on me demande de chiffrer du dev, ça comprend toujours les tests. Ca n'a pas vraiment de sens de séparer les deux) --> Livraison. Puis on enchaîne sur une nouvelle itération.

Je n'ai pas vraiment approfondi les "méthodes agiles" en vogue (Rup, tup, scrum, et autres), mais non, pour moi le cycle est permanent... Et c'est bien la raison pour laquelle je soutiens que les tests unitaires n'ont presque plus d'importance, et que la documentaton technique est à la fin..

L'idée de la conception est au début, mais la vraie conception est en gros au fur et à mesure (sauf le cadre global, et encore pour le plus gros).


D'ailleurs, en général, les "tests de démonstrations" ne se font pas... On fait des démonstrations, en ayant effectué 2 ou 3 tests systèmes avant.. Sans plus.. et en ayant de fausses données, des traitements cablés ou vides derrière.... Cela fait 25 ans que je fais des logiciels avec IHM et que je suis (très) souvent responsable des IHMs. Et je peux t"assurer que les gars du marketing, c'est vers toi qu'ils se tournent au bout de 3 semaines d'un développement de 2 ans en te disant "bon, il me faut une démo pour le salon le mois prochain" et puis 3 mois après "on a un autre salon.. Faudrait aussi que tu montres cette feature"...



Mais par rapport à ce que tu dis, fondamentalement le schéma même d'une itération cycle en V ne me convient pas. Disons que pour moi il n'y a pas de sens à priori... On part effectivement d'une spéc. On va vers une conception et un développement et des tests. Mais (à moins d'être particulièrement brillant et de passer 80% du temps à faire de la doc) les frontières , dans le cadre d'une "approche agile" (peut-être pas des méthodes du même nom) sont assez perméables... Tant qu'un cycle n'est pas vraiment fini, tout est potentiellement remis en cause en permanence. C'est le fameux principe de "réactivité" que tu citais plus haut de Wiki..

Je trouve totalement absurde l'étape test unitaire (et qui plus est documentation à priori et à posteriori de ces dits tests)...

Et dans le cycle en V justement chaque étape doit être documentée complètement avant la suivante..

Juste un petit retour sur l'industrialisation. Je n'ai pas compris ta remarque par rapport l'utilisation d'un framework..
..
D'ailleurs, j'ai même tendance à penser que l'utilisation d'un Framework augmente la qualité et la réduit uniquement si il est mal utilisé ou pas approprié. D'autre part, pour augmenter la productivité (oui, j'ai poussé mes recherches) il apparait qu'il est nécessaire d'avoir plein de mesures/reporting et là je rejoins l'avis qui semble ressortir de ce débat (à savoir, pas forcément utile (même si quelquefois ils le sont))

Je ne m'étendrais pas sur ces différences, peut-être ne parlons-nos pas d ela même chose..

Si il s'agit de se batir une base de "composants", bibliothèques, éléments divers, etc. communs, bien entendu, c'est ce qu'il faut..

Je parlais plutôt des outils du style RAD, IDE, etc, et méthodes associées (diagrammes, XML, etc etc)... En général, par expérience (mais sans doute d'autres personnes ont d'autres expériences différentes), je n'ai jamais trouvé que cela augmentait la productiivté, et même bien au contraire...

Comme on le disait au début, tout repose sur les hommes dans l'équipe..

Les fameux "L4G" (maintenant L5 ) produisent des montagnes de code bien plus volumineuses que ne l'aurait fait une bonne équipe traditionnelle.. (voir le nombre de fihciers en Java par exemple.. Eclipse installe 65 000 fichiers !!!). Même Delphi produisait déjà du code plus volumineux. De plus, il est moins bien structurable à cause des liens entre diverses parties de ces L4G.

Les diagrammes , méthodes de description, etc. outre le fait qu'il faut les apprendre (temps de formation) sont encore une fois de la génération de papier, par rapport à de la production de code ..

M'enfin je ne me battrais pas là-dessus...

Par contre, le poids majeur, comme tu le re-mentionnes à la fin, ce sont papiers, rapports, rapports d'étapes, commnications et documents divers...

[yann2]

Re

Là tu tombes (un peu ) dans ce que dénonçait B.A.F. ..

dire "diagrammes UML" est déjà associer une technique... d'informaticiens...

Use Case est par contre (mais en langage naturel, non formalisé) quelque chose d'essentiel.

Donc, nous ne sommes pas compris à la base. Quand tu parlais de document d'analyse, j'ai pensé que tu parlais également des documents au sein de l'équipe de développement. Je pense qu'utiliser un diagramme UML (pas exhaustif, UML est trop compliqué pour avoir quelque chose d'exhaustif et on perd trop de temps à modéliser des choses qui ne sont pas nécessaires (et qui, donc, pollue ton joli diagramme) ou implicites), montrer ce diagramme à ses collègues et dire : "cette tâche, c'est comme ça que je vais l'implémenter. Vous pouvez me faire des retours". Il y a d'énormes avantages !! Plusieurs avis sur le micro-problème et l'équipe sait comment ce problème est résolu dans l'application (même si il l'oublie, lorsqu'il aura besoin de revenir dessus, il y a de grandes chances que ça lui revienne en tête). Pour la documentation technique, je suis d'accord avec toi. A la fin tu fais un joli reverse engineering et tu complètes avec ce qu'il te semble nécessaire. Enfin, des fois, le client est aussi un informaticien et comprend UML et aimerait bien pouvoir modifier le programme si besoin est

Pour la partie industrialisation, il est possible qu'on ne parle pas de la même chose
Mais en fait... j'y crois encore plus que ça Notamment à l'ingénierie des modèles et à la génération de code (oui, je sais, la génération de code souffre d'une très mauvaise réputation. Mais, ça évolue). Je me rappelle même d'une question d'un collègue alors que nous étions en train de pisser du co... euh... de développer : "Mais ? On arrive à générer cette partie là ! On ne pourrait pas générer ces fichiers là aussi ?" J'ai trouvé ça génial ! Le MDA efficace quand on y a goûté on a du mal à s'en passer ! Pourtant, beaucoup sont sceptiques.

Sinon, je ne suis pas d'accord pour les tests U ! Non seulement ça valide (dans la limite de la couverture des tests) ton composant mais, surtout, ça permet d'avoir une bonne base de test de non régressions. Ca sert un peu de filet de sécurité aux refactorings que peut subir l'application (refactoring que tu dis est omni présent. Et, je suis d'accord). Le tout lié avec une plate forme d'intégration continue et tu sais tous les matins si les tests passent. En, gros, tous les jours on peut savoir si un changement fait "péter" l'application (enfin... dans la limite de la couverture des tests ). Et ce n'est pas du process managing reporting engineering rétro pro actif !! C'est plutôt le contraire : c'est l'équipe de dev qui a tanné la hiérarchie (qui n'a pas rechigné puisqu'elle reconnaît l'utilité d'une telle plate forme) pour pouvoir mettre en place ce système ! Au jour le jour on voit vraiment la différence. En prime : là où on devait faire un tas d'opérations manuelles chiantes et répétitives (le tout prenant une à deux heures), nous n'avons plus qu'à cliquer sur un bouton et voilà.
Bref, Agile, c'est les hommes avant les outils mais ça n'empêche pas d'utiliser les outils. Surtout si ça améliore le train de vie des hommes (d'ailleurs l'intégration continue est une pratique présente dans l'eXtreme Programming).

yann

[B.AF]

UML....Ca me fait rire...

Tu mets 10 personnes dans la salle à faire de la modélisation UML sur le même sujet, il n'y en a pas une qui te sort le même process..

UML c'est une vaste blague...

Ca sert à quoi d'avoir un formalisme de présentation alors que la perception et donc la concpetion et par nature spécifique à la personne ?

Tu finis par te retrouver avec une application complêtement incohérente, mais au moins elles sont écrites...

Le Use Case est vital car il te permet de comprendre à quoi l'utilisateur s'attend. Maintenant, en UML ou en texte simple et bien structuré...

Mais là où je rejoins souviron, c'est que dans l'absolu ce qui prend du temps c'est l'IHM.
Si tu ne pars finalement de cette vision cliente, tu as aussi un risque qui est connu et récurrent : la multiplication et la redondance des services.
Par "absence" de compréhension des données qui sont restitués, on construit des services sur une logique de "prévoir tous les cas". Alors qu'en se basant sur une logique cliente, on peut réduire les services à la portion réellement utile et consacrer le reste à du test unitaire.

La politique des tests unitaires est souvent très complexe à mettre en oeuvre dans le cas où on ne sait pas ce qu'attend réellement le client in fine.
Donc on se retrouve à tester les éléments techniques, les services, les composants, en croisant les doigts que la somme des tests unitaires garantie une pérenitée.

En outre, il est évident que l'IHM dans un soft joue énormément sur l'appréciation de celui-ci...Combien de fois alors que j'avais montré des fonctionnalités métier la question qui est apparue était "Pouvez vous faire un camembert? , Pouvez vous comparer deux situations ?".

C'est comme tous : le contenu est plus important que la forme.

[yann2]

Salut

UML....Ca me fait rire...

Tu mets 10 personnes dans la salle à faire de la modélisation UML sur le même sujet, il n'y en a pas une qui te sort le même process..

UML c'est une vaste blague...

Ca sert à quoi d'avoir un formalisme de présentation alors que la perception et donc la concpetion et par nature spécifique à la personne ?

Tu finis par te retrouver avec une application complêtement incohérente, mais au moins elles sont écrites...

UML peut peut être paraître drôle quand on ne sait pas à quoi ça sert ! Si je prend 10 personnes que je les enferme dans une salle à développer une application en (au choix : Java, C#, VB, ...) sur le même sujet, il n'y en pas deux qui vont me faire la même application.

Si je prend un couteau par la lame et que je tente de cuire ma viande avec :

• Ca ne sera pas pratique
• Ca risque de faire mal

UML, comme son nom l'indique, est un langage pas une méthode ! Et, si on obtient une application incohérente, ce n'est pas forcément à cause du langage (des fois ça peut être le cas, enfin je crois).

Les diagrammes UML te permettent d'avoir une représentation graphique de ta conception ! Ca ne fait pas la conception à ta place !
UML te permet d'obtenir un modèle de ta conception, ça ne fait pas la conception à ta place.

Partant de cet état de fait, je ne jetterai pas un outil aussi pratique. A moins qu'on me trouve quelque chose de plus simple pour exposer graphiquement mes idées.

Ca sert à quoi d'avoir un formalisme de présentation alors que la perception et donc la concpetion et par nature spécifique à la personne ?

La notation UML est assez riche pour exprimer une conception. Si il y a ambiguïté c'est que soit le diagramme est mal fait et sert à rien, soit que le lecteur ne connaît pas UML et le diagramme ne lui sert à rien. Dans une équipe de développement, j'ai toujours trouvé ce moyen de communication très efficace (là ça s'appuie sur du réel ). Plus efficace que 2 000 lignes de code par exemple !

UML est loin d'être the silver bullet. Je suis le premier à le reconnaître. Ca n'en fait pas pour autant un outil bon à mettre à la poubelle.

Yann

[chaplin]

+1

Après maitriser UML, c'est une autre affaire car c'est franchement pas évident car relativement abstrait en particulier pour les diagrammes de classe.

[souviron34]

Salut..

Je commence par un bref retour en arrière...

Dans ce que tu dis, j'ai l'impression que c'est l'IHM qui dirige le travail d'analyse et de conception d'un logiciel. Ce qui de mon point de vue, revient à penser un logiciel en termes d'écrans (c'est peut être ça que j'ai mal compris d'ailleurs tu nuances un peu : "c’est à dire pratiquement directement architecture globale et logicielle") ! Alors, qu'un tas d'autres choses sont aussi importantes que l'IHM. Je pense qu'il faut choisir au mieux comment on va aborder telle fonctionnalité (ou comment répondre à tel besoin). Pour ça on dispose de plusieurs outils/artefacts : Use Case avec scénario, diagrammes UML, prototype d'écrans, texte en langage naturel... il suffit de choisir les bons outils au bon moment (et, là, encore une fois, je ne pense pas qu'il y ait une recette).

Quand tu cites Use Case, proto d'écrans, texte en langage naturel, on parle bien d'IHM..

C'est bien ce que je dis : toute l'arborescence fonctionnelle, une grande partie (> 80%) des structures de données, et une grande partie (> 80%) des flux de données, sont déterminés à priori par une étude ergonomique de l'IHM.

L'IHM détermine l'architecture fonctionnelle. Pas forcément l'architecture du code, mais celle de la fonctionalité.

Ce qui reste comme "variables" sont les algos, les fonctionalités internes (accès aux BDs, calculs, cascades d'actions, etc etc..).

Ce qui reste à déterminer comme "paramètres" ou "compléments de structures de données sont les paramètres à usage interne...

Pour la partie industrialisation, il est possible qu'on ne parle pas de la même chose
Mais en fait... j'y crois encore plus que ça Notamment à l'ingénierie des modèles et à la génération de code (oui, je sais, la génération de code souffre d'une très mauvaise réputation. Mais, ça évolue). Je me rappelle même d'une question d'un collègue alors que nous étions en train de pisser du co... euh... de développer : "Mais ? On arrive à générer cette partie là ! On ne pourrait pas générer ces fichiers là aussi ?" J'ai trouvé ça génial ! Le MDA efficace quand on y a goûté on a du mal à s'en passer ! Pourtant, beaucoup sont sceptiques.

là on ne sera pas d'accord... Mais alors pas du tout

Mais je suppose que ça vient avec le nombre et la complexité des projets traités...

Mais je peux t'assurer que a) maintenir ou b) reprendre un code créé avec des outils de génération de code est une galère abominable.... (un seul exemple : un outil de génération de code ne fait pas tout seul de routine (ou callback, ou service) générique.... Il en fait une (ou un) pour chaque objet ou instance d'objet... Si donc tu as des dizaines d'objets, il ont tous la même routine dupliquée, avec juste le préfixe du nom qui change pour tenir compte de l'objet.. Ce qui peut faire de milliers de lignes de code....)

Sinon, je ne suis pas d'accord pour les tests U ! Non seulement ça valide (dans la limite de la couverture des tests) ton composant mais, surtout, ça permet d'avoir une bonne base de test de non régressions. Ca sert un peu de filet de sécurité aux refactorings que peut subir l'application (refactoring que tu dis est omni présent. Et, je suis d'accord). Le tout lié avec une plate forme d'intégration continue et tu sais tous les matins si les tests passent. En, gros, tous les jours on peut savoir si un changement fait "péter" l'application (enfin... dans la limite de la couverture des tests ).

c'est là que pour moi ce n'est pas "agile"...

Pour moi, c'est au fur et à mesure(dans la journée) que ça se teste... Et je répète, les test unitaires tels que définis dans les normes de développement (tester que si on a fait une fonction somme (a,b), elle fait bien a+b, avec documentation aval et amont) sont stupides...

Ce que j'ai fait, et poussé mes équipes à faire, c'est : comme je disais, chacun est reponsable de sa partie. Mais chaque évolution se fait tester toutes les 10 ou 30 minutes...

Quand je développe, je fais de 80 à 150 compils par jour... Et je teste avec les vraies données, le vrai environnement... Même si je dois faire des copies ftp 3 ou 4 fois dans la journée pour me mettre sur la machine "opérationnelle"...


Et un bon gestionnaire de config t'avertira si tu as un conflit avant de placer les modifs dans le répertoire central.. Et tu pourras le tester avant de remplacer.. Donc , au cours de tes modifs, si tu touches à des structures ou autres, tu pourras vérifier avant de faire le code. Et après, ben c'est plus que pisser des lignes...

Ce que tu exposes là n'est donc pas ce que, de mon point de vue, j'appelle "agile"..

Je pense qu'utiliser un diagramme UML (pas exhaustif, UML est trop compliqué pour avoir quelque chose d'exhaustif et on perd trop de temps à modéliser des choses qui ne sont pas nécessaires (et qui, donc, pollue ton joli diagramme) ou implicites), montrer ce diagramme à ses collègues et dire : "cette tâche, c'est comme ça que je vais l'implémenter. Vous pouvez me faire des retours". Il y a d'énormes avantages !! Plusieurs avis sur le micro-problème et l'équipe sait comment ce problème est résolu dans l'application (même si il l'oublie, lorsqu'il aura besoin de revenir dessus, il y a de grandes chances que ça lui revienne en tête). ... Enfin, des fois, le client est aussi un informaticien et comprend UML et aimerait bien pouvoir modifier le programme si besoin est

UML, comme son nom l'indique, est un langage pas une méthode !

100% d'accord avec notre ami B.A.F.

UML c'est une vaste blague...

Pourquoi avoir besoin d'un autre langage que celui avec lequel nous parlons tous les jours ??

Pourquoi avoir besoin de formaliser plus que des boites et des flêches que tout le monde peut faire avec Word ou à la main ??

Pourquoi vouloir toujours "modéliser" pour un truc aussi simple qu'écrire sur une feuille de papier ??

Qu'est-ce qui t'empêche de faire partager ta feuille aux autres ?

En quoi est-ce qu'un informaticien ne comprendrait pas le langage naturel et des boites et des flêches ??

Mais ça fait de nouveau partie (j'avais démarré un thread là-dessus au début de l'an dernier) des "buzz-word" et modes qui fait qu'il y a ceux qui sont "in" (qui les connaissent ou les utilisent) et ceux qui sont "out" (les autres).. (suffit de voir les offres d'emploi, et quand on voit ce qui se passe sur le forum conception->modélisation, visiblement ça simplifie pas la vie ).

Je suis résolument "out" de ce côté-là, et, comme pour CMM etc, c'est bien de le connaître, mais non merci... Quand je travaille, j'ai pas de temps à perdre.. Chaque heure compte... Donc faire une présentation et/ou un diagramme à la main ou sous Word, ça me suffit amplement..


@B.A.F. : pourrais-tu préciser ce que tu aimerais voir développer ??

[ZeRevo]

UML est surtout pratique pour partager et exposer un point de vue sur une architecture ou un concept complexe. Utiliser l'UML pour faire de l'UML n'a aucun sens.

souviron, quand tu parles de fournir vite une démo c'est l'un des principes des méthodes agiles, car elles préconnisent de commencer par les tâches qui apportent le plus de valeur ajoutée au client et de fournir la possibilité à tout instant de pouvoir donner un livrable au client.

Ce qui me désole dans ton discours c'est que tu nous sorts ta solution miracle, tu dis d'un côté qu'il n'y a pas de méthode parfaite mais en même temps tu proposes ta méthode : ergonomie / ihm.

Un commentaire aussi sur "on ne peut travailler avec les meilleurs". Je dirais non car personne n'est parfait et puis le mieux dans une équipe c'est de limiter les conflits et d'avoir des leaders et des moutons. Les indomptables sont très négatifs à la survie d'un projet.

Pour en revenir sur l'agilité, les méthodes mettent le développeur au centre des choix technologiques, et pour les choix importants, il doit demander l'avis de son équipe. Au passage, il est préconisé d'avoir une équipe de 7 personnes max en collocalisé.

Je pense qu'un logiciel c'est pas uniquement le rendu final. Derrière toute conception, il faut penser plaisir. Pourquoi on crée de belle ihm ? pour que l'utilisateur soit content tous les jours d'utiliser le logiciel. C'est la même chose avec l'informaticien, s'il doit travailler avec des outils inadaptés, il se lassera vite et pensera moins à la qualité. De plus, les méthodes agiles préconisent de prendre toujours la solution la plus simple (qui ne veut pas dire non plus n'importe quoi). La simplicité est une notion complexe et personne dans mon équipe n'est tombé d'accord pour l'instant. Certains la définisse comme faire le plus simple sur l'instant quitte à faire des mauvais choix technologiques qui seront revus par la suite s'il le faut et d'autres pensent qu'il faut penser à l'avenir en mettant en place une structure plus complexe mais qui permettra par la suite plus de souplesse. En clair, il s'oppose 2 mentalités : les pro-frameworks et les anti-frameworks.
J'appartiens au pro-framework, car ils m'aident à ne pas réinventer la roue, mais ils demandent de la formation, du temps pour l'installation, pour le choix du framework, pour la configuration. Je vois la simplicité plutôt au niveau algorithmique, ca ne sert à rien de faire des choses complexes, ca n'apporte que des problèmes (maintenance, évolutivité, expertise, bugs) ormis le fait de se sentir "intelligent" auprès de ceux qui ne comprennent pas; alors que la simplicité apporte que des avantages. Faire un programme qui fonctionne et qui soit utilisé n'est il pas en soit un exploit et quelque chose de complexe ?

Un dernier point, les méthodes agiles préconisent le travaile en pair programming (binomage) : l'un code et l'autre vérifie et propose; et alternativement. Sens présenter les points positifs et négatifs, je m'attarde sur le fait que cette méthodologie permet de ne pas être expert d'un bout de code ou partie (ihm par exemple) et donc de devenir indispensable. Ne pas être dépendant de sa création et la faire évoluer au fil du temps par d'autre développeur.

En tout cas il ne faut pas voir les méthodes agiles comme la solution miracle ou comme une solution de trop. Elles ne répondent pas à tout mais elles apportent une réponse au développement d'un logiciel.

[Furikawari]

UML est un "buzz word" qui dure depuis quinze ans.

Et puis, pourquoi avoir inventé l'écriture ? Finalement, la transmission orale ça marchait bien, l'écriture aussi doit faire partie des buzz words...

Les mots peuvent être ambigüs et c'est pour ça qu'un petit dessin (et donc un diagramme UML dans notre domaine) sera clair et net pour tout le monde.

Evidemment si on travaille la plupart du temps seul dans son coin on a probablement pas besoin de ce genre d'outils.

[rakakabe]

Quel debat ! on apprend bien des trucs avec. grand merci a vous tous.

je suis pour l'idee 'centrer sur l'utilisateur' et l'importance de l'IHM pour garantir un produit qui repond aux specifications . En effet, mon humble avis me dis que l'une des rares choses qui permet de mettre en accord les informaticiens et les utilisateurs finaux est l'IHM :

1 - l'utilisateur se fout completement qu'il y a des tas de techniques et autres pour arriver a de tels resultats (methodes, processus, ...). Ce qui l'interesse en revanche, c'est qu'en cliquant sur tel bouton, il peut voir les trucs qu'il a besoin pour son travail et tout le reste ...

2 - l'informaticien, lorsqu'on le met sur le projet, s'interesse plus a la technique qu'a comprendre ce que fait l'utilisateur.

Ainsi, lorsque l'utilisateur dit qu'entrer un nom et cliquer sur tel bouton fait afficher l'information d'un tel client, alors l'informaticien comprend vite qu'il doit faire des requetes sur une base de donnees distante pour l'afficher dans une jolie table (du point de vue de l'utilisateur bien sur) ...

Comme ca, tout le monde comprend ce que tout le monde veut dire car c'est pas technique et evite la formation de l'utilisateur (car c'est son intuition).

Tout le reste est relatif ....

Malheureusement, ce n'est pas toujours le cas ....

[chaplin]

UML est surtout pratique pour partager et exposer un point de vue sur une architecture ou un concept complexe.

- oui

Les mots peuvent être ambigüs et c'est pour ça qu'un petit dessin (et donc un diagramme UML dans notre domaine) sera clair et net pour tout le monde.

- oui

quand on voit ce qui se passe sur le forum conception->modélisation, visiblement ça simplifie pas la vie.

C'est tout simplement que la peur est un frein pour beaucoup de personne car UML s'apparente à quelque chose d'ésothérique mais Bruno Pages fait partie de ces personnes qui cherchent à démistifier avec son outil BOUML le langage de modélisation. Après, il faut reconnaître qu'il y a des gens extremement doués (je m'exclu) dans ce domaine, car les exemples dans les bouquins sont remarquables en terme de clarté pour peu qu'on a compris le principe et cela demande pas mal d'efforts intellectuels.

Il y a un bouquin qui m'a particulièrement marqué, celui de Christian Soutou "De SQL à UML", il a fait un tour de force en faisant un parallèle entre le modèle Merise et le modèle UML donnant un visage plus concret au langage de modélisation UML. Bien entendu, sur le fond c'est la méthode Merise qui est utilisée derrière, les représentations sont un chouya différents mais elles expriment les mêmes concepts, juste avec des syntaxes différentes. Cependant, UML est plus riche que Merise car il permet d'aborder la dimension dynamique (ie méthodes/fonctionnalités) avec les diagrammes de séquence/interactivité dont la clarté est remarquable lorsque les classes et les méthodes sont bien définies.

En clair, il s'oppose 2 mentalités : les pro-frameworks et les anti-frameworks.
J'appartiens au pro-framework, car ils m'aident à ne pas réinventer la roue, mais ils demandent de la formation, du temps pour l'installation, pour le choix du framework, pour la configuration. Je vois la simplicité plutôt au niveau algorithmique, ca ne sert à rien de faire des choses complexes, ca n'apporte que des problèmes (maintenance, évolutivité, expertise, bugs) ormis le fait de se sentir "intelligent" auprès de ceux qui ne comprennent pas; alors que la simplicité apporte que des avantages. Faire un programme qui fonctionne et qui soit utilisé n'est il pas en soit un exploit et quelque chose de complexe ?

C'est là ou la notion de design pattern prend toute sa force, car en décorticant les frameworks objet, on s'apperçoit que c'est une combinaison de design pattern, des briques de légo "patterns" assemblés pour donner des architectures complexes appelés Framework. Dans ce cas on rentre dans le domaine de l'ingénierie logiciel.

Utiliser l'UML pour faire de l'UML n'a aucun sens.

C'est une phrase de bon sens, il ne s'agit pas d'employer UML comme un Buzz word, au contraire de le rendre populaire au même titre que les langages objet à une autre époque surtout qu'il a été conçu sur la base des langages objet donc adapté pour les langages objets, mais il peut être utilisé pour n'importe quel type de problèmes même non informatique.

[souviron34]

souviron, quand tu parles de fournir vite une démo c'est l'un des principes des méthodes agiles, car elles préconnisent de commencer par les tâches qui apportent le plus de valeur ajoutée au client et de fournir la possibilité à tout instant de pouvoir donner un livrable au client.

Si tu me lis correctement, j'ai effectivement parlé de se concentrer sur la fonctionalité la plus importante, mais aussi, pour les démos, du fait d'avoir plein de "coquilles vides" ou "coquilles hard-codées".

Ce qui ne figure pas dans la desription et guidelines des méthodes agiles en tant que tel...

Ce qui me désole dans ton discours c'est que tu nous sorts ta solution miracle, tu dis d'un côté qu'il n'y a pas de méthode parfaite mais en même temps tu proposes ta méthode : ergonomie / ihm.

Je n'ai pas dit que c'était la solution miracle... J'ai simplement dit que sans ça, l'échec est quasi-certain...

C'est nécessaire. Pas suffisant...

Un commentaire aussi sur "on ne peut travailler avec les meilleurs". Je dirais non car personne n'est parfait et puis le mieux dans une équipe c'est de limiter les conflits et d'avoir des leaders et des moutons. Les indomptables sont très négatifs à la survie d'un projet.

Si tu le dis....

J'ai déjà donné tous mes arguments. Encore une fois, "si vieillesse pouvait et si jeunesse savait"...

Je pense qu'un logiciel c'est pas uniquement le rendu final. Derrière toute conception, il faut penser plaisir. Pourquoi on crée de belle ihm ? pour que l'utilisateur soit content tous les jours d'utiliser le logiciel. C'est la même chose avec l'informaticien, s'il doit travailler avec des outils inadaptés, il se lassera vite et pensera moins à la qualité.

Alors là, tu rêves...

Où est le plaisir pour le gars qui serre des boulons sur une chaîne de voiture ??

Tu es dans l'illusion (et ma génération en est responsable) que parce que l'informatique est "intellectuelle", on doit y prendre plaisir...

C'est faux..

C'est bien si on peut, mais ça n'est pas le but, et ça n'arrive que dans les cas où tu as assez de bagage pour être "indépendant" (c'est à dire éventuellement démissionner, changer de projet, etc).

Tu te rendras vite compte dans la vraie vie qu'entre les supérieurs idiots ou léche-culs, les incompétents, les décisions qui te dépassent dans l'intérêt du Groupe, les guerres entre services, ou le poids de tel ou tel client, etc etc, le "plaisir" n'est de loin pas le moteur d'un développement ...

Encore une fois, le seul but d'un projet informatique est de fournir un produit. Point final. De même que le seul but d'une chaîne de production est de produire une voiture..

Ca n'est qu'un bonus si tu y prends plaisir..

Mais le but du client qui paye tant de centaines de milliers d'euros pour avoir un soft, c'est pas que l'équipe du prestataire ait du plaisir, c'est qu'il ait son soft..

En tout cas il ne faut pas voir les méthodes agiles comme la solution miracle ou comme une solution de trop. Elles ne répondent pas à tout mais elles apportent une réponse au développement d'un logiciel.

Absolument d'accord, mais c'est bien pour ça que je dis, comme B.A.F., que c'est une philosophie, et pas une méthode.. Et que ce qu'on n'enseigne pas ou ne met pas en avant (mais c'est pas nouveau, c'est pareil avec toutes les modes en info) c'est l'état d'esprit...

[souviron34]

C'est tout simplement que la peur est un frein pour beaucoup de personne car UML s'apparente à quelque chose d'ésothérique mais Bruno Pages fait partie de ces personnes qui cherchent à démistifier avec son outil BOUML le langage de modélisation. Après, il faut reconnaître qu'il y a des gens extremement doués (je m'exclu) dans ce domaine, car les exemples dans les bouquins sont remarquables en terme de clarté pour peu qu'on a compris le principe et cela demande pas mal d'efforts intellectuels.

Donc tu admets que ce n'est pas "straightforward".. par rapport à une simple écriture et pensée.

le modèle UML donnant un visage plus concret au langage de modélisation UML.
..avec les diagrammes de séquence/interactivité dont la clarté est remarquable lorsque les classes et les méthodes sont bien définies.
..
C'est là ou la notion de design pattern prend toute sa force, car en décorticant les frameworks objet, on s'apperçoit que c'est une combinaison de design pattern, des briques de légo "patterns" assemblés pour donner des architectures complexes appelés Framework.

Que de concepts informatiques !!!!

Je rappelle l'argument cité ci-dessus par yann2 :

Je pense qu'utiliser un diagramme UML ... montrer ce diagramme à ses collègues et dire : "cette tâche, c'est comme ça que je vais l'implémenter. Vous pouvez me faire des retours". Il y a d'énormes avantages !! Plusieurs avis sur le micro-problème et l'équipe sait comment ce problème est résolu dans l'application ... Enfin, des fois, le client est aussi un informaticien et comprend UML et aimerait bien pouvoir modifier le programme si besoin est

souligne que le besoin central est de pouvoir exposer et communiquer...

En quoi l'introduction de concepts et d'un nouveau langage ou codification (opposés au langage naturel et aux dessins manuels) fait-elle améliorer la communication ??

Bien au contraire, cela la restreint aux seuls "initiés"..

Si il te faut présenter ton schéma ou ton arborescence à une réunion de gens "métiers", il faudra que tu le re-traduises.. De même si, pour convaincre la Direction de donner plus de temps ou d'argent, il faut que tu le présentes au CA..

Donc, tu as fait soi-disant un travail de "communication", mais qui doit être traduit car le commun des mortels ne le comprend pas, ni aucun des concepts qu'il y a en dessous...

ça c'est de l'avancée dans la communication

C'est une phrase de bon sens, il ne s'agit pas d'employer UML comme un Buzz word, au contraire de le rendre populaire au même titre que les langages objet à une autre époque surtout qu'il a été conçu sur la base des langages objet donc adapté pour les langages objets, mais il peut être utilisé pour n'importe quel type de problèmes même non informatique.

Voir plus haut...

En bref, c'est un langage technocratique reservé à l'aéropage des gens de l'informatique..

[yann2]

Salut

Souviron, j'utilise la génération de code tous les jours (et avec succès). J'y reviendrai plus tard. Je pense que nous n'avons pas les même expériences.

Pourquoi une notation graphique alors qu'on peut écrire ? Pourquoi un architecte fait il un plan du bâtiment alors qu'il pourrait le décrire textuellement ?

Enfin, je développerai ce soir

Yann

[B.AF]

Salut

UML peut peut être paraître drôle quand on ne sait pas à quoi ça sert ! Si je prend 10 personnes que je les enferme dans une salle à développer une application en (au choix : Java, C#, VB, ...) sur le même sujet, il n'y en pas deux qui vont me faire la même application.

Si je prend un couteau par la lame et que je tente de cuire ma viande avec :

• Ca ne sera pas pratique
• Ca risque de faire mal

UML, comme son nom l'indique, est un langage pas une méthode ! Et, si on obtient une application incohérente, ce n'est pas forcément à cause du langage (des fois ça peut être le cas, enfin je crois).

Et c'est ça le problème : Tout le monde peut parler la même langue, mais tout le monde n'a pas le même dictionnaire et tout le monde n'a pas la même capacité de synthése et tout le monde n'a pas la même capacité de compréhension.

Et je te rassure : on peut ne pas croire en sachant ce que c'est.
Mais ça c'est une approche personnelle...Ce n'est pas parce que 1000 personnes te disent qu'un film est génial qu'il l'est pour toi.
Donc évite ce genre de figure générale STP.

Les diagrammes UML te permettent d'avoir une représentation graphique de ta conception ! Ca ne fait pas la conception à ta place !
UML te permet d'obtenir un modèle de ta conception, ça ne fait pas la conception à ta place.

Partant de cet état de fait, je ne jetterai pas un outil aussi pratique. A moins qu'on me trouve quelque chose de plus simple pour exposer graphiquement mes idées.

La notation UML est assez riche pour exprimer une conception. Si il y a ambiguïté c'est que soit le diagramme est mal fait et sert à rien, soit que le lecteur ne connaît pas UML et le diagramme ne lui sert à rien. Dans une équipe de développement, j'ai toujours trouvé ce moyen de communication très efficace (là ça s'appuie sur du réel ). Plus efficace que 2 000 lignes de code par exemple !

UML est loin d'être the silver bullet. Je suis le premier à le reconnaître. Ca n'en fait pas pour autant un outil bon à mettre à la poubelle.

Si ça ne sert qu'à ce que tu décris, je ne vois pas l'utilité d'utiliser un outil aussi lourd et aussi spécifique pour échanger. Forcer les gens à apprendre une langue n'a jamais aidé les gens à mieux communiquer.

[B.AF]

Salut

Souviron, j'utilise la génération de code tous les jours (et avec succès). J'y reviendrai plus tard. Je pense que nous n'avons pas les même expériences.

Pourquoi une notation graphique alors qu'on peut écrire ? Pourquoi un architecte fait il un plan du bâtiment alors qu'il pourrait le décrire textuellement ?

Enfin, je développerai ce soir

Yann

Parce qu'il est tout seul à faire les plans, pas 120 à tous voir les choses différemments. Le problème de la formalisation de la conception n'est pas une question d'outils mais une question de personnes.

[B.AF]

Et d'ailleurs, l'exemple est encore plus décalé du fait que l'architecte connait parfaitement les besoins et contrainte de la maitrise d'oeuvre (exemple déjà cité je crois); ce qui est très loin de ce que certains défendent ici.

Là où l'exemple est encore pire, c'est que l'architecte (BTP) impose la conception (archi), les matériaux (techno), l'emplacement et le temps (moyens), et les "concepts de vie" (métier).

D'ailleurs en ayant 2 dans la famille, ils pensent que le terme architecte est aujourd'hui largement usurpé dans des tonnes de métiers par des gens qui ne comprennent pas grand chose à ce qu'ils architecturent.