the Sprint

9 downloads 3364 Views 9MB Size Report
SWEBOK V3 (on Review Stage). Knowledge Areas (KAs). Software requirements . Software design. Software construction. Software testing. Software ...
1. CMMI and Scrum

TWO BRANCHES OF SOFTWARE DEVELOPMENT

Enterprise Software Engineering Agenda 1. 2. 3. 4.

CMMI and Scrum Kanban Software Engineering Software Development Life Cycle Secure Software Engineering

2

Enterprise Software Engineering Agenda 1. 2. 3. 4.

CMMI and Scrum Kanban Software Engineering Software Development Life Cycle Secure Software Engineering

3

What is Software Engineering? Software engineering is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software

From cradle to grave

The Three Critical Dimensions

5

What is Software Engineering?

SWEBOK V3 (on Review Stage) Knowledge Areas (KAs) Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering models and methods Software quality Software engineering professional practice Software engineering economics Computing foundations Mathematical foundations Engineering foundations Software security specialized knowledge area

15 Knowledge Areas

Growing Pains

10

Crafting Software Resource

Code

Product

Input Debug Test

11

Engineering Software Resource

PM

F Input

RA

R

Product

D C T

12

Build a Bridge vs. Build Software

Design 10% Construction 90%

Design 90% Construction 10%

13

Software Engineering Maturity • Stages of engineering maturity Professional Engineering

Commercial Practice

SW Engineering Craftsmanship Currently, software engineering might be placed some where between craftsmanship and commercial practice 14

Waterfall

The Waterfall Process

Requirements

Design

Code

Testing

Requirements

Design

Code

Testing

Requirements

Design

Code

Testing

Requirements

Design

Code

Testing

Requirements

Design

Code

Testing

Requirements

Design

Code

Testing

Time

DONE

“Gimme all requirements, or ….”

The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements Analysis Program Design Coding V&V

But …

Operations

The Waterfall Process Big Requirements Up Front (BRUF) System Requirements

Preliminary Design

Analysis

Software Requirements

Program Design

Preliminary Design

Software Requirements Specification

Coding Testing Usage

Analysis Program Design

Prelim. Review Preliminary Design Document

Coding

Final Design UI Design Document

Operating Instructions V&V

Design Review

V&V Plan

Operations

Waterfall is like Cannonball

Waterfall Summary

Iterative Development

Incremental Development

Iterative and Incremental Development

Iterative and Incremental Process

R

R

D

C

R

D

C

T

R

D

C

T

R

D

C

T

R

D

C

T

D

C

T

T

Time

What is Iterative and Incemental Development?

Risks in Waterfall and Iterative Methods We do risky things first

R I S

Iterative development

Waterfall

K TIME

28

Standish Report - 2006 USA : $80-145 billion per year is spent on failed and cancelled projects UK :12 out of 18 Large IT projects have failed

The Cost of Change in Waterfall and Iterative Methods

WF

Iterative

Wasted Features - Standish Report - 2002

Waterfall vs. Iterative & Incremental But ...

32

TWO BRANCHES OF SOFTWARE DEVELOPMENT CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

The History of CMMs

38

CMMI: 3 Complementary “Constellations”

DoD / Carnegie Melon University / Software Engineering Institute

40

DoD / Carnegie Melon University / Software Engineering Institute

SW Industry vs. NASA

6 SIGMA 3.4 Defects Per Million Opportunities – DPMO

Characteristics of the Maturity Levels

43

CMMI Model Representations Staged

Continuous

ML4 ML3 ML2

Capability

ML5

ML 1 Organization

PA

PA

PA

Process 44

Equivalence Staging – Maturity Level 3

The Appraisal Method

TWO BRANCHES OF SOFTWARE DEVELOPMENT AGILE METHODOLOGIES

The Manifesto for Agile Software Development Individuals & Interactions

2001

• Working Software • Customer Collaboration • Responding to Change

Processes & Tools • Comprehensive Documentation • Contract Negotiation • Following a Plan

50

Agile Manifesto February 2001,Jim a subtle but deadly attack on Martin Alistair Ward Kent Beck Highsmith Fowler Cockburn Cunningham the old

• Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. • Agility is the ability to balance flexibility and stability. TARTU murdes: „väledad metoodikad“

Agile is like Homing Missile

Agile Success & Hype

Agile „Brand Name“ Methodologies

Agile 2001 vs. 2009 vs. 2011 Scrum; 3% Lean; 7% Other; 17%

XP; 38%

DSDM; 19%

FDD; 23% ASD; 22%

eXtreme Programming (XP): 38% → 4% Scrum: 3% → 58% 55

Agile Ecosystem

Standish Group 2012

Scrum & XP

Scrum & Agile

Whatever agile practices you like

58

Scrum and XP (most common practices)

