eXtreme Programming

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 youre 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. Theyre 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 wont
  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 dont 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 whats 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 Customers 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 isnt 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
• Dont 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)
• Dont 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 hasnt
  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

• Dont set priorities customer does
• Dont assign tasks developers do
• Dont estimate how long stories or tasks will
  take developers do
• Dont 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 ltpage nameaboutgtlt/pag
  egt
• Standard header with ltXMLgt 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 pages
  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 customers
  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

51
XP isnt over

• We will continue to talk about it throughout the
  semester
• Programming style
• Participant roles
• Sharing code
• Project Management
• Adapting the process

52
XIA Resources

• http//axkit.com/
• http//www.servletsuite.com/servlets/xmlflt.htm
• http//cocoon.apache.org/
• http//www.csc.calpoly.edu/dbutler/tutorials/wint
  er96/crc_b/

53
XP Resources

• http//www.xp123.com/xplor/xp9912/index.shtml
• www.xp123.com
• www.junit.org
• www.xprogramming.com
• www.xprogramming.com/Practices/PracOwnership.html
• Java.sun.com/docs/condconv/index.html
• What XHTML conventions?
• JavaDoc
• All I Really need to know about pair programming
  I learned in kindergarten CACM
• www.rational.com/products/whitepapers/350.jsp
• The Craft of Text Editing Finseth, Craig 1991
• Members.aol.com/humansandt/papers/jitmethy/jimethy
  .html
• www.pairprogramming.com
• Xpdeveloper.com
• Home.san.rr.com/deans/lisagui.html
• A Guide to Metaphorical Design. Kim Halskov
  Madsen. CACM 1994