Agile Development p XP p Scrum p 2

内容 Agile Development 介绍 p XP p Scrum p 2

敏捷开发的核心价值 (Core Value) Individuals and interactions over Process and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan 5

设计原则沿袭设计模式的SOLID原则 p p p SRP n 单一职责原则SRP：Single Responsibility Principle OCP n 开放封闭原则OCP：Open－Closed Principle LSP n Liskov替换原则LSP：Liskov Substitution Principle DIP n 依赖倒置原则DIP：Dependency Inversion Principle ISP n 接口隔离原则ISP：Interface Separate Principle 7

Content 1. XP 2. Scrum 9

Outline Traditional life cycle vs. XP p XP motto: “embrace change” p n How does this attitude compare with that implicit with traditional waterfall software life cycle? XP values p XP practices p Pair programming p An XP development road map p 10

Extreme Programming (XP) Developed by n Kent Beck n “a light-weight methodology for small to so extreme he medium-sized teams developing software never smiles? !? in the face of vague or rapidly changing requirements. ” p Alternative to “heavy-weight” software development models (which tend to avoid change and customers) n "Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities a little at a time throughout development. ” 11 -- IEEE Computer , October 1999

Successes in Industry p p Chrysler Comprehensive Compensation system n After finding significant, initial development problems, Beck and Jeffries restarted this development using XP principles n The payroll system pays some 10, 000 monthly-paid employees and has 2, 000 classes and 30, 000 methods, went into production almost on schedule, and is still operational today (Anderson 1998) Ford Motor Company VCAPS system n Spent four unsuccessful years trying to build the Vehicle Cost and Profit System using traditional waterfall methodology n XP developers successfully implemented that system in less than a year using Extreme Programming (Beck 2000). 12

Embrace change p p p In traditional software life cycle models, the cost of changing a program rises exponentially over time n Why would it cost more to make large changes during testing than during requirements specification? A key assumption of XP is that the cost of changing a program can be hold mostly constant over time Hence XP is a lightweight (agile) process: n Instead of lots of documentation nailing down what customer wants up front, XP emphasizes plenty of feedback n Embrace change: iterate often, design and redesign, code and test frequently, keep the customer involved n Deliver software to the customer in short (2 week) iterations n Eliminate defects early, thus reducing costs 13

Four Core Values of XP Communication p Simplicity p Feedback p Courage p 14

Communication What does lack of communication do to projects? p XP emphasizes value of communication in many of its practices: p n p On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc. XP employs a coach whose job is noticing when people aren’t communicating and reintroduce them 15

Simplicity p ''Do the simplest thing that could possibly work'' (DTSTTCPW) principle n Elsewhere known as KISS A coach may say DTSTTCPW when he sees an XP developer doing something needlessly complicated p YAGNI principle (''You ain’t gonna need it'') p How do simplicity and communication support each other? p 16

Feedback at different time scales p Unit tests tell programmers status of the system p When customers write new user stories, programmers estimate time required to deliver changes p Programmers produce new releases every 2 -3 weeks for customers to review p 17

Courage The courage to communicate and accept feedback p The courage to throw code away (prototypes) p The courage to refactor the architecture of a system p 18

12 XP Practices The Planning Game p Small Releases p Metaphor p Simple Design p Test-driven development p Refactoring p Pair Programming p Collective Ownership p Continuous Integration p 40 -Hours a Week p On-Site Customer p Coding Standards p 19

Planning Game p p p Customer comes up with a list of desired features for the system Each feature is written out as a user story n Typically written in 2 -3 sentences on 4 x 6 story cards Developers estimate how much effort each story will take, and how much effort the team can produce in a given time interval (iteration) Project velocity = how many days can be committed to a project per week Given developers’ estimates and project velocity, the customer prioritizes which user stories to implement 20

Planning Game Split a Story (Customer) Sort stories by value (Customer) “too big” Write a Story Estimate a story (Customer) (Developer) Declare velocity (Developer) “don’t know how” Spike a Story (Developer) Exploration Planning 21

Small and simple p Small releases n Start with the smallest useful feature set n Release early and often, adding a few features each time n Releases can be date driven or user story driven p Simple design n Always use the simplest possible design that gets the job done n The requirements will change tomorrow, so only do what's needed to meet today's requirements (remember, YAGNI) 22

Test-Driven Development (TDD) p p p Test first: before adding a feature, write a test for it! n If code has no automated test case, it is assumed it does not work When the complete test suite passes 100%, the feature is accepted Tests come in two basic flavors… Unit Tests automate testing of functionality as developers write it n Each UT typically tests only a single class, or a small cluster of classes n UTs typically use a framework, such as JUnit (x. Unit) n Experiments show that TDD reduces debugging time n Increases confidence that new features work, and work with everything n If a bug is discovered during development, add a test case to make sure it doesn’t come back! Acceptance Tests (or Functional Tests) are specified by the customer to test that the overall system is functioning as specified n When all acceptance tests pass, that user story is considered complete n Could be a script of user interface actions and expected results n Ideally acceptance tests should be automated, either using a unit testing framework, or a separate acceptance testing framework 23

Sustainable Pace Coding is a marathon, not a sprint. p Team works 40 hours a week - MAXIMUM! p Tired people aren’t productive p 24

Pair programming p Two programmers work together at one machine Driver enters code, while navigator critiques it Periodically switch roles p Research results: p p n n Pair programming increases productivity Higher quality code (15% fewer defects) in about half the time (58%) Williams, L. , Kessler, R. , Cunningham, W. , & Jeffries, R. Strengthening the case for pair programming. IEEE Software, 17(3), July/August 2000 Requires proximity in lab or work environment 25

