一、敏捷的定义
怎么去定义敏捷，首先敏捷是一种方法，也可以理解为一种理念，一种价值观，它不是我们在解决工作中某些具体问题时使用的一种对应工具，而是贯穿于工作当中的一种方法和理念。我是这么来理解敏捷理念如何指导项目实践的，就像人的价值观，不为解决我们生活中衣食住行任何具体的问题，但是我们思考每一个问题的过程，做出的每一个选择，都是在价值观的指导下完成的。这也可以映射到敏捷的理念指导项目实践的方式。
敏捷最初是从软件开发领域诞生的，这就是我们经常讨论的敏捷开发-Agile。敏捷概念诞生的标志，是在2001年2月， 17位著名的软件开发专家在美国犹他州雪鸟滑雪场举行了会议，会议中正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。敏捷宣言是一个非常简洁但是极为重要的宣言，指导了后面十几年的敏捷推广和应用。虽然Agile的概念是在2001年被提出，但这并不是说敏捷开发实践是在2001年才被提出。雪鸟会议其实是对之前几十年中软件开发实践探索的总结，是水到渠成的一个结果。
到了2020年的今天，距离雪鸟会议也过去了19年，我们所讨论的敏捷，以及敏捷理念很多时候已经不仅仅是知道软件行业做敏捷开发，还会延伸到很多领域，例如对于传统行业转型，组织变革等等，因为他们也要对不断变化的环境、市场做快速响应和迭代。
二、为什么要敏捷？
前面我们对敏捷做了一个概念化的定义，那既然敏捷影响力如此之大，几十年来可以指导多个领域的发展变革，那敏捷开发到底诞生于什么样的背景之下，可以解决哪些问题，才使得它如此受到推崇和关注呢？这个就要从敏捷得到定义之前，当时非常主流的一种软件开发方式，瀑布式开发说起。
1、瀑布模型
瀑布式开发是一种预定义过程的方法，严格遵循确定的计划。下图就是一个典型的瀑布式开发的模型，从需求的产生、定义、设计，到代码开发、测试，再到发布和管理，其实是一个非常稳定的计划。
瀑布式开发的特点是每个阶段之间都有强烈的依赖关系，前一个阶段被当作是后一个阶段的输入，如果这个输入质量不高，那就会严重影响后续阶段的输出质量。例如设计阶段出现了某个错误，会造成后续的阶段都累积这个错误，并且随着计划的不断推进，修改错误的成本会越来越高。随着累积的工作成果越来越多，后续去改动、调整整个软件的风险就会越来越高，所以，瀑布式开发是一个随着计划推进风险递增的开发模式。因此为了减小风险，在瀑布式开发中就需要预先有非常确定的需求，因为这套开发模式响应变化的能力是比较弱的。
但这并不是说瀑布式开发已经因为它的局限没有价值了，相反，它是有自己适用的场景的，那就是一些可以完善定义且不易变更的软件系统。在这种场景下，瀑布的这种确定的计划性会相当的有效率，我们经常拿富士康来做类比，富士康的流水线，是一套非常确定，分工极为明确的流水线，对于生产一批确定规格的产品，富士康是有相当确定的计划性的，哪几条流水线分别生产什么零件，再由其他流水线完成组装，因此富士康才能有如此之高的效率，为全球性的手机厂商供货。如果我们在富士康的生产过程中，要让它能不断响应变化，不断去改变零件的参数，那对效率是会有非常致命的影响的。
2、数字时代的挑战
上文中介绍到，瀑布式开发适用于可以完整定义，不易改变的系统，但是在我们如今的数字时代，这一类的系统可能越来越少，或者说已经不再是主流。
因为数字时代市场需求是瞬息万变的，从20世纪60年代，到现在的21世纪20年代，根据真实的数据统计和基于真实数据的周期性预测，世界范围内企业的平均生命周期是在明显缩短的，相对应的，软件产品的生命周期也在急剧缩短。在较短的生命周期中，很少有公司能像瀑布式开发那样，持续投入资源憋大招，等长达几年的时间，完成一个产品的生产和发布，这个资源变现的过程太久，已经是很多现代化公司所不能承受的。
并且，随着市场变化，人的因素对软件产品开发的影响也愈来愈不可忽视。之前的系统，由于网络、设备等等因素的限制，用户数量非常有限，但随着移动时代的到来，动辄千万甚至上亿的用户，这在互联网，尤其是移动互联网领域大家的感受会更加明显。用户群体扩大，用户价值成为关键性的价值，这已经是一个不可逆转的趋势。但是，在广阔的用户人群中，人们的使用习惯、市场的风向都在快速变化，这就要求企业需要一种及时、快速的交付形式，能够及时地响应这些变化才能在市场竞争中活下来。因此，瀑布式的软件发布频率已经远远不能适应这种市场需求了，市场越来越倾向于小步快跑式的产品迭代模式，快速发布、快速验证、快速调整才能让企业以最小的投入完成试错，获得正确的方向。
另外，大部分的软件系统由于历史积累、业务扩展等原因，正在变得越来越复杂，已经很难实现产品需求明确并且完整的收集，同时，由于技术的发展、更新换代也很快，对于所定义的功能实现性也面临着多种不确定性的因素。所以，当需求收集和产品定义的工作没办法很好完成的时候，瀑布式的开发方法自然也摆脱不了高失败率的命运。
所以当需求越来越不确定，系统越来越复杂，瀑布模型的适用前提便受到了挑战。
复杂系统
对于复杂系统，我们可以看一个非常典型模型——Stacey模型。
如下图，Stacey模型是一个描述系统复杂度的模型。在这个模型当中纵轴代表需求的确定性，从下至上，分别是需求可以达到一致，还有需求很存在分歧，也就是从下至上，需求的不确定性增高。横轴代表技术实现的确定性，从左至右，分别是技术实现非常确定，还有技术实现存在着较大变化，也就是从左至右，技术实现的不确定性逐渐增高。
需求的不明确性和技术、也就是工程实现的不确定性有一个阈值，在阈值内，需求相对确定，实现方法也相对明确，所以一般称为简单系统。简单系统是适合传统的瀑布开发的，他可以收集到确定的需求，可以按计划去实现，效率也会比较高。
但是当需求的不明确性和技术的不确定性超出了这个阈值，那就把它称为较为复杂或者非常复杂的系统，都属于复杂系统，这时候，瀑布方式因为无法明确的前提就不再适用，就需要用到敏捷这种迭代和循序渐进的方法。举个例子，在《用户故事与敏捷方法》中，当一个用户故事复杂到无法评估的时候，书中提供了两种方式来解决这个问题：第一种是拆解，故事无法评估是因为实在太大了，把大的故事根据一些事件等维度拆解为多个小一些的故事，这样分别去评估这些小故事，就会相对容易评估；第二种情况是由于故事的实现方案非常不确定，那就把这个故事分离出一个spike探针方案和一个具体的实现方案，确定实现方法后，再去评估实现，这样也可以达到简化问题的目的。其实这些都是敏捷的理念的应用，就是通过将复杂问题降维，一种降维打击的方式，来解决问题。
3、敏捷模型
上文提到，由于市场变化、系统越来越复杂、人的影响因素越来越高，这个背景下，瀑布开发的模式已经很难适用，我们推荐敏捷的方法来应对这些问题。那敏捷模式下具体是怎么去工作的？
先给出一个标准的定义，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在下图中可以发现，敏捷是一个滚动推进去实现最终价值的模型，在敏捷中，我们将一个具体产品的开发分为多个sprint迭代，分别去完成一部分产品的需求设计、开发测试和发布，在这个过程中，我们每次仅需确定当前要做的迭代的需求和技术实现即可，后面迭代的需求，可以是一种不确定的、粗粒度的状态，这是一个近细远粗的计划方式，因为每个迭代周期相对较短，也就是几周的时间，可以不断的在后续的迭代中去确认、响应变化，这样来循序渐进地去完成产品的整体价值。
在这个过程中，最开始的时候，由于远期需求的不确定性最高，可能是风险最大的时候，但是随着迭代的不断完成，产品整体的确定性却来越高，风险也会逐渐降低。
有个非常经典的比方，就是有一天，你和朋友去餐厅吃饭，你们点好了十个菜，但等了40分钟，都快饿过头了，也没吃上。你有点着急，便询问服务员，服务员说后厨要把十个菜全部做完才能上菜。结果好不容易10个菜都做完上来了，你觉得菜口味不对，太咸，跟服务员反应，服务员却回应说菜已经都做好了，想加点配料还行，想减盐已经做不到了。可想而知，你吃完这顿饭肯定是不满意的，现在应该也没有餐厅这么做生意。那一般餐厅是怎么解决这个问题的呢，在你十个菜点完之后，后厨做完一个，就先上一个，这个过程中，顾客的口味有什么要求，还可以随时反馈，比如第一道菜觉得咸了，后面的九道就可以得到调整，你就能吃到整体上还算合口味的菜。这其实就是一个瀑布模式和敏捷模式很直观的区别。 总结起来呢，就可以用到王总的一句话，敏捷就是在面对一个很大的任务时，先定一个小目标，一个能达到的小目标，例如一个亿~
敏捷三角
根据上文总结来讲，对于瀑布开发，是计划驱动的，一般情况下合同谈判后基本就确定了软件的scope，这个scope一般是确定的，然后项目组制定计划并且遵循计划，而时间和资源相对于范围会弹性一些。
而对于敏捷开发，一个核心的思维模式转换就是，从瀑布开发代表的“固定范围，弹性时间、资源”，转向“固定时间、资源，弹性范围”。为什么这么说？在市场变化和技术变化的背景下，既然市场需求和产品定义所代表的范围都没有办法实现固化，那可以从这个角度去触发，固定好资源，以资源为约束，来确保在有限的时间和资源里做最有价值的事情，也就从计划驱动转向价值驱动。
那我们就可以和传统项目管理三角对照一下：
传统的项目管理里面，尤其大家学习过PMP的话应该比较清楚，传统项目管理从范围、时间和成本三个维度将所有任务锁定在一个稳定的三角形内，然后有条不紊的达到规划的目标。在这个三角里面：
范围：基本在项目前期已经规划好，并且有为完成项目所需要的详细待办任务清单，在后续执行的过程中很少会去进行调整；在传统的项目管理中对于变更的管理是非常严格的，要经过一串很长的程序，例如变更委员会之类的审批，因此基本可以理解为传统项目管理里面是不提倡变更的。
时间：完成范围内待办任务所需要的时间投入；
成本：完成范围内待办任务所需要的成本投入。
而在当前的时代背景下，软件领域快速发展、客户要求的不断提高、需求也不断变化，我们很难以保证在自己先期投入大量成本的项目规划是准确无误的，因为对于变化我们很难以去预判，也难以去管控。传统的敏捷三角难以适用，所以我们更需要不断的尝试和总结，就得到了更能体现这类项目特点的敏捷三角。
敏捷三角中，价值是一个非常重要的基点。
价值：来保证任务团队将目标聚焦在客户和用户的视角，软件用来交付他们需要的价值，而非站在项目角度去完成对应的待办任务。
质量：软件行业发展至今，用户对软件的依赖越来越强，要求也越来越高。
约束：制约用户价值和软件质量的因素，由传统项目管理三角型中的范围、时间和成本构成。
对于传统三角的范围不变，敏捷三角不一样，在既有的约束条件下，我们会高质量的优先完成高价值的事情。敏捷三角相较于传统三角，将范围从固定演进为可变以灵活适应市场的变化，将目标聚焦于客户价值而非既定任务，加强质量的权重以提升终端用户的体验。价值驱动的项目管理方式在当前的软件时代背景下显然是优于计划驱动的管理方式的。
4、瀑布与敏捷对比总结
上面我们从瀑布开发模式及它的局限性，聊到了敏捷怎样去解决这些问题，怎样去跟软件发展、市场发展更好的适应。所以，我们可以来总结和对比一下，对于瀑布，它的特点是确定的计划和高效率，瀑布模式中，需要尽早锁定需求和细节，也就是范围要是确定的。需要计划完整的问题和难度，也就是需要去计划项目整体的需求细节。在实现过程中，按照计划，一次性走完开发、测试、发布这些流程。需要严格地按照计划进行，当然，如果一个大项目完全没有变更也不现实，但瀑布不提倡变更，要有严格的变更控制措施，来保证计划的贴合性。
而对于敏捷，敏捷的特点是响应变化、迭代和价值。支持持续地而不是一次性地区挖掘产品的需求，对于复杂的问题，复杂的系统，提倡把问题做分解，降低解决的难度。也正是因为敏捷不需要在前期投入大量资源去完成确定的需求设计，所以敏捷可以更快地开始，做到move fast，逐次、循序渐进地增量式开发。并且，敏捷始终是拥抱变化，积极响应变化的，因为敏捷是一种近细远粗的计划方式，对于需求范围不明确，需求变更较多的项目而言，是支持针对计划做适应性调整的。通过这种方式，敏捷开发其实可以最大程度体现80/20法则的价值，20%的功能可以产生80%的效益，通过增量迭代，每次都优先交付价值最高的20%的功能。实现最大化收益。
三、敏捷理念的框架
我们了解了我们为什么要敏捷，那敏捷究竟包含哪些内容呢，他的whole picture是怎样的，敏捷代表了什么样的价值观来指导我们的工作，提供了哪些原则，积累了哪些实践，下面我们就可以仔细来了解一下敏捷的框架。
敏捷的框架，包含敏捷的道、法和术。道，都说悟道，道是最根本的原理，是值得不断去钻研和领悟的，法，则是方法，就是指导方法，也可以理解为对到的解读和方法论延伸，而术，则是道和法的具体应用。
我们可以去把敏捷的框架形象地类比到一棵大树，大树有树根、树干和树冠，树根作为大树生存的根本，可以为大树本身源源不断提供养料支撑，这对应到敏捷，就是敏捷的道，代表了一种价值观，价值观是理论发展和实践的根基，而树干是敏捷的原则，树冠上的内容可以根据敏捷宣言和敏捷原则不断衍生出来新的实践，所以敏捷也是不断在进化，保持活力。
1、敏捷宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体与交互OVER过程和工具
可用的软件OVER详细的文档
客户协作OVER合同谈判
响应变化OVER遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
*解读：
“我们一直在实践中探寻更好的软件开发方法”，这句话告诉我们敏捷方法论并不是凭空而谈，它源自于截止目前的实践积累，并且一直在持续改进，是一个现在进行时的时态，不是一个完成态，没有最好，只有更好。
“身体力行的同时也帮助他人”， 自发地去帮助他人，敏捷很重要的一个因素是人，是团队，团队之间是要互相信任的，互相协作的，因为大家都认同团队的目标，帮助团队的其他人，也是帮助团队去实现目标，不是说这是你的事情，这是我的事情，而是我们的事情。
（1）个体与交互高于过程和工具
在团队协作中，如果没有规范的流程和指定使用的工具，很难实现共同协作，反而会制造出麻烦，出现混乱。在团队中过程和工具，也是非常有其价值的。但在敏捷开发中更加重视人和交互。敏捷开发中以人为本，人是其中最重要的核心因素。试着想想如果一个普通的团队使用上好的流程和工具，产生的价值也是非常有局限性的。只有优秀的团队使用上好的流程和工具，才能创造出极大的价值。人的能力的提升，是敏捷开发中非常重视的部分。
在工业时代，就像卓别林的电影《摩登时代》里面一样，人们试图用标准的流程和工具，把人变成一颗螺丝钉，但在脑力劳动为主的互联网时代，显然是不可行的，而是需要去关注每一个个体的发展，每个个体都有其自身的优势和能力。而且现代软件体量很大，团队成员可能会到几十个上百个，个体是不能决定成败了。那此时的关键，就是团队的这些人可以有效组织起来，互相协作，完成同一个团队目标。以人为主、团队协作，即便用简单的过程工具也能产生巨大的价值。
（2）可用的软件高于详细的文档
传统的方式每个环节流转到下一个环节，都需要有详细的文档，如产品需求文档、交互设计文档等。在软件开发过程中光维护这些文档，就是一项繁重的工作。而且文档和代码设计开发无法做到同步，那么文档就失去了它的及时沟通的价值。在软件开发中，面面俱到的文档会占用团队大量的精力。敏捷开发重视可用的软件高于详细的文档，交付给客户可以使用的软件才是最最重要的。所以在敏捷开发过程中，每个迭代以交付可以使用的功能做为衡量敏捷开发的进度，是很有必要的。
但这也不代表在敏捷中我们要求完全裸奔不产生任何文档，我们不需要不经济的文档、过期的文档，但是产生价值的文档还是可以考虑的。例如客户要求的、作为项目资产保留的、人员交接的。
（3）客户协作高于合同谈判
敏捷开发中非常重视沟通，不仅是团队内部的有效沟通，还包括团队外部与客户的沟通。敏捷开发中建议与客户一同办公，只有与客户维持良好的沟通，才能开发出适用于客户的软件产品。有时候合同谈判可能会限制了开发方式，按照合同开发的内容，很可能开发完了，完全不适用于市场了。因为，软件需求调研到软件交付给客户，是有一个过程的。在开发的过程中，会由于对需求业务的理解能力加强，对有些功能做技术上的调整，或者有些功能在开发过程中，发现已经不适用了。这些情况都不是开始经过谈判所签署的合同所能包含的。所以说客户协作胜过合同谈判。
（4）响应变化高于遵循计划
传统上所有需求都是确定的，它被分解到任务并得到评估，成本和完成日期是根据这些粒度较细的任务通过自底向上的计算得到的，计算得到的进度计划成 为项目的一个基线，用于度量项目的性能。控制范围蔓延在计划驱动中非常重要。应为这样才能避免成本超支和进度拖延。
互联网时代是一个瞬息万变的时代，市场变化极快，可能今天决定非常好用的软件，过几天就会被淘汰了。如果我们不懂得快速响应变化，只遵循原有的计划，可能就会错失良机。并不是说计划不重要，敏捷团队专注于制定计划和再访问、调整这些计划，采用自上而下的策略，价值决定计划。
最后一句，“尽管右项有其价值，我们更重视左项的价值” 这一句比较关键，敏捷方法论源于实践，它应回归实践，帮助我们解决实际问题，所以在实践中，我们应该以开放的心态去接受右项的价值，不发生冲突的时候，我们选择对于解决问题最有效的办法，但是如果发生冲突，我们还是倾向于左项的内容。
2、敏捷12原则
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欣然面对需求变化——即时是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
激发个体的斗志，给他们以所需要的环境和支持，并相信他们能够完成任务。
不论团队内外，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的发展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队定期地反省如何能提高成效，并相应地调整团队的行为。
*解读：
第一条原则：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。几个关键词是：尽早，持续，有价值和满足，通过这几个词，我们实际上是可以理解第一条原则的意义，那就是将产品对于客户的价值放在首位，整个产品的交付和开发周期都是为了满足客户对于产品价值的满意度。传统软件开发中没有将产品对于客户的价值作为产品开发的目标，只有将产品价值作为软件开发的目标，才能保证团队理解开发工作的目标，这样团队和个人才能够不断调整自己，为了这个目标而去工作，才能保证产品的持续交付。
第二条原则：欣然面对需求变化。在传统的软件开发中，需求变更可能是软件开发人员最讨厌的，软件开发人员的理想状态应该是，设计、接口定义好，我做好就行了，你最好别再找我。但是实际情况则是需求变更永远是存在的，尤其是最有价值的需求是随着时间在变化的，花时间做了没有价值的需求更可怕，所以敏捷开发提出来的这条准则是，既然我们无法阻止变更，那么我们就应该抱着欢迎的态度，看看能不能从需求变更中找到机会，化风险为机遇，从而制造更大的价值给客户。
第三条原则：要不断交付可用的软件，周期从几周到几个月不等，且越短越好。传统软件开发流程中，有从需求分析-设计-编码-测试等串行的控制流程的存在，而且各个流程可能由不同部门和团队来分担，客户到项目最后才能看到软件，而且交付时间也容易不受控制，风险很大。敏捷则希望软件团队能够不断持续的交付软件，也就是小步快跑的过程，让客户不断的看到项目进展，从而增强客户对于团队产品交付能力的信心和满意度。例如，传统开发模式中，往往都是到了release结束的时候，客户才能够看到能够工作的产品，这个时候发现问题，往往需要加班维护，客户和开发人员都苦不堪言。后来在接受了敏捷理论之后，将软件功能拆分成非常小的用户故事，每个迭代按优先级实现用户故事，每个迭代为客户进行shoucase，这样客户每个迭代都能够看到产品在不断完善，同时也能够不断的进行反馈。
第四条原则：项目过程中，业务人员与开发人员必须在一起工作。敏捷宣言中地调就强调协作和沟通，那么这条准则也是希望团队成员能够有一个适合沟通的环境，特别是业务人员，他们是接触客户的第一责任人，任何客户的需求都是通过他们传递给开发团队的，只有大家在一起不停的沟通协作，才能保证开发团队开发出来的产品真正是客户想要的。
第五条原则：激发个体的斗志，给他们以所需要的环境和支持，并相信他们能够完成任务。这是一种以人为本的思想。在敏捷开发流程中，团队的组建是非常重要的，首先我们要相信团队成员，相信他们是愿意为了团队的目标而工作，有能力完成当前的开发任务的。然后给予团队成员支持，鼓励。而不是压迫与被压迫的关系。
第六条原则：不论团队内外，最有效的沟通方法是面对面的交谈。敏捷非常强调面对面沟通，因为面对面沟通是所有沟通方式中最高效的方法，大家可以通过直接的沟通第一时间把问题解决。例如，邮件/视频/即时通信/电话/面对面沟通中，其中文档和邮件是效率最低的方式，而在敏捷中，站会和看板则是制造一个每天让团队开发人员面对面交流的机会，从而将团队沟通成本降低，减少因沟通造成的项目问题。
第七条原则：可用的软件是衡量进度的主要指标。敏捷强调即时交付，但是交付产品的衡量则是可以工作的软件，传统开发方式中可能在相当长一段时间，客户无法看到软件产品。而敏捷则强调交付一定是可以工作的软件，这样的话客户可以从一开始就看到我们的产品，例如一个MVP，对产品有一个直观的感受，从而可以不断的提出反馈和建立信心。
第八条原则：敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的发展速度。敏捷不只是一味强调快速交付，而是强调一个开发节奏，这个节奏能够让项目管理人员和客户对于这个团队有信心，就是客户交付给这个团队的开发任务，他们能够在多久完成，并且是保证质量的。我们在实践中去尽量保证一个稳定的迭代容量，就是出于这个考虑。
第九条原则：对技术的精益求精以及对设计的不断完善将提升敏捷性。敏捷开发非常重视技术提升，因为它相信团队技术能力的扩展和提升能够提高产品质量，交付能力等，从而提高团队的敏捷性。鼓励大家学习钻研，也是我们常说的追求卓越。
第十条原则：要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术。只做需要做的、最有价值的事，这是敏捷的核心之一。不要镀金，刚好最好。
第十一条原则：最佳的架构、需求和设计出自于自组织的团队。敏捷相信好的架构设计是出自自组织的团队。自组织团队就是团队可以自己决定怎么样完成工作。敏捷的最终目标也就是打造一个自组织团队，通过高效协作来进行项目交付。
第十二条准则：团队定期地反省如何能提高成效，并相应地调整团队的行为。回顾会议是敏捷活动中非常重要的会议之一，通过回顾会议，找出团队需要保持的和不足之处，在下个迭代进行改进，才能够实现团队持续改进，提高交付能力。
3、敏捷实践
我们常用的一些敏捷实践，像scrum就是一个非常典型、应用非常广泛的敏捷实践，他非常有名的3355框架可以很好地指导软件开发的实践，Scrum框架最大的价值就是帮助团队建立了一种工作方式。还有我们常用的KANBAN方法，可以把团队的迭代质量要求、进展和风险进行透明化，也是我们日常开发工作中的一种常用实践了。以及近年特别火的领域驱动设计DDD，这些都是在敏捷的价值观和原则基础上衍生出来的实践方法。
这些具体的实践本文暂不展开，后续整理资料做专题笔记。
