关注嘉为科技，获取运维新知
一、为什么不用“人天”？
传统的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计划扑克是很多敏捷开发团队非常喜爱的小工具，几元十几元一副的超低成本，在需求的快速评估阶段，可以让每个团队都全情参与进来、并且“无废话”的独立表达自己的观点，若运用得当，则可能大幅提高早期工作量评估及需求排期的效率。每个团队还可以进行微调、探索最适合自身及项目特点的玩法。在这一阶段评估成功完成之后，需求仍然较粗，还需要进行进一步的需求细化和具体开发工作的拆分与认领。
【注：】本文部分图文内容来自相关公司及互联网，该部分的版权属于原所有者。