敏捷的核心：消除浪费，走向精益

敏捷的核心是什么？敏捷给软件企业（以及软件开发者个人）带来的好处究竟在哪里？这个问题有很多不同的答案。例如“重视个人和交流”，软件开发者喜欢这样的态度，这是毫无疑问的。例如“重视可工作的软件”，它的价值是显而易见的。但在这一切的背后，敏捷的核心是什么？时下流行的观点是：敏捷就是软件行业里的精益（lean）生产，它的核心是消除浪费。ThoughtWorks中国公司的高层在近日接受采访时明确指出了这一点。

首先考虑质量问题。一些软件企业为了降低成本而忽视质量，但质量低下的软件会造成返工的浪费，反而提高成本。相反，在日常工作中投入更多的精力来保证质量，反而能够为企业节约成本。ThoughtWorks中国公司技术总监Michael Robinson用软件工程的经典理论来分析这个问题：

任何一本软件工程教材都会告诉你：假设在分析阶段找到并解 决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的众多实践正是为 了避免低质量和返工的浪费。尽管它们一开始看起来似乎有些麻烦，但它们带来的收益是实实在在的。

另一种常见的浪费则是“为将来准备的投资”。例如为了应付将来可能出现的需求变化而提前引入的灵活设计，如果需求没有发生变化，这些灵活设计就会成为浪费：不仅浪费了将它设计出来的成本，而且浪费了继续维护它的成本。制造业为了降低库存成本而创造出“Just In Time”的生产和决策方法，ThoughtWorks中国公司总经理郭晓认为这些方法同样适用于软件行业：

如何消除预测错误的浪费？避免预测错误的 根本办法就是推迟决策：决策下得越晚，就越不容易因为预测失准而造成浪费。当然也不能晚到错过了时机、耽误了工作才下决策，这就像丰田制造的Just In Time，决策也要Just In Time。过早的、含有太多预测成分的决策也会造成浪费，其危害丝毫不亚于过晚的决策。

在最近的两篇Blog里，我谈到了一些从更深层次思考敏捷的心得。在我看来，敏捷的、精益的、实用主义的决策往往是符合中庸之道的：它们往往是各种因素、选择权衡之后的结果。敏捷方法极端重视提升客户价值，为了达到这个目标而采取的手段通常都不可能是极端的。

中庸之道常常有效的深层原因是边际效用递减律：对一个方面的东西重视到一定程度以后，再加入更多的重视，收到的边际效用递减；同样的重视度放到另一个方面上，能够收到更大的边际效用。让每一分投入收到最大的回报，尽可能地消除浪费，这是精益的追求。

在另一篇Blog里我谈到了如何进行精益设计。设计方案的选择说到底应该是一次成本与收益的计算，而不是个人审美取向的衡量——当然，优秀的程序员能够把这种计算变成本能，我认为这就是“软件开发的艺术”所在。敏捷方法强调“简单设计”，同样是经过计算的结果。

在面对一个复杂并且灵活的设计时，首先要衡量的不是实现它的收益，而是“现在实现它”与“将来实现它”之间成本的差额。不论一个灵活的设计的收益和成本如何，只要这个差额非常小——等到未来实现它也没有什么额外的困难，就应该毫不犹豫地推迟决策，等到真正需要的时候再引入灵活的设计。感谢现代化的IDEs，很多时候我们讨论的这个成本差额确实非常小，这是敏捷设计通常取简单方案的原因所在。

值得注意的是，随时进行这种成本与收益的计算并不是一件易如反掌的事。计算本身也有成本。这是最佳实践和工具支持存在的意义所在：你可以用较低的成本得到前人积累的知识。例如ThoughtWorks在介绍其项目管理工具Mingle时特别指出其中融汇了该公司多年从事敏捷软件开发的经验：

Mingle是一个敏捷项目管理工具。它为整个团队在软件交付过程中提供“一站”式服务，并通过有10年敏捷项目开发经验的ThoughtWorks公司提供的开发框架共享所有的项目成果。我们带来了敏捷开发方法，同时Mingle将会支持和推动这一切工作。

畅通的信息渠道，清晰的成本/收益核算，全面消除浪费，这是精益制造的核心所在，也是敏捷软件开发的核心所在。

