[Day13] 团队系统设计－估点技巧

前面的文章讨论过估点与专案管理、风险控管的高度相关性。对於较年轻的工程师来说，估点是一个容易产生挫折感的活动。有关工程的实践方式，有很多的参考资料，但对於估点，可搜寻到的资料多半是概念性的说明，较少介绍实践的细节。今天我来分享一些，由我的团队成员自行发展，并且落地於日常开发的估点实务经验。

根据设计模式

这个方法主要针对用户端开发。目前主流的设计模式大概是 MVC，MVP，MVVM 等，其中心思想都是将画面，业务逻辑与模型分开，以达成解藕合的目的。以 MVVM 的架构来说，我们可以先将 User Story 分拆成 View，View Model， Model 三种不同类型的 Task。 如下图，一个假想的画面，就可以细折成不同的任务。拆 Task 可以帮助工程师思考，寻找问题。而点数是用来沟通的工具，例如，在下面的例子中，动画设计需要 9 点，此时 PO 就可以思考，在 MVP 的精神下，动画是否为高商业价值的特徵 (feature)。

根据正／负向流程

通常，产品专案会包含多个画面，在每个单一画面的估点完成後，就可以针对流使者流程进行下一步的估点。所谓正向流程，是指用户不经历错误到达操作目的的流程，其中可能包含画面切换，非同步事件处理，资料传递等。分析後，若中间有较复杂的逻辑需要特别设计，就可以给予点数。通常正向流程不会产生太多额外的点数。

所谓负向流程，是指每个使用者交互或资料流动可能造成的错误。负向流程通常需要较多的关注，因为很多开发品质的争论都与它相关。负向流程的 Refine ，最好有 QA 的加入，在规画期中，多方就可以针对错误处理的原则，讯息，画面等进行讨论。比如当服务器回传错误码时，该出现什麽画面，使用者该回到什麽状态，这些都可能造成额外的工程需求，都必须给予点数。忽略这个步骤的代价，就是在 Sprint 进行中，会需要大量的多方（ 用户端、後端、 QA、设计师、PO) 进行讨论，打乱开发步骤。

文件阅读

将新技术导入开发，难免需要研究技术文件。这个活动的时间成本，有时容易被上层主管或专案经理忽略。在没有健康的 Refinement 文化的团队中，对看似简单的任务，却有很大的时间估计，通常就是工程师在技术掌握度低时的自保策略。我的建议是，需要读书的时间，就给个点数，提升透明度。接下来，常被问到的问题是：我们怎麽知道需要多久时间才能读完？　根据几个团队运行的经验，我建议与技术文件阅读相关的任数，先给予 1~2 天的点数，重点不在完成，而在「推进」。在站立会议中，必须很明确的回报进度，如果需要更多时间，就以 1 天为单位延展点数。一个运行了一阵子的团队，对於非创新性的技术研究，最终会有一个估点平均值出现，可当作末来的基准参考值。

维护性质的任务

有负责维运性质工作的团队成员曾经反应过，工作较难拆分，估点对他们来说是一件困扰的事情。显然，估点在这个情境中成了维运团队的内部张力。对於有类似困扰的朋友，我还是强调点数是沟通工具，目的是让规画资源的同仁可以保护团队不会负载过重。不能拆分的任务就不要硬拆，给一个整体需要花费的时间平均值，相信不会很难。

刚入行时，我也没有「拆分」、「估点」的概念，工作一下来，就是埋头做，冲出来为止。但能力再强，最终都很容易让自己成为团队的瓶颈。改变自己习惯的结构会有点阻力，但出发就会到达终点。希望今天的文章能帮助到大家，明天见！