Designing the Process. A Brief Introduction to Agile Programming

Transcription

1 Designing the Process A Brief Introduction to Agile Programming

2 In the beginning, there was the waterfall... Analysis, Design, Implementation, Testing & Evaluation: Discrete, linear tasks Each step completed before the next step can proceed

3 Waterfall Highly structured Not very adaptable

4 Agile: a new paradigm Process model that recognizes the significance of change and responsiveness Emphasis on adaptability Same basic steps are involved (ADITE), but throw out linearity and discreteness

5 Agile view of programming process Feedback at each stage Linkage Collaboration

6 Scrum: Agile for software development Scrum is the most prominent example of agile model in the programming world Scrum describes both the process and the participants in the process

7

8 Scrum as process framework Sprint: basic work cycle 1-4 weeks in duration (assuming 40+ hour weeks) Tasks pulled from prioritized list of requirements (top first) Working software delivered at end of each sprint Fixed duration: end at predefined end date, whether successful or not

9 Product backlog: example Source: onproductmanagement.net

10 Product backlog: example Source:

11 Scrum artifacts Sprint backlog (aka release backlog) Detailed list of requirements to be met during current sprint Includes time estimates (programmer-hours) for completion of each task No more than 16 hours per task Larger tasks broken down into smaller tasks if estimate exceeds this limit

12 Product backlog vs. Sprint Backlog Source:

13 Scrum artifacts User stories (customer requirements) Used in lieu of conventional (long, detailed) requirements docs Basic unit of backlog Generated by customer (user) Describe what system needs to do for them Not limited to UI Short 2-3 sentences non-technical Serve purpose similar to use cases Product owner prioritizes these, may tweak them Programming team uses these to create time estimates for sprint

14 User stories Suggested formats: As a [role], I want [feature] because [reason] As a [role], I can [feature] As a [role], I can [feature] so that [reason] Examples: As a student, I want to see a list of classes so that I can register As account owner, I can check my balance online As a user, I want to search for my customers by their first and last names.

15 Forms of user stories* Cards: like CRC cards, only less (or more) Conversation: discussion surrounding card: how team interprets what's there Confirmation: tests that verify requirement(s) met ** * Source: ** Source:

16 User stories Source:

17 Product backlog vs. Sprint backlog Source: agile.dzone.com

18 Sprint backlog example Source:

19 Scrum artifacts Burndown chart Shows ongoing (cumulative) work done & remaining in sprint Updated daily Guide for team: on-time delivery of working product

20 Burndown chart: example Source:

21 Burndown chart: example ource:

22 Kanban board Not really a Scrum artifact (Scrum & Kanban are really two different Agile methodologies) but often associated with Scrum projects Visual tool (like burndown chart in that sense) for monitoring project progress May be used to visualize sprint backlog

23 Kanban board examples Source: /commons/thumb/d/d3/simplekanban-board-.jpg/400px-simplekanban-board-.jpg Source:

24 Scrum roles Product owner: in charge of project backlog; acts as the voice of the customer Scrum team: develops the product Cooperative, self-organizing Cross-functional Scrum master: facilitates meetings, protects & serves the team

25 The process Start with product backlog Sprint planning meeting Product owner & team review high priority items, decide what to implement during this sprint goal is for team to understand what product owner wants Team then focuses on detailed task planning: Time estimates Ordering of tasks to maximize both speed & quality of production

26 Sprint Basic work cycle of scrum Team works from product backlog Fixed time frame Goal: working product at end of every sprint Product may be prototype or some aspect of larger system Emphasis here is working product something tangible to show for work

27 The process Daily scrum Short meeting; team members report What they did since last meeting What they plan to do before next meeting Any problems getting in the way of progress scrum master responsible for helping solve these

28 The process Sprint backlog & burndown chart updated daily Product owner works with team to groom product backlog on a regular basis: Refining requirement details Splitting large tasks into smaller ones Time estimation for new items Re-estimation of existing items

29 The process Ending the sprint Duration is preset sprint is not extended Sprint review: team & product owner inspect & adapt whatever team has produced Sprint retrospective: team review of sprint: What went well What could be improved Things to try Issues to escalate Start next sprint cycle

30 Problems with Scrum Mostly, it doesn't work if you don't do it right, e.g.: Meeting rules not followed Goals are unclear Key players not available to answer questions Product backlog not prioritized well Not everyone contributes

31 Benefits of Scrum Puts the agile in agile development: Sensitive to changing requirements Doesn't attempt to understand entire project before it's started emphasizes learning along the way Delivers a working product quickly Customers (via product owner) set priorities Products developed according to these priorities