引言

就在上月底，MD 发了一封关于敏捷实践的讨论到 China 邮件组，场面是非常激烈，当时并没有参与讨论，但回顾看了每一个人的讨论和观点，我自己也在思考，为什么现在大家的认知和理解产生了如此的分歧，我个人觉得这在某种程度上算一种“橙色”信号，有时候自己都开始怀疑之前的认知，都会变得不确定和不自信了。好在已经有了争论，有争论就要反思找到问题的根源，那就要有实际的行动来解决问题，达成统一的认知基准，不过在组织大面积实施 Action 之前，就我个人而言，决定好好回顾一下之前在入职前和 TWU 时受到的敏捷文化熏陶和洗礼，同时结合书籍文章及在项目日常工作中遵循的敏捷实践来总结一下，正所谓是温故而知新。

刚好最近也受到好友 姜姜姜 之邀，希望在5月6号的『中国开发者关系大会』成都分会场线下分享一个话题，想来想去，那就分享关于敏捷实践和文化的话题吧，正好最近也在思考这个问题，而且自己对于敏捷实践和文化还是有一定理解的，也希望用通俗易懂的表达来阐述一下我理解的敏捷实践和文化，同时也想与大家一起交流探讨，或许我的理解也并不完整，因此，除了准备 Keynote，还是打算写这一篇博客，也好从整体上捋一捋自己的思路，多一些探讨和交流。

敏捷开发是什么？

敏捷(Agile)不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程(XP, Extreme Programming), Scrum, 精益软件开发(Lean Software Development), 动态系统开发方法(DSDM, Dynamic Systems Development Method), 特征驱动开发(FDD, Feature Driver Development)，水晶开发(Crystal)等，不过最为常用的当属 Scrum 和 XP 了。
图片来自网络

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法，即把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨。敏捷开发的特征包括：迭代式开发、增量交付、开发团队和用户反馈推动产品开发、持续集成和开发团队自我管理。敏捷开发具体实践通常采用 Scrum 和 XP(极限编程)，在后续内容中会进行详细的介绍。

谈到了敏捷开发，不得不提到敏捷软件开发宣言(简称敏捷宣言)，敏捷开发是需要遵循一些共同的价值观和原则的。

敏捷软件开发宣言

2001年，在美国犹他州瓦萨奇山雪鸟滑雪胜地，由17位专家组成的代表团制定并宣布了 敏捷软件开发宣言。

官方翻译如下：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

特别要提醒的是，敏捷宣言一共是6句，而并不只是中间4句价值观，第一句很重要，最后一句更加重要。从第一句中可以体会到，敏捷宣言是通过不断实践总结出的价值观，是一种思维的导向和转变，是能够影响我们所做的每一件事情。而最后一句传递的意思是，敏捷宣言并不是否定右项的价值，并不是表达舍弃右项实施左项，而是在承认右项价值的同时更重视左项的价值，它们是可以共存的，为了树立正确的敏捷价值观，千万不可断章取义错误地传递了敏捷宣言。

敏捷宣言遵循的十二条原则:

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。

需要强调的是，敏捷的价值观应遵照敏捷宣言，而不是简单粗暴地指向具体实践的价值观，通过实践来把握和体会敏捷宣言的价值观及其遵循的十二条原则，从而在不同的上下文和团队中达到一个有效的共识。

为什么要敏捷开发？

长期以来，满足用户不断变化的需求是软件开发的难题之一。软件开发是一个复杂的活动，其过程中存在着需求的不确定性，也存在着技术的不确定性，更存在着团队和人员因素，软件开发方法一直处在不断发展过程中。
图片来自 scrumcn.com

经典的瀑布模式把整个开发过程分为收集需求、定义、设计、编码、测试、发布等阶段，每个阶段设定明确的目标和标准，然后一步步按可预测计划实施，最终交付产品，但一旦需求变化，特别是在项目后期，瀑布模式显得力不从心了，因此，需要新的方法来解决这一问题。

