Agile Methodologies (including: XP & Scrum)

1. Agile Methodologies(including: XP & Scrum) By Avi Wortzel 22.03.2007

2. Agenda • Problems in software development. • What is a Methodology. • The Agilemethodology. • The Agile Manifesto. • Stepping towards Agile Development. • Well-known agile methodologies. • The eXtreme Programming (XP) methodology. • The XP lifecycle. • The Original 12 Practices. • When to use XP. • The Scrum methodology • Our best practices.

3. Problems in software development • Schedule slips • Business misunderstood • Defect rate • Project cancelled • System goes sour • Business changes

4. Schedule slips • Many projects are not delivered on time • Examples: Netscape 6 • Some deadlines cannot be moved • Example: Y2K • What if: most business value is delivered on time

5. Business misunderstood • Without direct communication, developers have to guess what the customer wants. • What if: an on-site customer steers development

6. Defect rate • The software is put in production, but the defect rate is so high that it isn’t used. • What if: you have automated testing

7. Size of project Early On-Time Delayed Cancelled Sum 1 function point 14.68% 83.16% 1.92% 0.25% 100.00% 10 function points 11.08% 81.25% 5.67% 2.00% 100.00% 100 function points 6.06% 74.77% 11.83% 7.33% 100.00% 1,000 function points 1.24% 60.76% 17.67% 20.33% 100.00% 10,000 function points 0.14% 28.00% 23.83% 48.00% 100.00% 100,000 function points 0.00% 13.67% 21.33% 65.00% 100.00% Average 5.53% 56.94% 13.71% 23.82% 100.00% Project cancelled Table 1: Percentage of projects early, on-time, late, canceled(from Patterns of Software Systems Failure and Success, by Capers Jones)

8. Project cancelled • What if: short releases deliver at least some useful working software, reflecting investment to date.

9. System goes sour • Software is put into production successfully, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced. • What if: the design is simple and the code quality is high

10. Business changes • New laws, market changes: business priorities change • What if: the customer can change their mind, substitute functionality, and change priorities

11. Economics of software development

12. What if…

