ICSM and Extreme Programming(XP )

1. ICSM and Extreme Programming(XP) Tim Wahmhoff

2. Extreme Programming • Agile process • 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

3. Lifecycle

4. Similarities • Emphasis on customer satisfaction • 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.

5. 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.

6. 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

7. 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

8. 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

9. 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

10. 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!

11. 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

12. 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

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

14. 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.

15. 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