而敏捷开发模式通过迭代来适应需求变化，每一次迭代周期结束后都可以生产或开发出一个可交付的软件产品，用户使用并体验，从而能够更早及时地收集用户反馈并处理需求变化，即从 计划驱动 转向为 价值驱动，这是一个新的软件开发趋势。敏捷开发注重的是人与人之间的交流，强调以人为核心，在高度协作的环境下，不断的通过反馈来进行自我调整和完善，从而能够全面提升团队的效率，敏捷开发以其能持续满足不断变化的用户需求的优势，已成为众多高效开发团队的制胜之道。

不过也不要对敏捷开发产生误解，敏捷开发不是银弹，它不是一个普适的方法，而是具有一定语境和背景的。如果当团队连 自己要做什么事、为什么这样做、这样做为了解决什么问题 都搞不清楚的情况下，那么敏捷开发不适合这样的团队，同时团队还要依赖于 成员之间是否相互信任、是否与管理层之间建立了信任、是否与客户之间建立了信任 等等因素。敏捷转型有很多成功的案例，当然也有很多失败的，敏捷开发的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。

如何实践敏捷开发？

敏捷开发具体实践通常采用 Scrum 和 XP(极限编程)，通常的做法是，在管理模式上启用 Scrum，而在实践中，创造一个适合自己团队的 XP。那接下来就分别进行详细介绍。

敏捷实践之 Scrum

Scrum 是一个用于开发和维持复杂产品的框架，是一种增量的、迭代的开发过程，通常用于敏捷软件开发，它并不等同于敏捷，Scrum一种流程，而敏捷是一种理念，Scrum 非常突出团队自组织能力。

图片来自网络

Scrum 是橄榄球运动的一个专业术语，原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。比喻在 Scrum 敏捷开发流程中，开发团队在开发一个项目时，大家像打橄榄球一样迅速敏捷，富有战斗激情、人人你争我抢的拼搏精神，可以看到一个兴奋的团队作为一个整体在高效地工作。

在 Scrum 框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 的建议长度是2到4周，互联网产品研发可使用1周的 Sprint。在 Scrum 中，使用 Product Backlog 来管理产品的需求，Product Backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为 用户故事。在 Sprint 中，Scrum 团队从 Product Backlog 中挑选对客户具有较高业务价值的需求作为最高优先级进行开发，挑选的需求在 Sprint 计划会议上经过讨论、分析和 估算 得到相应的任务列表，称之为 Sprint Backlog 。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量，Scrum 适用于复杂的或创新性的项目。
Scrum框架 (图片来自网络)

通常，在 Product Backlog 之前还会有更大粒度的产品需求形式 Epics，包含了 用户故事。另外，在每天同一时间，在可视化的任务板前面召开10分钟左右的 每日站会，通常针对故事卡更新 昨天完成了什么任务、今天打算做什么任务、遇到了哪些障碍或困难，所有人都可以看到当前每个任务的状态和 燃尽图(Burn Down Chart)，在每个迭代结束时，还要 Sprint Retrospective 回顾上个迭代并提出改进。

一个 Scrum 团队是自组织、跨职能的完整团队，团队自己决定如何最好地完成工作，其包含三个角色:

  • Product Owner: 即产品负责人，负责最大化产品以及开发团队工作的价值。
  • Scrum Master: 负责确保 Scrum 被理解并实施，并服务于产品负责人、开发团队和组织。
  • 开发团队: 负责交付潜在可发布的产品增量，成员有5-10人，通常包含 PM/BA/UX/DEV/QA。

Scrum的五个价值观：

  • 专注(Focus) – 一次只关注一小部分事情，把心思和能力用到团队工作上，输出价值
  • 勇气(Courage) – 有勇气做出承诺，履行承诺，接受挑战，作为一个团队相互支持
  • 开放(Openness) – 以开放地心态一起工作，全方位展现出工作的做事方式和关注点
  • 承诺(Commitment) – 愿意对目标做出承诺，愿意一起付出，更致力于成功
  • 尊重(Respect) – 每个人都有他独特的背景和经验，一起分享成功，承担责任，相互尊重

