InfoQ 文章：我和敏捷团队的五个约定（覃其慧，ThoughtWorks 敏捷咨询师，2009-3-2）

原文中提出了敏捷测试的 5 个约定。对于这几个约定，传统软件工程会怎么做，传统与敏捷有什么区别？我们在这里作一个比较，应该很有意思。



“预防胜于治疗”，这点说得很好，预防质量缺陷正是 QA 的主要使命之一。

非常重视预防和计划恰恰也是传统软件工程的特点和长处。当然，与敏捷不同的是，传统软工更强调文档化和数量化，而其预防、计划和准备工作往往是 heavy-weight 的，要保留、记录开发全过程的动态演变。

约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议。

这条约定在传统软件工程项目中，是必然的要求。无论 ISO 9001、CMM/CMMI 和 RUP 等等，在过程规范和企业制度里，肯定都会要求所有关键的 Stakeholders（包括测试、QA 人员在内）参加客户需求会议，因为客户需求会议实在太重要了。而且测试、QA 不是仅仅参加会议，发表口头意见就够了，还要形成会议纪要（记录）和正式文件，并在上面签署质量意见。

不要忘了，现在成熟的 ISO 9001、CMMI 团队也应该掌握迭代开发的能力，不应该“到项目后期才能开始测试”。迭代递增式开发是敏捷的基础，然而仅仅做到了迭代开发，未必就是敏捷的。

原文中提到的以下几点，不但敏捷团队应该做到，成熟的传统软件工程团队也可以做到，或应该做到：



作者这里谈到的 BA 和 QA/Tester 的分工是比较合理的，本质上还是迭代开发的基本要求。

完成以上 3 个任务（或目标），需求用例（use case）的分析是非常有效的。BA 分析 business use cases，Tester 分析 software/system use cases，并根据软件需求用例来编写 test cases，基本完成测试用例的准备，从而“赶在开发人员们写代码之前就告诉他们我要测什么”。需求用例非常有利于帮助测试了解“客户需求与使用软件的惯常行为”（简述或基本流），而需求用例的扩展条件和扩展流非常有助于发现“重要的有破环性的情况”。

需求用例（use case）分析技术其实在传统软件工程、敏捷软件工程项目中都可以使用。


约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见。

约定3. 项目经理们，请不要要求我们测试软件的所有路径。

这条约定好像是软件工程的常识问题。对于成熟的传统软件工程来说，是多余的。如果一个项目经理不懂软件测试的基本常识和规律，他不配来管理软件开发项目。

约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我。

约定5. 测试人员们，那些敏捷实践对于我们也是有用的。

InfoQ 文章：

我和敏捷团队的五个约定（覃其慧 发布于 2009年3月2日）

其慧的这篇文章写得不错，我大体上赞成。同时我也不觉得这 5 个约定要求很高，这些要求对于敏捷团队来说是起码的，很普通，也很常见，而且有些约定是传统软件工程团队也应该做到，甚至可能做得更好。

在讨论中，有些网友认为这样对测试人员的要求很高，而我认为，这些要求其实并不高，因为：

许多测试人员本身就是程序员，而好的测试（人员）水平要高于普通程序员。

太极敏捷还有一个观点：

如果一名程序员，不知道怎么测试（尤其是通过编写另一段程序的方式来测试）自己所编写的程序，那只能算半拉子程序员。

一个软件研发组织的自动化测试程度和水平往往反映了这个组织的软件工程成熟度水平，那些过度依赖人工测试的组织往往会效率低下，缺乏竞争力。所以，其实大部分测试人员，比如 10 个里面有 8 个，应该会熟练地编写测试程序。当然，我这里说的是先进企业、领导企业的情况。

我在 10 多年前就听说，华为、中兴好像有一种“轮岗”制度，有些程序员做一段时间后，会被鼓励去做测试，或者两者定期交换，这么做是非常科学的。现在想起来，这应该也算一种敏捷实践。

组织测试能力的强弱可能跟行业软件的特点有关，我们通常在通信、金融等具有高质量要求的设备、系统研发行业中看到很强的组织、个人测试能力。

在华为、中兴这样有很强的测试能力的领导企业中，有专门的、庞大的测试部门，采用大量的测试平台、测试工具和技术，测试也分测试项目、测试需求、测试计划和测试架构等等，这种测试和普通的开发有什么区别？

