请教熟悉敏捷开发的兄弟
　

---

我原先没有了解过敏捷方法，而是更多地去关注RUP和CMM。
最近在一份报告中看到对于敏捷方法的评论，其中产生了一些迷惑：
1、敏捷方法强调最少化的文档，甚至认为“好的代码就是你所需要的所有文档”。是这样吗？
2、敏捷方法试图减少了最广泛的user的沟通，例如希望通过“official user”作为桥梁与其他相关使用者沟通。是这样吗？
3、敏捷方法强调淡化过程和工具。是这样吗？
4、敏捷方法的核心就在于refactoring，希望一切的change都能通过refactoring解决。是这样吗？

希望各位兄弟能为我解惑。

 回复: 请教熟悉敏捷开发的兄弟
　

---

我理解xp与rup，cmm是两个极端（都是很好的），而经验就是如何在这两个极端中根据项目、开发小组等情况把握平衡点，

1、敏捷方法强调最少化的文档，甚至认为“好的代码就是你所需要的所有文档”。是这样吗？

是，如果不能用一句话把函数说明白，把这个函数分解，直到一句话能把它说明白，而此时函数名就说明了一切。（当然不可能用远这样，还是要写文档，特别是中国人很难用简单的英语来起函数名称）

2、敏捷方法试图减少了最广泛的user的沟通，例如希望通过“official user”作为桥梁与其他相关使用者沟通。是这样吗？

错了，敏捷方法是最注重用户了，希望有专门的用户从始至终的跟在开发小组旁边，随时解决问题

3、敏捷方法强调淡化过程和工具。是这样吗？

敏捷是一种新的方法，当然原来用的过程和工具都不能用了，但是现在地pair工具，refactoring工具都在研制中，会有一套新的工具，如果你在新的方法下使用旧工具，岂不是...!@#$%^&

4、敏捷方法的核心就在于refactoring，希望一切的change都能通过refactoring解决。是这样吗？

不只是refactoring了，refactoring也不只是解决change了，建议阅读refactoring这本书后再看design pattern。
　

敏捷开发的一些办法，如强调程序员编写测试代码， 适用于web开发或组件
开发， 对GUI开发程序，就必要性不大，程序本身就是测试代码
象接对开发，适用于代码量少，但技术质量要求较高的程序，象底层API接口， 通用开发平台等， 一般商业项目， 容易造成项目工期长，内部关系紧张，
还有定期集中build。适用于基于模块架构的项目。