You are on page 1of 19

Traditional Lifecycle Models

Requirements Analysis Design Code Test Implementation Maintenance


Master planning

Acceptance planning
Plan

System planning
Unit/Integration planning
Requirements inventory

Acquire

Design/code inventory

Architect test design


Detail test design and implementation
Measure

Test execution and reporting


Defect and status reporting
Testware maintenance

2016 Robert Sabourin

Scrum

2016 Robert Sabourin

Motivation for SCRUM

Context

Turbulent environment

Lifecycle

Incremental Iterative Development

Delivers

Working Shippable Code

Goals

Prioritized requirements from


Backlog

Approach Self-Organizing Teams


2016 Robert Sabourin

Some SCRUM

15 30 Days

2016 Robert Sabourin

Some SCRUM Steps


Always

Actively manage backlog

Planning

Decide which backlog items implement


Work with product owner
Estimate - Prioritize
Commit resources to project

Sprint

Do work
Adapt
Self organize
Roles flexible
Involve product owner in changes
Keep stakeholders informed

Demonstration

Demonstrate working code

Retrospective

Review work done


Identify process changes

2016 Robert Sabourin

Roles & Responsibilities

Product Owner Role Should


Actively manage backlog
Be available throughout iteration
Work with team to prioritize backlog
Work with tester to build test stories at start of iteration
Advocate Customer as part of team

2016 Robert Sabourin

Roles & Responsibilities

SCRUM Master
Facilitate SCRUM within TEAM
Removes road blocks
Status to stakeholders

2016 Robert Sabourin

Roles, Responsibilities & Skills

Yoda: You must unlearn what you have


learned

2016 Robert Sabourin

Skills & Roles

Team members
Implement stories from backlog
Implement automated unit test frames
Be able to work in different roles

2016 Robert Sabourin

Skills & Roles

Team members
Elaboration and documentation of test stories
Implement of automated test frames

2016 Robert Sabourin

10

Skills & Roles

Team Should
Define fluid development workflow
Minimize documentation needed
Adapt and self-organize

2016 Robert Sabourin

11

Req Flow

Product owner actively manages backlog


Elicit requirements
Prioritize backlog per iteration
Create product roadmaps
Elaborate as late as possible

Many approaches

2016 Robert Sabourin

12

Teams
Traditional
development

Agile selforganizing
teams

2016 Robert Sabourin

Development
Testing
Product management
Documentation
Project management

Team member
ScrumMaster
Product owner

13

Evolving Roles
Traditional

Agile

Delineation of
responsibilities
Orthogonal
functions
Centers of
excellence

Teams are
self-organizing
Flexible
Adaptable

2016 Robert Sabourin

14

Requirements
Traditional
Elaborated in detail
before design and
implementation
Validated with
inspection and
review
Traces to test and
development tasks
Change is expensive

2016 Robert Sabourin

Agile
Collected in a
continuously evolving
dynamic backlog
User stories
Product constraints
Features
Change is
realistically expected

15

Integration Testing
Traditional
Separate testing phase
Done after coding is
competed
Done by developers or by
independent testers
Ensures components or
subsystem interoperate
correctly
Exercise integration paths

2016 Robert Sabourin

Agile
Continuous integration is
done as code is
implemented
New modules are
integrated immediately
Automated frameworks
are used to exercise
integration paths and
ensure code from
different sources
interoperate correctly
This is not a separate
testing phase

16

System Testing
Traditional
Separate testing phase
Performed after
development and
integration are complete
Done by independent
testers
Test objectives derive
from requirements and
system design

2016 Robert Sabourin

Agile
No system testing phase
Testing is performed as
items are implemented
Testing may be assigned
to any team member
Tools support automation
In sprint
Functional
Non-functional
Failure modes
Exploratory testing
Regression testing

17

Acceptance Testing
Traditional
Separate testing phase
Performed after
development, integration
and system testing are
complete
Often done by or for the
customer
Test objectives are based
on project requirements
Tied to meeting customer
and project business
goals

2016 Robert Sabourin

Agile
Completed for each story
implemented
Story tests
Established with users
Not a separate phase of
development
Automated tools such as
FitNesse or Cucumber
support user defined
acceptance testing for
each story
Automated, repeatable

18

Defining Done

Done means DONE

Fully
Fully
Fully
Fully
Fully
Fully
Fully

analyzed AND
designed AND
coded AND
tested AND
refactored AND
integrated AND
demonstrated

2016 Robert Sabourin

DONE means
shippable
19

You might also like