业界大咖谈敏捷（上篇）

《洞悉敏捷》一书客观全面地介绍了全球正在使用的各种敏捷方法的价值、原则、架构、过程和适用场景。除敏捷知识讲解外，书中还记录了13位享有盛名并且受人尊敬的敏捷大咖的访谈内容。受访者包括，Bob 大叔、Mike Cohn、Scott Ambler、Lyssa Adkins、Alistair Cockburn……本期为您带来Bob 大叔、Mike Cohn与Scott Ambler的访谈实录。

唤醒者Daniel滕振宇，京东资深敏捷与创新顾问、《Scrum精髓》译者姜信宝，InfoQ中国总编辑崔康，《敏捷无敌》作者、《敏捷开发一千零一夜》主编王立杰，软件工匠和敏捷教练姚若舟，精益看板国际认证讲师、前微软过程改进经理王明兰，资深软件工程师Gary Zhang联袂力荐。

（Bob 大叔）

Robert

Robert Martin（Bob 大叔）从1970 年起就成为了一名职业程序员，是8th Light 公司的首席工匠。他创办并担任总裁的Bob 咨询公司及Object Mentor 公司，为全球各大公司提供软件咨询、培训及技能发展服务。他经常在各大国际会议和贸易展上发言，出版了多部著作，包括： Designing Object-Oriented C++ Applications Using the Booch Method、 Pattern Languages of Program Design 3、More C++ Gems等。作为软件开发行业的领军人物，Martin为CReport 做过3 年主编，他还是敏捷联盟的首位主席。

Q

如果敏捷开发到了一个广泛应用的阶段，你认为敏捷宣言是否需要做出更新或调整？

Bob：不需要。我认为敏捷宣言是个指引方向的东西；我并不认为这个方向改变了，或将会改变。我认为敏捷宣言不是，也不应该是一个动态的文本。我觉得它是道路上的里程碑，而不是道路本身。之后也有了其他宣言，它们扩展或延伸了敏捷宣言的方向，例如软件匠艺宣言（http://manifesto.softwarecraftsmanship.org/）。

Q

你是否认为敏捷方法在所有情况下都优于传统的瀑布式方法？或者说，有没有瀑布式方法更胜一筹的情况呢？

Bob：敏捷方法在任何时候都更胜一筹，因为敏捷方法是更人性化的方法。小学三年级的时候，老师就开始教我们敏捷了。那时她让我们写一个故事，她帮助我们设定一个故事梗概，然后拟第一稿，再拟第二稿……任何值得做好的事情必须经过一系列的改良、迭代，这是我们从小就学会的道理。

Q

有没有一个契机，或是一系列的事件导致你意识到编写整洁代码和重构的重要性？

Bob：没有特别的事件。相反，这是一个漫长的学习、观察、思考的过程。若说在这个过程中有某个关键的时刻，那就是当我向Kent Beck 学习TDD——测试驱动开发（本书第7 章中会有详细介绍）的时候。实践这一关键原则时，我认识到如果你有一套可以信任的测试，那么代码就会非常易于修改。TDD 消除修整代码所带来的风险时，重构就成为你的家常便饭了。一旦你明白了这个道理，重构和整洁代码的重要性就显而易见了。当你害怕去修整代码的时候，你就不得不接受烂代码。而当你知道你可以简单并安全地修整代码时，你就无法接受烂代码了。

Q

在你看来，敏捷开发给软件开发领域做出的最重要的贡献是什么？

Bob：敏捷方法打破了瀑布式开发方法。这本身就是极其重要的，由此软件开发变成了人性化的行为。如今我在等待下一次革命，软件匠艺革命。我们已经知道我们必须迭代、必须通过不断的改良构建我们的系统。我们要学习的下一件事是追求速度且不会把事情弄得一团糟。我们接下来要做到的就是“保证速度的唯一方法就是把事情做好”。

Mike Cohn 访谈

Mike

Mike Cohn 于1995 年开展了他的第一个Scrum项目，并从此成为Scrum 富有号召力的支持者。作为创始人和Scrum 联盟认证的Scrum 讲师，他使敏捷和Scrum 成为了主流。他的书包括《敏捷估计与规划》、《用户故事与敏捷方法》，以及《Scrum 敏捷软件开发》，同时还有几本关于Java 和C++数据库编程的书。Mike 是敏捷联盟和Scrum 联盟的创始人之一，现任董事会主席。他领导的Mountain Goat Software 公司，是一家提供过程和项目管理咨询和培训的公司，该公司运用他在各种环境中二十余年的经验来帮助其他公司采用并改善敏捷过程和技术，以构建高性能的开发组织。他合作过各种大大小小的公司，其中包括：Bioware、Capital One、Electronic Arts、Google、雅虎等等。他也曾在各种规模的组织中担任过技术主管，从初创公司到《财富》排名前40 的公司都有。

Q

谁应该参与待办事项列表梳理会议？你如何将会议的价值最大化？它有可能一直有趣吗？

