Scrum实践，计划会议中的用户故事，需求是否已经很明确

在实施Scrum中，因为我们团队都是没有这方面的经验，会遇到各种方面的问题，细节上的问题特别多。
就如在进行计划会议时候，PO在阐述用户故事时候，团队都对用户故事的细节不够清楚，从而很难承诺在Sprint在完成功能的开发。
然后我打算采用一下几种方案：
1.PO和策划人员一起工作，在计划会议之前，先把用户故事排序好，并且把认为需要在这个Sprint期间需要做的用户故事做好策划，（写好需求文档、画好原型），在计划会议时候，PO就阐述这些用户故事，团队从而比较明确用户故事是做成怎么样的，容易判断故事点和可以承诺完成。

2.PO只能确定用户故事的大致方向，而具体的细节还不明确。在计划会议时候，策划团队和开发团队同时判断用户故事。当然，如果计划会议上，用户故事能够很明确做成怎么样那基本没有问题，如果用户故事具体细节还不明确，策划团队需要估算策划的工作，那需要在计划会议之后，策划团队需要做更多的策划工作（分析、更新需求文档、画原型）。

不知道各位的scrum实施细节是怎么样的，分享一下经验。

一开始可以不用分析得太透彻，那会浪费你们大量时间用于扯淡和天马行空。

1. 有界面的需求先画个简单的界面。判断需要哪些操作（输入输出）
   不一定要用代码来做原型，画在纸上或者是EXCEL（怎么画自己研究）
   分解： a)开发出界面   b)显示数据  c)操作数据
   需求不明确情况下，做到这一步即可。但是需求人员需要迅速跟进，需要添加些什么。

2. 没有界面的需求通常是纯业务处理的，比如有复杂的业务处理流程。
   那么通过分析需求目标来分解出
   a)达到目标的第一个点   b)第二个点  c)....  d)得出结果

涉及到界面的比较好处理。纯业务的需要在前期把业务执行步骤确定好。

界面的需求启动时只需考虑输入输出达成即可。通常你用MVC设计模式的情况下，后期增加业务处理不会很难。但是需要先启动。一定要画好原型。这样开发人员理解起来更容易。一个界面原型的理解通常不会超过5分钟，然后他就会有问题和意见要发表了。

需求文档这个反而是浮云。重要的明确的需求写上。
如
1. 保存时需要调用第三方系统进行XXXX
2. 第三方系统处理完成后需要XXXX
3. 需要同步数据到XXX
之类硬性需求。有了这些就可以要开发人员进行相关工程级设计了。需要开发人员在相关需求上进行更详细的补充。以及提供出解决方案之类用于评审。

这种方式可能启动阶段估算不准，但是用户故事是可以增加的，至少在你交付版本前一个星期是可以增加的。

以最快速度启动并且开发出第一个需求。

以这个为目的，只有看到实际的东西，才会有想法出来。策划设计神马的。很快就会落后于你的开发进度。

文档可以在后期补充。给开发人员递小纸条好了。（当然，你要有个小纸条备份）

会后team写testcase 交PO确认

计划会议的时候显然没有详细的需求文档，只有用户故事，即原始需求的
团队成员之所以没有办法弄清楚需要花多少时间，一个很可能的原因是用户故事写的太粗了，建议不要超过一个人做一周的规模

Scrum中鼓励"just enough"，细节不能澄清但是不阻碍工作的开始，其实也就够了。要理清细节，无非是出于两个目的：这个需求的具备高价值；或者这个需求蕴含高负面风险。

至于承诺在Sprint中完成功能开发，这个导向也有待研究，"commit the best possibility”，在sprint中不能完成开发，那又如何；做scrum规划，视其为一个过程而非结果。

如果使用故事点来做估计，“承诺在sprint内完成功能开发”本身就是个伪命题，不需要承诺...

我们的planning meeting分为两个部分, planning meeting 1 是team,PO和Stackholder共同参与,PO之负责分配story给team并排列priority.具体问题描诉由Stackholder解释.planning meeting 2只有team参与,讨论每个story并把story拆分为task card. 在implement过程中有问题直接联系Stackholder,PO不再参与.
如果有很复杂的story我们会在第一个sprint的时候只做analyse

不是:
一般会有修改......你知道的他们习惯了....

我的理解scrum更多是一种管理手段，而不是开发手段。就是说scrum是一种敏捷管理，当然管理当中包括开发。也就是说需求的明确可以是一个sprint.用户故事我觉得应该算是明确了，就是说用户要做那个事情了。但是需求的细节还没有明确。就是说还要经过分析和设计阶段。

scrum开发是有点强度的！