According to WikiPedia:
Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.
Although the Scrum approach was originally suggested for managing product development projects, its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach.Here is a video that talks about scrum and what the scrum master does:
Now for RUP and what WikiPedia says:
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.
Here is a video that talks about RUP here:
So, which process is better? SCRUM OR RUP?
Well, there isn't a magic bullet or a one size fits all development process for everyone, so we aren't going to declare a winner. However, here, at Axosoft, we are biased towards Scrum because OnTime was made to be great agile scrum software, we still believe in other development processes. We would be interested in learning more about what your thoughts are on both development processes. Contact us or post in the comments.
This blog is finally active again, so please subscribe to our feed to get the latest info about scrum and scrum development!
3 comments:
"The team was killing themselves trying to get the defect counts within the acceptance criteria "
sounds like there was a clear indication that your backlog items were too big or the team was underestimating. What did the team think? Were there a lot of surprise acceptance tests in the middle of sprints that the team hadn't accounted for? Maybe those should have been new story cards or new backlog items.
In SCRUM, even a 5 week iteration is on the long side. To go to a 3 month iteration sounds an awfully lot like Water Fall and definitely not Agile. Part of the intent of Agile/Scrum development as I get it is to work off small, logical chunks of work and get them to the end user as soon as possible. You continuously build code and as each area of functionality is complete, the product owner decides if there is value to release, or if there is a mis-direction. If you go in 3 month chunks, you can really miss the mark and be way out in left field long before you realize you left the base line.
Excellent call out. One thing to note, though, is that the iterations are 3 months, not the sprints. The sprints still remained 1 month long. There would be a formal review of the release every three months. Thanks for the comments!
Post a Comment