Agile Methods. Background

Transcription

1 Agile Methods Agile Alliance Background In 2001, a group of lightweight methodologies practioners met to discuss similarities and experiences They wrote the Manifesto for Agile Software Development * Their experience was that software development is mostly an empirical process and not an engineering process ( e.g. assembling an automobile) Domain of Agile methods: For non-safety critical projects Volatile requirements Built by relatively small and skilled collocated teams 6/22/

2 Values of the Agile Manifesto 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan Agile Plan-Driven source: agilemanifesto.org 6/22/ A Perspective on Development Approaches 6/22/2008 Kroll, P.; Kruchten, P.; The Rational Unified Process Made Easy 4 A Practionner s Guide to the RUP.; Addison-Wesley, 2003, ISBN

3 Typical Agile Processes extreme Programming (XP) SCRUM Dynamic System Development Method (DSDM) Feature-Driven Development (FDD) RUP claims it can be tailored as an agile method 6/22/ extreme Programming (XP) Elements 1. Planning game: Quickly determine the next release s scope, combining business priorities and technical estimates. The customer decides scope, priority, and dates from a business perspective, whereas technical people estimate and track progress. 2. Small releases: Put a simple system into production quickly. Release new versions on a very short (two-week) cycle. 3. Metaphor: Guide all development with a simple, shared story of how the overall system works. 4. Simple design: Design as simply as possible at any given moment. 5. Testing: Developers continually write unit tests that must run flawlessly; customers write tests to demonstrate that functions are finished. Test, then code means that a failed test case is an entry criterion for writing code. 6. Refactoring: Restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. 6/22/

4 extreme Programming (XP) Elements 7. Pair programming: All production code is written by two programmers at one machine. 8. Collective ownership: Anyone can improve any system code anywhere at any time. 9. Continuous integration: Integrate and build the system many times a day (every time a task is finished). Continual regression testing prevents functionality regressions when requirements change.. 40-hour weeks: Work no more than 40 hours per week whenever possible; never work overtime two weeks in a row. 11. On-site customer: Have an actual user on the team full-time to answer questions. 12. Coding standards: Have rules that emphasize communication throughout the code. 6/22/ extreme Programming (XP) Elements XP and SQA Addressed by the pair-programming culture Peer pressure helps comply to process and product assurance Larger team require more formal mechanisms for objectively verifying adherence to procedures and standards Might be ineffective when team is subjected to pressure No management visibility into nonconformance issues 6/22/

5 6/22/ Balancing Agility & Discipline 6/22/2008 5

6 Balancing Agility & Discipline Personnel (% Level 1B) (% Level 2&3) Criticality (Loss due to impact of defects) Dynamism (% Requirements change/month Many 0 Lives Single Life Essential Funds Discretionary Funds Comfort Size (# of personnel) Culture (% thriving on chaos vs. order) 6/22/ Agile Plan-driven Agile Plan-driven Two Project examples Lease Management CCPDS-R 6/22/

7 Boehm-Turner Risk-driven Approach Step 1. Risk Analysis Rate the project s environmental, agilityoriented and plan-driven risks. Uncertain about ratings? Yes Buy information via prototyping, data collection and analysis Note: Feedback loops present, but omitted for simplicity No Step 2. Risk Comparison Step 3. Architecture Analysis Compare the agile and Plandriven risks Architect application to encapsulate agile parts Step 5. Execute and Monitor Plan-driven risks dominate Neither dominate Deliver incremental capabilities according to strategy Monitor progress and risks/opportunities, readjust balance and process as appropriate Agility risks dominate Go Risk-based Agile Go Risk-based Plan-driven Go Risk-based Agile in agile parts; Go Riskbased Plandriven elsewhere Tailor life cycle process around anchor point commitment milestones Step 4. Tailor Life Cycle 6/22/ Characteristics Application Primary Goals Size Environment Management Customer Relations Planning/Control Communications Technical Requirements Development Test Personnel Customers Developers Balancing Agility & Discipline Agile Rapid value; responding to change Smaller teams and projects Turbulent; high change; project-focused Dedicated on-site customers; focused on prioritized increments Internalized plans; qualitative control Tacit interpersonal knowledge Prioritized informal stories and test cases; undergoing unforseeable change Simple design; short increment; refactoring assumed inexpensive Executable test cases define requirements, testing Dedicated, collocated CRACK* performers At least % full-time Cockburn level 2 and 3 experts; no Level 1B or -1 personnel** Disciplined Predictability, stability, high assurance Larger teams and projects Stable; low-change; project/organization focused As-needed customer interactions; focused on contract provisions Documented plans, quantitative control Explicit documented knowledge Formalized project, capability, interface, quality, forseeable evolution requirements Extensive design; longer increments; refactoring assumed expensive Documented test plans and procedures CRACK* performers, not always collocated 50% Cockburn Level 3s early; % throughout; % Level 0 s workable; no Level -1s** Culture Comfort and empowerment via many degrees of Comfort and empowerment via framework of policies and freedom (thriving on chaos) procedures (thriving on order) 6/22/ * Collaborative, Representative, Authorized, Committed, Knowledgeable ** These numbers will particularly vary with the complexity of the application 7