eXtreme Programming & (X)IA

1. eXtreme Programming & (X)IA • Methodology Overview • XP Review • XP + IA = XIA • User Stories • Class Work: User Stories • Class Work: Navigation Start up • Topics selection finalized & dated

2. IA Methodology Planning Analysis Design Verification Construction Maintenance

3. Other Methodologies • Mostly from Software Development • Waterfall Development Model • Life-cycle(s) • Structured (Programming) Methodology • AD/Cycle and CASE • User-Centered System Design • Agile Development • Rapid Application Development • Object-Oriented Development • Many more

4. A “New” Methodology – XP • eXtreme Programming • Combination of many methods • Formalized around 1999 • Takes good development methods to the extreme • Pair programming and code reviews • Testing all the time in small units by both developers and users • Constant re-design for simplicity and modularity (refactoring) • Architecture of system always kept in mind and changed if needed • Integration and testing throughout the process • Short goals help iterate and improve the process

5. Is XP Just Common Sense? • Methods improve over time • Small steps to make sure you’re on the right track (not as much work later, less bugs) • Focusing on the process gets you thinking about the process • Find the right combination of methods for each project or product • Different organizations may use more appropriate methods or emphasize other methods • Designers and developers can improve both methods and the product quickly • Customers and users can both observe and advise in the product design and development (agreements on time & resources) • Requires more commitment to apply XP, often why other methods are chosen. They’re easier, but not better.

6. XP… • “is a lightweight, efficient, low-risk, flexible, predictable, scientific and fun way to develop software” p xvii • Uses and overall plan that evolves • Allows for schedule flexibility • Involves customers more than ever by helping to design tests and understanding design decisions • Stresses short-term results with long-term interests

7. XP • Long projects are broken into 1-3 week projects: • Customers pick the features to be added • Programmers add the features so they are completely ready to be deployed • Programmers and customers write and maintain automated tests to demonstrate these features • Programmers evolve the design of the system to gracefully support all the features in the system

8. Careful Planning • The team must choose the best possible features to implement • The team must react as positively as possible to the inevitable setbacks • Team members must not overcommit, or they will slow down • The team must not undercommit or customers won’t get value for their money • Team members must figure out clearly where they are and report this accurately, so that everyone can adjust their plans accordingly. • Martinfowler.com

9. Plan for: • Ensure that the most important thing • Coordinate with others • Understand unexpected occurrences in light of 1 & 2 • Understand how far you are in the plan • Create a visible, transparent plan • “Plans are about figuring out a likely course of events and the consequences of the inevitable changes.” p4 Planning XP • Plans don’t control events • Plan must be kept realistic - continually updated

10. Customer Bill of Rights • You have the right to an overall plan, to know what can be accomplished, when, and at what cost. • You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. • You have the right to change your mind, to substitute functionality, and to change priorities. • You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can even cancel at any time and be left with a useful working system reflecting investment to date.

11. Programmer Bill of Rights • You have the right to know what is needed, via clear requirement declarations, with clear declarations of priority. • Produce quality work at all times • Ask and receive help from peers, managers and customers • Make and update your own estimates • The right to accept your responsibilities and instead of having them assigned to you. • (You have the right to say how long each story will take you to implement, and to revise estimates given experience. • You have the right to identify risky stories, to have them given higher priority, and to experiment to reduce risk. • You have the right to produce quality work at all times. you have the right to peace, fun, and productive and enjoyable work. )

12. Power • Business people making business decisions • Dates • Scope • Priority • Technical people … • Estimates • Revising Estimates • Customer • Domain of application • How app provides value in domain • Determined to deliver value regularly (too little rather than nothing) • Make decisions about what’s needed now and also later • Accept responsibility

13. Story • A story represents a feature a customer wants. • Describes great new system. • Small and simple. • Should take a few days or a week to implement

14. Variables for XP Dev • Cost • People • Tools • Time & Scope • Sliding, opposing scales • Quality • External – Customer’s view • Internal – Design, Tests (Refactoring)

15. Release Planning • Customer • Defines the user stories • Decide what business value the stories have • Decides what stories to build upon in this release • Developers • Estimate how long to build each story • Warn the customer about significant technical risks • Measure team progress to provide customer with an overall budget p40 • Release Plan is totally plastic • Plan ahead just 1 or 2 iterations • Build just enough infrastructure to complete stories

