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