A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

23
A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer

Transcript of A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

Page 1: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

A little Software Engineering:

Agile Software Development

C Sc 335Rick Mercer

Page 2: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

2

Goal and Outline

Main Goal:– Suggest practices, values, and some process for

completing a final project on time that is better than any one person could do it in in four times the time

Outline– Distinguish Waterfall (plan driven) from Agile– Practices of quality software development– Moving from User Stories -> Sprints with Tasks

Page 3: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

3

Waterfall Model

Waterfall was described by 1970Understood as– finish each phase– don’t proceed till done

W. W. Roycecriticized this– proposed an iterative approach

Page 4: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

4

Became Popular

Management (usually software ignorant) likes waterfall – easily set deadlines

Customers provide all requirements Analysts translate requirements into specificationCoders implement the specification Reviews ensure the specification is met Testing is performed by testers (not devs, QA team)Maintenance means modifying as little as possible – old code is good code

Change is hard, and costly

Page 5: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

5

A Spiral Approach

Dr Barry Boehm proposed a spiral approach

Page 6: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

6

To waterfall or not

Waterfall became popular– This process is still is used a lot

Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software – In his study, 87% of all projects failed – The waterfall process was the "single largest contributing

factor for failure, being cited in 81% of the projects as the number one problem."

[1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

Page 7: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

7

Cost of change

Costof

change

time

Waterfall

Agile

Page 8: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

8

Agile Software Development

60% of survey 2011 respondents: up to half of company’s projects are Agilehttp://www.versionone.com/state_of_agile_development_survey/11/

Set of SE practices that produce high-quality software with limited effort

Many books– Kent Beck

• Extreme Programming–Embrace Change

– Ken Schwaber, Mike Beedle, • Agile software development with Scrum

Page 9: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

9

eXtreme Programming

eXtreme Programming (XP) is – a disciplined approach to software development– code centric: no reckless coding, test-first– successful because it emphasizes customer

involvement and promotes team work– not a solution looking for a problem– One of several "agile" (can adapt to change)

software development processeshttp://www.agilealliance.org/

Page 10: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

10

Essence of XP

Four variables in software development: – Cost, Time, Quality, Scope (# features)

Four Values– Communication, Simplicity, Feedback, Courage

Five Principles– Provide feedback, assume simplicity, make incremental

changes, embrace change, quality workPractices– Planning games, small releases, simple designs, automated testing,

continuous integration, refactoring, pair programming, collective ownership, Continuous Integration, on-site customer, coding standards

Page 11: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

11

Cost of the Project

Paraphrasing from two software development companies I've talked to in Chicago and in Denmark

When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile

Page 12: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

12

An Agile Practice: The Planning Game

The planning game involves user stories– Short descriptions of desired features– Testable (and part of your grade, 10 points per sprint)

• Did you get those stories implemented in this 1 week sprint?

Clients write stories and assign story points– In 335, SLs wrote the stories (see final project specs)

• And have assigned story points to each, which are estimates of relative complexity: 1 3 5 8 13

Scrum calls these the Product Backlog – In 335, the project specifications have those User Stories and points

Page 13: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

13

An Agile Practice: Estimation

Based on similar stories from the pastYou get good at estimation simply by– just do it

Page 14: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

14

An Agile Practice: Sprints

Sprints range from 1 to 4 weeks– We choose 1 week sprints (because classes end in 4

weeks)A sprint should make sense as a wholeNeed to track stories during a sprint– Product Backlog is the complete list of stories that

needs to be implemented—see the project specs– The Iteration/Sprint contains just the things to be

executed during that sprint

Page 15: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

15

Sprints continued

Plan a sprint (we will do this three times)– Meet with you PM each of the next three weeks– Prioritize: Which “stories” should be developed next

• Move stories from product backlog to the sprint backlog• Create a list of tasks

– A task is a technical requirement such as implement a Command hierarchy for 5 commands

• Volunteer for those tasks• Finish those tasks so the stories are working

– By the end of Sprint (or lose team project points)

Page 16: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

335 Sprints

Your first planning meeting is next week– Have Artifacts Complete (10pts)

• Which means you know what you are supposed to do and have an idea of its architecture (classes and relationships between major objects)

– Have a Repo set up with access to all on team– Have a Rally Community edition setup with all story points

in the Product Backlog (can plan the sprint more quickly next week)

– Attendance and Engagement: 13pts16

Page 17: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

Preview a Sprint in Progress Ken Schwaber task board mockup

17

Page 18: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

Actual Task Board

18

Page 19: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

How do we plan and track

We will be using Rally’s Application Lifecycle Management platform – Been around a long time– Developed by Agile people– Will help us plan and track the 335 final project– Keeps us on task– Can see who did what

19

Page 20: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

ScreenShot of BackLog

20

Page 21: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

ScreenShot of Plan

21

Page 22: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

ScreenShot of Track

22

Page 23: A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.

Need a Volunteer

Request Rally’s Community Licensehttp://www.rallydev.com/product-features/rally-community-edition

Add a 2nd user (a team member)– Select Setup > Users > Add

Let Rick edit the Sample project a little– We only have one project and max of 10 people

23