实践敏捷开发的困惑

正在学习和实践敏捷开发，但遇到了一些困难，产生了一些困惑，想听听大家的意见。

1、完整团队

XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

困惑：

在小型的软件公司，一个团队的工作往往不局限于单一的项目。开发人员需要同时交叉管理3个甚至更多的软件和项目。这么说，墙上得贴好多张进度图表，更新这些图表一定得花费不少精力吧，大家都忙于自己手头的任务，谁来维护墙上这些复杂图表内容的更新呢？

2、计划游戏

计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

困惑：

持续的计划非常容易被打破，比如一个紧急报告来的客户需求需要开发，或者一个刚刚发现的BUG必须马上修正----这些当然都是计划外的，于是计划被破坏了。事实上这种情况不可避免。如果每次的计划都被破坏，是不是会失去计划的效果，让成员产生挫败感呢？

3、客户测试

作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

困惑：

小型的软件公司所服务的客户项目往往在100万RMB一下。与银行不同，这些项目所属的客户单位通常缺少专业的项目配合人员，他们没有（或者不愿意，不习惯）花费时间和精力去配合你的测试。他们的领导更不可能配合你去做这样的工作－－这些人恰恰是验收的决定因素。即便客户的配合人员完成了测试，领导的一句话就可能改变需求。怎么解决这个矛盾呢？

5、结对编程

所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

困惑：

任何规模的软件公司都非常渴望“结对编程”可能带来的效益。但“结对编程”似乎更难在工作内容相对繁杂的任务环境中实施。而且，做为开发人员的你喜欢结队吗？我想听听你的看法。

6、测试驱动开发

编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7、改进设计

随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

困惑：

TDD真的不错，改进设计和重构也相当必要。而有时改进设计和重构需要更改接口(Interface)甚至改动很多局部结构，这事测试脚本就必须重写，原来写的测试脚本全部作废了。有时完善的测试脚本比代码本身更难写。

8、持续集成

团队总是使系统完整地被集成。一个人拆入（Checkin）后，其它所有人责任代码集成。

困惑：

如果一个开发人员Checkin了一段可以测试通过的代码，尽管能返回正确的结果，但其内部的实现可能存在很大缺陷。这个缺陷也被“持续集成“进去了，怎么发现呢？可能过了很久才被别人偶然发现，也可能最终部署到用户那里了才被发现（比如并发上去了）。

9、集体代码所有权

任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

困惑：

立即接手自己没参与过模块代码，是否会遇到较陡峭的学习曲线，不得不花费一定的时间才能适应？

很想听听大家的意见。