1 / 15

ICSM and Extreme Programming(XP )

ICSM and Extreme Programming(XP ). Tim Wahmhoff. 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

Download Presentation

ICSM and Extreme Programming(XP )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related