Showing posts with label Agile. Show all posts
Differences Between Scrum and Extreme Programming
Differences Between Scrum and Extreme Programming
four main differences between Scrum and XP:
Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.
Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.
Extreme Programming teams work in a strict priority order.Features to be developed are prioritized by the customer (Scrum’s Product Owner) and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.
Scrum doesn’t prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on
Scrum and XP (aka Extreme Programming), both agile software development methodologies based on the iterative and incremental development. They do have similarities but also have differences and here is my attempt to briefly highlight the differences:
1. Scrum is more high level, focusing on the management of the project (e.g. the requirements or features are managed) rather than specifying or defining engineering practice such as pair programming or test driven development
2. The length of an iteration in XP is usually 1-3 weeks whereas, in Scrum sprints are 1-4 weeks
3. Once sprint (or iteration in XP) starts, customer cannot change the requirements, in other words the customer will have to wait until the sprint (or iteration in XP) finishes. In XP however, requirements can change anytime
4. In XP features are developed in a strict order whereas in Scrum, the team is free to choose the features to be developed. Sequence does not matter
5. Both XP and Scrum define the role of a coach, In Scrum it is called Scrum Master and requires (or strongly recommended) certification, whereas, XP defines the role of coach quite informally and the role may float between members of the team.
Scrum and XP are often used together: Scrum defines the framework and XP defines the engineering practices and they fit together nicely.
What is SCRUM?
Introduction
SCRUM is a set of guidelines that control the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:
confusion due to changing requirements
Unrealistic estimates of time, cost, and quality of the product
Developers are forced to lie about how the project is progressing
SCRUM Values
The SCRUM values are derived from the Agile values of software development.
Individuals and interactions over processes and tools - processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion.
Working software over comprehensive documentation - documentation is important, but what's most important is to have working software.
Customer collaboration over contract negotiation - you are not just looking to get a contract and get money that way - you are solving the customer's problem.
Responding to change over following a plan - if the requirements or perceived requirements changed, so should the plans and design.
The SCRUM Process
The scrum process has 3 main phases.
Planning
In this phase, the project is planned and high-level design decisions are made.
Sprint Cycle
The sprint cycle is an iterative cycle of about 3-4 weeks, in which the actual development of the product is done. It starts out with a Sprint Planning Meeting to decide what will be done in the current sprint. Then the development is done. A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.
The sprint cycle is repeated until the product's development is complete. The product is complete when the variables of time, quality, competition, and cost are at a balance.
Develop the product further - implement, test, and document.
Wrap up the work - get it ready to be evaluated and integrated.
Review the work done in this sprint.
Adjust for any changes in requirements or plans.
Closure
In this phase, the product's development is brought to a close, and the product is released.
Commonly Used Terms
Sprint
The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint Planning Meeting is held to determine what features are to be implemented in that sprint. The sprint has 4 major steps:
Develop the product further - implement, test, and document.
Wrap up the work - get it ready to be evaluated and integrated.
Review the work done in this sprint.
Adjust for any changes in requirements or plans.
Product Backlog
A prioritized list of all the desired changes to the product being developed, put together by the product owner.
Sprint BackLog
A list with items that will be completed in the current sprint, taken from the product backlog
Daily SCRUM Meeting
A 15-minute SCRUM meeting is held every day. The SCRUM Master asks the three questions, and all members of the team and interested parties take part and give feedback. The meeting should be held at the same place every time, so that people know where to go.
Unit Testing
A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration
Impediment
Impediments are things that get in the way of the progress of the project. The SCRUM Master is responsible to look for and remove these obstacles so that they do not slow down or impair the project.
3 Questions
The Scrum Master asks the developers 3 important questions at every SCRUM meeting:
What have you accomplished since the last meeting?
Are there any obstacles in the way of meeting your goal?
What will you accomplish before the next meeting?
Product Owner
The person who commissions the project, and defines the requirements and priorities for the product.
Sprint Planning Meeting
A meeting at the beginning of a sprint where the sprint is planned. Items from the Product Backlog are selected to be completed in the sprint, based on the priorities set by the Product Owner.
Sprint Review Meeting
A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.
What Is Extreme Programming?
Introduction
Extreme Programming is a combination of simple, common-sense practices stressing communication, teamwork, requirements, and customer satisfaction. It is based on these values:
Communication - in order to successfully create and deliver a software product on time, there must be constant and thorough communication between members of the development team.
Feedback - Customer involvement and feedback are essential for customer satisfaction.
Simplicity - XP stresses the need to keep things as simple as possible while meeting the requirements laid out for the project.
Courage - Developers must have the courage and confidence to bring change and produce quality results
Core concepts in XP
Pair Programming
XP assumes that people work best in pairs so that they complement each other's strengths and weaknesses and so that knowledge can be spread between members of the team. The benefits as far as design, bug elimination, etc., can make two programmers at one computer be much more effective than they would be if they were each at separate computers.
Benefits of pair programming.
Economics, Satisfaction, Design quality, Continuous Reviews. Problem solving.Learning. Team Building and Communication.Staff and Project Management.
Stories and Test/Requirement-Driven Development
A project's requirements are laid out as individual stories. These stories have test cases. A test case includes the test and the desired results which, if met, indicate that that story is complete.
The project is done in iterations. At the end of an iteration, the next iteration is planned out in an iteration planning meeting. The customer (with the developers' guidance, of course) decides what stories are to be implemented in the next iteration, based on what is most important to them, and what is most practical to implement next.
It is important that each iteration takes just as long as all the others in a given project. The time that it took to complete a given story is recorded so that the programmers get a good feel for how much effort it takes to do that type of work.
The stories are broken down into tasks, which are the steps needed to implement a given user story. Developers then sign up to do those tasks.
On the completion of an iteration, acceptance tests are done to ensure that the test cases defined in that story have been met. The acceptance tests include both automated unit testing, and customer testing. This makes sure that all requirements are reached because the development is based around those requirements and there are definite indicators on whether a given requirement is met. It also breaks down the project into reachable goals rather than having programmers work away forever on an ever-expanding megalith.
Continuous Integration
Continuous integration eliminates the headaches of working with outdated code and trying to integrate fragmented or diverging code into the system.