16
Heavy Heavy vs vs Light Methodologies: Light Methodologies: Bulimic or Anorexic? Bulimic or Anorexic? Fernando Brito e Abreu Fernando Brito e Abreu FCT/UNL FCT/UNL ISCTE, 15 April 2005 2 Abstract Abstract From anorexic to bulimic From anorexic to bulimic Overview of heavy Overview of heavy - - weight methodologies weight methodologies Origins of light Origins of light - - weight methodologies weight methodologies  The The Manifesto Manifesto ¡ Agility example: XP Agility example: XP ¡ The dark side of the light The dark side of the light ¢ Planned (RUP) Planned (RUP) vs vs Agile (XP) Agile (XP) £ When to be agile? When to be agile?

Heavy vsLight Methodologies: Bulimic or Anorexic?home.iscte-iul.pt/~mms/events/agile_seminar/apresentacoes/fernando... · Heavy vsLight Methodologies: Bulimic or Anorexic? Fernando

Embed Size (px)

Citation preview

1

Heavy Heavy vsvs Light Methodologies:Light Methodologies:Bulimic or Anorexic?Bulimic or Anorexic?Fernando Brito e AbreuFernando Brito e Abreu

FCT/UNLFCT/UNL

ISCTE, 15 April 2005

2

AbstractAbstract

From anorexic to bulimicFrom anorexic to bulimicOverview of heavyOverview of heavy--weight methodologiesweight methodologiesOrigins of lightOrigins of light--weight methodologiesweight methodologiesThe The ““ManifestoManifesto””Agility example: XPAgility example: XPThe dark side of the light The dark side of the light Planned (RUP) Planned (RUP) vsvs Agile (XP)Agile (XP)When to be agile?When to be agile?

2

3

Some hype Some hype ……

Thin? Anorexic?Thin? Anorexic?Fat? Bulimic?Fat? Bulimic?

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

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

LightLight--weight methodologiesweight methodologiesHeavyHeavy--weight weight methodologiesmethodologies

Agile software developmentAgile software developmentPlanPlan--driven driven methodologiesmethodologies

4

From anorexic to bulimicFrom anorexic to bulimic"If you don't know where you are going, every road will take you there..."

Alice in Wonderland

•• Many projects run unconstrainedMany projects run unconstrained–– Total freedom for artists Total freedom for artists ☺☺

–– Unpredictable results Unpredictable results

•• DoDDoD Mil. Std 2167AMil. Std 2167A–– Highly constrained, high organizing overheads Highly constrained, high organizing overheads

–– Very well defined deliverables Very well defined deliverables ☺☺

3

5

Overview of heavyOverview of heavy--weight weight methodologiesmethodologies

•• Processes and toolsProcesses and tools

•• Comprehensive Comprehensive documentationdocumentation

•• Contract negotiationContract negotiation

•• Following a planFollowing a plan

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

Jim Highsmith

6

CMM CMM -- Capability Maturity ModelCapability Maturity Model

ProgressProgress

Initial (1)

Repeatable (2)

Defined (3)

Managed (4)

Optimising (5)

Disciplined process

Standard, consistent process

Predictable process

Continuously improving process

4

7

CMM CMM -- Capability Maturity ModelCapability 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

8

Process AdvisorProcess Advisor((RogerRoger PressmanPressman & & AssociatesAssociates))

5

9

ISO 15504ISO 15504

• SPICE - Software Process Improvement and Capability dEtermination

• Initiative of WG10 (Process Assessment) - ISO/IEC JTC1/SC7 (Software Engineering)

• OBJECTIVES:– Unify software process assessment efforts

– Elaboration of a set of international standards

10

ISO 15504ISO 15504Organizations involvedOrganizations involved

Defense Research Agency, UK

European Software Institute

Software Engineering Institute

Etnoteam, Italy

University of Oulu, Finland

Bellcore, EUA

… and other organizations from Japan, South Africa, France, Ireland, Spain, ...

Australian Software Quality Research Institute

Bell Canada

Northern Telecom

Bell Northern Research (BNR)

BOOTSTRAP Consortium

British Telecommunications Plc.

Centre de Recherched'Informatique de Montréal

6

11

ISO 15504ISO 15504

Considers 5 Generic Process CategoriesConsiders 5 Generic Process Categories::•• CUSCUS -- customercustomer--supplier process categorysupplier process category

•• ENGENG -- engineering process categoryengineering process category

•• PROPRO -- project management process categoryproject management process category

•• SUPSUP -- support process categorysupport process category

•• ORGORG -- organization process categoryorganization process category

12

Capability Maturity Model Integrated Capability Maturity Model Integrated (CMMI(CMMI®®))•• Is an integrated model to propel process Is an integrated model to propel process

improvements in systems engineering and improvements in systems engineering and software engineering.software engineering.

•• The model encompasses:The model encompasses:

–– 5 maturity levels5 maturity levels

–– 25 Process Areas (25 Process Areas (PAsPAs))

–– Several flavors (SE/SW/IPPD/SS)Several flavors (SE/SW/IPPD/SS)

7

13

