【IT168 专稿】    如何才能成功实践敏捷开发是一个课题。最近Keith Swenson一直在考虑这个问题，并最终总结出26条重要原则，以指导敏捷软件开发团队更好地工作。

    原则1：第1个用例完全处理好后再开始处理第2个用例。打个比方说，好比“先上这道菜，再开始做下一道菜”。软件开发方面的最大问题是同时开始处理一堆任务，因为免不了会出现部分工作后来被丢弃的结果，而这意味着浪费工作。先处理好某个用例，确保它完全可以使用，进行测试，编写说明文档，签入所有代码，作为一件完成的工作，之后开始处理下一个用例。

    原则2：千万不要破坏编译版本。这一条原则显而易见，但必须包括在任何软件开发忠告清单当中。如果程序员在签入代码之前采取了所有相应的防范措施进行测试，就永远不会破坏编译版本（build）。如果编译版本被破坏，十有八九是因为有人在抄捷径。

    原则3：除非用例确实需要，否则不要实现例行程序。实现某个特定的类时，你应该想好了某个特定的用例，而且应该只实现该用例需要的那些方法。你可能会考虑该类可能具有的其他功能，不妨把这写入到注释中，但应该等到用例实际需要时，再去实现。

    原则4：除非用例确实需要，否则不要添加数据成员。与上面这条原则如出一辙，只不过涉及的是类的数据成员。“客户”记录似乎显然需要“送货地址”，但直到有一个用例明确需要送货地址，才应该实现它。

    原则5：不要害怕做决定；也不要害怕改变之前所做的决定。敏捷开发的本质就是遇到不确定状况后，迅速响应。在开发的早期阶段，你没有完整信息。应当尽可能推迟决定，但到时候终究需要做决定，才能开展进一步工作。你可以推迟决定，直到拥有了相应的信息。应当根据现有信息，做出最合理的决定。以后等有了新的信息，不要害怕改变之前所做的那个决定。（有些老派的人称之为朝令夕改，但我称之为是应对不断变化的环境。）

    原则6：不断学习如何改善质量。这项工作永远不会结束，所以你应该不断留意哪些方面可以改善，并收集如何确认及处理质量问题的实际方法。

    原则7：重视度量。敏捷开发是为了帮助处理将来不确定的问题，但过去毫无不确定性可言。应该不断进行测试。应该度量并记录每次测试所得到的性能。

    原则8：奉行以人为本、而不是以系统为本的设计理念。开发人员常常会走入为技术而设计的误区。我们绝不能忘了软件的最终目的，即软件是用来帮助人完成工作的。

    原则9：测试是产品的一部分。许多开发人员和经理认为产品就是交付给客户的东西，其他一概都不那么重要。其实，应该把测试看作是产品的一个实际部分，值得在设计阶段予以全面考虑；甚至在许多情况下，要与产品一同交付给客户。（这后一种做法颇有争议，但是内建自测作为交付软件的一部分占用的空间微不足道，却在必要时提供了显著效益。所以，这种方法值得考虑。）

    原则10：先编写测试用例，后编写代码。测试本身可以用来让设计体系清楚到底需要什么样的代码。在执行测试用例时，往往可以发现设计方法存在的缺陷。想一想在编写代码之前执行测试用例可以省下多少时间。但要注意：先编写第1个测试用例，并编写代码，然后开始处理第2个用例。

    原则11：消除浪费。坦率地说，这是另一条老生常谈的普遍原则；因为它实在太重要了，所以任何开发原则清单中都少不了它。一旦发现浪费，就要消除，这项工作要坚持不懈。消除无法为客户增添价值的任何代码。如果你发现代码无法为客户带来价值，那么可能不需要该代码。

    原则12：营造发现编译版本被破坏、立即采取对策的文化氛围。要明白当编译版本被破坏时，它会影响参与项目的每个人；因此，没有什么比确保核心代码进行合理编译及测试更重要的了。我见过有些团队任由不完整的测试持续数个月，因为他们觉得那是别人的工作，不关自己的事。每个人都受到了不利影响，却没有人采取行动。而是需要达到一种共识：自己多做一点工作，就有望为整个团队带来很大的回报。

    原则13：团队的每个成员都要了解客户需求。大型的复杂项目必须进行划分，交给不同团队；这些任务需要进一步细分，分派给开发人员。但是在这么做的同时，要确保开发人员了解使用最终产品的实际用户的需求和目标。