tag:blogger.com,1999:blog-479555891921312205.comments2023-06-27T02:39:41.567-07:00Institut AgileAnonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.comBlogger54125tag:blogger.com,1999:blog-479555891921312205.post-3491323700978999222012-04-30T08:55:40.166-07:002012-04-30T08:55:40.166-07:00Bonjour
besoin d'un avis d'expert sur un...Bonjour <br /><br />besoin d'un avis d'expert sur un process agile<br /><br />Consultant qualification SI, mon client me demande de mettre en place de l'agilité dans la phase de conception de son cyle de vie projet, l'objectif est de d'arrêter de tenter de produire des spec qui n'en finissent plus et jamais vaLidées...<br /><br />Mon idée est de proposer un process de conception agile avec :<br />- en entrée, les besoins utilisateurs "dépoussiérés" par des ateliers thématiques MOA déjà en place<br />- en sortie, la liste des exigences et tests pour amoa et moe qui concevront les tests respectifs et vérifieront les couvertures d'exigences, les uses cases et autres diag UML pour la moe qui démarre ses sprints de dév<br />- comme acteurs : scrum master, amoa, moe<br /><br />Quel est ton avis sur les livrables en entrée et sortie de ce process ?<br /><br />Cordialement<br />François LEFEVRE<br />lefevre_francois@orange.frflefevrehttps://www.blogger.com/profile/02413844942366787391noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-29302970412882925242011-11-17T12:57:30.320-08:002011-11-17T12:57:30.320-08:00Bonjour,
Merci à toi Laurent et tous ceux qui son...Bonjour,<br /><br />Merci à toi Laurent et tous ceux qui sont à l'origine de cette initiative. C'est toujours motivant de voir d'autres personnes aller dans la même direction que soi.<br /><br />Je finis par une gentille coquille dans le premier paragraphe de la partie 'Mission du group' de cet article qui me donner l'occasion d'un feedback : <br />"Quel et son objectif" au lieu de "Quel est son objectif".<br /><br />A bientôtChristophehttps://www.blogger.com/profile/12027317041129277891noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-29604775521451218082011-11-10T00:57:28.816-08:002011-11-10T00:57:28.816-08:00Bonjour,
j'ai malheureusement raté l’évèneme...Bonjour,<br /><br /> j'ai malheureusement raté l’évènement mais j'ai tout de même une question sur le sujet, ou pas très loin:<br /><br />quid d'un enseignement agile des sciences/informatique ? Non pas l'apprentissage de l'agilité (encore que) mais l'apprentissage de l'informatique dans un contexte agile. <br /><br />bien à vous.Cédric Hartlandhttps://www.blogger.com/profile/06847651175530065118noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-13986724519489791452011-05-28T04:03:26.218-07:002011-05-28T04:03:26.218-07:00Bonjour,
Je viens de découvrir ce blog à l'i...Bonjour,<br /><br /> Je viens de découvrir ce blog à l'instant et je voulais juste profiter de ce billet pour faire part de mon expérience personnelle. Je travaille sur des projets multimédia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE. <br /> Et je dis: Attention car un effet de mode s'est emparé de notre industrie en vendant les bienfaits d'une méthodologie dont le nom semblait séduisant mais le retour d'expérience a été un peu cuisant pour plusieurs prestataires <br /> - Dans le cadre d'un projet au forfait avec des paiements liés aux livrables mensuels, continuer d'imposer une phase de spécification du projet (80%) pour garantir vos rentrées d'argent. En vendant le principe que client peut redéfinir ses besoins et les affiner à chaque itération, il trouve cela très plaisant et c'est très constructif pour l'équipe, mais il ne le fait pas pour les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être fait car le contrat n'est pas respecté à la lettre. Le Product Owner (client) que vous impliquez dans votre méthodologie n'est pas nécessairement le décisionnaire et cette méthodologie peut rapidement vous étouffer financièrement<br /><br /> - Conservez la notion de Chef de Projet au SCRUM MASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une structure de lead technique, lead artiste, lead ergonome ... avec des strates (de senior à junior). Un jour la problématique des responsabilités individuelles viendra sur la table et la notion d'équipe unifiée explose à ce moment. <br /> Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver un système d'évaluation des individus sur le long terme. Ce n'est pas le chef de projet, mais bien les leads qui vont évaluer les juniors ( en cas de primes ou de promotion)<br /> - ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement car le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme les notre, de formaliser un feedback et nous le communiquer) Entre temps l'équipe à avancer dans la mauvaise direction et c'est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et toujours le faire faire par écrit <br /> - Ne négliger pas la documentation, les réunions stand-up meeting ont la fâcheuse tendance de ne laisser aucunes traces. Réduisez les à l'essentielle et laisser les leads organiser des réunions métier avec un COMPTE RENDU à la clef ... ce qui permet aux gens de s'y référer si un problème resurgit et une décision déjà prisemarc_fieldhttps://www.blogger.com/profile/17519506124783094870noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-28108427475288097892011-04-09T02:00:18.965-07:002011-04-09T02:00:18.965-07:00Bonjour,
Vous trouverez sur le lien ci-après ma ré...Bonjour,<br />Vous trouverez sur le lien ci-après ma rétrospective de cette super 1ère Master Class organisée par l'Institut Agile autour des "Innovation Games" :<br />http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/03/31/Retrospective-Master-Class-Innovation-Games-du-29-au-30-mars-2011<br />@+<br />FabriceJapon 2023https://www.blogger.com/profile/01876392284304887848noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-29423849839684756182011-01-05T13:20:31.595-08:002011-01-05T13:20:31.595-08:00Neal Stephenson utilise aussi l'image des Morl...Neal Stephenson utilise aussi l'image des Morlocks dans son essai "In the Beginning... Was the Command Line" (voir http://en.wikipedia.org/wiki/Morlock#Morlocks_in_essays_and_other_nonfiction)Sekondahttps://www.blogger.com/profile/10727234043392183668noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-74843990891554138602011-01-05T10:36:47.307-08:002011-01-05T10:36:47.307-08:00Une innovation de rupture, c'est la chance d&#...Une innovation de rupture, c'est la chance d'un pays, qui peut grâce à elle faire prendre à sa population une avance importante sur la concurrence internationale. Mais la lancer exige des efforts quasiment surhumains face à la concurrence traditionnelle, bien mieux armée, installée et rentable. Lancer une innovation de rupture exige une très forte compétence marketing puisqu'il faut pénétrer une clientèle qui n'est pas demandeuse, non pas parce que cela ne l'intéresse pas mais car elle ne croit pas cette innovation possible. <br /><br />Le problème de l'innovation de rupture en France, c'est que notre pays n'a pas de structure pour aider à percer ces innovations qui nous rendraient TOUS riches. Il n'y a pas de cellules ou d'organismes spécialisés dans ce domaine avec tout un réseau adapté. Oseo, par exemple, est parfaitement désarmé face à une innovation de rupture. <br /><br />Je sais de quoi je parle car j'ai mis au point une invention de rupture en ...1986 ! Et depuis 12 ans, chaque année je sollicite du capital-"risque". Qui répond "non" sans même demander une démonstration... Aujourd'hui, elle est toujours autant "de rupture" et les investisseurs ne s'y intéressent toujours pas tellement elle leur paraît révolutionnaire. <br /><br />Il s'agit d'un ordinateur intelligent... Entre autres, il écrit lui-même les programmes en interrogeant les experts en langage courant. Il le fait infiniment plus rapidement que les outils classiques, plus fiablement et la maintenance, le point noir du génie logiciel, est plus facile que le développement ! Donc, suivez mon raisonnement : plus besoin d'utiliser les langages informatiques classiques (Java, C++, Pascal, etc.) ! Donc, plus besoin d'informaticiens ! Tout possesseur de PC devient un programmeur beaucoup plus performant, compétent et rapide que les développeurs professionnels.<br /><br />Nous sommes bien là dans le domaine du génie logiciel... Le développement du logiciel se fait en langage courant par des non-informaticiens... Il s'agit bien d'une innovation de rupture. Et pourtant, ce sont les innovations "de rupture" présentées par les informaticiens (Cloud Computing...) qui recueillent les capitaux. Or, elles sont déjà totalement dépassées et surtout inutiles face à la programmation sans contrainte, à la portée de tous, en langage naturel... <br /><br />En dépit de cette évidence, cela fait 24 ans que je rame ! Cherchez mon nom sur Internet : Jean-Philippe de Lespinay...Jean-Philippe de Lespinayhttps://www.blogger.com/profile/09651699652844504769noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-34467227842614526692011-01-04T23:24:24.462-08:002011-01-04T23:24:24.462-08:00Interesting. Although, in science, all “truths” ar...Interesting. Although, in science, all “truths” are provisional and all “truths” are candidates for subsequent revision based on evidence and experimentation.<br /><br />And for an operational definition of programmer productivity see recent paper by Tom Gilb.<br /><br />- Bob (@FlowChainSensei)zx12bobhttps://www.blogger.com/profile/07434630569746999346noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-15294421917719410352011-01-03T06:05:46.674-08:002011-01-03T06:05:46.674-08:00Bonjour Laurent,
Le billet est paru:
http://blog...Bonjour Laurent,<br /><br />Le billet est paru:<br /><br />http://blog.piaction.com/2010/12/scrum-analyse-de-nos-retrospectives/<br /><br />Merci pour ce billet, et surtout pour tes éclairages et avis lors de notre discussion.<br /><br />Ludovic.Anonymoushttps://www.blogger.com/profile/15765720546751024219noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-39267570819320460122010-12-17T08:09:56.598-08:002010-12-17T08:09:56.598-08:00Oui, j'ai pensé à ce film en écrivant le bille...Oui, j'ai pensé à ce film en écrivant le billet. Je dois t'avouer que je ne l'ai pas (encore) vu.<br /><br />C'est donc difficile de commenter, je ne sais pas notamment si le film insiste plus sur l'activité de programmation ou sur l'aspect "business", qui par contre n'est pas du tout absent des média: on nous parle assez souvent à la télé ou à la radio de Google, d'Apple, voire de Wikipedia (je me demande d'ailleurs dans quelle mesure le battage autour de Wikileaks entretient la confusion qui existait déjà sur la nature des Wiki dans l'esprit du grand public).<br /><br />Mais il s'agit toujours de l'aspect extérieur de ces technologies, de leur impact économique ou sociétal, qui n'est visible précisément que parce qu'elles sont en décalage avec le quotidien. On ne parle jamais (ou, si TSN en parle, presque jamais) de ce que c'est que *fabriquer* du logiciel.<br /><br />Il y a aussi des films ou des épisodes de série qui tournent autour du personnage du "hacker", mais c'est une caricature du programmeur, pas la réalité. En règle générale, à chaque fois qu'on montre un écran d'ordinateur dans un film et qu'il s'y passe quelque chose c'est ridiculement et grossièrement irréaliste: et encore il ne s'agit le plus souvent que *d'utilisation* d'un logiciel, plutôt que de sa création.Anonymoushttps://www.blogger.com/profile/07379040637704958977noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-29128136700075981742010-12-17T07:53:40.570-08:002010-12-17T07:53:40.570-08:00Le film "Social Network" n'est-il pa...Le film "Social Network" n'est-il pas une manière de parler de ces fameux programmeurs ? Dans ce cas, peut-on vraiment dire qu'on ne parle par d'eux ?Etienne Charignonhttps://www.blogger.com/profile/16992622240771983808noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-2507522069137888332010-12-10T07:06:57.093-08:002010-12-10T07:06:57.093-08:00Hmmm... Je me rappelle qu'à l'époque où j&...Hmmm... Je me rappelle qu'à l'époque où j'étais étudiant à l'IUT, on nous disait: "On va vous apprendre à apprendre".<br /><br />Et j'ai pu constater que ceux que je considère comme de bons professionnels font ce qu'ils peuvent pour "rester à jour". On voit deux-trois ans après la sortie de l'école ceux qui ont mis à jour leurs connaissances, et les autres.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-57618217504791279452010-12-06T11:09:55.017-08:002010-12-06T11:09:55.017-08:00J'ai plus aucun espoir en la recherche informa...J'ai plus aucun espoir en la recherche informatique française depuis que j'ai expliqué à un thésard de l'INRIA ce qu'étaient les méthodes agiles (il avait jamais entendu le terme !).<br /><br />Non pas que l'agile soit l'alpha et l'omega mais un brillant cerveaux universitaire français dans le domaine IT qui passe complètement à côté, ça laisse entrevoir toute la richesse des échanges et des débats d'idées...Unknownhttps://www.blogger.com/profile/13609050279617107357noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-55099425835447832372010-12-03T07:42:43.777-08:002010-12-03T07:42:43.777-08:00Bonjour Laurent,
Visiblement je ne peux pas poste...Bonjour Laurent,<br /><br />Visiblement je ne peux pas poster de commentaire ici, j'ai mis ma réponse sur mon blog [1] en attendant,<br /><br />Gildas<br /><br />[1] http://blog.endemics.info/post/2010/12/03/R%C3%A9ponse-au-post-de-l-Institut-Agile-%3A-%22Devops-premi%C3%A8res-rencontres-et-survol%22Unknownhttps://www.blogger.com/profile/17982448843964276851noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-81399362639373142192010-12-03T07:28:07.495-08:002010-12-03T07:28:07.495-08:00Bonjour Laurent,
Merci pour ce compte-rendu, je n...Bonjour Laurent,<br /><br />Merci pour ce compte-rendu, je n'ai malheureusement pas été en mesure de venir à ce premier meetup-parisien.<br /><br />Je m'inscris un peu en faux sur l'impression que me donne ta phrase "Vous aurez compris qu'on est entre techniciens...".<br /><br />Je conviens que le choix du nom devops est un peu malheureux et de nature à donner l'impression qu'il s'agit là d'un mouvement de techniciens pour les techniciens.<br /><br />Du chemin a été parcouru depuis le premier Devopsdays à Gand en 2009 où le nom est apparu, et déjà à l'époque le nom était apparu comme trop réducteur car il n'adressait qu'une partie des centres d'intérêts des personnes présentes.<br /><br />En fait les difficultés entre dév et prod n'étaient que la partie cachée de l'iceberg, et les problèmes abordés étaient aussi bien techniques qu'organisationnels ou humains.<br /><br />DU fait du rayonnement international de la conférence et parce qu'il remplissait un vide, le terme devops [1] s'est propagé comme une trainée de poudre et s'est imposé.<br /><br />Si l'on peut regretter que le terme soit trompeur, ce défaut est à mon sens contrebalancé par le fait qu'il existe désormais une étiquette sous laquelle nous sommes nombreux à nous retrouver pour échanger.<br /><br />Je ne doute pas qu'au vu des profils des gens ayant participé au premier devops meetup parisien la majorité des problématiques abordées aient été plutôt techniques, et il est de fait logique que ce soit ce point qui apparaisse dans ton compte rendu, mais il me semblerait dommageable que cela renforce chez tes lecteurs l'ambiguité déjà imputable au nom.<br /><br />A mon sens devops est un mouvement qui traite des problèmes liés à l'informatique d'entreprise, ce qui est un vaste sujet! De fait, je partage complètement l'avis de Damon Edwards : devops n'est pas la réponse à un problème technique mais à un problème business [2]. J'invite les lecteurs curieux ou réfractaires à l'anglais à aller lire la rapide présentation que j'ai posté il y a de cela plusieurs mois déjà sur devops.fr [3].<br /><br />Cordialement,<br />Gildas Le Nadan<br />http://blog.endemics.info / @endemics<br />-- <br />[1] Le plus souvent d'ailleurs sous une forme, "DevOps", différente de celle souhaitée initialement par Patrick Debois pour qui les majuscules rappellent malheureusement la séparation entre dév et prod.<br />[2] http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html<br />[3] http://www.devops.fr/ qu'il est plus qu'urgent que je mette à jourUnknownhttps://www.blogger.com/profile/17982448843964276851noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-75047519845522374952010-12-03T03:36:42.966-08:002010-12-03T03:36:42.966-08:00Je possède les 2 cultures : je fais du dev depuis ...Je possède les 2 cultures : je fais du dev depuis 20 ans (perso puis pro) et de l'admin (en pro) depuis 10 ans maintenant. Et je dois dire que cela m'aide *beaucoup* dans mon travail : cela me permet d'intervenir sur l'ensemble de la chaine de valeur et de l'optimiser sans cette fameuse barrière dev / admin. D'ailleurs, je retrouve dans vos sujets abordés des fonctionnalités que nous avons mis en place :<br /><br />- création d'un environnement virtualisé à la demande pour les tests<br />- le test (quelques que soit la version, stable comme dev) se fait en créant un package binaire identique à celui déployé par un client. Les tests internes reproduisent la chaine complète (et non juste un test sur une machine de développeur).<br />- l'environnement de buid permet de créer des versions en cours de developpement (version stable + 1 bugfix ou fonctionnalité en cours)<br />- le système fait du partie de l'ensemble (pas le choix, nous vendons des appliances)<br />- et plus généralement, il n'y a pas de séparation dev / prod (tous à la R&D, dans la même piece)<br /><br />Pour en revenir à tes propos. Le rapprochement est encore lointin, car si tu ne veux pas que cela se réduise à des outils, c'est bien ces outils qui sont le point de discordre le plus important. La ou un développeur à besoin d'outil souple pour le développement, l'admin veut des outils en rapport avec sa philosophie.<br /><br />Un exemple assez criant se trouve sur les outils de gestion de composant. Un développeur travail avec Maven (Java) ou Buildout (Python), la ou l'admin veut du RPM / DEB, qui s'intégre dans son OS, ses outils classiques de gestion de parc, et qu'il maitrise. Et apprendre à un admin les outils de dev, c'est le faire rentrer dans le monde du dev, avec toute sa complexité : outil de gestion de source (Git), outil de composant code (Buildout), fonctionnement des paquets Python (Egg) sont par ex. le minimum vital qui doit être maitrisé ici. Rien de bien méchant pour un dev, mais un pas gigantesque pour un admin qui n'a jamais développé de sa vie (à part modifier quelques scripts Shell ici ou la).<br /><br />On peut voir cette dychotomie dans la refonte du projet Distutils2, de mon ami Tarek : l'objectif est de revoir le packaging Python (trop longtemps délaissé hélas). De longues discussions ont suivis sur les besoins et exigeances de chacun, et on a pu voir distinctement qu'un admin (admin lambda, responsable de packages Debian...) avait une vision bien différentes des développeurs.<br /><br />Un autre aspect intéressant est le cloud : la plupart n'offre plus la même liberté d'administration, et c'est bien l'aspect développement qui est mis en avant. J'ai pu tester récemment Heroku, une plateforme d'hébergement d'application Ruby : on gère ses instances avec un outil CLI qu'on télécharge sur sa machine puis on met en prod... avec Git. Le modèle Heroku semble prendre de l'ampleur (naissance de plusieurs plateformes de ce type en cours).<br /><br />Clairement, cette barrière doit disparaitre mais le changement de culture sera aussi important que de faire disparaitre MOE / MOA je pense.Unknownhttps://www.blogger.com/profile/01521930817789457626noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-42527301359443140282010-12-03T02:15:15.252-08:002010-12-03T02:15:15.252-08:00Je commence par ma conclusion : l'utilisation ...Je commence par ma conclusion : l'utilisation conjointe de pratiques agiles et du model-driven peut sous certaines conditions être extrêmement performant.<br /><br />Je pense qu'il faut définir ce que veut dire "model-driven". En fonction de la stratégie MD choisie, il y a des conséquences sur la compatibilité avec les pratiques agiles ; Exemples :<br /> 1. modèle exécutable : implique d'utiliser un environnement MD sur étagère. L'architecture technique cible est imposée par l'outil (au mieux, possibilité de choisir entre quelques variantes). L'effort de modélisation est important, en particulier sur le "code métier". Les formalismes de modélisation associés (state machines, activités, diagrammes de séquence) sont relativement complexes à utiliser (=> contraintes sur les profils des développeurs).<br /> NB : l'approche "modèle exécutable" est très intéressante et pertinente dans certaines situations. J'essaie juste de montrer les contraintes qu'elle impose (ces contraintes pouvant être jugées tout à fait acceptables pour le projet).<br /> 2. modèle et code synchronisés : jouable seulement en utilisant un environnement MD sur étagère. Les modèles sont du même niveau d'abstraction que le code, donc complexes et techniques (=> le modeleur devient une sorte d'interface graphique du code). Si on souhaite changer d'architecture technique, tout (ou presque) est à refaire. <br /> N. DSL, UML ou pas, MDA ou pas, GMF, XTEXT, MDSD, MDE, etc.). Combinatoire importante.<br /> 999. approche DSL + générateurs spécifiques + pratiques agiles : ma préférée ;-) DSL = Domain Specific Language. Le principe et le suivant : on met en place un vocabulaire (métaphores?) qui permet de qualifier et décrire l'architecture logique du logiciel(par exemple, des "ObjetPersistant", "ServiceCRUD", "ServiceMetier", etc., en fonction de vos besoins). Une architecture logique peut être implémentée en Java, .Net, Android, etc. (sans impact sur le modèle). Pour mettre en oeuvre une approche DSL, le plus simple aujourd'hui est d'utiliser un bon modeleur UML avec un "Profil UML" que vous mettez en place vous même . Le générateur de code est développé au fur et à mesure par l'équipe agile. Les bénéfices de l'aproche :<br /> - le modèle est simple. Donc facile à modéliser, comprendre, faire évoluer. Par exemple, si on marque une UMLClass comme étant un "ObjetPersistant", on peut générer un script DDL, une interface de DAO, une implémentation de DAO, un POJO Java, de la configuration Spring, hibernate, etc. C'est le générateur qui décide comment on met en oeuvre les concepts de l'architecture logique.<br /> - on peut facilement générer et faire évoluer tout le code technique sans refactoring (intervention sur les seuls templates de génération). <br /> - on place le curseur où on veut : généralement, on ne souhaite générer "que" le code technique et laisser le développement du code métier en mode manuel (codage classique). Le positionnement du curseur dépend d'un compromis effort/bénéfice (les fonctionnalités du générateurs sont dans le backlog). Rester pragmatique.<br /> - l'approche met en avant une réfléxion découplée sur les architectures logiques et techniques, qui n'est pas sans intérêts ni bénéfices.<br /> - on gagne en célérité dans les développements (production automatique et en masse de code)<br /> - le modèle est la référence (approche top-down). Il n'est pas désynchronisé du code et est donc représentatif du logiciel (intérêt pour la maintenance à long terme). On peut l'exploiter pour de l'analyse d'impact, détecter des défauts (validation de modèles), générer des docs, calculer des métriques, etc.<br /> - on peut développer les profils UML, les générateurs et le code manuel avec des pratiques agiles. Tout ça n'est que du code après tout.<br /> - si on a bien travaillé, on peut même réutiliser les profils et générateurs pour d'autres projets (capitalisation)Romain BERNARDhttps://www.blogger.com/profile/13523486475156091328noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-13442849547939306562010-12-03T00:07:14.214-08:002010-12-03T00:07:14.214-08:00@oaz
"comment développer en "test driven...@oaz<br />"comment développer en "test driven", c'est à dire en commençant par écrire des tests exécutables, et apporter des réponses sous forme de code "model driven" aux tests qui ne passent pas encore ?"<br /><br />Tu codes ton test, en manuel ou en DSL dédié ou ce que tu veux (préférence pour le mode manuel pour ne pas perdre la pratique agile). Après, au lieu de coder manuellement le code de prod, tu mets en oeuvre la chaine modele-generateur-code pour faire passer ton test. La mise à jour incrémentale de modèle et de générateur peut aller très vite, là j'ai des preuves (avec solution MIA Generation par exemple)<br />La conception émergente et le refactoring peuvent donc être adressés par MD, mais par une approche différente, qui peu s'avérer tout aussi agile voire plus.<br /><br />Faut rester pragmatique et tester cette méthode sur des projets réels, à enjeux de production.<br />Dans mon cas, je suis toujours au stade d'élaboration de proto par manque de temps (je n'y ai pas retoucher depuis un an, c'est dire !)<br /><br />Je pense qu'il faudrait un bon vieux financement R&D pour aller au fond des choses un fois pour toutes.<br />Il faut rester ouvert et honnête en regard des faits. Je m'engage à reconnaître le cas échéant toute démonstration d'incompatibilité.<br /><br />Bref je vois le MD comme une évolution naturelle et inéluctable de la programmation, mais pas à court terme. Et svp, oubliez MDA !<br />Il s'agit avant tout de trouver le bon équilibre entre l'apport MD comme cohésions d'artefacts et l'apport de l'agilité comme livraisons incrémentalesUnknownhttps://www.blogger.com/profile/16627198547260108037noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-55726319759237936172010-12-01T13:38:11.544-08:002010-12-01T13:38:11.544-08:00Bonjour Laurent,
Merci pour ce point de vue intér...Bonjour Laurent,<br /><br />Merci pour ce point de vue intéressant. Vouloir vérifier à quel point l'étiquette "Agile" correspond à ce qui est pratiqué par la communauté Model-Driven, l'intention est louable! Mais tout comme Omid, je ne comprends pas comment le Model Driven peut paraître "aux antipodes du discours agile". <br /><br />C'est vrai, les programmeurs ne trouvent pas toujours leur compte quand ils utilisent des outils MD (automatisation oblige), mais la satisfaction du client ne passe pas forcément par celle du programmeur. L'acceptation du changement, cheval de bataille de l’agilité, est grandement favorisée quand on communique et qu'on raisonne au niveau modèle, car on est alors capable de se rapprocher des acteurs du métier en parlant leur langage.<br /><br />D'après nos observations sur le terrain et les résultats sur les nombreux projets auxquels W4 participe en collaboration étroite avec ses clients (et pas seulement en mode RAD), les principes et les valeurs du manifeste agile sont essentiellement renforcés quand un développement est piloté par le modèle. Non, il ne s'agit pas de buzz : le MDE est indéniablement vecteur d'agilité. <br /><br />En ce qui concerne W4, nous répertorions sur notre site web, sous http://www.w4.eu/workflow-bpm-methode-agile.htm , en quoi notre produit renforce, selon nous, le mise en œuvre des principes et des valeurs du manifeste agile. Cela est encore favorisé, ils nous semble, par l’approche MDE que nous préconisons : pas de génération de code mais une exécution ‘à la volée’ du modèle.<br /><br />Jean-Loup ComeliauUnknownhttps://www.blogger.com/profile/04803641394570375771noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-48816994021821735752010-12-01T12:48:15.904-08:002010-12-01T12:48:15.904-08:00Merci Xavier pour votre contribution, je suis asse...Merci Xavier pour votre contribution, je suis assez en phase avec cette analyse.<br /><br />@Oaz: dans le cas de notre produit, nous pouvons inclure dans nos modèles des données, ce qui facilite le test-driven également. Je ne sais pas bien si nous sommes les seuls sur ce point.<br /><br />DanielUnknownhttps://www.blogger.com/profile/15227070812734687725noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-37616482300810281932010-12-01T07:33:38.470-08:002010-12-01T07:33:38.470-08:00Bonjour,
Evidemment que l'ingénierie des modèl...Bonjour,<br />Evidemment que l'ingénierie des modèles peut être agile! Tout comme des équipes Scrum ne sont parfois pas du tout agiles...<br />Tout est question d'outillage. L'idée est de choisir l'outil effaçant les pseudos lourdeurs de la démarche MDE. Pour cela, j'estime qu'il y a 4 éléments clés que l'outil MDE doit remplir :<br />- synchronisation automatique du modèle et du code<br />- validation en live du modèle<br />- repository de modèles (et merge de modèles!)<br />- interoperabilité des outils<br /><br />Sans ces 4 points (au moins!), j'estime à 70% la probabilité d'échec d'une démarche model driven agile. En effet ils permettent de répondre au point du manifeste suivant : "Individuals and interactions over processes and tools" en permettant à chaque developpeur d'avoir dans son workspace une version du code et du modèle alignés et toujours à jour sans efforts.<br /><br />En ce qui concerne les autres points du manifeste agile, je ne voit pas en quoi ils sont incompatibles avec le MDE : <br /><br />- "Working software over comprehensive documentation" : c'est le but du MDE<br />- "Responding to change over following a plan" : le MDE facilite cela<br /><br />Les principes agiles sont totalement compatibles, je viens de les relire, et j'irai même plus loin en disant que le MDE facilite la mise en oeuvre des principes agiles.<br /><br />Bonne journée,<br />Xavier SeignardXavier SEIGNARDhttps://www.blogger.com/profile/05507552082288691776noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-12954897358054467642010-12-01T05:39:40.607-08:002010-12-01T05:39:40.607-08:00Je suis assez d'accord... Je pense que la plup...Je suis assez d'accord... Je pense que la plupart des programmeurs se *sentent* mal éduqués en tout cas, et ça explique le succès de diverses initiatives (conférences agiles, ateliers, etc.) parce qu'on pressent qu'on va y trouver un apprentissage plus pertinent.<br /><br />On pourrait se demander pourquoi les écoles ne font pas un boulot plus efficace? Après tout c'est leur rôle...Anonymoushttps://www.blogger.com/profile/07379040637704958977noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-25753895905682941072010-12-01T05:27:01.696-08:002010-12-01T05:27:01.696-08:00Difficile d'expliquer cette phrase sans contex...Difficile d'expliquer cette phrase sans contexte, chacun ira donc de son interprétation. Voici la mienne.<br /><br />La plupart des développeurs que je vois ne sont pas fait pour ce job : c'est un métier bien particulier, introspectif, analytique. Dans l'informatique, il y'a les développeurs et les autres. C'est le seul métier de conception.<br /><br />Ensuite, le niveau moyen à la sortie de l'école est mauvais : aucune connaissance réelle en gestion de projet, en maitenance de code, en test, en conception logicielle. Au bout de 5 ans, ils ne maitrisent que difficillement la syntaxe d'un ou de deux langages.<br /><br />Si la personne ne fait pas preuve de réflexion, d'apprentissage (lecture de livres, de blogs..) et de sociabilité (conférence, user group...), il restera dans une meconnaissance sidérante du métier de développeur.<br /><br />Voila en gros mon point de vue sur cette phrase. Qu'en penses tu ?Unknownhttps://www.blogger.com/profile/01521930817789457626noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-57574775666872185912010-12-01T02:50:50.110-08:002010-12-01T02:50:50.110-08:00Vu la vitesse d'évolution du monde de l'in...Vu la vitesse d'évolution du monde de l'informatique et des multi-compétences que nous devons acquérir, cette phrase semble logique et évidente. Si nous étions toujours prêt, où serait le challenge du dév ?Yannick AMEURhttps://www.blogger.com/profile/09262460932246495702noreply@blogger.comtag:blogger.com,1999:blog-479555891921312205.post-36692873070011509062010-11-29T12:00:26.380-08:002010-11-29T12:00:26.380-08:00"nous cherchons à répondre à la demande d'..."nous cherchons à répondre à la demande d'un client : est-ce que le résultat est correct ?"<br /><br />Voilà une question intéressante, qui débouche, entre autres, sur la question des tests.<br />Mon expérience sur le "model driven" est quasi-inexistante, mais il y a une chose que je n'arrive pas à visualiser : comment développer en "test driven", c'est à dire en commençant par écrire des tests exécutables, et apporter des réponses sous forme de code "model driven" aux tests qui ne passent pas encore ?Oazhttps://www.blogger.com/profile/04654282422215040284noreply@blogger.com