敏捷拆包过程实践

本次敏捷拆包以行啊产品线V2.11.0版本实践，过程记录于此：
1、会前准备（一般为需求人员/统筹人负责整理）
一般来说，会前准备的内容架构可以包含：用户故事、任务拆分、优先级、验收标准。
（1）用户故事
用户故事是从用户角度来描述用户渴望得到的功能。
用户故事需要满足三个点：who、what、why
-who：角色，谁要用这个功能
-what：活动，需要完成什么样的功能
-why：为什么需要这个功能，这个功能带来什么样的价值
用户故事通常按照如下格式来表达：作为一个<角色>，我想要<活动>,以便于<商业价值>，举例：作为一个“旅客用户”，我想要“预定机票”，以便于“我能够从重庆到达北京”。
（2）任务拆分
将用户故事拆分为任务，故用户故事要尽量短小，一个故事为一个任务，任务最好不要超过3天的工作量，用户故事量越大，在安排计划，工作量估算时风险越大。
（3）优先级
根据需求将任务的优先级进行排列，以方便在任务认领时优先领取
（4）验收标准
分析需求需要使用到的角色/产物标准，如是否需要交互设计师、视觉设计师、前端工程师，产物的标准应该是怎么样的。
2、敏捷计划会议
（1）所有成员上交手机、电脑，不能有干扰元素存在；
（2）统筹人或者需求分析人员讲述用户故事及任务，大家提出疑问，并解释疑问，确保每个人对需求清楚明白；
（3）确定任务之后，全员进行任务的投票估点，目前ICED是按照时间来估点，如：某个任务完成需要4h，可估算完成该任务需要4个点；成员投点差距相差一倍，需要角色成员进行解释，然后再继续投点，取平均值；点数估算值为：1、2、4、6、8、10 ；
（4）把点数记录在任务页面上面，一般来说，估算的点数会乘以一个系数，比如乘以1.5。
3、每日站会
（1）总结昨日工作情况和问题
（2）对任务进行认领，只认领当日任务
（3）会议时间尽量控制在10分钟以内，鼓励项目成员多发言，统筹人少发言
4、 项目总结会议
（1）总结本次迭代中遇到的问题及改进方案
（2）汇报整体工作情况

本次拆包实践过程中遇到的问题：
（1）部分需求分析不到位
（2）用户故事颗粒度大
（3）任务估算不准确
（4）需求变动
（5）两个人认领的任务存在联动性，缺少沟通