The RUP Factor
Mar 25th, 2007 by Sandra
Or, How the Rational Unified Process Nearly Did Me In
I came into a new tech writing job back in December 2006. The company is fantastic, encourages employee personal and professional growth, and is generally a spanking good place to work. I worked on a distributed team that produced the first round of an online help system for a mature product that was being rewritten for greater security, performance, and usability. Phase 1 was due to go into code freeze on March 16. The Tech Comm team kicked ass and took names.
I listened in on some of the weekly project management conference calls and folks talked a lot about RUP: they were doing this for iteration 1; they were completing the Elaboration phase and moving into the Transition phase. The Tech Comm managers participated in these calls, but didn’t say anything to the TC team about RUP or what would be expected of us. It didn’t even occur to me to ask what the heck RUP was. I found some really confusing stuff on the internet about it, but you know how it is — you’re busy and you have to get this section of the online help finished and working.
Then we came to the end of the project and I found myself, as lead writer on the project, up the proverbial creek. I was used to a waterfall methodology, so I was anticipating at least a couple of weeks to get help errors sorted out. But nope. Come March 16, that was all she wrote (literally). If a help button was hooked up to the wrong help topic, too bad.
Hence this series of short articles about how RUP impacted us, how we’re working our way through the process of getting RUPified, and the end result for Phase 2 of our software project.
This page has the following sub pages.