就像其慧所说的，测试人员与业务分析师，其实是同一个角色的两种面孔；programmer or tester，其实也是同一个角色的两个面孔（张恂 太极敏捷）。programmers 开发一个系统，testers 则开发另一个系统来对 programmers 开发的系统进行验证，两者都是开发，两个系统是相对和互补的，两种角色也是相对和互补的。

太极敏捷：Testers are also programmers.

当然这样的测试工作需要大量高水平的会编写程序的测试人员。在此类环境中，测试人员其实就是另一种高水平的程序员（测试程序员）。

What Is Agile Testing, Anyway?
By Janet Gregory and Lisa Crispin, 2009-1-19 (informit)

Agile Testing: A Practical Guide for Testers and Agile Teams 的样章（AWP）

有关敏捷 QA 的参考：

The Role of QA in an Agile Development Project (Damon Poole, 2007-5-11)

Agile Quality Assurance 讨论（AgileSoftwareDevelopment.org 论坛，2006-11-13）

Wikipedia 上关于 Quality assurance 术语的解释

InfoQ 文章：我和敏捷团队的五个约定（覃其慧，ThoughtWorks 敏捷咨询师，2009-3-2）

原文中提出了敏捷测试的 5 个约定。对于这几个约定，传统软件工程会怎么做，传统与敏捷有什么区别？我们在这里作一个比较，应该很有意思。



“预防胜于治疗”，这点说得很好，预防质量缺陷正是 QA 的主要使命之一。

非常重视预防和计划恰恰也是传统软件工程的特点和长处。当然，与敏捷不同的是，传统软工更强调文档化和数量化，而其预防、计划和准备工作往往是 heavy-weight 的，要保留、记录开发全过程的动态演变。

约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议。

这条约定在传统软件工程项目中，是必然的要求。无论 ISO 9001、CMM/CMMI 和 RUP 等等，在过程规范和企业制度里，肯定都会要求所有关键的 Stakeholders（包括测试、QA 人员在内）参加客户需求会议，因为客户需求会议实在太重要了。而且测试、QA 不是仅仅参加会议，发表口头意见就够了，还要形成会议纪要（记录）和正式文件，并在上面签署质量意见。

不要忘了，现在成熟的 ISO 9001、CMMI 团队也应该掌握迭代开发的能力，不应该“到项目后期才能开始测试”。迭代递增式开发是敏捷的基础，然而仅仅做到了迭代开发，未必就是敏捷的。

原文中提到的以下几点，不但敏捷团队应该做到，成熟的传统软件工程团队也可以做到，或应该做到：



作者这里谈到的 BA 和 QA/Tester 的分工是比较合理的，本质上还是迭代开发的基本要求。

完成以上 3 个任务（或目标），需求用例（use case）的分析是非常有效的。BA 分析 business use cases，Tester 分析 software/system use cases，并根据软件需求用例来编写 test cases，基本完成测试用例的准备，从而“赶在开发人员们写代码之前就告诉他们我要测什么”。需求用例非常有利于帮助测试了解“客户需求与使用软件的惯常行为”（简述或基本流），而需求用例的扩展条件和扩展流非常有助于发现“重要的有破环性的情况”。

需求用例（use case）分析技术其实在传统软件工程、敏捷软件工程项目中都可以使用。


约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见。

约定3. 项目经理们，请不要要求我们测试软件的所有路径。

这条约定好像是软件工程的常识问题。对于成熟的传统软件工程来说，是多余的。如果一个项目经理不懂软件测试的基本常识和规律，他不配来管理软件开发项目。

约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我。

约定5. 测试人员们，那些敏捷实践对于我们也是有用的。

InfoQ 文章：

我和敏捷团队的五个约定（覃其慧 发布于 2009年3月2日）

其慧的这篇文章写得不错，我大体上赞成。同时我也不觉得这 5 个约定要求很高，这些要求对于敏捷团队来说是起码的，很普通，也很常见，而且有些约定是传统软件工程团队也应该做到，甚至可能做得更好。

在讨论中，有些网友认为这样对测试人员的要求很高，而我认为，这些要求其实并不高，因为：

许多测试人员本身就是程序员，而好的测试（人员）水平要高于普通程序员。

太极敏捷还有一个观点：

如果一名程序员，不知道怎么测试（尤其是通过编写另一段程序的方式来测试）自己所编写的程序，那只能算半拉子程序员。