Capability Maturity Model Integrated Capability Maturity Model Integrated (CMMI(CMMI®®))

•• Level 2 Level 2 -- Requirements Management, Project Monitoring and Control, Requirements Management, Project Monitoring and Control, Project Planning, Supplier Agreement Management, Configuration Project Planning, Supplier Agreement Management, Configuration Management, Process & Product QA, Measurement & Analysis Management, Process & Product QA, Measurement & Analysis

•• Level 3 Level 3 -- Requirements Development, Technical Solution, Product Requirements Development, Technical Solution, Product Integration, Organizational Training, Verification Validation, RIntegration, Organizational Training, Verification Validation, Risk isk Management, Decision Analysis & Resolution, Integrated Project Management, Decision Analysis & Resolution, Integrated Project Management, Organizational Process Focus, Organizational ProcessManagement, Organizational Process Focus, Organizational ProcessDefinition Definition

•• Level 4 Level 4 -- Quantitative Project Management, Organizational Process Quantitative Project Management, Organizational Process Performance Performance

•• Level 5 Level 5 -- Organizational Innovation & Deployment, Causal Analysis & Organizational Innovation & Deployment, Causal Analysis & Resolution Resolution

•• Additional Requirements of IPPD Additional Requirements of IPPD -- Changes to Integrated Project Changes to Integrated Project Management, Integrated Teaming and Organizational Environment foManagement, Integrated Teaming and Organizational Environment for r Integration Integration

•• Additional Requirements of SS Additional Requirements of SS -- Integrated Supplier ManagementIntegrated Supplier Management

14

Rational Unified Process (RUP)Rational Unified Process (RUP)

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

8

15

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)Rational Unified Process (RUP)

16

Rational Unified Process (RUP)Rational Unified Process (RUP)

(When)Workflow

(What)

(Who) (How)

9

17

Origins of lightOrigins of light--weight weight methodologiesmethodologies

Project Start

Final Result

Planned Result

18

Origins of lightOrigins of light--weight weight methodologiesmethodologies•• AgilityAgility

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

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

•• ChaordicChaordic (ex: agile view)(ex: agile view)–– Exhibiting properties of both Exhibiting properties of both chachaos and os and ordorderer

•• The blend of chaos and order inherent in the external The blend of chaos and order inherent in the external environment and in people themselves, argues against the environment and in people themselves, argues against the prevailing wisdom about predictability and planningprevailing wisdom about predictability and planning

•• Things get done because people adapt, not because they Things get done because people adapt, not because they slavishly follow processesslavishly follow processes

–– An agile view is a An agile view is a chaordicchaordic viewview

10

19

The Agile Manifesto SubscribersThe Agile Manifesto SubscribersAlistair CockburnAlistair Cockburn

Andrew HuntAndrew Hunt

ArieArie van van BennekumBennekum

Brian Brian MarickMarick

Dave Thomas Dave Thomas

James James GrenningGrenning

Jeff SutherlandJeff Sutherland

Jim Jim HighsmithHighsmith

Jon Kern Jon Kern

Ken Ken SchwaberSchwaber

Kent Beck Kent Beck

Martin FowlerMartin Fowler

Mike Mike BeedleBeedle

Robert C. Martin Robert C. Martin

Ron JeffriesRon Jeffries

Steve MellorSteve Mellor

Ward CunninghamWard Cunningham

20

The Agile Manifesto The Agile Manifesto [Feb 2001][Feb 2001]

““We are uncovering better ways of developing software We are uncovering better ways of developing software by doing it and helping others do it.by doing it and helping others do it.

Through this work we have come to value:Through this work we have come to value:–– Individuals and interactionsIndividuals and interactions over processes and toolsover processes and tools

–– Working Working swsw over comprehensive documentationover comprehensive documentation

–– Customer collaborationCustomer collaboration over contract negotiationover contract negotiation

–– Responding to changeResponding to change over following a planover following a plan

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

11

21

Agile Management IssuesAgile Management Issues

•• Promote teambuilding and trustPromote teambuilding and trust

•• Set an open tone with the customer(s) Set an open tone with the customer(s) organizationsorganizations

•• Interpret and translate risks for overall Interpret and translate risks for overall program integration and a common viewprogram integration and a common view

•• Have a robust, flexible, and adaptable Have a robust, flexible, and adaptable configuration and data management systemconfiguration and data management system

22

Summary of Agile CharacteristicsSummary of Agile Characteristics

•• Adaptability rather than predictabilityAdaptability rather than predictability

•• People rather than development processPeople rather than development process–– Being agile means accepting that outcomes are not Being agile means accepting that outcomes are not

predictable and that processes are not repeatablepredictable and that processes are not repeatable

•• Collaborative values and principlesCollaborative values and principles

•• A barely sufficient methodologyA barely sufficient methodology–– ““the conventions we agree tothe conventions we agree to””–– Processes are described in manuals; practices are Processes are described in manuals; practices are

what happen in realitywhat happen in reality

12

23

Agility example: XPAgility example: XP

24

•• The Planning GameThe Planning Game

•• Small ReleasesSmall Releases

