Designing the Process · Scrum: Agile for software development Scrum is the most prominent example...

Preview:

Citation preview

Designing the Process

A Brief Introduction to Agile Programming

In the beginning, there was the waterfall ...

Analysis, Design, Implementation, Testing & Evaluation:− Discrete, linear tasks− Each step completed before the next step can

proceed

Waterfall

Highly structured Not very adaptable

Agile: a new paradigm

Process model that recognizes the significance of change and responsiveness

Emphasis on adaptability Same basic “steps” are involved (ADITE), but

throw out linearity and discreteness

Agile view of programming process

Feedback at each stage− Linkage− Collaboration

Scrum: Agile for software development

Scrum is the most prominent example of agile model in the programming world

Scrum describes both the process and the participants in the process

Scrum as process framework

Sprint: basic work cycle− 1-4 weeks in duration (assuming 40+ hour weeks)− Tasks pulled from prioritized list of requirements

(top first)− Working software delivered at end of each sprint− Fixed duration: end at predefined end date, whether

successful or not

Product backlog: example

Source: onproductmanagement.net

Product backlog: example

Source: http://www.mountaingoatsoftware.com/blog/a-sample-format-for-a-spreadsheet-based-product-backlog

Scrum artifacts

Sprint backlog (aka release backlog)− Detailed list of requirements to be met during

current sprint− Includes time estimates (programmer-hours) for

completion of each task No more than 16 hours per task Larger tasks broken down into smaller tasks if estimate

exceeds this limit

Product backlog vs. Sprint Backlog

Source: www.altexsoft.com

Scrum artifacts User stories (customer requirements)

− Used in lieu of conventional (long, detailed) requirements docs

− Basic unit of backlog− Generated by customer (user)

Describe what system needs to do for them Not limited to UI Short – 2-3 sentences – non-technical

− Serve purpose similar to use cases Product owner prioritizes these, may tweak them Programming team uses these to create time estimates

for sprint

User stories

Suggested formats:− As a [role], I want [feature] because [reason]− As a [role], I can [feature]− As a [role], I can [feature] so that [reason]

Examples:− As a student, I want to see a list of classes so that I

can register− As account owner, I can check my balance online − As a user, I want to search for my customers by

their first and last names.

Forms of user stories*

Cards: like CRC cards, only less (or more) Conversation: discussion surrounding card: how team

interprets what's there Confirmation: tests that verify requirement(s) met

*** Source: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

** Source:

http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/

User stories

Source:http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/

Product backlog vs. Sprint backlog

Source: agile.dzone.com

Sprint backlog example

Source: www.mountaingoatsoftware.com/uploads/blog/SprintBacklog.jpg

Scrum artifacts

Burndown chart− Shows ongoing (cumulative) work done &

remaining in sprint− Updated daily− Guide for team: on-time delivery of working product

Burndown chart: example

Source: http://upload.wikimedia.org/wikipedia/commons/0/05/SampleBurndownChart.png

Burndown chart: example

Source: http://agilesoftwaredevelopment.com/files/apostimages/Scrum/simple-sprint-backlog.png

Kanban board

Not really a Scrum artifact (Scrum & Kanban are really two different Agile methodologies) but often associated with Scrum projects

Visual tool (like burndown chart in that sense) for monitoring project progress

May be used to visualize sprint backlog

Kanban board examples

Source: http://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Simple-kanban-board-.jpg/400px-Simple-kanban-board-.jpg

Source: http://www.infoq.com/resource/articles/agile-kanban-boards/en/resources/Fig1_task-board.jpg

Scrum roles

Product owner: in charge of project backlog; acts as the voice of the customer

Scrum team: develops the product− Cooperative, self-organizing− Cross-functional

Scrum master: facilitates meetings, protects & serves the team

The process

Start with product backlog Sprint planning meeting

− Product owner & team review high priority items, decide what to implement during this sprint – goal is for team to understand what product owner wants

− Team then focuses on detailed task planning: Time estimates Ordering of tasks to maximize both speed & quality of

production

Sprint

Basic work cycle of scrum Team works from product backlog Fixed time frame Goal: working product at end of every sprint

− “Product” may be prototype or some aspect of larger system

− Emphasis here is working product – something tangible to show for work

The process

Daily scrum− Short meeting; team members report

What they did since last meeting What they plan to do before next meeting Any problems getting in the way of progress – scrum

master responsible for helping solve these

The process

Sprint backlog & burndown chart updated daily Product owner works with team to “groom”

product backlog on a regular basis:− Refining requirement details− Splitting large tasks into smaller ones− Time estimation for new items− Re-estimation of existing items

The process

Ending the sprint− Duration is preset – sprint is not extended − Sprint review: team & product owner inspect &

adapt whatever team has produced− Sprint retrospective: team review of sprint:

What went well What could be improved Things to try Issues to escalate

Start next sprint cycle

Problems with Scrum

Mostly, it doesn't work if you don't do it right, e.g.:− Meeting rules not followed− Goals are unclear− Key players not available to answer questions− Product backlog not prioritized well− Not everyone contributes

Benefits of Scrum

Puts the “agile” in agile development:− Sensitive to changing requirements− Doesn't attempt to understand entire project before

it's started – emphasizes learning along the way Delivers a working product quickly

− Customers (via product owner) set priorities− Products developed according to these priorities

Recommended