一个软件研发组织的自动化测试程度和水平往往反映了这个组织的软件工程成熟度水平，那些过度依赖人工测试的组织往往会效率低下，缺乏竞争力。所以，其实大部分测试人员，比如 10 个里面有 8 个，应该会熟练地编写测试程序。当然，我这里说的是先进企业、领导企业的情况。

我在 10 多年前就听说，华为、中兴好像有一种“轮岗”制度，有些程序员做一段时间后，会被鼓励去做测试，或者两者定期交换，这么做是非常科学的。现在想起来，这应该也算一种敏捷实践。

组织测试能力的强弱可能跟行业软件的特点有关，我们通常在通信、金融等具有高质量要求的设备、系统研发行业中看到很强的组织、个人测试能力。

在华为、中兴这样有很强的测试能力的领导企业中，有专门的、庞大的测试部门，采用大量的测试平台、测试工具和技术，测试也分测试项目、测试需求、测试计划和测试架构等等，这种测试和普通的开发有什么区别？

就像其慧所说的，测试人员与业务分析师，其实是同一个角色的两种面孔；programmer or tester，其实也是同一个角色的两个面孔（张恂 太极敏捷）。programmers 开发一个系统，testers 则开发另一个系统来对 programmers 开发的系统进行验证，两者都是开发，两个系统是相对和互补的，两种角色也是相对和互补的。

太极敏捷：Testers are also programmers.

当然这样的测试工作需要大量高水平的会编写程序的测试人员。在此类环境中，测试人员其实就是另一种高水平的程序员（测试程序员）。

What Is Agile Testing, Anyway?
By Janet Gregory and Lisa Crispin, 2009-1-19 (informit)

Agile Testing: A Practical Guide for Testers and Agile Teams 的样章（AWP）

有关敏捷 QA 的参考：

The Role of QA in an Agile Development Project (Damon Poole, 2007-5-11)

Agile Quality Assurance 讨论（AgileSoftwareDevelopment.org 论坛，2006-11-13）

Wikipedia 上关于 Quality assurance 术语的解释

InfoQ：Scrum实施情况调查之案例分析



这个“有人”大概就是指张恂吧。没错，这些就是我们中式太极敏捷的主张，除了只“在字面上下功夫”。要真正理解敏捷，从基本概念、字面含义开始不啻为一种好方法。

“敏捷就是反应要灵敏，动作要快捷；敏捷就是又好又快，或者就是多快好省”，不但是我们中式敏捷的基本主张，也符合西式 Agile、light-weight 过程的基本含义。当然，Agile 的含义不止于迭代和轻载。

如果一种方法不具有英文单词 Agile 的基本含义，怎么会叫 Agile？难道西方的敏捷大师们也都是些文盲？不会吧。作为一名本土中国人，我也始终弄不明白，为什么一种方法不能做到起码的“敏”和“捷”，可以叫“敏捷”？作为知识分子、知识青年的我国程序员们，逻辑思维不能这样差吧。

当然，张恂的文章《Agile 与太极敏捷：到底啥是敏捷？》只是初初开了个头，从敏捷这个单词的基本含义讲起（实在看不惯国内一些文盲型的程序员老是在那里忽悠），敏捷的含义当然非常丰富，不仅如此。

张恂差不多有 8 年以上的敏捷实践经验，可能是国内最早采用敏捷实践的程序员之一（早于 2001 年），因此决不是在玩字面，比 ThoughtWorks 咨询师熊节（Jeff Xiong）那一派的弄文青年要好得多。

我觉得，在中国推广敏捷，首先要打破 ThoughtWorks 和西式敏捷的“话语垄断”（如果这种垄断存在的话），尤其要警惕某些人片面打着 ThoughtWorks 或者西方敏捷大师的旗号、话语来误导。

InfoQ 讨论：50位开发人员的答案：你最想让CIO了解敏捷的哪个方面？

如今任何一位非文盲，具有小学文化水平的人，恐怕都懂得“捷”的含义。如今有洋人（大洋彼岸之人）说了，“敏捷并不代表更快”，那么，咱还留着“捷”字干嘛？是不是我们译错了，Agile 不应该译成“敏捷”？究竟是谁第一个把 Agile 译作“敏捷”的，现在很难考证了。

