1. CMMI and Scrum TWO BRANCHES OF SOFTWARE DEVELOPMENT
Enterprise Software Engineering Agenda 1. CMMI and Scrum 2. Kanban Software Engineering 3. Software Development Life Cycle 4. Secure Software Engineering 2
Enterprise Software Engineering Agenda 1. CMMI and Scrum 2. Kanban Software Engineering 3. Software Development Life Cycle 4. 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 Input Code Debug Test Product 11
Engineering Software Resource Input F R PM D C RA T Product 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 DONE Requirements Design Code Testing Requirements Design Code Testing Requirements Design Code Testing Requirements Design Code Testing Time
Gimme all requirements, or.
The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements Analysis But Program Design Coding V&V Operations
The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements Specification Preliminary Design Document Software Requirements Prelim. Review UI Design Document Preliminary Design Preliminary Design Final Design Analysis Design Review Analysis Program Design Program Design V&V Plan Coding Coding Testing V&V Usage Operating Instructions Operations
Waterfall is like Cannonball
Waterfall Summary
Iterative Development
Incremental Development
Iterative and Incremental Development
Iterative and Incremental Process R D C T R D C T R D C T R D C T R D C T R D C T Time
What is Iterative and Incemental Development?
Risks in Waterfall and Iterative Methods We do risky things first R I S K Iterative development Waterfall T I M E 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
Capability CMMI Model Representations Staged Continuous ML4 ML5 ML3 ML2 ML 1 Organization PA PA Process PA 44
Equivalence Staging Maturity Level 3
The Appraisal Method
TWO BRANCHES OF SOFTWARE DEVELOPMENT AGILE METHODOLOGIES
The Manifesto for Agile Software Development Individuals & Interactions Working Software Customer Collaboration Responding to Change Processes & Tools Comprehensive Documentation Contract Negotiation Following a Plan 2001 50
Agile Manifesto February 2001, a subtle but deadly attack on Alistair Jim Martin Ward the old Cockburn Highsmith Fowler Cunningham Kent Beck 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% ASD; 22% FDD; 23% 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
Typically 5-9 people Cross-functional: The Team 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 multi-skilled workforce few job descriptions Information widely shared Few levels of management Whole-business focus Shared goals Seemingly chaotic Purpose achievement emphasis High worker commitment Continuous improvements Self-controlled Values/principles based Traditional Organization management driven workforce of isolated specialists Many Job Descriptions Information limited Many levels of Management Function/department focus Segregated goals Seemingly organized Problem-solving emphasis High Management commitment Incremental improvements Management-controlled 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 Database Application Life Sciences 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 Testing Sprint (1 or 2 weeks) Showcase Retrospective Planning meeting
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 Current product Technology Sprint planning meeting Sprint prioritization Analyze and evaluate product backlog Select sprint goal Sprint planning Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint goal 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 What did you do yesterday? What will you do today? Is anything in your way? 1 2 3
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 Iteration Level Story Release Level Story Iteration 1 4 weeks Release 1 12 weeks Project 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. As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 3 8 Improve exception handling 8... 30... 50
A Sample Sprint Backlog Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 4 Test the middle tier 8 16 16 11 8 Write online help 12 Write the foo class 8 8 8 8 8 Add error logging 8 4
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
Hours Tasks Code the user interface Code the middle tier Test the middle tier Write online help Mon 8 16 8 12 Tues Wed Thur Fri 4 8 12 10 7 16 16 11 8 50 40 30 20 10 0 Mon Tue Wed Thu Fri
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