Introduction To Xp And Scrum Practices

Introduction to XP and Scrum

Pradyumn Sharma
pradyumn.sharma@pragatisoftware.com
Pragati Software Pvt. Ltd.
www.pragatisoftware.com

Pragati Software Pvt. Ltd., 312, Lok Center, Marol-Maroshi Road, Marol, Andheri (East), Mumbai 400 059. www.pragatisoftware.com

Agile Software Development Methodologies

• Useful compromise between no process and too much
process.
• Suitable for responding to changing customer requirements.
Adaptive rather than being predictive.
• Work well even for predictable requirements.
• People-oriented as against being process-oriented.


Introduction to Extreme Programming (XP)

• Pioneered by Kent Beck, along with Ward Cunningham and
Ron Jeffries.
• A set of useful guidelines or best practices for handling
software development projects.
• Strong emphasis on small iterations, simple design, and test-
driven development.


Five Core Values of XP

• Communication
• Simplicity
• Feedback
• Courage
• Respect


Overview of XP: Practices

Primary practices (13) Secondary practices (11)
• User stories •Customer involvement
• Weekly cycle (iteration planning) •Shared code
• Test-first programming •Root-cause analysis
• Incremental design •Code and tests
• Continuous integration •Single code base
• Ten minute build •Incremental deployment
• Pair programming •Team continuity
• Energized work •Shrinking teams
• Quarterly cycle •Daily deployment
• Sit together •Negotiated scope contract
• Whole team •Pay-per-use
• Informative workplace
• Slack


Stories

• Story = customer-visible functionality provided by a system.
• Build a list of stories based on discussions with customers.
Just note down the names initially.
• Role of stories:
 Estimation
 Scope definition for a release cycle
 Units of planning and monitoring a system
 Prioritization by customers.
 Risk assessment and estimation by developers.


Pair Programming

• Two programmers working together for some programming
task.
• Benefits:
 Knowledge sharing
 Better quality
 Coding standards
 On-going code reviews
 Ease of inducting new team members (mentoring)
 Mutual learning
 Improved productivity


Planning: Release Cycles and Weekly Iterations

• Small releases: providing quick value to customers and
feedback to developers.
• Release planning involves both customers and developers.
• Customers prioritize the stories based on their value to them,
developers estimate the time required.
• Divide a release cycle further into weekly iterations for all
work planning and monitoring.


Slack

• Important to establish and maintain the credibility of the
release plans.
• It is better to undercommit and deliver what is committed,
rather than overcommit and underdeliver.
• Introduce slack in your release plan, but not slyly.
• Slack = including low value, non-critical stories in the release
plan that can be dropped if the schedule starts slipping


Test-First Programming

• Write tests for all code before you code.
• Automate the tests. Open-source testing tools, such as JUnit,
There are tools such as JUnit, NUnit, HttpTest, Fit, etc.
available for this purpose.
• A code is completed only when it passes all tests.
• Maintain the tests along with your code.
• Write code at various levels: unit tests, acceptance tests, etc.


Incremental Design

• Avoid “complete design before implementation”.
• According to a Standish Group report:
 7% of features and functions are always used, 12% are often used,
16% are sometimes used, 19% are rarely used, 45% are never used.
• Design what is needed now. Keep investing in the design
every day.
• Create spike solutions to tackle tough technical or design
problems.
• Design done close to when it is needed is more efficient.
• Refactor your design as you go ahead.


Ten-Minute Build

• Automate the build and run cycle, to be completed within ten
minutes.


Continuous Integration

• Integrate and test code every few hours.
• Dedicate one machine for integration.
• If any tests fail, we know we broke it, and must therefore fix
it, or throw away what we did.
• Cost of packaging a release is minimal.
• Open-source tool: CruiseControl


Shared Code

• Nobody owns any code and everybody owns all the code.
• Anybody can change any line of code anywhere, to add
functionality, fix bugs, or refactor.
• Works well because of refactoring and unit tests.
• Eliminates the need for separate code reviews.


Real Customer Involvement

• Customer writes user stories, acceptance tests, and answers
queries of developers.
• Negotiates a set of stories to be included in each scheduled
release.
• Benefits:
 Priorities can be set / adjusted in real-time
 No need to have water-tight requirements
 Customer is available to help make course corrections as clarity
