Agile Methods (Extreme Programming)

1. Agile Methods (Extreme Programming) A Framework For Pulling It All Together

2. Extreme Programming • A deliberate and disciplined approach to software development • Suited to risky projects with dynamic requirements • Including late life cycle changes • Emphasizes customer satisfaction • Unproductive activities have been trimmed from the process • Reduces cost • Reduces frustration

3. Extreme Programming (cont.) • Promotes team work • Managers • Customers • Developers • Software project improvements (see following slides) • Communication • Simplicity • Feedback • Courage

4. Software project improvements • Communication • Between developers • Between managers and developers • Between customer and developers • Simplicity • Designs are keep simple • Designs are keep “clean” (uncluttered with extraneous features)

5. Software project improvements (cont.) • Feedback • Testing begins on day 1 thus encouraging feedback • Customer feedback/requests are implemented immediately • Courage • Programmers respond to changing requirements • Programmers respond to changing technology • No fear of repercussion such as cost/time

6. Something New? • “software engineered to be simple and elegant is no more valuable than software that is complex and hard to maintain” • XP refutes this view • Programs that are easy to understand and maintain save time and money

7. Something New? (cont.) • Testing is a crucial part of development • Tests are created before, during, and after code is written • Tests are well matched to the code they are testing • Identification of bugs leads to new tests to ensure that the same bugs do not reoccur

8. Something New? (cont.) • Change is embraced • Customer feedback is encouraged throughout development • Allows customers to take full advantage of unseen/unanticipated opportunities in the marketplace

9. When? • Created in response to problem domains whose requirements change • Address areas of risk • Time schedule • Unproven/unfamiliar technology • Small groups of developers (2-10) • Not good for large teams of developers

10. When? (cont.) • Extended development team • Developers • Managers • Customers • All must “buy in” to the process

11. Another Methodology? • Software methodology • The set of rules and practices used to create computer programs • Heavyweight methodology • Many rules, practices, and documents • Requires discipline and time to follow correctly • Lightweight methodology • Few rules, practices, and documents • Easy to follow

12. Another Methodology? (cont.) • To facilitate use of heavyweight methodologies, tools were invented • CASE (Computer Aided Software Engineering) tools, but the tools themselves are often difficult to learn • Time that could be spent on the problem is redirected to the “meta-problem”

13. Another Methodology? (cont.) • For the lightweight methodologies we pick and choose the rules to follow • Learn from the past • Keep rules that directly lead to the creation of quality software • Omit the rules that hinder progress • Simplify the rules that are too complex • Make programmers feel free to be creative and productive while remaining organized and focused

14. What is Extreme Programming? • A collection of rules and practices each of which supports the development and delivery of quality software • The rules and practices support each other (are used together) • It’s an iterative process

15. Stages • Planning • User Stories • Design of the system architecture • Architectural spikes or prototypes • Code creation • Testing • From day 1 • Not necessarily in this order

16. User Stories • Similar in purpose to use cases • Create time estimates for release planning (to be defined later) • Replace large requirements documents • Written by customers as things the system must do for them (like scenarios) • Helps to avoid technical jargon

17. User Stories (cont.) • Drive the creation of acceptance tests • Derive tests to verify the implementation of the story as the story is being written • Provide only enough detail to make an implementation time estimate • Detailed descriptions will be solicited during implementation (i.e. questions for the domain expert or customer)

18. User Stories (cont.) • Time estimates • Provided by developers • “ideal development time” units • Assuming no distractions • Assuming no other assignments • Assuming you know exactly what to do • Should be 1-3 weeks in duration • Shorter stories get merged • Long stories get split

19. User Stories (cont.) • Focus is on user needs • As opposed to technical details that may be present in a “classical” requirements specification • As opposed to GUI designs that may be present in a “classical” requirements specification

20. Release Plan/Planning • Layout the overall project • Layout individual iterations through the project • Release planning follows a set of rules • Development team estimates user story times • Customer determines user story priorities • Management make resource decisions

21. Release Plan/Planning (cont.) • Business people make business decisions • Technical people make technical decisions • Negotiation results in a schedule all can commit to • The approach yields a useable system (in terms of customer needs and technical abilities) delivered as early as possible

22. Release Plan/Planning (cont.) • Planning may be based on time or scope • Time • How many user stories can be implemented by a specified date • Scope • How long it will take to complete a set of user stories • Project velocity is used in the estimates • A measure for time estimates and progress • More on this later

23. Release Plan/Planning (cont.) • Iterations are not planned in detail until just before they begin • Facilitates scheduling change • Addresses issue of poor estimates in time • Facilitates task (user story) priority changes

24. Release Plan/Planning (cont.) • “But it looks like it’s going to take too long” • Don’t change estimates based on such statements • This will cause problems later (when they’re more difficult to correct) • Negotiate a release plan that is acceptable to all parties…developers, customers, management

25. Release Plan/Planning (cont.) • A release plan can be quantified by four variables • Scope – how much is to be done • Resources – how many people are [how much equipment is] available • Time – when will the project be done • Quality – how good will the finished produce be

26. Release Plan/Planning (cont.) • Management can only choose to manipulate 3 of these variables • Developers always get the 4th • …and, skimping on quality is never acceptable • Always causes problems at a later date • Let developers have a say in how many people get “dumped” onto the project