但仅仅在软件开发部门实施 Scrum 是不够的，这不足以达成真正的敏捷，很多公司忽视了在企业文化、管理风格、流程以及项目执行方法上的必要改变，如果理解和使用不当，可能会更加低效。

敏捷实践之 XP 极限编程

XP 是一种灵巧的轻量级软件开发方法，它强调把列出的每个方法和思想做到极限、做到最好，是敏捷软件开发中很著名的一个，XP 是针对业务和软件开发的规则，注重严格的工程实践约束。

极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性，软件需求的不断变化是很自然的、不可避免的现象，极限编程的主要目标在于降低因需求变更而带来的成本，一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
极限编程实践 (图片来自网络)

极限编程有如下一些核心实践，但并不要求满足所有，通常会根据团队情况进行一些裁剪和自定义：

  • 完整团队(Whole Team): 项目的所有参与者(开发人员、客户、测试人员等)工作在一起，是同一个团队的成员。
  • 计划游戏(Planning Game): 结合项目进展和技术情况，根据商业价值确定下一阶段要开发与发布的系统范围，计划是持续的、循序渐进的，随着细节的不断变化而完善。
  • 小型发布(Small Release): 采用迭代的交付方式，每个迭代1-3周时间，在每个迭代结束的时，团队交付可运行的经过测试的功能，及时处理用户反馈。
  • 客户测试(Customer Tests): 客户可以根据脚本语言定义出自动验收测试来验证功能正常运行。
  • 编码规范(Coding Standard): 开发人员都遵循统一的编码标准和规范，每个开发人员更易读懂别人的代码，尽可能减少不必要的文档，这也是实现代码集体所有的重要前提之一。
  • 可持续的速度(Sustainable Pace): 以能够长期维持的速度和精力努力工作，把项目看作是马拉松长跑，而不是全速短跑，团队只有持久才有获胜的希望。
  • 系统隐喻(System metaphor): 用普通语言和术语的集合来预见项目中的功能，通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。
  • 持续集成(Continuous Integration): 频繁地通过自动化的构建(包括编译，发布，自动化测试)提供可运行的版本进行集成验证，从而尽快地发现项目风险和集成错误。
  • 代码集体所有权(Collective Code Ownership): 每个成员都有更改任意部分代码的权利，所有的人对于全部代码负责。
  • 测试驱动(Test-Driven Development, TDD): 在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。
  • 重构(Refactoring): 在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高设计的可重用性。
  • 简单设计(Simple Design): 只处理当前的需求使设计保持尽可能简单，这些设计将在后续的开发过程中就被不断地重整和优化，整个设计过程是个螺旋式的、不断前进和发展的过程。
  • 结对编程(Pair Programming): 由两位成员在同一台电脑上共同编写解决同一问题的代码，形式有多种，可以通过参考 扩展阅读 了解更多。

除了最佳实践，极限编程还提倡四大价值：

  • 沟通(Communication)
  • 简单(Simplicity)
  • 反馈(Feedback)
  • 勇气(Courage)

极限编程是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其它一系列的方法，团队和客户能够非常清楚掌握开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

关于 Scrum 和 XP 的区别可参阅『Differences Between Scrum and Extreme Programming』。

敏捷实践与文化的融合

人就是核心，筑成优秀的团队

拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。在平时的日常工作中，会根据每个项目情况而为团队分配有不同的角色人员，针对国内和国外项目的人员分配也会有一些调整，通常的角色包括: PO、PM、IM、BA、DEV、UX、QA 等，一般10个人左右。而大家最重要的目标是，通过持续不断地及早交付有价值的软件使客户满意，欣然面对需求变化，帮助客户提升竞争优势。

扁平化结构管理 & 开放式办公环境

只有打造一个相对扁平的组织，给予充分的信任和自由度，才有利于敏捷的实施，换句话说，这就要求团队中的每个人有高度的自律性。在公司内部管理上，采用的是扁平化结构管理，开放式办公环境，每个人处于一种平等状态，每个人都可以面对面自由地交流，鼓励并引导大家相互主动给反馈(Feedback)、寻求反馈、接受反馈，同时针对反馈付出行动进行自我调整和完善，通过双向反馈机制让每个人每天都正面面对工作和生活，团队与成员都可以保持提升，形成良性循环。

