Crystal:
http://alistair.cockburn.us/index.php/Crystal_methodologies_main_foyer
http://proquest.safaribooksonline.com.ezproxy.lib.uh.edu/0201699478/pref01#X2ludGVybmFsX1RvYz94bWxpZD0wMjAxNjk5NDc4L2NoMDE=
Plus
It’s simple. I like the idea of keeping crystal "has the least methodology that could possibly work." In doing it reveals some crucial element of an agile process. And it’s very extensible since it leaves a lot of space for its practitioners. In fact crystal encourages its practitioners to tune it from time to time by adding or removing extra features to or from the process.
The philosophy of crystal is a Zen abstraction from the details of agile software development. By comprehending such an abstraction, one is expected to be able to absorb all kinds of useful new techniques according to the context on the fly.
Minus
I talked about Zen philosophy of crystal. Just like all eastern philosophies, it’s somewhat obscure and uncertain for beginners. In fact Alistair says in "crystal clear" that crystal requires very experienced programmer as leader, and can not tolerate more than 1 beginner in the team. Also, since most of its elements are based on the ease of communication and simplicity of a small team, it’s unable to be scaled to be used in large or distributed teams. And it’s not suitable for life critical applications since it does not encourage a rigid process.
XP:
http://www.extremeprogramming.org
http://www.extremeprogramming.org/lessons.html
Plus
“Going extreme” is an effective way of motivating people who are depressed for long. There is a Chinese saying of “In order to correct a wrong behavior, you have to over adjust yourself.” In fact extreme appears at many cases as a cure of an unpromising process. XP includes a rich bundle of techniques. It’s very technical compared with crystal. I think the essence of XP is to leave all the compromises for uncertainties at the planning game stage, and be extreme in the implementation, with an extensive set of feedback mechanisms to ensure the healthy circulation between the two. The many techniques of XP, like peering programming, backlog, planning game and test driven could be an introductory course for teams on the way to agile. I like Alistair’s idea of classifying developers into level 1, 2, 3. For level 3 developers you don’t need to tell him anything specific. A general description will be enough, and it’s best to let them create their own strategy along the way, which is the very essence of agile. But for beginners, the family of agile practices seems to be not that easy to master. XP provides a comprehensive way for the beginners to start with in agile path.
Minus
Being extreme compromises flexibility, so I think XP’s application potential is some what limited by its extreme standard. However, XP developers do encourage partially applying XP in a project. Also it takes a lot commitment and courage for developers, especially none-agile developers to try XP practices.
Context Driven Testing:
Plus
The context driven testing is an agile revolution for testers, not developers. But I think it’s also beneficial for testers to learn something about it, so they can improve their test driven development and better their relationship with testersJ. Context driven testing rethinks testing as an evolving complex process, which has to be dealt according to the context of it. It avoids following procedures, focuses on solving problems. It encourages a positive relationship between testers and developers. For developers I think their test for their own software is kind of context driven in the first place, for not many of them do the testing often, and even few of them will stick to ceremonial “best” testing methodologies. But still developers can utilize some techniques here to gain understanding of others’ system, which is important in agile practices, and try to treat testers as consultants, or promote this relationship. Also, I think it gives us a clear idea that acceptance test or functional test in some agile practices is an evolving process just like coding, where good enough solution is also needed.
Minus
Context driven testing requires the testers to figure out what to do based on the context. This not only requires constant thinking, but also a lot of experience, for you have to know the assumptions and consequences of your options.
Scrum:
Plus
Scrum seems like to be the opposite of CMMI. Yet it proves to be a successful management style in projects with a high degree of uncertainty, like most software projects. It maximizes communication, collaboration in the team, and minimizes distraction.
Minus
Scrum encourages “all at once”, which limits the scope of the projects and the number of team members as well. Also in interface clean projects, like OO development, we can partition the projects to smaller pieces and have a separate scrum team for every piece of work. It’s not going to work if you have people who is not committed or not experienced on the team. But when everyone is highly motivated and committed, they may keep pushing some real limits since in scrum team the management tends to impose as little restrain on team members as possible.
