Upload
yannis
View
48
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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• 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
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.
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?
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
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)
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• 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
• 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
• 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
• 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
• 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?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?
• 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
• 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 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• 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 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
• 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