《Succeeding with Agile: Software Development Using Scrum》 -- Mike Cohn
- 愿意改变是一种优势，即使这意味着某段时间会使公司的某个部分陷入混乱 -- 杰克·韦尔奇
- 成功实施 Scrum 的关键是结合自上而下和自下而上的变革相关要素
- 生态系统是绝不可以管理的，我们只能干扰它，然后等着观察它的反应
- 有机会改变或者定制一个过程，使其更适合其本身，是团队成功实施其过程的关键因素
- 习惯于涌现式设计（emergent design）是困难的，它有种让你乱来的感觉
- 敏捷实施需要一位激情四射的发起人热情投入，做出艰难的企业变革，从而服务于敏捷团队和成功结果
- 理想试点项目的4个属性：持续时间、规模、重要性、发起人的保证
- ScrumMaster的权力来自于团队的授权
- 顶尖ScrumMaster共有的六种品质：负责、谦逊、协作、投入、有影响力、知识渊博
- 优秀ProductOwner的品质：始终都在、懂业务、善于沟通、果断、得到授权的
- 一些人成为项目经理是因为他们认为这是他们想要的职业发展道路中的必要步骤，并不是因为他们喜欢项目管理
- 保留原有的头衔会阻碍人们用新的方式思考
- 不编码的架构师的出现是众所周知的麻烦出现的先兆，Scrum 项目要摆脱他们
- 因为与程序员紧密工作而导致测试人员失去更多测试视角从而无法测试软件，这样的案例及其少见
- Scrum 并没有指定具体的工程实践，因为那样做有悖于 Scrum 的基本原则 -- 相信团队可以解决问题
- 保持小团队和定位每个团队基本上可以交付端到端的、用户可见的功能
- 小团队的成员不容易出现社会惰化
- 一个团队如果超过10~12个人将很难建立信任感、共同的责任感以及凝聚力
- 组件团队的工作只有在它被特性团队集成到产品后才是有价值的
- 在选择合适的团队结构时请记住：没有一个团队结构是永久的
- 宁可让少数人承担更多一些的任务，也不要让每个人都有少量的多任务
- 只有两个匹萨你的团队是否够吃？
- Scrum 团队一成俱成，一败俱败。这里没有“我的工作”和“你的工作”，只有“我们的工作”
- 要成为高效能 Scrum 团队，首要目标是接受团队责任制
- 要成为一个真正的高效团队并领会 Scrum 带来的所有好处，团队必须主动寻求学习和分享知识的新方法
- 一个积极性很高、技术娴熟的个人经常能使他的每个同事也变得更好一些
- 一个懒散没有斗志的成员也会拖垮整个团队
- 管理层的工作是给予团队合适的任务并帮他们移除障碍
- 如果领导层过分约束团队解决问题的方法，就不会有自组织团队
- 影响团队自组织的三要素：容器、差异与交流
- 书面文档容易让人误解，它看起来并没有那么准确
- 当文档主要用于用户任务交接时，他们是罪恶的；而当它们用于捕捉交谈记录使其不被忘记时，则是有价值的
- 用户故事是将团队焦点从编写功能需求转移到谈论它们的最佳方式
- 用于故事通常遵循一个简单的模板：作为一个<用户类型>，我想<某个目标>，以便于<一些原因>
- 跨职能的团队能降低对文档的需求
- 优秀产品 Backlog 的几个关键属性 (DEEP): 详略得当(Detailed Appropriately), 做过估算的(Estimated), 涌现的(Emergent), 排列优先级的(Prioritized)
