Apt agile methodology


Published on

Published in: Design, Technology
  • Be the first to comment

Apt agile methodology

  1. 1. Agile MethodologyAn Introduction to the Concepts of the Agile Methodology
  2. 2. CopyrightThis material is primarily for the use of Orange andBronze Software Labs, Inc.No part of this material may be reproduced ortransmitted in any form or by any means, electronic ormechanical, including photocopying, recording, or by anyinformation storage and retrieval system, withoutpermission in writing from the publisher.www.orangeandbronze.com
  3. 3. Overview• What is the Agile Methodology? → History → Principles → Characteristics• Agile Method: SCRUM• Agile Method: XPwww.orangeandbronze.com
  4. 4. History• Evolved in the mid 90s as part of a reaction against “heavyweight ” methods → e.g. heavily regulated, regimented, micro-managed use of the Waterfall Method• Sought to move away from the Waterfall Method which was seen as bureaucratic, slow, demeaning, and inconsistent with the ways that developers perform effective work• Initially called lightweight methodswww.orangeandbronze.com
  5. 5. History• Earlier Methods → Scrum (1986) → Crystal Clear and Other Crystal Methodologies → Extreme Programming (XP) (1996) → Adaptive Software Development (ASD) → Feature Driven Development → Dynamic Systems Development Method (DSDM) (1995) → Agile Modeling → Lean Software Development → Agile Unified Process (AUP)www.orangeandbronze.com
  6. 6. The Agile ManifestoWe are uncovering better ways of developing softwareby doing it and helping others do it. Through this workwe 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 planwww.orangeandbronze.com
  7. 7. Agile Principles (The Agile Manifesto)• Customer satisfaction by rapid, continuous delivery of useful software• Working software is delivered frequently (weeks rather than months)• Working software is the principal measure of progress• Close, daily cooperation between business people and developers• Face-to-face conversation is the best form of communicationwww.orangeandbronze.com
  8. 8. Agile Principles (The Agile Manifesto)• Projects are built around motivated individuals, who should be trusted to get the job done• Continuous attention to technical excellence and good design• Simplicity• Self-organizing teams• Regular adaptation to changing circumstanceswww.orangeandbronze.com
  9. 9. Agile Characteristics• More adaptive than predictive• Focuses on the near future rather than the distant future• Focuses on adapting quickly to changing realities rather than planning for the entire length of the development process• Has a lot in common with Rapid Application Development www.orangeandbronze.com
  10. 10. Agile Characteristics• Time periods are strict time boxes and are measured in weeks rather than months• Highly collaborative work• Emphasizes real time communication• Emphasis on building releasable software in short time periods• Customer is on site and part of the development teamwww.orangeandbronze.com
  11. 11. Agile Characteristics• Phases → Inception → Elaboration → Construction → Transitionwww.orangeandbronze.com
  12. 12. Agile Characteristics• Inception Phase → Smallest phase in the project → Ideally short → Goals: • Establish a justification or business case for the project • Establish the project scope and boundary conditions • Outline the Use Cases and key requirements that will drive design tradeoffs • Outline one or more architectures • Identify riskswww.orangeandbronze.com
  13. 13. Agile Characteristics• Inception Phase → Goals: • Prepare a preliminary project schedule and cost estimate • Establish a baseline by which to compare actual and planned expenditures → Deliverables: • Objectives and Scope of the Project • High Level Use Cases • Candidate Architectures • Project Schedule and Cost Estimateswww.orangeandbronze.com
  14. 14. Agile Characteristics• Elaboration Phase → Project starts to take shape → Healthy majority of the system requirements is captured → Analysis of the problem domainwww.orangeandbronze.com
  15. 15. Agile Characteristics• Elaboration Phase → Primary Goals: • Address known risk factors • Establish and validate system architecture • Delve deeper into the requirements previously gatheredwww.orangeandbronze.com
  16. 16. Agile Characteristics• Elaboration Phase → Deliverables: • Detailed Use Cases • Conceptual Diagrams – Ex. Process Flow Diagrams, Activity Diagrams, etc. • Package Diagrams – Architectural Diagrams • Stable System Architecture • Plan for Construction Phase – Including cost and schedule estimateswww.orangeandbronze.com
  17. 17. Agile Characteristics• Construction Phase → Largest phase → Where the bulk of the coding takes place → Use cases are translated to demonstrable prototypes → System is built under the foundation laid in Elaborationwww.orangeandbronze.com
  18. 18. Agile Characteristics• Construction Phase → Main Focus: Development of components and features • Implemented in a series of short, timeboxed iterations • Each iteration yields an executable release of software → Deliverables: • First external release of the software • Succeeding releases of the software as per iterationwww.orangeandbronze.com
  19. 19. Agile Characteristics• Transition Phase → Product moves from development team to end users → Feedback received may lead to further refinements → Refinements may be incorporated in several iterationswww.orangeandbronze.com
  20. 20. Agile Characteristics• Transition Phase → Activities: • System conversion • Training of end users and maintenance team • Validation of system against end user expectation via beta testing • Quality level validation → Deliverables: • Final release of the systemwww.orangeandbronze.com
  21. 21. Agile Characteristics• Principles on Code Production → Keep it simple → Have one shared metaphor → Regularly restructure the system ( Refactoring) → Continuously integrate and test → Follow coding standardswww.orangeandbronze.com
  22. 22. Agile Characteristics• Agile Best Practices → Daily kickoff and review of goals → Short release cycles → Responsive development → Generalism • Use of generic skill sets that are common across the team, instead of reliance on specific skill sets that are scarce www.orangeandbronze.com
  23. 23. Agile Characteristics• Advantages → Customer decides scope, priority, and dates from a business perspective, while technical people estimate and track progress → Incremental development → Emphasis on responsibility for qualitywww.orangeandbronze.com
  24. 24. Agile Characteristics• Advantages → Emphasis on keeping it simple, regular refactoring, and continuous integration and testing → Lightweight, efficient, low-risk, flexible, scientific, and fun way of developing softwarewww.orangeandbronze.com
  25. 25. Agile Characteristics• Criticism / Disadvantages → Puts strong dependence on trust → Code-centered rather than design-centered → Lack of orderly design process and structured reviews may lead to extensive and time consuming tests www.orangeandbronze.com
  26. 26. Agile Characteristics• Criticism / Disadvantages → Lack of structure and necessary documentation → Only works with senior-level developers → Reliance on verbal communication → Requires too much cultural change to adopt www.orangeandbronze.com
  27. 27. Suitability with Types of Projects• AGILE Homeground → Low criticality → Senior developers → Requirements change frequently → Culture that thrives on “chaos” or changing realitieswww.orangeandbronze.com
  28. 28. Suitability with Types of Projects• PLAN-DRIVEN Homeground → High criticality → Junior developers → Requirements dont change too often → Large number of developers → Culture that demands orderwww.orangeandbronze.com
  29. 29. Agile Methods• Scrum• Extreme Programming (XP)• Agile Modeling• Agile Unified Process (AUP)• Agile Data Method• Test Driven Development (TDD)• Feature Driven Development (FDD)• Behavior Driven Development (BDD)• Essential Unified Process (EssUP) www.orangeandbronze.com
  30. 30. SCRUM• Originally a rugby term which is short for “scrummage”www.orangeandbronze.com
  31. 31. SCRUM• Characteristics → An iterative incremental process commonly used with the Agile Methodology → Can be used: • For managing software development projects • As a program management approach (Scrum of Scrums) → Works hand in hand with the PSA Time and Material Model www.orangeandbronze.com
  32. 32. SCRUM• Characteristics → A process skeleton that includes a set of practices and predefined roles → Employs “Sprints” - a time period, usually 15 – 30 days, in which development occurs on a set backlog items that the team has committed to www.orangeandbronze.com
  33. 33. SCRUM Roles• Pig Roles – The ones committed to the project and the Scrum process (Scrum Team)• Chicken Roles – The ones not part of the actual Scrum process but are only involvedwww.orangeandbronze.com
  34. 34. Pig Roles• Product Owner → The voice of the customer → Responsible for maintaining the Product Backlog• Scrum Master (or Facilitator) → Responsible for the Scrum process → Ensures that Scrum is used correctly and its benefits are maximized www.orangeandbronze.com
  35. 35. Pig Roles• Team → A cross-functional group of people → Responsible for managing itself to develop the productwww.orangeandbronze.com
  36. 36. Chicken Roles• Users → Who the software is built for• Stakeholders → People who have interest in the project → People within or outside an organization that may influence the projects objectives and outcomes• Managers → The people who will set up the environment for developmentwww.orangeandbronze.com
  37. 37. SCRUM Documents• Product Backlog → The WHAT that will be built → High level document for the entire project → Prioritized list of high level requirements → Contains broad descriptions of all required features, wish list items, etc. → Contains rough estimateswww.orangeandbronze.com
  38. 38. SCRUM Documentswww.orangeandbronze.com
  39. 39. SCRUM Documents• Sprint Backlog → Tells HOW requirements are to be implemented in the upcoming Sprint → Greatly detailed document enumerating tasks to be completed during the Sprint → Broken down list of tasks, with each task being no more than 16 hours → Tasks are never assigned, but signed-up for by team members www.orangeandbronze.com
  40. 40. SCRUM Documentswww.orangeandbronze.com
  41. 41. SCRUM Documentswww.orangeandbronze.com
  42. 42. SCRUM Documents• Burn Down Chart → Publicly displayed chart → Shows the amount of remaining tasks for the current Sprint → Updated daily → Gives a simple view of the daily progress of the team during a Sprintwww.orangeandbronze.com
  43. 43. SCRUM Documentswww.orangeandbronze.com
  44. 44. SCRUM General Practices• Customers are part of the development team• Frequent intermediate deliveries with working functionality• Frequent risk and mitigation plans• Transparency in planning and module developmentwww.orangeandbronze.com
  45. 45. SCRUM General Practices• Frequent stakeholder meetings to monitor progress• No one is penalized for recognizing or describing any unforeseen problems• Workplaces and working hours must be energized www.orangeandbronze.com
  46. 46. SCRUM Processwww.orangeandbronze.com
  47. 47. Extreme Programming (XP)“Extreme Programming is a discipline of softwaredevelopment based on values of simplicity,communication, feedback, and courage. It works bybringing the whole team together in the presence ofsimple practices, with enough feedback to enable theteam to see where they are and to tune the practices totheir unique situation.” – Ron Jeffries (2001)www.orangeandbronze.com
  48. 48. Extreme Programming (XP)• Founded by Ron Jeffries, Kent Beck & Ward Cunningham• A deliberate and disciplined approach to software development• Stresses customer satisfaction → It is designed to deliver the software needed by the customer and when it is neededwww.orangeandbronze.com
  49. 49. Extreme Programming (XP)• Empowers developers to confidently respond to changing customer requirements, even late in the life cycle• Emphasizes teamwork → Managers, customers and developers are all part of a team dedicated to delivering quality software• Involves changing the way we program, putting greater emphasis on producing simple, high quality codewww.orangeandbronze.com
  50. 50. Extreme Programming (XP) Ron Jeffries Ron Jeffries Kent Beck Kent Beck Ward Cunningham Ward Cunninghamwww.orangeandbronze.com
  51. 51. XP Values• Communication → Accomplished through documentation → Goal is to give developers a shared view of the system which matches the views held by the users• Simplicity → Start with the simplest solution, extras can be added later → Focus on today, not tomorrow → Simple design with simple code can be easily understood www.orangeandbronze.com
  52. 52. XP Values• Feedback → From the system through unit tests → From the customer through functional / acceptance tests → From the team through changes in the requirements• Courage → Enables developers to feel comfortable in refactoring their own code → Knowing when to throw obsolete code away → Persistencewww.orangeandbronze.com
  53. 53. XP Values• Respect → Respect for each members work → Nobody on the team should feel unappreciated or ignoredwww.orangeandbronze.com
  54. 54. Requirementswww.orangeandbronze.com
  55. 55. Capturing Requirements: User Stories• Each story is a short description of the behavior of the system, from the viewpoint of the user• The system is specified entirely through stories www.orangeandbronze.com
  56. 56. Capturing Requirements: User Storieswww.orangeandbronze.com
  57. 57. Iterative Development• What is an iteration? → A complete development cycle • Planning, Designing, Implementation, Testing → Customer selects features to implement at the start of the iteration → By the end of an iteration, the system should have acquired additional business behavior that implements business value to the customer www.orangeandbronze.com
  58. 58. Velocity• The number of IPDs (Ideal Programming Days) completed per iteration• Used to determine the amount the work that can be accomplished by the team or an individual in an iteration• The pace of the team or individualwww.orangeandbronze.com
  59. 59. Software Release Cycle• Software is built incrementally by iteration• Each iteration lasts from 1 – 3 weeks• Customer defines the release → Customer decides what to release at the end of one or more iterations www.orangeandbronze.com
  60. 60. Customer Defines Release• In each release cycle, the customer controls the scope: → What to do, what to defer → Provide the best possible release by due date• Towards or at the end of each iteration, the customer decides whether enough functionality has been added to warrant a release www.orangeandbronze.com
  61. 61. Common Problem: Too Much to Do• Not Enough Time → No solution: Cant create time• Too Much to Do → Have solutions: • Prioritize and defer some things • Reduce the size of the things you need to do • Ask someone else to do thingswww.orangeandbronze.com
  62. 62. Planning the Budget• The Items: Stories• The Cost: Estimates• The Budget: Team Velocity• The Constraints: Business and technology constraints discovered www.orangeandbronze.com
  63. 63. Planning the Release• Customer: Write enough stories to define a successful product or system• Development Team: Estimate effort of implementing each story• Customer: Prioritize stories based on business value and difficulty• Development Team: Divide stories into iterations based on team velocity (in previous iterations)www.orangeandbronze.com
  64. 64. XP Development Cyclewww.orangeandbronze.com
  65. 65. XP Basic Activities• Coding• Testing• Listening• Designing www.orangeandbronze.com
  66. 66. XP Core Practiceswww.orangeandbronze.com
  67. 67. XP Core Practices• Fine Scale Feedback → Pair Programming → Planning Game → Test Driven Development → Whole Team• Continuous Process → Continuous Integration → Small Releases → Refactoring or Design Improvementwww.orangeandbronze.com
  68. 68. XP Core Practices• Shared Understanding → Coding Standards → Collective Code Ownership → Simple Design → System Metaphor• Programmer Welfare → Sustainable Pacewww.orangeandbronze.com
  69. 69. XP Core Practices• Fine Scale Feedback → Pair Programming • Ensures all production code is reviewed by at least one programmer • Results in better design, better testing, and better code • A good way to pass knowledgewww.orangeandbronze.com
  70. 70. XP Core Practices• Fine Scale Feedback → Planning Game • Addresses two key questions: – What should/will be accomplished by the due date? – What to do next? • Emphasis on steering the project • Release Planning – Desired features are determined and estimates are done • Iteration Planning – Features are broken down into tasks – Costs are estimated in a finer level of detailwww.orangeandbronze.com
  71. 71. XP Core Practices• Fine Scale Feedback → Test Driven Development • Aims to improve the system; always notching forward, never backsliding • Its not enough to write tests, you have to run them • 100% or bust • Provides immediate feedbackwww.orangeandbronze.com
  72. 72. XP Core Practices• Fine Scale Feedback → Whole Team • Everyone on an XP team contributes in any way they can • The best teams have no specialists, only general contributors with special skill (Jeffries, 2001)www.orangeandbronze.com
  73. 73. XP Core Practices• Continuous Process → Continuous Integration • It is encouraged to integrate multiple times a day • Infrequent integration usually leads to “integration hell”www.orangeandbronze.com
  74. 74. XP Core Practices• Continuous Process → Small Releases • The team releases running, tested software, delivering business value chosen by the customer, every iteration (Jeffries, 2001) • Ultimate goal is to have software that is visible, which is given to the customer at the end of each iterationwww.orangeandbronze.com
  75. 75. XP Core Practices• Continuous Process → Refactoring or Design Improvement • Focuses on: – Removal of duplicate / obsolete code – Increasing cohesion – Decreasing coupling“High cohesion and low coupling are recognized ashallmarks of well-designed code for at least thirty years.” -- Ron Jeffries www.orangeandbronze.com
  76. 76. XP Core Practices• Share Understanding → Coding Standards • All the code looks as if it were written by a single – very competent – individual (Jeffries, 2001) • All the code looks familiar to the developerswww.orangeandbronze.com
  77. 77. XP Core Practices• Share Understanding → Collective Code Ownership • Code gets the benefit of many peoples attention, increasing code quality and reducing defects (Jeffries, 2001)www.orangeandbronze.com
  78. 78. XP Core Practices• Shared Understanding → Simple Design • Start simple, maintain through programmer testing and design improvement / refactoring → System Metaphor • A simple evocative description of how the program works (Jeffries, 2001) • Provides a common vision for the team • A way to get everyone on the same pagewww.orangeandbronze.com
  79. 79. XP Core Practices • Example of a Metaphor: “ This program works like a hive of bees, going out for pollen and bringing it back to the hive.” → Description for an agent- (Roberts, 2006) based information retrieval (Roberts, 2006) system (Jeffries, 2001)www.orangeandbronze.com
  80. 80. XP Core Practices• Programmer Welfare → Sustainable Pace • XP teams work at a pace that can be sustained indefinitely • Maximize productivity week in and week out • XP teams are “in it to win it, not to die” (Jeffries, 2001)www.orangeandbronze.com
  81. 81. Strong Opinions Against XP• Unstable Requirements → Informal change requests may lead to costly rework and scope creep• User Conflicts → Dependence on programmers being able to assume a unified client viewpoint www.orangeandbronze.com
  82. 82. Strong Opinions Against XP• Requirements are expressed as automated acceptance tests rather than specification documents• Requirements are defined incrementally, rather than trying to get them all in advance• Developers are required to work in pairswww.orangeandbronze.com
  83. 83. Strong Opinions Against XP• No “Big Design Up Front ” → Most design activities take place on the fly• A customer representative is attached to the project• Scalability → Historically, XP only works in teams of twelve or fewer people www.orangeandbronze.com
  84. 84. Benefits of XP• Allows one to be more Agile• Focus on programming• Enables quicker delivery of quality software than traditional methods• Enables more flexibility than traditional methods www.orangeandbronze.com
  85. 85. References• Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001) Manifesto for Agile Software Development. Retrieved from http://agilemanifesto.org• Clark, T., Vizdos, M. (2006) The Classic Story of the Pig and Chicken. Retrieved from http://implementingscrum.com• Jeffries, R. (2001) What is Extreme Programming? Retrieved from http://www.xprogramming.com/xpmag/whatisxp.htm www.orangeandbronze.com
  86. 86. References• Landingin, R. (2008) Agile Methodology Workshop [Powerpoint Slides].• Patel, N. (2006) Agile Methods [Powerpoint Slides]. Retrieved from http://greenbay.usc.edu/csci577/spring2006/site/presentat• Roberts, H. (Artist). (2006) Bees swarming around a beehive [Digital Image]. Retrieved July 31, 2008 from http://bluebison.net/sketchbook/2006/0906/bees.png•www.orangeandbronze.com