tag:blogger.com,1999:blog-91156446058333841382024-03-13T21:16:17.380+01:00X de XavierUnos y ceros. A veces, en el orden adecuado.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-9115644605833384138.post-61951872900661391612008-12-10T23:21:00.003+01:002008-12-11T00:39:31.296+01:00Pushing agility from the business side?<div style="padding: 3px; text-align: left;"><a href="http://www.flickr.com/photos/xverges/3099036368/" title="Pushing agility from the business side?"><img src="http://farm4.static.flickr.com/3094/3099036368_8e1f12a965.jpg" style="border: 2px solid rgb(0, 0, 0); width: 400px;" alt="" /></a><br /><span style="margin-top: 0px;font-size:0;" ><a href="http://www.flickr.com/photos/xverges/3099036368/">Pushing agility from the business side?</a>, originally uploaded by <a href="http://www.flickr.com/people/xverges/">-Xv</a>.</span></div><p>A possible scenario:<br /><br /><b>1.</b> IT happy with status-quo: Big Design Up Front and Waterfall.<br /><b>2.</b> Stakeholders accept non-agility as a fact of life.<br /><b>3.</b>Tell stakeholders that they are entitled to learn, to defer<br />decisions until the have more info, to change their opinion. That some<br />of their competitors use those right to their advantage.<br /><b>4.</b> Stakeholders will push agility upon IT<br /><br />Just in case it helps Ferran Rodenas to get some idea to <a href="http://www.rodenas.org/blog/2008/12/09/thoughts-on-software-development-methodologies/">break the status-quo</a></p>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-25832717787084280092008-08-03T15:23:00.003+01:002008-08-03T15:37:50.659+01:00Falta chico con experienciaUno ya se va acostumbrando a que el papel del programador <a href="http://codeclimber.blogspot.com/2008/04/all-i-need-is-programmer.html">no se valore mucho</a>, incluso por gente que se supone mejor informada, pero esta perla me ha hecho reir:<br /><blockquote style="font-style: italic;">Falta chico con experiencia en programación PHP, AJAX, MySql, sistemas, etc. También precisamos un diseñador gráfico manejando bien Photoshop y Flash. Interesados enviar CV con datos completos, teléfono de contacto y horario para llamar. Si cumples el perfil puedes tener una entrevista de inmediato.</blockquote>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-68501944382327851562007-11-30T00:17:00.000+01:002007-11-30T01:38:00.131+01:00Yay! Barcelona Python Meetups are here!Back from the first <a href="http://python.meetup.com/185/">Barcelona Python Meetup Group</a> event. The event was good, with two talks:<br /><ul><li><a href="http://www.linkedin.com/pub/0/a5/280">Maik Röder</a>, based on the <a href="http://tarekziade.wordpress.com/2007/09/24/eight-tips-to-start-with-python/">Eight tips to start with Python</a>. Maik added an additional tip (use <a href="http://divmod.org/trac/wiki/DivmodPyflakes">PyFlakes</a>, a faster PyChecker) and asked the attendants for our own tips: <a href="http://ipython.scipy.org/moin/">IPython</a> (a great shell that I should be using again) proved to have many fans! I mentioned my love for <a href="http://docs.python.org/lib/module-ctypes.html">ctypes</a>.</li><li><a href="http://jardigrec.eu/">Ramon Navarro Bosch</a>, on Design Patterns in Python. Ramon recommended us <a href="http://www.aleax.it/">Alex Martelli</a>'s <a href="http://video.google.com/videoplay?docid=-3035093035748181693">Google TechTalk video</a> on the topic.<br /></li></ul>If the event was good, the post-event (beers, croquetas and bravas) with Maik was great and I'm bringing home lots of food for thought. Most of the talk was about <a href="http://www.openplans.org/projects/funittest/project-home">Funittest (<span style="font-style: italic;">Making it easy to go from use case to functional test</span>)</a>. Maik uses daily a high level Test Driven Development flow:<br /><ul><li>write the functional test, to get aligned with the user's needs/customer value,<br /></li><li>write unit test, that can be driven faster and focus in the approapiate level of abstraction</li><li>write the code</li></ul>My impression is that his ideas have lots of commonalities with <a href="http://fit.c2.com/">Fit</a> and <a href="http://fitnesse.org/">Fitness</a>, and the story-based-testing that they advocate. Maik said that Funnitest's theoretical foundation can be grasped in <a href="http://blogs.msdn.com/micahel/archive/2005/05/04/FromAccountantToScientist.aspx">The Braidy Tester articles</a>; I'm adding them to my to-read list...<br /><br />Beyond functional testing, the programmer's flow, the business-technical gap, Barcelona, Sevilla, tele-working... an intriguing an promising idea: the I-told-you-that-this-was-a-wrong-decision year-end bonus.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-924225900593695212007-10-22T00:15:00.000+01:002007-10-21T23:44:53.680+01:00We make mistakesEveryone makes mistakes. Some times we are aware of them, some times we are not: looks like putting the blame of mistakes in someone or something is part of our nature. It's a pity, because we let pass by lots of learning opportunities.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://flickr.com/photos/srslyguys/1207374447/"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px;" src="http://farm2.static.flickr.com/1139/1207374447_559295ffea_m_d.jpg" alt="" border="0" /></a><span style="font-size:78%;"> Flickr picture by <a href="http://flickr.com/photos/srslyguys/">srslyguys</a></span><br /></div><br />We software engineers are lucky enough of being faced in our trade with lots of mistakes that we cannot blame in any one but ourselves. Of course, some mistakes allow allocating blame on our customer, our team, our tools... My teammates often hear me cursing loudly Bill Gates or Linus Torvalds, but they know I'm jocking: we are experienced enough to know that <a href="http://pages.citebite.com/b2i2d5v2n1rxq">select isn't broken</a>. When writing code, you rarely can put the blame on someone/something else unless you are a pathological liar; that's good.<br /><br />I would like to think that having to face our daily mistakes helps us weaken our blame-someone-else voice in other areas of our life, but, honestly, I don't have any evidence about it. But, just in case, I'd like my kids to learn the <span style="font-style: italic; font-weight: bold;">we make mistakes, we learn from them</span> lesson/mindset, and this has been one of the main drivers in getting our new home pet, <a href="http://xdexavier.blogspot.com/2007/09/happy-and-secret-co-owner-of-nxt-kit.html">a Lego Mindstorms NXT Robot</a>.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-86415959236402912562007-10-06T20:25:00.000+01:002007-10-06T21:39:11.262+01:00Jazz in the hood<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://jazz.net/"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_T679aggANRU/RwfjSDzZQRI/AAAAAAAAACs/kZxgxQHhTNo/s320/jazz.png" alt="Jazz band playing" id="BLOGGER_PHOTO_ID_5118309400927879442" border="0" /></a><br /><a href="http://martin-espinach.neurona.com/">Martin Espinach</a>, coffee machine and lunch mate, gave yesterday a very nice internal talk about how his previous project used <a href="http://www.bugzilla.org/">bugzilla</a> and <a href="http://www.eclipse.org/mylyn/">Mylyn</a> to help them plan, assign and track team tasks. Although they were initially excited about Mylyn's task-focused UI, none of the team members ended up using it; they did love Mylyn's ability to get notifications from bugzilla. It looked like a neat solution.<br /><br />When his very detailed talk was almost done, he told us that, for their recently started new project, they are using <a href="http://jazz.net">IBM Rational Jazz</a>. I felt like killing him, but I then I would have missed the chance to complain about his talk during every afternoon coffee in the next weeks.<br /><br />And Jazz? So far, they are loving it. I'll have to ask him to demo it to our team.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com1tag:blogger.com,1999:blog-9115644605833384138.post-41629243131415135092007-09-22T11:43:00.001+01:002007-09-22T11:46:37.859+01:00Why interpreted programming languages suck<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://xkcd.com/303/"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand" src="http://imgs.xkcd.com/comics/compiling.png" border="0" alt="" /></a>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-48657567271202332262007-05-16T23:22:00.000+01:002007-05-16T22:29:27.496+01:00Coding Contest in Second LifeJust good an email from <a href="http://www.linkedin.com/in/christophsteindl">Christoph Steindl</a>, a former IBM colleague, where he used to co-lead the Agile@IBM community and write an excellent blog.<br /><br />Are you familiar with the Coding Wars in <a href="http://www.amazon.co.uk/gp/product/0932633439?ie=UTF8&tag=xdexavie-21&linkCode=as2&camp=1634&creative=6738&creativeASIN=0932633439">Tom DeMarco and Tim Lister's Peopleware</a>?<img src="http://www.assoc-amazon.co.uk/e/ir?t=xdexavie-21&l=as2&o=2&a=0932633439" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /> Christoph is into something similar: the cool <a href="http://catalysts.cc/index.php?id=contest">Catalysts' Coding Contest (CCC)</a> that his company is running:<br /><blockquote><ul><li>Who is faster? Who is more efficient? Who is more effective? Who is more productive?</li><li>Does "Pair Programming" really make you faster?</li><li>Does "Test-Driven Development" really lead to fewer bugs?</li><li>How many ways are there to solve a problem?</li><li>Is it right that good developers only write 30 lines of code for which mediocre developers need to write 300 lines?<br /></li></ul><a href="http://catalysts.cc/">Catalysts</a> organizes a coding contest to go further into some of these questions. </blockquote>They will be running the contest in Linz, Austria (with post food and beverages) and in Second Life (do avatars drink and eat?).<br /><br />Looks like a bright idea to me. I bet that having participants with different backgrounds, and letting anonymous participation will provide coders and organizers useful insight. I don't know if other companies do this sort of thing internally, but it looks like very interesting way to get information, a honest measurement <a href="http://www.transformingperformancemeasurement.com/">not linked to rewards and punishments</a> (note to self: bring this to IBM's internal <a href="http://services.alphaworks.ibm.com/thinkplace/">ThinkPlace</a>).<br /><br />I'm even considering ignoring my usual too-busy-with-real-life-to-get-me-a-second-life to be able to <a href="http://catalysts.cc/index.php?id=525&L=0">participate via Second Life</a>.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-41763351587962417962007-04-27T13:52:00.000+01:002007-04-27T14:11:55.926+01:00Evangelizing and toilets<span class="q"><blockquote>One of Google's little secrets that has helped us to inspire our developers to write well-tested code: <span style="font-weight: bold;">we write flyers </span>about (testing techniques) <span style="font-weight: bold;">and then regularly plaster the bathrooms all over Google with each</span> episode, almost 500 stalls worldwide.<br /><br />We've received a lot of feedback about it. Some favorable ("This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!") and some not ("I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?")</blockquote>Stumbled upon this evangelizing technique in </span><a href="http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html">Introducing "Testing on the Toilet"</a>, while googling trying to decide which JavaScript unit testing framework use (yeah, shame on me, I've been doing lots of JavaScript lately without doing Test Driven Development).<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://googletesting.blogspot.com/" title="Debugging sucks. Testing rocks"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px;" src="http://photos1.blogger.com/x/blogger2/5468/1836/1600/z/275811/gse_multipart55189.gif" alt="" border="0" /></a>They not only use a surprising evangelizing technique, but also have a great banner and motto for their blog: "<span style="font-style: italic;">Debugging sucks. Testing Rocks.</span>"-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-88440863142272724112007-03-21T16:08:00.000+01:002007-03-21T16:22:00.164+01:00Play with ClearQuest and ClearCase without installing themI've been playing with IBM Rational ClearQuest and ClearCase without doing any configuration. Cool. I'm hoping that we'll do the same for more IBM Rational products.<br /><br />You can access a dW server with a tutorial environment setup using a Citrix client. Go to <a href="http://www.ibm.com/developerworks/downloads/r/rcc/">Trial: Rational ClearCase V7.0</a> (I just reported it, but, in case that you take the first tutorial, you'll see that the screenshots of the first part don't match the actual product: you'll have to "connect" instead of "login", and you better know that pat's password is pat and that she has the lead project role).-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-66983770353538255442007-01-23T00:31:00.001+01:002007-01-23T07:03:36.564+01:00Grandmothers and designers' expectations<a href="http://www.informit.com/authors/bio.asp?a=61899683-7393-4dd2-9ba2-a3d0a579e8b4&rl=1"> Bruce MacIsaac</a>:<br /><blockquote><span style="font-weight: bold;">Systems often outlive the assumptions of their original designers</span>. The millenium bug is a classic example. Assuming that the software would be replaced by 1999, early designers used two-digit dates. That assumption cost billions to correct. My own grandmother was the victim of a similar false assumption. When my grandfather passed away in the 1970s, she bought a dual headstone, precarved with her name and "19__". <span style="font-weight: bold;">At the age of 112, Mary MacIssac, like many legacy systems, continues to outlive the designer's expectations</span>.</blockquote>From the <span style="font-style: italic;">Leverage Legacy Systems</span> chapter of <span style="font-style: italic; font-weight: bold;">Agility and Discipline Made Easy. Practices from OpenUP and RUP</span> <span style="font-size:78%;">(<a href="http://www.amazon.com/gp/product/0321321308?ie=UTF8&tag=xdexa-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321321308">amazon.com</a><img src="http://www.assoc-amazon.com/e/ir?t=xdexa-20&l=as2&o=1&a=0321321308" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />,<a href="http://www.amazon.co.uk/gp/product/0321321308?ie=UTF8&tag=xdexavie-21&linkCode=as2&camp=1634&creative=6738&creativeASIN=0321321308">amazon.co.uk </a><img src="http://www.assoc-amazon.co.uk/e/ir?t=xdexavie-21&l=as2&o=2&a=0321321308" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />,<a href="http://safari.awprofessional.com/0321321308">safari</a>)</span>, by <a href="http://www-306.ibm.com/software/rational/bios/kroll.html">Per Kroll</a> and Bruce MacIsaac.<br /><br />Bruce dedicates the book to his grandmother.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-32429324146914383392007-01-04T23:12:00.001+01:002007-01-08T06:26:09.184+01:00Planning PokerI'm reading <a href="http://www.mountaingoatsoftware.com/index">Mike Cohn</a>'s <span style="font-weight: bold;"><span style="font-style: italic;">Agile Estimating and Planning</span></span> <span style="font-size:78%;">(<a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F0131479415&amp;amp;amp;tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a><img src="http://www.assoc-amazon.com/e/ir?t=xdexa-20&amp;amp;amp;amp;l=ur2&o=1" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F0131479415&amp;amp;amp;tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a><img src="http://www.assoc-amazon.co.uk/e/ir?t=xdexavie-21&amp;amp;amp;amp;l=ur2&o=2" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />)</span>; so far, a great book. <a href="http://www.cutter.com/meet-our-experts/jhbio.html">Jim Highsmith</a>'s <a href="http://www.phptr.com/content/images/0131479415/forward/0131479415_foreword_highsmith.pdf">foreword</a> is well worth reading.<br /><br />On the chapter of techniques for estimating, Cohn describes <span style="font-weight: bold;">Planning Poker</span>, something that feels so simple and effective that you almost have to run to join your team and give it a try. You can read the description at <a href="http://www.planningpoker.com/detail.html">http://www.planningpoker.com/detail.html</a>. The site hosts a tool to enable distributed teams to play Planning Poker. Disclaimer: I still haven't played poker nor checked the tool.<br /><br />One the nice things of Planning Poker is that it is not tied at all to software development: projects from other domains that have to be sized by guestimates (like writing a complex report) fit nicely in this approach.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-40448192226429035622006-12-28T02:02:00.000+01:002006-12-28T02:05:34.044+01:00Mary Poppendieck: Competing On The Basis Of SpeedI watched <a href="http://www.poppendieck.com/">Mary Poppendieck</a>'s talk at Google: <a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694">Competing On The Basis Of Speed</a>. It is a good talk, but it does not compare well to Mary and Tom's most excellent <span style="font-style: italic; font-weight: bold;">Lean Software Development: An Agile Toolkit</span> <span style="font-size:85%;">(<a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F0321150783&tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F0321150783&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a> <a href="http://safari.oreilly.com/0321150783">safari</a>)</span>.<br /><br /><embed style="width: 400px; height: 326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=-5105910452864283694&hl=en" flashvars=""></embed><br /><br />I took some messy notes, way too powerpointish :-(. My advice: go for the book<span style="font-weight: bold;"></span>.<br /><br /><span style="font-weight: bold;"><span style="font-size:130%;">Intro</span><br /></span><ul><li>Fast companies (e.g. Dell, Toyota, Google)</li><ul><li>competitive advantage<br /></li><li>lower costs<br /></li><li>large barrier to entry for competition<br /></li></ul><li>Speed's enemy: complexity</li><li>3 faces of complexity [1]:</li><ul><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> waste</span>: anything that depletes resources without <strong style="font-weight: normal;">adding customer value<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">keep it simple</span><br /></strong></li><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> inconsistency</span>: anything uneven, unbalanced, irregular<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">make it flawless</span><br /></li><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> overload</span>: excessive burden<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">let it flow</span><br /></li></ul></ul><span style="font-weight: bold;font-size:130%;" >Keep it simple</span> (<span style="font-size:85%;"><a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#5m45s">video 5m45s</a></span>)<br /><ul><li>Common infrastructure:</li><ul><li>Architecture</li><li>Conventions: naming, coding, security, logging, ui, configuration management...</li><li>Tools</li></ul><li>Refactoring to keep simplifying</li><li> Sustainable simplicity: <span style="font-weight: bold;">change tolerance</span> (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#7m52s"><span style="font-size:85%;">video 7m52s</span></a>)</li><ul><li>60%-80% of code is written after the first release</li><li>the development process has to anticipate change</li><li><span style="font-weight: bold;">decide as late as possible</span>, when you have more info<br /></li><ul><li> make decissions reversible whenever possible</li></ul><ul><li>make irreversible decissions at the <span style="font-weight: bold;">last responsible moment</span></li><li><span style="font-weight: bold;">set-based development</span>: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.</li><li>paradox: these redundant solutions are not waste</li></ul></ul></ul><span style="font-weight: bold;font-size:130%;" >Make it flawless</span><span style="font-size:130%;"> </span>(<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#18m28s"><span style="font-size:85%;">video 18m28s</span></a>)<br /><ul><li>2 kinds of inspection</li><ul><li>to find defects -> waste</li><li> to prevent defects -> essential</li></ul><li>Mistake-proof every step: detect defects the moment they ocurr</li><ul><li> don't track defects on a list: find them and fix them</li></ul><ul><li> test first, automated test suites</li></ul><li>Role of testing (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#21m55s"><span style="font-size:85%;">video 21m55s</span></a>)</li><ul><li> manufacturing:<br /></li><ul><li>a quality process brings quality into the products (unlike in software development traditional view)<br /></li></ul><ul><li> finding process in verifcation -> you have a defective process</li></ul><li> focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.</li></ul><li>4 kinds of testing</li><ul><li>unit testing: developer intend. Automate them.<br /></li><li>acceptance/regression testing: business intend. Automate them.</li><li>exploratory + usability testing. Manual by definition.</li><li> property (response, security, scaling....) testing. Take advanteg of tools.</li></ul><li>Technical debt (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#26m55s"><span style="font-size:85%;">video 26m55s</span></a>)</li><ul><li> anything that makes code difficult to change</li><li> the longer you acquire debt the worse it gets</li><ul><li>cost ofcomplexty is exponential</li><li> regression deficit: more features, longer testing, until it dominates the release cycle</li><li> unsync code branches: the longer apart, the longer it will take to merge</li></ul></ul><li>Build Quality in (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#33m17s"><span style="font-size:85%;">video 33m17s</span></a>)</li><ul><li>configuration management, one click build, automated testing, continuous integration, frequent depoyment</li><li>nested synchronization: test as early and often as possible<br /></li><ul><li> every check in - unit tests</li><li> evrery day - regression test harness</li><li> every week - operations test harness</li><li> every iteration - deployment ready code</li></ul></ul></ul><span style="font-weight: bold;"><span style="font-size:130%;">Let it flow</span> </span>(<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#43m40s"><span style="font-size:85%;">video 43m40s</span></a>)<ul><li> cycle time : customer problem to customer solution.</li><ul><li> software development cycle time: requests to deployment</li></ul><li style="font-weight: bold;"> process capability: wether you have or not a reliable and repetible cycle time for a given set of problems<br /></li><li> delays: hint of opportunities for cost/waste reduction</li><li> queuing theory</li><ul><li> total cycle time = number of things in process / average completion rate </li><li> shorter cycle time: ability to add new features</li><li>small tasks and slack decrease the total cycle time<br /></li><ul><li> utilization paradox (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#48m23s">48m23s</a>) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.<br /></li></ul></ul><li>Keep a <strong>honest queue</strong>/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues</li><li>Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.<br /></li></ul><span style="font-size:130%;"><span style="font-weight: bold;">System meassurements</span></span><br /><ul><li> cycle time (lean classic) - process capability</li><li> business case (are you making money) - business return</li><li> customer satisfaction <span>—</span> sustainability</li><ul><li> net promoter score [2]</li></ul></ul><br />[1] From Matthew May's <span style="font-style: italic;">The Elegant Solution: Toyota's Formula for Mastering Innovation</span> (<span style="font-size:85%;"><a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F0743290178&amp;amp;amp;amp;amp;amp;tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F0743290178&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a></span>)<br />[2] Frederick F. Reichheld's <span style="font-style: italic;">The Ultimate Question </span>(<span style="font-size:85%;"><a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F1591397839&tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F1591397839&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a></span>)-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-85174116993178278482006-12-13T01:23:00.000+01:002006-12-13T07:05:21.426+01:00OpenUP: a short intro to the Open Unified ProcessI listened to <span style="font-weight: bold;">Introducing OpenUP</span>, a very interesting ibm internal presentation by <a href="https://www.cmpevents.com/SDe6/a.asp?option=G&V=3&id=453445">Per Kroll</a> and <a href="http://www.eclipsecon.org/2007/index.php?page=presenters/#Ricardo_Balduino">Ricardo Balduino</a>, and hosted by the Agile@IBM community. I'm highly impressed. The slide set used has quite in common with <a href="http://www.eclipse.org/epf/community/Open%20Unified%20Process%20Distilled%20by%20Kroll%20and%20Lyons.ppt">this powerpoint</a>, available in the <a href="http://www.eclipse.org/epf/">Eclipse Process Framework Project (EPF)</a> <a href="http://www.eclipse.org/epf/community/community_index.php">community news page</a>.<br /><br />Take the RUP principles, borrow freely from XP, Scrum, Agile Modelling and DSDM, shake, and you get a methodology that makes lots of sense despite having a mostly ungoogleable name...<br /><br />OpenUP/Basic is organiced around 4 subprocesses: Collaboration, Intent Management, Management, Solutions Development. It has 6 different roles.<br /><br /><a href="http://www.flickr.com/photos/70148893@N00/320824056/" title="OpenUP roles and subprocesses"><img src="http://static.flickr.com/144/320824056_1aec8ccaca_o.png" alt="OpenUP roles and subprocesses" style="background: white;" /></a><br /><br />Did you notice that the tester role works in the intent management?<br /><br />OpenUP/Basic is minimal, complete and extensible.<br /><ul><li>Minimal means that it is not the kind of methodology where you have a huge role and workproduct initial list that you have to cleanup for your project (and that usually makes you shop more than you really need...): 6 roles, 18 tasks, 20 work products, 200 printed pages.</li><li>Complete: can be manifested as an entire process to build a system (scrum does not deal with the solution construction subprocess)<br /></li><li>Extensible: can be used as a foundation on which process content can be added or tailored as needed. In fact OpenUP consists of</li><ul><li>A base process - OpenUP/Basic</li><li>Extensions to this base process, such as Model Driven Development content</li></ul></ul>The main worproducts and their realtion to roles/subprocesses can be viewed here:<br /><br /><a href="http://www.flickr.com/photos/70148893@N00/320824059/" title="OpenUP roles and workproducts"><img src="http://static.flickr.com/135/320824059_07a1295a6c_o.png" alt="OpenUP roles and workproducts" style="background: white;" /></a><br /><br />The Work Item List is very close to the scrum backlog (not only for the current iteration, but for all the project). Of course, it is iterative, a la RUP:<br /><br /><a href="http://www.flickr.com/photos/70148893@N00/320824054/" title="OpenUP Iterations"><img src="http://static.flickr.com/129/320824054_daa5bd05d3_o.png" width="450" alt="OpenUP Iterations" style="background: white;" /></a><br /><br />But adaptable! The project plan is a 2 pages doc, describing the goals for the different iterations. And, since each iteartion brings its learning, the plan changes:<br /><br /><a href="http://www.flickr.com/photos/70148893@N00/320824053/" title="OpenUP iteration assesment"><img src="http://static.flickr.com/138/320824053_5462d40428_o.png" width="400" alt="OpenUP iteration assesment" style="background: white;" /></a><br /><br />I really like the concept of "Stakeholder Satisfaction Space".<br /><br />Other things that I'd like to highlight:<br /><ul><li>daily meetings</li><li>test driven developemnt</li><li>use case based</li><li>promotes a readable representation of the architecture. <span style="font-style: italic;">Much of the architecture can be</span></li><ul><li><span style="font-style: italic;">Selected instead of designed</span> (patterns)</li><li><span style="font-style: italic;">Referenced instead of described</span> </li></ul></ul><br />OpenUP/Basic instantiates the core values of the <a href="http://agilemanifesto.org/">agile manifesto</a> in some slightly more concrete core principles:<table style="border-style: solid; border-color: black;"><tbody><tr><td style="font-weight: bold;">OpenUP/Basic Key principles</td><td style="font-weight: bold;">Agile manifesto</td></tr><tr><td>Collaborate to align interests and share understanding</td><td>Individuals and interactions overprocess and tools</td></tr><tr><td>Evolve to continuously obtain feedback and improve</td><td>Responding to change over following a plan</td></tr><tr><td>Balance competing priorities to maximize stakeholder value</td><td>Customer collaboration over contract negotiation</td></tr><tr><td>Focus on articulating the architecture</td><td>Working software over comprehensive documentation</td></tr></tbody></table><br />Does it work? I cannot tell, but at least looks like its building blocks have proven to work often.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com1tag:blogger.com,1999:blog-9115644605833384138.post-5433343381861036062006-12-06T11:55:00.000+01:002006-12-06T14:05:52.301+01:00dW chats: Grady Booch on the latest Rational tools releaseAnother developerWorks chat that looks very interesting: <a href="http://www.ibm.com/developerworks/rational/chat/booch.html">Grady Booch answers your questions about this week's Rational tools release</a>. On Thursday December 7th, at <a href="http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=7&amp;amp;amp;year=2006&hour=16&min=30&sec=0&p1=179">4:30 pm his time or 10:30 pm my time</a>.<br /><br />I did not learn about this <a href="http://www.ibm.com/developerworks/blogs/page/gradybooch?entry=empowering_the_a_in_soa">from Booch's blog itself</a>, but from a comment by <a href="http://www.rodenas.org/blog/">Ferran Rodenas</a> to a <a href="http://kellypuffs.wordpress.com/2006/12/05/rational-software-delivery-platform-v70-released/#comments">post in Kelly Drahzal's blog</a>. The interesting bit about this is that Ferran works for "la Caixa", a very important ibm client, and it is a very good thing for me and some team mates to be able to read his posts and keep track of his blogroll. Or explore <a href="http://www.linkedin.com/in/frodenas">his linkedin profile</a> and our common connections. The openess that blogs and social software have brought rocks!-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com2tag:blogger.com,1999:blog-9115644605833384138.post-52376862091731804912006-12-05T00:50:00.000+01:002006-12-05T00:54:27.726+01:00dW chats: Making the move to AjaxIBM Rational's <a href="http://www-03.ibm.com/developerworks/blogs/page/BillHiggins">Bill Higgins</a> will be the moderator of a <a href="http://www-03.ibm.com/developerworks/blogs/page/BillHiggins?entry=ajax_chat_with_me_wed">developerWorks chat on Ajax</a>. to be held on Wednesday December 6th at <a href="http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=6&amp;amp;year=2006&hour=13&min=0&sec=0&p1=179">1pm his time or 7pm my time</a>. I was not aware of these dW chats going on (this is the second one, <a href="http://www-128.ibm.com/developerworks/java/chat/glover.html">as far as I've seen</a>).-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-12373329414255798872006-11-15T00:25:00.000+01:002006-12-13T12:39:32.494+01:00No lo leeránNo sólo este blog, sino gran parte de la documentación que se escribe en los proyectos de desarrollo de software.<br /><br />Después del <a href="http://xp.c2.com/YouArentGonnaNeedIt.html">No Lo Necesitarás</a>, el <a href="http://www.agilemodeling.com/essays/tagri.htm">No Lo Leerán</a>. O YAGNI (You Aren't Gonna Need It) y TAGRI (They Aren't Gonna <del>Need</del> Read It). Dos grandes principios que es bueno recordar en el desarrollo de software, al escribir artículos y correo, al hacer la carta a los Reyes, al ir a la ferretería...-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com3