emerges gradually about the requirements, effort estimates and
consequences
 Customer participates in discussions and planning meetings; has
greater understanding of technical issues and status of the progress.


Energized Work

• Projects requiring overtime to finish in time will finish late,
no matter what.
• Overtime is a symptom of a serious problem with the project.


Quarterly Cycle

• At the macro level, plan work a quarter at a time.
 Identify bottlenecks
 Identify and initiate corrective steps
 Focus on the big picture, where the project fits within the
organization.
• Take stock of the project, the team, and its progress.


Root-Cause Analysis

• Whenever a defect is found after development, eliminate the
defect and its cause. Follow the steps given below:
 Write an automated system-level test to demonstrate the defect.
 Write a unit test to reproduce the defect.
 Fix the system so that the unit test works. The system test should also
pass. Run the entire test suite of the application.
 Analyze why the defect was created and was not caught. Initiate the
necessary changes to prevent such a defect in future. [Taiichi Ohno’s
Five Whys is a good technique for this.]


Single Code Base

• Maintain a single code stream.
• Having multiple versions of code results in maintenance
nightmares.
• Temporary branches should be for very short durations only.


Code and Tests

• Maintain only code and tests as permanent artifacts.
• Generate documents from the code and tests.


Other Practices

• Sit Together:
 Develop in an open space big enough for the whole team.
• Whole Team:
 Create a cross-functional team, with all the skills and perspectives
needed for the project to succeed.
• Informative Workspace:
 Display information about the project status all over in the workspace.
 Place user story cards or big charts for issues that require steady
progress.


Other Practices (contd…)

• Incremental Deployment:
 When taking over a legacy system, gradually take over its workload
beginning very early in the project. No “cut over” during a weekend.
• Team Continuity:
 Keep effective teams together. At the end of a project, don’t send the
programmers to the “pool”.
• Shrinking Teams:
 As the team grows in capability, keep its workload constant but
gradually reduce its size. Free people to form more teams.
 If a team is too small, merge it with another very small team.
• Daily Deployment:
 Put new software into production every night.


Other Practices (contd…)

• Negotiated Scope Contract
 Write contracts for software development that fix time, cost, and
quality, but call for an ongoing negotiation of the precise scope of the
system.
 Reduce risk by signing a sequence of short contracts instead of one
long one.
 Split big, long contracts in smaller ones.
• Pay-Per-Use


Introduction to Scrum

• Another prominent agile methodology.
• Co-developed by Jeff Sutherland and Ken Schwaber in the
early 1990s.
• While XP practices are more programmer-centric, Scrum
practices are geared towards the project managers.
• XP and Scrum complement each other very well.


Overview of Scrum
The core of Scrum is an interative, incremental process skeleton.
At the start of each iteration, the team selects what it can implement
by the end of the iteration, by looking at the requirements,
technology available, its skills and capabilities.
The team is then left alone to implement the chosen functionality.


Overview of Scrum

• Three roles:
 Product Owner
 Team
 ScrumMaster
• Three artifacts:
 Product Backlog
 Sprint Backlog
 Increment of potentially shippable product functionality
• Scrum Flow
 Project Vision
 Product Backlog
 Sprint
• Sprint planning meeting
• Daily Scrum meeting
• Sprint review meeting
• Sprint restrospective meeting


Scrum Process


Product Owner

• Represents the interests of all the stakeholders
• Achieves initial and ongoing funding for the project by
creating
 the project's initial overall requirements
 ROI objectives
 release plans
• Frequently prioritizes the Product Backlog to ensure that the
most valuable functionality is produced first and built upon


Team

• Responsible for developing functionality.
• Teams are self-managing, self-organizing, cross-functional.
• Responsible for
 figuring out how to turn Product Backlog into an increment of
functionality
 managing their own work to do so
 success of each iteration and of the project as a whole


ScrumMaster

• Responsible for
 the Scrum process
 teaching Scrum to everyone involved in the project
 implementing Scrum so that it fits within an organization's culture
and still delivers the expected benefits
 ensuring that everyone follows Scrum rules and practices


Scrum Flow

• Project Vision
• Product Backlog
• Sprint
 Sprint planning meeting
 Daily Scrum meeting
 Sprint review meeting
 Sprint restrospective meeting


