Shape Up 翻译为中文意思为持续改进，或者精进的意思。目前还没有找到更准确的翻译，以下内容都按精进表述。
团队
- 产品团队：负责需求分析，制定方案框架，每个成员要有一流的分析、设计、表达能力，部分重要人员还要具备开发经验。
- 执行团队：负责开发、设计，开发小组及设计师搭配执行落地。
- 安全团队：黑白测试，部署上线。
方案的核心就在于
- 资深团队、成员分析需求，将想法变成可执行的方案
- 掌舵者和资深团队一起审议，挑选优先级最高的方案
- 执行团队无干扰推动进展
- 一切以发布为首要任务
周期
团队的工作内容不同分分为周期内和周期外，周期内是执行团队，周期外是产品团队。
六周是一个大周期，小的项目为两周的小周期。
产品团队比执行团队提前一个或几个周期完成文案（Pitch）等待执行团队的 Betting（押注）。
周期外
产品团队六周完成 Shaping（塑造）输出文案（Pitch），2周 Betting（押注）评审通过交给执行团队。
周期内
执行团队开始的Building （建设），由团队 leader 分解并分配任务，在期限内产出。
2周 Betting（押注）时间，执行团队除参加会议外还需要修复遗留的 Bug ，也可以尝试一些新东西，自我充电。
如果团队在一个周期内的工作量不饱和，甚至只参与其中很小的一部分时，可以给团队分配多个小项目，但是不能突破六周的周期规定。
六周加两周是 Basecamp 这家公司自己制定的最合理周期，国内团队目前不太容易做到。根据实际情况把大周期缩短一半三周加一周，小周期一周半加一周。
流程
分为三步：
Shaping（塑造）：对需求进行探讨、分析，给出解决方案的雏形，预估风险，输出文案（Pitch）。文案要求定义完整、轮廓明确，并留出了细节空间待执行团队去解决。
Shaping 结果则要求满足三个条件
- Rough 这个计划必须是简单粗浅的，只设计大框架，而不深入细节。这里 Shape Up 提了个观点非常有意思，计划越详细，最后要花的时间越多，因为一旦你把细节都设计好了，团队在执行的时候，可以做的 tradeoff 越少，反而会投入更多的时间
- Solved 这个计划必须是可以执行最后产出结果的，这要求了计划必须考虑清楚潜在的坑（rabbit hole）
- Bounded 这个计划必须是有边界的，既要知道什么可以做，也要知道什么不能做，到哪里止步。
Shaping 由专门的资深团队来做保证质量，这个团队做完 Shaping 把方案雏形交给其他执行团队来执行。
Pitch 文案内容包含
- 想解决的问题
- 项目的大小，small batch 还是 big batch。Small batch 需要在一两周内完成，Big batch 则是六周内完成
- 解决方案
- 潜在的坑
- 有哪些功能是不要做的
Pitch 文案的评审工作由产品领导和执行领导共同参与。
Betting（押注）：将⼯作变成⼀个有期限和团队的计划项⽬。
完善的⽅案、各方关键人员在一次高效的会议中把方案交给接到各执行团队，执行团队在接下来的六周内需要不被扰的工作，产出一个令人惊艳的产品。
要做到完全不被打扰可能在现实中有一些困难，我们梳理一些规则尽量减少这种事情的发生。
Bug 的优先级，只有事故级的 Bug 才立即处理，其它 Bug 等到冷却期再处理或集中一个时间段清理 Bug 列表。
新的需求文案需要中断执行团队正在进行的工作，这种事件应该是极少的，如果你的团队经常要这么做的话那么团队的士气将受到打击。
Building （建设）：团队在成型的概念轮廓内⼯作，将项⽬分解成不同范围，整合前后端⼯作，并在早期完成⼀个范围，以验证概念并获得动⼒。再往后，团队对整个项⽬的范围进⾏规划，按照优先级来先完成最重要的范围。
执行团队对分解工作任务，对应到人，合理安排时间。
要点
轮换制度
- 资深工程师参与到执行
- shaping团队每次预留位置给初级工程师, 每个release轮换
执行
本质上执行团队拿到的是一个porject, 而不是一个tasks.
执行过程中需要拒绝干扰
Debt/Bug Fixing
每个release之间, 增加两周的自由时间. 团队利用这些事件来进行bug修复和代码重构
局限
适合这个 20 – 50 个人的团队
要求推动者能够获得较大的产品控制权，要高度自治
参考文章：
Shape Up: Stop Running in Circles and Ship Work that Matters | Basecamp
「Shape Up」 适合中小团队的一种工作方式 – Rebornix, homepage and blog belongs to Peng Lv.
Shape Up – 贝克街的设计师笔记