Heavy vs Light Methodologies: Bulimic or Anorexic? Fernando Brito e Abreu Universidade Nova de Lisboa (

Transcription

1 Heavy vs Light Methodologies: Bulimic or Anorexic? Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa ( QUASAR Research Group ( Abstract Anorexia versus Bulimia Overview of heavy-weight methodologies Origins of light-weight methodologies The Agile Manifesto Agility example: XP The dark side of the light Planned (RUP) vs Agile (XP) When to be agile? Fernando Brito e Abreu 2 1

2 Anorexia versus Bulimia Anorexic (thin) project / Light-weight / Agile Project run unconstrained Total freedom for artists Unpredictable deliverables Bulimic (fat) project / Heavy-weight / Planned Highly constrained project e.g. following DoD Mil. Std 2167A High organizing overheads Very well defined deliverables Fernando Brito e Abreu 3 Examples Plan-driven methodologies Heavy-weight methodologies CMM, ISO9000-3, ISO12207, PSP, TSP, ISO15504 (SPICE), RUP, CMMi, Fat? Bulimic? Agile software development Light-weight methodologies Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Adaptive Software Process, Crystal Light Methodologies, Dynamic Systems Development Method (DSDM), Lean Development Thin? Anorexic? Fernando Brito e Abreu 4 2

3 Overview of heavy-weight methodologies Processes and tools Comprehensive documentation Contract negotiation Following a plan On projects with more than 250 people, methodology will have almost no impact on success or failure politics will dominate. Jim Highsmith Fernando Brito e Abreu 5 CMM - Capability Maturity Model See details on this model on another slides collection! Optimizing (5) Process change management Technology change management Defect prevention Managed (4) Software Quality management quality management Quantitative Process measurement process management and analysis Initial (1) Defined (3) Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Repeatable (2) Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Fernando Brito e Abreu 6 3

4 CMMI - CMM Integrated Maturity Levels See details on this model on another slides collection! Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Common Features Commitment to Perform Ability to Perform Directing Implementation Verifying Implementation Specific Practices Generic Practices Fernando Brito e Abreu 7 ISO/IEC See details on this model on another slides collection! Measurement Framework Capability Levels Process Attributes Rating Scale Capability Dimension Capability Scale ISO Process Assessment Model Process Dimension ENG.1 CUS.2 ORG.3.. n Process Entities (process areas) + Indicators per Process Entity Fernando Brito e Abreu 8 4

5 Rational Unified Process (RUP) Some history Performance Testing Business Engineering Data Engineering 1997 Requirements College 1996 OMT approach IBM - Rational Unified Process v2003 Rational Unified Process 5.0 Rational Objectory Process 4.1 Rational Objectory Process 4.0 UML 1.2 Objectory UI Design Change & Configuration Management SQA Process UML 1.0 UML 0.5 OOSE 1995 Rational Approach Objectory Process 3.8 Fernando Brito e Abreu 9 Rational Unified Process (RUP) Model-based development Use-Case Model Specified by Realized by Analysis Model Distributed by Design Model Implemented by Deployment Model Implementation Model X OK Verified by X OK X OK Test Model Fernando Brito e Abreu 10 5

6 Rational Unified Process (RUP) Who, What, How, When Workflow (When) (Who) (How) (What) Fernando Brito e Abreu 11 Origins of light-weight methodologies Project Start Planned Result Final Result Fernando Brito e Abreu 12 6

7 Origins of light-weight methodologies Agility 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 planning Things get done because people adapt, not because they slavishly follow processes An agile view is a chaordic view Fernando Brito e Abreu 13 The Agile Manifesto subscribers Alistair Cockburn Andrew Hunt Arie van Bennekum Brian Marick Dave Thomas James Grenning Jeff Sutherland Jim Highsmith Jon Kern Ken Schwaber Kent Beck Martin Fowler Mike Beedle Robert C. Martin Ron Jeffries Steve Mellor Ward Cunningham Fernando Brito e Abreu 14 7

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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding 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] Fernando Brito e Abreu 15 Individuals and interactions over 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 Fernando Brito e Abreu 16 8

9 Working software over 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 Fernando Brito e Abreu 17 Customer collaboration over 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 Fernando Brito e Abreu 18 9

10 Responding to change over 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 Fernando Brito e Abreu 19 Case Study: Extreme Programming (XP) 10

11 XP principles and planning Basic principles Very short cycles Intense feedback Networked communication Planning practices User stories Release planning Iteration planning On site customer Fernando Brito e Abreu 21 XP Schedule Fernando Brito e Abreu 22 11

12 XP product build philosophy Principles Build the complete product, all the time One button builds everything, including Product executables Installation materials Test harness and test components Generated documentation Benefits Easy to manage Easy to add new team members Integrates well with testing environment Fernando Brito e Abreu 23 Agility example: XP Fernando Brito e Abreu 24 12

13 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 25 Pair programming Method: Two programmers sit at one workstation Each programmer take turns driving Short lived pairs to avoid vices Benefits: Avoids loosing focus and drifting away Transmits knowledge to the team Trains newbies Fernando Brito e Abreu 26 13

14 Pair programming research findings Pairs use no more man-hours than singles Pairs create fewer defects Pairs create fewer lines of code Pairs enjoy their work more Source: Laurie Williams Fernando Brito e Abreu 27 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 28 14

15 Test-first design aka Test-Driven Development (TDD) Principles All code must have tests, with the test created first Unit tests are executed during the automated build When a bug is found, new tests are created All unit tests must pass before code can be released Benefits Provides constant visibility into areas of the system at risk The result is rapid progress and a system that always works better than it did the previous version We end up with a rich suite of regression tests! Fernando Brito e Abreu 29 Test first design Progress in tiny (5 min) cycles Write a test case Write the code that passes it Repeat until program does what you want Use a unit testing framework e.g. Junit ( uses a green bar sign to mean that the code has passed all tests Fernando Brito e Abreu 30 15

16 Example 1st step: Write the tests public void testcreatefuelingstationvisit() { Date date = new Date(); double fuel = 2.0; // 2 gallons. double cost = 1.87*2; // Price = $1.87 per gallon int mileage = 1000; // odometer reading. double delta = ; //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); Fernando Brito e Abreu 31 Example 2nd step: Write the code public class FuelingStationVisit { public FuelingStationVisit(Date date, double fuel, double cost, int mileage) { itsdate = date; 3rd step: Run the tests! 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;} Fernando Brito e Abreu 32 16

17 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 33 Refactoring After getting something to work we refactor Refactoring must progress incrementally in tiny steps improve internal code structure, namely by reducing its complexity not alter the external behavior of the software components (this is guaranteed by running all the tests Refactoring techniques redistribute classes, variables and methods in order to facilitate future adaptations and extensions remove all duplications make the code as expressive as possible (e.g. forcing naming conventions) make the code as simple as possible Fernando Brito e Abreu 34 17

18 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 35 Continuous integration Daily builds are for wimps Build, end to end, at every check in Check in frequently Build and test time must be very fast Put resources on speeding build time Put resources on speeding test time Wimp: A person who lacks confidence, is irresolute Fernando Brito e Abreu 36 18

19 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 37 Collective ownership Anyone can improve any part of the code at any time No one acts as the gatekeeper for any part of the code This includes schemas and libraries and everything else that s different Fernando Brito e Abreu 38 19

20 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu 39 Coding standard Group of conventions that everyone agrees to Emerges over time Continuously evolves The team rules Fernando Brito e Abreu 40 20

21 XP programming practices Pair programming Test-first design Refactoring Continuous integration Collective ownership Coding standard 40 hour week Fernando Brito e Abreu hour week You can t do your best when you are tired When you don t do your best, you make messes Messes slow everyone down So you must be rested Occasionally, you may work one week of moderate overtime Fernando Brito e Abreu 42 21

22 Fernando Brito e Abreu 43 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 Fernando Brito e Abreu 44 22

23 Planned (RUP) vs Agile (XP) RUP XP Business Modeling Req. Management Analysis & Design Implementation Test Deployment CCM Project Management Environment Coding Testing Listening Designing Fernando Brito e Abreu 45 Planned (RUP) vs Agile (XP) Process Disciplines Business Modeling Requirements Analysis and Design Implementation Test Deployment Supporting Disciplines Configuration Mgmt Management Environment Phases Inception Elaboration Construction Preliminary Iteration(s) Iter. #1 Iter. #2 XP-Window Iter. #n Iter. #n+1 Iterations Iter. #n+2 Transition Iter. #m Iter. #m+1 Fernando Brito e Abreu 46 23

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 processes Production-line projects are often well-served by rigorous methodologies Fernando Brito e Abreu 47 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 Fernando Brito e Abreu 48 24

25 References [Acton2002] [Ambler????] [Beck2000] Agile Software Development, Dottie Acton, Lockheed Martin Mission Systems Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler 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 Fernando Brito e Abreu 49 25