Mike：产品待办事项列表梳理会议至今还不是一个正式的Scrum 会议。只不过很多团队发现它是很有价值的，能够提高Sprint 计划会议的效率。同样，对于谁需要参与会议没有达成共识。我的观点是团队的一个子集就足够了。虽然我一般信奉整个团队参与，但这对该会议来说不现实。产品待办事项列表梳理会议通常会在Sprint 结束之前的两到三天召开。团队中几乎总有些人会在Sprint 结束前的两三天非常忙。如果让这些人多参加一个会议，将会加大他所负责的工作的交付风险。要最大化产品待办事项列表梳理会议的价值，可能会归结为同样适合于任何会议的几件事情：尽可能简短，预先有所准备，鼓励每个人都参与进来。我不认为有什么会议是真正有趣的，但我认为跟合适的队友共事时，可以将会议视为团队在紧张工作过程中的一个受欢迎的短暂休息。好的团队可以建立一种节奏，团队在紧张的脑力工作（不管是单独还是结对）和不时发生的会议间交替循环。如同其他大部分的社会活动一样，会议中可以伴随着同事之间的玩笑，在投入到更紧张的单独或结对的脑力工作之前，这恰好是精神上的一点休息。

Q

在Sprint 计划会议中最常见的错误是什么？

Mike：在Sprint 计划会议中最常见的错误是误解了会议的目的。因为Sprint计划会议的产物之一是Sprint 待办事项列表，所以很多团队都在Sprint待办事项列表上陷入了完美主义。这些团队试图识别出每一项任务并对它们进行精确估算。但这并不是Sprint 计划会议的目标。Sprint 计划会议的目标是为Sprint 选择正确的待办事项集合，并且确定这些将执行的工作已经被充分地讨论清楚了。对任务和估算的过度关注会导致团队在Sprint 计划会议中花费太多时间。任务和估算是必需的，但是它们只是团队用来决定为Sprint 选择哪些待办事项的工具而已。

Q

估算真的很难。我们怎样才能得到体现故事大小的最佳估算值呢？

Mike：当然很难，但是也有些招儿可以帮助团队来估算。首先，尽量将绝大多数估算，或者至少是最重要的估算，保持在一个数量级之内。已经有一些研究证明，人们在一个数量级内时可以做得很好，但是如果超出了一个数量级则会表现得很差。其次，使用相对估算而非绝对估算。比如“这（一个故事）将花费和那个（故事）一样长的时间”而不是“这将需要五天”。然后用速率来确定这些事究竟会花多长时间。相对估算不仅更准确，而且团队进行估算的时间也更短。使用相对估算，团队不需要考虑所有的细节，分别估算再求和。他们只需要找到类似的工作然后使用相同的估算就可以了。最后，不要认为我们是在为每个待办事项做估算，我们是在把待办事项放到合适的篮子里。为了指导团队，通常会预先确定一组用来做估算的值。我们通常使用如1、2、3、5、8、13 这样的值, 当然这是斐波那契序列。每个数字代表一个该大小的篮子。估算待办事项时，其目标就是把待办事项放入正确的篮子。如果团队认为某事是10，它应该放入大小为13 的篮子内，因为对于大小为8 的篮子而言它太大了。

Q

缺陷、维护工作或者技术债是待办事项列表的一部分吗？

Mike：它们显然是产品待办事项列表的一部分。产品待办事项列表包括产品负责人想对产品做的所有工作。如果产品负责人想做这些事，它们就属于产品待办事项列表。

Scott Ambler 访谈

Scott

Scott W. Ambler 是Scott Ambler Associates公司的高级咨询合伙人，帮助世界各地的组织改善其软件流程。在项目和组织层面，他提供关于规范化敏捷和精益策略的培训和指导。Scott 是敏捷模型（Agile Modeling）、敏捷数据（Agile Data）、规范化敏捷交付（Disciplined Agile Delivery）和企业统一过程（EUP）等方法论的创始人。他是数本书的作者或共同作者以及Dr. Dobb 期刊的高级特约编辑。他也是Disciplined Agile Consortium（DAC）的创始人。

Q

怎样知道一个公司已在文化方面做好了采用敏捷的准备？

Scott：我最初的想法是“你就是知道”，但是显然这不是你想要的答案。IT中的各级人员或至少业务中处于关键位置的人员，需要认识到他们需要更有效地交付IT 方案。他们需要认识到陈旧的、大量文档的方式是没用的。他们需要意识到时下的规则是更广泛的协作、更大的灵活性，同时需要接受一些不确定性。

Q

从文化的角度看，敏捷型模式和瀑布型模式之间最明显的区别是什么？

Scott：敏捷关注协作、迭代、高价值的活动，这些活动关注于产生可以满足利益干系人的方案；其挑战是敏捷团队需要具备足够的技能和纪律性来达成此事。瀑布团队经常以降低风险的名义使用大量的文档；其挑战是瀑布方法虽然在实践中具有更高的风险，但因为它包含了如此多的“检查和平衡”，身处其中的人们无法清晰地认识到他们正在承担的风险。

Q

诸如安排座位之类的事情对于成功地采用敏捷有多重要？

Scott：交流和沟通是敏捷项目成功的关键因素，因此在物理上如何组织大家是很重要的。我曾在多个调查问卷中探讨过这个问题（ 请见http://Ambysoft.com/surveys/），很明显的结论是，包括利益干系人在内的人们彼此之间越亲密，项目团队成功的几率就越高。甚至是将人们放在工作隔间中这样的简单事情都会降低成功率。

Q

成功的团队如何整合虚拟（甚至全球的）的团队成员？

Scott：最好的方法是根本不要去承担这类风险。如果你不得不承担，那么做的时候就需要倍加小心。尝试使用分布式子团队，而不是分散的个人。让关键人物在不同团队之间来回穿梭。将关键人物在项目的关键时刻聚集在一起，尤其是开始时，那时会做出很多根本性的决定。采取一些沟通技术，尤其是在视频会议中。最后，采用分布式开发工具，比如IBM Jazz或Microsoft TFS。