(1) - 反馈

最近很多人都在体验VS2010，我忙着很多事，没有去体验。但我了解到其中一点，VS2010为敏捷开发提供了更多的支持。以前我所认为的敏捷开发，只有在理想公司，理想团队才可能开展，现在微软通过IDE，将敏捷的思想进行大范围的普及，让敏捷更加的深入人心。

敏捷宣言中只有简短的几句话，但是能真正做到不是那么容易。

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Practices of an Agile Developer一书中，对敏捷开发做了一个精辟的概括：

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

今天我就谈谈“反馈”。

最近我在做一个项目，单枪匹马，只有我一个人，看上去一点都不敏捷对吗？敏捷团队通常是一些小型团队，但是小到一个人，也不好。理想的团队应该是10人左右。每天早上的站立式会议上，我都是自报进度，对于遇到的困难，别人也很难给出意见，因为他们都没有参与进来。但是有一点，他们是这个项目未来的客户，站立式会议上，我可以听到作为客户的反馈。

这个项目是一个基于VMWare Esx的虚拟化管理平台，我有一个大客户，就是服务器管理员C。和C讨论过系统的需求和基本实现后，我开始将任务分成了以下几个部分：

1. VMWare Esx API的封装。

2. 分布式Controller, Agent控制系统。

3. 数据库设计

4. Web界面

整个过程计划在一周的时间完成，并且能够上线，提供一个基本可用的版本。看上去几乎是不可完成的任务，于是我开始了高效的Coding。过程中，我不断的收到了来自“用户”的反馈：

1. “可以暂时使用原有系统的数据库系统，用户才不关心他的数据存在哪里。”

于是，“数据库设计”暂时砍掉。

2. “我最关心的是系统最基本的申请和释放功能，至于其他的细节问题，我可以暂时不关心。”

于是，“分布式Controller, Agent控制系统。”也暂时被砍掉了。不过，这个反馈来的太晚，我已经花费了一天的时间实现和调试。

3. “这个数据列表我希望是横着排的。”

在我把数据列表做好，自我感觉很好给C演示时，他表示希望列表是横着排列的。而这时我已经在这个竖的列表花费了不少时间。

4. “也许，我们可以考虑使用另外一种方式实现。”

听到这句崩溃的话时，已经周五了。这是我将系统实现的差不多的时候，找C聊天，C蹦出来的一句话。经过分析，确实可行，亡羊补牢，为时未晚。新的方案一定程度上还是对之前方案的简化，并且更加可行。

…

在不断的用户反馈中，不断的纠正了我的方向，才使得我能够在一周的时间内完成。

有时，

我们关注的，用户不一定关注。

我们认为重要的，用户不一定觉得重要。

我们认为很酷的，用户不一定想要。

我们认为没所谓的，用户反而觉得非常重要！

所以，做用户最想要的软件，关注用户的反馈，如果可能，让用户也加入到团队的开发中来。这就是敏捷宣言中所说的：

Customer collaboration over contract negotiation（客户协作胜过合同谈判）

(2) - 持续集成

这篇，我只谈“持续集成”。

有人说敏捷必须有持续集成，有人说持续集成就是敏捷。如果你还不了解持续集成，赶紧看看《持续集成》第二版的中译本。

持续集成的最大益处是降低风险，及时发现代码的缺陷，并让代码保持随时可用的状态。

如果不使用持续集成，会出现什么问题呢?

1. 到最后的集成时，会花费大量的时间，而且可能有很多BUG。

2. 开发过程会比较混乱。开发人员无法基于稳定的代码版本新增或修改代码。

一个良好的持续集成应该包括，鼓励冲突编辑的源代码管理系统，自动构建系统，自动化测试系统，自动部署系统。

构建一个持续集成环境成本非常低，通过一些开源的工具就能实现。比如，我们使用的SVN + CruiseControl.NET + NAnt(MSBuild) + xUnit。

使用持续集成，我们需要注意什么？

第一，重视持续集成的结果。

