当开发人员接到新任务后
1. 向上追溯（纵向拉齐）
1.1 首先提出的问题
- 这个任务针对的需求点是什么？
- 用户/客户是谁？他们有什么特点？
- 该需求为用户/客户提供了什么价值？
- 这个需求的满意条件是什么？
1.2 其次想到的是
- 这个需求属于哪个发布版本？
- 为什么这个版本需要开发这个需求？
- 这个版本的满意条件是什么？
1.3 三次想到
- 这个需求属于哪个特性？
- 这个特性还有哪些其他需求？与当前需求的关系是什么？
- 为什么当前需求在当前版本的这个特性中是必须开发的？如果不开发会有什么影响？
1.3.1 特性
特性（Feature）来自《软件需求 第三版》中的特性树（Feature Tree）。一个特性包含一个或多个逻辑上关联的系统功能，能够为用户提供价值。特性树展示了特性如何层层分解为更小的特性组，最终与具体的用户需求关联，引出功能需求。
特性树为项目提供了一个简洁的视角，帮助管理者快速了解项目范围。它通常分为三个层次：一级（L1）、二级（L2）和三级（L3）特性。
注意：特性是一个非敏捷开发概念，与敏捷开发有一定冲突。个人认为，特性树更适合产品开发。如果用户故事无法形成特性树，可能说明用户故事过于分散。
1.4 四次想到
- 当前开发业务的整体目标是什么？
- 版本是如何规划的？
- 当前目标由多少个特性组成？特别是与当前特性关联的特性有哪些？
- 目标的满意条件是什么？
1.5 五次想到
- 如果继续深入思考，可以追溯到产品愿景、策略和企业愿景。由于这些内容较为宏观，此处不再展开。
1.6 思考
- 如果目标错误，做得越多，错得越多。开发人员需要对目标有深刻理解，否则容易事倍功半。
- 如果任务价值不高，即使完成得再好，也难以获得用户/客户的认可。
- 任务到开发者手中时，目标和价值往往已经模糊。PRD（产品需求文档）的一个常见问题是未能清晰传达目标和价值。
- 要做好任务，需要纵向和横向拉齐。纵向拉齐是对目标的追寻，横向拉齐是对关联需求的追寻。如果目标和关联需求需要刻意追寻，说明流程存在问题。
2. 任务追溯
2.1 针对当前任务
- 当前任务的依赖、假设和限制是什么？
- 当前任务的满意条件是什么？
- 有哪些开放性问题需要澄清？
2.2 用户故事
2.2.1 用户故事
拿到任务后，我会尝试通过用户故事来理解任务。用户故事通常包括：
- 用户及特点：作为一个***用户，
- 推荐解决方案：我希望***，
- 价值：以便于***。
有时一个用户故事无法满足需求，可能需要多个用户故事。例如，一个功能可能有使用者和维护者，需要分别描述。
2.2.2 应用场景
用户故事较为抽象，我会尝试写一到三个应用场景，描述功能的具体使用场景。应用场景更形象，有助于在不同人员之间达成一致，并为问题解决提供依据。
2.2.3 满意条件
在用户故事和应用场景后，我会列出满意条件（验收条件）。满意条件需要与业务人员沟通并达成一致，建议不超过7条。
2.3 开发
2.3.1 估算与计划
在敏捷开发中，通常使用斐波那契数进行估算。我会先制定一个简单的计划，作为后续调整的基础。
2.3.2 关联图
在开发前，我会绘制关联图，明确任务之间的关系和依赖。