敏捷开发之团队公约

团队公约

一、早会规则

1.每日早会召开前，团队成员需在行云看板更新各自单据状态，并准备好早会发言内容2•固定时间早会（上午10:00）,由团队成员轮流主持，会议时间控制在15-20分钟

3.早会内容昨天我完成了什么工隹具体非细节地表述昨天完成的情况0;今天我计划做什么工作预期今天任务的完成程度，会不会完成或预测完成时间在工作中我遇到了什么障碍如果有任务的截止时间，可说明是否有基于截止时间的风险

4.早会不对具体问题进行深入讨论，如有必要另外组会

5.参会人员需保持专注态度听取其他团队成员发言，不低头看手机，确保每个人都明确了解每日早会内容，同时保持团队成员间的交流互动

6.早会主持人需提前浏览迭代看板内容，在团队成员发言过程中，可比较明确地追踪成员所讲的单据，发版周由主持人最后对早会做总结性说明或表述，如通过整体看板说明当前迭代情况

7.一般情况下早会请假需提前说明在项目团队群说明；或与早会主持人提前说明自身任务进展情况，或告知其他成员请其代发言

二、迭代规则L迭代周期两周（10个工作日）

2.迭代截止时间迭代第二周最后一个工作日18:0，截止当天15:00仍未完成的任务，需告知产品，产品依据实际情况调整安排至下一迭代周一周二周三周四周五第一周

3.团队日历迭代计划会开发开发开发开发测试用例编写测试用例编写测试用例编写及测试用例便写及评审评审周五周一周二周三周四第二周开发开发开发开发需求澄清会SIT测试SIT测试UAT测试回顾会UAT测试UAT验收SIT测试SIT测试注拥有完整需求任务的迭代按以上规划，推广实施阶段依据实际情况调整

4.迭代会时间迭代第一周第一天下午（一般为14:00-16:00）o

5.迭代会内容Story澄清、Story评估、Story认领、Story任务拆分

三、需求规则

1.需求评审日常需求，如新功能建设、功能改版等，产品团队需先做初步评审（产品经理＞2人），0然后进行项目团队评审，评审人员包含产品、开发、测试、运营（如涉及配置）等示型需求，如文案修改、样式/像素调整等不涉及技术方案的需求，可由产品或产品与设计师直接确认，不要求团队评审

2.需求呈现方式因涉及与其他项目组需求沟通，或部分业务需求确认要求格式，因此呈现方式包括润工作

3.0在线文档、AxureRP原型、Word文档、UI效果图等需求依据故事方式编写，并具备AC（验收准则）

3.需求优先级高VIP业务需求、核心功能问题;中普通业务需求、项目组需求及日常迭代优化低开发自驱动提出的优化项

4.需求讲解需求产出并通过产品团队初步评审后，产品需组织团队成员进行需求讲解，讲解前需提前提供相关文档或说明，团队成员在初步了解后，再进行进一步讲解针对明确需求，如为需求方案未明确的情况下，建议先进行需求方案沟通确认，明确需求后再对需求细节进行讲解说明5需求澄清.需求和解清晰后，需由团队成员反讲需求，做需求澄清，确保相关成员都了解清楚需求后，再进行开发o一般情况下日常需求都需进行需求澄清，重点为开发测试向产品澄清

6.需求置换o当出现高优先级的新需求，需对正在进行中的需求做置换时，产品需清楚知会相关成员，如早会、项目沟通群等产品组织相关成员进行评估，确认新需求的开发人天，以及可被置换的需求，相关负责人在行云单上对被置换的需求进行备注说明

7.需求变更如为需求开发前期，不影响项目整体进程，产品应及时修改需求文档/说明，测试调整测试用例，开发按变更后的需求投入开发如为需求开发中后期，影响项目整体进程，应考虑延长交付时间，或削减部分功能需求，分迭代进行开发

四、评估规则

1.评估阶段迭代会-迭代计划阶段通过poker的形式进行故事点评估

02.评估要求需有基准或参照值，如新增功能开发或测试某一功能，依据历史工作量做基准或参照判0断，与该参照物进行对比，进行故事点评估评估时除参照基准外，团队觉得故事点过大或者下，通过poker的方式进行多轮评估。