Agile methods
Download as PPTX, PDF9 likes5,759 views
The document provides an overview of agile software development methods. It discusses the history and principles of agile development, including the Agile Manifesto. Specific agile methods like Scrum, XP, RAD, TDD, Crystal and Kanban are covered. For Scrum, it describes the roles of Product Owner, Scrum Master and Development Team. It also explains Scrum events like Sprint Planning, Daily Scrums, Sprint Review and Retrospective. The document aims to give the reader a brief introduction to common agile concepts and practices.
![Top Distributed Scrum IssuesDifficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintainDifficulty synchronizing work between distributed sitesLack of effective communication mechanismsConflicting behaviors, processes, and technologiesIncompatible data formats, schemas, and standardsEnsuring electronic transmission confidentiality and privacyDifficult to share values [Bas Vodde]A brief introduction to Agile Software Development40Sutherland et al.](https://image.slidesharecdn.com/agilemethods-110924014626-phpapp01/85/Agile-methods-47-320.jpg)
Agile methods
- 1. Agile MethodsA brief guide to agile software developmentDuong Trong Tantandt@fpt.edu.vnHCM city, 9- 2011
- 2. ObjectivesSoftware Engineering history & agileWhat is agile development?The Agile ManifestoThe diversity of methodsScrumXPRADTDDCrystalKanbanAgile mashupThe cooperative gameA brief introduction to Agile Software Development2
- 3. Agile Basics“Agile projects succeed when the team gets the spirit of agility.” – Ron JeffriesA brief introduction to Agile Software Development3Image courtesy of Pollyanna Pixton
- 4. A brief introduction to Agile Software Development4Continuous improvementHyper productiveKaizenAgileSmall teamsBuzzwordsIncrementalLeanChangesEarned Value BasedIterativeRapidAdaptive
- 5. HistoryA brief introduction to Agile Software Development5SEScrumWeinberg: psychology of computer programDeclaration of IndependencedeMarco: PeoplewareXP2005201120011970198019951990AgileAlliance.org1968Gilb: Principles of Software EngineeringRoyce: managing the development of large software systemsPMI developed agile certificationsRADDSDM
- 6. A brief introduction to Agile Software Development6So, what are software projects?
- 7. Partiesand ConcernsUsers?Customers?BO?Developers?A brief introduction to Agile Software Development7
- 8. A brief introduction to Agile Software Development8What is agile development?
- 9. The Agile Manifesto 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 toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planA brief introduction to Agile Software Development9That is, while there is value in the items on the right, we value the items on the left more.AgileAlliance.org
- 10. The Twelve Principles of Agile Software Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity--the art of maximizing the amount of work not done--is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.A brief introduction to Agile Software Development10AgileAlliance.org
- 11. Home ground comparisonA brief introduction to Agile Software Development11
- 12. The diversity of methodsA brief introduction to Agile Software Development12
- 13. Rapid Application DevelopmentOne of the earliest methodA strategy instead of comprehensive processUtilizing of Prototyping“VB – Access Method”Still useful, esp. prototyping techniqueA brief introduction to Agile Software Development13
- 14. PrototypingEarly visibility of the prototype gives users an idea of what the final system looks likeEncourages active participation among users and producerIncreases system development speed (in RAD)Steps:Identify basic requirementsDevelop Initial PrototypeReviewRevise and Enhance the Prototype14A brief introduction to Agile Software Development
- 15. ScrumA hyper-productive development modelA brief introduction to Agile Software Development15
- 16. ScrumOne of the most successful agile methods because of its hyper-productivityIt is management – orientedSomewhat CMM Level 3 equivalenceWidely used in various types of projectsGoogle AdWorlds project3MUniversities RnD projectsIn VN: LogiGear, KPM, FSOFT, FAT, etc.A brief introduction to Agile Software Development16
- 17. Scrum FrameworkA brief introduction to Agile Software Development17Scrum TeamRulesRulesScrumTransparencyInspectionAdaptionArtifactsScrum EventsRules
- 18. A brief introduction to Agile Software Development18Image courtesy of ScrumAlliance
- 19. Scrum RolesScrum MasterProduct OwnerDevelopment TeamOther parties (all kinds of ‘chicken’)A brief introduction to Agile Software Development19
- 20. Transition of rolesProject ManagerTesterDeveloperSystem DesignerQAGraphic DesignerA brief introduction to Agile Software Development20Cross-functional Scrum Team
- 21. Management Transformation21Managers tell people what to do and make sure they do it properly
- 22. Managers maintain the right to authorize decision
- 23. Managers limit the information or resources available to workers
- 24. People decide what, and how to do
- 26. Information is transparentTOA brief introduction to Agile Software Development
- 27. Transition of organizationSelf-directed TeamMulti-functional TeamA brief introduction to Agile Software Development22Customer-drivenMulti-skilled workforceFew job descriptionsInformation widely sharedFew levels of managementWhole-business focusShared goalsSeemingly chaoticPurpose achievement emphasisHigh worker commitmentContinuous ImprovementsSelf-controlledValues/Principles basedManagement-drivenWorkforce of isolated specialistsMany job descriptionsInformation limitedMany levels of managementFunction/Department focusSegregated goalsSeemingly organizedProblem-solving emphasisHigh management commitmentIncremental ImprovementsManagement-controlledPolicy/Procedure based
- 28. Development TeamTeam is cross-functional and consists of 5-9 peopleThere are no set project roles within the teamTeam defines tasks and assignmentsTeam is self-organizing and self-managingMaintains the Sprint BacklogConducts the Sprint ReviewA brief introduction to Agile Software Development23
- 29. ScrumMasterHolds Daily Scrum meetingAssures every people related to the project follow the Scrum rulesRemoves obstaclesShields the team from external interference: “Keep Chickens away from Pigs”Conducts Sprint Retrospective at the end of a SprintIs a facilitator, not a managerA brief introduction to Agile Software Development24
- 30. Product Owner (PO)Accountable for product successDefines all product featuresResponsible for ordering product featuresMaintains the Product BacklogInsures team working on highest valued featuresA brief introduction to Agile Software Development25
- 31. Product BacklogList of all desired product featuresList can contain bugs, and non-functional itemsProduct Owner responsible for ordering the itemsItems can be added by anyone at anytimeEach item should have a business value assignedMaintained by the Product OwnerA brief introduction to Agile Software Development26
- 32. Examples of Product BacklogA brief introduction to Agile Software Development27
- 33. A SprintTime box: 2-4 weeks (why?)An iteration for building a piece of increment (potentially shippable) of the whole systemIt’s the working time, not planning or asking what to do.The team manages itself during a SprintThe team commits to Product Backlog during the Sprint planning meetingThe Sprint Backlog is updated during a SprintA brief introduction to Agile Software Development28
- 34. Sprint BacklogA brief introduction to Agile Software Development29Each item is prioritized and estimated
- 35. A brief introduction to Agile Software Development30The Scrum Skeleton2.Daily Scrum Meeting What have you done?
- 36. What will you do?
- 37. What is impeding you?3. A Sprint (2-4 weeks)4. Sprint Review Meeting1. Sprint Planning Meeting5. Sprint Retrospective Meeting
- 38. Sprint Planning MeetingTime box: 8 hoursProduct backlog prepared prior to meetingFirst HalfTeam selects items committing to completeAdditional discussion of Product Backlog occurs during actual SprintSecond HalfOccurs after first half done – PO available for questionsTeam solely responsible for deciding how to buildTasks created / assigned – Sprint Backlog producedA brief introduction to Agile Software Development31
- 39. Scrum Daily MeetingHeld every day during a SprintThe most important inspection event in ScrumTimebox:15 minutesTeam members talk to the whole Development Team, not Scrum MasterAsks 3 questions during meeting“What have you done since last daily scrum?”“What will you do before the next daily scrum?”“What obstacles are impeding your work?”Opportunity for team members to synchronize their workIt helps removing burdens between membersA brief introduction to Agile Software Development32
- 40. Sprint ReviewTime box: 4 hoursTeam presents “done” code to PO and stakeholdersFunctionality not “done” is not shownFeedback generated – Product Backlog maybe reprioritizedScrumMaster sets next Sprint ReviewA brief introduction to Agile Software Development33
- 41. Sprint RetrospectiveTime box: 3 hoursParticipantsScrumMaster Scrum Team. Product Owner is optionalQuestionsWhat went well and what can be improved?ScurmMaster helps the team in discovery – not provide answersA brief introduction to Agile Software Development34
- 42. Sprint BacklogA kind o f To-do list for a SprintCreated by the Scrum Team (can be originated by one member, responsibility belongs to another)Product Owner has defined as highest priorityUsed for synchronizing works between team membersA brief introduction to Agile Software Development35
- 43. Sprint Backlog examplesA brief introduction to Agile Software Development36“digital” Sprint Backlog“analog” Sprint Backlog >>
- 44. The Burn-down ChartA brief introduction to Agile Software Development37Burndown Chart shows the Sprint trend, the performance\velocity of the team through Sprints
- 45. Potentially Shippable ProductSelected items are fully implemented, tested and ready for useSmall but complete, “it will be bigger”Scrum Team needs to define what does “done” mean, in what aspects and contexts.“DONE” may be executable, “passed all tests”, “approved by senior engineers”, “reviewed by peers” or just nothing to do more with the item.A brief introduction to Agile Software Development38
- 46. Distributed ScrumIsolated Scrums - Teams are isolated across geographies. Distributed Scrum of Scrums –Scrum teams are isolated across geographies and integrated by a Scrum ofTotally Integrated Scrums – Scrum teams are cross-functional with members distributed across geographies.A brief introduction to Agile Software Development39Sutherland et al.
- 47. Top Distributed Scrum IssuesDifficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintainDifficulty synchronizing work between distributed sitesLack of effective communication mechanismsConflicting behaviors, processes, and technologiesIncompatible data formats, schemas, and standardsEnsuring electronic transmission confidentiality and privacyDifficult to share values [Bas Vodde]A brief introduction to Agile Software Development40Sutherland et al.
- 48. eXtreme ProgrammingFrom hacking code to a real processA brief introduction to Agile Software Development41
- 49. eXtreme Programming ProjectA brief introduction to Agile Software Development42
- 50. XP ValuesSimplicity encourages starting with the simplest solutionCommunicationfavors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedbackFeedbackFrom the system, customer and from the team, to avoid optimismCouragedesign and code for today and not for tomorrowRespectrespect for others as well as self-respectA brief introduction to Agile Software Development43
- 51. A brief introduction to Agile Software Development44
- 52. XP RolesThe Customer Sets project goals and makes business decisionsThe Developer Turn customer stories into working codeThe Tracker Keeps track of any metrics used by teamThe Coach Guides and mentors the teamA brief introduction to Agile Software Development45
- 53. Test Driven DevelopmentTests created before codingFocus on qualityNot a complete development strategyDerived version: Behavior-Driven Development (BDD)A brief introduction to Agile Software Development46
- 54. TDD RationaleA brief introduction to Agile Software Development47
- 55. TDD StrategyYou don’t start programming until you have designed your tests!StrategyMake it FailNo code without a failing testMake it WorkAs simply as possibleMake it BetterRefactor(code, design, test, documentation)Believe in testingA brief introduction to Agile Software Development48
- 56. Acceptance TDD3D strategyDiscuss in requirement workshopTo make tests libraryDevelop in concurrenceTo create more Passed featuresDeliver for acceptanceTo meet DONE definition, accepted by users49A brief introduction to Agile Software Development
- 57. Continuous IntegrationContinuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently.Supported by a CI system with lots of automated tests, builds and other generated artifacts.Benefits:Increases transparencyIncreases cooperation and communicationEnables people to work on same code50A brief introduction to Agile Software Development
- 58. CI System51A brief introduction to Agile Software Development
- 59. Incremental DesignFlexible complex design on paper|CASE toolIncremental Design (not simplistic)52Something unexpected always changes
- 60. Something unexpected always changesMore complexity than needed. Hard to maintain. Easier to adopt. ID is easier to change. Less complexityA brief introduction to Agile Software Development
- 61. Pair ProgrammingA pair of developers shares a problem, a computer, a keyboard and a goal: solve the problemPP was defined in XPUtilize the R-mode activitiesImprove communication and effectivenessImprove software qualityWidely ADOPTED, but CONTROVERSAL!2 roles: Driverand Navigator:The Driver doesn’t see the big pictureThe Driver should “step a way from the keyboard”The Navigator tends to use pattern-matching problem solving technique53A brief introduction to Agile Software Development
- 62. RefactoringYou practice “code a bit, fix a little” => result in dirty code & bad design.Refactoring helps in restructure or design your code to make it better. what does “better” mean?Keep in mind:MaintainabilityExtensibilityHigh CohesionLow Coupling54A brief introduction to Agile Software Development
- 63. Crystal Clear“A human-Powered methodology for small team”A brief introduction to Agile Software Development55
- 64. Crystal Clear PracticesFrequent DeliveryReflective ImprovementOsmotic CommunicationPersonal SafetyFocusEasy Access to Expert UsersAutomated TestsConfiguration ManagementFrequent IntegrationA brief introduction to Agile Software Development56
- 65. Crystal Clear“The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.” - Alistair CockburnA brief introduction to Agile Software Development57
- 66. Crystal ClearEvery product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve. - Alistair CockburnA brief introduction to Agile Software Development58
- 67. Crystal Clear RolesSponsorAllocates money for the projectExpert UserLead DesignerLead Technical person, mentors less experienced team membersDesigner-ProgrammerEach person designs and programsA brief introduction to Agile Software Development59
- 68. KanbanKanban literally means “visual card,” “signboard,” or “billboard.” Toyota originally used Kanban cards to limit the amount of inventory tied up in “Work In Progress” on a manufacturing floorA brief introduction to Agile Software Development60…Step 1DoneStep 2Step nInProcessInProcessInProcessQueueQueueQueue…Work Items
- 69. A brief introduction to Agile Software Development61Why use Kanban in Software Development?
- 70. Time-boxed iterative development has challenges Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller
- 71. Smaller development items are often too small to be valuable and difficult to identify
- 72. Quality of requirements suffers as analysts rush to prepare for upcoming cycles
- 73. Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development
- 74. Quality often suffers as testers race to complete work late in the development time-box A brief introduction to Agile Software Development62
- 75. The time-boxed iteration dramaA brief introduction to Agile Software Development63
- 76. A brief introduction to Agile Software Development64Using a Kanban approach in software drops time-boxed iterations in favor of focusing on continuous flow.
- 77. Kanban queueA brief introduction to Agile Software Development65…DoneStep 2Step nWork ItemsStep 1InProcessInProcessInProcessQueueQueueQueue…
- 78. Kanban queues (cont’d) Large enough to keep the team busySmall enough to avoid premature prioritisationIdeally should be FIFOA brief introduction to Agile Software Development66
- 79. Kanban - Work In ProgressReduce multi-taskingMaximize throughputEnhances teamworkA brief introduction to Agile Software Development67
- 80. The multitasking issuesFacts:20% time lost to context switching per ‘taskSequential yields results soonerA brief introduction to Agile Software Development68AAABBBCCCABCChart courtesy of Yahoo!
- 81. ThroughputA brief introduction to Agile Software Development69Organizational overhead goes up as work in progress increasesTotal Cycle Time = Number of Things in Process Average Completion Rateto improve cycle timeImprove Average Completion RateReduce Number of Things in Process
- 82. Enhances TeamworkTeam focus on goals that add value not individual tasksA brief introduction to Agile Software Development70
- 83. Kanban Example 1A brief introduction to Agile Software Development71Image courtesy to Jeff Patton
- 84. Kanban Example 2A brief introduction to Agile Software Development72
- 85. Kanban Example 3A brief introduction to Agile Software Development73
- 86. Agile MashupIt follows the Agile Manifesto and keeps the sprit of agilityIt utilizes practices from several methods, for example:Use sprint backlog and user stories with TDD and standup meeting with a kanban liked dashboard.Use stand up meeting in daily ScrumUse Burn down chart in KanbanA brief introduction to Agile Software Development74
- 87. A brief introduction to Agile Software Development75Agile Software Development - a cooperative game.Alistair Cockburn
- 88. 76PaperFace-to-face communication is better2 people atwhiteboard2 people on phoneCommunication EffectivenessVideotape2 peopleon email Richness of communication channelA brief introduction to Agile Software DevelopmentSlide courtesy to Cockburn. A.
- 89. References and Further ReadingsAgile Software Development: The Cooperative Game, 2ndEdn. By Alistair Cockburn.Scrum Guide 2010 by Ken Schwaber and Jeff SutherlandAgile Project Management with Scrum by Ken Schwaber Agile Java Crafting Code with Test-Driven Development By Jeff LangrTest-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov Extreme Programming Explained by Kent Beck XP introduction,http://www.extremeprogramming.org/http://xprogramming.com/http://www.agilealliance.org/Kanban Oversimplifiedhttp://www.agileproductdesign.com/blog/2009/kanban_over_simplified.htmlKen Schwaber & Jeff Sutherland, Scrum Guide, Scrum.orgPete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer, GoodAgile.com HanoiScrum.netAgileVietnam.orgScrumAlliance.orgAgileAlliance.orgA brief introduction to Agile Software Development77
- 90. Q&AA brief introduction to Agile Software Development78
- 91. A brief introduction to Agile Software Development79Thank you!Let’s Go Agile!Sunday October 23rd 2011FPT University, Innovation Building, Quang Trung Software City, District 12, HCMC, Vietnam
Editor's Notes
- #4: film
- #6: A research and reflection of SomeBody:We are living in chaos: eco crisis, tech boom, changes …
- #7: How to create a software from scratch?
- #8: Parties:UsersHas problems to be solvedUsually disorganized, chaotic, groupCustomersProvides requirements and validationShould speak with “one voice”Developers Actually builds the stuff Lots of different roles hereBusiness Owner Manages resources and money Often ignored in Development Process…Tech concernsRequirementsDetermine What the Software has to do…Challenge: Satisfy the UsersProduction Actually Build the Software Challenge: Deliver Quality ProductMaintenance Modify Software to satisfy new requirements Challenge: Maintain Quality
- #11: For reference and printing if needed, not for presenting
- #12: Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp. 55–57. ISBN 0-321-18612-5.
- #15: Inherit from RAD
- #18: Film firstVẽrađồhình Scrum3 PhútBạnnàocóthểgiúptôicắtnghĩatừ framework nhỉ? “độtnhiêntôithấybítừ”Kháiniệmkhunglàmviệc (framework) làgì?Tạisaokhônggọi Scrum làquytrình?
- #22: Cross the mountainTraditional managers => ScrumMaster
- #24: cross-functional = there is no strict role for individualsCode are collectively developed
- #32: The importance of planning, not plan documentThe importance of responsibility -> select itemsThe importance of prioritizing -> reduce risksMake things clear
- #33: Image , point to position
- #41: Sutherland
- #43: Architectural spike():very simple program to explore potential solutions, Most spikes are not good enough to keepMetaphor(an du): common vision of how the program works
- #44: Courage(kien quyet)
- #49: Introduced in XP
- #52: SCM: svn,cvs, gitAutomated Build:Ant, Maven, MSBuild or IBM Rational Build ForgeAutomated tools: CruiseControl, Jenkins, Hudson
- #54: Introduced in XP
- #76: What does it mean?