Just got back from my cool-o coworker Nate Oster‘s OpenUP Distilled presentation at SD Best Practices (okay, it wasn’t really given to a lama – but ya gotta admit, that’s a cool picture and only goes to show that while maybe not a hax0r like myself, Nate truly is a much better geek than I. Yes, that really is UML he’s explaining to the lama).
Working with Nate at Number Six, I’ve of course been reading up on OpenUP. But, I have to say seeing the presentation after all of these other talks on agile really helped put it into a new light.
OpenUP is the open source, agile version of the Unified Process, to which Number Six (and Nate, in particular) have been large contributors. At first glance, if you’re not paying close attention, it looks an awful lot like the same ol’ UP we know and love with the good ol’ IECT.
But then you start digging in and you realize that this is not your father’s unified process. With Test-Driven Development (TDD), just in time planning from a product backlog, agile estimation techniques like velocity, executable (rather than documented) artifacts, 4 week iterations resulting in demo-able/shippable builds, and micro-increments measured in hours – well, huh, now you find yourself wondering, how is this actually different from the other agile processes?
After 10 agile presentations, it all starts blurring together a bit.
But then you start to realize that wait, a lot of those things that you just don’t feel quite comfortable with agile – you know, the lack of architecture and reduced focus on risk, the lack of requirement details… OpenUP still keeps UP’s architecture-centric focus (executable architectures, mind you, not boxes and arrows), it’s risk-driven approach, and yes, even the use cases we all know and love. Of course, you can swap those out for user stories if you want (I’m still trying to understand how well use cases will jive with the agile estimation/4 week iterations – but I’d like to see this work), because it’s just as customizable as the old RUP.
So, I’m really jazzed about this (pardon the pun). I think this is a very real approach that will appeal to hax0rs who worry that agile feels a bit too close to, well, hack and fix.