Heavy vs Light Methodologies: Bulimic or Anorexic? · 2007. 6. 26. · Analysis Model Specified by Deployment Model Distributed by Design Model Realized by Implementation Model Implemented

1

Heavy vs Light Methodologies:

Bulimic or Anorexic?

Fernando Brito e Abreu ([email protected])Universidade Nova de Lisboa (http://www.unl.pt)QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

© Fernando Brito e Abreu 218-06-2007

AbstractAnorexia versus BulimiaOverview of heavy-weight methodologiesOrigins of light-weight methodologiesThe “Agile Manifesto”Agility example: XPThe dark side of the light Planned (RUP) vs Agile (XP)When to be agile?

2


Anorexia versus Bulimia

Anorexic (thin) project / Light-weight / AgileProject run unconstrainedTotal freedom for artists ☺Unpredictable deliverables

Bulimic (fat) project / Heavy-weight / PlannedHighly constrained project

e.g. following DoD Mil. Std 2167AHigh organizing overheads Very well defined deliverables ☺


Examples …

Thin? Anorexic?Fat? Bulimic?

Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Adaptive Software Process, Crystal Light Methodologies, Dynamic Systems Development Method (DSDM), Lean Development

CMM, ISO9000-3, ISO12207, PSP, TSP, ISO15504 (SPICE), RUP, CMMi, …

Light-weight methodologiesHeavy-weight methodologies

Agile software developmentPlan-driven methodologies

3


Overview of heavy-weight methodologies

Processes and toolsComprehensive documentationContract negotiationFollowing a plan

“On projects with more than 250 people, methodology will have almost no impact on success or failure – politics will dominate.”

Jim Highsmith


CMM - Capability Maturity Model

Quality management Process measurement and analysis

Initial (1)

Repeatable (2)Software configuration management

Software quality assurance Software subcontract management

Software project tracking and oversight Software project planning

Requirements management

Defined (3) Peer reviews

Intergroup coordination Software product engineering

Integrated software management Training program

Organization process definition Organization process focus

Managed (4)

Process change management Technology change management

Defect prevention

Optimizing (5)

Software quality management Quantitative process management

See details on thismodel on anotherslides collection!

4


CMMI - CMM Integrated

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

AbilityImplementation

Verifyingto Perform

Commitment DirectingImplementation

Specific Goals

Implementation

Specific Practices

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

AbilityImplementation

Verifyingto Perform

Commitment DirectingImplementation

Specific Goals

Implementation

Specific Practices

See details on this model onanother slides collection!


ISO/IEC 15504

Measurement Framework•Capability Levels•Process Attributes•Rating Scale

Process Entities (process areas) +Indicators per Process Entity

ISO15504-5Process

AssessmentModel

ENG.1 CUS.2 ORG.3 .. n

Capability Dimension

Process Dimension

Capability S

cale

543210

See details on thismodel on anotherslides collection!

5


Rational Unified Process (RUP)Some history …

Rational Approach Objectory Process 3.81995

IBM - Rational Unified Process v2003

2003

Rational Objectory Process 4.01996 OMT approach UML 0.5

OOSE

Rational Unified Process 5.01998

Performance TestingBusiness EngineeringData Engineering

Objectory UI DesignChange & Configuration Management

UML 1.2

Rational Objectory Process 4.11997 Requirements

CollegeSQA ProcessUML 1.0


Analysis Model

Specified by

Deployment Model

Distributed by

Design Model

Realized by

Implementation Model

Implemented by

XOK

XOK

XOK

Test Model

Verified by

Use-Case Model

Rational Unified Process (RUP)Model-based development

6


(What)

(Who) (How)

Rational Unified Process (RUP)Who, What, How, When

(When)Workflow


Origins of light-weight methodologies

Project Start

Final Result

Planned Result

7


Origins of light-weight methodologiesAgility

The ability to both create and respond to change in order to profit in a turbulent business environment

Companies need to determine the amount of agility they need to be competitive

Chaordic (ex: agile view)Exhibiting properties of both chaos and order

The blend of chaos and order inherent in the external environment and in people themselves, argues against the prevailing wisdom about predictability and planningThings get done because people adapt, not because they slavishly follow processes

An agile view is a chaordic view


The Agile Manifesto subscribersAlistair CockburnAndrew HuntArie van BennekumBrian MarickDave Thomas James GrenningJeff SutherlandJim Highsmith

Jon Kern Ken SchwaberKent Beck Martin FowlerMike BeedleRobert C. Martin Ron JeffriesSteve MellorWard Cunningham

8


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 documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value on the items on the right,we value the items on the left more.”

[Feb 2001]


Individuals and interactionsover processes and tools

Promote teambuilding and mutual trust

Build projects around motivated individuals

Give team members the environment and support they need, and trust them to get the job done

Adopt a barely sufficient methodology“the conventions we agree to”Processes are described in manuals; practices are what happen in reality

9


Working softwareover comprehensive documentation

Our highest priority is to satisfy the customer through early and frequent delivery of valuable software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter time scale

Working software/product is the primary measure of progress


Customer collaborationover contract negotiation

Set an open tone with the customer(s) organization(s)

Adopt collaborative values and principles

Business people and developers work together daily throughout the project

10


Responding to changeover following a plan

Being agile means accepting that outcomes are not predictable and that processes are not repeatable

Welcome changing requirements, even late in development

Agile processes harness change for the customer’s competitive advantage

Agility is about adaptability rather than predictability

Case Study:Extreme Programming (XP)

11


XP principles and planningBasic principles

Very short cyclesIntense feedbackNetworked communication

Planning practicesUser storiesRelease planningIteration planningOn site customer


XP – Schedule …

12


XP product build philosophyPrinciples

Build the complete product, all the timeOne button builds everything, including

Product executablesInstallation materialsTest harness and test componentsGenerated documentation

BenefitsEasy to manageEasy to add new team membersIntegrates well with testing environment


Agility example: XP

13


XP programming practicesPair programmingTest-first designRefactoringContinuous integrationCollective ownershipCoding standard40 hour week


Pair programmingMethod:

Two programmers sit at one workstationEach programmer take turns “driving”Short lived pairs to avoid “vices”

Benefits:Avoids loosing focus and drifting awayTransmits knowledge to the teamTrains newbies

14


Pair programming research findingsPairs use no more man-hours than singlesPairs create fewer defectsPairs create fewer lines of codePairs enjoy their work more

Source: Laurie Williamshttp://collaboration.csc.ncsu.edu/laurie/



15


Test-first designaka Test-Driven Development (TDD)Principles

All code must have tests, with the test created firstUnit tests are executed during the automated buildWhen a bug is found, new tests are created All unit tests must pass before code can be released

BenefitsProvides constant visibility into areas of the system at riskThe result is rapid progress and a system that always works better than it did the previous versionWe end up with a rich suite of regression tests!


Test first designProgress in tiny (5 min) cycles

Write a test caseWrite the code that passes itRepeat until program does what you want

Use a unit testing frameworke.g. Junit (www.junit.org) uses a green bar sign to mean that the code has passed all tests

16


Example1st step: Write the testspublic void testCreateFuelingStationVisit() {Date date = new Date();double fuel = 2.0; // 2 gallons.double cost = 1.87*2; // Price = $1.87 per gallonint mileage = 1000; // odometer reading.double delta = 0.0001; //fp tolerance

FuelingStationVisit v = new FuelingStationVisit(date, fuel, cost, mileage);

assertEquals(date, v.getDate());assertEquals(1.87*2, v.getCost(), delta);assertEquals(2, v.getFuel(), delta);assertEquals(1000, v.getMileage());assertEquals(1.87, v.getPrice(), delta);

}


public class FuelingStationVisit { public FuelingStationVisit(Date date, double fuel,

double cost, int mileage){itsDate = date;itsFuel = fuel;itsCost = cost;itsMileage = mileage;

}

public Date getDate() {return itsDate;}public double getFuel() {return itsFuel;}public double getCost() {return itsCost;}public double getPrice() {return itsCost/itsFuel;}public int getMileage() {return itsMileage;}

}

3rd step: Run the tests!

Example2nd step: Write the code

17




RefactoringAfter getting something to work we refactor

Refactoring mustprogress incrementally in tiny stepsimprove internal code structure, namely by reducing its complexitynot alter the external behavior of the software components (this is guaranteed by running all the tests

Refactoring techniquesredistribute classes, variables and methods in order to facilitate future adaptations and extensionsremove all duplicationsmake the code as expressive as possible (e.g. forcing naming conventions)make the code as simple as possible

18




Continuous integrationDaily builds are for wimps

Build, end to end, at every check inCheck in frequently

Build and test time must be very fastPut resources on speeding build timePut resources on speeding test time

Wimp: A person who lacks confidence, is irresolute

19




Collective ownershipAnyone can improve any part of the code at any time

No one acts as the gatekeeper for any part of the codeThis includes schemas…and libraries…and everything else that’s different

20




Coding standardGroup of conventions that everyone agrees toEmerges over timeContinuously evolvesThe team rules

21




40 hour weekYou can’t do your best when you are tiredWhen you don’t do your best, you make messesMesses slow everyone downSo you must be restedOccasionally, you may work one week of moderate overtime

22



The dark side of the light ...“XP Considered Harmful ... for Reliable SW Development”

[Gerold Keefer, 2002]

The embrace change value ...The practice of refactoring ...The simplicity value ...The practice of pair programming ...

...

23


Planned (RUP) vs Agile (XP)

Business Modeling

Req. Management

Analysis & Design

Implementation

Test

Deployment

CCM

Project Management

Environment

Coding

Testing

Listening

Designing

RUP XP


Configuration Mgmt

Management

Environment

Business Modeling

Requirements

Analysis and Design

Implementation

Test

Deployment

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Supporting Disciplines

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Elaboration TransitionInception Construction

XP-Window

Planned (RUP) vs Agile (XP)

24


When to be agile?Problems characterized by change, speed, and turbulence are best solved by agility.

Accelerated time schedule combined with significant risk and uncertainty that generate constant change during the project

Is your project more like drilling for oil or like managing a production line?

Oil exploration projects need agile processesProduction-line projects are often well-served by rigorous methodologies


When to be agile?Important questions

How close are the views and values expressed in the Agile Manifesto to:

your customer’s views and values?your project’s views and values?your organization’s views and values?your personal views and values?

If the answer if not positive for all of this questions, then there is a high failure probability for agility

25


References[Acton2002] Agile Software Development, Dottie Acton, Lockheed Martin Mission Systems[Ambler????] Agile Modeling: Effective Practices for Extreme Programming and the Unified

Process, Scott Ambler[Beck2000] Extreme Programming Explained: Embrace Change, Kent Beck, Addison

Wesley[Charette????] Foundations of Lean Development: The Lean Development Manager’s Guide,

Vol 2, Robert Charette[Cockburn2002]Agile Software Development, Alistair Cockburn, Pearson Education, Inc,

Boston, MA[Fowler2000] Refactoring: Improving the Design of Existing Code, Martin Fowler et al.,

Addison-Wesley[Highsmith2000] Adaptive Software Development: a Collaborative Approach to Managing

Complex Systems, Jim Highsmith, Dorset House Publishing, New York[Highsmith2002] Agile Software Development Ecosystems, Jim Highsmith[Jeffries????] Extreme Programming Installed, Ron Jeffries & Ann Anderson, Addison-

Wesley[Kruchten2000] The Rational Unified Process: an Introduction, 2nd Edition, Philippe Kruchten,

Addison-Wesley[McCabe2003] Agile Development, Rich McCabe[Palmer????] A Practical Guide to Feature-Driven Development, Stephen Palmer & John

Felsing[Rising2000] The Scrum Software Development Process for Small Teams, Rising, L. & N.

S. Janoff, IEEE Software[Schwaber2002] Agile Software Development with Scrum, Ken Schwaber & Mike Beedle,

Prentice-Hall

Documents

Heavy vs Light Methodologies: Bulimic or Anorexic? · 2007. 6. 26. · Analysis Model Specified by Deployment Model Distributed by Design Model Realized by Implementation Model Implemented