tag:blogger.com,1999:blog-44752941403412674402024-03-13T00:08:04.542-04:00Agile 2009 ConferenceOur experience at the Agile 2009 conference in Chicago.Unknownnoreply@blogger.comBlogger33125tag:blogger.com,1999:blog-4475294140341267440.post-14334149967645770842009-09-21T10:00:00.001-04:002009-09-21T10:02:16.176-04:00Le banquetPour clore la conférence, un impressionnant banquet fut organisé. Durant le souper, Jared M. Spool nous a livré un discours digne des grands orateurs de ce monde. Une <a href="http://agile2009.agilealliance.org/keynotes">présentation </a>soignée avec trois grands objectifs à retenir : vision, feedback et culture.<br /><br />Pour la vision à long terme je vous invite à voir cette petite vidéo tournée en 1987.<br /><a title="http://www.theheretech.com/2009/08/apples-mistaken-mystique.html" href="http://www.theheretech.com/2009/08/apples-mistaken-mystique.html">http://www.theheretech.com/2009/08/apples-mistaken-mystique.html</a><br /><br />Pour ce qui est du feedback, je vous invite à lire mes derniers posts.<br /><br />Finalement, pour ce qui est de la culture, il faut apprendre de ses erreurs. Si personne de l’équipe n’a fait d’erreur depuis les dernières semaines, posez-vous des questions. Vous voulez un bon exemple, savez-vous comment déterminer le sexe d’un poussin? Les poussins male et femelle sont pratiquement identiques. Cependant, il existe des professionnels dont la tâche consiste à les différencier. Lorsqu’une personne commence ce métier, il a un taux de réussite autour de 50%. C’est seulement après plusieurs mois (voire des années) de pratique qu’ils finissent par obtenir un taux de réussite au dessus de 90%. Et pourtant, ils sont incapables de vous dire comment ils font. Est-ce vrai? Allez voir sur wikipedia : <a href="http://en.wikipedia.org/wiki/Chick_sexing">chicken sexing</a>.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-26905288666525238752009-09-21T09:59:00.000-04:002009-09-21T10:00:17.190-04:00L’approche ToyotaLa dernière présentation auquel j’ai assisté fut: <a href="http://agile2009.agilealliance.org/node/2440">Set-based Design: Anti-Agile or Agile’s Future?</a> Comment pouvons-nous établir une base solide tout en étant Agile? Il faut avoir une vision à long terme, une base solide. Cependant, il ne faut pas juste essayer une solution. Il faut commencer par ratisser large et réduire la zone. Plusieurs conférenciers nous ont dit qu’il faut faire des choix logiques pour l’entreprise. Il faut cibler quel produit nous donne les meilleurs retombées, séparer les gros produits en petits livrables et faire plus de tests, plus vite, plus tôt. J’ai l’impression d’avoir déjà écrit ça :-)<br /><br /><a href="http://fr.wikipedia.org/wiki/Principes_de_gestion_agile">Principe de gestion Agile</a><br /><br />Toyota s’est dit que s’ils produisent plus vite, ils auront du feedback plus rapidement. Ils pourront corriger leur produit plus tôt et ainsi produire encore plus vite.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-68643381998579209192009-09-21T09:55:00.001-04:002009-09-21T09:58:46.697-04:00CI Vendor Cape-Flight!Durant cette semaine de conférences, les sponsors et vendeurs sont très présent. Plusieurs d’entre eux offrent des outils ALM (<a href="http://en.wikipedia.org/wiki/Application_lifecycle_management">Application Lifecycle Management</a>) qui nous facilite l’intégration continue. (Continous Integration). Certain semble très intéressant mais il est difficile de les comparer sans les avoir utilisés. Alors, j’ai cru bon d’assister à cette présentation (<a href="http://agile2009.agilealliance.org/node/572">CI Vendor Cape-Flight!</a>) dans le but d’aider notre compagnie dans le choix de l’un de ces outils. Ce que je ne savais pas, c’est que nous avons déjà fait l’acquisition de Concerto. Pour les curieux, voici quand même quelque uns des autres produits :<br /> <a href="http://www.anthillpro.com/html/default.html">AntillPro</a><br /> <a href="http://www.openmakesoftware.com/meister-info/">Meister</a><br /> <a href="http://www.openmakesoftware.com/free-mojo/">Mojo</a><br /> <a href="http://www.viewtier.com/products/parabuild/index.htm">Parabuild</a><br /> <a href="https://hudson.dev.java.net/">Hudson</a><br /> <a href="http://www.atlassian.com/software/bamboo/">Bamboo</a><br /> <a href="http://www.microsoft.com/visualstudio/en-ca/default.mspx">Visual Studio Team System</a>FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com1tag:blogger.com,1999:blog-4475294140341267440.post-55894902928619211522009-09-18T10:16:00.001-04:002009-09-18T10:17:59.973-04:00Des requirements qui changent !Dans le domaine aéronautique, nos clients semble très <a href="http://en.wikipedia.org/wiki/Waterfall_model">Waterfall</a> ce qui nous restreint à l’interne, principalement avec les <em>requirements</em>. Cependant, dans le cas de mon département (et division), nos clients sont principalement deux autres divisions de notre compagnie. Nous aurions intérêt à plus souvent tenir compte de la rétroaction de nos clients et ainsi adapter certains <em>requirements</em> en fonction du <em>feedback</em> reçu. Les <em>requirements</em> devraient aussi être mieux associés aux différents issues (dans JIRA) et livrables (Package Repository).FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-34188453517121090782009-09-18T10:12:00.000-04:002009-09-18T10:15:10.933-04:00Continuous Integration: Your New Best FriendLe principe est simple, un changement au début du projet coûte moins cher qu’à la fin du projet. Donc, comment trouver un problème plus tôt : <a href="http://en.wikipedia.org/wiki/Continuous_integration">Continuous Integration</a>. Il y a 3 sortes de tests : via les <em>requirements</em>, via les <em>unit tests</em> et via l’interface usager. Il faut faire les 3 types de test en continu durant le développement. Nous allons ainsi réduire les coûts en réduisant les problèmes d’intégration de dernière minute.<br /><br />Lien sur la <a href="http://agile2009.agilealliance.org/node/161">présentation</a>.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-31765180390178953002009-09-18T10:08:00.001-04:002009-09-18T10:12:02.549-04:00Agile MetricsAvoir une bonne méthode de mesure est important pour la gestion afin de comprendre où nous sommes, connaitre le progrès de l’équipe et voir les projections futures.<br /><br />Dans ma compagnie, nous voulons migrer vers une méthode plus Agile. Est-ce vrai?<br /><br />La direction a implanté la méthode Scrum, probablement la méthode la plus populaire dans Agile. Nous l’utilisons de plus en plus et de mieux en mieux (sprints, backlog, metrics, meetings). Cependant, l’esprit Agile n’est pas là. J’ai l’impression que nous n’utilisons Scrum que pour les métriques, pour que la direction puisse mieux mesurer et avoir un business value associé aux produits software. Voici quelques exemples de pratiques que nous avons et qui ne sont pas Agile : nos requirements ne s’adaptent pas, les unit tests sont presque absents, la plupart des programmeurs travaille individuellement, le feedback du client n’est pas présent durant les sprints.<br /><br />Il faudrait se poser la question : Voulons-nous rester Scrum sans être Agile?<br /><br />La présentation, <a href="http://agile2009.agilealliance.org/node/248">Agile Metrics</a>, est disponible en <a href="http://agile2009.agilealliance.org/files/session_pdfs/Rawsthorne_AgileMetrics_v6d.pdf">pdf</a>.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-45081424993771051932009-09-18T10:03:00.001-04:002009-09-18T10:06:16.411-04:00Blitz PlanningImaginez un petit exemple très simple d’organisation matinale. Nous avons deux parents et deux enfants (un de 12ans et un bébé) et nous voulons organiser l’horaire : brossage de dents, faire les lits, réveil des enfants, déjeuner, lunch… L’exercice devient rapidement compliqué. Il faut prévoir qui peut faire quoi, quelle tâche dépend d’une autre, prévoir le temps… Le but est de prévoir et placer les tâches dans le bon ordre sans en bloquer une autre. De plus, il sera possible de prévoir un premier livrable le plus tôt possible et ainsi avoir un retour sur l’investissement le plus tôt possible. Cette <a href="http://agile2009.agilealliance.org/node/1690">présentation</a> nous démontre, par des exercices simples, les avantages de bien planifier afin d’obtenir le plus tôt possible les bénéfices qui en découle.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-34656529832774794182009-09-18T10:00:00.000-04:002009-09-18T10:02:32.167-04:00We Didn't Quite Get ItCette <a href="http://agile2009.agilealliance.org/node/2080">présentation</a> couvre les problèmes et solutions rencontrée par deux développeurs (<a href="http://agile2009.agilealliance.org/user/1507">Brian Victor</a> et <a href="http://agile2009.agilealliance.org/user/2651">Noah Jacobson</a>) qui implantent Agile dans leur petite compagnie sans avoir d’expérience avec Agile.<br /><br />Pour ceux que ça intéresse, je vous suggère ce lien : <a href="http://brianhv.org/temp/agilenotes/">http://brianhv.org/temp/agilenotes/</a><br /> Il y a quelques parallèles intéressants à faire, cependant il faut garder à l’esprit qu’il y a aussi des différences entre les 2 compagnies; entre autre la grosseur et le produit final (hardware & software).FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-89949926877843137802009-09-18T09:56:00.002-04:002009-09-18T10:08:03.500-04:00Activity Theory for Manifesting AgileAgile est probablement la méthode de travail la plus actuelle pour ce qui est de la programmation. Agile est vivant et comme toute chose vivante, ça continue à s’adapter, à évoluer. <a href="http://agile2009.agilealliance.org/user/20">Robert Biddle</a>, un professeur (<em>Human-Computer Interaction</em>) à l’université de Carleton à Ottawa, a développé un <em>framework</em> qui s’applique à Agile. Son <em>framework</em> qu’il qualifie de « <em>psychological framework</em> » sert à comprendre la collaboration et les tensions entre les personnes, les projets, les outils, le code… Son <em>framework</em> tient aussi compte qu’une personne n’est pas uniquement impliquée dans une seule activité (travail, famille, projets…), tout en incluant les groupes et les règles. Il est possible d’étendre son <em>framework</em> pour tenir compte des autres systèmes autour : client, département, fournisseurs… Son <em>framework</em> peu ainsi servir à comprendre et améliorer le développement software qui est agile.<br /><a href="http://2.bp.blogspot.com/_9GhISPdzIes/SrOSGYsHWGI/AAAAAAAAAA8/7HpH6zlMu7k/s1600-h/ActTheoryForManifestingAgile.JPG"><img id="BLOGGER_PHOTO_ID_5382806618042226786" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 226px" alt="" src="http://2.bp.blogspot.com/_9GhISPdzIes/SrOSGYsHWGI/AAAAAAAAAA8/7HpH6zlMu7k/s320/ActTheoryForManifestingAgile.JPG" border="0" /></a>FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-24390371965616594922009-09-18T09:51:00.002-04:002009-09-18T09:55:13.218-04:00Programming with the starsPendant l’heure du lunch, 6 équipes de 2 personnes (une vedette de la programmation avec un partenaire) s’affrontent dans un jeu d’élimination pour trouver les meilleurs programmeurs. Cette petite activité de programmation fonctionne un peu comme les jeux télévisés. Il y a un jury de 3 personnes (Liz Keough, Brian Marick & Jim Newkirk) qui compte pour 50% et le public vote pour compléter l’autre 50%. L’idée est bonne et ça fonctionne très bien. J’ai beaucoup apprécié l’ambiance, par exemple, l’un des juges travaillait chez Microsoft et quelques participants s’amusaient à narguer les outils de Microsoft au risque de perdre des points auprès de ce juge cependant, ils ont gagné la faveur du public et même celle d’un autre juge.<br /><br />Lors de cette activité, je me suis posé la question suivante : un programmeur moyen-fort de ma compagnie serait-il à la hauteur? J’en doute. Une bonne partie des points était attribuée pour la façon de faire le CI (<a href="http://en.wikipedia.org/wiki/Continuous_integration">Continuous integration</a>). Chaque nouvelle ligne de code était testée avant de continuer à coder.<br /><br />Lien: <a href="http://agile2009.agilealliance.org/programmingwiththestars">Programming with the stars</a>FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-55097284500430807012009-09-02T10:20:00.003-04:002013-07-22T14:24:20.697-04:00How to run 4.5 Million tests per day, and whyIf you had to guess what software company has the expertise (and plain guts) to scale up the CI (<a href="http://en.wikipedia.org/wiki/Continuous_integration">continuous integration</a>) concept to running almost 5 <span style="font-style: italic;">Millions</span> tests per day, what would you say? Google, of course. This short talk by <a href="http://agile2009.agilealliance.org/user/681">Mark Striebeck</a> (a Google employee) was very interesting and somewhat illustrative of what Google is capable of when it sets its collective mind to something.<br /><br />People at Google were finding it harder to apply CI because of the large size of their test base. Tests were taking a long time to run so they were run less often. To solve this problem, they decided to leverage the Google infrastructure and implemented their <a href="http://en.wikipedia.org/wiki/Test_harness">test harness</a> as a scalable web service. The test execution is distributed on more than 1500 CI servers!<br /><br />The interface to the test system is a nice dynamic web page where you can filter and display the results in many different ways, giving you the exact view you want on your test results. And as you would expect, the search works pretty well, too.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-14424371705062963202009-08-31T16:25:00.005-04:002013-07-22T14:24:20.695-04:00Big Balls"<a href="http://www.agile2009.org/node/2470">Big Balls of Mud: Is This the Best that Agile Can Do?</a>" was one of my favorite sessions, given by <a href="http://www.laputan.org/">Brian Foote</a> and <a href="http://www.joeyoder.com/">Joseph Yoder</a>. It was presented as a "debate", where both of the presenters answered a series of questions given by a moderator. This session was a reflection on what I consider a fundamental problem in our profession: why is the "Big Ball of Mud" still the de-facto standard software architecture?<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_6CZdTRBRXZI/Spw9pjFRVWI/AAAAAAAAAu0/cViu0WuTO3Y/s1600-h/spaghetti-medium.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 232px; height: 320px;" src="http://2.bp.blogspot.com/_6CZdTRBRXZI/Spw9pjFRVWI/AAAAAAAAAu0/cViu0WuTO3Y/s320/spaghetti-medium.jpg" alt="" id="BLOGGER_PHOTO_ID_5376239839174808930" border="0" /></a><br />Most of the material presented comes from an article (41 pages) the presenters wrote called "Big Ball of Mud" (<a href="http://www.laputan.org/mud/">html</a> | <a href="http://www.laputan.org/pub/foote/mud.pdf">pdf</a>). Big Balls of Mud are<br /><blockquote>haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.<br /></blockquote>The architects preach better practices, with diagrams, principles, books, but in the end we still end up with mud. What makes the Big Ball of Mud software architecture so successful? Foote gives the example of Internet Explorer and Netscape, both of which he considers to be monstrous large balls of putrid mud. These products were successful, and made money. Some other examples of cleaner things that failed: Mac (smaller market share than Windows), lisp, Smalltalk, Betamax (versus VHS), FrameMaker (versus MS-Word).<br /><br />Foote and Yoder came up with the idea of "<a href="http://www.laputan.org/selfish/selfish.html">The Selfish Class</a>" (a reference to <a href="http://en.wikipedia.org/wiki/The_Selfish_Gene">The Selfish Gene</a>, by Richard Dawkins) to explain the evolution of software. Would this mean that Mud is more fit for survival than other types of software architectures? Is Mud normal? Is Mud the best we can do in real production systems? Why do people keep doing it? Why do we make money with Mud? In the global software environment, where different architectures fight and compete for survival, it would seem that the Big Ball of Mud is the dominant species.<br /><br />Does Mud == Legacy? Not necessarily, Mud is produced daily in prodigious amounts. On the other hand, some old code is good (e.g., Smalltalk).<br /><br />To illustrate his view that mud is the mostly used and deployed software architecture, Foote gave the dark matter analogy.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_6CZdTRBRXZI/SpxKTdmhdKI/AAAAAAAAAu8/eDXGaStC5iM/s1600-h/DarkMatterPie.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 178px;" src="http://1.bp.blogspot.com/_6CZdTRBRXZI/SpxKTdmhdKI/AAAAAAAAAu8/eDXGaStC5iM/s320/DarkMatterPie.jpg" alt="" id="BLOGGER_PHOTO_ID_5376253753397703842" border="0" /></a><br />What are the reasons for Mud happening?<ul><li>Throwaway code</li><li>Piecemeal growth</li><li>Keep it working</li><li>Copy / paste metastasis (faulty code is reproduced in many places and spreads)<br /></li></ul>When asked about the best and worst code he has ever seen, Yoder answered the following:<br /><ul><li><span style="font-weight: bold;">Best code</span>: the Smalltalk core library</li><li><span style="font-weight: bold;">Worst code</span>: a single C++ class with over <span style="font-style: italic;">500 000 lines of code</span>. This class is still in production at a large and well-known Silicon Valley company!</li></ul>Finally, is Agile useful in preventing Mud? Over the years since the first software programs, we went through many changes to what should be the "best" process. But still, year after year, decade after decade, we produce gargantuan mountains of nauseous mud. Is Agile the definite "best" process for avoiding mud? Yoder answers that many aspects of Agile actually seem to lead directly to mud:<br /><ul><li>Lack of upfront design</li><li>Late changes to the requirements</li><li>Late changes to the architecture</li><li>Piecemeal growth<br /></li></ul>In the end, maybe teams of good people produce good software, while teams of bad people produce bad software. This means that average teams will have some of both (good and bad), thus slowly inching towards mud. Is it that simple? Did we overestimate the importance of the process?<br /><br />Overall, it was a very interesting session, with excellent speakers.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-4475294140341267440.post-88008763546607706182009-08-31T16:04:00.004-04:002013-07-22T14:29:37.678-04:00Null References: the Billion-Dollar MistakeAt the QCon 2009 Conference in London, the inventor of <a href="http://en.wikipedia.org/wiki/Quicksort">QuickSort</a>, <a href="http://en.wikipedia.org/wiki/Tony_Hoare">Tony Hoare</a>, talked about another one of his creations: <a href="http://en.wikipedia.org/wiki/Null_%28computer_programming%29">null references</a> (without pride, it would seem):<br /><br /><a href="http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare">http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare</a><br /><br />I didn't have time to watch the video, but I'm pretty sure it is very interesting. I was surprised to find out that such a fundamental concept as null references had an inventor!<br /><br />This presentation was suggested by Dean Wampler during <a href="http://agile2009.blogspot.com/2009/08/scala-programming-language.html">his session on Scala</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-75869013723338635802009-08-31T11:48:00.006-04:002013-07-22T14:29:37.673-04:00The Scala Programming LanguageOn Wednesday morning I was in the mood for a more technical presentation, and "Scala: Object-Oriented and Functional Programming for the JVM", by <a href="http://www.deanwampler.com/">Dean Wampler</a>, seemed to fit the bill perfectly. The presenter was a bit surprised that his session was accepted in the Agile 2009 schedule, since it does not really relate to Agile... Anyway, it was a very interesting introduction to a new language: <a href="http://en.wikipedia.org/wiki/Scala_%28programming_language%29">Scala</a>.<br /><br />Why do we need a new language?<br /><ul><li>We need <a href="http://en.wikipedia.org/wiki/Functional_programming">functional programming</a></li><ul><li>for concurrency</li><li>for concise code</li><li>for correctness</li></ul><li>We need a better object model</li><ul><li>for composability</li><li>for scalable designs</li></ul><li>But we want to keep our investment in Java and C#</li></ul>Scala is also a <a href="http://en.wikipedia.org/wiki/Type_system#Static_typing">statically typed</a> language.<br /><br />Here are some references if you are interested in learning more about the language:<br /><ul><li>The <a href="http://en.wikipedia.org/wiki/Scala_%28programming_language%29">Wikipedia entry</a> entry on Scala</li><li>The official <a href="http://www.scala-lang.org/">Scala website</a></li><li>The <a href="http://scala.sygneca.com/">Scala Wiki</a> (with many code examples)<br /></li><li><a href="http://en.literateprograms.org/Category:Programming_language:Scala">Scala on Literal Programs</a> - interesting examples<br /></li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-7652760254356323702009-08-31T11:32:00.003-04:002013-07-22T14:29:37.675-04:00Planning Poker: one card only!On Tuesday night, during a marketing event, I had a short discussion with someone from <a href="http://www.cyrusinnovation.com/">Cyrus Innovation</a> about planning poker. I had a specific question: "should we use multiple cards when making our estimate?" The idea behind using multiple cards is to form numbers that are not available in the list, for example, use 1 and 3 to play a 4. His opinion was that no, we should not do this. The cards have those values (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) for a reason. According to Wikipedia:<br /><blockquote>The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.<br /></blockquote>Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-4475294140341267440.post-63910350041799856872009-08-31T10:44:00.005-04:002013-07-22T14:29:37.667-04:00The Ideal Agile ToolsetMy last presentation for Tuesday was a talk by <a href="http://www.agile2009.org/user/1991">Brad Appleton</a> (who was using <a href="http://en.wikipedia.org/wiki/Crutch">crutches</a> because he hurt his leg while <a href="http://en.wikipedia.org/wiki/Breakdance">breakdancing</a>, true story!) about the characteristics of the ideal Agile toolset. Appleton feels that the current tools we have that support the Agile process (e.g., <a href="http://en.wikipedia.org/wiki/Eclipse_%28software%29">Eclipse</a>, <a href="http://en.wikipedia.org/wiki/Confluence_%28software%29">Confluence</a>, <a href="http://en.wikipedia.org/wiki/TWiki">TWiki</a>, <a href="http://en.wikipedia.org/wiki/Trac">Trac</a>, <a href="http://en.wikipedia.org/wiki/JIRA_%28software%29">Jira</a>, <a href="http://www.zagile.com/">zAgile</a>) all fail one way of another to deliver proper Knowledge Management.<br /><br />Most current Agile toolsets treat source code as the primary deliverable of a project. This means that the source code gets special treatment: branches, labels, history, dependencies, etc. However, Appleton asserts that source is not the product: <span style="font-style: italic;">knowledge</span> is the product delivered on a project. Source code is only one way to represent knowledge, it is a knowledge <span style="font-style: italic;">format</span>. What follows is that the ideal toolset should manage all knowledge the same way, allowing tight revision control on diagrams, wiki entries, tests, etc.<br /><br />Appleton then raises some interesting questions:<br /><ul><li>How can we define "done" for non-code artifacts (e.g., a UML diagram)?</li><li>Is it possible to apply TDD (test driven development) to non-code artifacts?<br /></li></ul>This talk by Brad Appleton got me thinking about a practice we have in our department. We usually manage our designs by checking in a complete design document (a Word .doc file, or a EAP file) in our VCS. Maybe we should try to have a finer level of control on those designs by splitting the documents into individual diagrams, or sections, etc. This would allow for a better management of dependencies (e.g., between code and individual diagrams), branches, etc.<br /><br />On a final note, the presenter mentioned a book that could be an interesting addition to our library: <a href="http://www.amazon.com/Laws-Software-Process-Production-Management/dp/0849314895">The Laws of Software Process</a>, by Phillip G. Armour. (I don't think we have it, but I could be wrong...)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-66621336079041598582009-08-28T12:07:00.009-04:002013-07-22T14:29:37.669-04:00Agile Project Management with Google DocsThis session was an experience report by a company who decided to use Google Docs as a lightweight approach to Agile project management for a distributed Scrum. For their daily stand up meetings, they would use a shared Google Spreadsheet while having a Skype conference call. They also used this approach for the planning poker. In both instances, a single person would edit the spreadsheet, but being a shared Google Spreadsheet, everyone would see the updates in real time.<br /><br />One thing they do that I found interesting is that they have a couple of LCDs near their Scrum meeting area that constantly display information about the project, such as snag count, the status of the build, etc. The goal is to create or encourage participation through shared and visible information. The term usually employed for this is "<a href="http://en.wiktionary.org/wiki/mieruka">mieruka</a>" which means "making visible" in Japanese, and seems to have been pioneered by Toyota.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_6CZdTRBRXZI/SpvhkEGEYWI/AAAAAAAAAus/Qr5oh0aiBGI/s1600-h/mieruka.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 320px; height: 133px;" src="http://2.bp.blogspot.com/_6CZdTRBRXZI/SpvhkEGEYWI/AAAAAAAAAus/Qr5oh0aiBGI/s320/mieruka.jpg" alt="" id="BLOGGER_PHOTO_ID_5376138589887553890" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_6CZdTRBRXZI/Spvgdan4WXI/AAAAAAAAAuk/UUbB1NEehT4/s1600-h/mieruka.jpg"><br /></a>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-4475294140341267440.post-70970177093064291192009-08-28T12:03:00.004-04:002009-08-28T12:09:21.501-04:00Diagrams for understanding and improving Agile practiceMon mardi après midi fut probablement ma meilleure journée. Trois bonnes conférences en trois dont deux salles combles. Plusieurs personnes se sont vu fermer la porte au nez. When is full, is full !<br /><br />La conférence de <a href="http://agile2009.agilealliance.org/user/2915">Bonnie Aumann </a>et <a href="http://agile2009.agilealliance.org/user/1891">Arlo Belshee</a>, « <a href="http://agile2009.agilealliance.org/node/649">Diagrams for understanding and improving Agile practice </a>», commence avec un petit exercice pratique. Avec comme information seulement un estimé du « Business Value » (Low, Some, Good & High) associer à chacun des livrables de l’entreprise, nous devons choisir par quel livrable nous commençons. Nous retournons la carte et nous obtenons la durée et le bénéfice obtenu. Nous soustrairons la durée des 120 jours initiaux que nous disposons et nous répétons l’exercice tant qu’il nous reste des journées. La deuxième phase de l’exercice ce fait avec les même cartes cependant, nous disposons d’une information supplémentaire pour faire notre choix. Nous avons un estimé en temps pour chacun des livrables, ce qui correspond au coût du livrable. Après avoir fait cette deuxième phase, nous comparons les bénéfices pour nous rendre compte que nous obtenons un meilleur bénéfice avec seulement comme information le Business Value. Hasard ? Selon les deux conférenciers ce n’est pas le fruit du hasard. Après quelques courbes, graphiques et formules mathématiques nous comprenons que la nature humaine nous porte à prendre des mauvais choix. Cet exercice nous démontre que nous interprétons mal un surplus d’information parfois plus complexe que nous le croyons.<br /><br /><a href="http://4.bp.blogspot.com/_9GhISPdzIes/SpgARL11T5I/AAAAAAAAAA0/rNhd9jBpR-A/s1600-h/diagrams.JPG"><img id="BLOGGER_PHOTO_ID_5375046450503045010" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 262px" alt="" src="http://4.bp.blogspot.com/_9GhISPdzIes/SpgARL11T5I/AAAAAAAAAA0/rNhd9jBpR-A/s320/diagrams.JPG" border="0" /></a><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />Le reste de cette présentation a porté sur la performance versus l’overhead et la période (continues processing) versus la production incluant d’autre donné comme les frais fixe (taxes…). Une très bonne présentation qui avait comme objectif de nous démontrer qu’une courte période est souvent signe de $.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-16240263913459897842009-08-28T10:12:00.002-04:002009-08-28T10:15:32.964-04:00ScrumMasterLe problème avec le ScrumMaster c’est le nom. Le nom porte à confusion. Que veut dire Master dans ScrumMaster? La courte conférence de <a href="http://agile2009.agilealliance.org/user/133">Paul Hodgetts </a>« <a href="http://agile2009.agilealliance.org/user/133">ScrumMaster Considerer Harmful </a>» nous aide à mieux définir le rôle d’une ScrumMaster. Je vous énumère rapidement ce qu’un ScrumMaster est :<br />ScrumMaster as a Scrum Change Agent<br />ScrumMaster as Our Process Conscience<br />ScrumMaster as a Remover of Impediments<br />ScrumMaster as Coach and Team Builder<br />ScrumMaster as Committed to the Team<br />ScrumMaster as an Ambassador to the Organization<br /><br />Cependant, le ScrumMaster n’est pas un Manager ni un Project Manager. Le ScrumMaster à l’esprit et le goût d’aider les autres. Petite parenthèse, je ne veux certainement pas dire que le Manager ou PM ne veut pas aider les gens. D’ailleurs, j’ai appris que la majorité des ScrumMasters était Project Manager au paravent. Je crois que nous (mon organisation) devrions maintenant nous poser les questions suivantes : Avec toutes ces responsabilités, le ScrumMaster devrait-il codé ? Devrait-il avoir le temps ?FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com1tag:blogger.com,1999:blog-4475294140341267440.post-55079895790416832762009-08-27T19:59:00.002-04:002009-08-27T20:01:58.120-04:00Butterfly EffectLors de la conférence “<a href="http://agile2009.agilealliance.org/node/177">What (Else) Can Agile Learn from Complexity?</a>”, <a href="http://agile2009.agilealliance.org/user/1940">Jurgen Appelo </a>nous fait la démonstration que rien n’est simple. Dans un monde complexe, il est impossible de tout prédire. La phrase qu’il a mentionné vers la fin de sa présentation, invoque bien le sens général: « All models are wrong, but some are usefull ».<br /><br />Il n’y a pas de solution magique qui peut s’applique à une entreprise et encore moins à toutes les entreprises. Cependant, aujourd’hui Agile est probablement le model le mieux adapter au monde du software. À nous de l’appliquer du mieux que nous pouvons.FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-86130277627680808112009-08-27T19:13:00.005-04:002013-07-22T14:29:37.677-04:00The Greatest Misses of an XP coach<a href="http://en.wikipedia.org/wiki/J._B._Rainsberger">J. B. Rainsberger</a> is a software consultant that gave a talk about his greatest misses as an XP coach. He is a very good speaker, the talk was rather pleasant and interesting. What he basically said during 90 minutes is "people are more important than practices", and that the key to succeeding with Agile is good communication.<br /><br />He mentioned two techniques that can improve your communication skills:<br /><ul><li><a href="http://www.infoq.com/articles/satir-communication-model-teams">The Satir Interaction Model</a>. This model will help you "debug" the conversations you have with other people.<br /></li><li>The laws of "<span style="font-weight: bold;">generous interpretation</span>" and "<span style="font-weight: bold;">harsh interpretation</span>". When someone tells you something, try to come up with three different interpretations of what they said. Assume that most generous is the real one. On the other hand, when you want to say something to someone, make up three different interpretations and assume the other person will choose the most harsh. This should improve your reactions to what other people tell you, and also deepen your understanding of the reaction of others to what you say.<br /></li></ul>He also suggested a book, "<a href="http://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420">The Psychology of Computer Programming</a>", saying that it was the most influential book he ever read.<br /><br />I would like to end this post with something that Rainsberger said that I found very interesting:<br /><blockquote>Doing the right thing for the right reason is not enough. [You also need to have the trust and commitment of your teammates and stakeholders.]</blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-10625716509097435932009-08-27T18:31:00.003-04:002013-07-22T14:29:37.663-04:00Covert AgileI selected the "Covert Agile: Development at the Speed of…Government?" session to complete my Tuesday morning schedule. It turned out to be a pretty interesting experience report by a consultant who did a contract for the United States Department of Defense. The project was to re-write some legacy satellite scheduling software so it would work with modern hardware. It wasn't just for the thrill of using the latest and greatest hardware though. They were actually forced to go on ebay.com to find replacement parts because nobody produced the old hardware they were dependent on. Having DoD software running on machines bought on ebay is not very reassuring for American citizens.<br /><br />They knew that at least one previous attempt at doing this by another company had failed. It didn't fail because that company didn't deliver, on the contrary, they delivered a complete working solution after many months of work. However, the operators simply didn't like the interface. They refused to use the new software so the project was a failure.<br /><br />So it was obvious that if they were to succeed, they needed to include the operators very early in the process, and have relatively short iterations, with rather fluid requirements. They wanted to be Agile. However, in order to get the contract they needed to hide their Agility! They were required by DoD to provide "Waterfall" type artifacts at various milestones in the project. They actually had to hire people to produce all these "Waterfall" artifacts, and deliver them to DoD. These people were not contributing anything to the software, they were just producing heavy documents and sending them upward to be able to keep the contract.<br /><br />In the end they succeeded, but the presenter said he hoped to never have to do such a contract ever again. I think a part of his soul died during this project and was buried in a large requirements binder.<br /><br />As a last note on this session: the presenter mentioned that one thing they did that helped them was to leave a certain proportion of sprints (say 1 in 4, or 1 in 5) entirely dedicated to bug fixes, refactorings, etc. We sometimes do something similar, but in our team it seems to be reactive, and somewhat disruptive for the schedule. In their case, they were proactively planning for it from the beginning of the project.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-60166295967820111792009-08-27T01:21:00.003-04:002009-08-27T01:31:55.966-04:00Agile is not a religion<div>Ce titre est en fait un des 10 conseils pour un coache Agile selon <a href="http://agile2009.agilealliance.org/user/3">Rachel Davies </a>et <a href="http://agile2009.agilealliance.org/user/278">Liz Sedley</a>. J’ai assisté à leur conférence <a href="http://agile2009.agilealliance.org/node/2224">Top 10 Tips for Agile Coaches </a>avec plaisir. Elles ont commencé par le dixième conseil : Get Introduced. C’est dans la logique des choses. On se présente, ont dit nos attentes, … Je me dis soudainement que je ne me suis pas présenter lorsque je me suis assis entre deux personnes. Normalement je me présente. Neuvième conseils, Agile is not a religion, ça fait sourire toute l’audience. L’homme à côté de moi griffonne sur un bout de papier et le tasse sur mon côté comme pour me le montrer. Je regarde et il est écrit qu’il est un évangéliste. Je suis surpris, … huitième conseils, Show respect ! C’est ce que j’ai fait.<br /><br />Vous devinez, la présentation fut très intéressante, principalement pour un coache Agile. Ce que je ne suis pas. Mais certain conseil me seront très pratique lors de mon retour. </div><br /><div><br />Si vous voulez connaitre les 10 conseils, voici leurs livres qui fut le premier meilleur vendeur de la conférence 2009. </div><br /><div></div><a href="http://3.bp.blogspot.com/_9GhISPdzIes/SpYaCpBUUxI/AAAAAAAAAAs/aG79VJKdiog/s1600-h/AgileCoaching.JPG"><img id="BLOGGER_PHOTO_ID_5374511837986706194" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 269px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://3.bp.blogspot.com/_9GhISPdzIes/SpYaCpBUUxI/AAAAAAAAAAs/aG79VJKdiog/s320/AgileCoaching.JPG" border="0" /></a><br /><div></div>FGhttp://www.blogger.com/profile/02555742619447353615noreply@blogger.com0tag:blogger.com,1999:blog-4475294140341267440.post-7565823694121789252009-08-26T23:06:00.003-04:002013-07-22T14:29:37.671-04:00Kill the Gatekeeper!On Tuesday morning I attended an experience report given by <a href="https://launchpad.net/%7Eflacoste">Francis Lacoste</a>, who's working on <a href="https://launchpad.net/">LaunchPad</a> (not to be confused with our LaunchPad). He basically described the changes they made to their integration system to render it more Agile, more "continuous".<br /><br />They initially had a single "Main" branch that they tried to never break, a bit like what we have in our department. They had a GateKeeper that would validate all changes submitted by developers, and only if everything passes (build, unit tests, etc.) would the change be applied to the main branch.<br /><br />They realized this was preventing them to fully implement continuous integration, so they now work with a "stable main" and a "devel main". The developers can now push changes at any time they want to the "devel main". The gatekeeper resides between the "devel main" and the "stable main".<br /><br />(Note: the gatekeeper in their case is not a human being, it is an automated tool)Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-4475294140341267440.post-13026111240386153042009-08-26T21:57:00.010-04:002013-07-22T14:29:37.665-04:00Keynote<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_6CZdTRBRXZI/SpXuRYBxbHI/AAAAAAAAAuM/rY1lGAIl-94/s1600-h/cockburn.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 145px; height: 200px;" src="http://2.bp.blogspot.com/_6CZdTRBRXZI/SpXuRYBxbHI/AAAAAAAAAuM/rY1lGAIl-94/s200/cockburn.jpg" alt="" id="BLOGGER_PHOTO_ID_5374463712611626098" border="0" /></a><br />We were all staring at the freakish picture of the speaker, <a href="http://alistair.cockburn.us/">Alistair Cockburn</a>, when a guy emerged from the door and crossed the entire room, playing <a href="http://en.wikipedia.org/wiki/Bagpipes">bagpipes</a> along the way. Cockburn then appeared on the stage and started reciting the "Agile" <a href="http://alistair.cockburn.us/I+come+to+bury+Agile,+not+to+praise+it">version</a> of <a href="http://www.presentationhelper.co.uk/friends-romans-countrymen.htm">some part</a> of Shakespeare's Julius Caesar... That's how the keynote speech, titled "I come to bury Agile, not to praise it", started.<br /><br />It was an interesting talk overall. Here are some points Cockburn made during the presentation (not an exhaustive summary):<br /><br /><ul><li>When we pick items from the backlog, we should not just consider business value; technical risk is also an important consideration. We may want to start working on the riskier things earlier to get a lot of knowledge as fast as possible.</li><li>The "gold card": when a developer gets a "gold card" (I'm not sure through what mechanism), that developer gets to work on anything he wants for a couple of days. Cockburn seems to be in favor of having some sort of "thinking time"!</li><li>We should stop talking about "Agile". We should bury the term itself, since all those practices are now part of the current way to do software engineering. It is now time to consider experimenting with newer techniques.<br /></li></ul>Unknownnoreply@blogger.com0