Clash of the Software Development Process Methodologies

 

ses"Embrace Change." This is the subtitle of Kent Beck's book, Extreme Programming Explained, as well as an apt summary of the sticking point in our organization's recent clash of the process methodologies. Stated simply, there was little motivation (read: great resistance in some quarters, including mine) to embrace change when there was no overwhelming evidence that anything was wrong.

Our team typically uses a hybrid methodology that is pretty traditional and generally follows the guidelines set out in McConnell's tome, Software Project Survival Guide. Requirements are documented and finalized up front--this being key to expectation setting, contractual or otherwise. While test plans and test cases are developed during the planning phase, the bulk of testing doesn't start until after coding is complete.

Extreme Programming, or XP, turns those plus many other traditional approaches on their heads. In case you haven't used it or read about it, XP is--in short--an agile methodology consisting of a collection of practices that rely heavily on short cycles, flexibility and constant client communication. Notably, XP does not rely on written documentation, preferring oral communication, tests and source code as system documents.

For the past couple years, our manager of software engineering has occasionally forwarded me links to articles on XP…

Please log in or sign up below to read the rest of the article.