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