16. Stories and User Scenarios • Describe a feature and how the user would use it. • Description should be in context and understandable to a user. • Shorter is better • A story is a way for developers and users to explore a feature • Must provide value to the users • A story isn’t done until the user and developer agree it is useful • Stories should be independent of each other • Each story should be testable

17. Story Properties • Estimable time to complete • Ideal time to complete • Assemble in ranked order • Users determine business value • Divide up stories into manageable release schedules • Not completed until tested • Don’t let the dates slip, resize and refactor to keep to a deliverable schedule

18. Story and Planning Meeting • Review stories in order • Record tasks to be done for each story with agreement on tasks • Add any technical tasks dependent on stories • Developers (pairs) choose and estimate story development times • Stories are deferred by choice or by schedule sizing • Agree on closure of previous stories and their tests • Stand up meetings • Use visible, understandable project plan graphs and charts

19. XP Challenges • Missing estimates • Users having trouble making decisions • Testing failures • Procedural inefficiencies • Daily build issues • Users not signing off on deliverables

20. XIA • More emphasis on interface that systems internals • Less infrastructure development • Test cases and stories can be very granular and may be combined into scenarios • Set of technologies more limited • Goals beyond functionality for product (communication/collaboration)

21. XIA Design Specification • User Profiles • Technology Implications • Site functionality • Site contents • Site map • Site navigation • Site content sections • Test cases • Scenarios • Timeline and Budget • Roles

22. XIA Process • Stories • Deliverables • Planning and Estimating • Preparing for Development • Development • Testing • Iterate

23. XIA Stories • Select images for Products pages • Collect content for an About Us page • Select navigation features for Home Page • Specify Search requirements • Install and configure servers • Decide on IDE and tools • Install and configure version control • Select color palette • Design CSS template • Layout Wireframe for page type(s)

24. XP in Practice • A spike is a quick experiment to “drive deep into the question” p 10 • Instead of guessing how long some code will take, you make a spike of working code to get a better estimate. • First releases are made to be tweaked and help establish confirmation of total design ideas. • Small iterations are best. How many per project timeline? • Intense Communication – Customer involvement

25. Lessons Learned • Test the hard stuff • Make sure customer writes acceptance tests • Reduce dependencies when you test (isolation, spoof/no-op modules) • Stick to your plan (no acceleration) • Change plans only when you have a story and an estimate • Even small projects needs a process • Keep process light (least possible) • Story writing is chaotic (and variable) • Don’t anticipate infrastructure (over design) • Tests eliminate fear of change (for code) • Back into solutions from initial premises • Split functionality out of difficult tests

26. Summary Table

27. XP Explored • Customer Decides • Scope – what system does • Priority – what is most important • Composition of releases – what is in a release to make it useful • Dates of releases • Do Customers want to work this hard?

28. Developers Decide • Estimated time – per feature • Technical consequences • Process – how team will work • Detailed schedule – when parts will be completed for an iteration (integration and test)

29. The Spec is the Code • Code is testable, shows system • Tests are retested • Tests are repeatable (match to stories) • Tests help document the code – show functionality working to match with story

30. Best Practices • Coding • Code & Design Simply • Refactor Mercilessly • Develop Coding standards • Develop a common vocabulary • Developer • Adopt test-driven development • Pair programming • Adopt collective code ownership • Integrate continually • Business • Customer on the team • Schedule & plan • Release regularly • Work at a sustainable pace Extreme Programming Pocket Guide, pp 15-44

31. Martin Fowlers’ Refactoring book • “the process of improving the design of code without affecting its external behavior. We refactor so code is kept as simple as possible, ready for any change that comes along.” p 23 • You need: • Original code • Unit tests (to make sure external behavior hasn’t changed) • A way to identify things to improve • A set of refactoring rules we know how to apply • A process to guide us • www.refactoring.com • Pragmatic Programmer • Programming Pearls

32. Release Planning • Customer sorts stories by value • Must have • Should have • Could have • Programmers declare the velocity – how many story points the customer should expect per fixed-length iteration. • Customer chooses scope – the stories for the next release. First release should show system end to end, even if at a minimal level. P 103

33. Roles: the Tracker • The tracker reminds the team how many story points were completed last iteration. Use to predict next. • Customer selects unfinished stories for iteration time • Tracker reminds each developer how many days per task last time. • Developers choose tasks to fit time.

