1 / 24

Extreme Programming & New Theory of Programming

Learn about Extreme Programming (XP), its basic ideas, scope equation, values, practices, and larger scale implementation. Discover how XP addresses technical debt and the costs associated with software development.

kennethi
Download Presentation

Extreme Programming & New Theory of Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related