RUP: A more comprehensive analysis
Today I attended a meeting where IBM/Rational got to extol their glorious Unified Process (RUP). RUP has a lot of good sides, and I think a lot of the high-level ideas are very good. Phases, workflows, artifacts, and roles all make sense. The concepts can be used to understand any process, even “non-processes” like code-and-hack. The central question then is whether the components of RUP individually are the right ones for a given project and whether their composition is appropriate.
IBM repeatedly highlighted the configurability of RUP. This configurability is an answer to many of the objections in this memo.
However, at some point in time one must ask oneself whether it makes any sense to call what one is doing RUP. The speaker from IBM asserted that he had been doing RUP-for-one as well as RUP for as small teams as 3. I felt he was stretching RUP meaninglessly far. With his interpretation of RUP, I could merely assert “I am doing RUP” and carry on without changing the way I work!
Anyho: to the details. I think RUP gets the following core parts wrong:
Read the rest of this entry »
Permalink Comments off