敏捷反馈循环的重要性

敏捷社区的一些成员强调了反馈循环对于提高敏捷开发流程效力方面的重要性。

“反馈循环”是什么呢？简单来说，如果某个流程的执行结果可以影响到此流程未来的运作方式，那么它就存在反馈循环。

在敏捷开发流程中存在哪些类型的反馈循环呢？在Henrik Kniberg和Mattias Skarin的著作《看板与Scrum：把两者发挥到极致》（Kanban and Scrum: Making the Most of Both）中，他们描述了Scrum和XP中的一些反馈循环。他们提到的一些在较短时间内形成反馈循环的XP实践，包括：

• 结对编程
• 单元测试
• 持续集成

而需要较长时间才能形成反馈循环的Scrum实践包括：

• 每日站立会议
• Sprints

然而，在所有例子中，这些反馈循环背后的主要目的就是迅速提升流程能力。正如Kniberg和Skarin所说的：

做些改变=>搞清楚它的实施状况=>从中汲取教训=>再做些改变。一般而言，你会希望反馈循环尽可能短，这样就能迅速优化你的流程。

Rune Sundling最近的一篇博文提到了更多能够支持敏捷反馈的实践：

• 代码审查
• 静态代码分析
• 自动集成测试
• 自动验收测试
• 你与客户或者业务专家紧密协作，贯穿项目过程
• 高频率发布（至少发布至测试环境）

除了流程和生产力的改进，紧凑的反馈循环还能使团队成员在工作方面感觉更好。 Lisa Crispin指出：

如果我们实施“持续集成”这一实践，对每个代码新版本做回归测试，在几分钟或几个小时之内我们就可以知道新写的或者更新后的代码是否导致别的功能不能工作。一旦我们第一时间发现，修正起来就很容易。问题不会困扰我们，因为我们知道我们能够及时修正它们，继续前进。

较短的反馈循环使我们信心倍增。有了信心，我们也就乐在其中。

查看英文原文：The Importance of Agile Feedback Loops

敏捷可用性

可用性专家和《可用性工程》的作者Jakob Nielsen，最近提出了这样的担心：敏捷方法对使用传统方式设计可用性会造成威胁。他说敏捷对可用性的最大威胁是，“它是一个由程序员提出的方法，主要关注系统开发的实现方面”。

Alistair Cockburn说这种说法完全不对：

1. 谁提出观点并不重要，重要的是观点是否够好。
2. 这引起社区中“我们对他们”的分裂，而不是“我们加他们”的合作。
3. 与Nielsen提到的其他威胁不同，他并没有提出解决方案，所以把“我们对他们”这个悬而未决的问题留给我们，这是不能接受的。

建议方案: 好的观点拿来用就行了——不要担心它们的出处。像Kurt Morris在敏捷可用性发贴中说的：“一旦消除了“我们对他们”的敌对心态，你就会见到令人惊羡的成果。”

Nielsen 继续提出这样的问题，敏捷习惯把故事分成更小的任务，这允许以不一致的方式开发功能，有可能掩盖了总的用户体验。他说，最糟糕的是“用户界面最终会看起来像缝缝补补”。Nielsen's的解决方案是：

• 快速重复地执行可用性测试。他说“每周测试完全可行，即使在最短的sprint开发周期，也肯定能让你整合用户的多轮反馈。”
• 采取并行轨道，让可用性工作比开发工作更早一步完成。
• 采用不需编码的低仿真原型(比如纸)，把前面花费的时间减少到最小。

Jeff Patton 提炼了12个可用性的最佳实践(与Nielsen的相呼应)：

1. 驱动：用户体验从业者是客户或者产品所有者团队的一部分
2. 前期研究，建模，设计——但是只需要够用就行了
3. 分解大块设计工作
4. 采用并行轨道开发，提前工作，后期跟踪
5. 从复杂故事中争取设计时间
6. 培养用户验证小组，以方便持续用户验证使用
7. 在单独轨道中进行用户持续研究，与开发分离
8. 平衡用户多个活动的时间
9. 开发前采用RITE方法对用户界面进行迭代
10. 低真原型
11. 把原型当作详细说明
12. 成为设计的协调者

