kingbill

看了你第一段感觉你就不想用敏捷，非要把敏捷放到瀑布里用（或者连瀑布都没用起来），你非要这样也没办法。
敏捷交付的是价值，不是功能。咱俩现在是两个频道，鸡同鸭讲。
你有你的场景，你判断你不能这么用，那你就不用就好了。

我们就是这么做的，几乎没有任何的“本土化改进”，就是按照 scrum 去做的，我是 SM ，前期累一点，偏技术管理，2 、3 个月以后大家习惯迭代的节奏就好很多了，我不明白你为什么看了这么多书还不明白应该怎么做。

在我来看，scrum 是一整套体系，不能断章取义，尽量完整使用一段时间再看是不是有不适合团队的地方。

我们一开始也很难，可能是我运气好，碰到了希望和我们一起用敏捷的 PO ，PO 从不知道怎么写 story ，不知道怎么描述我们需要的 value （她知道业务价值是什么，但不知道我要她写在 story 里的业务价值是什么），有时间还会和我讨论，比如：你真的觉得 PO 应该无时无刻和团队在一起办公吗？然后就是聊，改进、再聊、再改进。

然后就是开发团队，可能因为我就是开发出身，所以感觉这个没什么难度。你从心里尊重他们，他们是有感觉的，不管活有多多都坚持每天整个团队 code review ，就是我每天找出一段有代表性的代码，然后投到投影上，大家一起 review ，畅所欲言，谁都可以说，想到什么说什么（这点也很重要，做为 SM 要让团队成员说话，还要注意大家涌现出来的想法）。然后我再结合大家的意见把我修改的代码拿出来和源代码 diff （这是因为 team 一开始的技术水平确实参差不齐），慢慢地大家写的代码就越来越像一个人写的了。

每天站会，不是形式，不是为了汇报进度，昨天我做了什么，今天我要做什么，我还需要谁的帮助。三个问题都要说，重点在第三个问题，但是要让大家能说出来我需要什么帮助。这就和前面的实践有关联了。比如：SM 不能让大家被 100%占用，甚至 80%也不行，我们一般也就是 50~60%，这样大家才能闲下来，这样才能帮助别人，只有你能去帮助别人了，你才会认为你需要别人帮忙的时候，别人回来帮你。至于前两个问题，又涉及到 planning 的时候的 story 评估，必须是开发团队自己评估，自己认领的 task ，如果是被指派的那大家就对别人干了什么，要干什么不感兴趣了。如果每个 story ，TA 都参与评估了，TA 才有可能会关注这个 story 最后是不是按照我当时的建议去干了……

等等等等吧，我也不是说我们就一点问题都没有，但这些都是一点点涌现出来，然后大家一起面对，一起解决的。

期间大家也会有疑问，你说的这样行不行，这个时候你不能独裁，行不行可以试试啊，试出来了大家就知道行不行了。当然，SM 得扛住压力，能去让团队去试。这个时候去“忽悠”PO 和领导就得看 SM 的本事了

哦，对了，我们的迭代是一周一次，开发提出过太短，要变成两周一次，我们也实验过两周，PO 先扛不住，强烈要求回到一周，而且正好当时也出了一次“事故”，所以我也就借机改回了一周（所以你看 SM 的忽悠本领很重要）

大概就是这样吧，不知道这些实践对你有没有帮助

我也有 xps 9550 ，装的 manjaro ，显卡驱动省心点

Lifecycle 接口？

故事点和时间没有严格的对照关系，比如：某团队一次迭代一周，团队一周可做的故事点大概是 12~15point ，那就在 planning 的时候根据优先级等要素选出 12~15point 的 story ，迭代结束的时候看是不是成功了即可，同时这次迭代成功的故事点数又做为以后的故事点评估标准。即：敏捷这个东西看的是 business value ，而不是工作量。只要能在迭代中完成指定的业务目标，工作量的大小不是特别重要（比如，团队这个迭代只完成了 5point ，但也完成了业务目标也可以接受，但在 retro 的时候就需要研究一下 planning 的时候是不是估算有问题什么的）。总之呢，这是一个系统工程，你单独的看某一部分意义不大，所以我推荐你先去把书看一遍，先知道 scrum 是个啥怎么回事，再说里面具体的概念怎么解释

你看看 HHKB 就知道了，顺不顺手只有自己知道

确实抠门，可能因为编程也是这抠抠那抠抠，所以习惯了吧

@1000copy 我说它不一样，你非要认为它是一样的，可能故事点是啥并不重要了，你就按你想的用就行了……（而且我上面告诉你故事点是啥了）

因为在实际执行的时候，同一个工作量的不同工作可能会用不同的时间。
故事点估算只是估算的工作量，而不是完成工作用的时间，而且是按倍数类比估算
可以先把《 Scrum 精髓》看一遍，再来回看你的这些问题