•• System MetaphorSystem Metaphor

•• Simple DesignSimple Design

•• TestingTesting

•• RefactoringRefactoring

•• Pair ProgrammingPair Programming

•• Collective OwnershipCollective Ownership

•• Continuous IntegrationContinuous Integration

•• 4040--hour weekhour week

•• OnOn--sitesite--CustomerCustomer

•• Coding StandardsCoding Standards

XP XP –– PracticesPractices

13

25

XP XP –– Schedule Schedule ……

26

The dark side of the light ...The dark side of the light ...

““XP Considered Harmful ... for Reliable SW DevelopmentXP Considered Harmful ... for Reliable SW Development””

[[GeroldGerold Keefer, 2002]Keefer, 2002]

••The embrace change value ...The embrace change value ...

••The practice of refactoring ...The practice of refactoring ...

••The simplicity value ...The simplicity value ...

••The practice of pair programming ...The practice of pair programming ......

14

27

Planned (RUP) Planned (RUP) vsvs Agile (XP)Agile (XP)

Business Modeling

Req. Management

Analysis & Design

Implementation

Test

Deployment

CCM

Project Management

Environment

Coding

Testing

Listening

Designing

RUPRUP XPXP

28

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) Planned (RUP) vsvs Agile (XP)Agile (XP)

15

29

When to be agile?When to be agile?

•• Problems characterized by change, speed, and Problems characterized by change, speed, and turbulence are best solved by agility.turbulence are best solved by agility.–– Accelerated time schedule combined with Accelerated time schedule combined with

significant risk and uncertainty that generate significant risk and uncertainty that generate constant change during the project.constant change during the project.

•• Is your project more like drilling for oil or like Is your project more like drilling for oil or like managing a production line?managing a production line?–– Oil exploration projects need Agile processes.Oil exploration projects need Agile processes.

–– ProductionProduction--line projects are often wellline projects are often well--served by served by rigorous methodologies.rigorous methodologies.

30

ThatThat’’s s allall folksfolks ☺☺Fernando Brito e AbreuFernando Brito e Abreu

[email protected]@di.fct.unl.pt

http://http://ctp.di.fct.unl.ptctp.di.fct.unl.pt/QUASAR/QUASAR

•• QuestionsQuestions??

16

31

ReferencesReferencesAgile Software Development Ecosystems, Agile Software Development Ecosystems, Jim Jim HighsmithHighsmith

Agile Software Development, Alistair Agile Software Development, Alistair Cockburn, PCockburn, Pearsonearson Education, Inc, Boston, Education, Inc, Boston, MA, 2002MA, 2002

Agile Modeling: Effective Practices for Agile Modeling: Effective Practices for Extreme Programming and the Unified Extreme Programming and the Unified Process, Scott AmblerProcess, Scott Ambler

Agile Development, Rich McCabe, May 2003Agile Development, Rich McCabe, May 2003

Agile Software Development with Scrum, Agile Software Development with Scrum, Ken Ken SchwaberSchwaber and Mike and Mike BeedleBeedle, Prentice, Prentice--Hall, Inc., 2002Hall, Inc., 2002

Extreme Programming Explained: Embrace Extreme Programming Explained: Embrace Change, Kent BeckChange, Kent Beck

Refactoring: Improving the Design of Refactoring: Improving the Design of Existing Code, Martin FowlerExisting Code, Martin Fowler

Adaptive Software Development, A Adaptive Software Development, A Collaborative Approach to Managing Collaborative Approach to Managing Complex Systems, Jim Complex Systems, Jim HighsmithHighsmith, , Dorset Dorset House Publishing, New York, 2000.House Publishing, New York, 2000.

A Practical Guide to FeatureA Practical Guide to Feature--Driven Driven Development, Stephen Palmer and John Development, Stephen Palmer and John FelsingFelsing

Rising, L. and N. S. Rising, L. and N. S. JanoffJanoff (2000). The (2000). The Scrum Software Development Process for Scrum Software Development Process for Small Teams. IEEE Software. July/August Small Teams. IEEE Software. July/August 2000 2000

Foundations of Lean Development: The Foundations of Lean Development: The Lean Development ManagerLean Development Manager’’s Guide, s Guide, VolVol 2, 2, Robert Robert CharetteCharette

Extreme Extreme ProgrammingProgramming ExplainedExplained, Kent , Kent Beck, Beck, AddisonAddison Wesley, 2000Wesley, 2000

TheThe Rational Rational UnifiedUnified ProcessProcess, An , An IntroductionIntroduction, Second Edition, Philippe , Second Edition, Philippe KruchtenKruchten, , AddisonAddison--WesleyWesley, 2000, 2000

Refactoring: Refactoring: ImprovingImproving thethe Design of Design of ExistingExisting Code, Martin Fowler et al., Code, Martin Fowler et al., AddisonAddison--WesleyWesley, 2000, 2000

Extreme Extreme ProgrammingProgramming InstalledInstalled, Ron , Ron Jeffries, Ann Anderson, Jeffries, Ann Anderson, AddisonAddison--WesleyWesley