Software development landscape
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

Software Development Landscape PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Software Development Landscape

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

De-Cubiclization2004


Origins of agile

Origins of Agile


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)

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


  • Login