@zhongjianxin
2017-04-10T17:21:55.000000Z
字数 2206
阅读 812
training
#[项目生命周期]
介绍参与者，活动，交付物。
用户故事拆分时，需要考虑：
* 角色
* 格式
* 原则
角色
从系统中的角色出发，沿着 User Journey 梳理用户故事。
细分角色，比如一个育儿社区应用，用户可以有爸爸，妈妈，爷爷奶奶等，他们的需求和痛点可能是不一样的。
格式
As a ... I want ... So that ...
原来我们描述需求时，基本只有中间的功能部分。不提这个功能是为谁做的，需求不明确时，不知道该找谁确认，功能上线后，不知道找谁要反馈。也不提满足了用户的什么价值，做出来也没有用户去用。
原则
3C
* Card，用粗笔将 User Story 写到物理卡片上，用粗笔是强迫不能写太多太详细，促进当面沟通。
* Conversation，Dev 会拿着卡去找 BA 和 QA 讨论。
* Confirmation，讨论完要确认验收条件。
一个良好的User-story的编写应该遵循INVEST原则：
Independent：独立性
用户故事之间应该具有独立性（有点类似于UT中的test case），不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级，只有被依赖的用户故事完成才能继续开发依赖的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
Negotiable：可协商
用户故事不是签订的商业合同contracts，它是由客户或者PO同开发小组的成员共同协商制定的，如果最开始像商业合同一样设定了太多的条条框框和限制就无法更好的沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。
Valuable：有价值
用户故事必须对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
Estimable：可评估
故事不能太大，也不要有太大的业务和技术不确定因素，否则就无法评估。
Small：短小
故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少划分过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。
Testable：可测试
个人认为这一点在所有的特性中对于用户故事的重要程度最高。首先，如果一个用户故事无法进行测试，那么也就无法判断该故事是否完成。除此之外，对应的验收测试也最好是自动运行的，这样在任何时候都能触发该用户故事的检验。最后，必须在定义了验收测试通过的标准后才能认为故事划分完毕。
为什么要站着开？
控制时间。坐着太舒服，很容易不小心延长开会时间。如果站着开都还是长，可以平板支撑开，或者站在风口上开，反正就是要控制好时间。
怎么开？
团队每天固定时间在 Story 墙前围成一圈，更新信息，通常回答三个问题：
1. 昨天做了什么
1. 今天准备做什么
1. 遇到了什么问题
Token 是什么？
如果人数较多，为了保持一个会话，避免开小会，可以用一个物件当做令牌，只有拿到令牌的人才可以讲话。
什么是 Parking Lot？
站会过程中如果有比较耗时的话题，可以先写一张 Sticker 贴到停车场。等站会结束后再分头讨论。
怎么开好站会？
* 不说重复的内容，比如：昨天做了 IPM。
* 提前准备好要说的内容，不要边想边说
* 看着大家说，而不是一直盯着某个人，PM
扩展阅读：
* 开不好站会？首先要知道不同阶段站会的目的不一样
Dev 在从 Ready for Dev 栏领取 Story 时，流程如下：
* 拿下物理卡
* 打开电子卡理解需求
* 找 BA 和 QA kick off
* 确定 AC
在开发完，把卡片挪到 Ready for QA 前，需把 QA 叫到自己的电脑上，使用测试环境，根据 AC 演示功能。
每天，所有开发人员一起 Review 当天的代码，一个人主持，一个人记录。
按提交记录逐个过，注意提交消息格式的统一性（首字母是否大写，末尾是否有句号，是中文还是英文）。
记录者用报事贴，每张记录一个问题，写上代码提交者名字，文件名和问题简要描述。
在每个迭代最后一天，邀请客户，整个团队给客户演示这个迭代的开发成果，逐个 Story，逐个 AC 演示。
将客户的反馈记录下来，更新到 Backlog 中。
Showcase 可以增强客户对团队的信心，尽早地获得反馈，发现潜在风险。
回顾会议是团队持续改进的基础，在回顾会议中，团队不讨论具体需求和技术，只讨论工作流程和实践。
在不同阶段，回顾会议的目的也不同，刚组件的团队，主要是建立信任，比如采用 360 degrees appreciation。
在正规期和高效期，更多的是产生改进的 Action。
回顾会议有很多种形式，参考我司国外同事的书：http://www.caroli.org/book-fun-retrospectives/