13. What it Methodology? (In software engineering and in project management) “A methodology is a codified set of practices (sometime accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software. Software engineering methodologies span many disciplines, including project management, analysis, specification, design, coding, testing, and quality assurance.” (Wikipedia)

14. What is Agile? • “The ability to move or think easily and quickly“ (http://www.answers.com). • In software development, “agile” tends to mean “the ability to respond to change.”

15. The Agile Manifesto The focal values honored by the agilists are presented in the following: • Customer’s satisfaction: • By a rapid, continuous delivery of useful software • Even late changes in requirements are welcomed • Time to market: • Working software is delivered frequently (weeks rather than months) • Communication: • Close, daily, cooperation between business people and developers • Face-to-face conversation • Human factor: • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good & simple design • Regular adaptation to changing circumstances

16. Focal aspect in Agile • Focus only on the necessary functions at first hand. • Deliver them fast. • Collect feedback. • React to the received information.

17. What makes a development methods an agile one? • When software development is incremental (small software release, with rapid cycles ). • Cooperative (customer and developers working constantly together with close communication). • Straightforward (The design & code are easy to learn and to modify, well documented). • Adaptive (can make last moment changes).

18. “Sweet spots” for successful project(by Alistair Cockburn 2002) • 2 to 8 people in one room (communication & community). • On-site customers (Short & continuous feedback cycles) • Short increments (One to three months, allow quick testing and repairing). • Fully automated regression tests (Unit & functional tests stabilize code and allow continuous improvement) • Experienceddevelopers speeds up the development time from 2 to 10 times, compared to a slower team members.

19. Some of the well-known agile software development methods: • Extreme Programming)XP( - 1999 • Scrum -1993 • Agile Modeling- 2002 • Adaptive Software Development )ASD) - 2000 • Crystal Clearand Other Crystal Methodologies- 2002 • Dynamic Systems Development Method)DSDM( - 1997 • Feature Driven Development- 2002 • Lean software development - 2002 • Agile Unified Process)AUP( - 2000

20. What Is eXtreme Programming? • eXtreme Programming (XP) is a software engineering methodology. • The most popular in agile methodologies. • Evolved from the problems: • long development cycles of traditional development models. • XP combines best practices in a different way.

21. The XP lifecycle

22. Exploration phase • The customer writes out the story cards. • Each story card is a feature to be added. • Development team decides on tools, technology and practices. • Building a prototype of the system. The exploration phase takes between a few weeks to a few months

23. Story card

24. The XP lifecycle

25. Planning phase • Sets the priority order for the stories. • Agree on the first small release (no more than tow months for the first release). • The programmers first estimate each story requires. The planning phase itself takes a couple of days

26. The XP lifecycle

27. Iterations to release phase • Includes several iterations before the first release. • Each iteration takes one to four weeks to implement. • The first iteration creates a system with the architecture is the whole system. • The customer decides the stories for all other iterations. • The functional tests created by the customer are being run at the end of every iteration. • At the end of the last iteration the system is ready for production. The Iterations to release phase takes one to tree months

28. The XP lifecycle

29. Productionizing phase • Requires extra testing and checking of the performance before the system can be released. • New changes may still be found and the decision has to be made if they are included in the current release. • The postponed ideas and suggestions are documented for later implementation during, e.g., the maintenance phase. The Productionizing phase takes one to tree weeks

30. The XP lifecycle 0

31. Maintenance phase • The XP Project must both: • keep the system in the production running • while also producing new iterations. • The maintenance phase requires an effort also for customer support tasks. • The development velocity may decelerate. • This phase may require incorporating new people into team and changing the team structure. The Maintenance phase takes ...

32. The XP lifecycle 0

33. Death phase • This phase is near when the customer does no longer have any stories to be implemented. • This required that the system satisfies customer needs also in others respects (e.g., concerning performance and reliability). • This is the time in the XP process when the necessary documentation of the system is finally written as no more changes to the architecture, design or code are made. • Death may also occur if the system is not delivering the desired outcomes, or if it becomes too expensive for further development.

34. The Original 12 Practices • The Planning Game • On-Site Customer • Small Releases • Testing • Simple Design • Pair Programming • Refactoring • Continuous Integration • Collective Ownership • Coding Standards • Metaphor • 40-Hour Week

35. Planning Game • This stage includes release planning & Iteration Planning. • “Requirements collection” phase: • The customer write stories. • The customer set priority for each story. • The developers estimate the costs and risks. • The “Planning Game” phase: • Calculating all the parameters of risks, priorities and coats. • Creating a list of tasks. • This help to get a real estimation based on the real team’s performance. • The release is generally from 1 to 3 month, and each iteration is generally from 1 to 3 weeks.

36. Planning Game Story Priority Cost Story card 1 Story card 2 Story card 3 3d 1 5 5d 0 5d

37. On-Site Customer • The main idea in XP is based on project community. • The customer attends and is available on site to clarify stories, identify and solve requirements problem quickly. • Reducing the developers waiting time for decisions. • The communication is more effective (without organization politics).

38. On-Site Customer

39. Small Releases • Time-boxing - the deadline is fixed, and the deliverables are adjusted. • Immediate ROI (Return of investment): small release with enough business values. • Fast feedback. • Easy to guidance. • The customer feels that the application is always under a developing process, and that he has quick influence abilities.

40. Testing • Acceptance Testing: • Written by the customer, based on the story cards. • To check that the system implements all the requires. • All acceptance tests executed in each iteration (part of the regression testing) • Usually as automation tests. • Using to measure the project progress. • Unit Testing: • Written by the programmer. • Automation tests. • Coverage testing - Checking all your code. • Running the unit tests in a daily process, before check-in and before & after refactoring. • Use the xUnit framework.

41. Testing: Test-Driven Development • Likely the most innovative XP practice • Developer writes a unit test prior to writing code • Developer writes just enough code to make the unit test pass • Developer refactors to ensure code is simple and clean. • Developer continues until acceptance test passes. • Unit Testing makes your developer lives easier: • Easier to find bugs • Easier to maintain • Easier to understand • Easier to Develop

42. Simple Design • Design the most simple possible solution that can be implemented at the moment: • Passes all the tests. • No duplicate code. • Fewest possible classes and methods. • See the whole picture before jumping to write code. • Involves a lot of people in thinking of a solution. • Simple designs reduce programmer’s questions.

43. Simple Design

44. Pair Programming • All production code is written in pairs. • Includes two people that are sitting on one computer, with one keyboard and one mouse. • Benefits: • 15% less output than 2 solo programmers. • Higher quality code :Continuous code review, better design, less defects. • Confidence to add or change the system. • Teach each other how the system works (reduced risks). • Learn from partner’s knowledge and experience (enhances technical skills). • Research shows that pairing can be more effective than solo programming. • Short-term costs made up by long-term benefits. • Contributes to avoidance of knowledge debt.

45. Pair Programming

46. Refactoring (Design Improvement) • Improves the design of existing code without changing its functionality. • Design becomes everybody’s daily business. • Always improve quality of the code. • Easy to make when using unit tests & pair programming.

47. Refactoring (Design Improvement)

48. Continuous Integration • Move to the next task only after the current task pass the integration tests. • Integration occurs several times a day. • Daily builds – part of the integration process. • Benefits: • Forces bug fixing to occur immediately • Avoiding a situation when the integration occurs only next to the deployment. • reducing the changes after merging.

49. Collective Ownership • Any one can make changes to any part of the code at anytime. • No queuing bottlenecks: • No need to wait for someone else to fix something. • Everyone responsible for code integrity.

50. Coding Standards • Consensus of coding style and practices. • Code conventions: • consider when using Pair Programming, Refactoring and Collective Code Ownership. • Method commenting: • The code should explain itself: • If your code needs a comment to explain it, rewrite it. • If you can't explain your code with a comment, rewrite it.