Jeff描述的RITE(pdf) 方法来自于微软的游戏工作室：“RITE与传统的可用性测试不同，它强调极快的变化，并验证这些变化的有效性”。具体来说，一旦发现问题，方案受到影响， 从业者就修改用户界面(原型或者应用程序)。在另一个参与者到来之前，诸如重命名按钮、修改菜单条目文字这样的变化经常发生。更复杂、但是很明显的变化是 越快越好，这样变化就能被尽快地测到。

除此之外，Jeff发现他的角色发生了变化：“由于我开始在敏捷团队内工作，我变得喜欢协同设计。我发现自己越来越多地扮演着协调者的角色：从大规模人群中收获信息并对信息建模。我发现自己同一群群的用户和开发者一起工作，撰写用户场景，起草用户接口设计。”

最后，Alistair 说道(在提到开发者/可用性分歧时)：“谨记住，'只有我们'。”

查看英文原文：Agile Usability

敏捷书籍推荐

最近 Mike Cottmeyer推荐了一系列书籍，为传统项目经理和新团队提供转向敏捷的参考。他列出了下列书籍，同时给出了选取它们的简短原因。

• 解析极限编程——作者：Kent Beck。书中提到XP的相关实践和成功秘诀，让所有的敏捷项目管理人员和领导者都念念不忘。
• Managing Agile Projects with Scrum——作者：Ken Schwaber。在解释如何使用Scrum做项目管理方面做得非常出色，而且对于刚刚接触敏捷的人来说也非常有价值。
• 敏捷估计与规划——作者：Mike Cohn。如果你已理解了基本理念，希望将规划加入到敏捷中，请阅读本书。
• User Stories Applied——作者：Mike Cohn。将需求撰写成对客户有价值的功能线索，要理解这一点挺难的，本书可以帮你做到更好。
• Agile Software Development—— 作者：Alistair Cockburn。进阶敏捷实践人员的必读书，将软件开发描述为合作游戏，类似于音乐演奏者在舞台上的即兴演奏。
• Software Project Manager's Bridge to Agility——作者：Michele Sliger与Stacia Broderick。将PMP背后的流程映射到敏捷。是试图管理敏捷项目的PMP的必读书。
• Scaling Lean & Agile Development——作者：Bas Vodde和Craig Larman。为敏捷如何扩展到企业提供了合理的视角。
• Scaling Software Agility——作者：Dean Leffingwell。在复杂的企业范围内描述如何扩展敏捷。
• Managing Iterative Software Development Projects——作者：Kurt Bittner和Ian Spence 。更多地关注RUP，但是在迭代和增量式软件项目管理方面做了很扎实的说明。

这个列表中的更多书籍可以在“史上最好的20本敏捷开发书籍”中找到，由Jurgen Appelo完成。Jurgen使用了下列方式来产生列表。

1. 亚马逊评论数目
2. 亚马逊平均评分
3. Google点击数
4. Jolt得奖情况

Jurgen的列表中还包括：

• 敏捷软件开发：原则、模式与实践—— Robert C. Martin
• 重构——改善既有代码的设计—— Martin Fowler
• 程序员修炼之道：从小工到专家—— Andrew Hunt，David Thomas
• 敏捷软件开发工具——精益开发方法—— Mary Poppendieck与Tom Poppendieck
• Crystal Clear——小团队的敏捷开发方法 —— Alistair Cockburn
• 测试驱动开发 —— Kent Beck

Agile Tortoise 也 推荐了一系列敏捷书籍 并将它们按照下列类别进行了分类：

• 敏捷项目管理
• 项目需求、估算和规划
• 开发
• 持续过程改进

Ryan Cooper 推荐了他自己的 100本敏捷必读书 ，供实践敏捷开发和对敏捷好奇但仍存有疑心的人参考。除了上面提到的书之外，Ryan还提到一系列与人、沟通和风险管理相关的书。他的列表包括

• 目标：简单而有效的常识管理—— Eliyahu Goldratt
• Fearless Change: Patterns for Introducing New Ideas—— Mary Lynn Manns和Linda Rising
• 与熊共舞——Tom DeMarco与Timothy Lister
• 关键对话——Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler
• 人件——Tom DeMarco与Timothy Lister

查看英文原文：Recommended Agile Books