能直接放到
客户面前的
软件。

阶段有意重叠。第一块切片一清楚，设计就开始。开发不等一份完美文件。发第一版时已经想着扩展 — 只是不会在第一天做过头。

1. 01

   发现

   任何人打开编辑器之前，先把要做的事写下来。

   最初的对话谈的是产品，不是技术栈。给谁用、已经有什么、什么不能坏、「完成」实际长什么样。简报乱是正常的 — 我们会问到具体到可以据此开发。

   你会拿到书面的工作轮廓：范围内、范围外、第一块切片、风险、协作方式。可以要，也可以不要。宁可停在这里，也不启动没人相信的开发。

   你带走什么

   • 简短的书面范围和成功标准
   • 范围内、范围外、可以再等的
   • 可以交付并从中学习的第一块切片
   • 我们如何沟通、演示和做决定
   
2. 02

   设计

   改起来还便宜的时候，你可以和产品较真。

   我们把范围变成你可以点的东西：流程、页面、会反复出现的少数组件。重点不是一份好看的文件，而是找出别扭之处 — 空状态、权限、没人想到的第三次点击 — 在它们变成工单之前。

   静态原型不够，就在真实技术栈里做尖峰验证。评审对象是会用它的人，不只是委托它的人。达成一致后，那份文件就是我们要做的。它不会掉进真空。

   你带走什么

   • 可点击的流程和核心页面
   • 一套小的设计系统，不是 200 个组件的工具包
   • 点名的未决问题，不藏在评论里
   • 与第一块切片匹配的开发顺序
   
3. 03

   开发

   每周可运行的软件。你看、你试，我们调整。

   启动会上的人就是写代码的人。你拿到自己控制的仓库、每周可点击的演示、一个放决策的地方。哪一周做得薄，我们直说。没有可运行软件的状态不算进度报告。

   测试、日志和发布方式边做边加 — 不是最后再打扫。出了偏差，趁还小就抓住。范围可以变；我们把取舍写下来，账单就不会变成意外。

   你带走什么

   • 你拥有的仓库、环境和发布路径
   • 每周可运行软件的演示
   • 写下来的决策，不是谁也找不到的聊天记录
   • 产品里的质量和监控，不是以后另开的项目
   
4. 04

   扩展

   发布不是合作的结束。

   真正的问题从正式上线开始：生产环境的缺陷、业务变化、需要读懂代码的新同事。我们加固已经在跑的系统，衡量真正重要的指标，如果你希望我们继续，就继续交付下一块切片。

   你应当能把产品收回内部。架构、测试和注释留在你这边。希望我们留下，我们就留下。不希望，你也不该感到被锁住。

   你带走什么

   • 你可以运营的生产系统
   • 你的工程师跟得上的交接说明
   • 若要继续，已划定范围的下一块切片
   • 会回复的支持，不是工单黑洞