Gooddata is growing. I see new faces in our office every Monday. The Gooddata "legacy" is often under fire. Our new colleagues come from many different environments and bring new ideas and perspectives. That's how we got to the RUP vs Agile discussion.
We practice agile development (scrum) at Gooddata. We have just proudly started our fifth sprint. Our mantra is design, build & re-factor. Iterate quickly until it is done. And suddenly there is a new Yam (yet-another-Martin in our office) who talks about the old good Rational Unified Process. Analysis, design, implementation, deployment. Requirements, use-cases, class and sequence diagrams, logical and physical models etc.
So where is the truth? Where the agile meets RUP? How to marry concepts of these two worlds? I believe that RUP tells us WHAT we need to deliver (use-cases, diagrams, models, schemas, code and deployments) and Agile shows HOW to deliver all the above. The essential pieces that we can't live without need to go to the first iteration of the RUP delivery cycle. All the rest will follow in subsequent iterations. If an iteration crashes because of a new findings, we simply restart it. If we need to dump everything what we have done in an previous iteration we will dump it. If we keep the iterations very short we are not going to regret such loses. And we need to realize that we do not need to go all the way down from use-case to deployment in every iteration. The first iteration can end up with a half-baked command-line script that pretends some functionality rather than fully fledged component with all belts and whistles. We can get to deployment, REST API or whatever it needs later.
I believe that we can have the best from both worlds. Let's blend the proven methodology, useful deliverables and tools from the RUP with the agility, flexibility and efficiency that comes from the Agile. Quickly define the Gooddata way, start using it knowing that we are going to re-factor it million times in the Gooddata future. :)
5 comments:
Sounds good. Obviously, the RUP deliverables do serve a purpose - they document every step of design & development process.
The real question is though - can they be produced swiftly, without lengthening the iteration cycle considerably? That's the answer I'll be looking for in the upcoming weeks.
Lets see it from a different angle. If we dont use RUP for analyse and documentation, do we have something else which is: easier to use, simpler AND standardized ? Using RUP with all the bells and whistles is an overkill, but if we want to analyse before implementing, we should stick to some standard. And I think UML is the way to go.
Ultimately, I believe the methodology is largely irrelevant. A good team will succeed, within limitations, with almost any methodology; and no approach ever invented will save a bad team from fucking up.
In the end, it's all common sense.
Find the process that fits your project.
I have implemented some XP practices in waterfall model projects.
when you create documents, they should be done to improve your understanding of a business/technical problem and not be print some you already knew.
The RUP does have some pretty good advice on what to deliver and how to do requirements and design.
Unfortunately, a lot of it is overkill and buried in a lot of bad advice as well.
The RUP can not be taken as is and apply to an agile project. As to the question about other approaches to requirements analysis and design there certainly are alternatives that could still be considered "RUP compliant"
Take classical "use case realizations" or OOAD as recommended by RUP. I prefer taking concepts from Domain Driven Design as well as CRC-based modeling techniques.
Most versions of use cases as described by RUP practitioners are not to my taste either, for a more agile blend of use cases I like to follow the approach is recommended by Alastair Cockburn.
I just finished a couple of posts on mixing agile RUP which can be found@
agile over RUP
Further comments or feedback welcome
regards
Jeff Anderson
http://agileconsulting.blogspot.com
Post a Comment