如果 Agile 不应该叫做“敏捷”，那么叫做“敏秀”，“敏爽”，“敏杰”，怎么样？或者干脆用直译，叫尊贵的“啊极乐”方法，ok？

玩笑归玩笑，敏捷的“快”其实有多种含义。

首先，敏捷的“捷”是指反应快，应变快，措施快，能够快速地应对变化，响应变化，包括各种风险。这是 Agile 的本意，属于真理部分，应该不会错的。

至于项目能否更快地完成，这倒未必是一个重点。过去软件工程界有一个经验数值，超时 20% 通常是一个可以接受的范围。所以，认为敏捷就一定是要赶时间，提前完成项目，其实没有这个必要。

敏捷方法能够提高质量，这点应该也没有问题，属于 common sense，而且被过去多年来的实践已经证明了。而软件质量提高了，返工、废品、折腾自然就少了。因而从长远来说，敏捷可以缩短开发时间，提高开发效率，减少资源的耗费，也在情理之中。

世界上只有两种方法，一种是代表“旧势力”的传统方法，另一种是代表“进步势力”的敏捷方法。如果敏捷方法不能在项目的 time, cost, quality, risk 等等生产要素、衡量指标方面，处理、完成得比旧方法更好，请问，我们到底为什么要拥抱敏捷？难道仅仅是为了像消费时尚歌曲、电影、霓裳一样，作一个喜新厌旧的追星族？

InfoQ 上的讨论：敏捷不是什么

敏捷项目采用迭代方式开发，对于 fixed-time、fixed-budget 的项目。敏捷团队会怎么做？敏捷项目可以缩减需求内容和范围，这是保证项目按时、按预算交付的关键。

我们知道，根据成熟的项目管理理论，time、cost（resource）、scope 和 quality 是软件开发项目中 4 个相互制约的主要因素。当 time、cost 固定后，通常 quality 要求是不可以降低的，这时唯一可以调整的变量是 scope。也就是说，如果敏捷团队提前发现，项目有可能不能按时、按预算完成时，他们将及时与客户协商，缩减开发内容，比如从开发任务中去掉一些次要的特性。这样，敏捷团队仍然可以保持按时、按预算完成项目。

由于敏捷团队采用短迭代，频繁地测量实际的开发速度，并与客户进行沟通，所以能够及时、尽早地发现问题，有效地控制和降低项目开发风险。所以，对于真正做到了敏捷的团队，基本上不可能发生拖到项目末期才爆发重大 surprise 的情况。

这些早已都是国际上的通行做法，最佳实践，大量案例证明了敏捷迭代方法的有效性。显然，最终结果严重超时、超支（比如超出 50% 甚至一倍以上）的项目肯定不是敏捷的，说明这个项目已经失控，而开发团队未能很好地控制项目风险。


林芷薰 于 2007-12-11 3:20 说：

另一种对敏捷的置疑之声是关于实施敏捷的效果的：

我们经常看到一些号称 Agile 的国内项目，按照菜谱、操作指南和教父语录的提示，采用了许多花哨的技巧和实践（做法），是啊，表面上确实 Agile 了，那么结果呢？项目还是不能按时完成，甚至严重超支和超时，这能叫“敏捷”吗？

可以看出，一些对敏捷缺乏了解的同行和甲方代表又把这个时髦的新词汇当作了万灵药：按照他们的逻辑，如果做好了敏捷，项目就一定能够按时完成，预算也不会超支的。首先，不难看出这是一个无法兑现的承诺：开发团队是有其能力极限的，超出他们能力极限的项目无论如何也无法按时按预算完成，不管用不用敏捷。如果把敏捷当作一种宗教信仰来看待，认为项目不成功就一定是没有做好敏捷的话，就可能让真正的问题从眼前滑过。


不知道林作家作出这样的评论，是基于什么样的逻辑，是否真的看懂了张恂的论点和逻辑。

他认为张恂的这段话，“不能按时完成，严重超时超支的项目不是敏捷”，是对敏捷的置疑之声。这看上去很滑稽。显然，张恂是在质疑号称“敏捷”，结果却不敏捷的项目，因为敏捷不敏捷，首先应该看实际的效果，项目、团队是否真正做到了“灵敏”与“快捷”。而质疑“假敏捷、伪敏捷”，与质疑“敏捷”，当然不是一码事。

