实践敏捷开发的困惑

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

---

1、完整团队

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

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

---

2、计划游戏

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


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

---

3、客户测试

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


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

---

5、结对编程

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


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

---

6、测试驱动开发

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

7、改进设计

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


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

---

8、持续集成

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


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

---

9、集体代码所有权

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

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

---

很想听听大家的意见。

评论

7 楼 dongbin 2007-06-14  

道可道，非常道。所有文字上的东西都是教条，用了才明白。

6 楼 xly_971223 2007-06-14  

要理论联系实际 不能完全的教条主义

5 楼 basicbest 2007-06-14  

关于PP似乎讨论过很多，你可以翻以前的帖子看看，要注意每个人的不同观点，因为没有人是完全正确的，必须要放到具体的场景中才有适合或者不适合的说法。
假设一个极端的情况，即在一个没有任何斗志的团队中，PP我觉得是不可能实现的，但出现PP聊天的情况就非常高，呵呵。
所以请记住o6z的建议：实际操作

4 楼 neora 2007-06-13  

ozzzzzz 写道

有些事情我觉得还是要实际操作一下才能有深入的理解。
比如我们这些年纪大的人，其实对pp都会有感觉，因为我们学的时候虽然都不知道pp，但是却不得不被迫的去pp。

我本人对PP还是很有感觉的，充分认为PP对无论是对代码还是程序员都很有好处。但我在团队里尝试过一段时间PP，大家好像都不太积极........

3 楼 ozzzzzz 2007-06-13  

neora 写道

ozzzzzz 写道

1.项目的管理者可以负责维护进度表。而实际上每日的例会之类的站立会议，都会明确目前的项目进度等关键管理参数。同时请注意，这些表格和图示一定是特别容易被理解的，从这个意义上说一定也需要特别容易被维护的。
2.这其实才是迭代计划显露其威力的场景。也仅仅是小步伐的迭代才可能在最即时的计划中满足突然产生的关键需求，也仅仅是在小步中才能够不断的发现关键性bug并进行及时维护。
3.领导一句话就改变了需求，这实际上就是在说领导改变了需求的验收标准，而这个标准实际上就是领导写的客户测试，只不过这个时候需要你把这个测试表达为具体的代码。
5.一般使用过pp的人绝大多数会喜欢pp，不过pp的需要良好的环境进行保证，比如大桌子和舒服的椅子等等这些。
6.7。对我觉得有时候完善的测试比代码难写，不过绝大多数情况下，完善是一个过程，而不是一步到达的目标。也就是说不仅仅你的代码需要在迭代中增量进行，测试也需要这样做。问题的关键在于修改测试，其实也是认识需求和设计思路的一个部分，化点时间精力在这个上面，我觉得很值得。
8.可能的缺陷如果没有具体的测试予以证明，就不是问题。持续集成的优势就在于可以持续的将你的代码集成进去，同时也可以持续的将你的测试集成进去。
9.任何时候学习都需要付出精力，实际上代码集体所有是集体选择持续性review的一个部分。当然对于所有权的问题，有各种不同的考虑，xp只不过是其中的一种适合其团队理念的选择。
5

非常感谢ozzzzzz的精心讲解。我需要在实践中逐步消化和理解。

有些事情我觉得还是要实际操作一下才能有深入的理解。
比如我们这些年纪大的人，其实对pp都会有感觉，因为我们学的时候虽然都不知道pp，但是却不得不被迫的去pp。

2 楼 neora 2007-06-13  

ozzzzzz 写道

1.项目的管理者可以负责维护进度表。而实际上每日的例会之类的站立会议，都会明确目前的项目进度等关键管理参数。同时请注意，这些表格和图示一定是特别容易被理解的，从这个意义上说一定也需要特别容易被维护的。
2.这其实才是迭代计划显露其威力的场景。也仅仅是小步伐的迭代才可能在最即时的计划中满足突然产生的关键需求，也仅仅是在小步中才能够不断的发现关键性bug并进行及时维护。
3.领导一句话就改变了需求，这实际上就是在说领导改变了需求的验收标准，而这个标准实际上就是领导写的客户测试，只不过这个时候需要你把这个测试表达为具体的代码。
5.一般使用过pp的人绝大多数会喜欢pp，不过pp的需要良好的环境进行保证，比如大桌子和舒服的椅子等等这些。
6.7。对我觉得有时候完善的测试比代码难写，不过绝大多数情况下，完善是一个过程，而不是一步到达的目标。也就是说不仅仅你的代码需要在迭代中增量进行，测试也需要这样做。问题的关键在于修改测试，其实也是认识需求和设计思路的一个部分，化点时间精力在这个上面，我觉得很值得。
8.可能的缺陷如果没有具体的测试予以证明，就不是问题。持续集成的优势就在于可以持续的将你的代码集成进去，同时也可以持续的将你的测试集成进去。
9.任何时候学习都需要付出精力，实际上代码集体所有是集体选择持续性review的一个部分。当然对于所有权的问题，有各种不同的考虑，xp只不过是其中的一种适合其团队理念的选择。
5

非常感谢ozzzzzz的精心讲解。我需要在实践中逐步消化和理解。

1 楼 ozzzzzz 2007-06-13  

1.项目的管理者可以负责维护进度表。而实际上每日的例会之类的站立会议，都会明确目前的项目进度等关键管理参数。同时请注意，这些表格和图示一定是特别容易被理解的，从这个意义上说一定也需要特别容易被维护的。
2.这其实才是迭代计划显露其威力的场景。也仅仅是小步伐的迭代才可能在最即时的计划中满足突然产生的关键需求，也仅仅是在小步中才能够不断的发现关键性bug并进行及时维护。
3.领导一句话就改变了需求，这实际上就是在说领导改变了需求的验收标准，而这个标准实际上就是领导写的客户测试，只不过这个时候需要你把这个测试表达为具体的代码。
5.一般使用过pp的人绝大多数会喜欢pp，不过pp的需要良好的环境进行保证，比如大桌子和舒服的椅子等等这些。
6.7。对我觉得有时候完善的测试比代码难写，不过绝大多数情况下，完善是一个过程，而不是一步到达的目标。也就是说不仅仅你的代码需要在迭代中增量进行，测试也需要这样做。问题的关键在于修改测试，其实也是认识需求和设计思路的一个部分，化点时间精力在这个上面，我觉得很值得。
8.可能的缺陷如果没有具体的测试予以证明，就不是问题。持续集成的优势就在于可以持续的将你的代码集成进去，同时也可以持续的将你的测试集成进去。
9.任何时候学习都需要付出精力，实际上代码集体所有是集体选择持续性review的一个部分。当然对于所有权的问题，有各种不同的考虑，xp只不过是其中的一种适合其团队理念的选择。
5