EXTREME PROGRAMMING

EXTREME PROGRAMMING - EXTREME PROGRAMMING EXTREME...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: EXTREME PROGRAMMING EXTREME Feb.14,2007 Problems in software development Problems Delivery deferring Business misunderstood High Defect rate High Defect Project cancelled System goes sour Business changes Schedule slips Schedule Many projects are not delivered on time – Examples: Windows vista Examples: Windows Some deadlines cannot be moved – Example: Y2K Example: Y2K We want the software deliver to the We customer on time customer Business misunderstood Business Without direct and effective communication, developers have to guess what the customer wants. But the guess what often not precisely and correctly. often What if: What an on-site customer take part in the development development Defect rate Defect Although the software is tested in a test he phase before release, but the defect rate phase but is so high that it cause so much mend for the software. the Project cancelled Project Size of project 1 function point 10 function points 100 function points 1,000 function points 10,000 function points 100,000 function points Average Early 14.68% 11.08% 6.06% 1.24% 0.14% 0.00% 5.53% On-Time 83.16% 81.25% 74.77% 60.76% 28.00% 13.67% 56.94% Delayed 1.92% 5.67% 11.83% 17.67% 23.83% 21.33% 13.71% Cancelled 0.25% 2.00% 7.33% 20.33% 48.00% 65.00% 23.82% Sum 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% Table 1: Percentage of projects early, on-time, late, canceled (from Patterns of Software Systems Failure and Success, by Capers Jones) System goes sour System Maintenances and updates of the software Maintenances is high costly is What if: What the design is simple and the code quality is high high Business changes Business When production changes etc, it will lead production to business change to Economics of software development software cost of change Requirements Analysis Design Implementation Testing Production What if… What cost of change Time What is XP What XP is a lightweight methodology for small XP lightweight to medium sized teams developing medium software in the face of vague or rapidly vague changing requirements. -- Kent Beck NOTE: The main aim of XP is to reduce the cost of change. Practices Practices 12 most useful practices (guidelines or 12 rules) that support each other: rules) – Planning game – Frequent releases – System metaphor – Simple design – Tests – Refactoring – Pair programming – Collective code ownership – Continuous Integration – Forty-hour week – On-site customer – Coding standards Planning Game Planning Requirements are divided into pieces of user stories user user stories are written by the customer in user by business language on small index cards business describing things that the system needs to do each user story is assigned a business value by each business the developers the for a few months projects there may be 50-100 user stories user Who will play in the planning game? customer & developer Planning Game (2) Planning Moves: – Do the story estimation Assign a cost to each user story by the developer Assign by Cost is measured on ideal weeks (1-3 weeks) A story is split by the customer if it takes longer than 3 by weeks to implement weeks – Make the Commitment Make Commitment Customer and developer together decide which user stories ustomer together constitute the next release constitute – Deal with the Value and Risk first Deal Value developer orders the user stories of the next release so that – more valuable or riskier stories are deal with earlier in more deal the schedule the – a fully working (sketchy) system is completed (in a fully couple of weeks) couple Frequent Releases Frequent The development process is highly iterative The highly A release cycle is usually up to 3 months and consists of iterations up to 3 weeks iterations In each iteration, the selected user stories are implemented implemented Each user story is split in programming tasks of 1Each 13 days small and frequent releases can get frequent small can feedback from the customer feedback Release cycle---iterations—user story—several Release days days System Metaphor System The system metaphor provides a broad view of the The broad project’s goal project’s It defines the overall theme to which developers and It overall clients can relate clients Everybody understands and is responsible for: – Base architecture – Whole system Common concept of what the system is like The system is built around one (or more) system The metaphor from which classes, methods, variables and basic responsibilities are derived basic A description of the system architecture which can be understood by developers and customers underst It describes how the system operates, how the new It function added into the system. function Do not need to design the architecture in detail prior in Do XP. XP. Simple Design Simple Do the simplest thing that could possible work Do simplest could – create the best (simple) design you can Only spend time on current useful functions Only current – do not spend time to implement potential future functions do implement (requirements will change) (requirements Put in what you need when you need it It focus on Simple and Useful It Simple Simple design ensures that there is less – – – to communicate to test to refactor Tests Tests Tests are written before the code is Tests developed developed – Concentration on the interface – Accelerates development – Safe for coding and refactoring for All tests are automated We can consider: We User stories as requirements Tests as specifications Tests Tests(2) Tests(2) 2 kinds of test: – Acceptance tests (functional tests) customers provide test cases for their stories developers transform test cases in automatic tests developers test – Unit tests developers write tests for their classes before developers implementing the classes implementing All unit tests must run 100% successfully all the All time time Refactoring Refactoring The aim of refactoring is to The – make the design simpler – make the code more understandable – improve the tolerance of code to change Change it even if it is not broken! To make it more effectively effectively Improving code while preserving its function and remove mproving preserving and emove redundant code redundant The code should not need any comments The should – – There is no documentation in XP The code and the user stories are the only documents The documents Useful names should be used (system metaphor) Refactoring is continuous design Tests guarantee that refactoring didn’t break anything Tests that worked! that Pair programming Pair “Pair programming is a dialog between two people trying Pair to simultaneously program and understand how to program better”, Kent Beck Kent Two programmers use a computer to program together Two use – one enters code – one reviews the code and thinks Pairs change continuously – every programmer knows all the aspects of the system – a programmer can be easily replaced in the middle of the project Costs 10-15% more than single programming Costs single Code is simpler with less defects (15%) Code Collective code ownership Collective The code does not belong to any programmer but to the The team team Any programmer can change any of the code at any time any any in order to in – make it simpler – make it better Encourages the entire team to work more closely Encourages together together Everybody tries to produce a high-quality system – code gets cleaner – system gets better all the time – everybody is familiar with most of the system – In the same place, so that they can communicate with each In other well other Continuous integration Continuous Daily integration at least An famous example is the Daily Build of An Microsoft Microsoft Integrate the system several time a day. Integrate According the change of requirements, should do the feedback tests. do A working tested system is always available It can avoid the disadvantages of the only one It system integration. system “Overtime is defined as time in the office when Overtime you don’t want to be there” Ron Jeffries Ron Programmers should not work more than one (or Programmers two) week of overtime. It is decided by the two) It affection to the efficiency. affection Keep people happy and balanced Rested programmers are more likely to refactor Rested effectively, think of valuable tests and handle the strong team interaction strong The motivation is to make the developers more The efficiency efficiency 40 hour week 40 On-site customer On-site User stories are not detailed, so there are User always questions to ask the customer always It can make the developers understand It the system well. the The customer must always be available – to resolve ambiguities – set priorities – provide test cases Customer is considered part of the team Coding standards Coding Make pair progamming and collective ake code ownership easier code It emphasis to communicate well through It the coding standards, reduce the unnecessary documents. unnecessary It is different with traditional software It engineering. engineering. Listen-Test-Code-Design Listen-Test-Code-Design Traditional Software Lifecycle: – Listen - Design - Code - Test XP lifecycle – Listen - Test - Code - Design Listen to customers while gathering requirements Develop test cases (functional tests and unit tests) Develop test Code the objects Design (refactor) as more objects are added to the system system Requirements of XP Requirements small teams (up to 10-15 programmers) common workplace and working hours all tests must be automated and executed in all short time short on-site customer developer and client must commit 100% to XP developer practices practices Iterate integration Frequently release etc Who benefits from XP? Who Programmers: – – – – – – – – get clear requirements & priorities can do a good job can make technical decisions don’t work overtime get most business value first get accurate feedback can make informed business decisions can change their mind Customers: When to use XP When It fit for the development of Software project which is: Software Small or medium, the requirement changed Small rapidly, high quality. rapidly, XP is a choice which can balance the XP benefit of short cycle and long cycle. benefit What is XP again? What XP is a discipline of software development. There are certain things you must do. – – – – – – – You must write tests before code. You must program in pairs. You must integrate frequently. You must be rested. You must communicate with the customer daily. You must follow the customer’s priorities. You must leave the software clean and simple by the You end of the day. end – You must adapt the process and practices to your You environment. environment. Values of XP Values Communication Simplicity – Problem of caused by the inefficient communication – Just focus on the current useful requirement and Just make the system as simple as possible without affect it functionalities it – More feedback, more better. – More detail, more better. – It is most important value of XP. Developers should It have courage to face their mistakes, modify their prior code and even drop their prior code. code Feedback Courage Why XP is successful ? XP XP can handle changing customer requirements, XP even late in the life cycle even Use XP on projects – with vague or changing requirements – with small teams XP works, and is very fast XP stresses customer satisfaction; it delivers XP – what the customer needs – when the customer needs it XP emphasises team work XP is fun NOTICE NOTICE Next tutorial will be postponed a week. The next tutorial will be held in Feb,28. Thank You Thank ...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online