• • • •

Pair programming Test-driven development Collective code ownership Coding standards

Scrum

The Founding Fathers 1995

Jeff Sutherland •In collaboration with Jeff McKenna

Ken Schwaber •In collaboration with Chris Martin and Mike Smith

Mike Beedle and Martine Devos

Scrum

61

The Goal of Scrum

• Manage Complexity, Unpredictability and Change • through Visibility, Inspection and Adaptation

Scrum Explained

Introduction by Ken Schwaber  Scrum is not a methodology. Scrum does not provide the answers to how to build quality software faster.  Scrum is a framework within which the game of product development is played.  Your team plays and how good or notgood it is becomes highly visible.  Your team gets to continuously improves itself. 64

What is Scrum? •

Definition from rugby football:

a scrum is a way to restart the game after an interruption, where the forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them

Scrum - an Agile Process • SCRUM is an agile, lightweight process for managing and controlling software and product development in rapidly changing environments. • • • • • • •

Iterative, incremental process Team-based approach developing systems/ products with rapidly changing requirements Controls the chaos of conflicting interest and needs Improve communication and maximize cooperation Protecting the team form disruptions and impediments A way to maximize productivity

Characteristics • Self-organizing teams • Product progresses in a series of month-long “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed • Uses generative rules to create an agile environment for delivering projects • One of the “agile processes”

Scrum in a Nutshell

See the Big Picture

It’s all about the business, not the technology

Scrum

Today: 1-2 weeks 70

Scrum Framework Roles

•Product owner •ScrumMaster •Team

Ceremonies

•Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts

•Product backlog •Sprint backlog •Burndown charts

picture by exfordy

Scrum Roles

The Boss

The Boss

Product Owner

• Owner of project vision • Represents the customer

Product Owner • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed

• Accept or reject work results

Scrum Master

• Servant leader • Team protector • Troubleshooter • Scrum guide

The ScrumMaster • Represents management to the project • Responsible for enacting Scrum values and practices • Removes impediments

• Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences

The Team

Small (5–9 people) Colocated - Cross-functional Self-organized - Full-time

The Team • Typically 5-9 people

• Cross-functional: • Programmers, testers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator)

• Teams are self-organizing • Ideally, no titles but rarely a possibility

• Membership should change only between sprints

Self-Organized-Team vs. Traditional Organisation Self ManagingTeams customer-driven

Traditional Organization management driven

multi-skilled workforce few job descriptions

workforce of isolated specialists Many Job Descriptions

Information widely shared

Information limited

Few levels of management

Many levels of Management

Whole-business focus

Function/department focus

Shared goals

Segregated goals

Seemingly chaotic

Seemingly organized

Purpose achievement emphasis High worker commitment Continuous improvements Self-controlled

Problem-solving emphasis High Management commitment Incremental improvements Management-controlled

Values/principles based

Policy/procedure based

Source: "Leading self-directed work teams" by Kimball Fisher

81

Team Size

Communicaton Pathways Increase Geometrically with Team Size

Why a complete graph has n(n−1)/2 edges?

The Team is Empowered and Accountable • In Scrum, the team is both empowered and accountable to deliver the goods. • The team does their job when they self-organize, selfmanage and self-achieve the objectives of the Sprint. • For many organizations, this turns things upside down. • The hierarchical-technical-management-directive approach is essentially eliminated with Scrum. • The Product Owner now sets the objectives and priorities, the team figures out how to achieve them, and no one need tell them how to do that along the way.

Scrum Framework Roles

•Product owner •ScrumMaster •Team

Ceremonies

•Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts

•Product backlog •Sprint backlog •Burndown charts

Scrum Meetings

Sprint Planning Meeting Outcome is Committed Product Backlog Items (PBIs) and Subordinate Sprint Tasks

Sprints

• Steady pull of business value • Inspect and Adapt

Sprints • Scrum projects make progress in a series of “sprints” • Typical duration is 1–4 weeks or a calendar month at most • A constant duration leads to a better rhythm • Product is designed, coded, and tested during the sprint

No Changes During a Sprint Change

• Plan sprint durations around how long you can commit to keeping change out of the sprint

The Sprint Goal • A short statement of what the work will be focused on during the sprint Life Sciences Database Application

Support features necessary for population genetics studies.

Make the application run on SQL Server in addition to Oracle.

Financial services Support more technical indicators than company ABC with real-time, streaming data.

Sprint Planning meeting

Stand-ups

Development

Sprint Testing Showcase Retrospective

Planning meeting …

(1 or 2 weeks)

Sprint Planning • Team selects items from the product backlog they can commit to completing • Sprint backlog is created • Tasks are identified and each is estimated (1-16 hours)

• Collaboratively, not done alone by the ScrumMaster

