Meghan Allen

CPSC 310 – Software

Engineering

Lecture 3 – Agile Process Models

2

Reading!

For this lecture:• Scrum (required)

http://refcardz.dzone.com/refcardz/scrum?oid=hom9677

• What is Extreme Programming? (required)

•http://www.xprogramming.com/xpmag/whatisxp.htm

•written by Ron Jeffries, one of the three inventors of XP

For next lecture:• Voyages in the Agile Memeplex – Professor Kruchten

• The Architecture of GWT (http://danielwellman.com/publications/GWT-Shortcut_To_Ajax-Oct2008.pdf)

3

Tips� Programming skills

• Project Euler http://projecteuler.net/

• Eclipse Tutorials

• Google Web Toolkit tutorials

• OSS bug trackers and mailing lists

4

Learning Goals

�Describe the commonalities of agile software development.

�Describe the software process described by Extreme Programming, Scrum, and Lean/Kanban.

5

Prospects for an engineering discipline of software

� Origins of software ‘engineering’

� Challenges:

• Routine vs innovative design (sharing)

• Science and engineering must reinforce one another

� Goals

• Awareness of best practices

• Make problems routine

• Specialize and standardize

6

The Boehm Curve

Source: Greg Wilson,

http://www.cdf.toronto.edu/~csc301h/fall/lec/01-

intro.html

7

Means Waterfall?

Source: Greg Wilson,

http://www.cdf.toronto.edu/~csc301h/fall/lec/01-

intro.html

• http://www.groklaw.net/articlebasic.php?story=20110614184205441

11

Choosing a model

�Technical management must choose best model and adapt model for situation

� You might be management

� You might influence management

�Understanding the choice

� Helps you work well within the model

� Can reduce frustration

12

What is “agility”?

� Adapt to change

• Particularly changes in requirements

• Use frequent, short iterations to flatten cost curve

� Focus on working software

• What works is how success is measured

� Process based on collaboration

• Heavy customer involvement

� A sustainable process

• Find a cadence that delivers reliably

13

Drawbacks of Agile� Harder to enforce with inexperienced

programmers

• Can fallback into cowboy coding

� Requires close customer involvement

� Hard to estimate completion schedule

� Increases the risk of feature creep

• Adapting is good, but you need to draw the line

� Can be inefficient

• No BDUF saves time, but

• Too much refactoring can be costly

14

Agile Methods� Extreme Programming

• Specific practices - customer driven development, small teams, daily builds

� Scrum• Project management approach, relying on self-organizing

independent teams

� Several others – Crystal, FDD, DSDM

� Commonly seen as “Agile” is Lean Software

Development, but this is more of an approach

15

Discussion questionOften, the customer does not have a complete understanding

of what she actually wants (requirements) at the beginning of

a project.

What solution to this issue does the Agile approach suggest ?

A. Discuss the problem in detail with the customer at the beginning of the project.

B. Start with a significantly larger group of developers at the beginning of the project.

C. Ignore requirements and begin writing code.

D. Use short development cycles to allow for incremental requirements development.

E. Write requirements in the customer’s language and discuss.

16

Extreme Programming

� Developed by Kent Beck at Chrysler in mid-90s Not necessarily always successful

� Management buy-in critical regardless

17

Values of XPFive principal values:

1. Communication: common metaphors, frequent verbal communication, customer involvement

2. Simplicity: do the simplest thing that could possibly work, then refactor

3. Feedback: from the code (unit tests), the customer (co-location), the team (planning game)

4. Courage: be willing to throw things away

5. Respect: don't do things that make work for others

Thanks to Greg Wilson for slides:

http://www.cdf.toronto.edu/~csc301h/fall/lec/02-agile.html17

18

Thanks to Greg Wilson for slides:

http://www.cdf.toronto.edu/~csc301h/fall/lec/02-agile.html

• Pair programming

• Test-driven development

• Continuous integration

• Shared metaphor

• Small releases

• Planning game

• …

http://www.extremeprogramming.org/rules.html

XP Practices

• Test cases are written first

• Cover new functionality or improvement

• Then the necessary function is implemented

• Code is “complete” when all tests pass

• Refactor before adding feature if design could be better

Test-Driven Development

• Tests define units of work

• Tests document expected functionality

• Tests are contracts for methods

• Later additions can be “regression” tested

• Failure indicates breakage

• Small steps

Advantages of Test-Driven

• Designing good tests is difficult

• Can require extra implementation time

• Hard to do for real systems

• GUIs can be hard to test

Drawbacks of Test-Driven

• In groups of 2-3, writing your names or ids on a piece of paper:

• Write three tests for banking software that manages deposits at an ATM

• E.g., “Ensure that the customer does not leave his or her card in the machine”

Activity

Management framework for incremental product development

� Self-organizing, cross-functional teams

� Product progresses in a series of two- to four-week (fixed length) iterations: sprints

� Every iteration produces a potentially shippable (properly tested but not complete) product

� Requirements are captured as items in a list: product

backlog

� The business sets the priorities.

� No specific engineering practices prescribed (unlike XP)

taken from www.mountaingoatsoftware.com (Mike Cohn)Mountain Goat Software, LLC

Scrum

taken from www.mountaingoatsoftware.com (Mike Cohn)

Mountain Goat Software, LLC

change

Scrum

• Product Owner• Defines features of the product

• Prioritizes features according to market value

• Adjust features and priorities every iteration, as needed

• ScrumMaster• Facilitates Scrum process

• Helps resolve impediments

• Shields team from external interferences

• NOT the manager

• Team• Self-organizing, self-managing, cross-functional

• 7 (+/- 2) people

Scrum - Roles

• Product Backlog• prioritized list of requirements (or wishlist) that describes all

desired functionality

• Product Backlog Item• specifies a customer-centric feature (User Story form) – effort

estimated by team, business value estimated by Product Owner

• Sprint Backlog• contains list of tasks that are negotiated by team and product

owner from the Product Backlog for the sprint (negotiated PBIs broken down into specific tasks)

• Burndown Chart• Total remaining team

• task hours within one sprint

Scrum: Artifacts

• Specifies the WHAT not the HOW of a feature

• In User Story form

• Show what the user gets from the product

• Show what value the system adds to the user

• generally follows (but not restricted to) the format:

• As a [type of user], I want/can/need/etc. [goal or

need], so I can [reason]

• Large PBIs (called ‘Epics’) are split into thin vertical slices, not horizontal implementation slices

Product Backlog Item

29

User storiesUser stories are:

� a ~3 sentence description of what the software should do

� written in the customer’s language, from the customer’s point of view

� Conversation starters

� should only provide enough detail to make a low-risk estimate of how long it would take to implement (1,2 or 3 week estimate in “ideal development time”)

� Typically take Role-Goal-Benefit form:• “As a <ROLE>, I want to <GOAL> in order to <BENEFIT>”

• As a student, I need to login to RTC in order to finish the assignment

Examples of User Stories:

� As a user, I want to search for contacts so I can message them.

� As a customer, I want to search for product items so I can buy them.

� As an employer, I want to post a job on the website so people can apply for it.

NOT User Stories:

� Implement contact list view ContactListView.java

� Define the product table database schema

� Automate the job posting algorithm

Product Backlog Item

User Story also

� has a description of the story providing additional detail

� specifies acceptance criteria that defines what is meant for this feature to be DONE

� provides estimate of the required effort (story points)

• INVEST (for a good user story):

• Independent, Negotiable, Valuable to users or customers, Estimable, Small, Testable

Product Backlog Item

As a job company, I can use my credit card so I can pay for postings.• (A job company can pay for posting with a credit card.)

• Note: Accept Visa, MasterCard, American Express. Consider Discover.

• Test: (on the back of the story card)

• Test with Visa, MasterCard and American Express (pass)

• Test with Diner’s Club (fail)

• Test with good, bad and missing card ID numbers.

• Test with expired cards.

• Test with over $100 and under $100.

Example – User Story

• As a Creator, I want to upload a video from my local machine so that any users can view it.

• Note: …

• Test:

• Click the “Upload” button.

• Specify a video file to upload.

• Check that .flv, .mov, .mp4, .avi, and .mpg extensions are supported.

• Check that other filetypes aren’t able to be uploaded.

• Check that files larger than 100MB results in an error.

• Check that movies longer than 10 mins result in an error.

• Click “Upload Video”.

• Check that progress is displayed in real time.

Example – User Story & Test

In groups of 2 or 3, on paper:

• Write down 3 user stories for an online music store (such as the music part of iTunes) including test criteria

Class Activity

• List of tasks Scrum team commits to for sprint (negotiated PBIs for sprint broken down into specific tasks)

• Based on priorities and team’s perception of required time (normally between 4 and 16 hours)

• SMART: Specific, Measurable, Achievable, Relevant, Time-Boxed

• Tasks in Sprint Backlog represent developer’s

(technical) perspective, not customer perspective

Sprint Backlog

Real Weather App:

• PBI: As a subscriber, I want to see a 10-day forecast of conditions so that I can plan at least a week ahead

• T1: Parse the weather data in day packs

• T2: Push several days data to the client

• PBI: As a subscriber, I want to see precipitation accumulations and forecast so that I can plan my activities.

• T1: Parse snow/rain data from the provider’s data

• T2: Push the snow/rain data to the client

• T3: Redesign client screen a bit

• T4: Refactor the server code

Example – Sprint Backlog Items

Scrum: Process

Lean Software Development

• Roots in Toyota Production System

• Focus on:

• Continuous Improvement (kaizen)

• Trust workers

• Visualize work in progress

• Reduce waste in the value-stream

• Mary Poppendieck popularized this as “Lean Software Development”

Mary Poppendieck, Tom Poppendieck (2003), "Lean Software Development: An Agile Toolkit", Addison-Wesley ProfessionaISBN 0321150783

Kanban

1. Visualize

2. Limit WIP (and therefore lead time)

3. Manage Flow

4. Make Process Policies Explicit

5. Improve Collaboratively (using models & the scientific method)

Kanban boards

• Why process

• Sturdy, ‘waterfall’ models

• Agile models

• XP/TDD

• Scrum

• User stories

Summary: Software Process