如果30天内无法将Idea转换成具备商业模式及可操作性的项目，
如果2个月内无法找到团队核心并组成初创团队，
如果3个月内你的Idea还没被团队充分理解并预期付诸实践，
如果6个月内你还在筹划半年前的那个Idea，
这个Idea已经过时勒，请下一个，这里是互联网！
更迅捷的项目管理，
更快速的项目决断，
更舒适的用户体验，
更早地实现Idea，
好与不好交由公众来评断，
不要闭门造车以为一切尽在掌握。
— Reinhardt
项目的开始至完成绝不可能是一帆风顺的过程，即使完美主义者也会不可避免地遭遇挑战，”自上而下”或”自下而上”的过程都有其无可掩盖的缺点，只有不断在实践中迭代前进，才能一步步接近真相。
— Reinhardt
项目自始至终周期过长，会造成心理放松，对于项目危机感缺失，以至于造成前期浪费时间，后期加班赶时间的窘相。所以我们需要通过不断地迭代，在一次次循环中完成可交付的增量，基于事实的决策远比前端预测型决策更为有效。
— Reinhardt
Scrum有3种职能者：ScrumMaster，Product Manager，Team，相互之间不渗透，各司其职。ScurmMaster负责Scrum流程顺利完成，即迭代地不断进行，Product Manager根据产品需求及市场预期制定产品Backlog，Team在自发性驱使下完成Sprint。通常过程中，30天为一个迭代周期，称之为Sprint，流程如下：
Scrum Start -> Sprint 计划会议（第一部分分析Product Backlog，第二部分解答产品Backlog，并制定Sprint Backlog） –> Sprint 迭代开始 –> Daily Scrum（Sprint 迭代）–> Sprint 评审会议（展示，提问，调整）–> Sprint 评审会议（团队总结，调整）–> Sprint 迭代结束 –> Scrum End
图：Product Backlog
图：Task Board
Product Backlog: 是否代表所有利益相关者的最近需求，提醒大家关注最近的将来（利益相关者：投资方，团队，目标用户）
Sprint Backlog: Sprint迭代周期内，团队需要完成的项目细则，并确保Sprint周期结束后，项目的潜在可交付性
Scrum计划过程涉及3个问题的解答：
1. 项目投资人希望项目结束时能取得哪些成果？
2. 每个Sprint应作出哪些进展？
3. 如何使项目投资人相信该项目是有价值的投资，以及项目申报者有能力交付预期收益？
4. 计划的目的之一是说服投资者为项目注资
Daily Scrum（全天工作的第一件事）：
1. 自上次的Daily Scrum后我做了什么？
2. 现在到下次Daily Scrum我准备做什么？
3. 在工作中遇到了什么困难？
Scrum基本原理：
1. Scrum是经验型方法，是”可能性的艺术“
2. Scrum使得所有事项充分可见，使“秘密交易”最小化
3. Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制
4. 团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum
ScrumMaster
ScrumManager主要职责:
1. ScrumMaster与传统项目经理区别：从传统的控制者到引导者的转变
2. ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。
3. ScrumMaster使团队在Sprint过程中免受干预
4. 产品负责人谈论业务需求和目标，团队则讲技术。由于产品负责人很难掌握技术，ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog
ScrumMaster职责：
1. 排除产品开发和负责人之间的障碍，确保产品负责人直接推动开发工作
2. 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标
3. 激发创造力和放权，从而改善开发团队的环境
4. 千方百计提高开发团队的生产力
5. 改善工程实践和工具，确保每个功能增量都具备潜在可交付性
6. 向各方确保团队工作进展实时更新并高度可视
Scrum高效率探究
限期30天Sprint的固有压力，团队成员表示“需有所付出”的相互承诺，自组织原则及跨职能责任，有助于团队成功履行职责承诺机制条理化，增加相互责任心，团队凝聚效应
“限定时间”可向团队灌输“可能”的艺术，避免过分追求完美
“增量交货”的举措改进工程实践
“放权”和“自组织”能够激发创造力，提升员工满意度
(*****) 当人们不能聚在一起面对面交流时，往往会将自己的问题抛给他人
(****) 预估的目的是为了解每个需求自身及相对于其他需求的规模。该信息有助于划分产品Backlog的优先等级，并将之分入各个Sprint
Scrum运行无需过于宽泛的计划，但需足以引导Scrum的经验性过程的检查与适应循环，若成本/收益及假设性数据引导适应环境更有意义地展开，项目必可收益
团队
团队从被管理到自我管理的转变十分困难，但在生产力和工作愉悦度方面的回报显著
在我们的生活和工作经历中，受他人管理的习惯根深蒂固。
Scrum真理：成功的开发需要不断检查和调整
本质：内心深处，认为自己应在一开始便完美安排各事项，确保计划得以严格实施。需要适应调整时，责备自己为实现妥善安排全部事项。从开始就预知结果的人不会存在。
(**) 总体度量，即在最合适的日期交付最佳、最优质的系统。实施其余度量法时应保持谨慎，确保其支持总量度量，避免削弱其效果。我们在设计度量系统时应考虑人类固有的、为取悦他人不计后果的欲望。（e.g. 代码量不应作为绩效考核标准）
(***) 团队通常难以用产品负责人能理解的语言与之交流，若产品负责人只谈商业，团队只谈技术，双方无法交流，也就没有协作
Scrum报告
每个Sprint结束时还需产生正式报告
Scrum报告：
1. 第一份列出上一次Sprint开始时的产品Backlog
2. 第二份为新Sprint开始时的产品Backlog
3. 第三份是“变更报告”，详细列出前两份报告的差别
4. 第四份为产品Backlog的“剩余时间报告”（Burndown Report）
变更报告总结以下内容：
1. Sprint中发生及Sprint审核的情况
2. 项目针对Sprint审核结果所做的适应调整
3. 未来Sprint重构的原因
4. 发布日期或内容重新制定的原因
5. 为何团队在Sprint中完成的需求量比预期少
6. 在产品Backlog中，未完成工作的优先等级重排情况如何
7. 团队为何比预期生产率高（低）
不使用术语，却教会管理层使用Scrum，属于只是一种表现形式。（e.g. Ajax = 无页面刷新）
Scrum扩展项目
Scrum of Scrums
Scrum实践扩展成功的关键：
1. 在扩展前构建必须的基础设施（构建扩展基础设施的非功能性需求必须在扩展开始前完成）
2. 建构基础设施的同时确保交付商业价值
3. 优化原始团队的能力，向其余团队分派至少一名初始团队成员
项目扩展为多个团队的产品Backlog中应加入以下非功能性需求：
1. 分解业务结构以支持整洁界面的多团队开发
2. 分解系统结构以支持整洁界面的多团队开发
3. 必要时，定义并实施特定开发环境，支持多团队并置或分布的环境
e.g. 曳光弹：射击者摸黑开冲锋枪时难以瞄准，若每50发子弹中有一颗曳光弹，便可看清方向，调整瞄准。（指明团队方向，冲破迷雾）
e.g. 马克吐温曾说：“没有东西比绞索更易让人集中精神。”（增加紧迫感，提高效率）
e.g. “癫狂愚顽”：反复做同样的事情，却期待不同的结果。在预定义方法在项目管理中失败时，人们通常将原因归结于未能严格执行预定义方法。断定项目成功的关键在于加强控制和项目定义。（不断重复地用失败的方法华丽地完成另一次更大的失败）
