风险驱动开发

快速迭代过程中的问题

在一个项目从0到1快速迭代开发的过程中, 除了常规的需求开发, 还会面临很多问题, 来自于deadline, 线上bug, 用户咨询的问题等等

多人开发过程中, 除了上下游项目依赖, 还存在协作

我们无法完全按照既定的规划注意处理问题, 但是也不能切换到紧急的事情上.

我们应当将目标focus在 重要紧急和重要不紧急的事情上, 而实际迭代过程往往会受到紧急的事情打断, 导致真正重要的事情延期.

那么, 我们应该如何应对这种情况?

---

风险驱动模型是什么?

«恰如其分的软件架构»的第一部分就是讲述风险驱动模型的.

运用最小的架构技术集合去降低最紧迫的风险, 以求事半功倍

步骤

• 识别风险, 并排定优先级(从需求出发)

• 选择并运用一组技术

• 评估风险降低的程度

---

实践

• 首先, 我们采用了OKR的方式管理每个迭代的目标和关键结果
• 在每个迭代开始之初, 先将近期所有事项加入一个池子, 这其中会包含最近加入的issue, 也会包含既定规划好的issue, 以及上个迭代delay的issue.
• 然后逐一review, 评论, 这个过程需要issue相关的所有人员进行review, 补充信息. 补充信息包括, 涉及的人员/上下游状态, 交付时间, 风险点等等.
• 然后, 使用风险驱动开发的模式, 对池子里面的所有issue进行风险评估, 从而确定最重要的事情(注意不一定是最紧急的事情), 最终排定优先级及时间
• 对于紧急而不重要的事情, 采用类似GTD中的二分钟法则(如果一件事情两分钟内能搞定那么马上处理), 如果工作量不大, 那么适当优先处理, 已减少干扰项, 有更大块的时间处理重要的事情

---

问题

为什么每个迭代都需要对issue补充信息?

这是因为, 一切都是变化的, 相关的需求/人员/上下游等等都可能存在变化, 这样就导致一个issue的重要程度变化, 同时也关系到这个issue的风险.

这样做的好处?

在项目的不同阶段, 或者在同一个阶段的不同迭代, 整个项目的风险是动态变化的, 你必须评估项目当前时刻的每一个风险, 最大程度地降低失败的风险