ICSM and Extreme Programming(XP) Tim Wahmhoff

Extreme Programming Agile process Rapid development Embrace change Less focus on documentation, more on coding Rapid development Working version to the customer as quickly as possible Embrace change Short development cycles Plan for change rather than attempt to establish stable requirements

Lifecycle

Similarities Emphasis on customer satisfaction User Stories Testing XP –Get to know the business process ICSM- WikiWinWin Conditions User Stories Combine requirements and use cases Testing Both emphasize unit tests and acceptance testing Requirement updates Similarity is both expect requirements to update and change throughout the cycle. Difference is that most of XP changes come during development of the system.

Differences I consider ICSM advantage Design with whole system in mind Better system architecture Documentation Development is slower, but transition is easier Doesn’t require experts Heavyweight generally better for less experienced developers.

Differences (Advantage XP) Early development The sooner you give the client something to play with the sooner you can start getting feedback Improves ability to actually assess how much work a requirement is going to be and keep client updated. Short development iterations Not actually prohibited by ICSM in 577ab Pair programming Again, although not prohibited in any way by ICSM, I think its incorporation into the 577ab development process could improve productivity

What is pair programming? Two programmers working side by side Design, Code, Test as a team Driver Controls keyboard and mouse Actually does the coding Navigator Provides strategic planning Looks for defects

When to use it Novice-Novice attacking complex problem Experiment with repeat programming Greatest benefit when both are inexperienced with implementing the feature Implementation of simple or familiar problems decreases the REAP

How and When for 577ab When team encounters non-trivial, unfamiliar feature When working on parts of the system that are critical to implementation of other parts of the system Training a novice One expert in a large section of the project Expert is the Driver Novice is the Navigator

Advantages of using pair programming Couples programming and debugging/code review Code reviews are more effective Know what you are reviewing Better designed and more extensible code Forces communication with regards to the code More Fun!

How 577ab would change Lab session to teach the basics of pair programming Assign a fairly simple problem to complete as a pair Driver vs. Navigator roles In the case of an unsettled dispute default to the driver, argument decreases group productivity Prior to prototyping if possible

Potential Difficulties for 577ab Overlapping Free Time Programmers strongly opposed to working in pairs Not an anticipated problem for all, but some personality types can clash Collocation Requires sharing a computer

Short Development Iterations Reasons IKIWISI Need client feedback "Optimism is an occupational hazard of programming, feedback is the treatment.” MuSCoW updates still satisfice.

How to change 577ab to incorporate No change in the ICSM, this is already allowed. Incorporate into weekly client meetings No new reports Require client meeting notes to contain product feedback as well as what was demonstrated.

Conclusions ICSM could improve even more by incorporating some the practices of Extreme Programming Pair programming Better designed, more reusable code Essential features created faster Short iteration cycles More customer feedback