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 4 th …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

51. Unit Test Create the unit test [plan] prior to creating the code –Aids in describing exactly what the software unit must do –Makes requirements very specific –Provides immediate feedback (the tests either pass or fail) –Provides a definite finish point (when all the tests pass)

52. Unit Test (cont.) Designs are then driven by the desire of the customer to have all tests pass –Remember – the customer is also involved in designing the tests (the functionality to be tested) as well as performance of the testing The resulting code does exactly what the tests specify…no more, no less –Better make sure the tests are all encompassing

53. Pair Programming Two people work together at a single computer –Driver/backseat driver Two people working together on one task will be more productive than two people working on separate tasks –Very counter intuitive

54. Pair Programming (cont.) Reason – Quality! –Higher quality now results in lower [more costly] maintenance later Two people physically sit at one computer –One thinks tactically – e.g. doing the current class method –One think strategically – e.g. envisioning how current class method interacts with other methods

55. Pair Programming (cont.) Very awkward at first… …but it beats talking to yourself

56. Sequential Integration Integration is the act of taking one task and making it work with the rest of the system Classically, this is done simultaneously (by all developers) when all individual tasks are completed –Or by a development team trained at such tasks

57. Sequential Integration (cont.) XP specifies that each developer (pair?) should integrate their task into the system –This is done one developer (pair?) at a time (sequentially) The mechanics of this is some sort of source code repository with locking method that allows only one developer access at a time –MicroSoft™ has a product called SourceSafe for such a system

58. Integrate Often Integrating often should shorten the “lock-out” time from the repository Reduces the complexity of the integration task Makes latest code available to all developers Identifies incompatibilities early (before it’s too late)

59. Collective Code Ownership Everyone has full access to all code –Not allowed to label something as “my code” –Anyone can fix any portion of the code –Anyone can break any portion of the code –Hopefully, since designs are simple, someone won’t misconstrue working code for a bug Unit testing plays an influential role here too

60. Optimize Last Don’t guess what the system bottleneck will be –Measure performance when the system is complete –Address performance when the bottlenecks are well known

61. No Overtime Don’t ask (make?) developers to work overtime –Call a release planning meeting to change project scope or timing –Over worked developers make bad decisions leading to low quality software… Don’t add people to the team without consulting existing developers

62. Unit Test Frameworks We’ve discussed this previously A test suite for performing regression testing automatically –JUnit –others

63. Acceptance Tests Basically, when the software passes all of the customer defined functional tests, you’re done

64. Summary Extreme Programming (and other agile methods) suggests some software development practices and allows you to pick and choose the ones that work best for your team Most of all, it stresses –Teamwork –Communication