Reading about Agile Is Pretty Simple (which is a good thing...)
In my previous post on my preferred development approach, Agile over RUP, My Preferred Development Approach I touched upon the idea that mixing Agile with a more structured methodology like the Rational Unified Process (or the unified process in general) was a good way to combine what I see as a energetic, creative and real-time approach with a structured, more methodical framework that can help to organize large-scale projects.. I then went on to describe what agile means to me, and gave a summary of the agile best practices that I found useful on projects that I have been a part of.In general, talking about agile is relatively straightforward. The practices are deceptively simple, and relatively easy to explain. The real difficulty in agile is in the implementation. I have probably been attempting to use "agile development" since early 2000, and I'm still probably learning at an incredible rate. I doubt that this rate of learning is going to decrease anytime soon, getting agile right is actually quite hard to do, but then again so is real success. IMHO this is all about what a good process should be, really easy to read, and incredibly hard to master.
Reading about the Rational Unified Process Is Pretty Complex (Which Isn't a Good Thing...)
The Rational Unified Process, on the other hand is a fully featured software development lifecycle framework that tries to encompass all aspects of software delivery. Unfortunately this leaves consumers of RUP with the impossible task of trying to get one's head around a complex, dense, and sometimes contradictory piece of work.
It's important to note that the creators of RUP refer to the unified process as a process framework, meaning that the process should be customized to the particular needs of a project, program or IT organization. RUP should not be taken out of the box and applied as is.
The RUP framework is a complex web of disciplines, (specific skill sets, i.e. requirements, design, development, etc.) phases, (product lifecycle stages i.e. inception, construction, etc.) process groupings, processes, artifacts, templates, gating criteria, and a bunch of other detailed process material, enough to make process geeks the whole world over cackle with glee, much to the detriment of those of us who are actually trying to get some work done. Here's a quick picture of all the pieces of RUP, written in UML, taken from my memory
So what's wrong with the above picture? For one, its complexity and sheer volume of information makes it incredibly difficult to actually find the valuable pieces of the process. Unfortunately, as of the last time I looked at the Rational Unified Process (which to be fair is ever evolving) it contained some incredibly good information (especially in the requirements and analysis and design of object-oriented systems) but there was a huge amount of process details that appear to be ad hoc, and added just to make the process complete. This seems to be a systemic problem of any detailed and "comprehensive" software methodology. The quality of different pieces of the process vary incredibly (the project management and testing is laughably bad), and it takes a very intimate knowledge of the process framework and some very real experience using it to determine what to use and what to completely ignore.
But even if all aspects of the rational unified process were of proper quality, RUP is just too complex.
But RUP Still Has Incredible Value, It Just Needs to Be Pared down a Little...
Since RUP is a process framework, it's okay to actually tailor it to make it compatible with an useful style of delivery, in fact many of the fundamental pieces of RUP are completely compatible with an agile way of doing things.Listed below are the portions of the rational unified process that I consider actually valuable to a software development project...
phases like it or not, the kind of work you do during specific iterations are going to change over the length of any project, lightly applying a notion of a lifecycle is a good idea
disciplines, while agile projects categorized work into just a couple of roles, there really is more involved if you consider all aspects of delivery, RUP disciplines represent a reasonable way to organize the different types of work that need to be done, just be flexible in applying multiple roles to the same person
principles and best practices are IMHO the most important part of the process. By tweaking the RUP best practices and principles to be a little more agile in nature, you're left with a solid foundation in which to base your development and delivery.
Roles as stated previously, agile only has a couple of roles (e.g. Product Owner, Scrum Master, Developer) I personally like to see this list expanded, as long as everyone is clear that each single role does not equal one person, each person needs to fulfill many different roles.
Discipline Oriented Guidelines where many software development processes fail is that they offer either too little advice, or offer to much and present this advice as standards that must be followed. Detailed process material should be represented as a suite of advice, patterns, and lessons learned based on real project experience. Above all this detailed process work needs to be presented as accelerators that can but don't have to be used. I think it's also okay to base guidance on the work of established authors, but make sure you test the waters on a real project before socializing the guidance across different project teams. So far, I have based my guidance, and implemented real projects, on work presented by the following authors, of course this is a continuing work in progress...
Kent Beck (Implementation Patterns and Test Driven Development)
and a whole bunch of other stuff...
Please refer to
Part 3 of this post for further details of other valuable components of RUP
No comments:
Post a Comment