关于 QA 的定位（边缘场景 only）
- QA 在每个 Cycle 的尾声进入，并测试各种边缘场景
- 实施团队对主要功能的质量负责
- Basecamp 的实践是，很多年来都没有 QA 这个角色，直到业务的规模发现，边缘场景的 bug 造成的影响足够大了才开始专门在这方面投入
- QA 是 Level-up（增值），而非 Check-point（兜底）
- QA 提交的 tasks 默认是 nice-to-have 属性，实施团队来决定是否要修复
关于 Code Review
- Code Review 和 QA 测试一样，不是强制的
- Code Review 会让代码变得更好，但不强制
- Code Review 是 Teaching 和 Learning 的机会，应该珍惜抓住而非逃避
如何对待线上发现的 Bugs
- 首先，真实的考虑 bugs 的影响。大部分的 bug 可以等六周或者不需要修。
- 处置：
- 用 cool down
- 用 betting table，正式的
- 偶尔安排专门的 bug smash 周期，某个六周只修 bug
关于项目延期的原则
- 极少的项目允许延期
- 所有遗留的没有做完的 Tasks，都是确实是 must-have 的
- 剩余的 Tasks 必须是 downhill 状态的，没有不确定性，没有未解答的问题
- 即使如此，大部分项目我们仍然不鼓励延期
- 2 weeks 的 Cool Down 可用来完成未完成的项目，但不鼓励，不应该是常态
- 任何未完成的项目中，如果有 uphill 状态的工作，都被视为 shaping 本身的问题。任何带有不确定性的项目，都应该回到 shaping 阶段去重新探讨，直到重新完善后通过同样的 Betting 过程，回到未来的某个 Cycle 中
Pitches 是如何被管理的
- 所有写好初稿的 Pitches 会被发送到一个专门的频道里，异步评审
- 所有 stakeholder 自行阅读
- 异步的 comment 并尽可能修正，解决所有的顾虑
- 因此这个 Shaping 的过程，是同样值得和 Cycle 等价6 周的
- 绝不在评审阶段说 yes or no（这是 betting 做的），这是重要的边界
- 但所有的 Idea，默认的态度都应该是： no，值到它被足够的思考，最终塑造成赌桌上值得下注的筹码
- 所有没有被批准的 Pitch，都等同于作废。除非显著的被修改后重新提起。（注意重申：没有任何 Backlog）
特殊的超大型项目怎么操作？
书内有从 0-1 一个产品，显然 6 周不可能做完的场景。详细的见书中原文，但个重点很有意思：
- 会有一个特殊的初期（R&D Mode），这个阶段工作节奏仍然和 Cycle 一样，但 Pitch 和分工均有不同。
- Pitch 可以允许写的比较模糊，因为很多事需要在建设的过程中才能学习到
- 尽量不给标准的实施团队，而是资深的管理层（CTO 哟）亲自先做。原因如下两个：
- 当你自己都不知道要什么的时候，你无法让别人来做，这是不负责任的表现
- 架构责任极大，需要高层级的人来担
- 最终这个阶段产出的是基础的设计和代码，不一定是可 ship 到市场的可用版本，但决定了整个产品的可行性，未来产品的大致形态等
至此，所有《Shape Up》这本书的内容，我都重新串了一次，希望对您有帮助。