Agile and Open Source Software Development 3/15 Dirk Riehle Friedrich-Alexander-University of Erlangen-Nuremberg Lecture of 09.11.2009 Professur für Open-Source-Software Martensstraße 3 91058 Erlangen
Content of This Lecture Section Content 1 Limits of Lifecycle Model 2 Introduction of Agile Methods 3 Scrum Roles, Practices, Artifacts 4 Scrum's Product Management 5 Scrum's Development Process 6 Sprint and Release Planning Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 2
Recap Lifecycle Model Linear, phase-oriented process model 3.1 Limits of Lifecycle Model Intends to minimize risk through upfront planning No iterations, no user feedback, equates activities with phases start analysis design implementation end time Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 3
An Analogy for the Lifecycle Model Picture credit: From http://www.megawoosh.com Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 4
The Megawoosh Reality Picture credit: From http://www.megawoosh.com Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 5
From Extreme Programming Explained Learning to Drive Driving is about constantly paying attention, making a little correction this way, a little correction that way. This is the paradigm for XP. Stay aware. Adapt. Change. See [Beck and Andres 2005] Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 6
Agile Methods 3.2 Agile methods is the name of a class of process models Introduction of Agile Methods Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, etc. Unified by the recognition of a common philosophical base and joined in their rejection of the traditional life-cycle model... P E R P E R P E R... time Iterative processes are not new, see [Budde 1984] [Floyd 1989] Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 7
Agile Philosophy and Agile Manifesto Core agile method values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Codified (and marketed) as the Agile Manifesto See http://www.agilemanifesto.org Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 8
Scrum and Extreme Programming Scrum (mostly as process framework) Extreme Programming (XP) (mostly for development practices) Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 9
Scrum A particular agile method, invented around 1993, 1995 See [Sutherland 1995], [Schwaber 1995] A rugby situation requiring intense self-organizing collaboration Photo credit: Maree Reveley, CC-BY-SA 2.5 Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 10
Scrum's Roles, Practices, and Artifacts 3.3 Roles and Responsibilities Scrum's Roles, Practices, Artifact Product Owner Team Member Scrum Master Sprint Scrum Product Backlog Sprint Planning...... Sprint Backlog Sprint Review Daily Scrum Product Burndown Chart Practices Artifacts Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 11
Core Scrum Roles and Relationships Product Owner Scrum Master Developer... Team Developer Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 12
Scrum Role: Product Owner The product owner holds overall responsibility for the product Focus is on delivering business value through the product Owns and maintains product backlog and release plan Defines feature functionality and scope Faces internal and external customers, marketing department Is available to team to answer questions during sprints Jointly with development team Assesses and determines risk of features Addresses external supplies to product Does not tell team how to do things, only what to do Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 13
Scrum Role: Team and Team Member Team responsibilities Delivers product matching the agreed-upon requirements Commits to achieving sprint goals after planning discussion Is responsible to reaching appropriate development velocity Team member responsibilities Performs analysis, design, coding, testing, and documentation activities Team composition At least one senior engineer who can mentor more junior engineers Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 14
Scrum Role: Scrum Master (also ScrumMaster) Scrum master responsibilities Primary goal is to create a self-sustaining process Manages process, coaches people, brings forward issues Protects the team during the sprint from outside interruptions The scrum master does not... Manage people nor does performance evaluations Act as the project manager to rest of world Please note: scrum master is a role; may also be team member Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 15
Scrum's Product Management 3.4 Product owner is responsible for product management Product owner creates product concept Product owner maintains product backlog Product backlog is a prioritized feature list Maintained as list or table in spreadsheet or on wiki Does not contain activity descriptions (see planning, sprint backlog) Feature (or requirement) describes a user requirement Again, no activity, just a description of a user need Can be functional or non-functional requirements Scrum's Product Management Product management runs in parallel to development Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 16
Wahlzeit Product Concept Wahlzeit Product Concept Wahlzeit is a Web 2.0 application that lets users upload phot get to present their best photos and learn what other users th Wahlzeit is used to teach agile methods and open source sof Software at the University of Erlangen. It is an easy-to-learn yet complete Java application that is av Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 17
Wahlzeit Flowers Product Concept Wahlzeit Flowers Product Concept Wahlzeit Flowers is a web service that lets users upload flow Users get to present their best flower photos and can discuss users in discussion forums. Wahlzeit Flowers provides a high-quality channel for the flow industry to reach lovers of flowers and photography, reducing Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 18
A Snapshot of the Wahlzeit Product Backlog Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 19
Requirements Analysis and Feature Description Feature description Description: Allow user to determine notification interval about recent praise Acceptance tests: Profile UI allows for configuring notification intervals and notification agent sends out email according to user specification User story User story: I'd like to switch on and off notifications as well as enter the notification interval; I provide the interval in days Acceptance tests: Notifications on or off are displayed as a flag; interval is provided in days as a number >= 1 and < 30 Use case Use case: The user goes to the profile menu; s/he can switch on and off a boolean flag for notifications; the user can enter a number for the notification interval; finally, the user exits by clicking save Acceptance tests: After saving, the flag and notification interval are successfully saved to the database Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 20
Properties of a Good Feature Description I N egotiable: V aluable: E stimatable: S mall: T estable: ndependent: Features are orthogonal (independent) of each other. No feature is cast in stone; can be split or merged. Every feature should have apparent (economic) value. A feature should be clear and specific so the team can estima A feature should be small enough to be implemented in one sprint. A feature should have clear acceptance criteria (tests). Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 21
Example Wahlzeit Feature Description estimatable independent Allow a user to configure praise notifications for photos. A praise notification is one email listing all photos and their negotiable changes in praise. The email is sent out in regular intervals. The user can switch on and off the notifications, and the user can determine the frequency of such notifications. Frequency is in days, or weekly, or monthly. testable small valuable Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 22
Feature Classification by Value and Risk risk high realize never realize first low realize last realize second low high value Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 23
Scrum's Development Process Succession of equal-length sprints (= short iterations) Intervention points are during planning and review Product owner is always available to answer questions 3.5 Scrum's Development Process sprint n-1 sprint n sprint n+1... P E R P E R P E R... time 1-4 weeks 1-4 weeks 1-4 weeks P = planning E = engineering (i.e. design and implementation) R = review (or release or retrospective) Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 24
The Significance of (Short) Iterations Establishes shortest economically feasible feedback loop Short iterations lead to focus on high-value features first User feedback helps team steer product to meeting needs right Quality feedback helps team deliver high-quality software Feedback loop ensures problems and hence risk surfaces early Iterations help recognize and realize new innovative features Established well-worn rhythm is sustainable, avoids burnout Even with missed deadlines, partial functionality is better than none Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 25
Structure of an Exemplary Sprint start noon end day 1 Thursday day 2 Friday day 3 Monday day 5 Wednesday sprint planning... release daily scrum daily scrum daily scrum daily scrum product backlog development software development product backlog development software development product backlog development next sprint software development preparation product backlog development review software development retrospective Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 26
Start and Duration of a Sprint Original recommendation: one month for a sprint In some application domains, one month sprints are too long With one-month iterations, you can start on a Monday or the 1st Many recommend one week sprints, but they are hard to do One-week sprints require well-working team that knows how to scrum With one-week sprints, start on a Wednesday, not on a Monday Two week sprints are realistic, even for beginning teams Like with one-week sprints, to start on a Wednesday may be preferable Alternatively, align with half-month rhythm What's most important is the reliable rhythm Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 27
Types of Sprints Regular Sprints Exploration Sprints Release Sprints Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 28
Quantifying Effort with Story Points 3.6 A story point represents the expected effort for a story They are a relative measure (in contrast to person days) Point CategoryMeaning 0 No effort 1 Minimal effort 2 Small effort Sprint and Release Planning Story points typically bucket stories into effort categories Story points are determined by development team 3 Medium effort 5 Large effort 8 Very large effort 13 Too large effort Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 29
Estimating Effort with Planning Poker Planning poker is an estimation technique for user story effort Product owner proposes story, development team estimates effort Team acts as expert group (cf. Wideband Delphi method) The planning poker process is an iterative negotiation process 1. Product owner suggests story 2. Team members discuss story 3. Each member privately plays card 4. Cards are laid open 5. In case of consensus, move on 6. Discuss disagreement, goto 3 Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 30
Sprint Planning Sprint planning serves to create the sprint backlog The sprint backlog contains the features to be implemented Sprint planning is the first activity of a given sprint The product owner provides the prioritized list of features Developers play planning poker to assign effort to features Features get added to sprint backlog as long as there is room Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 31
Development Velocity (Speed) (remember Newtonian physics?) v = s = t = development velocity [story point / sprint] development effort [story point] number of sprints Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 32
Use and Usefulness of Development Velocity Over time, an average number of per-sprint story points emerge During demo/review, actual sprint achievements are counted Features that have not fully passed acceptance test are not counted This average number per sprint is the (team) development velocity The default development velocity is a team metric Within limits, it can be broken down to a user metric Changes to the team and other disruptions destroy its reliability Within limits, if team member availability varies, velocity can be adjusted Continued usefulness depends on development practices Refactoring, continuous integration, test-driven development Development velocity is mainly used for release planning Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 33
Release Planning The release plan maps sprints and features into a schedule Focuses on overall project/product goals by means of releases Is a prediction based on current data that is subject to change By way of derived reports allows for early recognition of problems Sprint # 1 2 3 15 Start/End21.10.2009-27.10.2009 28.10.2009-03.11.2009 04.11.2009-10.11.2009... 11.02.2009-17.02.2009 Goal Make UI presentable Allow for simple configuration Fix-up testing setup Features 1, 2, 6, 13, 21 9, 12, 14, 18, 27 3, 4, 10, 15 TBD Effort 13 15 17 Much of this depends on the type of project or product Comment Team forming Taking up speed Full speed; address test risk Final release v1.0 TBD Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 34
You Can't Manage What You Can't Measure Release Burndown Chart 14 8 13 3 11 5 10 1 81 76 69??? 20 Development Velocity Chart 18 15???? 14 8 5 Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 35
Outlook: Exercises, Next Lecture Exercises: planning, estimation Next lecture: engineering practices Agile and Open Source Software Development Dirk Riehle Universität Erlangen-Nürnberg 36
Questions? Feedback! Announcements Forum Slides http://groups.google.com/group/fau-ws09-auos https://fsi.informatik.uni-erlangen.de/forum/forum/130 http://osr.informatik.uni-erlangen.de/lehre/ws09/auos dirk.riehle@informatik.uni-erlangen.de Professur für Open-Source-Software Martensstraße 3 91058 Erlangen