RN Studio 团队敏捷开发实践规范
一、核心原则
我们希望团队成员尽可能遵循敏捷软件开发宣言之的精神，坚持以下四项价值观：
| 原则 | 说明 |
|---|---|
| 个体与互动 > 流程与工具 | 团队成员的高效直接沟通优先于工具和流程。工具服务于人，流程不应成为束缚。先进工具可以团队内沟通是否尝试引入来优化流程，反之亦然。 |
| 先跑起来 > 面面俱到的文档 | 我们应当以复仇时刻"能跑起来/变得更好"为主要目标，文档够用即可，避免为写文档耽误开发进度。 |
| 响应变化 > 遵循计划 | 拥抱变化，每个迭代结束后根据反馈迅速调整下一步计划。 |
重要提示：敏捷并非否定流程、文档、合同和计划的价值，而是当两者冲突时，优先选择左侧原则。
二、需求与规划规范
2.1 需求数值化要求
- 所有Bug单/任务单(Issue/Task)必须提供明确的建议数值（如"预期单位具体数值"，"预期效果"等）。
- 目的：提升开发和测试效率，便于量化验收。
2.2 版本规划评审机制
- 每个版本规划需召开会议评审，确保团队对齐方向。
- 会议参与人：相关开发人员、测试人员、内测人员。
- 会议目标：明确版本范围、关键指标、风险点及迭代节奏。
2.3 规划缺失时的处理流程
若版本规划未能按时产出，则需要通知团队主要成员，并沟通未来计划和解决方案，若Issue有指定负责人，@相关负责人。若Issue没有指定负责人，则 @ZeroFanker + @kk + @shuiping233
- 目的：确保规划缺位时有人及时补位，不影响开发节奏。
- 责任：收到 @ 的人员尽快响应请求并推动规划落地。
三、敏捷执行要点
- 小步快跑：将大需求拆分为可独立交付的小任务（拆解大型需求成SubIssue，方便后续追踪/开发/测试）。
- 快速迭代：每个迭代周期固定，按时交付可用版本。
- 注重实用：优先做对用户有价值的功能，拒绝过度设计。
- 及时调头：根据反馈快速调整，不固守过时计划。
四、总结
敏捷的精髓：用最小成本、最快速度交付有价值的产品，并在过程中持续改进。