看来，分歧出在判断敏捷的标准上。难道林作家认为“严重超时超支”的项目也算敏捷？他的理由是：

“开发团队是有其能力极限的，超出他们能力极限的项目无论如何也无法按时按预算完成，不管用不用敏捷”

不错，每个开发团队的确有其能力极限，问题是当敏捷团队发现项目超出了能力极限（最大的开发速度），预计无法按时按预算完成时，他们会怎么做，采取哪些行动？

通常，这时敏捷团队会和客户沟通，商量对策。如果客户同意延长工期，或增加预算（包括增加人手），那么自然皆大欢喜，项目最终还是能够按时按预算完成（根据调整后的工期和预算执行）。如果客户不答应延期，必须 fixed-time、fixed-cost，那么按照我前面的分析，通常只有两个办法，降低发布的质量，或缩减交付内容。如果客户又不答应这两项措施，该这么办呢？我想，敏捷团队这时应该衡量一下得失，以决定这个项目是否还值得做下去。

由于通常敏捷团队在项目进行到 1/3 或一半（工期过半，或支出过半）的时候，就能比传统团队更准确地判断出项目能否如期完成，是否超出了自己的能力极限。因此，即便在此时停止继续开发，也不会发生严重超时、超支的情况。

张恂从来不认为，采用了敏捷方法，项目就能 100%（一定）成功、按时按预算完成，张恂说的是“可以”或“极有可能”。科学技术不是万能的，敏捷方法自然也不是万灵药。而什么叫“按时、按预算”完成项目？这个概念本身就包含了一段客户允许的误差范围。重要的是，由于采用了更为科学和有效的方法，敏捷团队在大多数情况下比传统团队风险更小，更容易取得成功。

真正做到了敏捷（灵敏、快捷）的项目，与声称采用了若干敏捷实践（做法）的项目，显然是有所区别的。你做到了某些敏捷实践，未必代表你能让整个项目的运行敏捷起来。一个项目实施了“敏捷”，效果却不敏捷，这算什么逻辑？

可见，林作家的“一种对敏捷的置疑之声是关于实施敏捷的效果的”以及“超出他们能力极限的项目无论如何也无法按时按预算完成，不管用不用敏捷”等等，恰好说明：林作家对于软件项目管理和敏捷迭代开发的基本常识，乃至什么是真正的敏捷，缺乏真正的理解。

林芷薰 于 2007-12-11 3:20 写道：

有人认为“敏捷其实更强调一种包容与和谐的文化”。事实是这样吗？从Ivar Jacobson的描述中似乎看不出敏捷是如此强调“文化”：


敏捷是关于以下三件事情的：敏捷是一门社会工程学。敏捷是轻量级的。敏捷提供技术实践。

我们必须用新的观念来看待实践。我们不再谈论过程，实践已经取而代之，成为一等公民。过程仅仅是实践的组合。


看起来Ivar Jacobson更愿意把敏捷看作一组最佳实践的组合。毕竟正如ThoughtWorks中国公司总经理郭晓所说，“敏捷的目标是消除浪费”。而把它无限拔高成为一种“文化”对于企业消除浪费有什么实际的帮助呢？



首先我来认领一下，“敏捷其实是更强调一种包容与和谐的文化”这句话正是本掌门数日前在 InfoQ 中文站上的发言。有什么错吗？

林作家煞有介事地问道：“事实是这样吗？”怪了去了，我倒要反问：难道事实不是这样的吗？您认为的事实又是咋样的呢？

作者举出两位名家，Jacobson 和郭晓，的只言片语来作为可靠的论据。关于郭晓所说的“敏捷的目标是消除浪费”，后面我再评述，这里先谈 Jacobson。

Jacobson 说，敏捷是关于三件事，社会工程学，轻量，以及技术实践。请问林弟弟，你知道什么是社会工程学？社会工程学，不研究社会，研究文化，研究人与人之间的关系，还研究什么？

“看起来 Ivar Jacobson 更愿意把敏捷看作一组最佳实践的组合”，这可是你说的，你看起来的。如果 Jacobson 把敏捷只看成一组技术实践，那么肯定是片面和错误的。你可以去问问 Jacobson，他说的最佳实践组合，到底包不包括敏捷文化方面的实践？

再说了，为什么只有 Ivar Jacobson 的发言才叫事实？我们太极敏捷派掌门的发言就不是事实？