持续集成的结果有两种，不通过（红灯）和通过（绿灯）。尤其是亮红灯时，一定要让团队的所有人都看到，并且相关的人员必须重视，立即停下手头的工作去修复它。我见过有的团队使用一个大显示器，让在团队成员的中间，显示器中显眼的红灯很容易就被团队的成员看见，并且每个人看着都会不爽，直到去修复它。甚至，有的团队使用邮件进行骚扰，当编译不过时，不断的给Breaker或团队所有成员发邮件，直到解决为止。据说ThoughtWorks公司使用一种类似灯笼的东西，集成不过时，灯笼两红灯，非常的生动有趣。

另外一个简单的办法，就是要求团队成员在自己电脑开机时自动启动CCTray（如果使用CCNET的话），团队所有成员通过CCTray及时的得到集成的结果。

“谁破坏了构建，谁就要受到惩罚”，不过这里的“惩罚”并不是真正的惩罚，而是诸如请别人喝可乐之类的。每个人都有犯错误的时候，都有入库时忘记入某些文件的时候，我还记得有个同事因为破坏了构建，导致我和另外一个同事无法工作，最后解决后给我们送上的可乐。

第二，入库前，先在本机集成。

这是一个好习惯。要让团队所有人都养成这个习惯，就必须让本机的集成做的越简单，比如做成一个Bat文件。Martin Fowler的文章里提到在本机集成两次，第一次在代码完成时集成，第二次更新最新的代码下来，如果有冲突，解决冲突后在集成一次。然后再入库。

本机集成通过，并不一定提交后在集成服务器就能通过。通常让构建亮红灯，都是因为本机编译没问题，到了构建服务器就出问题。最常见的原因就是漏了入库文件，以及，本机未更新最新代码进行的集成。

第三，鼓励频繁的集成。

构建一般分为，日构建，实时构建，手工构建。我觉得，日构建肯定是必须的，能做实时构建就做实时构建。在完成一个小的迭代，或是功能时，就加入到构建中，让团队中的其他成员能够获得更加及时可用的代码。频繁的入库，集成，同时也能减少代码冲突产生的代价。

我见过有的团队，采用日构建加手工构建的方式，在进行手工构建时，有时还需要加入一些手工的干预，比如修改某个配置文件，替换某个文件等等。其实这是不鼓励的。应该尽量保证构建的自动执行。

第四，加快集成的速度。

相信任何一个稍微大点的项目都会遇到这样的困境，完整的构建整个项目需要花费几个小时甚至更长的时间。这是难以忍受的，除非在半夜里进行的日构建。如果代码提交后，需要等待1小时才有结果，也是难以忍受的。我们之前就遇到过这样的问题。之后我找了很多办法，将实时构建的时间降了下来。比如将不同的工程区分开来、白天只编译Release，晚上Release和Debug一起编译、通过编写MSbuild插件实现入库文件的智能判断，只编译产生影响的代码工程。之前我写过一篇文章专门介绍过这个方法（CCNET+MSBuild+SVN 实时构建的优化总结）。

第五，自动测试。

CCNET中，有良好的扩展机制，可以在代码编译完成后自动执行单元测试案例。同时，CCNET还支持一些代码风格检查工具以及代码覆盖率工具(如NCover)。除此之外，一些集成测试案例也需要在构建完成后能够自动触发，这些案例通常会依赖一些具体环境，比如外部数据库，案例执行的时间会稍长。为了不影响自动构建的时间，需要使用单独的机器来触发和执行这些案例，甚至做成一个自动化分布式案例执行平台。比如我们自己实现的Box自动化测试平台。

三言两语并非以偏概全，而是说说我心里所想的。想要了解更多关于持续集成，还是仔细看看Martin Fowler的《持续集成》第二版的中译本。如果有CCNET使用的一些问题，可以来问我。

作者：CoderZh（CoderZh的技术博客 - 博客园）

出处：http://coderzh.cnblogs.com/

文章版权归本人所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。