Agile Methodology and Extreme Programming Anuj Kumar and

Agile Methodology and Extreme Programming Anuj Kumar and Bassam Tork

Agenda • What is Agile Methodology • How Agile Methods differ from Traditions Techniques • Agile Manifesto • Agile Methodologies • What is XP • XP Values • Life Cycle of an XP Project • Basic XP Practices • Examples • XP Limitations • XP Misconceptions

What is Agile Methodology? • It is a conceptual framework for software engineering and mainly advocates frequent and regular software releases. Incrementally build software – Highest priority feature first software • Common theme behind Agile Methods: – Keep things simple and lightweight, focus on producing the end product and be responsive to changing requirements.

How Agile Methods differ from Traditions Techniques

Agile Manifesto • Individuals and interaction over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

Agile Methodologies • • • AM(Agile Modeling) XP (e. Xtreme Programming) DSDM(Dynamic System Development Method) SCRUM FDD(Feature Driven Development)

What is XP? • Definition: -Extreme Programming (XP) is a discipline of software development based on values of simplicity, communication, feedback, and courage. • It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Cost of Change • Traditional methodologies seek to reduce costs according to Barry Boehm’s cost of change curve

How XP helps? The XP Cost of Change Curve

XP Values • Basic values of Xp – Communication – Simplicity – Feedback – Courage

XP Value: Communication • Poor communication in software teams is one of the root causes of failure of a project • Stress on good communication between all stakeholders--customers, team members, project managers • XP emphasizes value of communication in many of its practices: – On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc

XP Value: Simplicity • ‘Do the Simplest Thing That Could Possibly Work’ – Implement a new capability in the simplest possible way – Refactor the system to be the simplest possible code with the current feature set • ‘You Aren’t Going to Need It’ – Never implement a feature you don’t need now

XP Value: Feedback • Programmers produce new releases every 2 -3 weeks for customers to review • Unit tests tell programmers status of the system • Small iteration and pair programming help a great deal to give a proper understanding of where they stand • Hence, Feedback is repetitive and frequent in XP

XP Value: Courage • The courage to communicate and accept feedback • The courage to throw code away (prototypes) • The courage to refactor the architecture of a system

Life Cycle of an XP project

Basic XP Practices • XP is based on 12 key practices: – The Planning process At the start of each iteration customers, developers meet to estimate the requirements(stories) for the next release. – Small Releases Start with the smallest useful feature set. Release early and often, adding new features each time. – System Metaphor Is a naming concept, that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. – Simple Design Go for the simplest possible design that gets the job done. Do what’s needed to meet today’s needs.

Basic XP Practices…. contd – Continuous Testing Before programmers add a feature they write a test for it. – Refactoring Refactor out any duplicate code generated in a coding session. – Pair Programming All production code is written by two programmers setting at one machine. Driver: types the code Navigator or Observer: reviews the code. The two programmers switch roles frequently. – Collective Ownership No single person owns a module.

Basic XP Practices…. contd – Continuous Integration All changes are integrated into the code-base at least daily. The tests have to run 100% both before and after integration. – 40 -Hour Week Requirements should be selected for each iteration such that developers need not put in overtime. – On-Site Customer Development team has continuous access to a real live customer , that is , someone who will actually be using the system – Coding Standards Everyone codes to the same standards.

Shedding The Light Upon Some Key Practices • • • I’ll talk more deaply about some important/key practices that need more technical skills than others(unit test, refactoring). with some examples to see how XP methodology is applied in real environment. User Stories Unit test/Functional Test Refactoring XP limitations XP misconceptions

User Stories • A short description of the behavior of the system from the point of view of the Customer • Customer’s terminology without technical jargon • One for each major feature in the system • Must be written by the users

User Stories. …. contd • Drive the creation of the acceptance tests: – Must be one or more tests to verify that – a story has been properly implemented • Different than Use Cases: – Written by the Customer, not the Programmers, using the Customer’s terminology – More “friendly” than formal Use Cases

User Stories. …. contd User stories have three crucial aspects: • Card – Enough information to identify the story • Conversation – Customer and Programmers discuss the story to elaborate on the details • Confirmation – Acceptance tests to confirm that the story has been properly implemented

User Story Examples continued The user must be able to search for a book. Risk: High Cost: (too large!)

User Story Examples continued The user must be able to search for a book by Title, and display the results as a list. Risk: Med. Cost: 1 point