27. Release Plan • Result of Release Planning • Based on user stories and release planning • Specifies exactly which user stories are going to be implemented for each release date

28. Release Plan (cont.) • Provide a set of user stories for the customer to choose from for the next iteration (iteration planning) • Translate these stories into programming tasks for the iteration • Will be translated into acceptance tests during the iteration • If the project velocity changes for an iteration, schedule another release planning meeting and update the release plan

29. Releases • Results of the Release Plan • Release iterative versions often • Get the software into the customer’s environment as soon as possible • Get meaningful feedback from the customer in a timely manner • The longer you wait, the less time you have to fix problems

30. Project Velocity • A measure of how fast work is getting completed • The number of user stories (programming tasks) that were completed during an iteration • Used for subsequent release planning • Update estimates/priorities • Hopefully it’s more meaningful than “lines of code”

31. Project Velocity (cont.) • Used for subsequent iteration planning • Developers “sign-up” for programming tasks equal to the current project velocity • Allows developers to “recover and clean up” after iterations – i.e. they don’t become overworked and stressed • Developers can ask for another user story (programming task) in the event that they finish early • Causes project velocity to increase

32. Project Velocity (cont.) • Project velocity will vary throughout system development • Use release planning and iteration planning to smooth out the ups and downs

33. Iterative Development • Each iteration should be of limited time (1 to 3 weeks?) • Don’t schedule programming tasks in advance (just-in-time planning) • Don’t implement anything that was not planned for a given iteration (never add functionality) • Facilitates dealing with changing user requirements

34. Iteration Planning • Meet prior to each iteration • Map out programming tasks for the iteration • User stories are selected by the customer based on their priorities • Failed acceptance tests [from the previous iteration] are selected

35. Iteration Planning (cont.) • User stories are translated into programming tasks • Tasks are written down on cards which become the detailed iteration plan • Tasks should be 1-3 days “ideal development time” units • Shorter tasks are merged • Longer tasks are split

36. Iteration Planning (cont.) • The developer does the time estimate • There’s a novel approach • Project velocity is used to check the “booking” of the iteration • If over booked, the customer must choose which user stories are to be eliminated (moved to the next iteration) (snow plowing) • If under booked, the customer may add user stories

37. Iteration Planning (cont.) • Don’t fudge your time estimates, no matter how tempting this may be • And don’t let others fudge your time estimates either

38. Moving People Around • One expert in a given area can be disastrous • Moving people from one task to another allows all to become knowledgeable in various areas • Loss of a team member is now manageable • Pair programming (discussed later) eases the pain of cross training people • Avoids productivity loss • Ensures continuity of thought

39. Daily Stand Up Meeting • Communicate problems, solutions, and promote team focus • Avoid long, drawn out meetings that leave people feeling demoralized and stressed out (due to not working on the project) • Specialized meetings can be scheduled as the need arises • Involve only pertainent team members

40. Simplicity • Avoid complexity • Difficult to implement • Difficult to debug • Difficult to maintain • Not always possible, but try anyway • “KISS approach” – Keep It Simple Stupid

41. CRC Cards • Class, Responsibility, and Collaboration • Object-oriented design • Cards represent objects (instances) • Class • Responsibility • Collaborating classes • Cards are easily manipulated (physically) facilitating stepping through the process

42. CRC Cards (cont.) • Easy for many people to become involved in the class design process/verification • Informal walk-through or structured walk-though may be stifling to some people • Criticism • Cards result in lack of written documentation • Solution is to write one card from each class formally and store it away

43. Spike Solution • A simple program used to explore potential solutions • Also known as a prototype • Figure out answers to tough technical questions • Reduce technical risk • Increase user story estimate reliability • This used to scare developers for fear that at spike solution will be made “the solution” through a business/management decision

44. Spike Solution (cont.) • Only addresses the problem at hand • Total disregard to all other issues • Throw-away code

45. Never Add Functionality Early • Keep the system focused and uncluttered • Items you predict might be useful may turn out to be totally unnecessary • Concentrate on today’s tasks • These are the high priority items as specified by the customer

46. Refactor • Learn to “let go” • Perhaps the hardest thing for a software developer to do is to walk away from something they’ve poured their heart into • “Ego-less” programming • This is a key part of XP (and iterative design methodologies in general)

47. Refactor (cont.) • Refactor • Remove redundancy • Eliminate unused functionality • Rejuvenate obsolete designs • Constant refactoring results in • Life cycle time savings • Increased software quality • Design simplicity

48. Include the Customer • Throughout the process • Beginning to end • Develop user stories – it’s their system so who better to describe how it will be used • Prioritize user stories – it’s their system so who better to decide which parts are most important • Release planning – it’s their system so who better to decide which parts to deliver first

49. Include the Customer (cont.) • Throughout the process (cont.) • During iterations – to fill in details [intentionally] left out of user stories • Functional testing – creation of test data and verification of results (on site quality assurance) • Requires full cooperation/buy-in • Trade-off up front “requirements specification” time for “development” time through-out • Don’t settle for a trainee, even though that may seem cost effective – you need a “domain expert”

50. Coding Standards • Define them and stick to them • Provides consistency facilitating team understanding and refactoring • Supports moving people around and pair programming • More on this later