敏捷开发之团队公约.docVIP

团队公约 一、早会规则 每日早会召开前，团队成员需在行云看板更新各自单据状态，并准备好早会发言内容。 固定时间早会（上午 10:00），由团队成员轮流主持，会议时间控制在 15-20 分钟。 早会内容： 1. 2. 3. 昨天我完成了什么工作：具体非细节地表述昨天完成的情况。 ? 今天我计划做什么工作：预期今天任务的完成程度，会不会完成或预测完成时间。 ? 在工作中我遇到了什么障碍：如果有任务的截止时间，可说明是否有基于截止时间 ? 的风险。 早会不对具体问题进行深入讨论，如有必要另外组会。 参会人员需保持专注态度听取其他团队成员发言，不低头看手机，确保每个人都明确了 4. 5. 解每日早会内容，同时保持团队成员间的交流互动。 早会主持人需提前浏览迭代看板内容，在团队成员发言过程中，可比较明确地追踪成员 6. 所讲的单据，发版周由主持人最后对早会做总结性说明或表述，如：通过整体看板说明当 前迭代情况。 一般情况下早会请假需提前说明：在项目团队群说明；或与早会主持人提前说明自身任 7. 务进展情况，或告知其他成员请其代发言。 二、迭代规则 迭代周期：两周（10 个工作日） 迭代截止时间：迭代第二周最后一个工作日 18:00，截止当天 15:00 仍未完成的任务，需 1. 2. 告知产品，产品依据实际情况调整安排至下一迭代。 团队日历： 3. 周一 周二 周三 开发 周四 开发 周五 开发 第一周 第二周 迭代计划会 开发 测试用例编写 测试用例编写 测试用例编写及测试用例便写及 评审 评审 SIT 测试 SIT 测试 周一 周二 周三 周四 周五 开发 开发 开发 开发 需求澄清会 回顾会 SIT 测试 SIT 测试 UAT 验收 UAT 测试 UAT 测试 注：拥有完整需求任务的迭代按以上规划，推广实施阶段依据实际情况调整。 迭代会时间：迭代第一周第一天下午（一般为 14:00-16:00）。 迭代会内容：Story 澄清、Story 评估、Story 认领、Story 任务拆分。 4. 5. 三、需求规则 需求评审： 1. 日常需求，如：新功能建设 、功能改版等，产品团队需先做初步评审（产品经理≥2 ? 人），然后进行项目团队评审，评审人员包含产品、开发、测试、运营（如涉及配置） 等。 小型需求，如：文案修改、样式/像素调整等不涉及技术方案的需求，可由产品或产 ? 品与设计师直接确认，不要求团队评审。 需求呈现方式： 2. 3. 4. 因涉及与其他项目组需求沟通，或部分业务需求确认要求格式，因此呈现方式包括： ? 润工作 3.0 在线文档、Axure RP 原型、Word 文档、UI 效果图等。 需求依据故事方式编写，并具备 AC（验收准则）。 ? 需求优先级： 高：VIP 业务需求、核心功能问题。 ? 中：普通业务需求、项目组需求及日常迭代优化。 ? 低：开发自驱动提出的优化项。 ? 需求讲解： 需求产出并通过产品团队初步评审后，产品需组织团队成员进行需求讲解，讲解前 ? 需提前提供相关文档或说明，团队成员在初步了解后，再进行进一步讲解。 针对明确需求，如为需求方案未明确的情况下，建议先进行需求方案沟通确认，明 ? 确需求后再对需求细节进行讲解说明。 需求澄清： 5. 6. 需求讲解清晰后，需由团队成员反讲需求，做需求澄清，确保相关成员都了解清楚 ? 需求后，再进行开发。 一般情况下日常需求都需进行需求澄清，重点为开发测试向产品澄清。 ? 需求置换： 当出现高优先级的新需求，需对正在进行中的需求做置换时，产品需清楚知会相关 ? 成员，如：早会、项目沟通群等。 产品组织相关成员进行评估，确认新需求的开发人天，以及可被置换的需求，相关 ? 负责人在行云单上对被置换的需求进行备注说明。 需求变更： 7. 如为需求开发前期，不影响项目整体进程，产品应及时修改需求文档/说明，测试调 ? 整测试用例，开发按变更后的需求投入开发。 如为需求开发中后期，影响项目整体进程，应考虑延长交付时间，或削减部分功能 ? 需求，分迭代进行开发。 四、评估规则 评估阶段： 1. 2. 迭代会-迭代计划阶段：通过 poker 的形式进行故事点评估 ? 评估要求： 需有基准或参照值，如：新增功能开发或测试某一功能，依据历史工作量做基准或 ? 参照判断，与该参照物进行对比，进行故事点评估。 评估时除参照基准外，团队觉得故事点过大或者下，通过 poker 的方式进行多轮评 ? 估 五、开发规则 开发人员需对开发完成的功能进行自测。 1. 2. 3. 4. 完成开发任务后需组织产品、测试、运营（如涉及配置）等人进行 Show Case。 统一开发环境，先统一使用 IDEA。 代码提交： 前后端提交代码一定要遵守代码提交规范，每次提交的代码只含有单个迭代 任务的