敏捷项目如何评估故事点

敏捷项目如何评估故事点但是在敏捷项目中会，如何需要进行故事点的估算呢？在软件开发整个过程中，我们可能经常听到老板和间隔客户问我们需要多少时间来提前完成项目？或者到某一个时间点，产品能做到什么程度？在瀑布模式下，项目经理们基本需要会给出明确的项目上线时间。但是在敏捷项目中，特别是Scrum开发框架下，变成项目团队变成了一个自社团组织团队，没有了“经理”，那我们如何开展这项工作？如何进行故事点的估算呢？在Scrum的开发框架下，团队共担责任，集体承诺每个Sprint的工作，因此对于工作量的估算通过特兰县集体估算的方式进行。集体估算通常采用估算扑克作为工具。估算扑克是完全符合共识的，电脑游戏化的估算方法。估算扑克是宽带德尔菲法的一种变体，由一组类似斐波纳契数列的数字组成，这些数字包括：0,0.5,1,2,3,5,8,20,40,?,8。它最常用于敏捷软件开发，特别是Scrum和极限编程。那么如何采用估算扑克进行估算呢？在估算会议上，team中的每位人员都会得到一副纸质扑克，当然，随着移动互联网的普及,目前大多数敏捷团队使用了更为便捷的电子扑克。无论电子扑克,还是纸质扑克,牌上都需要包括这些数字1/2,1,2,3,5,8,13,20,40产。产品经理按照排定的优先级顺序从ProductBacklog中可以选择一个用户故事，为大家详细讲解该大伙用户故事；team针对该用户故事进行讨论并提出问题,产品负责人逐一解答大家的问题。当团队成员已经对该用户故事完全了解、不具任何重大问题后,大家开始对该用户故事进行估算。估算时,首先,选择一个比较小的客户故事,确定其故事点,并将该寓言作为基准寓言。然后再将其他用户就要故事和基准故事进行非常,得出普通用户故事的相对其他用户点数,评估完成后,进行下一个用户故事闲家的评估。如果估算值差距明显,代表大家对该用户故事的大小没有获得共识,高估计和低估计的人需要给出他们评估的理由。如在某中同一个用户神话故事的评估中,有的人复核的故事点数为3,有的人复核的故事点数为13,有的人复核的故事点数为8,则评估故事点数为3和13的人需要说明评估理由,观众们对该故事所包含重大任务的任务达成共识后,在对故事点数进行重新评估,相符合直至大家对故事点数的评估基本达成一致。如果对于同一个用户故事的评估中才,可能出现评估相同的故事点数不完全一致,但点数之间差距有所增加,比如在3和5个故事点之间,该用户故事评估故事点数可以采用平均值法进行计算,将平均值将牌结果与评估的故事点数比较,并把与评估故事点差值较小的故事点数作为用户故事的最终点数。如在A故事点的评估中，共有7人参与评估，其中4人评估的故事点数为3,3人评估的故事点数为5，则取平均值后的故事点数为3.85，与评估的故事点3和5比较，平均值与故事点3差值更小，所以，该用户故事的最终点数为3，该用户故事点数评估完成。在哪一个会议上进行用户故事点评估？故事点评估一般在冲刺计划会时进行，并可能需要选定主持人，主持人一般由ScrumMaster担任。为什么需要产品负责人讲解用户故事？讲解手机用户故事的步骤是team和产品调研员之间的交互的环节，能够帮助team和产品负责人共同加深对用户故事的理解。同时产品负责人也会根据大家的反馈，进一步完善用户故事。根据我的经验，在讲解用户故事的投资过程中，千万别千万不要指定该用户故事的负责人或明显的倾向于某些人来做这个用户故事，因为一旦指定了负责人员，可能会大大降低不负责该用户故事代为的team其他领导者的积极性，甚至会扰乱估算的经济秩序与结果。估算完成后，可以任意亮牌吗？估算时每个领袖人选出代表自己估算值牌面上的数字，每个人都将叙伊佩县朝下，不可立即亮牌，待team所有人员示意如期完成评估后，参与估算的所有人员同时亮牌。在估算过程中，团队成员之间不可以互相商讨。这样做是为了避免影响其他参与者，总的来说出一个数字，它可能听起来像一个建议，并影响其他市场参与者的评估。这一整个过程也是逐步提升team独立思考的能力的一种手段。估算与人/天，人/时有关系吗？估算的是一个相对值，而不是绝对值。和人／天，人／时没有关系。假设我们以开车从北京到保定的工作量为参考基准，是1个故事点，那么从北京到太原的距离大概是从北京到保定的3倍，那么我们可以估算从计算北京到太原的工作量为3个故事点。估算时，需要找一个参照物进行估算吗？每次估算时，最好使用相同的标准用户故事，这样对于整个投资项目的统计有很大帮助。使用相对值进行估算，可以如何有效的监控团队的生产能力。对于初次实施敏捷的团队，可能出现对故事点的评估可能还是不太不易理解，根据我的实践经验，初次实施评估故事点时，可以尝试1人/工作量三日的工作量作为一个故事点（与文中描述的“故事点和人／天，人／时没有关系”这句话并不矛盾）。产品负责人和ScrumMaster参与估算吗？关于参与估算的人员覆盖面积，team中的所有人员都要参与估算，可能的角色包括开发人员、测试人员，但不包括产品设计负责人和ScrumMaster。这也是为什么建议team人数5-9人的原因之一，人数太少，会并使估算结果偏差很大，人数太多，会拉长估算时间，降低估算效率。评估时最大点数不超过多少合适？取决于团队。我们团队确定的用户故事最大点数为13，超过13，会将故事卡片或进行进一步的拆分。实际开发中发现了估算失误要不要修改点数？不必。安排测算是为了辅助我们的工作安排，而不是用来科学管理管理模式员工的绩效表现。为了达到精准的估算而了过多的时间盒精力，这是本末倒置。有的故事卡片会比预计的先