Agile sdlc


Published on

Agile SDLC

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile sdlc

  1. 1. Bhawani Nandan Prasad Agile Software Development Life-cycle Bhawani Nandan Prasad
  2. 2. Bhawani Nandan Prasad Objective To help you understand the principles of Agile software development and successfully implement the software development life-cycle on your projects
  3. 3. Topics Agile primer Why Agile? Mapping Agile to SDLC activities Writing good requirements A typical iteration in Scrum Software engineering best practices Wrapping up releases Bhawani Nandan Prasad
  4. 4. Why bother about Agile?  Israel Gat: Cutter Consortium:  “Agile can do to software development what internet did to computing”  “Agile is a train. Either you get on to it or you will be under it”  PMI research: Use of Agile has tripled from December 2008 to May 2011  Gartner: 80% of software development projects would use Agile by end of 2012  74% of IT professional surveyed had practiced Agile in some form or other; 55% for 2 years or more Copyright (c) Sandeep Shouche, CSM, PMP, PgMP, PMI-ACP 2012
  5. 5. Bhawani Nandan Prasad Problems with Software Development  Excessively long “time to market” for products  Customer orientation is lacking  Cost of delivering software is too high  Poor productivity of teams  Too much “wasted work” to fix defects and rework designs  Software quality is poor  Ability to responding to change is low  Employee morale is low (and attrition rates are high!)  Project failure rate is too high  ~70% or more  Delivered ROI falls short of expectations
  6. 6. Usage of features in a system Bhawani Nandan Prasad
  7. 7. Waterfall v/s Agile Bhawani Nandan Prasad
  8. 8. Waterfall v/s Agile Bhawani Nandan Prasad
  9. 9. Choosing Agile Bhawani Nandan Prasad
  10. 10. Bhawani Nandan Prasad Choosing Agile  • Are requirements for the finished project complete, clear and stable?  • Can the effort required to complete the project be easily predicted?  • Have you successfully completed previous projects similar to the one you’re about to start?  If you can answer “yes” to these questions, then a plan-driven process like the waterfall method is likely your best bet. Because answering “yes” to these questions indicates the project you’re about to start is predictable to a reasonable degree.  In short, If Project has three factors–urgency, complexity, and novelty - choose agile
  11. 11. Bhawani Nandan Prasad Traditional Software Development Design Coding Testing DeployAdvantage: Logically sound Disadvantage: Assumes predictability! Analysis
  12. 12. Bhawani Nandan Prasad Evolution of Agile  Iterative development, done in small incremental chunks, validating requirements at each step  Agile development evolved in mid-90’s – the word “Agile” was adopted in 2001  Has significant parallels with “Lean movement” in the manufacturing world  Is also similar to “spiral models”, except spiral iterations are longer and rely on “prototypes, where Agile emphasizes “working software”
  13. 13. Bhawani Nandan Prasad Providing early value Value Realized Time Incremental delivery All-at-once Delivery
  14. 14. Bhawani Nandan Prasad Agile Manifesto – Feb 2001 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas See
  15. 15. Bhawani Nandan Prasad Principles related to SDLC  Principle No.1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Break it up to deliver early and frequently  Principle No.2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Do not be bureaucratic about change management, be flexible to absorb change
  16. 16. Bhawani Nandan Prasad Principles related to SDLC  Principle No.3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Typical length of an iteration is 2 weeks to 2 months  Principle No.7: Working software is the primary measure of progress.  The output of each iteration must be “working software”  Principle No.9: Continuous attention to technical excellence and good design enhances agility.  Design is important, but design is “continuous” – not one time activity
  17. 17. Agile Unified Process  Four project lifecycle phases  Inception  Elaboration  Construction  Transition  Six engineering disciplines  Business modeling, Requirements, Analysis and Design, Implementation, Test, Deployment  Three supporting disciplines  Environment, Configuration and Change management, Project management Bhawani Nandan Prasad
  18. 18. Rational Unified Process (Continued) Bhawani Nandan Prasad
  19. 19. Bhawani Nandan Prasad Scrum Basics Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  20. 20. Bhawani Nandan Prasad Product backlog  List of everything that could ever be of value to the business for the team to produce.  Defined in terms of “epics” and “user stories”  Ranked in order of priority Priority is a function of business value and risk  Product owner can make any changes they want before start of a Sprint / Sprint Planning meeting It can be addition of new items, changing or removing or existing items or re-ordering them  Ideally for 2 sprints items should be well defined
  21. 21. Bhawani Nandan Prasad Example of Product Backlog Description Size Utility to mark all positions to market at end of trading day 20 Report on outstanding positions for SEBI filing 10 On-the-fly introduction of securities into intra-day trading 5 Upgrade server platform to JRE 1.6 5 Fix intermittent problem with index window flickering (Defect No.0002413) 10 Integrate Mark-to-market utility with trading system (execute every hour) 20  List of requirements in descending order of priority  Can be … Functional or non- functional Technical upgrades Significant bug-fixes
  22. 22. Bhawani Nandan Prasad User Stories and Epics  Epic: High-level theme that combines a set of planned features or requirements Examples … Scalability improvements to handle processing rate of 100 transactions per second Usability improvements  User Story: A short description of a planned feature or requirement. Examples … Modify server code to support multi-threading Reduce the size of packets sent over Reduce number of clicks to checkout to 5 Support Section 508 recommendations
  23. 23. Bhawani Nandan Prasad Epics and user stories Can include any or all of the following New features Modification or Deletion of existing features Bug-fixes to existing software Internal clean-up tasks like code re-factoring, support for new technologies, etc. Should all result in “adding value” to the customer!
  24. 24. Bhawani Nandan Prasad User Stories Should be small Typically no more than 40 man hours of effort Should be deliverable as a unit (de- coupled or loosely coupled) Should be described in as much detail as is necessary to “validate successful completion” May contain child stories or tasks
  25. 25. Writing good user stories  Example templates  As a [role], I can [feature] so that [reason]  E.g. As a account holder, I can check my balances online so that I can maintain daily balance  Use 3”X5” index cards (ensure that you don’t write too much)  Make it testable by writing acceptance criteria  Given [context] <and/or [some more context]> When [event] Then [outcome] <and/or [another outcome]  E.g. Given account balance is negative and no direct deposit is scheduled on the day when the account holder tries to withdraw money then the bank will deny the request and send the account holder an alert  Connect the dots by thinking of all possible scenarios  More references:  Bhawani Nandan Prasad
  26. 26. Bhawani Nandan Prasad How to split storiesRef: Bill Wake’s “20 Ways to Split Stories”: The Big Picture  • Research vs. Action  If a story is too hard, one split is to spend some time researching solutions to it.  • Spike vs. Implementation  You can buy learning for the price of a spike (a focused, hands-on experiment on some aspect of the system).  A spike might last an hour, or a day, rarely longer.  • Main Flow vs. Alternate Flows  (Use case terminology.) The main flow - the basic happy path - is usually the one with the most value.  • Manual vs. Automated  If there's a manual process in place, it's easier to just use that for a while before throwing it away.  • Buy vs. Build  Sometimes, what you want already exists, and you can just buy it. For example, you might find a custom widget that costs a few hundred dollars. It might cost you many times that to develop yourself.  Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you spent customizing it might have been better spent developing your own solution.
  27. 27. Bhawani Nandan Prasad How to split stories User Experience  Batch vs. Online  A batch system doesn't have to interact directly with the user.  Single User vs. Multi-User  Keep concurrency, access control issues, etc. in abeyance for some time.  API-only vs. User Interface  It's easier to not have a user interface at all. For example, if you're testing your ability to connect to another system, the first cut might settle for a unit test calling the connection objects.  Generic UI vs. Customer UI  At one level, you can use basic widgets before you get fancy with their styles. To go even further, something like Naked Objects infers a default user interface from a set of objects.
  28. 28. Bhawani Nandan Prasad 20 ways to split stories “Ilities”  • Static vs. Dynamic  It's easier to calculate something once than ensure it has the correct value every time its antecedents change.  • Ignore errors vs. handle errors  While it's less work to ignore errors, that doesn't mean you should swallow exceptions. Rather, the recovery code can be minimized.  • Transient vs. Persistent  Let's you get the objects right without the worries about changing the mapping of persisted data.  • Low fidelity vs. High fidelity  You can break some features down by quality of result. E.g., a digital camera could start as a 1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels, 10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy, 95% color accuracy." (William Pietri)  • Small scale vs. large scale  "A system that works for a few people for moderate data sets is a given. After that, each step is a new story. Don't forget the load tests!" (William Pietri)  • Unreliable vs. Reliable  "Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William Pietri)
  29. 29. Bhawani Nandan Prasad Typical life-cycle in a Scrum World Repeated as long as it takes to create a releasable product High-level Roadmap For a Release
  30. 30. Bhawani Nandan Prasad Release Planning  Aims at coming up with a “long-term roadmap”  What should happen during a release planning?  Prepare of a release roadmap with “epics” defined at high level  Estimate of what and how much can be accomplished in a release  Identify and tie up dependencies on external factors or events  Prepare a high-level project plan with milestones  Mode of release planning  Usually face-to-face, lasting up to a week  The entire team need not attend– key representatives should  Product Owner and optionally other stakeholders can attend  Advance preparation (understanding epics, priorities, dependencies, etc.) help this go faster
  31. 31. Bhawani Nandan Prasad Sprints Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  32. 32. Bhawani Nandan Prasad Sprints!  Refers to an “iteration” Typically 1-4 weeks long  Produces an enhanced version of the software All engineering activities (Code, Unit Test, System, Regression test) must be completed within the Sprint Should be “near releasable quality”  A “release” or project contains multiple sprints As many as is necessary to create substantial “value” to the customer
  33. 33. Bhawani Nandan Prasad Sprint at a glance
  34. 34. Bhawani Nandan Prasad Sprint Planning Meeting Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  35. 35. Bhawani Nandan Prasad Sprint planning meeting  Goal:  For the team to make good commitment around what it will deliver by the end of the Sprint  What’s a Good Commitment?  Clearly understood by all  Shared among team  Achievable without sacrificing quality  Achievable without sacrificing “sustainable pace” (heijunka!)  Attended by Team, Product owner, Scrum Master  Usually take 1-2 Hrs for each week of Sprint duration
  36. 36. Bhawani Nandan Prasad Sprint Calendar - Example Mon Tues Wed Thurs Fri 3 4 5 6 7 10 Sprint Planning 11 First day of Sprint 12 13 14 17 18 19 20 Last day of Sprint 21 Review & Retrospective 24 25 26 27 28
  37. 37. Bhawani Nandan Prasad How Sprint Planning should work Clarifying questions about stories asked Determine how many stories can “fit” into a Sprint Stories are broken down to tasks and assigned to individuals Estimates may be modified if necessary Tip: Some pre-preparation (story- grooming) helps make the meeting short
  38. 38. Bhawani Nandan Prasad Sprint backlog (planning template) Story Task Owner Estimate Utility to mark all positions to market at end of trading day Generate and test query to get open positions Sanjay 2 Determine formula for M2M based on regulations Shreya 4 Call web service to custodial services for margin calls Kapil 8 Email notifications to account owners about margin position Manish 2 Write and execute unit tests Sanjay 8 Test story end-to-end Murali 16 Upgrade server to JRE 1.6 Changes to the build system and installer Larry 8 Try out latest patch of JRE 1.6 to make sure it works Gaurav 16 Limited regression testing Alex 24
  39. 39. Bhawani Nandan Prasad No changes during a sprint!  Once team has committed, no changes can be made to the Sprint deliverables Details will emerge during Sprint, but no new work or substantially changed work  No Changes to Sprint Duration either Sprint ends on planned date whether has completed its commitment or not  The Product Owner can … Change the Product backlog before the next Sprint Terminate a Sprint (used very rarely)
  40. 40. Bhawani Nandan Prasad The team Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  41. 41. The team!  Usually 7 + or – 2  As low as 3 or as high as 15  Resources can be shared (but ideally should not be)  Can change between Sprints (but ideally shouldn’t)  Can be distributed (but better when co-located)  Is “cross-functional”  Has all the skills necessary to produce another increment of “potentially shippable” product  Is “self-managing”  Is empowered enough to do whatever it takes to produce the potentially shippable product, within organizational constraints Bhawani Nandan Prasad
  42. 42. Bhawani Nandan Prasad Daily Standup Meeting Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  43. 43. Bhawani Nandan Prasad Daily standup meetings  Ground-rules Every weekday Whole team attends Everyone stands 15 minutes or less  Everyone reports three things What was able to accomplish since last meeting What will try to accomplish since by next meeting What is blocking me  No discussion, conversation until end of meeting
  44. 44. Role of testing/QA in Scrum No separate QA team Quality is everyone’s responsibility One team that is responsible for the product delivery No more adversarial relationship between Dev and QA QA is lot tougher with Agile Near releasable quality each Sprint is a huge challenge Bhawani Nandan Prasad
  45. 45. Testing best practices Continuous testing and regression Automate as much testing as possible Testers to participate in story elaboration and estimation Test early and test often Close coordination between Developer and Tester needed Move towards “test driven development” Bhawani Nandan Prasad
  46. 46. Test-Driven Development Never write a single line of code until there is a failed automated test How to do it? Design: Figure out what you want to do Test: Write a test to express the design (it should FAIL) Implement: Write the code Test again: Now the test should pass Bhawani Nandan Prasad
  47. 47. Test frameworks/tools for TDD  Xunit  Junit (  cppunit (  Ruby  PHPunit  Jsunit  TAP (Test Anything Protocol)   Other test libraries  e.g.  Use code coverage tools (e.g. Clover, Emma, Cobertura) Bhawani Nandan Prasad
  48. 48. Bhawani Nandan Prasad Orderly closure of Sprints Backlog Item Priority Product Owner Inputs from Customers, Team, Execs, Support, etc. Team Sprint Backlog Sprint Planning Meeting Sprint 1-4 weeks Finished Deliverables Sprint Review Sprint Retrospective Scrum Master Daily Standup Once agreed, Sprint end date & deliverables do NOT change
  49. 49. Bhawani Nandan Prasad Sprint review Purpose of Sprint Review Demo (not just slides) what the team has built Generate feedback which Product Owner can incorporate in the product backlog Decide about “release” of the builds to the stakeholders (alpha, beta, etc.) Attended by Product Owner, Managers, Scrum Master and Team Usually lasts 2 Hrs
  50. 50. Sprint “done” criteria  Software with all features work as defined by the user story  All QA testing for completed features is done with no pending defects Regression tests pass  All documentation is completed  Planned stories demonstrated to the Product Owner, Customer and other stakeholders Bhawani Nandan Prasad
  51. 51. What happens if Done criteria are not met? Incomplete stories move to the backlog and prioritized again before the next Sprint Retrospective to determine why the plan commitment was not met Under no circumstances can you “extend” a Sprint! Bhawani Nandan Prasad
  52. 52. Bhawani Nandan Prasad Sprint retrospective  What it is? 1-2 Hr meeting followed by each Sprint Review/Demo Attended by Product Owner, Scrum Master, Team What’s working and what could work better  Why does Retrospective matter Accelerate visibility Accelerate actions to improve It’s a key mechanism of continuous improvements (Inspect & Adopt)
  53. 53. Bhawani Nandan Prasad How to make retrospectives effective Have fun (e.g. bring in food, recognize star performers from the previous sprint) One person facilitates (Scrum Master) Do not stifle opinion – collect all inputs Arrive at few (2-3) things to change Follow up! Assign specific actions Token penalty if improvements are repeated!
  54. 54. Bhawani Nandan Prasad Engineering best-practices Continuous integration: “Automated” nightly builds Mandatory code reviews (integrated with code check-ins) and unit tests Automated testing: Sanity tests, executed daily Regression tests, executed per iteration Test-driven development
  55. 55. Bhawani Nandan Prasad Wrapping up the release!  Once the work required for the release is done Final readiness checks for a “release”  Can be preceded by one or more “hardening” sprints No new features added during hardening Focus on fixing bugs, packaging, regression testing, performance testing, etc. Hardening sprints can be split across the release (need not all be at the end) Resist temptation to bank on hardening sprints to do required bug fixes – it quickly turns into waterfall in disguise
  56. 56. Release “done” criteria  Customer acceptance received  Beta feedback incorporated  Release documentation (e.g. Release Notes, Read me First, etc.) is completed  Non-functional requirements (e.g. Performance, Usability, etc.) are tested and validated  Regulatory and compliance requirements are met (e.g. Section 508, ECCN, License agreements, etc.)  All planned integrations with other products are tested and working Bhawani Nandan Prasad
  57. 57. Bhawani Nandan Prasad Release retrospective  What it is? A retrospective session for an entire release To draw lessons from the project and use for the future Bring an orderly closure to the activities of a release  How to make it effective? Bring in food! Do some reward and recognition Preferably bring an external facilitator Run like a brainstorming session to generate ideas Use mute mapping to prioritize ideas generated
  58. 58. Summary  Agile teams must master the art of working in small increments and delivering quickly  Good engineering practices are of paramount importance  QA must be built into the development process – automated testing is indispensable  If we are able to delivery early, we create value faster, and by getting feedback continuously, we are better able to adapt to the changing environment Bhawani Nandan Prasad
  59. 59. Bhawani Nandan Prasad Thank You