More XP practices p Refactoring n n p Collective code ownership n n p Refactor out any duplicate code generated in a coding session You can do this with confidence that you didn't break anything because you have the tests No single person "owns" a module Any developer can work on any part of the code base at any time Continuous integration n n All changes are integrated into the code base at least daily Tests have to run 100% both before and after integration 26

More XP Practices p On-site customer n Development team has continuous access to a real live customer, that is, someone who will actually be using the system, or a proxy p Coding standards n Everyone codes to the same standards n Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code 27

Daily Standup Meeting p Goal: Identify items to be accomplished for the day and raise issues • Everyone attends, including the customer • Not a discussion forum • Take discussions offline • Everyone gets to speak • 15 minutes 28

Kindergarten lessons for Pair Programming p Williams, L. and Kessler, R. , “All I Really Need to Know about Pair Programming I Learned In Kindergarten, ” Communications of the ACM (May 2000) n Share everything. (Collective code ownership) n Play fair. (Pair programming—navigator must not be passive) n Don’t hit people. (Give and receive feedback. Stay on track. ) n Clean up your own mess. (Unit testing. ) n Wash your hands before you eat. (Wash your hands of skepticism: buy-in is crucial to pair programming. ) n Flush. (Test-driven development, refactoring. ) n Take a nap every afternoon. (40 -hour week. ) n Be aware of wonder. (Ego-less programming, metaphor. ) 29

XP practices — A Road Map (from www. extremeprogramming. org) 30

XP emphasizes iteration 31

XP emphasizes communication 32

TDD 33

Content 1. XP 2. Scrum 34

Scrum in 100 words • Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. • It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). • The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. • Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

Scrum 36

Scrum Origins p p p Jeff Sutherland n Initial scrums at Easel Corp in 1993 n IDX and 500+ people doing Scrum Ken Schwaber n ADM n Scrum presented at OOPSLA 96 with Sutherland n Author of three books on Scrum Mike Beedle n p Scrum patterns in PLOPD 4 Ken Schwaber and Mike Cohn n Co-founded Scrum Alliance in 2002, initially within the Agile Alliance

Scrum has been used by: • Microsoft • Yahoo • Google • Electronic Arts • High Moon Studios • Lockheed Martin • Philips • Siemens • Nokia • Capital One • BBC • Intuit • Nielsen Media • First American Real Estate • BMC Software • Ipswitch • John Deere • Lexis Nexis • Sabre • Salesforce. com • Time Warner • Turner Broadcasting • Oce

Scrum has been used for: p Commercial software p In-house development p Contract development p Fixed-price projects p Financial applications p ISO 9001 -certified applications p Embedded systems p 24 x 7 systems with 99. 999% uptime requirements p the Joint Strike Fighter Video game development p FDA-approved, life-critical systems p Satellite-control software p Websites p Handheld software p Mobile phones p Network switching applications p ISV applications p Some of the largest applications in use p

Roles Scrum 框架 • Product owner • Scrum. Master • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts 46

Scrum Framework Roles • Product owner • Scrum. Master • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts

Scrum Framework Roles • Product owner • Scrum. Master • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts

Team capacity Product backlog Business conditions Sprint planning meeting Sprint prioritization • • Analyze and evaluate product backlog Select sprint goal Sprint planning • Current product • Technolog y • Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint backlog

No changes during a sprint Change p Plan sprint durations around how long you can commit to keeping change out of the sprint

Start / Stop / Continue p Whole team gathers and discusses what they’d like to: Start doing Stop doing This is just one of many ways to do a sprint retrospective. Continue doing

Scrum Framework Roles • Product owner • Scrum. Master • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts

Burn Down 迭代燃尽图表 67

Burn down Charts Are used to represent “work done”. p Are wonderful Information Radiators p 3 Types: p n n n Sprint Burn down Chart (progress of the Sprint) Release Burn down Chart (progress of release) Product Burn down chart (progress of the Product) X-Axis: time (usually in days) p Y-Axis: remaining effort p

Sprint Burn down Chart p p Depicts the total Sprint Backlog hours remaining per day Shows the estimated amount of time to release Ideally should burn down to zero to the end of the Sprint Actually is not a straight line Can bump UP Remaining work (hrs) p Time (working days)

Release Burn down Chart Will the release be done on right time? p X-axis: sprints p Y-axis: amount of remaining hrs p The estimated work remaining can also burn up p

Alternative Release Burn down Chart p Consists of bars (one for each sprint)

Values on the Y-axis: positive AND negative p Is more informative then a simple chart p

Product Burn down Chart p Is a “big picture” view of project’s progress (all the releases)

Scaling Scrum A typical Scrum team is 6 -10 people p Jeff Sutherland - up to over 800 people p "Scrum of Scrums" or what called "Meta-Scrum“ p Frequency of meetings is based on the degree of coupling between packets p

Scaling Scrum

Pro/Con p p Advantages n Completely developed and tested features in short iterations n Simplicity of the process n Clearly defined rules n Increasing productivity n Self-organizing n each team member carries a lot of responsibility n Improved communication n Combination with Extreme Programming Drawbacks n “Undisciplined hacking” (no written documentation) n Violation of responsibility n Current mainly carried by the inventors

Review

Backup e. Xtreme Programming

XP原则和实践-Planning-project velocity p project velocity n 团队在开发过程中要收集数据，以便于对自己的开发 速度进行评估，用于以后的release plan 2020/10/26 86