Project Vision

• A project starts with a vision of the system to be developed.
 May be vague initially, but will become clearer as the project moves
forward
 Product Owner is responsible (to those funding the project) for
delivering the vision in a manner that maximizes their ROI.


Product Backlog

• Product owner formulates a plan for delivering the vision that
includes a Product Backlog.
• List of functional and nonfunctional requirements.
• Prioritized so that the items most likely to generate value are
top priority and divided into proposed releases.
• Prioritized Product Backlog is the starting point.
• Contents, priorities, groupings into releases may change the
moment the project starts.
• Changes in the Product Backlog reflect changing business
requirements and the speed with which the Team can
transform the Product Backlog into functionality.


Sprint

• All work is done in Sprints.
• An iteration of 30 consecutive calendar days.
• The Team can seek outside help, information, support.
• No one can provide advice, instructions, etc. to the Team
during the Sprint. The Team is self-managing.
• The Team is committed to the Product Backlog selected
during the Spring Planning meeting. The Product Backlog is
frozen, and no one is allowed to change this Product Backlog
during the Sprint.
• If the Sprint proves to be unviable, the ScrumMaster can
terminate the Sprint and initiate a new Sprint planning
meeting.


Sprint Planning Meeting

• At the start of a Sprint, there is a Sprint planning meeting. In
this meeting, Product Owner and Team get together to
collaborate about what will be done for the next Sprint.
• Product Owner tells the team what is desired. The Team tells
the Product Owner how much it believes it can turn into
functionality over the next Sprint.
• Time-boxed to a maximum of eight hours. Divided into two
parts. The first part is for selecting Product Backlog, the
second part is for preparing a Sprint Backlog.


Daily Scrum Meeting

• 15-minute team meeting at the start of each day.
• Each team members answers three questions:
 what have you done on the project since the last Daily Scrum meeting
 what do you plan on doing on this project between now and the next
Daily Scrum meeting
 what are the obstacles
• Purpose of the meeting:
 synchronize the work of all Team members
 schedule any meetings that the Team needs to forward its progress


Sprint Review Meeting

• Held at the end of a Sprint.
• Timeboxed to four hours.
• Team presents what was developed during the Sprint to the
Product Owner and any other stakeholders who want to
attend.
• Functionality that isn't quot;donequot; cannot be presented.
• Majority of the Sprint review is spent in presenting
functionality, answering stakeholder questions, noting desired
changes.
• At the end, the stakeholders are polled to get their
impressions, any desired changes, the priority of these
changes.
• Brings people together and helps them collaboratively
determine what the Team should do next.


Sprint Retrospective Meeting

• Conducted by the ScrumMaster. Attended only by the Team,
the ScrumMaster, and the Product Owner (optional).
• Timeboxed to three hours.
• Team is encouraged to revise its development process to
make it more effective and enjoyable for the next Sprint.
• ScrumMaster starts by asking all the Team members:
 what went well during the last Sprint?
 what could be improved in the next Sprint?
• Role of ScrumMaster is not to provide answers, but to
facilitate the Team's search for better ways for the Scrum
process to work for it.
• Actionable items to be added to the next Sprint are devised as
high-priority nonfunctional Product Backlog.


References

• Books on XP
 Extreme Programming Explained, Second Edition. by Kent Beck, Cynthia
Andres.
 Planning Extreme Programming. by Kent Beck, Martin Fowler.
 Refactoring. by Martin Fowler.
 Extreme Programming Installed. by Ron Jeffries, et al.
• Websites on XP
www.extremeprogramming.org
www.xprogramming.com
c2.com/cgi/wiki?ExtremeProgrammingRoadmap
www.egroups.com/group/extremeprogramming/
www.agilealliance.org
• Books on Scrum
 Agile Project Management with Scrum. by Ken Schwaber.
• Websites on Scrum
www.controlchaos.com
www.scrumalliance.org
scrumdevelopment@eGroups.com


Thank You!

Pradyumn Sharma
pradyumn.sharma@pragatisoftware.com


Introduction To Xp And Scrum Practices

Recommandé

Recommandé

Contenu connexe

Plus de Naresh Jain

Plus de Naresh Jain (20)

Dernier

Dernier (20)

Introduction To Xp And Scrum Practices