敏捷开发清单

引言

本文旨在为敏捷软件开发项目定义一套理想的实践方法。这篇文章的灵感来自于我讨论CMMI类型流程后，意识到没有敏捷的等效物。我鼓励您使用本页底部的讨论模块来评论这篇文章。请注意，所列的实践是我认为对良好的敏捷开发项目至关重要的实践；它们不一定与敏捷有关。我已尽量按重要性降序排列这些实践。

实践 1：积极重构

在我看来，重构是软件开发人员最容易被忽视的一项技能。与重构不佳的应用程序相比，一个良好重构的应用程序对项目发起人来说价值要高得多。需要重构的代码最常见的迹象是方法过长。我尽量将方法保持在100行以内。其他常见的代码坏味道是误导性或无意义的变量名，以及代码重复。静态代码分析工具，如FxCop，可以提供代码质量的有用度量。

实践 2：测试

首先，应该进行一些开发者测试。所有编写的代码都应该是可测试的，并且应该为其编写测试。为了便于进行良好的测试而修改程序是可以接受的。我认为传统的测试术语；单元测试、集成测试和系统测试已经过时。相反，我更喜欢术语开发者测试、功能测试和非功能测试。非功能测试包括性能测试，功能测试是客户关心的测试，如用例测试或业务事务测试，而开发者测试是开发人员为证明代码正确性所需进行的所有其他测试。

我们应该尽可能自动化测试，并将其作为持续集成的一部分运行。如果将代码覆盖率分析包含在自动化测试中，它就能提供系统在任何时间点健康状况的良好指示。

实践 3：自动化构建和部署

项目应该有自动化构建、自动化部署，最好还有自动化测试。在理想情况下，开发人员可以单击一个按钮，构建过程就会构建最新的源代码，进行部署、测试并报告结果。自动化这些过程不仅节省时间，而且消除了大量的错误和耗时的工作。

实践 4：持续集成

如果项目有自动化构建、部署和测试，那么持续集成实际上只是自动化该构建、部署、测试周期的启动。每次签入都应该在单独的构建服务器上产生一个新的构建和测试。结果应该报告给每个团队成员，并且应将立即修复构建作为一项既定的团队实践。一个正常工作的构建应该是每个人的首要任务。不应该让人们因为破坏了构建而感到难过，因为这会削弱他们的勇气。

实践 5：源代码管理

应该使用源代码管理系统来存储所有项目工件，包括：代码、非代码文档、构建脚本、数据库模式和数据脚本，以及测试。代码在编译并通过测试之前不应被签入构建。

实践 6：沟通计划

开发人员和客户之间应该有一个明确、直接的沟通渠道。这可以是（从最好到最差）：按需的面对面沟通、每日或每周的面对面沟通、联系电话、即时消息、电子邮件列表、中介（业务分析师或项目经理）。这些沟通渠道可以并且应该结合使用。

实践 7：任务跟踪

应该有一种明确的技术来记录和优先处理开发任务和错误。该系统应该能够将任务分配给个人。如果任务是针对估算值进行跟踪的，那么估算应该由将要执行该任务的人员来完成。

实践 8：自文档化代码

代码注释应该与代码本身一样受到质量要求的约束。应尽一切可能确保不需要其他技术文档。当需要非代码技术文档时，应遵循以下限制：从代码中引用，始终保持最新（代码更改时进行更改），每个基线只有一个版本，存储在源代码管理中。

实践 9：同行评审

必须有某种形式的同行评审，例如对其他程序员的代码评审。如果开发人员要接受绩效评估，那么他们进行的同行评审应该是该过程的输入。这有助于避免为了避免冲突而批准一切的诱惑。确保评审是为了质量，而不仅仅是为了正确性。

实践 10：进行中的工作

最新迭代的工作版本应始终可供客户反馈。这样做的优点是客户可以很快地发现有什么东西的开发与他们的想法不符。缩短这个反馈周期可以降低变更的成本。

实践 11：反馈机制

应该有一个明确的机制，供项目团队成员（包括客户）提供关于项目过程的反馈。我的建议是在每次迭代结束时举行一次简短的会议。