Penn State Abington
IST 261 (Fall 2015)
Application Development Design Studio I
Agile Scrum
Phil O'Connell
pxo4@psu.edu
Discussion
• Without looking anything up online, come up
with a description of what you think is a good
method of developing software
– What are the different phases?
– What are the roles of the people involved?
– How do you decide on the goals?
– How do you learn from missed goals?
IST 261 (Spring 2015)
Application Development Design Studio I
2
Software Development
• When working on a project, developers
don't/shouldn't just sit down and start coding
• There must be planning, phases, steps, etc…
• So the question is: what methodology to use?
• There are many different kinds of processes
• Each has advantages and disadvantages
• The first one we'll discuss is Waterfall Model
• Note, this is not the model we'll use for class
IST 261 (Spring 2015)
Application Development Design Studio I
3
Waterfall Model
•
•
•
•
•
•
Invented by Herbert D. Benington in 1956 1
Formalized by Winston W. Royce in 1970 2
Very popular in the 1980s and 90s
Sequential phases to be followed in order
Trying to backtrack can be very costly
Each phase should be totally completed
before the next one begins
1 https://www.worldcat.org/title/symposium-on-advanced-programming-methods-for-digital-computers-
washington-dc-june-28-29-1956/oclc/10794738
2 https://en.wikipedia.org/w/index.php?title=Waterfall_model
IST 261 (Spring 2015)
Application Development Design Studio I
4
Waterfall Model
Requirements
Deliver Product Requirements Doc
Design
Deliver software architecture plan
Implementation
Finish entire product
a.k.a Verification
Testing
Maintenance
https://commons.wikimedia.org/wiki/File:Waterfall_model.svg#/media/File:Waterfall_model.svg
IST 261 (Spring 2015)
Application Development Design Studio I
5
Drawbacks to Waterfall Model
• Discuss, and make a list of drawbacks…
• Each phase should be totally completed
before the next one begins
• No customer feedback until delivery
• Trying to backtrack can be very costly
• If a Design mistake was made, and it's not
discovered until Testing, then a lot of time and
money may be needed to fix it
IST 261 (Spring 2015)
Application Development Design Studio I
6
Waterfall Model
Requirements
Deliver Product Requirements Doc
Design
Deliver software architecture plan
Implementation
Time, money,
and effort to
backtrack for
changes
Finish entire coded product
a.k.a Verification
Testing
Maintenance
"Waterfall model" by Peter Kemp / Paul Smith - Adapted from Paul Smith's work at wikipedia. Licensed under CC BY 3.0 via
Commons - https://commons.wikimedia.org/wiki/File:Waterfall_model.svg#/media/File:Waterfall_model.svg
IST 261 (Spring 2015)
Application Development Design Studio I
7
Agile Paradigm
• Agile is a software development paradigm
• Agile doesn't give you a concrete process
• It's a set of principles for
a theory or a group
of ideas about how
software development
something should
methodologies to follow
be done, made, or
thought about
• Some Agile methodologies
1
– Scrum, Extreme Programming (XP), Feature Driven
Development (FDD), Agile Unified Process (AUP), Dynamic
Systems Development Method (DSDM), Crystal
1
IST 261 (Spring 2015)
http://www.merriam-webster.com/dictionary/paradigm
Application Development Design Studio I
8
Agile Manifesto
• Concepts for Agile started in 1994
• Formalized in 2001 with the
Manifesto for Agile Software Development
• Written by these software engineers
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
http://agilemanifesto.org/
IST 261 (Spring 2015)
Application Development Design Studio I
9
Agile Manifesto
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
•
•
•
•
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right [of "over"], we
value the items on the left more.
http://agilemanifesto.org/
IST 261 (Spring 2015)
Application Development Design Studio I
10
The 12 Agile Principles
1. Customer satisfaction by early and continuous delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity (the art of maximizing the amount of work not done) is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstance
1
http://www.agilemanifesto.org/principles.html
IST 261 (Spring 2015)
Application Development Design Studio I
11
The 12 Agile Principles
• I think the 12 principles can be boiled down to
– Be in continual communication
• With the customer
• With each other
• Face-to-face if possible
– Deliver software changes to customers frequently
• Get feedback often
– Adapt to changing requirements
• Most-likely from customer feedback during demos
IST 261 (Spring 2015)
Application Development Design Studio I
12
Scrum
• Scrum is a software development
methodology that follows the Agile paradigm
IST 261 (Spring 2015)
Application Development Design Studio I
13
A Very Broad Scrum Overview
• A project is broken down into small features
• The following cycle repeats until the project is done
Called a sprint
1. Choose some features that can be done in this sprint
2. The features are designed, coded, tested, docu'd
3. At the end of that sprint, the team will
– Demo those new features to the customer
– Discuss the cycle to see what can improve for next time
4. Start the next sprint
IST 261 (Spring 2015)
Application Development Design Studio I
14
Roles in Scrum
• Development Team (DT)
– Programmers, Testers, Documentation Writers
• Scrum Master (SM)
– Keeps the team on track during meetings
– Get rid of roadblocks
– Negotiates with Product Owner
• Product Owner (PO)
– Creates the Product Backlog (list of features)
– Represents the stakeholders and customer
• Stakeholders (SH)
– Managers above the PO; and the customer
IST 261 (Spring 2015)
Application Development Design Studio I
15
Scrum Overview
IST 261 (Spring 2015)
Application Development Design Studio I
16
Product Backlog
•
•
•
•
•
The Product Owner (PO) meets with the customer
The customer describes the product he/she wants
PO creates a list of product backlog items (PBIs)
PBIs are requirements/features for the product
Each PBI is given an effort level and priority
• We'll talk about that later
• One PBI should be able to be completed in one sprint
• or less. Because ideally, you have >1 PBI in a sprint
• The backlog may be readjusted at the end of a sprint
IST 261 (Spring 2015)
Application Development Design Studio I
17
Product Backlog Items (PBIs)
• The PO decomposes the product into PBIs
• A PBI is normally a user story, User Story is described
on the next slide…
but it can be
– Improvement goals (e.g., "increase response time")
– Research goals (e.g., "feasible to use AngularJS?")
– Defects needing to be fixed (e.g., "login screen hangs")
IST 261 (Spring 2015)
Application Development Design Studio I
18
User Story
•
•
•
•
A user story is a product goal or feature
It can be broken down into smaller stories
Worded in terms of who, what, and why
who
what
why
"As a ______,
I want ______
so I can ______."
– As a shopper, I want to add an item to a wish list
so I can easily find it later.
– As an admin, I want to have a list of old carts so I
can email a reminder to the shopper.
IST 261 (Spring 2015)
Application Development Design Studio I
19
I.N.V.E.S.T.
User stories should be (write these down)
• Independent – No story dependent on another
• Negotiable – Can be changed (until work is started)
• Valuable – It must result in value to the customer
• Estimable – You must be able to estimate its size
• Small – Enough to plan/prioritize/complete in a sprint
• Testable – Provide info so it can be tested
IST 261 (Spring 2015)
Application Development Design Studio I
20
Decomposing Big User Stories
• As a shopper, I want to search for items so I
don't need to remember item codes
• INVEST?
Independent?
Maybe. Do we already have item objects?
Negotiable?
Yes. We can change it before we start working on it
Valuable?
Yes.
Estimable?
No. Too large to estimate.
Small?
No. Result screens, paged results, database indexing, ...
Testable?
Yes.
IST 261 (Spring 2015)
Application Development Design Studio I
21
Decomposing Big User Stories
• As a shopper, I want a place to type in item
criteria it can be used for searches
• As a shopper, I want my item search criteria to
return a list of items
• As a shopper, I want each letter in my search
to instantly update the results so I don't have
to type full search terms
IST 261 (Spring 2015)
Application Development Design Studio I
22
Other Good User Stories
• As an admin, I want to be emailed when the
site goes down so I can investigate the cause
• As shopper, I want an email alert when my
order ships so I can start tracking it
• As a user, I want a link that will send my
password reminder so I can remember my
password
IST 261 (Spring 2015)
Application Development Design Studio I
23
Not-so-good User Stories
• What part(s) of INVEST do these not follow?
– As a shopper, I want a nice user experience so I
will be a loyal customer
– As a user, I want the software to be more efficient
so I can improve my productivity
– As an admin, I want report on open orders so I
don't get customers angry
IST 261 (Spring 2015)
Application Development Design Studio I
24
User Story Exercise
• Using Amazon.com as an example…
• Start with this high-level user story:
"As a shopper, I want to maintain a wish list so
I can quickly find items later"
• That's nice, but does it follow INVEST?
• Decompose that to 3 smaller user stories
• Can they be decomposed further?
IST 261 (Spring 2015)
Application Development Design Studio I
25
Sprint Planning and Backlog
• Happens on the first day of the sprint
• Product owner and sprint team attend
• PO chooses PBIs that can be done this sprint
• Time for: research, code, test, docu, review
• Team decides if they can complete them
• If approved, the PBI moves from the
product backlog to the sprint backlog
• Then they're SBIs (sprint backlog items)
• Items in the sprint backlog are then decomposed
into sprint tasks (next slide)
• That day, the team should begin work
IST 261 (Spring 2015)
Application Development Design Studio I
26
Sprint Tasks
• Each sprint backlog item will (normally) have tasks
• The backlog item is not done until each task is done
Sprint
Backlog
Items
Tasks Not
Started
Tasks In
Progress
Tasks
Completed
Scrum task
board
http://scrumreferencecard.com/scrum-reference-card
IST 261 (Spring 2015)
http://www.digitalsaber.com
Application Development Design Studio I
27
Sprint Tasks
• They can vary from company to company
• Sometimes they are the same for each story
– Design (Programmer designs/plans/researches)
– Code (Programmer codes and unit-tests)
– Test (QA tests the story)
– Document (Docu person)
IST 261 (Spring 2015)
Application Development Design Studio I
28
Sprint Tasks
Test
•
•
•
•
Docu
Code
Design
The programmer owns the Design and Code
The QA person owns the Test
The Documentation person owns the Docu
Ideally, roles can be changed around among people
IST 261 (Spring 2015)
Application Development Design Studio I
29
Sprints and Daily Meetings
• Every day at the same time, have a 10-15
minute meeting
• Stand, don't sit (so meetings go quicker)
• Each team member states
Or since the
last scrum
• What I did yesterday
meeting
• What I will do today
• What (if anything) is blocking me
• Do not take too long
• If needed, go "offline" with those involved
IST 261 (Spring 2015)
Application Development Design Studio I
30
Sprint Review
• On its last day, the sprint is demo'd live
• Anyone is allowed to attend
• Stakeholders are strongly encouraged to attend
• A demo almost always yield suggestions
• The suggestions are incorporated into the PBIs
IST 261 (Spring 2015)
Application Development Design Studio I
31
Sprint == Shippable Product Increment
• At the end of each sprint, you should have a shippable product
• "Shippable" meaning – deliverable to the customer
• This is a major benefit of Agile
• The customer can have a working version of the software
• It allows the customer to review the latest version of the product
• The customer is satisfied, and feels part of the process
IST 261 (Spring 2015)
Application Development Design Studio I
32
Retrospective Meeting
• Happens on the same day, following the sprint review
• Stakeholders are not allowed to attend
• The team reviews how smooth or rough the sprint was
• Suggestions are made to improve the next sprint
IST 261 (Spring 2015)
Application Development Design Studio I
33
Backlog Grooming
• After the sprint review and retrospective, the PB can be adjusted
• Typically, this is a result of suggestions made during the demo
• But it could also be due to the team or PO realizing a needed change
IST 261 (Spring 2015)
Application Development Design Studio I
34
More…
• There are more aspects to Scrum
• We'll cover more later
IST 261 (Spring 2015)
Application Development Design Studio I
35