What is UP? Definition from Wikipedia - IBM RUP
What is Agile? Definition from Wikipedia - Agile software development
Comparison of UP & Agile
"
Software development processes define a list of activities to undertake, what order the activities should proceed in, what the inputs and outputs of each activity should be, etc. What few software process specifies is when to stop. It’s often too easy to overuse a process, and continue to produce system designs, resulting in a heavyweight, document centric process. Essentially, process is followed for process sake, rather than adding value to the stakeholders of the project.
Although UP is iterative, it follows the general phases of inception, elaboration, construction, and transition in a more or less linear fashion. As the development proceeds less time is spent on requirements and analysis, and more time is spent on construction, testing, and transition.
Agile processes on the other hand, spend time on each activity in each iteration. During each iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development, test, etc.) are undertaken. The goal is to have stable software which could be shipped at the end of each iteration. At the beginning of each iteration, all stakeholders meet to reorganise requirements and their priorities, while at the end of the iteration, working software is demonstrated to the stakeholders. This ensures that customer value is being added at all times, and that progress is being made on what matters, working software.
UP and its relative the Rational Unified Process (RUP) are quire comprehensive, and were designed to be modified to suit the project being developed. This adds another layer of complexity to the development effort, as the process has first to be modified before being implemented. While this allows for the flexibility to use UP on any project, it requires teams to have access to UP experts to ensure that the process is being defined and used properly.
Agile on the other hand tends to be used for small to medium sized projects involving teams up to 10 closely knit developers. Once teams become bigger than this, agile methodologies begin to fail, as they don’t scale to large teams, or teams spread across geographies." - from chris blog
Which one is better and which one to use?
like what chris said in his blog "there is no silver bullet, or one size fits all approach. You need to tailor the process to the project and your individual circumstances. " Agile strike a good balance between process and productivity, but there is some project out there where agile may be an inappropriate process of choice. RUP is great, but you have to have experienced people doing RUP projects as you don't want to overload everyone with documentation, but also have to carefully look at what the customer wants.
One important difference (from dennis) between UP & Agile is that communication in UP is more through documents where as in Agile it's face to face communcation between the customer and the entire team.
SCRUM - What is SCRUM? Definition from Wikipedia - SCRUM
Scrum is an iterative incremental process of software development commonly used with agile software development.
Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach.
Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the "ScrumMaster" who maintains the processes and works similarly to a project manager, the "Product Owner" who represents the stakeholders, and the "Team" which includes the developers.
During each "sprint", typically a 2–4 week period (length decided by the team), the team creates an increment of usable software. The set of features that go into a sprint come from the product "backlog", which is a prioritized set of high level requirements of work to be done.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process which range from yellow stickers and whiteboards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.
Scrum Meetings
Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a "scrum", or "the daily standup". The scrum has specific guidelines:
* The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
* All are welcome, but only "pigs" may speak
* The meeting is timeboxed at 15 minutes regardless of the team's size
* All attendees should stand (it helps to keep meeting short)
* The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
* What have you done since yesterday?
* What are you planning to do by today?
* Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)
Sprint Planning Meeting
At the beginning of the sprint cycle (every 15–30 days), a "Sprint Planning Meeting" is held.
* Select what work is to be done
* Prepare the Sprint Backlog that details the time it will take to do that work
* 8 hour limit
Sprint Review Meeting
At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective"
* Review the work that was completed and not completed
* Present the completed work to the stakeholders (a.k.a. "the demo")
* Incomplete work cannot be demonstrated
* 4 hour time limit
Sprint Retrospective
* All team members reflect on the past sprint.
* Make continuous process improvement.
* Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
* 3 hour time limit
Please refer to wikipedia for more about role, artifaces in scrum
Scrum is kind of adaptive project management and here are some general practices of Scrum:
* Customers become a part of the development team (i.e. the customer must be genuinely interested in the output.)
* Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
* Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.
* Transparency in planning and module development—let everyone know who is accountable for what and by when.
* Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)
* There should be an advance warning mechanism, i.e. visibility to potential slippage or deviation ahead of time.
* No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
* Workplaces and working hours must be energized—"Working more hours" does not necessarily mean "producing more output."
Reference URLs:
Agile Modeling and the Rational Unified Process (RUP)
Posts
Highscalability is Up For Sale
1 year ago
No comments:
Post a Comment