敏捷软件开发

最近一直对敏捷软件开发比较感兴趣，找了一些资料，有不对的地方请大家多多指教。

《敏捷软件开发：原则、模式与实践(C#版)》一书中首先写道：“人和交互重于过程和工具；可以工作的软件重于面面俱到的文档；客户合作重于合同谈判；随时应对变化重于遵循计划”，也就是著名的敏捷软件开发宣言。那么究竟在团队中怎样才能有效的实施敏捷开发，以达到节省成本、提高质量的目的呢？下面列出了一些最佳实践和技术。

[1]. User Story（用户故事)：
它是关于需求的谈话的助记符，通过跟客户的反复讨论，获取对需求的理解，但是不去记录其中过多的细节，在一张卡片上记录下一些有共识的语言，以后的估算、开发、管理、测试应该以用户故事为单位进行（有点像用例的说）。
用户故事是一个需求分析方面的技术，那么敏捷软件开发中是怎么来做需求分析的呢？用户故事和RUP中的用例有什么区别呢？敏捷软件开发事实上分为三个部分：敏捷需求分析，敏捷项目管理和敏捷软件开发，而程序员眼中的敏捷往往是最后一个部分。敏捷开发中提到的一个观点叫做现场客户（Kent Back），就是希望客户能够一直跟随开发团队一起工作，从用户故事开始一直到项目的成功。但是，并不是所有的客户都有时间跟随开发团队一起工作的，如果遇到了这种情况，应该怎么办呢？这时候，我们就需要商务分析师这个角色，来充当客户的角色。商务分析师负责与客户交谈，了解并分析需求，制作成用户故事交给程序员，当然，商务分析师也应该代替客户做一些其他的事情，比如功能验收测试。商务分析师还有一个最重要的职责，就是搞清楚客户到底要的是什么？为什么要这些东西？有没有更好的更简单的办法去满足客户的要求？以挖掘出客户的真正需要。
搞清楚这些事情以后，就可以写出用户故事，用户故事一般分为三个部分：“作为（系统的一个Stackholder），我想要（做一件事情），从而（达到一个商业目的）”。其中最重要的部分是到达一个商业目的。举一个例子：“作为一个网站所有者，我希望能够提供用户注册功能，以便能让用户享受更多的服务”。

[2]. Test-Driven Development（测试驱动开发）：
一直认为测试驱动开发是敏捷软件开发最重要的一项实践及技术，所以理解好测试驱动开发至关重要。测试驱动开发的基本思想就是在开发功能性代码之前，先写测试代码，实现任何一个功能都应该从测试代码开始，没有测试代码就一定不会出现一行产品代码。不可运行（写一个不能工作的测试程序，这时候是编译不通过的）- 可运行（尽快让这个测试程序工作，这时候可以在程序中使用一些最简单的手段）- 重构（消除重复性代码，优化代码结构）是测试驱动开发的口号。
拿到用户故事卡片并进行简单的分析以后，结对编程的两个同事坐在电脑面前，一个人控制键盘来编写测试代码，另一个人一边看着一边思考，有不同的意见会马上提出来进行讨论，这样写出的代码会尽可能的保证接近于需求。这时候应该由另一个人来控制键盘，写出让测试通过的实现代码（产品代码）。
测试代码应该模拟一些业务场景，并且尽可能的多模拟一些，正常情况和异常情况的测试用例都需要存在，以达到在单元测试部分保证业务逻辑正确的目的（因为业务逻辑的错误是编译器检查不出来的）。
测试驱动开发还能够让你很自然的写出松耦合（编译时）的代码，因为在写产品代码之前写测试代码，常常会暴露出程序中应该被解耦和的地方。具体的例子请查阅《敏捷软件开发：原则、模式与实践(C#版)》的第四章。里面有更详细的介绍。

[3]. Continuous Integration（持续集成）：
开发人员每天都会多次的签入代码，在通常的软件开发过程中，集成是一件很痛苦的事情，开发团队通常会每一天或更长的时间做一次集成，这样会引起很多的问题，比如Build未通过或单元测试失败等。敏捷软件开发提倡持续集成，一天内集成十次以上是很常见的做法，每天如此多的集成会使错误的定位变得易常容易，也使得开发人员在签入代码的时候会特别小心，因为有可能他的代码会造成集成后测试的不通过，这也在一定程度上提高了软件开发的质量。
一次持续集成需要做的事情大致包括：获取源代码、编译源代码、运行单元测试、功能测试、发送报告等。可以使用 ThougthWorks 公司开发的 CruiseControl 工具实施持续集成。

[4]. Refactoring（重构）：
重构是大家每天工作中都在使用的一种技术，重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。敏捷开发提倡把重构贯穿于整个开发过程中，每次添加一个新功能的时候、每次checkin代码的时候、每次codereview的时候都是重构的最好时机。
关于重构的更多知识，请参考《重构：改善既有代码的设计（中文版）》(MARTIN FOWLER)一书，里面讲了重构的所有知识。

未完待续。。。