Fabio Casati

1

Learning objectivesWhat is a software development processWhy we need itDifferent process types

waterfallSpiralRUPAgile methods (XP, Scrum, Crystal)Open source development

Understand basic principles, benefits, limitations, and applicability of each

2

Software process modelAttempt to organize the software lifecycle

by defining activities involved in software production order of activities and their relationships

Goals of a software dev processstandardization, predictability (?), productivity,

high product quality, ability to plan (?) time and budget requirements

Enable the consistent delivery of quality products and solutions

3

A waterfall modelfeasibility

Requirements

Design

Coding

Test/Fix

Deployment

Maintenance

Waterfall with feedbackfeasibility

Requirements

Design

Coding

Test/Fix

Deployment

Maintenance

Critical evaluation of the waterfall model+sw process subject to discipline, planning, and

management+postpone implementation to after understanding

objectives– Assumes you understand objectives before

implementation – linear, rigid, monolithic

– Assumes requirements are clear and do not change– Assumes perfect execution of all phases– Assumes underlying technology does not change

during the process (or that we do not capture the benefits of new products, e.g. a new app server )

6

Incremental and Iterative modelsIncremental: Build and deliver in increments –

possibly build one part at a time, integrate progressivelyOpposite of big bang integrationNot necessarily build the whole system and improve

Iterative: go through improvement cycles In practice, terms used together, or mixed. Benefits:

Deliver early (based on what is needed, and what can be done)

Get feedbackRevise goals and plan

Many variants available: "do it twice" (F. Brooks, 1995), evolutionary prototype, “extreme” variants

Some mix of waterfall and evolutionary is commonly used

7

8

Spiral modelB. Boehm, 1988(simplified)

9

Define goals, alternatives, constraints

eval alternatives, resolve risks

Develop - next iteration

Plan

Rational Unified ProcessDeveloped at rational software, late 80s,

90sDevelopment of an OO systemUses the UML notation throughout the

processSupports an iterative and incremental

processDecomposes a large process into controlled

iterations (mini projects)

10

Six principles1. Adapt the process2. Balance stakeholder priorities3. Collaborate across teams4. Demonstrate value iteratively5. Elevate the level of abstraction6. Focus continuously on quality

11

12

Objective milestone

Agreements on scope, estimates. Main use cases.

Operational capability milestone

Iterations of development. Generates release 1

Architecture milestone

Most use cases, dev plan, architecture, prototype

Product release milestonetraning, beta testing, depolyment

13

14

The manifesto: “we value…Individuals and interactions over processes

and toolsWorking software over comprehensive

documentationCustomer collaboration over contract

negotiationResponding to change over following a plan

http://agilemanifesto.org/

15

The Agile Primerpatrick.kua@thoughtworks.com

July 2008

© ThoughtWorks 2008

17

18

19

20

21

Manifesto: the principles (1-6)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.

22

Manifesto: the principles (7-12)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.

23

Iterations

Common Agile Practices

© ThoughtWorks 2008

Release

UserStories

UserStories

UserStories

UserStories

UserStories

UserStories

UserStories

UserStories

Iterations Iterations

25

26

stories

Exploration

storiesstoriesstories

Planning

Priorities,

Effort estimates

Iterations to release

Analysis, design, implementation, unit

test

testing Collective codebase

XP PrinciplesTest-driven, continuous integration (see

test cases) - tests firstRefactoringCustomer on sitePair programming (code+tests)Small releasesSimplicityCollective ownershipNo overtime

27

SCRUM

28

Scrum

29

PreparationBusiness case

show it is makes sense for your companyProject vision

Short doc that describes goalsInitial project backlog

All reqs, even bold or strange ones. Put em there Anybody contributes. Owner prioritizes

Initial Release Plan And effort estimate

Stakeholder buy-inAssemble team, and logistics

30

31

Scrum rolesOwner

ROI, scope

Team~7 self-organized

members

Scrum masterProtect team, manage

process, call meetings

32

Scrum process

33

Scrum daily meetingEach Team member should respond to the

following questions:What have you done?What will you do? What impedes you from performing your work as

effectively as possible?

Team members should not digress. The ScrumMaster is responsible for moving the meeting along briskly from person to person.

Team members should address the Team, not the master

Chickens can attend, not talk.34

Sprint rulesNo one outside the Team should provide directionThe Team commits to deliver Backlog items during

the Planning meeting. No changes from outside. If the Sprint proves to be not viable, the

ScrumMaster can modify or terminate the Sprint Team members have admin responsibilities

attend the Daily Scrum Meetingkeep the status of Sprint Backlog items up-to-date, e.g.

estimated hours remaining. If Team members report the same item more than

one day, they need to decompose the tasksThe Team must conform to existing standards

35

Open source development processOpen/collaborative development vs open

sourceCollaboration on everything, including

requirements definitionBased on free will contributions

Essentially made possible by:The WebSoft eng tools (collaboration, versioning)Rigorous testing

36

Principles (Karl Fogel)Participants are people, not companiesMake it rewarding to do things rightMake it easy to do things rightMake decisions in publicDocument the cultureDon't work – amplify other people's workNo obstacles: act now, audit later

37

REWARD

I N V E S T M E N T

Step Function = High-Barrier Community

REWARD

I N V E S T M E N T

Linear Function = Low-Barrier Community

Up Next: CMMI for DevelopmentMaturity levels for development processs

40

References Agile overview: “Agile software development methods -

review and analysis”http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf

XP: http://advisor.com/doc/13571RUP: reference above, the book, or the wikipedia article is

well done http://en.wikipedia.org/wiki/Rational_Unified_Process

Spiral: original article http://www.sce.carleton.ca/faculty/ajila/4106-5006/Spiral%20Model%20Boehm.pdf

Scrum: http://scrumforteamsystem.com/ProcessGuidance/ProcessGuidance.html

Open source: http://producingoss.com/41