Unit/Programmer Tests Theory Of Test-Driven Development • Automated tests written to test the behaviour of individual classes • Fundamental to XP, and maintaining a flat cost curve. • XP uses a Test First mentality. – write the test, then write to code to make the test pass. (Kent Beck: "Never write a line of code without a failing test. “). • No code goes into production unless it has associated tests • Tests are written first • Tests determine what code you need to write

Cost of Change • Traditional methodologies seek to reduce costs according to Barry Boehm’s cost of change curve

Unit/Programmer Tests…contd Theory Of Test-Driven Development • Testing frameworks exist for many languages: – JUnit for Java – CPPUnit for C++ – NUnit for all. Net languages

Example-Test First Development User Story (Payroll System): Monthly income tax should be 5% of monthly salary if Monthly income is less than $1000. Other else it should be 10%. Risk: Low. Cost: 1 point

Example-Test First Development /The. Test Will Fail at First package junitdemo; //import static org. junit. Assert. *; import org. junit. Before; import org. junit. Test; import junit. framework. Test. Case; public class Test. Income. Tax extends Test. Case{ Income income 1, income 2; @Before public void set. Up() throws Exception { income 1=new Income(100); income 2=new Income(1000); } @Test public void test. Calc. Income. Tax() { doubleincome 1 Tax=income 1. calc. Income. Tax(); doubleincome 2 Tax=income 2. calc. Income. Tax(); assert. Equals(income 1 Tax, 5. 0); assert. Equals(income 2 Tax, 100. 0); } }

Example-Test First Development //test pass package junitdemo; public class Income { private double salary; public Income(){ this(1000); } public Income(double salary){ this. salary=salary; } void set. Salary(double salary) { this. salary = salary; } double get. Salary() { return salary; } public double calc. Income. Tax() { if (get. Salary()< 1000) return salary*0. 05; else return salary*0. 1; } }

Refactoring • Code refactoring is any change to code that improves its readability or simplifies its structure without changing its results. • Improves the quality and maintainability of code. • Refactoring neither fixes bugs nor adds new functionality • When my coauthors and I wrote Design Patterns, we mentioned that design patterns provide targets for refactoring. However. identifying the target is only one part of the problem; transforming your code so that you get there is another challenge. [Erich Gamma -Foreword] in [Refactoring – Improving the Design Of Existing Code, Martin Fowler].

Refactoring • In our current understanding of Software Development, we believe. good design comes first coding comes second. • Refactoring is the opposite of that practice. you can take a bad code, chaos even and rework it into well-designed code. • Over the time the code will be modified, and the structure according to that design, gradually fades.

Sample Refactoring Techniques – Encapsulate Field- force code to access the field with getter and setter methods – Generalize Type- create more general types to allow for more code sharing – Extract Method - to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. – Rename Method or Rename Field - changing the name into a new one that better reveals its purpose – Pull Up - in OOP, move to a super class – Push Down - in OOP, move to a subclass

Examples of refactoring • Extract Method – You have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of the method. void print. Owing() { print. Banner(); // Print Details System. out. println( “Name " + _name); System. out. println( “Amount " +amount); }

Examples of refactoring. . contd • The result: void print. Owing() { print. Banner(); print. Details(amount); } void print. Details (double amount) { System. out. println( “Name: " + _name); System. out. println( “Amount: " + outstanding); } (Source: “Refactoring”, by Martin Fowler)

Inline Method A method body is just as clear as its name Put the method’s body into the body of its callers and remove the method. int get. Rating(){ return (more. Than. Five. Late. Deliveries())? 2: 1; } boolean more. Than. Five. Late. Deliveries(){ return _number. Of. Late. Deliveries>5; } Int get. Rating(){ return (_number. Of. Late. Deliveries>5)? 2: 1; }

Examples of refactoring. . contd Replace Error Code with Exception int withdraw(int amount) { if (amount > _balance) return -1; else { _balance -= amount; return 0; } } void withdraw(int amount) throws Balance. Exception { if (amount > _balance) throw new Balance. Exception(); _balance -= amount; }

Examples of refactoring. . contd • Replace Iteration with Recursion • unsigned greatest_common_divisor (unsigned a, unsigned b) { while (a != b) { } • } else if (b > a) { b -= a; } } unsigned greatest_common_divisor (unsigned a, unsigned b) { (a > b) { return greatest_common_divisor ( a-b, b ); }else if (b > a) { return greatest_common_divisor ( a, b-a ); } else if(a == b) { return a; } } a -= b; if (a > if

Examples of refactoring. . contd Replace Complex Recursion that is hard to understand with Iteration. • public void count. Down(int n) { if(n == 0) return; System. out. println(n + ". . . "); wait. ASecond(); count. Down(n-1); } • public void count. Down(int n) { while(n > 0) { System. out. println(n + ". . . "); wait. ASecond (); n -= 1; }

Limitations of Xp • Team Size Because the development team needs to be co-located, team size is limited to the number of people that can fit in a single room, generally agreed to be from 2 -12. • Support for distributed teams Because of XP’s focus on community and co-location, distributed teams are not supported. • Limited support for developing large, complex software The assumption that code refactoring removes the need to design for change may not hold for large complex systems.

Misconceptions about XP 1. No documentation in an XP project Just produce the needed documentation and nothing more 2. No design in an XP project Encourages continuous incremental design. 3. Programmers get to work in pairs thereby increasing production cost. 4. Ignores gathering requirements Requirements are central but not as detailed as traditional methodologies.

Conclusion • • • XP is people oriented rather than process oriented XP flattens the cost of change curve. XP delivers high business value in early stages. Incremental and not upfront design in XP. In rapidly changing requirements environment. XP proves a much appropriate methodology than the traditions ones.

References • Agile Software Construction by John Hunt Springer © 2006 ISBN: 9781852339449 • Extreme Programming in Practice by Newkirk, Martin ISBN: 0 -20170937 -6 • Extreme Programming Installed by Jeffries, Anderson, Hendrickson ISBN: 0 -201 -70842 -6 • Extreme Programming Applied by Auer, Miller ISBN: 0 -201 -61640 -8 • Extreme Programming and Agile Methods XP/Agile Universe 2002 by Wells, Williams ISBN: 3 -540 -44024 -0 • Hayes, Steve; Andrews, Martin, An Introduction to Agile Methods, • www. wikipedia. com • Extreme Programming: A Gentle Introduction www. extremeprogramming. org • http: //www. ibm. com/developerworks/library/j-test. html

Thank You.