用户故事 & 持续集成/持续交付

敏捷开发的日常实践已经形成一种常态，在工作中，每天都会看到的 看板/故事墙、燃尽图(Burndown Chart)、CI/CD Pipeline 等。通常会借助一些工具来辅助可视化，对于故事墙，根据不同项目的性质会选择采用不同的形式，大多情况优先选择使用物理墙，而对于一些海外交付项目会考虑选择使用电子墙，如 Jira、Mingle、Trello 等，目标都是更好地管理项目和跟踪任务，能够清晰地展示出当前迭代的进度和团队成员工作状态；对于 CI/CD 工具，可以选择使用 GoCD 、Jenkins 等，通过持续集成工具可以实现快速自动化构建、部署以及状态反馈，包括代码质量、自动化测试等。

故事墙示意图故事墙示意图
CI/CD示意图CI/CD示意图

结对编程 & 测试驱动开发

结对编程在工作中运用得非常普遍，从团队长期发展来看，确实有很多优势，可以保持更加专注，提高解决问题的效率，促进沟通与协作，传递知识和共享信息等，帮助提升团队整体能力和凝聚力。测试驱动开发(TDD)也是在项目开发很常用的一项实践，而且也是我司非常推崇的其中一项实践，是进入公司后必备的技能之一，通常对于新人的培训都会从 TDD 和 Pair 开始，TDD 的好处我就不想在这里讨论，倒是可以单独起一个话题讨论的，不过很多人一直对 TDD 和 Pair 有一些争论，但我一定投赞成票的，我相信当你尝试之后会乐此不疲的。

持续学习与分享，满腔热情突破自我

Our mission is to better humanity through software and help drive the creation of a socially and economically just world. —— www.thoughtworks.com

We ThoughtWorkers 满怀激情的汇聚在一起，以引导软件创新、设计和交付的革命为己任，助推全球社会变革。每个人都拥有一颗追求软件卓越的心，保持高涨的学习热情，持续不断地学习，乐于分享，敢于突破自我，在这样的团队中工作是一种相互促进，共同进步！

总结

文中主要介绍了什么是敏捷、敏捷软件开发宣言、为什么要敏捷开发以及如何实践敏捷开发，针对敏捷开发实践详细介绍了 Scrum 和 XP(极限编程)，同时也结合平时的工作概括介绍了敏捷实践与文化的融合，最后再来谈一下自己的一些观点。

首先，不要对敏捷产生误解，敏捷不是一个普适的方法，并不适合所有团队，敏捷开发的适用范围主要包括：团队规模相对较小、项目经常发生变更、高风险的项目实施、开发人员可以参与决策、团队成员能够自组织等。敏捷转型有很多成功的案例，当然也有很多失败的，敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。

另外，拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件，只有打造一个相对扁平的组织，给予充分的信任和自由度，才有利于敏捷的实施。人是敏捷开发的核心，敏捷开发总是以人为中心建立开发的过程和机制，在团队中，每个人有高度的自律性，无论是团队还是个人都应坚持做到持续反馈、拥抱变化。

最后，在敏捷实践过程中，要因时而变，拒绝盲目套用方法论，但更要多实践，多反思，多分享，让敏捷成为一种习惯和基因，一句话高度概括为：Being Agile rather than only doing Agile!。在平时的工作中，我们所提倡的敏捷实践还是要做的，而且还要用心做好，不能只谈“心法”，如果基本的敏捷实践都做不好，那就更难达到敏捷的精神，就好像是一位剑客连剑都拿不起用不好，又何谈手中无剑心中有剑，又如何达到无招胜有招的境界呢！

敏捷提倡的以价值为导向的高响应力小团队结构，而针对大型组织里如何落地，有兴趣的朋友可以进一步了解 扩展阅读 中的 精益企业 相关内容。

References

扩展阅读: