Software development landscape
1 / 21

Software Development Landscape - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Development Landscape' - yannis

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software development landscape
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

Bridge to success
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

Values of agile development
Values of Agile Development

While there is value in the items on the right,

we value the items on the left more.

Scrum process
Scrum Process

  • what did you do yesterday?

  • what will you do today?

  • what got in your way?

  • 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

Benefits and challenges of scrum
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

De cubiclization 2004

Extreme programming








Pair Programming

Planning Game

Iteration Planning

Test Driven Development

Whole Team

Continuous Integration

Coding Standards

Collective Code Ownership

Simple Design


On-site Customer

Open Workspace

Acceptance Tests (Customer Tests)

Extreme Programming

Common practices
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”

Short iterations
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”

Continuous communication integration
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”

User stories
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

Test driven development
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”

Sample timeline
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

What are the 3 questions
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?

At the end of a sprint
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”

Planning iteration
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

Planning iteration1
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

Planning release
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

Planning release1
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

Tuning scope
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