对敏捷/极限开发方法的一点思考

    在人月神话的BLOG中看到了〈 不管理的软件开发项目管理-转载 〉一文，我不同意其中的一些观点。看来不少人对极限编程等敏捷方法存在一些误解，例如结对编程并不是说两个人在某段时间内完成一个功能点，而应该是两个人在某段时间内完成两个甚至两个以上功能点。

    项目管理并不只是软件开发项目管理，而是在各行业的项目管理基础上综合提炼出来的学科，并且软件工程比起建筑工程等领域算是比较新的，如何把项目管理的经验和软件开发的特点结合起来也是比较新的学科——IT项目管理。

    项目管理实在是综合的学科，至少官方声称PM由九个知识领域构成，每个知识领域的作用在不同的项目中都发挥着不同的作用，不可以忽视更不可以偏废。象成为一个优秀的军事指挥官那样，想成为一个好的项目经理确实不容易，挺累的。

    不同的项目，不同的公司，不同的客户，不同的团队（程序员水平的差异），管理的具体做法都会有所不同。所以不能够说那一种项目管理方法一定就是好的，另一种方法就一定不好，任何一种项目管理的方法都不是万能良药包治百病。每个项目所关心的重点要素不一样，每种方法适用的范围也不一样，只有哪一种方法更适合项目而已。与兵法一样，项目管理既有一定之规，又必须灵活运用。

    就象问Oracle和MS Server那个更好，Linux和Windows那个更好？每个人可以有不同的偏爱，但如果想比较好的回答这个问题，必须解答一大套话，因为客观地评价好和坏是不容易的，只有在一个具体的事情中，我们可以回答那一种产品/技术更合适。

    敏捷和极限方法中并没有认为程序员是机器，相反，我认为她关心了作为“人”的程序员的一些在以前的方法中没有被关注的很多特性。这个方法的文献中不写出其他的方法的成功之处，是因为那些经验和知识其他的文献中已经充分表达了，没有必要在这个范畴内再论述了。

        这篇文章中的主要观点都涉及到管理学范畴（不管理的软件开发项目管理-转载），比如企业文化问题和如何成为合格的领导者这些问题。这些问题是任何管理领域中（不只是软件开发）都要关注的，是成功项目管理的前提之一。

   敏捷和极限方法提醒我们注意到以前没有的要素和方法，拓展了我们的思路，是一个不错的方法，非常值得关注和学习。即使在项目中不能够完全按照敏捷/极限的方法开发，也能够让我们在项目中关注那些要素——例如注重交流和测试等，从而改进我们的项目管理。

       在这里感谢人月神话的转载引发了我的思考。