We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byXavier Bowes
Modified over 2 years ago
Alistair Cockburn©Humans and Technology, Inc., Slide 1 Agile Use Cases ( Writing Effective Use Cases meets Agile Software Development ! ) Alistair Cockburn Humans and Technology
Alistair Cockburn©Humans and Technology, Inc., Slide 2 Can use cases be agile?Yes (Can you be agile with use cases?)Yes Do use cases contradict Agile ? :Use cases / not use cases / value of use cases vs stories :Agile / not agile / value of agile When should we use agile use cases ? :document faster, later, cheaper, :plan on changing your mind along the way, :always. Detecting and exercising available dimensions of freedom :Write less, more clearly (tips). :Shortcut process & use case structure... (tips, tradeoffs) :Tools Q&A
Alistair Cockburn©Humans and Technology, Inc., Slide 3 Coming from agile non-use-cases to agile UCs is easier than coming from non-agile UCs Overly complex use case writing is hard to change, tied to overly complex process (hard to change!) Already understanding Agile means :already have a lighter process :already have mindset to simplify the writing :--> leads to agile use case writing. Need to understand :(A) Simple use cases :(B) Agility as energy savings
Alistair Cockburn©Humans and Technology, Inc., Slide 4 Part 1: What is / isn’t a use case (good for)
Alistair Cockburn©Humans and Technology, Inc., Slide 5 Good use cases arearen’t Text No GUI No data formats steps in main scenario Easy to read At user’s goal level Record of decisions made UML use case diagrams describing the GUI describing data formats multiple-page main scenario complicated to read at program-feature level tutorial on the domain Use cases *can be* written -- all up front--or--just-in-time each to completion--or--in (usable) increments
Alistair Cockburn©Humans and Technology, Inc., Slide 6 Use case: Text describing scenarios of user succeeding or failing to achieve goal. “Place an order” (User goal / Clerk) Main scenario: 1. Clerk identifies customer, item and quantity. 2. System accepts and queues the order. Extensions: 1a. Low credit & Customer is ‘Preferred’: System gives them credit anyway. 1b. Low credit & not ‘Preferred’ customer: Clerk accepts only prepayment. 2a. Low on stock: Customer accepts rain-check: Clerk reduces order to available stock level. (goal of primary actory) (level of goal [summary, user, subfunction]) (action steps: full sentences showing who takes the action! steps long.) (condition causing different actions) (action step(s) handling those conditions) (primary actor) Robert Martin: “It shouldn’t take longer than 15 minutes to teach someone how to write a use case!”
Alistair Cockburn©Humans and Technology, Inc., Slide 7 Good use cases arearen’t Text No GUI No data formats steps in main scenario Easy to read At user’s goal level Record of decisions made UML use case diagrams describing the GUI describing data formats multiple-page main scenario complicated to read at program-feature level tutorial on the domain Use cases *can be* written -- just-in-time --or--all up front in (usable) increments --or-- each to completion (more Agile) (more common)
Alistair Cockburn©Humans and Technology, Inc., Slide 8 Use cases summarize end-user experience, not programmers tasks. 1980’s: Let’s write requirements in features! :User’s don’t understand......user pressure to write in use cases ’s: Let’s write requirements in use cases! :Programmers’ work units are features, not use cases......programmer pressure to write in features : So let’s write requirements in features! :FDD & XP user stories......lose the end user experience again... A pendulum of features vs. use cases
Alistair Cockburn©Humans and Technology, Inc., Slide 9 1. Use cases hold functional requirements in an easy-to- read text format 2. They make a good framework for non-functional requirements & project scheduling. 3. Use cases show only the Functional req’ts. 4. Design is not done only in use case units. Use cases have strong & weak points (as anything)
Alistair Cockburn©Humans and Technology, Inc., Slide 10 Use cases do not collect formulae, state, cardinality, performance, uptime,... Examples: 1. Order cost = order item costs * 1.06 tax 2. Promotions may not run longer than 6 months. 3. Customers only become Preferred after 1 year. 4. A customer has one and only one sales contact. 5. Response time is less than 2 seconds. 6. Uptime requirement is 99.8%. 7. Number of simultaneous users will be 200 max. Capture those in any form available, *somewhere* in your requirements files !
Alistair Cockburn©Humans and Technology, Inc., Slide 11 Goals make a good structure on which to hang requirements & project details. Project planning capitalizes on goal structure: :Useable Releases. :Priorities, :Schedule, staffing NameP. ActorPr.Diff. Release Update customerCustomerhighmed1 Scan productsCustomerhighhigh1 Generate invoiceFinancehighhigh3 Funds transferFinancemedhigh4 (Note: spreadsheets are perfect for this!)
Alistair Cockburn©Humans and Technology, Inc., Slide 12 Use cases provide 4 values to the project at different times: 1. The list of goal names provides executives: :Shortest summary of what system will contribute :Project planning skeleton (priorities & timing) 2. The main success scenario provides all: :Agreement as to the system’s responsibilities 3. The extension conditions provide programmers: :List of things programmers have to watch for :List of things analysts have to investigate 4. The extension handling steps provide dev’t team: :Record of (tricky) business policy decisions
Alistair Cockburn©Humans and Technology, Inc., Slide 13 The hard parts about use cases is not typing, but thinking and agreeing. Total time :~ 3 days construction :~ 2 hours typing :2- 3/4 days spent thinking, arguing (over policy). 1. Is each step correct? 2. Are there any system responsibilities between steps? 3. Are there any outside systems this system should use? 4. Are there any other stakeholders whose interests we missed? 5. Did we catch every extension condition? (The programmers will (maybe))
Alistair Cockburn©Humans and Technology, Inc., Slide 14 Don’t try to teach a tutorial on the subject domain within the use cases! In any text, receiver must always jump a gap. :Experts jump larger gaps :Novices jump smaller gaps. To teach a domain, you need a textbook, not use cases. :Textbooks use smaller gaps. :Think of use cases as “documenting decisions”, not “teaching the domain.” Target the gap for the people: “sufficient” communication with a “small-enough”gap. :More experienced people need less writing !
Alistair Cockburn©Humans and Technology, Inc., Slide 15 Part 2: What is / isn’t agile development (good for)
Alistair Cockburn©Humans and Technology, Inc., Slide 16 History: How did “agile” arise? “Agile” techniques were in use since the beginning. Agile (mobility-based) techniques did not show competitive advantage in the 1970s / 1980s, but did during the 1990s and do now. 1994: trials of semi-formal agile methodologies RADDSDM XP Crystal Scrum Adaptive (3-1/2)
Alistair Cockburn©Humans and Technology, Inc., Slide 17 Development approaches are only attitudes, “centering of the attention”. Declarations of core values declare an “attitude” An attitude cannot promise success in the future, it can only be spoken successfully in the past tense. it is only a wish to be a certain way A would-be agile process A would-be predictable process A would-be repeatable process A would-be inexpensive process (4-1/2)
Alistair Cockburn©Humans and Technology, Inc., Slide Agile Software Development Manifesto - a declaration of values “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 in the items on the right, we value the items on the left more.” (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas )
Alistair Cockburn©Humans and Technology, Inc., Slide 19 Agile development works because software development is an economic game Economic consequences to each choice. :Less is usually better... “sufficient” is enough. (Project success factors reviewed:) Nourishment Skills Citizenship Communication Focus Increments (Agility resides Here!) (Includes developers AND users!)
Alistair Cockburn©Humans and Technology, Inc., Slide 20 Agile = shortcutting the process (cheating legally to win) Scope TimeResources Process (Some people use agile to handle late-breaking requirements changes, I use it to improve development efficiency) Scope TimeResources The “iron triangle” isn’t a triangle at all -- “Process” is the 4th dimension !
Alistair Cockburn©Humans and Technology, Inc., Slide 21 Agile development: short circuiting process steps without compromising final product. Focus on *early* & *frequent* delivery of *useful* software to real users using *just-in-time* techniques. Focus on *feedback* loops at all levels :(requirements design code test communication... ) Replace fanfare around the process with people checking in with other people. *Talk* to users / sponsors, find out what they need! Adjust your working habits *monthly or quarterly* to fit your particular situation!
Alistair Cockburn©Humans and Technology, Inc., Slide 22 The Agile attitude focuses on: 1. Talent & Skill(fewer better people) 2. Proximity(developers - developers - users) 3. Communication (morale, daily standup) 4. Just-in-time requirements and design 5. Frequent Delivery(incremental development) 6. Reflection 7. Less paper, more tacit / verbal communication 8. Tools 9. Quality in work 10. Different strategies for different projects
Alistair Cockburn©Humans and Technology, Inc., Slide 23 Agility *can* Be heavier or lighter, depending on circumstances Use various requirements techniques (e.g., use cases, stories, features) In agile development we value following the principles over following specific practices ! Good agile development is / doesisn’t / doesn’t Efficient Lots of “just in time” Adjust to circumstances (Re)Plan regularly Lots of person-to-person comm. Adaptively cut fat in the process hacking Giant Energy Up Front (GEUF) only XP (XP is one alternate) plan-less People sitting in isolation rigid adherence
Alistair Cockburn©Humans and Technology, Inc., Slide 24 Is / Isn’t: Misconstruing the message 1. Agile SD is cheating 2. Agile SD requires the best developers 3. Agile SD is hacking 4. Agile SD won’t work for all projects
Alistair Cockburn©Humans and Technology, Inc., Slide Agile techniques are “cheating”. ·Hire good people; ·Seat them close together to help each other out; ·Get them close to the customers and users; ·Arrange for rapid feedback on decisions; ·Let them find fast ways to document their work; ·Cut out the bureaucracy. This is: cheating stacking the deck a good idea the heart of agile software development
Alistair Cockburn©Humans and Technology, Inc., Slide Agile only works with the best developers. Every project needs at least one experienced and competent lead person. (Critical Success Factor) Each experienced and competent person on the team permits the presence of 4-5 “average” or learning people. With that skill mix, agile techniques have been shown to work many times.
Alistair Cockburn©Humans and Technology, Inc., Slide Agile is hacking. (Hacker interpretations are inevitable.) Hackers: “...spend all their time coding” Agilists:...test according to project priorities, recheck results with users often. Hackers: “...talk to each other when they are stuck” Agilists:...talk to each other and customers as a matter of practice. Hackers: “...avoid planning” Agilists:...plan regularly Hackers: “...management caves in out of fear” Agilists:...expect management to provide priorities, & participate jointly project adjustments.
Alistair Cockburn©Humans and Technology, Inc., Slide Agile won’t work for all projects. Right. (Business isn’t fair). Agile is an attitude prioritizing: Project evaluation based on delivered code Rapid feedback People as a value center Creativity in overcoming obstacles Not every team... values the Agile value set.... can set up the needed trust and communication (5-6/6)
Alistair Cockburn©Humans and Technology, Inc., Slide 29 Problem Size Light methodology Heavy methodology # people needed Lighter-agile vs. Heavier-agile : Light is good, but has limits fewer people more people
Alistair Cockburn©Humans and Technology, Inc., Slide 30 Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Discretionary money (D) Suit the process to the occasion project size & priorities, system criticality
Alistair Cockburn©Humans and Technology, Inc., Slide 31 Group’s tolerance for ambiguity / uncertainty Productivity: (Flux & Uncertainty) Reality Check: Work as parallel & light as project features and personalites permit. e-projects old-school projects Project requires at least this much productivity to succeed Where is your group, your project on this graph??
Alistair Cockburn©Humans and Technology, Inc., Slide 32 Part 3: Agile-ly generating agile use cases
Alistair Cockburn©Humans and Technology, Inc., Slide 33 Core elements to using use cases *agile-ly* increments, just-in-time, close communication Write just enough use case content to plan to the needed planning horizon :Long (project) horizon -> just use case names or briefs. :Short (iteration) horizon -> extension handling. Just barely beat the programmers to the extension handling decisions (just in time) Write just enough content for the team to understand. *Show* UCs, system to users/sponsors, get feedback! Adjust your working habits *each iteration* to fit your particular situation!
Alistair Cockburn©Humans and Technology, Inc., Slide 34 Core elements to using use cases *agile-ly*: increments, just-in-time, close communication Ask, How much do we need to write at this time? When do we need to write more? What is the fastest way to write/convey them? Who benefits from more information or more detail?
Alistair Cockburn©Humans and Technology, Inc., Slide 35 Take advantage of available degrees of freedom in the process 1. Write less more clearly (always) 2. Write less (sometimes) 3. Shortcut the use case structure (sometimes) 4. Write later & shortcut the process (usually)
Alistair Cockburn©Humans and Technology, Inc., Slide Write less more clearly (always) Text No GUI No data formats steps in main scenario Easy to read At user’s goal level Record of decisions made UML use case diagrams describing the GUI describing data formats multiple-page main scenario complicated to read at program-feature level tutorial on the domain (shorter, more economic & more readable!)
Alistair Cockburn©Humans and Technology, Inc., Slide Write less (sometimes) (the economics of communication) Fully dressed use cases Casual use cases Use case briefs The correct form to use depends on your project’s priorities and properties !
Alistair Cockburn©Humans and Technology, Inc., Slide 38 Economics of communication: Fully Dressed (expensive, complete) Use Case 12. Buy stocks over the web Primary Actor: Purchaser (user) Scope: PAF Level: user goalPrecondition: User already has PAF open. Guarantees: sufficient log information exists that PAF can detect what went wrong. Success Guarantees: remote web site acknowledged purchase, user's portfolio updated. Main success scenario: 1. User selects to buy stocks over the web. 2. PAF gets name of web site to use (E*Trade, Schwabb, etc.) 3. PAF opens web connection to the site, retaining control. 4. User browses and buys stock from the web site. 5. PAF intercepts responses from the web site, and updates the user's portfolio. 6. PAF shows the user the new portfolio standing. Extensions: 2a. User wants a web site PAF does not support: 2a1. System gets new suggestion from user, with option to cancel use case. 3a....
Alistair Cockburn©Humans and Technology, Inc., Slide 39 Economics of communication: Casual (less expensive, less complete) Buy something(Purchaser / user-goal level) The Requestor initiates a request and sends it to her or his Approver, who completes the request for submission and sends it to the Buyer. The Buyer finds the best vendor, initiates PO with Vendor. At any time prior to receiving goods, Requestor can change or cancel the request. Canceling it removes it from any active processing.
Alistair Cockburn©Humans and Technology, Inc., Slide 40 Economics of communication: Brief (inexpensive, just a short note) ActorGoalBrief Description Production Staff Prepare digital cartographic source Convert external digital data to standard format, validate & correct in preparation for merging with operational database.... (Note: spreadsheets again!)
Alistair Cockburn©Humans and Technology, Inc., Slide Shortcut the use case structure (sometimes) Use cases are not read by a compiler but by a human... --> so, Don’t be rule-bound, but adapt the form to your needs.
Alistair Cockburn©Humans and Technology, Inc., Slide 42 Test department needs detailed requirements. Development can usually use agile ones. Use cases Data formats UI descr. Program Tests Domain expert Usage expert RD RD (Detailed, expensive, long, tedious, brittle use cases) (Shorter, cheaper, easier to read, more stable (agile) use cases) (Test department) RD [Alistair’s generic process model] (Development department)
Alistair Cockburn©Humans and Technology, Inc., Slide Write later and shortcut the process (usually) Use cases *can be* written -- just-in-time --or--all up front in (usable) increments --or-- each to completion (more Agile) (more common) Req'ts Design Validate syntax Validate req'ts Code Validate logic Use the “Validation V” view of increments
Alistair Cockburn©Humans and Technology, Inc., Slide 44 Project horizon -> all use case briefs or casual Iteration horizon -> full use case, just-in-time Full Project SS S EEEEEE Iteration (all UCs, ultra-light content, estimation purposes) (just-in-time, complete) (10 use cases) (10 more use cases)
Alistair Cockburn©Humans and Technology, Inc., Slide 45 Finally, Tools: Choose for the value it delivers, not for its popularity List of UCs for project planning & status: :Spreadsheets are very effective :Lotus Notes medium effective Main success scenario for agreement: :Flipcharts in meeting good for fast disagreement :Word processor (Lotus Notes) quite effective List of extension conditions for completeness: :Word processor quite effective :Flipcharts in project room? (untried) Extension handling steps for policies: :Word processor very effective :WikiWiki technology? (http://c2.com)
Alistair Cockburn©Humans and Technology, Inc., Slide 46 Summary of Agile Use Cases User’s goal level - Text step main scenario - No GUI - No data formats - Easy to read - Record of decisions made (not a tutorial) Write briefs and casuals to estimate & plan project Write full use cases just-in-time per iteration Just-in-time = extension-handling decisions made before the programmer gets around to asking for them. Spreadsheets good for briefs, planning activities. Focus on communicating, not filling templates
Alistair Cockburn©Humans and Technology, Inc., Slide 47 (1) In 10 minutes: Write a use case for a clerk entering a video rental into the computer. (Write the basic dialog between the clerk and the system, Name all the things that could go wrong during the procedure. )
Alistair Cockburn©Humans and Technology, Inc., Slide 48 (2) In 10 minutes: Name all the use cases for a video rental store computer system. (List every person who will use the computer system. For each person, list every reason they have to use the system. )
Alistair Cockburn©Humans and Technology, Inc., Slide 49 (3) In 5 minutes: Prioritize the list of UCs (order in which to develop & deliver them). (Rank for when it is *really* needed, by dependency or business payback. )
Alistair Cockburn©Humans and Technology, Inc., Slide 50 Agile Use Cases Alistair Cockburn Humans and Technology
Agile Principles Suradet Jitprapaikulsarn 1. What is Agility? Effective (rapid and adaptive) response to change Effective communication among all stakeholders.
Agile Web Development C. Daniel Chase University of Colorado at Boulder.
© Alistair Cockburn, 2002 Slide 1 What Is Agile Development & What does it Imply? Alistair Cockburn.
The Agile Alliance By Mark Rucker. The Agile Alliance What is the Agile Alliance? History of the Agile Alliance What is the Agile Alliance today? The.
Alistair Cockburn©Humans and Technology, Inc., Slide 1 The World of Agile Software Development (or, “Creating a fair playing field in 30 minutes”)
Agile Software Development Agile Characterized by quickness, lightness, and ease of movement; nimble.
Time for a BREAK! You have 45 Minutes. Time Left 44.
"The thinking it took to get us into this mess is not the same thinking that is going to get us out of it."
Numbers Treasure Hunt
1 Week 2 The Object-Oriented Approach to Requirements.
Chapter 12 Working with Forms Principles of Web Design, 4 th Edition.
Technische Universität München Agile Modeling Emitzá Guzmán.
BMU - E I 1 Development of renewable energy sources in Germany in
1 How Do I Order From.decimal? Rev 05/04/09 This instructional training document may be updated at anytime. Please visit and check the.
GEtServices Services Training For Suppliers Requests/Proposals.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e Headquarters U.S.A.F. 1 Commodity Councils 101 NAME (S) SAF/AQCDATE.
1 DIGITAL INTERACTIVE MEDIA Wednesday, October 28, 2009.
1 Click here to End Presentation Software: Installation and Updates Internet Download CD release NACIS Updates.
Success Planner PREPARE FOR EXAMINATIONS Student Wall Planner and Study Guide.
Agile Programming Principles. What’s wrong with software today? Software development is risky and difficult to manage Customers are often dissatisfied.
GEtServices Services Training For Suppliers Direct Orders.
3rd Annual Plex/2E Worldwide Users Conference 13A Batch Processing in 2E Jeffrey A. Welsh, STAR BASE Consulting, Inc. September 20, 2007.
BMU – KI III 1 Development of renewable energy sources in Germany in
Copyright I/O International, 2013 Visit us at: A Feature Within from Item Class User Friendly Maintenance Copyright.
CRM ( Customer Relationship Management) An Application For iSeries 400 DMAS from Copyright I/O International, 2003, 2010 Skip Intro.
Optimize tomorrow today. TM 1 Optimize tomorrow today. Arlene Minkiewicz, Chief Scientist PRICE Systems, LLC Are Parametric.
1 Writing Pseudocode And Making a Flow Chart Instructor: Richard T. Vannoy II A Number Guessing Game.
Knowledge Extraction from Technical Documents Knowledge Extraction from Technical Documents *With first class-support for Feature Modeling Rehan Rauf,
Why Do You Want To Work For Us? 50 Great Interview Questions For Great Answers, see the Student Job Centre 1. Why Do You Want To Work For Us?
Agile Methods and Extreme Programming CS 414, Software Engineering I Mark Ardis Rose-Hulman Institute December 19, 2002.
Chapter 5 Software Process Models. Problems with “Traditional” Processes 1.Focused on and oriented towards “large projects” and lengthy development time.
RefWorks: The Basics October 12, What is RefWorks? A personal bibliographic software manager –Manages citations –Creates bibliogaphies Accessible.
Slide 1 FastFacts Feature Presentation August 28, 2008 We are using audio during this session, so please dial in to our conference line… Phone number:
1 CMPT 275 Software Engineering Course Information SUMMER 2014 Janice Regan,
14% of the exam 24 questions 1 Carol Pattyn 6/18/13.
Copyright © 2012, Elsevier Inc. All rights Reserved. 1 Chapter 7 Modeling Structure with Blocks.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
PP Test Review Sections 6-1 to 6-6 Mrs. Rivas 1. 2.
Local Customization Chapter 2. Local Customization 2-2 Objectives Customization Considerations Types of Data Elements Location for Locally Defined Data.
Sample Service Screenshots Enterprise Cloud Service 11.3.
Visual 2.1 Leadership & Management Unit 2: Leadership & Management.
C Copyright © 2005, Oracle. All rights reserved. Practice Solutions.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
By: Isuru Abeysekera AGILE DEVELOPMENT. WHAT IS AGILE DEVELOPMENT? Broad term used to describe several methods for a development process Introduced in.
Plan My Care Brokerage Training Working in partnership with Improvement and Efficiency South East.
©Alistair Cockburn The 2005 “Declaration of InterDependence” Alistair Cockburn
VistA Imaging Capture via Import. 2October 2007 The information in this documentation includes only new and updated functionality of the software after.
Module N° 4ICAO State Safety Programme (SSP) Implementation Course 1 Module N° 4 – ICAO SSP framework Revision N° 5ICAO State Safety Programme (SSP) Implementation.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
© 2017 SlidePlayer.com Inc. All rights reserved.