请问，Jacobson 发表过几本有关敏捷的著作？我们知道，他是 Use Case 和 RUP 大师，但他目前好像还不是敏捷的主要 Thought Leaders 之一吧（至少还没有获得普遍公认）。Agile UP 比 EssUP 出现早，那么请问 EssUP 与 Agile UP 有什么区别，是否比 Agile UP 更敏捷？Jacobson 所说的最佳实践组合与当前别人已经总结出来的敏捷最佳实践组合有多少不同？

再请问林弟弟，你又认真学习过几本敏捷经典（比如 Kent Beck、Alistair Cockburn、Jim HighSmith、Jeff Sutherland、Craig Larman 等等）？如果你还没有读过，没有实践过敏捷，没有学会如何与别人一起敏捷地工作，那么我告诉你一点有关敏捷的事实：

从现有的敏捷文献中，我们不难发现，敏捷至少包含三个部分：价值观、原则和具体的（实践）做法。敏捷的价值观、（做事）原则以及相关的理念、思想、哲学等一起构成了敏捷文化的基础。而敏捷的具体做法数量很多，而且大部分是 optional 的，应根据具体的适用环境和条件来有选择地进行应用。

这么多的敏捷实践（做法）缘何而来？正是为了实现、体现敏捷的价值观、原则 —— 敏捷文化！如果只记住了一些具体的敏捷实践，而忘记了我们到底要干什么（实现敏捷目标），这是本末倒置。

敏捷不是个别的、具体的实践，因为敏捷是一个整体的效果。你做到了 PP、CI、TDD 等几个实践，就真的敏捷了？未必吧。

敏捷文化才是敏捷的一等公民！

俗话说，无知者无畏。林弟弟，从你对包容、和谐的敏捷文化的无知和质疑来看，我觉得你至少没有做过 Team Leader，大概是一位刚参加工作不久的初级程序员吧。

事实是，目前你的逻辑分析能力与给你写序的 gigix 不相上下（一塌糊涂）。千万不要认为翻译了一两本时髦技术的书，自己就敏捷了，就专家了。建议今后要虚心加强学习，尤其是逻辑分析思维能力方面的锻炼。

InfoQ 上的讨论：敏捷不是什么

首先，这则讨论很好，可以让大家把敏捷是什么，不是什么，搞搞清楚。

作者写道：

“作为总结：敏捷不是放诸四海而皆准的通用理论；敏捷不是玄而又玄的文化；敏捷不是在传统项目合作模式下包治百病的金丹；敏捷不是抛开纪律盲目求快。除了这些，敏捷还不是什么？”

我的看法是：

1、敏捷不是抛开纪律盲目求快

不错！赞成。

2、敏捷不是在传统项目合作模式下包治百病的金丹

当然，这世上原本就没有 cure-all，敏捷自然也不是。

3、敏捷不是放诸四海而皆准的通用理论

这条有点问题。敏捷既是理论，也是实践。敏捷理论（软件开发哲学、思想和价值观等）中有一些可以认为是放诸四海而皆准的，比如以人为本，沟通，反馈，简化等等。

4、敏捷不是玄而又玄的文化

这条也有点问题。敏捷当然首先是一种文化，如果你理解《敏捷宣言》，而且了解什么是 culture（比如企业文化、团队文化等）的话，应该知道敏捷的内涵，其实包括价值观、原则以及约束和促进大家作为一个团队如何快乐、轻松、有效工作的游戏规则、习惯、纪律等等。那么，敏捷文化，团队文化或企业文化，玄不玄？一点都不玄，完全可以落到实处。


关于项目按时按预算完成，作者犯的一个逻辑错误

林芷薰 于 2007-12-11 3:20 写道：

“不难想象，在这种合作模式下，“按时按预算完成项目”已经不再是一个有效的衡量标准，因为项目的时间和预算都是动态调整的。在敏捷项目中，衡量项目成败的标准是：在合作的时间里，乙方能给甲方创造多大的价值。而这也是甲方真正在乎的。”

“按时按预算完成项目”，本身就隐含着项目的工期、预算执行是可以动态调整的，但不管如何，客户对动态调整必然有一个可以忍受的范围，项目必须 close，并达到阶段目标。所以，这与作者所说的“项目的时间和预算都是动态调整的”，一点都不矛盾。

