Scrum敏捷软件开发始末

格鲁夫给经理人的第一课

情商3部曲

scrumalliance

历史来源

谁使用了这个功能完成了什么

成本/收益

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

关于用户故事，用3个C来描述它：<br>1.卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。<br>2.交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。<br>3.确认（Confirmation）- 通过验收测试确认用户故事被正确完成

1.独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。<br><br> 2.可协商性（Negotiable）— 主要是实现价值，换个法子实现也是可以的，价值最大化<br><br> 3.有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。<br><br> 4.可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。<br><br> 5.短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。<br><br> 6.可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

一个正常流程

两个异常流程

编码

测试

代码review

会议

学习新技术

解BUG

低优先级的丢回产品backlog中

产品backlog中拿过来需求

验收标准是什么