davidbgk
/
larlet-fr-david
Beobachten 1
Favorisieren 0
Fork 0
Code Releases 0 Aktivität
Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Du kannst nicht mehr als 25 Themen auswählen Themen müssen mit entweder einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.
240 Commits
1 Branch
Struktur: 7498a5adae
Branches Tags
${ item.name }
Erstelle Branch ${ searchTerm }
von „7498a5adae“
${ noResults }
larlet-fr-david/david/biologeek/archives/20071030-le-futur-du-develo.../index.html

index.html 56KB
Originalformat Blame Verlauf

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648 
  1. <!doctype html>

  2. <html lang=fr>

  3. <head>

  4.   <!-- Always define the charset before the title -->

  5.   <meta charset=utf-8>

  6.   <title>Le futur du développement logiciel — Biologeek — David Larlet</title>

  7.   <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->

  8.   <meta name="viewport" content="width=device-width, initial-scale=1"/>

  9.   <!-- Fake favicon, to avoid extra request to the server -->

  10.   <link rel="icon" href="data:;base64,iVBORw0KGgo=">

  11.   <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />

  12.   <link rel="manifest" href="/manifest.json">

  13.   

  14.   <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />

  15.   

  16.   <noscript>

  17.     <style type="text/css">

  18.       /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */

  19.       body {

  20.         font-family: 'EquityTextB', serif;

  21.       }

  22.       h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {

  23.         font-family: 'EquityCapsB', sans-serif;

  24.         font-variant: normal;

  25.       }

  26.     </style>

  27.   </noscript>

  28.   

  29.   <!-- Canonical URL for SEO purposes -->

  30.   <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20071030-le-futur-du-developpement-logiciel">

  31. 

  32. </head>

  33. <body>

  34.   <div>

  35.     

  36.     <header>

  37.       <nav>

  38.         <p>

  39.           <small>

  40.             Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.

  41.           </small>

  42.         </p>

  43.       </nav>

  44.     </header>

  45.     

  46.     

  47.   <section>

  48.     <h1 property="schema:name">Le futur du développement logiciel</h1>

  49.     <article typeof="schema:BlogPosting">

  50.       <div property="schema:articleBody">

  51.         <img src="/static/david/biologeek/images/logos/readwriteweb.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />

  52.         <p>Voici une traduction de l'article intitulé <a href="http://www.readwriteweb.com/archives/the_future_of_software_development.php">The Future of Software Development écrit par Alex Iskold et publié sur Read/WriteWeb</a> qui reprend les bases et qui va remotiver tous les développeurs qui me lisent ;-). Je manque de temps en ce moment pour publier mais il y a pas mal de choses en gestation qui devraient évoluer au cours de la semaine.</p>

  53. 

  54. <p>En 1975, Frederick Brooks a écrit un livre sur la gestion de projets informatiques intitulé <a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month">The Mythical Man-Month</a> (<a href="http://fr.wikipedia.org/wiki/Le_Mythe_du_mois-homme">le mythe du mois-homme</a>). Dans cet ouvrage, il démontre brillamment qu'ajouter des personnes à un projet de développement va le ralentir et non l'accélérer. La raison évoquée est qu'<strong>ajouter de nouvelles personnes induit une augmentation non linéaire du temps consacré à la communication</strong>.</p>

  55. 

  56. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/mythicalman-month-cover.jpg" alt="Couverture du livre &quot;Le mythe du mois-homme&quot;" style="display:block; margin:0 auto;" /></p>

  57. 

  58. <p>Cinq années avant le livre de Brooks, une méthodologie du développement logiciel appelée le <a href="http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement#Cycle_en_cascade">«&nbsp;cycle » en cascade</a> (<a href="http://en.wikipedia.org/wiki/Waterfall_model">Waterfall model</a>) est inventée. Cette approche applique les idées de l'ingénierie (mécanique, civile, etc) au logiciel. L'idée était de commencer par recueillir les spécifications, puis faire le design, puis l'implémenter, enfin le tester, et finalement obtenir un logiciel de manière linéaire.</p>

  59. 

  60. <p>Il a coulé beaucoup d'eau sous les ponts depuis et nous avons beaucoup appris dans le développement logiciel. Le modèle en cascade est maintenant désuet car il est trop rigide et irréalisable. <strong>Dans la vraie vie, les projets de logiciels sont mal définis et ont des fonctionnalités en constante évolution, ce qui ne permet pas de tout envisager dès le départ</strong>. Les meilleurs logiciels sont aujourd'hui développés et entretenus grâce à des méthodes agiles. Ces techniques permettent aux ingénieurs de réajuster constamment le logiciel en fonction du marché et des exigences des clients.</p>

  61. 

  62. <p>Avec l'avènement des langages de programmation modernes (Java, PHP, Python et Ruby), les nombreuses bibliothèques et un nombre sans précédent d'infrastructures de services comme Amazon, nous sommes arrivés à un nouveau pallier de l'évolution. Digg, del.icio.us, YouTube et les autres sont les enfants d'une nouvelle ère du web développée par une poignée de développeurs. Pour concevoir un logiciel aujourd'hui, vous n'avez besoin que de quelques bons développeurs. Dans cet article, nous retraçons l'historique de cette évolution et analysons les possibilités futures.</p>

  63. 

  64. <h2>Pourquoi le modèle en cascade a-t-il échoué&nbsp;?</h2>

  65. 

  66. <p>Les néophytes pensent qu'une application est facilement modifiable. Comme ça reste relativement abstrait, les gens pensent que les logiciels peuvent être paramétrés et mis à jour en un claquement de doigts. <strong>Bien évidemment, ce n'est pas le cas</strong>. La conception, comme tout système mécanique, a un design et une structure&nbsp;; ce n'est pas aussi simple que ça en a l'air.</p>

  67. 

  68. <p>Depuis toujours, l'accélération de l'économie requiert des modifications constantes des logiciels. Les anciennes méthodes de développement ne sont plus du tout adaptées au marché actuel. Lorsque l'on utilise le modèle en cascade, ces modifications sont impossibles, le cycle de développement est trop long, les logiciels sont des usines à gaz et finissent par coûter une fortune, pour le plus souvent ne pas fonctionner correctement au final.</p>

  69. 

  70. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/waterfalldevmodel.jpg" alt="Le modèle de développement en cascade" style="display:block; margin:0 auto;" /></p>

  71. 

  72. <p>Le problème c'est que le modèle en cascade est arrogant. L'arrogance vient du fait que nous pensions pouvoir concevoir l'application parfaite au premier essai. Le second problème, c'est que la vie d'un projet logiciel suit une évolution non linéaire. C'est en partant de ce constat que l'on s'est tourné vers les méthodes agiles de développement.</p>

  73. 

  74. <h2>Les méthodes agiles ou l'évolution des logiciels</h2>

  75. 

  76. <p>Au début des années 90, un bon nombre de <a href="http://fr.wikipedia.org/wiki/M%C3%A9thode_agile">méthodes de développement agiles</a> ont vu le jour. Bien qu'elles diffèrent dans le détail, elles amorcent une réflexion profonde sur la manière dont doit être mené un projet de développement. Tout d'abord, les développements doivent être réactifs aux changements. Les besoins d'aujourd'hui peuvent évoluer, et l'industrie logicielle doit pouvoir répondre à une telle évolution. Pour y parvenir, <strong>les promoteurs de telles méthodes prônent le retour à la simplicité. Concevoir aujourd'hui un système simple qui satisfait les besoins actuels et prêt à s'adapter en fonction des exigences de demain</strong>.</p>

  77. 

  78. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/agiledevelopment-overview.jpg" alt="Les principes du développement agile" style="display:block; margin:0 auto;" /></p>

  79. 

  80. <p>Deux techniques, initiées par les méthodes agiles, doivent être prises en considération&nbsp;: <strong>la généricité</strong> et <strong>les tests</strong>. La généricité, élégamment décrite par Martin Fowler dans <a href="http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672">son grand classique</a> est l'idée d'améliorer le design du code actuel sans en changer le résultat.</p>

  81. 

  82. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/refactoring-movefeature.jpg" alt="Déplacement de fonctionnalité pour gagner en généricité" style="display:block; margin:0 auto;" /></p>

  83. 

  84. <p>La généricité est ce qui permet aux systèmes agiles d'être évolutifs, tout en restant élégants. Tout comme un décorateur d'intérieur change constamment celui-ci et améliore votre vie quotidienne, les développeurs agiles agissent sur le cœur de l'application de façon à en améliorer la qualité globale. Le code est en constante mutation de façon à obtenir en définitive le plus simple et le meilleur système adapté aux besoins.</p>

  85. 

  86. <p>Pour s'assurer de la non-incidence de ces changements perpétuels sur le résultat final, les méthodes agiles ont introduit les tests unitaires. À chaque nouvelle extension du projet, la base de test grossit proportionnellement. Chaque test porte sur un unique composant du système et s'assure de la validité de son fonctionnement. Généralement, les tests sont lancés à chaque modification et requièrent une correction immédiate si un échec est signalé.</p>

  87. 

  88. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/unit-testing.jpg" alt="Les tests unitaires dans les méthodes agiles de développement" style="display:block; margin:0 auto;" /></p>

  89. 

  90. <p><strong>Les systèmes conçus à l'aide de méthodes agiles ont davantage de chances de réussir car ils sont évolutifs et adaptés au problème</strong>. Comme des organismes vivants, ces systèmes sont continuellement refaçonnés afin de s'adapter aux contraintes. Aucun doute là-dessus, les méthodes agiles ont eu un impact majeur sur notre manière de concevoir un logiciel aujourd'hui&nbsp;: dynamiquement et de manière continue.</p>

  91. 

  92. <h2>L'utilisation des bibliothèques</h2>

  93. 

  94. <p>Parallèlement à la découverte de nouvelles méthodes de développement, de meilleurs langages de programmation sont arrivés à maturité. C a été remplacé par C++, puis vint Java. Perl était génial, mais PHP et Python on su tirer parti de ses erreurs. Plus récemment est apparu Ruby, qui est devenu très populaire grâce à sa manière expressive de déclarer le code. En raison de cette évolution, nous disposons aujourd'hui de nombreux langages excellents et virtuellement équivalents. <em>(<abbr title="Note du Traducteur">NdT</abbr>&nbsp;: je ne suis pas vraiment d'accord avec ce paragraphe mais les langages et les éditeurs, ça ne se discute pas...)</em></p>

  95. 

  96. <p>Alors que le choix du langage de programmation est un sujet sensible, en fait ça ne dépend pas à proprement parler du langage mais des bibliothèques qui font la différence. C++ n'aura jamais la bibliothèque standard que détient Java. Oui Java est le langage le plus simple mais les gens utilisent C++ depuis une décennie sans problème. Ce qui avantage Java, c'est la richesse de ses bibliothèques réutilisables. Et c'est la même chose pour PHP. Il a été le langage de prédilection des développeurs web grâce à ses bibliothèques dédiées au web et aux interactions avec les bases de données.</p>

  97. 

  98. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/toolbox.jpg" alt="Les bibliothèques, véritables boîtes à outils du développeur" style="display:block; margin:0 auto;" /></p>

  99. 

  100. <p>En plus des bibliothèques accompagnant ces langages modernes, le mouvement open source a aussi contribué énormément à l'infrastructure de développement logiciel. La fondation Apache a elle seule a produit énormément de briques réutilisables de grande qualité. <strong>Nous arrivons à une période où nous disposons des fondations solides pour bâtir des systèmes complexes</strong>. Nous avons les méthodes et les outils, et après&nbsp;?</p>

  101. 

  102. <h2>Le futur du développement logiciel&nbsp;: les petites équipes</h2>

  103. 

  104. <p>Depuis les débuts du développement logiciel, les gens s'excriment afin de déterminer comment concevoir de bons systèmes le plus rapidement possible. De plus en plus de personnes se sont mises à plancher sur le problème, ne faisant qu'empirer les choses. Mais avec la récente explosion des applications web sociales nous avons assisté à la naissance d'un intéressant phénomène&nbsp;: <strong>une poignée de développeurs est maintenant capable de bâtir des systèmes utilisés par des millions d'utilisateurs. Comment est-ce possible ?</strong></p>

  105. 

  106. <p>Le secret vient du fait qu'il ne faut que quelques hommes pour accomplir des tâches ardues. Avec un peu de discipline et une tonne de passion, de bons ingénieurs sont en mesure de concevoir des systèmes d'une grande complexité.</p>

  107. 

  108. <p>Équipés d'un langage de programmation moderne, de bonnes bibliothèques et de méthodes agiles, quelques développeurs intelligents dans leur garage arrivent tout simplement à faire beaucoup plus qu'une armée de développeurs médiocres.</p>

  109. 

  110. <p><img src="/static/david/biologeek/images/futur_developpement_logiciel/nextgenengineering.jpg" alt="La prochaîne génération de développeurs" style="display:block; margin:0 auto;" /></p>

  111. 

  112. <p>Nous allons assister à des changements au cours des prochaines années&nbsp;:</p>

  113. 

  114. <ul>

  115. <li><strong>Les ingénieurs qualifiés et passionnés vont être très demandés et vont gagner beaucoup plus</strong>. <em><abbr title="Note du Traducteur">NdT</abbr>&nbsp;: comment ne pas être d'accord ?! ;-)</em></li>

  116. <li>Les développeurs qui n'ont pas des qualités de programmeur avérées vont devoir se recycler.</li>

  117. <li>Les changements qui sont en train de s'opérer dans le domaine des applications sociales va gagner le monde de l'entreprise.</li>

  118. <li>La délocalisation du développement va devenir désuette.</li>

  119. <li>L'informatique va devenir un domaine compétitif et prestigieux.</li>

  120. </ul>

  121. 

  122. <h2>Conclusion</h2>

  123. 

  124. <p>Ironiquement, on a fait le tour avec le mythe du mois-homme. Ce qui était vrai 20 ans auparavant est toujours vrai, mais pour d'autres raisons. <strong>Un environnement exceptionnel regroupant des langages et des bibliothèques combinés à des méthodes de développement agiles ont permis de briser les dogmes anciens du développement logiciel</strong>. Une poignée de bons développeurs peut dorénavant concevoir des systèmes d'une grande complexité. L'homme des cavernes est finalement arrivé jusqu'au développement logiciel&nbsp;!</p>

  125.       </div>

  126.     </article>

  127.     <footer>

  128.       <h6 property="schema:datePublished">— 30/10/2007</h6>

  129.     </footer>

  130.   </section>

  131.   <section>

  132.     <div>

  133.       <h3>Articles peut-être en rapport</h3>

  134.       <ul>

  135.         <li><a href="/david/biologeek/archives/20120131-resolutions-rediriger-economiser-et-debattre/" title="Accès à ★ Résolutions : rediriger, économiser et débattre">★ Résolutions : rediriger, économiser et débattre</a></li>

  136.         <li><a href="/david/biologeek/archives/20110112-resolutions-decouvrir-concretiser-et-transmettre/" title="Accès à ★ Résolutions : découvrir, concrétiser et transmettre">★ Résolutions : découvrir, concrétiser et transmettre</a></li>

  137.         <li><a href="/david/biologeek/archives/20090102-bilan-apres-une-annee-de-freelance/" title="Accès à ★ Bilan après une année de freelance">★ Bilan après une année de freelance</a></li>

  138.       </ul>

  139.     </div>

  140.   </section>

  141.   <section>

  142.     <div id="comments">

  143.       <h3>Commentaires</h3>

  144.       

  145. <div class="comment" typeof="schema:UserComments">

  146.     <p class="comment-meta">

  147.         <span class="comment-author" property="schema:creator">NiCoS</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  148.     </p>

  149.     <div class="comment-content" property="schema:commentText">

  150.         <p>Ouais, enfin le modèle en cascade a encore de beaux jours devant lui. Suffit de faire une mission chez un &quot;grand compte&quot; pour s'en apercevoir. Leurs tentatives pour devenir agile ne font que souligner leur inertie et la lourdeur de leur structure (sans parler de la résistance au changement). Dans certaines SSII, c'est encore vrai aussi. Ce n'est pas évident de mettre un projet en mode &quot;agile&quot; :-/ <br />

  151. <br />

  152. Certaines personnes voient même ça comme une faiblesse du prestataire à faire des jolies specs &amp; co :-(<br />

  153. <br />

  154. A l'inverse, certains prennent les méthodes agiles comme un moyen de se débarasser des specs et de naviguer à vue (par temps de brouillard) sur un projet. Faut faire aussi attention à cet écueil là.<br />

  155. <br />

  156. Sinon, sur le fond, je suis d'accord :-)<br />

  157. <br />

  158. ++<br />

  159. NiCoS, en plein projet cascade :-((((</p>

  160.     </div>

  161. </div>

  162. <div class="comment" typeof="schema:UserComments">

  163.     <p class="comment-meta">

  164.         <span class="comment-author" property="schema:creator">Earered</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  165.     </p>

  166.     <div class="comment-content" property="schema:commentText">

  167.         <p>hmrf, une analogie de mon pôpa (dans le médical), c'est que l'informatique est comparable au médical dans le nombre de domaine qu'il couvre réellement.<br />

  168. <br />

  169. De la même façon qu'il n'y a pas grand chose à voir entre un proctologue et un dentiste, il n'y a pas grand chose à voir entre le développement du logiciel controlant la ligne 14 à Paris et celui d'une page web.<br />

  170. <br />

  171. Donc oui, rajouté une personne sur un projet de 6 mois avec 3 personnes ne va pas faire grand chose de bien.<br />

  172. Mais en former 15 pendant 6 mois, par groupe, avec 3 personnes à plein temps pour former, sur un projets prévu à l'origine sur 2 ans avec 50 personnes aura un effet radical (est ce que le temps consacré à la formation, sera rentabilisé par l'apport de main d'oeuvre supplémentaire, et est ce que les taches (séparation en couche de l'application) sont suffisament séparé pour que l'overhead de communication ne soit pas pénalisant par rapport au gain apporté par la main d'oeuvre).<br />

  173. <br />

  174. Et non, le C n'a pas disparu (sisi), le python, le java ne remplace pas le C, ils permentent d'autres choses. Un petit tour sur Gartner ou les offres d'emplois, ou les appels d'offres et résultat: pour le C ça n'a que peu bouger. Par contre, des langages de plus haut niveau permettent de faire d'autres choses (des jeux rapidement sur téléphone portable), mais ne remplace pas les compilateurs, ou la programmation des générateurs de compilateur (les tâches des anciens langage évolues). L'activité informatique a énormément grossi, de nouvelles choses sont apparus. Appuyé sur de bonnes bases bien adapté mais qui ne change pas rapidement.<br />

  175. <br />

  176. L'informatique évolue peu au sens biologique (ou en fait si, dans le sens ou il y a toujours des requins, mais maintenant il y a aussi des dauphin, mais pas dans le sens ou les espèces précédent le dauphin disparaisse). Elle aurait plutôt tendance à créer de nouvelles branches. vi existe toujours (légèrement évolué en vim), et probablement autant utilisé aujourd'hui qu'il y a 10 ans. Eclipse n'existait pas.<br />

  177. <br />

  178. En conclusion, le texte m'a titillé dans le mauvais sens du poil sur certains termes, et sur un certain optimisme, mais ça n'enlève rien à l'intéret des nouveauté (automatisation et formalisation des tests, développement de composant isolé de façon à ne pas préjugé des évolutions futurs, mais là on est dans le domaine de la conception/ingénierie logiciel plus vraiment dans une histoire de cycle de développement) :p<br />

  179. <br />

  180. P.S. pour les bibliothèques, je me demande si ça n'est pas plutôt une évolution de l'ingénierie juridique qui les rends  et moins couteuse (licence libre), et que du coup des produits (logiciel) qu'il n'aurait pas été rentable de créer appraisse maintenant et le son (et enrechisse le domaine, mais ça  semble normal quel que soit le domaine).</p>

  181.     </div>

  182. </div>

  183. <div class="comment" typeof="schema:UserComments">

  184.     <p class="comment-meta">

  185.         <span class="comment-author" property="schema:creator">omic</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  186.     </p>

  187.     <div class="comment-content" property="schema:commentText">

  188.         <p>Lecture très intéressante. Merci pour ce résumé de qualité. :o)</p>

  189.     </div>

  190. </div>

  191. <div class="comment" typeof="schema:UserComments">

  192.     <p class="comment-meta">

  193.         <span class="comment-author" property="schema:creator">neolao</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  194.     </p>

  195.     <div class="comment-content" property="schema:commentText">

  196.         <p>très bon article<br />

  197. <br />

  198. je pense également que le domaine va devenir plus compétitif<br />

  199. c'est fini les petits dev</p>

  200.     </div>

  201. </div>

  202. <div class="comment" typeof="schema:UserComments">

  203.     <p class="comment-meta">

  204.         <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  205.     </p>

  206.     <div class="comment-content" property="schema:commentText">

  207.         <p>Je commente l'article, pas le traducteur :-D<br />

  208. Et je pars en hors-sujet aussi, j'aime bien polluer ici :-D<br />

  209. <br />

  210. &quot;Les meilleurs logiciels sont aujourd'hui développés et entretenus grâce à des méthodes agiles.&quot;<br />

  211. <br />

  212. Houlà. Si ça ça n'est pas du retrofitting ! Ou alors c'est considérer que tout ce qui n'est pas cycle en V (ou waterfall, ce qui est quasi identique) est agile : on en est loin. Et ensuite, le meilleur logiciel est inconnu de l'immense majorité des gens. En même temps, il faut prendre le terme de logiciel dans le contexte du blog Read/WriteWeb, c'est-à-dire de manière assez restreinte.<br />

  213. <br />

  214. &quot;Ironiquement, on a fait le tour avec le mythe du mois-homme. Ce qui était vrai 20 ans auparavant est toujours vrai, mais pour d'autres raisons.Les ingénieurs qualifiés et passionnés vont être très demandés et vont gagner beaucoup plus.&quot; <br />

  215. <br />

  216. Et ta soeur ?<br />

  217. <br />

  218. &quot;Ironiquement, on a fait le tour avec le mythe du mois-homme. Ce qui était vrai 20 ans auparavant est toujours vrai, mais pour d'autres raisons. Un environnement exceptionnel regroupant des langages et des bibliothèques combinés à des méthodes de développement agiles ont permis de briser les dogmes anciens du développement logiciel.&quot;<br />

  219. <br />

  220. Rappelons que le Mythe du mois-homme est basé sur l'expérience de Brooks dans le développement d'OS/360, et qu'on souhaite beaucoup de courage au prochain qui voudra développer quelque chose de la même ampleur avec des méthodes agiles ; la première étape consiste à trouver le client pour lui demander tous les 15 jours : &quot;et là, pour avoir l'aide en ligne de commande, vous préférez /h, -h, /? ou -? ? Ou on peut le faire de manière totalement dynamique ! C'est agile, c'est fou !&quot;. Bref. là où cet article est trompeur, comme une palanquée de la Liturgie Agile, c'est qu'il est basé sur le dogme suivant : il n'y a pas complexité irréductible. (Et cette idée est d'ailleurs discutée dans le livre de Brooks).<br />

  221. <br />

  222. Et on retrouve là le palimpseste du web, le même que celui qui a fait disparaître les Community Management System de l'histoire des systèmes de publication. Il suffit pour cela de remplacer &quot;Méthodes agiles&quot; dans l'article par L4G. L'environnement exceptionnel c'est le L4G. La poignée de développeurs expérimentées qui claquent un ERP en trois semaines ? C'est grâce aux L4G. Les modifications en permanence à faible coût ? L4G toujours.<br />

  223. Alors, pourquoi ne parle-t-on plus des L4G ? Qu'est-ce-qui dans ces Méthodes Agiles n'était pas déjà promis par les L4G ?<br />

  224. <br />

  225. Ce qui nous amène au titre :<br />

  226. &quot;Le futur du développement logiciel&quot;<br />

  227. <br />

  228. Houlà. On a presque eu une info... &quot;Le mythe du mois homme&quot; : 1975, &quot;No Silver Bullet&quot; : 1986, &quot;Le mythe du mois édition anniversaire&quot; : 1995, &quot;Extreme Programming Explained: Embrace Change&quot; : 1999. Pour le futur, on repassera :-D<br />

  229. </p>

  230.     </div>

  231. </div>

  232. <div class="comment" typeof="schema:UserComments">

  233.     <p class="comment-meta">

  234.         <span class="comment-author" property="schema:creator">zyegfryed</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  235.     </p>

  236.     <div class="comment-content" property="schema:commentText">

  237.         <p>Salut,<br />

  238. Merci pour cet (traduction d') article ! C'est rafraichissant et motivant !<br />

  239. J'accompagne l'auteur dans ses pensées quant à notre manière de travailler actuelle et future. Vivement l'avènement des petites équipes de développeurs passionnés et passionnants grâce auxquels on apprend autant que se que l'on peut échanger. Bref, la culture open source au boulot c'est pour quand ? :)<br />

  240. Seb</p>

  241.     </div>

  242. </div>

  243. <div class="comment" typeof="schema:UserComments">

  244.     <p class="comment-meta">

  245.         <span class="comment-author" property="schema:creator">kib</span> le <span class="comment-date" property="schema:commentTime">30/10/2007</span> :

  246.     </p>

  247.     <div class="comment-content" property="schema:commentText">

  248.         <p>&gt;&gt;ajouter de nouvelles personnes induit une augmentation non linéaire du temps consacré à la communication<br />

  249. <br />

  250. Il faudrait alors préciser le terme &quot;non linéaire&quot;, il y a plein de choses qui ne le sont pas. Et on peut très bien ne pas l'être et s'en approcher de très près.<br />

  251. En tout cas, développer seul est très long et on aimerait parfois avoir de l'aide, ça c'est certain.<br />

  252. <br />

  253. &gt;&gt;Juste en dessous de l'image avec le bouquin : &quot;recueillir les spécification&quot;&lt;--- ton prof de Français ne serait pas content, tu me le copieras dix fois :)<br />

  254. <br />

  255. Quand à la conception, on est tous d'accord là dessus : qui voudrait d'un logiciel non extensible de nos jours ? Ces petits &quot;plugins&quot; rendent bien service et s'adaptent à nos besoins, même si on fini par en abuser souvent (tiens par exemple, combien d'extensions FireFox possédez-vous ?). Ils sont cependant beaucoup plus difficiles à mettre en place en pratique, le système doit être simple à manipuler pour le quidam moyen.<br />

  256. <br />

  257. La généricité et le développement par les tests ont faits leur preuve : ce sont d'excellents outils.<br />

  258. <br />

  259. &gt;&gt;nous disposons aujourd'hui de nombreux langages excellents et virtuellement équivalents<br />

  260. <br />

  261. Oui, 'virtuelement' en effet.<br />

  262. <br />

  263. Quant aux bibliothèques des langages, elles sont à la fois un atout mais aussi une faiblesse: Java a une bien jolie API (certainement la plus fournie), mais qui n'en a jamais eû peur à première vue ? Perso, je préfère une bibliothèque standard bien moins élaborée, mais dans laquelle je me retrouve.<br />

  264. <br />

  265. &gt;&gt;Les ingénieurs qualifiés et passionnés vont être très demandés et vont gagner beaucoup plus.<br />

  266. <br />

  267. Si ça pouvait être vrai...<br />

  268. <br />

  269. &gt;&gt;La délocalisation du développement va devenir désuette.<br />

  270. <br />

  271. Ah ? Tu veux dire par là qu'on pourra bientôt rivaliser avec des développeurs Indous chez nous ? Ca me paraît difficile à croire : <br />

  272. 1. Ils sont pour la plupart passionnés et ont un niveau technique vraiment très élevé;<br />

  273. 2. Ils ne sont pas très chers (et moins exigeants sur les contrats) comparé à un développeur moyen Européen.<br />

  274. <br />

  275. Dans dix ans tu pourras certainement réécrire le même billet concernant les méthodes d'aujourd'hui : on croît toujours détenir la vérité à l'instant t, à t+1 on s'aperçoit là encore que le monde n'évolue pas de façon linéaire...et on remet ça !<br />

  276. <br />

  277. Beau billet, @ +.<br />

  278. <br />

  279. <br />

  280. <br />

  281. <br />

  282. <br />

  283. <br />

  284. <br />

  285. </p>

  286.     </div>

  287. </div>

  288. <div class="comment" typeof="schema:UserComments">

  289.     <p class="comment-meta">

  290.         <span class="comment-author" property="schema:creator">Arnaud</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  291.     </p>

  292.     <div class="comment-content" property="schema:commentText">

  293.         <p>Bonjour,<br />

  294. <br />

  295. Merci pour cet article intéressant.<br />

  296. <br />

  297. Je me pose certaines questions à propos de l'Agile développement tant acclamé dans les pays occidentaux.<br />

  298. <br />

  299. Je ne renie pas le fait que d'avoir une poignée de gens motivés et de nombreux échanges avec le client final permettent d'avoir un logiciel mieux adapté aux exigences en étant de très bonne qualité.<br />

  300. <br />

  301. J’ai  juste l’impression que les ingénieurs et développeurs occidentaux tentent par tous les moyens de justifier l’importance de leur travail de proximité avec le client final. Ceci fermant directement la porte à la production dans des centres Offshores en Asie ou autres. <br />

  302. <br />

  303. Le développement Agile semble être ce bouclier idéal contre la mondialisation courante, sans parler de l’argumentaire Marketing indéniable.<br />

  304. -	On parle beaucoup d’Agile (comme le Java à l’époque)<br />

  305. -	Lire les 12 principes généraux de L’Agile développement dans WIKIPEDIA laissent penser que le client est vraiment  ROI, ça fait peur…<br />

  306. <br />

  307. Par ailleurs le client final ne dispose pas toujours des moyens et de la compréhension nécessaire du monde de la systématisation. L’échange direct et rapide avec les développeurs peut tourner à la catastrophe.<br />

  308. <br />

  309. Je pense que la bonne méthode se situe entre les deux:  une analyse stricte et relativement cadenassée avec de la flexibilité lors de certaines phases du développement et les batteries de tests unitaires en support. <br />

  310. <br />

  311. Qu’en pensez-vous ?<br />

  312. </p>

  313.     </div>

  314. </div>

  315. <div class="comment" typeof="schema:UserComments">

  316.     <p class="comment-meta">

  317.         <span class="comment-author" property="schema:creator">Aguillem</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  318.     </p>

  319.     <div class="comment-content" property="schema:commentText">

  320.         <p>Bonne traduction.. merci bien ;)<br />

  321. Bon moi je ne vais pas faire un commentaire aussi long que l'article ;) mais je pense aussi que les méthodes agiles sont un bon moyen d'avancer, a condition de les utiliser avec parcimonie et non pas bêtement.<br />

  322. Par contre, avant que le développement en cascade soit mort... on a le temps. Comme dit dans un commentaire plus haut, les grands comptes fonctionnent encore beaucoup comme ça et ça c'est très dur à faire bouger...</p>

  323.     </div>

  324. </div>

  325. <div class="comment" typeof="schema:UserComments">

  326.     <p class="comment-meta">

  327.         <span class="comment-author" property="schema:creator">giz404</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  328.     </p>

  329.     <div class="comment-content" property="schema:commentText">

  330.         <p>Merci pour cette traduction ! Ca faisait longtemps que ça n'avait pas bougé par ici, mais ce retour en fanfare en vaut la peine !<br />

  331. <br />

  332. @Nicos : &quot;Certaines personnes voient même ça comme une faiblesse du prestataire à faire des jolies specs &amp; co :-( &quot;<br />

  333. <br />

  334. Complètement !! J'étais dans ce cas pendant 2 ans, ou on faisait du développement &quot;agile&quot; comme Monsieur Jourdain fait de la prose.<br />

  335. Rachetés et fusionnés avec une autre boite, on s'est retrouvé à devoir adopter des méthodes et procédures qui nous ralentissaient plus qu'autre chose sans améliorer la qualité des applications produites... <br />

  336. <br />

  337. De façon plus générale, je suis assez d'accord avec ce qui est dit dans l'article et j'ai déjà pu voir au cours de ma maigre expérience les 2 modèles d'organisation dans le développement logiciel :<br />

  338. - le développement &quot;à l'ancienne&quot; avec définition très précise du besoin, procédures, specs etc, puis développement bête et méchant à partir de ces specs par des équipes délocalisées pour gagner de l'argent. Ce modèle fonctionnera bien sur des grosses applis à la mise à jour peu fréquente.<br />

  339. <br />

  340. - le développement agile : petites équipes composées de gens brillants et motivés, (et bien payés pour entretenir leur motivation). Cette organisation sera réservée aux projets sujets à changements fréquents (applications web en particulier)<br />

  341. <br />

  342. Clairement, le modèle &quot;agile&quot; est plus attirant pour les passionnés. Les personnes qui développent dans un seul but &quot;alimentaire&quot; trouveront leur compte dans une entreprise organisée à l'ancienne, mais n'auront pas leur place dans un process de développement agile où il faut être technologiquement à la pointe, créatif dans son approche et ses solutions.<br />

  343. <br />

  344. Alors le développement agile, le futur ? Oui, mais pas pour tout le monde...<br />

  345. <br />

  346. </p>

  347.     </div>

  348. </div>

  349. <div class="comment" typeof="schema:UserComments">

  350.     <p class="comment-meta">

  351.         <span class="comment-author" property="schema:creator">Christian Fauré</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  352.     </p>

  353.     <div class="comment-content" property="schema:commentText">

  354.         <p>On peut peut-être distinguer deux situations :<br />

  355. - on développe pour un client<br />

  356. - on développe en interne (comunauté open source, editeur de logiciel ou développement pour le web)<br />

  357. <br />

  358. Dans le deuxième cas le développement agile peut beaucoup apporter. Peut-être moins dans le deuxième cas, car cela suppose un &quot;client agile&quot;.</p>

  359.     </div>

  360. </div>

  361. <div class="comment" typeof="schema:UserComments">

  362.     <p class="comment-meta">

  363.         <span class="comment-author" property="schema:creator">Grogro</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  364.     </p>

  365.     <div class="comment-content" property="schema:commentText">

  366.         <p>&gt;&gt; Les développeurs qui n'ont pas des qualités de programmeur avérées vont devoir se recycler.<br />

  367. <br />

  368. C'est quoi un développeur avec des qualités avérées de programmeur ? un fantasme ?<br />

  369. <br />

  370. &gt;&gt; Les changements qui sont en train de s'opérer dans le domaine des applications sociales va gagner le monde de l'entreprise.<br />

  371. <br />

  372. &gt;&gt; La délocalisation du développement va devenir désuette.<br />

  373. <br />

  374. ... quand le monde deviendra un grand village ou tous les hommes marcheront main dans la main libres et égaux en droit, tout ça grâce à la grande révolution technologique que nous préparent nos ingénieurs informaticiens (et développeurs avec des qualités avérées).<br />

  375. <br />

  376. <br />

  377. &gt;&gt; L'informatique va devenir un domaine compétitif et prestigieux.<br />

  378. <br />

  379. J'espère que non car je crains le pire avec de telles visions de l'avenir que nous préparent ces ingénieurs surdoués  ... un avenir pavé des meilleures intentions.<br />

  380. <br />

  381. Désolé, pas envie de contredire plus loin ce ticket pourtant intéressant au départ. J'aime le logiciel libre mais aussi la pensée libre, pas ce genre de discours indigeste et bon marché qui semble tout droit sorti d'une pub Microsoft ou Apple.</p>

  382.     </div>

  383. </div>

  384. <div class="comment" typeof="schema:UserComments">

  385.     <p class="comment-meta">

  386.         <span class="comment-author" property="schema:creator">Timothée</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  387.     </p>

  388.     <div class="comment-content" property="schema:commentText">

  389.         <p>Merci pour ce post.<br />

  390. <br />

  391. J'ai récemment fait une présentation des méthodes agiles dans ma boite pour tout un service, le concept est apprécié mais globalement tout le monde se dit c'est trop beau pour être appliqué.<br />

  392. <br />

  393. Pourtant, c'est vrai que c'est inévitable, l'économie et la société vont beaucoup trop vite pour que l'entreprise machin puisse aujourd'hui livrer une application et dire &quot;Allez, à dans 5ans pour en changer&quot;. Non ça n'est plus possible (enfin si dans les administrations et les 'grands comptes', mais ça devrait changer progressivement), surtout avec l'avènement des nouvelles technologies et ce qu'il est convenu d'appeler le web 2.0, qui habitue les utilisateurs à la version bêta permanente et à l'implication des utilisateurs (clients).<br />

  394. <br />

  395. Et puis avec des applications compliquées qu'on peut réaliser de plus en plus vite et simplement, ce n'est plus le système qui va devenir prédominant, mais le service rendu aux utilisateurs, d'où l'intérêt des méthodes agiles...<br />

  396. <br />

  397. </p>

  398.     </div>

  399. </div>

  400. <div class="comment" typeof="schema:UserComments">

  401.     <p class="comment-meta">

  402.         <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  403.     </p>

  404.     <div class="comment-content" property="schema:commentText">

  405.         <p>Wow, ça motive toutes ces réactions !<br />

  406. <br />

  407. Bon alors par où commencer... ah oui, déjà ces propos sont ceux de l'auteur et je n'en suis que le traducteur ce qui implique une traduction dans le respect du style de l'auteur et je ne suis pas forcément d'accord avec tout ce qui est écrit ici.<br />

  408. <br />

  409. L'avantage d'avoir des lecteurs de qualité c'est que vous avez déjà en grande partie détecté et corrigé les faiblesses de l'article :-).<br />

  410. <br />

  411. Mon commentaire sur les méthodes agiles (mais il faudrait un billet complet), c'est qu'en tant que développpeur c'est vraiment motivant et la motivation est une composante essentielle de la réussite d'un projet et de l'épanouissement personnel donc ça serait dommage de ne pas l'utiliser à bon escient.<br />

  412. <br />

  413. Après ce n'est pas la réponse à tout non plus mais dans l'état actuel c'est un de mes critères de choix. Le prochain billet devrait apporter un éclairage nouveau à ce commentaire mais j'en ai déjà trop dit.<br />

  414. <br />

  415. Pour répondre à quelques réactions particulières :<br />

  416. <br />

  417. @NiCoS : que les SSII aient du mal à être agiles est normal, ce n'est tout simplement pas dans leur intérêt car elles facturent à la journée et ensuite au résultat donc les projets qui traînent sont des vaches à lait. De plus, avec un développement agile les maintenances et les évolutions ne seraient pas assez facturées...<br />

  418. <br />

  419. @Earered : <br />

  420. <br />

  421. &gt; Mais en former 15 pendant 6 mois, par groupe, avec 3 personnes à plein temps pour former, sur un projets prévu à l'origine sur 2 ans avec 50 personnes aura un effet radical<br />

  422. <br />

  423. Le problème actuel en informatique c'est aussi le turn-over dû à la pénurie de développeurs. Dans un projet de cette envergure, au bout d'un an la moitié des formés auront probablement trouvé une place ailleurs. C'est une réalité qui ne s'applique pas au domaine médical.<br />

  424. <br />

  425. &gt; Et non, le C n'a pas disparu (sisi), le python, le java ne remplace pas le C, ils permentent d'autres choses.<br />

  426. <br />

  427. Je suis entièrement d'accord avec ça et j'ai d'ailleurs bondi en traduisant cette partie.<br />

  428. <br />

  429. (analogie et proctologue dans le même commentaire, c'est parti pour des referers douteux ;-))<br />

  430. <br />

  431. @neolao :<br />

  432. <br />

  433. &gt; c'est fini les petits dev<br />

  434. <br />

  435. Je ne suis pas d'accord, je pense qu'on s'oriente vers deux types de projets : ceux qui sont très spécialisés et qui vont permettre le développement de bibliothèques à forte valeur ajoutée et ceux qui vont être la glue entre ces bibliothèques. L'idéal étant que chacun de ces projets reste « petit » justement.<br />

  436. <br />

  437. @Damien B. :<br />

  438. <br />

  439. &gt; Et je pars en hors-sujet aussi, j'aime bien polluer ici :-D<br />

  440. <br />

  441. Fais toi plaisir, j'aime bien ta pollution :-).<br />

  442. <br />

  443. &gt; Pour le futur, on repassera :-D<br />

  444. <br />

  445. Les références sont anciennes mais malheureusement encore trop rarement appliquées... il n'y a qu'à voir certains commentaires de réaction ici-même.<br />

  446. <br />

  447. @zyegfryed :<br />

  448. <br />

  449. &gt; Bref, la culture open source au boulot c'est pour quand ? :)<br />

  450. <br />

  451. C'est pour quand TU veux, ça existe déjà !<br />

  452. <br />

  453. @kib:<br />

  454. <br />

  455. &gt; Il faudrait alors préciser le terme &quot;non linéaire&quot;<br />

  456. <br />

  457. Tiré de l'article de Wikipédia : Formule des canaux de communication : n(n − 1) / 2 (pour 50 informaticiens, on a 50(50 − 1) / 2 = 1225 canaux de communication).<br />

  458. <br />

  459. &gt; Quand à la conception, on est tous d'accord là dessus : qui voudrait d'un logiciel non extensible de nos jours ? Ces petits &quot;plugins&quot; rendent bien service et s'adaptent à nos besoins<br />

  460. <br />

  461. L'article ne parle pas des plugins mais bien de bibliothèques ce que je considère différemment, il ne s'agit pas de petits ajouts à l'appli actuelle mais bien de son cœur qui évolue de manière agile avec des unités fonctionnelles pouvant s'adapter aux changements.<br />

  462. <br />

  463. &gt; Ah ? Tu veux dire par là qu'on pourra bientôt rivaliser avec des développeurs Indous chez nous ?<br />

  464. <br />

  465. Non, si c'était ma prose je n'aurais pas sous-estimé la délocalisation. Dans les deux types de projets dont je parlais avec neolao plus haut, le premier peut justement être délocalisé. Maintenant la délocalisation nécessite de nouveau métiers du style chef de projet « amélioré » qui sont encore trop peu présents et qui conduisent à certains échecs qui peuvent refroidir. C'est encore une fois une problématique de communication.<br />

  466. <br />

  467. Maintenant on pourrait discuter de l'esclavage Nord-Sud moderne mais c'est un autre débat...<br />

  468. <br />

  469. &gt; on croît toujours détenir la vérité à l'instant t, à t+1 on s'aperçoit là encore que le monde n'évolue pas de façon linéaire...et on remet ça !<br />

  470. <br />

  471. N'est-ce pas l'un des intérêts de la vie ? Si l'informatique me plaît c'est justement aussi pour sa constante évolution. Être obligé de se remettre en question régulièrement est un de mes stimulants.<br />

  472. <br />

  473. @Arnaud :<br />

  474. <br />

  475. &gt; Le développement Agile semble être ce bouclier idéal contre la mondialisation courante, sans parler de l’argumentaire Marketing indéniable. [...] Qu’en pensez-vous ?<br />

  476. <br />

  477. Je pense que la proximité a encore de beaux jours devant elle et certaines entreprises un peu échaudées par les développements offshore y reviennent (je ne peux pas citer mes sources ici donc il faudra me croire sur parole). Pour moi l'informatique c'est du code mais c'est aussi tout ce qui gravite autour et qui compte pour beaucoup, nous ne sommes pas (encore) des robots !<br />

  478. <br />

  479. Cela étant dit, oui c'est un argument marketing mais c'est très difficile de faire changer les mentalités et les méthodologies donc le marketing est nécessaire et ne porte ses fruits qu'à long terme. Pour exemple, malgré une communication assez conséquente sur les standards du web, l'usage des css, etc que l'on pourrait qualifier de marketing, il reste de nombreux sites conçus sans en tenir compte aujourd'hui...<br />

  480. <br />

  481. @giz404 :<br />

  482. <br />

  483. &gt; Clairement, le modèle &quot;agile&quot; est plus attirant pour les passionnés. Les personnes qui développent dans un seul but &quot;alimentaire&quot; trouveront leur compte dans une entreprise organisée à l'ancienne, mais n'auront pas leur place dans un process de développement agile où il faut être technologiquement à la pointe, créatif dans son approche et ses solutions.<br />

  484. <br />

  485. Merci pour ce résumé :-).<br />

  486. <br />

  487. @Christian Fauré :<br />

  488. <br />

  489. &gt; cela suppose un &quot;client agile&quot;<br />

  490. <br />

  491. Tu mets le doigt là où ça fait mal, c'est effectivement la principale cause d'échec d'un développement agile (d'après ma propre expérience). Le client ne comprend pas forcément qu'il a une large part de responsabilité dans le développement qui va répondre à SON besoin. Cela présuppose donc une phase d'éducation du client qu'il ne faut pas sous-estimer.<br />

  492. <br />

  493. @Grogro :<br />

  494. <br />

  495. &gt; C'est quoi un développeur avec des qualités avérées de programmeur ? un fantasme ?<br />

  496. <br />

  497. Non, un CV gonflé car la personne a fait 3 lignes de PHP dans sa vie et que l'on est en pénurie d'informaticiens...<br />

  498. <br />

  499. &gt; J'aime le logiciel libre mais aussi la pensée libre, pas ce genre de discours indigeste et bon marché qui semble tout droit sorti d'une pub Microsoft ou Apple.<br />

  500. <br />

  501. Huhu. J'espère que tout ce que j'ai écrit ci-dessus te convaincra que le but de ce billet n'était pas de distribuer des œillères numériques mais bien d'ouvrir la discussion.<br />

  502. <br />

  503. @Timothée :<br />

  504. <br />

  505. &gt; Et puis avec des applications compliquées qu'on peut réaliser de plus en plus vite et simplement, ce n'est plus le système qui va devenir prédominant, mais le service rendu aux utilisateurs, d'où l'intérêt des méthodes agiles...<br />

  506. <br />

  507. Excellente conclusion.<br />

  508. </p>

  509.     </div>

  510. </div>

  511. <div class="comment" typeof="schema:UserComments">

  512.     <p class="comment-meta">

  513.         <span class="comment-author" property="schema:creator">Ploum</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  514.     </p>

  515.     <div class="comment-content" property="schema:commentText">

  516.         <p>Beaucoup de grandes boites se targuent de faire du dev agile dans certaines équipes : petite équipe, refactoring, test unitaires.<br />

  517. <br />

  518. ça, c'est la théorie. En pratique, c'est juste du modèle en cascade : l'équipe de 10 personnes embauche de plus en plus car elle prend du retard, le refactoring consiste à réécrire 15.000 fois un truc qui marche et à supprimer des features pour avoir au final des trucs incompréhensibles (des génériques de génériques de génériques de génériques... je n'exagère pas, exemple vécu), les tests unitaires datent de mathusalem et ne passent plus car on a changé un truc mais les tests sont en fait pas valides.<br />

  519. <br />

  520. Bref, faut pas se fier au nom.<br />

  521. <br />

  522. Aussi, je suis un gros opposant à la pseudo réutilisabilité. Dans 90% des cas, un programmeur va complexifier à mort son code pour pondre une classe &quot;réutilisable&quot; mais devenue incompréhensible et qui ne sera de toutes façons jamais réutilisées car la réutilisation nécéssite :<br />

  523. <br />

  524. 1) de savoir qu'on est le cas particulier d'un cas général déjà traité<br />

  525. 2) de savoir qu'une classe pour traiter notre cas général existe déjà<br />

  526. 3) de savoir où se trouve cette classe général<br />

  527. 4) de constater qu'on est bel et bien face à un cas général et pas à un refactoring bête du cas particulier du collègue<br />

  528. 5) d'apprendre à utiliser cette classe générale avec moins d'effort que de bêtement réécrire notre petit truc particulier<br />

  529. 6) de pouvoir utiliser notre cas général (dépendances différentes, infrastructure différente, ...)<br />

  530. 7) Ne pas avoir à modifier la moitié du projet pour pouvoir réutiliser une classe &quot;générale&quot; qui ne s'interface pas exactement avec notre projet actuel (je l'ai vu faire)<br />

  531. <br />

  532. Bref, en pratique, j'ai découvert que la réutilisabilité est une belle utopie mais que les programmeurs &quot;agiles&quot; en font un but et non plus un outil.</p>

  533.     </div>

  534. </div>

  535. <div class="comment" typeof="schema:UserComments">

  536.     <p class="comment-meta">

  537.         <span class="comment-author" property="schema:creator">grogro</span> le <span class="comment-date" property="schema:commentTime">31/10/2007</span> :

  538.     </p>

  539.     <div class="comment-content" property="schema:commentText">

  540.         <p>&gt;Huhu. J'espère que tout ce que j'ai écrit ci-dessus te convaincra que le but de ce billet n'était pas de distribuer des œillères numériques mais bien d'ouvrir la discussion.<br />

  541. <br />

  542. Oui presque convaincu, et aussi par d'autres articles publiés sur ce blog qui sont vraiment passionnants, l'offense est donc presque pardonnée ...  j'attends la suite pour confirmer ce &quot;presque&quot; ;-)</p>

  543.     </div>

  544. </div>

  545. <div class="comment" typeof="schema:UserComments">

  546.     <p class="comment-meta">

  547.         <span class="comment-author" property="schema:creator">loïc m.</span> le <span class="comment-date" property="schema:commentTime">05/11/2007</span> :

  548.     </p>

  549.     <div class="comment-content" property="schema:commentText">

  550.         <p>@David &amp; @Christian Fauré :<br />

  551. &gt; cela suppose un 'client agile' <br />

  552. <br />

  553. &gt; Tu mets le doigt là où ça fait mal, c'est effectivement la principale cause d'échec d'un développement agile (d'après ma propre expérience). Le client ne comprend pas forcément qu'il a une large part de responsabilité dans le développement qui va répondre à SON besoin. Cela présuppose donc une phase d'éducation du client qu'il ne faut pas sous-estimer.<br />

  554. <br />

  555. Par expérience personnelle, je ne peux que souligner ce point très important et bien difficile parfois suivant les clients.<br />

  556. Pas facile d'expliquer ces concepts à une personne qui ne connait rien au monde informatique...</p>

  557.     </div>

  558. </div>

  559. <div class="comment" typeof="schema:UserComments">

  560.     <p class="comment-meta">

  561.         <span class="comment-author" property="schema:creator">Bluebird</span> le <span class="comment-date" property="schema:commentTime">15/11/2007</span> :

  562.     </p>

  563.     <div class="comment-content" property="schema:commentText">

  564.         <p>@ploum:<br />

  565. <br />

  566. Sur la problématique de la généricité, il est à noter que les méthodes de développements agile sont de très grands fervents de la simplicité et par là même opposés à la généricité. La phrase la plus répétée dans le livre de Kent Beck est &quot;you ain't going to need it&quot; i.e. &quot;tu n'en auras pas besoin&quot;. <br />

  567. <br />

  568. L'approche agile encourage à faire le &quot;minimum qui marche&quot; et à valider par des tests. Si les besoins augmentent vers de la généricité, on la rajoutera après et on validera avec les tests existants mais elle reste régulièrement au placard parce que on remplit le besoin (les tests) sans l'avoir mise.<br />

  569. <br />

  570. L'approche par les tests (&quot;tests driven development&quot;) encourage ce côté simplicité puisque le besoin est défini par les tests et le développement se réduit à faire marcher les tests. Il y a moins de risque de dérive du genre &quot;ah ouais mais je rajoute juste un niveau d'indirection et deux trois méthodes&quot; puisque le test est le référentiel.<br />

  571. <br />

  572. Sinon, la blague des tests unitaires qui sont là mais qui ne marchent pas et qui n'ont jamais été maintenus est un classique.  <br />

  573. <br />

  574. Quand j'explique l'architecture technique et la démarche qualité de mon entreprise, beaucoup me disent &quot;mais on fait pareil&quot;. Ils font pareil sauf que les tests ont beaucoup de retard sur l'implémentation, que le code censé marcher sur trois plateformes différentes ne fonctionne que sur une seule, que les branches de développement se rajoutent sans se réutiliser (comprendre qu'il n'y a plus de branche principale du produit mais n produits dont aucun ne comprend toutes les fonctionnalités des autes), qui l'équipe X a fait telle modif mais ne l'as pas mise sous svn, etc etc.<br />

  575. <br />

  576. Faire du développement agile et plus généralement programmer avec qualité, c'est quand même un combat quotidien contre le &quot;oui je sais que c'est mal (de faire un gros copier colle, de ne pas réparer les tests, ...) mais j'ai pas le temps&quot;.<br />

  577. </p>

  578.     </div>

  579. </div>

  580. <div class="comment" typeof="schema:UserComments">

  581.     <p class="comment-meta">

  582.         <span class="comment-author" property="schema:creator">Gelono. Création logiciel</span> le <span class="comment-date" property="schema:commentTime">16/09/2008</span> :

  583.     </p>

  584.     <div class="comment-content" property="schema:commentText">

  585.         <p>J&#39;appartiens à une nouvelle entreprise (<a href="http://www.gelono.com%29qui">http://www.gelono.com)qui</a> fait du web mais aussi des dev pour l&#39;aéronautique. Nous nous efforçons d&#39;appliquer les méthodes de dernière génération pour garantir une efficacité et une réactivité maximale dans nos développements.<br />Merci pour l&#39;article.</p>

  586.     </div>

  587. </div>

  588. <div class="comment" typeof="schema:UserComments">

  589.     <p class="comment-meta">

  590.         <span class="comment-author" property="schema:creator">mehdi</span> le <span class="comment-date" property="schema:commentTime">14/10/2008</span> :

  591.     </p>

  592.     <div class="comment-content" property="schema:commentText">

  593.         <p>Les méthodes en cascade ne répondent plus à la réalité d’aujourd’hui, non seulement pour les clients externes, mais aussi internes.</p>

  594. 

  595. <p>L’adoption en soit, des méthodes agiles, n’est pas aussi la solution miracle, il faut savoir comment tirer profit de ces méthodes et comment les adapter a la réalité de notre entreprise/projet.</p>

  596. 

  597. <p>Le plus dur n’est pas de faire le pas vers les méthodes agiles, mais de choisir et d’adapter la bonne méthode au bon projet, toute les clés n’ouvrent pas toutes les portes, a nous de choisir la bonne clé qui correspond a notre porte, et ne pas hésiter à aiguiser la clé pour qu’elle glisse mieux.</p>

  598. 

  599. <p>Et je suis d’accord sur le fait,  qu’augmenter le nombre de développeurs dans un projet, n’accélérera pas les délais de ce dernier : « Il faut 1 femme et  9 mois pour faire un bébé, mais 9 femmes et 1 mois ne feront jamais un bébé  »</p>

  600.     </div>

  601. </div>

  602. <div class="comment" typeof="schema:UserComments">

  603.     <p class="comment-meta">

  604.         <span class="comment-author" property="schema:creator">Robert</span> le <span class="comment-date" property="schema:commentTime">03/11/2010</span> :

  605.     </p>

  606.     <div class="comment-content" property="schema:commentText">

  607.         <p>Je suis totalement d&#39;accord.</p>

  608. 

  609. <p>Comme tout projet, il suffit d&#39;un nombre restreint de développeurs pour amener à terme un logiciel. Il est évident que passer son temps à transmettre à d&#39;autres développeurs comment il faut implémenter le logiciel c&#39;est une perte de temps.</p>

  610. 

  611. <p>Et il ne faut pas oublier que les gens ont tendance à partir sur des structures complexes au lieu de partir sur des bases simples. Il ne faut pas qu&#39;un logiciel devienne aussi un produit qui fait la cuisine, le ménage et des calculs de simulation, mais seulement qu&#39;il exécute les tâches que l&#39;on veut effectuer avec, ce n&#39;est pas un fourre-tout.</p>

  612. 

  613. <p>Et je reviens sur le fait que pour travailler dans le développement, il y a 3 choses à valider : <br />-être passionné par le développement<br />-être terriblement structuré<br />-être plus cultivé que la moyenne (lire des livres, avoir l&#39;esprit ouvert, revenir à des activités manuelles, )<br />car j&#39;ai vu des gars développer des logiciels de simulation mécanique sans jamais avoir tenu dans leur vie un tournevis ou conduit une voiture, des vrais abru...!!</p>

  614.     </div>

  615. </div>

  616. <div class="comment" typeof="schema:UserComments">

  617.     <p class="comment-meta">

  618.         <span class="comment-author" property="schema:creator">stemlaur</span> le <span class="comment-date" property="schema:commentTime">24/12/2010</span> :

  619.     </p>

  620.     <div class="comment-content" property="schema:commentText">

  621.         <p>Chez Stemlaur Inc. © nous avons une vision un peu différente du développement dans le futur :</p>

  622. 

  623. <p><a href="http://stemlaur.com/blog/2010/11/03/developpeur-en-2030/">http://stemlaur.com/blog/2010/11/03/developpeur-en-2030/</a></p>

  624.     </div>

  625. </div>

  626. 

  627.     </div>

  628.   </section>

  629. 

  630.     

  631.     <footer>

  632.       <nav>

  633.         <p>

  634.           <small>

  635.             Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>

  636.           </small>

  637.         </p>

  638.       </nav>

  639.     </footer>

  640.     

  641.   </div>

  642.   

  643.   <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>

  644.   

  645.   <script data-no-instant>InstantClick.init()</script>

  646.   

  647. </body>

  648. </html>