接受项目管理培训至今已经有三年时间了，一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头，从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验，希望可以帮助到从事项目管理的人！
接上一篇博文 《软件项目管理 之一 软件开发过程（软件开发生命周期）》。
历史
1986 年，竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在 《哈佛商业评论》（Harvard Business Review）杂志上发文《新型的新产品开发策略》（The New New Product Development Game），文中阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：
他们将这种新的整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而团队“作为一个整体前进，把球传来传去”。他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究，提出了一种提高速度和灵活性的商业产品开发新方法。
该文章可以在 /1986/01/the-new-new-product-development-game 查看
1995年，在德克萨斯州奥斯汀举办的业务对象设计和实现研讨会（ Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) 的一部分）上，萨瑟兰（Sutherland ）和施瓦伯（Schwaber）联合发表了论文首次提出了Scrum 概念。在接下的几年里，Schwaber 和 Sutherland 合作将这些材料与他们的经验和不断发展的良好实践相结合，形成我们现在所知的 Scrum。
2001 年，施瓦伯（Schwaber）与麦克·比窦（Mike Beedle）合著了《Agile Software Development with Scrum》一书，介绍了 Scrum 方法
2002 年，Schwaber 和其他人成立了 Scrum 联盟，并建立了 Scrum 认证系列。Schwaber 在 年末离开了 Scrum 联盟，并创建了 来监督平行的专业 Scrum 认证系列。
规范
年，Schwaber 和 Sutherland 发布了名为 《The Scrum Guide》 （ Scrum 指南）的公共文档。该文档给出了对于 Scrum 的的各种定义，可以说是 Scrum 的官方指导规范。该指南的官方网址：/index.html
自 年以来，该版本已被修订 6 次，当前版本为 年 11 月。官网提供了不同语言的版本，需要的可以直接从官方网站上下载即可。
组织机构
Agile Alliance
敏捷联盟（Agile Alliance）是一个全球性的非盈利性成员组织，致力于支持那些探索和应用敏捷价值、原则和实践的人们，使构建软件解决方案更有效、更人性化、更可持续。
2001 年 2 月 11 日和 13 日，十七名软件开发人员在犹他州的瓦萨奇山雪鸟滑雪胜地会面，起草了敏捷软件开发宣言，他们自称为敏捷联盟。官方网址：/
敏捷联盟会定期举办各种活动，以建立一个包容的全球社区，推进敏捷的广度和深度，并为成员提供帮助。这些活动包括：
组织敏捷社区成员聚集在一起召开会议维护充满关于敏捷和敏捷社区信息的网站 /提供访问社区成员创造的宝贵资源的会员资格Initiatives that address specific areas of interest in the Agile Community and provide support for Local Community Groups
Scrum Alliance
Scrum Alliance® 创建于 2001 年，是敏捷领域中非常具有影响力的认证组织。官网是：/。提供了 Scrum 技能的相关培训、认证等。制定和维护 SCRUM 认证体系。自 年起，最新 Scrum 认证体系更新如下：
至于每个认证类型的详细说明，可以直接去官网 /get-certified#cal 查看。
由 Ken Schwaber 成立，Ken 和 Jeff 是敏捷宣言的最初签署者之一。他们是权威的《Scrum指南》的作者。 提供 Scrum 资源、培训、评估，以及向 “Scrum Masters”、“Scrum 开发者”、“Scrum 产品负责人”，以及使用 Scrum 的机构发放证书。提供如下类型的认证：
详细见 /professional-scrum-certifications
概念
Scrum 是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum 不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。Scrum 是一个包括了一系列实践和预定义角色的过程框架。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 的建议长度是 1 到 4 周（也有的说是 2 ~ 4 周）。
使用产品待办事项列表（Product Backlog）来管理产品需求，它是按优先级排序的需求列表。在每次迭代中，Scrum Team 都会从 Product Backlog 中选择优先级最高的需求进行工作。在 Sprint 计划活动中对所选择的需求进行讨论、分析和评估，以获得相应的迭代目标和交付计划，我们称之为Sprint Backlog在迭代中，每天都有一个固定的Daily Scrum。在每次迭代的最后，Scrum Team 都会邀请业务人员和利益相关这来评审潜在的产品交付成果。通过 回顾会议来总结并准备下一次迭代
Scrum 的英文意思是橄榄球运动的一个专业术语，表示 “争球” 的动作；把一个开发流程的名字取名为 Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情。而 Scrum 就是这样的一个开发流程。
据 统计，在 Scrum 的帮助下交付的项目的总体成功率是 62%。Scrum Alliance 对近 5000 人进行了关于 Scrum 使用情况的年度调查。以下是 Scrum Alliance State of Scrum Report 提供的 4 个统计数据：
该报告可以从官网直接下载：/ScrumRedesignDEVSite/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-.pdf
最新的还有个 STATE OF SCRUM -
Scrum 是一个通过查看和调整来开发和维护复杂产品的框架。它是一种遵循敏捷声明和原则的类型，集成了三个角色、三个工件、五个事件、五个值，称为 3355。
当然，随着 Scrum 的完善，其中又新增了一些其他的内容，以上的 3355 的并没有指出全部内容。在实际实施 Scrum 开发中，我们一般还会结合其他一些工具或者手段。
Scrum Roles
Scrum 当中定义了许多角色。Scrum 具有三个致力于项目的核心角色，分别为产品负责人（Product Owner）、流程管理员（Scrum Master）、开发团队（Development Team）。
按照对开发过程的参与情况，这些角色被分为两组：猪组和鸡组。这样的分组源于一个猪和鸡开餐馆的寓言故事：
一头猪和一只鸡在路上散步。
鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”
猪回头看了一下鸡说：“好主意，那我们给餐馆起什么名字呢？”
鸡想了想说：“叫 ‘火腿和鸡蛋’ 怎么样？”
猪说：“那可不行，我把自己全搭进去了，而你只是参与而已。”
猪组的成员：在 Scrum 过程中全身投入项目的各种人物，他们在项目中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。例如：产品负责人（Product Owner）、Scrum 主管（Scrum Master）、Team鸡组的成员：鸡仅仅是通过蛋参与，并不是实际 Scrum 过程的一部分，但是必须考虑他们。例如：用户、经理、利益相关者（客户，提供商）
需要注意的是：
角色不是职位。因为 scrum 的本质是经验主义、自我组织和持续改进，所以这三个角色仅仅是给出了责任的最小定义。Scrum 对于团队中成员的个人能力要求比较高
流程管理员（Scrum Master）
Scrum Master 确保 Scrum 团队遵守 Scrum 价值、实践和规则，保证项目按照 Scrum 的要求顺利实施和进行。Scrum Master 是清除障碍的人，比如解决团队对外部的硬件或者软件依赖问题；需要其他团队的支持问题；需要工具的支持等。Scrum Master 是变革代言人，要促成组织内部人员转变思维，迎接敏捷开发方式，改变项目经理过去安排任务的习惯；改变团队成员等着分配任务习惯；引进新的测试工具；推进更多的敏捷实践到团队。
Scrum Master 本身可能也是开发人员。Scrum Master 不对 Scrum 团队进行管理及决策，团队是自组织的。ScrumMaster 绝对不能是产品负责人
产品负责人（Product Owner）
产品负责人（Product Owner）代表客户的声音。该人员被授权制定关于产品的全局决策、维护产品待办事项列表、定义所有待办事项列表项并确定优先级。确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责。
沟通是产品负责人的核心职责。传达优先级和传递团队成员和利益相关者的能力对于将产品开发引向正确的方向是至关重要的。产品负责人的角色是团队和干系人之间沟通的桥梁，是团队干系人的代理，也是整个干系人社区的团队代表
一个 Scrum 团队应该只有一个产品所有者（尽管一个产品所有者可以支持一个以上的团队），且不应将此角色与 Scrum 管理员的角色相结合。对于商业开发，产品负责人可能就是产品经理。对内部开发而言，产品负责人可能来自其业务会被该产品自动化的职能部门经理。产品负责人可以是团队成员，承担开发任务。但是这样可能会牵掣其精力，影响产品负责人和利益相关人协调工作产品负责人绝对不能是 Scrum Master。
开发团队（Development Team）
Scrum 的基本单位是一个小团队，由产品负责人（Product Owner）、流程管理员（Scrum Master）和开发人员（Developers）组成。好多文章中也称为 Scrum Team，都一个意思。团队是自我管理的，跨职能的，并且一次只关注一个目标：产品目标。
Scrum Team 执行软件产品在 Scrum 规定流程下的开发工作，人数控制在 5 ~ 10 人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到 Sprint 的目标。
团队同时是跨职能的；团队成员必须具备创造产品增量所需要的技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。简单来说，开发团队并不等于开发工程师，开发团队可以由各种各样的人组成，包括设计师、文档工程师、程序员等。
团队同时是自组织的。任何人，包括 ScrumMaster 都没有权利规定团队如何将产品待办事项列表转化成可交付的功能增量，而是由团队自己确定。团队的构成在 Sprint 结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。团队中没有头衔（职位）的概念团队不允许包括测试或业务分析等在特定领域工作的子团队架构师或设计人员而不愿意编码的人不适合成为团队成员
Artifacts
Scrum 的工件代表了工作或价值，为检视和适应提供了透明度和机会。Scrum 定义的工件是专门设计来最大化关键信息的透明度的，这样每个人都能对工件有相同的理解。
Product Backlog
产品待办事项列表（Product Backlog）是对待完成工作的分解，包含 Scrum 团队维护的产品需求的有序列表。常见的格式包括用户故事（User Story）和用例。
产品负责人负责为团队制定产品待办事项列表项，只有在产品负责人同意的情况下才可以更改。产品负责人根据风险、业务价值、依赖关系、大小和所需日期等考虑因素，对产品待办事项安排优先级。
若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用产品待办事项列表的特征对条目进行分组。分组可以根据特性集、技术或架构进行。这也是 Scrum 团队经常采用的一种组织工作的方法。
由 Product Owner 负责维护，包括增删及决定优先级。用户故事是其中一种最佳实践。每项需求都需要描述其外部价值。
用户故事（User Stories ）
在软件开发和产品管理中，用户故事是对软件系统的一个或多个特性的非正式、自然的描述。用户故事是敏捷软件开发中用来从最终用户的角度获取软件特性描述的工具。用户故事描述了用户的类型，他们想要什么以及为什么。 用户故事有助于创建对需求的简化描述。
1999 年，Kent Beck 为产品特性提出了一个术语“用户故事”。根据他的描述，用户故事是从用户的角度讲述他或她想要什么，而不是系统能为他做什么。因此，观点完全从产品转变为用户，用户故事成为所有敏捷框架中需求的事实上的标准。
产品待办事项列表是用户故事的列表。用户故事是根据定义的格式来叙述的：As (persona), I want to (expression of the wish), so that (goal to achieve).。Chris Matts 认为"寻找价值"是成功交付软件的第一步，并提出了这一替代方案：In order to <receive benefit> as a <role>, I can <goal/desire>。还有另一种基于 5W 的模板：As <who> <when> <where>, I <want> because <why>。下面是示例：
Epic（史诗）
一般来说，Epic 是要开发产品的宏观功能。史诗还可以描述为按类别或主题分组的多个用户故事集合。在实际开发中，我们可以将某些任务划归为一个大的目标：里程碑。
Task（任务）
任务（可能还有子任务）是帮助响应用户描述的技术活动。理想情况下，这些活动应该是相同的规模（从工作复杂性的角度来看），但可能具有不同的性质：设计、开发、测试等。在当下各种互联网项目管理工具（绝大多数是依据 Scrum 的）中，Task 是处理的最小单元。
Sprint Backlog
Sprint Backlog 是团队在下一个 sprint 中必须处理的工作列表。这个列表是由 scrum 团队根据优先级顺序从产品待办事项列表的顶部逐步选择产品待办事项列表项，直到他们觉得有足够的工作来完成 sprint。
来源于 Product Backlog。由团队评估和选择 Product Backlog 中哪些放入Sprint Backlog。团队需要一起定义 “完成” 的标准。
Product Increment
可交付产品增量（Product Increment）即 sprint 结束后可对外发布的产品功能增量部分，也被称着 “潜在可交付的产品增量”（Potential shippable product increment, PSPI）。它由所有已完成的 sprint 待办事项构成，并与所有先前 sprint 的工作集成在一起。
每个 Sprint 能否生成满足质量定义的 PSPI 是 Scrum 执行效果的试金石。因此这里关键的是团队内有一致同意的 DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队 DOD 内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。
需要在 Scrum Review 会议上进行演示完成的定义（DoD）和就绪的定义（DoR）在 Scrum 中很重要
Definition of ready (DoR)
DoR 给出了当前已具备的各种条件是否具备了真正开始某个用户故事的标准。
Definition of done (DoD)
DoD 给出了是否真正完成的标准。在许多情况下，DoD 要求所有的回归测试都要完成。“完成” 的定义可能因 scrum 团队的不同而不同，但必须在一个团队内保持一致。
真正 “完成” 的增量包含了增量和其中所有产品待办事项列表条目必须的分析、设计、重构、编码、文档和测试工作。测试包括单元测试、系统测试、用户测试和回归测试，另外还有非功能测试如性能测试、稳定性测试、安全性测试和集成测试。
有一些产品不包含文档，所以“完成”的定义不包含对文档的要求。“完成”也包含所有的国际化工作。有些团队尚没有能力将实现他们“完成”定义的所有要求都包含在内。这一点必须告知产品负责人。产品在实现、投入使用之前要把所有的剩余工作都完成。
具体来说，当我们谈论产品开发（考虑系统/软件/解决方案）时，DoD 包含3个主要组件：
Business or Functional requirements（业务或功能需求）Quality（质量）Non-Functional Requirements（非功能需求）
DoD 可能会有不同的级别类型：
Scrum 产品待办事项列表项的 DoD (e.g. writing code, tests and all necessary documentation)Sprint 的 DoD (e.g. install demo system for review)产品发布的 DoD (e.g. writing release notes)
Events（Workflow）
Scrum 的事件也称为流程或者规则。Scrum 中使用规定的事件来创建规律性并最大程度地减少对 Scrum 中未定义的会议的需求。 所有事件都有时间限制。 Sprint 开始后，其持续时间是固定的，不能缩短或延长。 只要达到事件的目的，其余事件就可以结束，从而确保花费适当的时间而不会在过程中造成浪费。
Sprint
Sprint（也称为迭代或时间框）是 Scrum 中开发的基本单元。Sprint 是有时间限制的工作，也就是说，每个 sprint 的长度都是事先商定和确定的，通常在一周到一个月之间，最常见的是两周。
1 - 4 周固定周期，固定时间开始，固定时间结束时间盒是其一个重要的概念Sprint 一个紧跟一个进行，之间没有任何时间间隔Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力
燃尽图（Burndown Chart）
燃尽图（Burndown Chart）主要用来追踪 Sprint 的进度情况。燃尽图（Burndown Chart）显示了 Sprint 中剩余的工作量。它提供了一种有效的方法来确定一个Sprint 是否按计划完成了所有计划好的问题。
Sprint planning
Sprint 计划会议制定迭代计划。Sprint 计划会议会在 Sprint 一开始召开。产品负责人和团队将共同决定将在这个 Sprint 完成那些故事。
确定 Sprint 的目标对产品 backlog 中 item 进行估算，以作为是否放入下期的参考。对于需求不清楚的 item，请 Product Owner 说明。输入是 Product backlog输出是 Sprint backlog
评估（Estimation）
评估是由整个团队在 Sprint 计划会议上完成的。评估的目标是根据优先级和团队在 Sprint 时间范围内交付的能力来考虑 Sprint的用户故事。Scrum 团队负责产品增量的交付，因此需要根据产品增量的大小和所需的工作，谨慎地为 Sprint 选择用户故事（即生成的 Sprint Backlog）。
传统的 IT 项目中，往往使用“人天”来作为工作量评估的量词。在软件项目开发经典著作《人月神话》中，明确的指出了按“人月”或“人天”来评估需求工作量的巨大弊端，主因之一就是在于这个词让人产生了“可以使用更多的开发人员就可以更快速的完成软件开发”这一错觉。
用户故事点（User Story Points）
产品增量的大小是根据用户故事点（User Story Points）来估计的。Scrum 对用户故事的评估是根据每个用户描述的困难程度来进行的。为了评估困难程度，使用了一种特殊的度量衡（尺度）。Scrum 评估中使用了几种类型的尺度。下面是一些例子
数字大小 (1 到10)T 恤的号码大小 (XS, S, M, L, XL XXL, XXXL)斐波纳契序列 (1, 2, 3, 5, 8, 13, 21, 34, etc.)狗的品种 (吉娃娃,………,大丹犬)
这些度量衡就被称为用户故事点（User Story Points）（其实就是对于用户故事难度的一个抽象值）。至于选择哪一种抽象方式，就需要根据团队的适应程度来决定了。最常用和最流行的评估技术是基于斐波那契数列规划扑克。
规划扑克技术（Planning Poker Technique）
在规划扑克估算技术中，用户故事的估算是通过玩规划扑克得出的。 整个 Scrum 团队都参与其中，并且可以快速但可靠地进行估算。所谓的计划扑克（Planning Poker）是一种标有斐波那契数列数字的扑克牌。上面标的数字就表示用户故事点（User Story Points）。具体玩法如下：
其中一个团队成员当主持人。主持人阅读正在进行评估的用户故事的描述。如果有人有任何疑问，产品负责人则需要给与解释。剩余人员每人一副牌，私下选择一张代表自己的评估的卡片（不受其他人干扰）。所有人员选择完毕后，大家同时将自己的卡牌翻过来，以便所有的团队成员都能看到每个评估。在第一轮中，大家的估计（选择的牌上的数字）很可能会有较大的差距。 选择了最高和最低估计量人员需要说明估计的原因。 应该注意的是，所有的讨论都是为了理解，没有什么是针对个人的。主持人必须确保这一点。讨论结束后，每个人收回自己原来的牌，重复上一步。
重复这个过程，直到估算收敛到一个可以用于故事的单一估算。最后将所有人的评估点数加起来就是这个用户故事最终的故事点。评估的轮数可能因用户描述的不同而不同。在评估中，每个成员必须清楚的认识到以下几点：
不是轮流出牌，而是大家考虑好之后同时出牌，这样就可以避免后出牌的人被先出牌的人干扰他们需要估计所有的是这个用户故事，而不仅仅是他们自己将要做的那些部分数值越大，表示用户故事难度越大
Daily scrum
又名 Sprint Daily Standup，每日站会，在 15 分钟以内，团队成员相互交流任务的进展，计划以及是否遇到困难。Scrum Master 要确保团队举行每日例会，团队则负责召开会议。
回答 3 个问题 本次会议之前，我做了哪些事情？本次会议之后，我准备做什么事情？目前我是否碰到障碍，阻碍我达成目标？ 每天 15 分钟不是深入的问题讨论每天固定时间召开，同一地点进行
然而，在实际开发过程中，该活动往往会难以正常进行。在最初运行阶段，还可能严格按照 Scrum 方式进行，在试运行一段以后，就会发现大家的参与度非常低，经常是 Scrum master 和发言者进行交流，其他人基本上都游离在外。这就需要我们自己制定一些符合自己团队的措施了！
Sprint review
Sprint 评审会议发生在 Sprint 将要结束的时候，团队、产品负责人和 Stakeholder 一起评审本次 Sprint 的产出是否如何预期，可以被接受。
团队全体参与邀请相关干系人参与2 - 4 小时Product Owner 可以拒绝接收成果
Sprint retrospective
这个回顾会议发生在 Sprint 的最后，由 Scrum Master 负责召集团队召开。会中大家会回顾和小结这个 Sprint 的好的地方以及有那些不足。保证团队能够持续改进，不断提高。回顾会议旨在对前一个 Sprint 周期中的人、关系、过程和工具进行检验。
Sprint 评审会结束后召开时间 2 - 4 小时团队全体参与
Scrum 价值观
理论
Scrum 基于测试过程控制理论(经验过程，或所谓的经验主义)。经验主义认为，知识来自于当前已知情况下的实际经验和观察。(注意，它不同于教条主义，不同于完全基于过去经验的固定思维，不同于忽略理论指导的部分经验主义)。Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险。Scrum 是一种反馈驱动的经验方法，与所有经验过程控制一样，它由透明度、检视和适应这三个支柱支撑。
透明：过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。检视：Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。适应：如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。
价值观
这三个支柱需要团队的信任和开放，而下面的 5 个 Scrum 价值观则是个保证。
Focus：因为我们一次只专注于少数几件事，所以我们可以很好地合作并取得出色的成果。 我们会尽快交付有价值的物品。
Openness：在我们共同努力的过程中，我们会表达我们正在做什么，我们的障碍是什么，以及我们所关心的问题，以便这些问题能够得到解决。
Courage：因为我们作为一个团队工作，我们感到受到支持，有更多的资源可供我们使用。这使我们有勇气接受更大的挑战。
Commitment：因为我们对自己的命运掌握得很好，所以我们更加致力于成功。
Respect：当我们一起工作，分享成功和失败，我们开始互相尊重，帮助彼此成为值得尊重的人。
常见误区
迭代开发等于 Scrum 开发
有人认为，敏捷 Scrum 就是快速迭代，快速迭代就能达到敏捷的效果，这样的理解是有偏差的。敏捷开发是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试（ART）等等。
敏捷与管理是冲突的
Scrum 强调的是自组织和自管理团队，领导充分授权，发挥人的能动性，使得团队成员能够独立地、集中地在创造性的环境下高效地完成工作。但凡事都要讲究一个平衡，人的消极和积极两面是共存的，过度的自由会放纵人消极的一面。自组织和自管理本身是很好的，但也有一定的局限性。如何把握“管理”和“放权”间的关系，还需要根据团队实际情况去寻找一个平衡点。
敏捷是反文档的
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，又该如何解决沟通的问题呢？每次沟通都完全用手比划、用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