34. Roles: the Manager • Don’t set priorities – customer does • Don’t assign tasks – developers do • Don’t estimate how long stories or tasks will take – developers do • Don’t dictate schedules • Face outside parties (funders) • Form the team • Obtain resources • Host meetings • Host celebrations • Coach

35. XP for Web Projects • Roles are more specific • XML • HTTPUnit for XP-like testing • Tidy • JUnit and JTidy • Testing with a validating parser is one kind of XP test

36. Laws of XML Web Dev • No formatted HTML should be generated anywhere other than in the XSLT style sheet. • Any code that retrieves data from databases or web services should always mark up that date using semantically meaningful XML tags rather than formatted HTML. • Use standard (pre-existing) schemas and DTDs if possible. • Keep content and format seperated. • Develop code for re-use • Use null XML files to test functionality.

37. XP Web • Assign each page a name according to a formatting standard • Make a blank template page for each with standard header information. • Root elements with attributes corresponding to its name in the site map <page name=“about”>…</page> • Standard header with <XML> tags. • Create an XML site map • Create an XSLT style sheet with templates for formatting the various content types • Add nav templates to the XSLT style sheet that read the site map and display menus and links. P 103-105 • XSLTUnit

38. XP = XIA? • Can XP be applied for IA projects? • Test cases will be simpler to design, explain and test • Lack of (comparable) flexibility in Web protocols and technologies may restrict some designs • Lightweight nature of development in typical IA projects enables more flexibility and iteration in design • New systems easier to attempt with new methods

39. XIA - eXtreme Information Architecture • Applying XP methods and approach to understanding users and developing information systems • Applicable to fast prototyping, verification and iterative design at individual and organizational levels

40. XIA • As much interaction with customers as possible • Different customers for each goal • Tests to continually confirm quality and scope of design progress • Change early and adapt according to: • Time • Resources • Functionality • Communication • Class listserv? • Email • Server?

41. XIA from Web XP • Small iterations – 2 weeks • Iteration strategy (meeting) • Will this story generate traffic? • New revenue of increase existing revenue? • Change patterns of behavior? • Help reduce costs? • Iteration planning (meeting) • What tasks needed to complete story? • List of stories to complete • Task selection • Plan for width over depth • Make customer contribution & involvement easy • Track tasks

42. XIA for IA2 • Small units designed • Tests developed for each page or subset of page’s functionality and recorded • Content • Context • Function • Pairs develop functionality • In and out of class • Rotating pairs • Continual integration into overall design • Systems Analysis and Design

43. XIA 2 • User Stories • Written in language understandable to customer • Stories should provide something tangible to customer • Stories should take between 1 and 2 weeks to complete • Stories must be testable • Project Velocity • Estimating • Adjusting • Measuring with Iterations

44. XIA 3 • Team • Experience • Diversity • Skills Transfer (pair work) • Management • Resources • Firewall to outside • Communications • Meetings • Design • Simple, elegant code • Cards for design sessions • Naming and code conventions • Prototype to avoid long risk

45. XIA 4 • Coding • Work with customer • Code to standards • Code unit test first • Optimize later • ABI - Always Be Integrating

46. Practical Guide to XP • Refactoring Events • Beginning of task to make room for code • End of task to integrate code as simple and clear as possible (Jeffries 2001A) • Big methodologies often have long timelines before the customers can even see part of the application. • Sometimes the methods cause coding to not begin until very late into the project.

47. Index Cards • Use an index card as the “Vision Card” for the system design. No more, no less. • Users stories on one side of card • Smallest story possible to describe customer’s use of the system • Use Cases • Use case name • Unique case ID • Primary actors (customer type) • Secondary actors • Description • Trigger – the customer selects an item from the catalog • Pre-conditions • Flow of events • Tests on other side of User Story card with customers approval (understanding) of the test • Get user stories from interviews (Critical Incident theory applied)

48. User Stories • Rank • Number of stories based on quantity and complexity of story • Each story has a number of “Story points” for complexity • Dividing up the ranking is the main step in release planning • Story points are matched with development resource points (time and developers) • Testing should be part of the release too • Testing give confidence that progress is being made • Testing leads to increased quality of each release

49. Agile Modeling • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan (Agile 2001)

50. Agile Modeling Values • Communication – among everyone including customers • Honesty – in estimates, with problems and slips • Simplicity – the simplest thing that can be done for models • Feedback – constantly • Courage – for the above and to rework if need be • Humility – everyone has good ideas and can make mistakes