作者接着说，敏捷项目衡量成败的标准是：在合作的时间里，乙方能给甲方创造多大的价值 ...

Ok，“在合作的时间里”，这还不是指时间上的约束，“按时”？

“乙方能给甲方创造多大价值”，请问 customer values 是什么东西？是可以凭空用嘴巴讲的吗？你说有价值就有价值，没价值就没价值？价值怎么样，应该用数据来说话。很多时候，带来多少客户价值，可以与财务指标联系起来，比如为客户创造了多少利润，节省了多少成本等等。所以，谈到价值本身，依然与预算有关。客户请你们开发，总有个成本、性价比要讲吧，不能超出预算太多。

如果因为“敏捷”了，原先 100 万的预算，表面上获得了 200 万的收入（价值），的确不错，价值很高啊！可是客户陆陆续续的真实投入却达 500 万，而且还超时一年！这样的“敏捷”其实是骗人的。

所以，项目“按时按预算完成”依然是一个有效的衡量标准，它本身并不排斥价值考核，只不过考察的角度不同罢了，两者并不矛盾。


林作家其实并未真的读懂李默案例

林芷薰 于 2007-12-11 3:20 写道：

正如“敏捷中国”讨论组的创始人李默在“客户协作 over 合同谈判”一文中所说：

“如果签订固定价格合同，客户会倾向于在这个价格内挤入更多的需求，而开发公司会希望在这里面减少成本。最终两方博弈的结果就是项目出了问题。这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己的能力，尽最大可能来保证质量和进度。”

不难想象，在这种合作模式下，“按时按预算完成项目”已经不再是一个有效的衡量标准，因为项目的时间和预算都是动态调整的。

前面我已经分析过，为什么“按时按预算完成项目”仍然是一个有效的敏捷衡量标准（起码是最低标准），当然很可能不是全部的标准（还有更高标准）。

在这里，李默推荐客户采用单价合同，也就是：

“确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。”

这是什么方式？不就是人力外包的方式么，现在国内外很普通，很流行啊。比方说，我们签三个月（“阶段时间”），5 名开发人员（“开发力量”），每人每月 3 万元（“单价”），那么费用一共是 45 万元，等于说客户在这段时间内外聘了 5 名熟练员工来干活，如果产出还不少的话，当然是合算的。

这样的敏捷项目，3 个月 45 万，难道不是按时，按预算？它恰恰对开发商提出了按时按预算完成项目的要求。当然，完成的内容和范围可以是协商的，但其价值至少要值 50 万吧（其实回馈价值 50 万已经失败了，回报应该起码要在 200-300 万以上）。难道签了这样一份单价合同，开发商就可以不按时，不按预算了？按时、按预算完成无疑仍然是一个有效的考核标准，而客户获得的价值衡量也应该以预决算为基准。

在这种合作模式下，每个阶段项目的时间和预算（客户的计划支出）其实都是固定的，所谓的“动态调整”其实是指不同阶段的工期和预算支出可能有所不同，客户和开发商可以一个阶段一个阶段的来签单价合同。

如果开发商在这 3 个月内（或在今后更长的一段时间内考查，这里简化为 3 个月）为客户产出的价值不能明显地超出客户付出的成本 45 万，甚至不足 45 万（项目预算），那么显然这个项目入不敷出，是失败的。

所以，我很难理解，作者所说的：

“不难想象，在这种合作模式下，“按时按预算完成项目”已经不再是一个有效的衡量标准，因为项目的时间和预算都是动态调整的。在敏捷项目中，衡量项目成败的标准是：在合作的时间里，乙方能给甲方创造多大的价值。而这也是甲方真正在乎的。”

是基于什么样的逻辑。

最近国内某家知名大型软件企业找到我和 Craig Larman，希望能请 Larman 和我一同组队，为他们提供敏捷实施咨询。他们同时交给 Larman 一份 RFP（Request For Proposals），请 Larman 提提建议。我们在这份 RFP 中发现了不少问题。于是，Craig 在与客户和我的三方通信中谈到了到底什么是敏捷，大中型组织和团队实施敏捷时应该注意的地方。

我发觉，这篇短文对于我们国内的读者、敏捷实践者来说，无疑具有很高的指导价值。在征得 Craig 的同意后，我对原文作了一些编译，在此一并奉献给大家。

Craig Larman 论敏捷与 Scrum