• High-level design is considered As a vacation planner, I want to see photos of the hotels.

Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)

Sprint Planning Team capacity

Product backlog

Business conditions

Sprint planning meeting Sprint prioritization

• Analyze and evaluate product •

Sprint planning

• Current product

• •

Technology

backlog Select sprint goal

Sprint goal

Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours

Sprint backlog

Daily Scrum

• The heartbeat of Scrum

The Daily Scrum • Parameters – Daily – 15-minutes – Stand-up

• Not for problem solving – Whole world is invited – Only team members, ScrumMaster, product owner, can talk – “Chickens” and “Pigs”

• Helps avoid other unnecessary meetings

Everyone Answers 3 Questions

1 What did you do yesterday?

2 What will you do today?

3 Is anything in your way?

Pigs and Chickens Product Owner Scrum Master Team Members

Users Managers Marketing

Sprint Review

• Satisfy Product Owner • Get feedback on product

Sprint Review Informal, no slides Whole team participates The world is invited

picture by oskay

The Sprint Review • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal • 2-hour prep time rule • No slides

• Whole team participates • Invite the world

The Sprint Review • Team demonstrates working software to product owner • Product owner accepts or rejects completed work • Result should be potentially shippable

Sprint Retrospective

Sprint Retrospective • Team meets to review: – What is working? – What is not working?

• Team adds tasks for immediate actions for working better

Sprint Retrospective • Periodically take a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates – ScrumMaster – Product owner – Team – Possibly customers and others

Scrum Framework Roles

•Product owner •ScrumMaster •Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts

•Product backlog •Sprint backlog •Burndown charts

ARTIFACTS 109

User Stories Mike Cohn

110

User Stories Mike Cohn

= value for user 111

Stories at Different Levels of Granularity Project Level Story

Release Level Story Iteration Level Story

Iteration

Release

Project

1 – 4 weeks

1 – 12 weeks

1 – many weeks

Stories, Features and Epics Feature

113

Product Backlog

First an Idea

115

Then a Vision

116

The Vision

117

Then a Product Backlog

118

Product Backlog



The Product Backlog answers following questions: What? When? For who? 119

Product Backlog • Is only a FORECAST!-> is not exact

Evolution of Product Backlog

A Sample Product Backlog Backlog item

Estimate

Allow a guest to make a reservation

3

As a guest, I want to cancel a reservation.

5

As a guest, I want to change the dates of a reservation.

3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room)

8

Improve exception handling

8

...

30

...

50

A Sample Sprint Backlog Tasks Code the user interface

Mon Tues Wed Thur Fri 8

4

8

Code the middle tier

16

12

10

4

Test the middle tier

8

16

16

11

8

8

8

8

8

8

4

Write online help

Write the foo class Add error logging

12

8

Sprint Burn down Chart • Depicts the total Sprint Backlog hours remaining per day • Shows the estimated amount of time to release • Ideally should burn down to zero to the end of the Sprint • Actually is not a straight line • Can bump UP

Tasks

Mon

Code the user interface

Tues Wed Thur Fri

8

4

8

Code the middle tier

16

12

10

7

Test the middle tier

8

16

16

11

Write online help

12

50 40 30

Hours

20 10 0

Mon

Tue

Wed

Thu

Fri

8

Scrum Summary  The Product Owner sets a List of Features called Product Backlog



 During the Sprint Planning, the Product Owner determines a piece of the top of that list: the Sprint Backlog; and decide how to implement it.  The Team has a time-box to reach this goal: the Sprint 126

Scrum Summary



 Each day, the Team measures its progress during a 15’ meeting: the Daily Scrum

 During the whole project, the Scrum Master ensures that the Team is still focused on its objective.  At the end of the Sprint, the work has to be potentialy shipable. This work is considered as done. 127

Scrum Summary



 The Sprint ends with the Sprint Review and the Retrospective.

 The Scrum process is done when all Stories are implemented, or the budget is consummed, or when the time is over. 128

RUP and Agile Methodologies

RUP What ?

How ?

Do !

Deliver !

Milestones

“Understand the problem”

“Understand the solution”

“Solution ready ?”

“Acceptance from the customer” 130

Sequential RUP ≈ "Waterfall"

“Pure” Iterative RUP

RUP RUP lifecycle is serial in the large and iterative in the small

When all of the sides of the parallelogram "collapse" into a diagonal line, a "pure waterfall" approach results with disciplines are distributed across iterations.

RUP → Scrum

Construction

SUMMARY

There are no silver bullets

Notice:

Methodologies

do not write

Code

Dimensions Affecting Method Selection

“Right-size" the Process • Allow projects to "right-size" the process they use; • That is, allow projects to use "just enough" process. • Users should be able to start with a small process, and as project needs expand, to grow the process to address those needs.

139