Extreme Programming & New Theory of Programming

1. Extreme Programming&New Theory of Programming

2. Recap • Time is important • Time estimation via features • Quality: linear burn curve

3. XP • The most famous agile methodology • First XP project: Chrysler’s C3 system (1997) • Notable figures: Kent Beck, Ron Jeffries • Toyota production system • Low latency: Unimplemented idea pile up (stock) • Stop the line: Detect a Defect as soon as it is introduced

4. XP’s Basic Idea • A fixed scope is a loose-loose situation • Customer wants to maximize scope • Developers want to minimize scope • Instead, decide on fixed time intervals • Periodically, re-negotiate scope • The software is always working • Short cycles of break-repair • Customer can always provide feedback • Project cannot take a wrong path for more than a week

5. The Scope Equation Scope = Time x Quality • You can only fix two of the variables: • Scope, time => Quality • Time, Quality => Scope • Scope, Quality => Time

6. XP: Values • Communication • Simplicity • Feedback • Courage • Respect

7. Simplicity • Passes all tests • Reveals intentions • No duplication/Locality • Minimal number of classes and methods

8. Locality Structure the code so changes have local consequences

9. Stories and Tasks • Story: a short description of customer visible functionality • Task: Breakdown of a task into code-level additions/changes • It is often that story == task

10. Iteration Cycle • Define scope (stories) • Planning game • For each story: Implement smallest delta needed to realize the story • “minimal thing that could possibly work” (YAGNI) • May trigger refactoring • Incremental steps • Reflection – what have been doing? • Everyone can see where the project is standing • Customer can see what is still missing • Learning: enhance the process

11. The Planning Game • Negotiate scope with customer • Customer: chooses stories • Developers: What can be completed • Output: a set of prioritized task • Deciding what can be completed • Esitmate task/story using points • Esitmate task/story using hours • Compare to previous week * Total capacity: “Yesterday’s weather”: Same as last weeks • Re-plan if completed early

12. XP: Practices • Negotiated Scope Contract • Incremental Design • Shared Code + Single Code Base • Intensive testing (easiest via TDD) • Ten-Minute Build • Continuous Integration • Daily Deployment * Customer can check the system on a daily basis => Can define the scope for the next iteration

13. Iteration-0 • At each iteration, the program evolves • By adding new functionality to the prev. iteration • Q: What happens at the very first iteration? • A: Develop a skeleton • Most of the parts • Degenerated functionality

14. Informative Workspace • AKA: • “Information Radiators” • “talking walls” • Continues Integration Status • Burn up • Stories: Waiting, In progress, Completed

15. Human Factor • Pairs • Standup meetings • Sense of accomplishment • Working software • Constant customer feedback • TDD keeps developer focused • Working software • No frustration over the weekend • Stories on real index card • Can be sorted, shuffled, grouped, passed, posted to a wall • Many people say they are better than s/w tools

16. XP: Larger Scale • Decompose into several smaller projects • Along the “natural fracture lines” • Release Planning • Quarterly • Choose themes – build a bank of stories

17. Technical Debt • A quick and dirty solution induces a technical debt • similar to a financial debt • Incurs interest payments: Extra effort due to the dirty design • We can choose to continue pay the interest • Or, we can pay down the principal • Refactor the dirty design into a clean one • Sometimes, quick and dirty is sensible • Taking a loan to take advantage of a business opportunity • Going into technical debt to meet a deadline

18. Costs • Past • cost = Tdevelop • Present • cost = Tplan + Tdevelop + Ttest + Tdeploy • Maintenance: Tplan includes time needed for understanding the existing system • XP • I have tests -> Code can adapt -> No need for sophisticated planning (other than choosing the iteration’s scope) • Tplan: Low • UML process • I carefully planned -> I have good code -> no need to adapt • (Planning requires foresight) • Tplan: high

19. Axioms • Super-linearity • Instability • Uncertainty • Non-traceability

20. Instability Existing code will need to change • Code should adapt • Testing

21. Uncertainty The more accurate the specification, the more error prone it is • Precise planning of the full system is a waste of time • XP: Roughly plan the current iteration

22. Non-traceability It is impossible to estimate the full effect of a change • Instead of inventing a design, discover it as you go along

23. Super Linearity A large task is relatively (and absolutely) more expensive than a small task

24. Program Breakdown • Two ways to decompose a software project • Feature by feature • Many small tasks • Subsystem by subsystem • Few large tasks • Essentially same amount of code • Feature by feature is less work • If we accept the super-linearity axiom