关注嘉为科技,获取运维新知
一、为什么不用“人天”?
传统的IT项目,尤其是软件开发项目,往往使用“人天”来作为工作量评估的量词、甚至是代表一种评估方式。在软件项目开发经典著作《人月神话》中,明确的指出了按“人月”或“人天”来评估需求工作量的巨大弊端,主因之一就是在于这个词让人产生了“可以使用更多的开发人员就可以更快速的完成软件开发”这一错觉。在Agile敏捷项目当中,大都避免在快速需求评估阶段使用“人天”。具体请参看《人月神话》。
《人月神话》中最著名的插图“焦油坑”
二、Story Point故事点
智能边缘计算作为一种新模式,使得物联网的每个边缘设备都具备数据采集、分析计算,通信,以及最重要的本地或就近的“智能”。新的智能边缘计算同时利用了云计算的能力,利用云来大规模的进行安全配置、部署和管理边缘设备,并能够根据设备类型和场景分配智能的能力,从而让智能在云和边缘之间流动,获得两全其美的结果。
计划扑克基于Story Point故事点,扑克牌牌面上印刷的巨大数字就是故事点。
那么,什么是故事点呢?
“故事点”是Scrum敏捷开发过程中所使用的概念,它代表某开发团队内部所推选的一个抽象的标准工作量。一个故事点,可以是大家熟悉的一件较独立、较简单工作的全部内容,比如,一个常见功能页面所涉及的所有的开发工作,包括该页面UI的设计、代码的编写、数据库表的设计等等。
这样一来,在快速评估的过程中,一个新需求大概的工作量是上述这个“标准工作量”的2倍的话,那这个新需求的粗略工作量就是2个故事点。
一副计划扑克提供了一组不连续的故事点数字,以便于代表不同大小需求的工作量。
计划扑克的故事点数序列,一套13张,同一种颜色
三、牌面数字的含义
0表示所选需求块非常简单,或者可以通过重用快速搞定,不需要精力就能完成;
?表示根据目前掌握的情况,暂时无法评估该需求块需要多少故事点,需要进一步了解与细化需求;
咖啡杯用于提示团队成员该休息了,实在太累了。
与纸币的规则类似,牌面没有的点数可以由多张牌累加而成
四、牌面最大数字才100,不够用怎么办?
任何一个大需求,都需要渐进明细、直到足够小足够详细才能进行设计编码。因此,对于开发人员进行设计而言,超级大的或很粗粒度需求是没有太大意义的。对于不少团队而言,仅一个大小为100故事点的需求,就可能需要消耗好几个迭代周期的工作量,更不用说大于100的了。
使出100牌的开发人员,往往是希望表达对于业务的庞大复杂的不解或者恐惧、或技术投入或风险的担心。而对于自己感觉更加不靠谱的,可以直接出那张问号卡牌。
对于像大部分人都会评估为40或100牌面的大需求,需要由Product Owner负责或牵头来不断细化,直至拆分为多个且足够详细、足够小的子需求,才有可能进入下一个迭代周期的开发排期。
可灵活组合的牌面
五、注意事项
每副扑克都会包含1~2张使用说明,中文或英文,介绍扑克的基本使用规则。
每位开发人员,应拿到一套13张,以便使用纸牌表达自己对某需求块工作量大小的快速评估。有些型号的计划扑克,会有四套,每套一种不同的颜色。参与评估的开发人员多,就需要同时使用多副扑克。
针对Product Owner每讲解的一个新需求,所有开发人员都需要同时出牌,以便能表达出每个人的独立观点。
点数最集中的评估结论往往会被采纳。与大多数差异很大的评估者可能会被提问说出自己评估的依据。对于该需求最了解的人员的评估,往往会被高度重视,而不是一味的少数服从多数。
六、小结
Planning Poker计划扑克是很多敏捷开发团队非常喜爱的小工具,几元十几元一副的超低成本,在需求的快速评估阶段,可以让每个团队都全情参与进来、并且“无废话”的独立表达自己的观点,若运用得当,则可能大幅提高早期工作量评估及需求排期的效率。每个团队还可以进行微调、探索最适合自身及项目特点的玩法。在这一阶段评估成功完成之后,需求仍然较粗,还需要进行进一步的需求细化和具体开发工作的拆分与认领。
【注:】本文部分图文内容来自相关公司及互联网,该部分的版权属于原所有者。
原创文章,作者:carmelaweatherly,如若转载,请注明出处:https://blog.ytso.com/195837.html