software development landscape from the well-known standish chaos report 1994 – software projects...

21
Software Development Landscape From the well-known Standish CHAOS Report 1994 Software projects fail: Cancelled - 31%; Late or lacking of features – 53% Industry has only delivered on-time and on-budget 16% of the time! 3 top reasons for failure Lack of user (sponsor) involvement No executive management support Unclear, incomplete, & changing requirements Typical software project experiences a 25% change in requirements 45% of features defined in early specs are never used

Upload: brittney-tucker

Post on 27-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Software Development Landscape From the well-known Standish CHAOS Report 1994

– Software projects fail:• Cancelled - 31%; • Late or lacking of features – 53%

– Industry has only delivered on-time and on-budget 16% of the time!

– 3 top reasons for failure• Lack of user (sponsor) involvement• No executive management support• Unclear, incomplete, & changing requirements

Typical software project experiences a 25% change in requirements

45% of features defined in early specs are never used

Page 2: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Bridge to Success• The Standish Group concluded that

keys to success are:

– Shorter time frames– Delivery of software components early and often– Iterative process– “Growing" software vs. "developing" software– Engage the user earlier – Clear statement and set of objectives for

components – Keep it simple! - Complexity = confusion and cost

Page 3: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Values of Agile Development

individuals and interactions

over processes and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to change over following a plan

While there is value in the items on the right,

we value the items on the left more.

Page 4: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Scrum Process• Key Practices Self-directed; self-organizing teams 15 minute daily stand up meeting

with 3 special questions 30-calendar day iterations Each iteration begins with adaptive

planning Stakeholder demo at end of each

iteration Team measures progress daily Each iteration delivers tested,

fully-functional software Never more than 30-days from

potential production release

•what did you do yesterday?•what will you do today?•what got in your way?

Page 5: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Benefits and Challenges of Scrum• Benefits

– Increased productivity through teamwork and focus– Increased satisfaction through transparency and involvement– Increased ROI through early delivery of high value functionality– High quality throughout the development cycle using Test-First– High energy, exciting process– People know the importance of their work– Opportunity to improve every 30 days

• Challenges– Leading the change– Good news, you know where you are.

Bad news, you know where you are…– Identifies all areas of improvement for engineering practices– Change in culture– Hard work

Page 6: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

De-Cubiclization 2004

Page 7: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Origins of Agile

Page 8: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Extreme Programming• Values:

– Communication– Simplicity– Feedback– Courage– Respect

• Practices:– Pair Programming– Planning Game– Iteration Planning– Test Driven Development– Whole Team– Continuous Integration– Coding Standards– Collective Code Ownership– Simple Design– Refactoring– On-site Customer– Open Workspace– Acceptance Tests (Customer

Tests)

Page 9: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Common Practices

• Short iterations (1 week to 1 month)• Continuous communication & integration• Designs driven by testability• User Stories• Don’t over-design (YAGNI), refactoring

when needed• “Travel Light”

Page 10: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Short Iterations• Usually 1 week (eg, XP or Evo) to 1 month (eg, Scrum)• During an iteration, requirements are usually fixed

– This enables developers to have stability while the business gets the ability to respond to change

• The highest priority things are always worked on first– This means that at any point in time, you’re delivering the

maximum possible business value– By extension, this also means that you avoid things that

don’t have the highest business value• Estimating things much beyond a week is “iffy”

Page 11: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Continuous Communication & Integration

• Follows the general “Principle of Least Surprise”• Teams are “self organizing”

– Have the responsibility and ability to identify and remove roadblocks

– Autonomous – sets its own policies and procedures within the context of the larger organization’s

– Everyone on the team knows what everyone else is doing

• Use “Big Visible Charts”

Page 12: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

User Stories

• Similar to “use cases” and “functional requirements documents”, but not… :-)

• The basic idea is to quickly (a sentence – a paragraph) give description of what’s needed– The point is to encourage collaboration over contracts

while still providing the written record of what is needed

• Describe external behaviors of the system understood by the custmer

Page 13: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Test Driven Development

• Write tests as early as possible– QA helps define/ensure functionality features

• Use a tool to track the tests– PHPUnit, Selenium

• Continuous Integration Environment– Automate integration testing– Cruise Control

• Testing done all the time– No big “OMG, we have to test this thing now”

Page 14: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Sample Timeline

• Four week cycle• Lots of discussion before project is “approved”

and started by dev team• Week one is overlap with previous cycle• Working out estimates, assignments, design• Week two-three heavy dev work• Week four – dry runs to launch, testing

Page 15: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

What Are The 3 Questions?

1. What have you completed (relative to the Backlog) since the last Scrum meeting?

2. What got in your way of completing this work?

3. What will you do between now and the next Scrum meeting?

Page 16: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

At the End of a Sprint?

• Status meeting with all stakeholders. • Increments are delivered.• Surprises are reported.• ANYTHING can be changed, work can be added, eliminated, re-

prioritized.• New estimates and team assignments are made for the next Sprint.• The project can be cancelled.

“Experience from earlier increments allows better estimates and planning as project progresses.It's always easier to estimate shorter development periods”

Page 17: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Planning Iteration

• Collect all user stories • Pick one feel its easy and give it worth 1• Select all stories with same worth level 1• Select stories with twice work of worth 1 mark as

worth 2• Repeat that to get stories with worth 4• Select stories with worth between 2 and 4 and

mark it as worth 3• Create a card for each stories with its worth

Page 18: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Planning Iteration

• Count total stories point• Estimate one story with worth 1 (e.g. 5 man/days)• Total estimation for release = total point * (worth1

estimation)– Example total estimation = (17 point) * 5 = 85 man/days

• If we have 2 developers then its should completed in 43 man/days

Page 19: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Planning Release

• Capacity Planning– Sprint (Iteration) = 2 weeks = 10 days– Sorties shouldn’t exceed our capacity– Capacity = 10 days / (estimation for worth 1 story=5) * number of

developer (2) = 4 story point for one sprint– Customer should prioritize stories– Customer should select stories with total point no more than 4

points– E.g. story one & two = 3 points– After sprint completed in two weeks, developer still need 0.5 point

to complete– Then team velocity is 3- 0.5 = 2.5 points per sprint instead of 4 points

Page 20: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Planning Release

• Now we have estimation for all release• 17 (total points)/ 2.5 (velocity)= 7 sprints to

complete all stories• Each sprint is 2 weeks• Then we have 2 * 7 = 14 week to complete

release• If 14 weeks are not suitable (exceed deadline)

then we have to tuning scope

Page 21: Software Development Landscape From the well-known Standish CHAOS Report 1994 – Software projects fail: Cancelled - 31%; Late or lacking of features –

Tuning Scope

• If deadline will complete 12.5 story points and there is 4.5 story point out from this release

• We have three approaches – Increase number of developer to meet deadline– Take out some stories from this release– Break down some stories worth by splitting card

one for release 1, and one for next release