1. Interactions

2. The prey, the pack, and the hunt Your goal is to meet your customer’s needs That goal, and nothing else, is the prey Not throwaway prototypes Not documentation Not models You will work as a team to obtain your goal 1 sweet airbrush!!

3. Identifying your Prey Extreme Programming offers three ways to identify your goal 1.User stories 2.Acceptance tests 3.Unit tests 2

4. User Stories (Review) How big should a story be? 3”x5” card How many user stories is the customer allowed to generate? As many as they want When can the engineer prioritize the stories? Never! The customer does the prioritization 3

5. Acceptance Tests and User Stories Each user story may have multiple acceptance tests A single acceptance test validates an aspect of a user story Exercising the system the way a user would Acceptance tests tell what the customer will use to judge success Main benefit of acceptance tests: You know when you can stop developing!!! 4

6. Example Tests User Story: Generate a Receipt “As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal” 5 PriceLookup PrintReceipt items prices receipt printer

7. Example Tests User Story: Generate a Receipt “As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal” Unit tests for PrintReceipt component: Input: 6-pack of craft beer; Verify: $8.99 Input: milk; Verify: $2.00 6

8. Example Tests User Story: Generate a Receipt “As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal” Unit tests for PriceLookup component: Input: Beer $8.99, Milk $2.00, Beer $ 8.99 Verify: Receipt lists items and total: $19.98 7

9. Example Tests User Story: Generate a Receipt “As items are entered by the clerk, their name and price are added to a receipt, and the price is added to the subtotal” Acceptance test (combines several unit tests): Test: Scan one 6-pack, one mile, one 6-pack Verify: Receipt lists items and total: $19.98 8

10. Creating Acceptance Tests Ideally, customer writes acceptance tests Acceptance tests are blackbox tests The test writer doesn’t get to read the testbed code Tests should be unambiguous 9

11. 10 FIT Framework http://fit.c2.com/FIT: Framework for Integrated Test

12. Running Acceptance Tests Run acceptance tests once a week, preferably more often Often useful to have an integration machine where you run acceptance tests Representative of what customer would have 11

13. Unit Tests (Review) Who write the unit tests? Programmer! When do unit tests get written? Before writing the application code 12

14. Benefits of Unit Tests Clarifies the task at hand Frees you from writing perfect code (temporarily) Make reliable refactoring possible 13

15. Creating Unit Tests Unit tests start out as blackbox tests, become whitebox tests First created for non-existent code At any time, you can read your (new) application code and revise the test code Exhaustive testing is usually infeasible Use representative testing instead Typical inputs Boundary cases 14

16. Creating Unit Tests Writing the first test is the hardest “Your test suite is more valuable than your code” “If you want a good suite of tests next year, you must being collecting them today” 15

17. When to Program You only write code when the test suite is broken or if you are refactoring Your twin goals: Pass the unit tests for today’s user stories Refactor to keep things under control 16

18. “The Hunt is not Yours Alone” It’s not your code, it’s the team’s code “Egoless programming doesn’t work; expand your ego to include everyone’s code” Anybody can edit any code that has been checked in 17

19. Benefits of Pair Programming Similar to a real-time code review Copilot can help catch implicit assumptions Pair programming takes 15% longer but leads to 15% fewer bugs (a “win” for many projects) Ideas and techniques spread throughout group 18

20. Pair Programming: The Driver Controls the keyboard and mouse Is actively talking to the copilot Explains intent of code and where he/she is going 19

21. Pair Programming: The Copilot Not a passenger!! Pays attention, watches for mistakes, offers ideas Talk about and agree upon best course of action If you can’t agree, then take turns yielding to each other’s preferences At any moment, copilot can request to switch places and drive Driver can say “hold on a second”, but should switch as soon as possible You are working as a pair, a team 20

22. Principles of Pair Programming If someone asks to pair with you, (and you can), you must say yes (No “playing favorites”) Code formatting: pick a standard as a team, enforce, move on Font size: choose a font large enough for copilot to see Take turns pairing with many different people If you write code alone, then it must be rewritten 21

23. Interacting with Team Periodically communicate progress E.g., end-of-day email Track progress with wiki or other tools Use models judiciously Draw diagrams to help you reason Draw diagrams to communicate Only draw diagrams if it helps your team get the prey 22

24. Models in Agile Processes Must provide value Must fulfill a purpose Must be understandable Must be as simple as possible Must be sufficiently: Accurate Concise Detailed 23

25. NOT TRUE about Models in Agile Models = documentation Modeling implies a heavyweight process Modeling freezes requirements Models never change Models are complete Models must be created with a tool All developers must know how to model properly Modeling is a waste of time The data model is the only one that matters 24

26. Tips for Agile Modeling Don’t let the models distract from the hunt Model iteratively and incrementally Model with other people Stakeholders Collectively (as a team) Display models publicly Create simple content Use the simplest tools 25

27. More Tips for Agile Modeling Don’t spend time getting things perfect Follow agreed upon standards Reuse existing resources Discard temporary models 26

28. The prey, the pack, and the hunt Your goal, and nothing else, is to meet your customer’s needs Each of these is a means to an end, not an end in itself Acceptance tests Unit tests Pair programming Modeling You will work as a team to obtain your goal 27

29. Next Steps Final Vision Statement due Friday!! (11/21) No late material will be accepted Midterm due 11/25 No late material will be accepted Homework #6 (Implementation Plan) due 12/03 28