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.comBlogger1125tag: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.com0