敏捷团队的福音

• 資深大佬 : mara1

  我们都是三二一，然后一起伸手指头。

• 主 資深大佬 : playplaycode

  @mara1 这么神奇的吗？我们现在流程是大家出牌，然后不一样的牌要说明理由，然后大家相互讨论（说服），讨论完之后再重新出牌

• 資深大佬 : salaryfly

  很好的想法！

• 主 資深大佬 : playplaycode

  @salaryfly 感谢，感谢！

• 資深大佬 : yunser

  还行吧，以前一直想做个估点的工具。建议加上 websocket 。

• 資深大佬 : mara1

  我们是小组形式，每个小组开发也就 4~5 个人，给 story 估分时候，倒数三二一，一起伸手指头，然后不一样的说说就行了，讨论完就能决定分值了，没有二次估分的场景。
• 資深大佬 : mara1

  另外，开会不看手机，非必要不看电脑，可以让会议更有效率。

• 資深大佬 : lbyo

  @mara1 #6
  团队一起过一下需求挺好的，就是不太明白，模糊工时概念的优点在哪里。直接说大概多久 /几天可以完成挺好的啊，心里大概有个数。
  sotry 点数最终还是要转化为工时的不是吗

• 主 資深大佬 : playplaycode

  @mara1 我们人数稍微多一点，实践看来二次估分基本就是确认大家是否还有疑惑和对最终时间是否有疑义呢！一般功能设计到多个后台同步改动的时候基本都要再阐述自己的改动和消耗时间。他们会在会议上明确自己那块同步修改的难度和所需时间

• 主 資深大佬 : playplaycode

  @lbyo 模糊工时的好处应该是优化产研部门的产出吧！比如这个月产出了 100 个点，下个月产出了 200 个点，这就是提效了。（这是我的理解）

• 資深大佬 : mara1

  @lbyo , 简单的 story 大家没异议，估分一般不会差太多，估分对于一些复杂 story 更有帮助。

  估分对我们团队的帮助：

  1. 加深理解
  大家估分不一致的情况下，拆分成更细的 task，拆分的过程就像解题一样，第一步第二步第三步，这个过程就会发现有些人漏掉了要做的步骤，或者理解的需求边界少了之类的，这个过程会和 BA，测试一起讨论。

  2. 合理安排团队进度
  比如一个 sprint 14 天，你们团队平均完成 100 分的 story，那么如果下个 sprint 有 5 天假期，团队很容易算出，下个 sprint 合理的安排。

  3. 解决长期问题
  这个是从团队管理者角度来看的，也可以团队自查。 从长期来看，sprint 完成分数，story 平均交付时间(从开始开发到发布)，结合其他一些参数，可以帮助团队成长。