前几天看了几篇文章，讲KPI是如何万恶，如何导致一个公司偏离了初衷，变得不再受用户喜欢。 其中，一个厂长的原话是这样说的：
“从管理层到员工对短期KPI的追逐，让我们的价值观被挤压变形了，业绩增长凌驾于用户体验，简单经营替代了简单可依赖，我们与用户渐行渐远，我们与创业初期坚守的使命和价值观渐行渐远”.
本人一直不是KPI的粉丝，也无意为KPI来辩护。 但是，对于一个公司的管理者来说，无论是高层，中层，还是一线，谁也不容易抵制魔术般神奇的数字指标的诱惑: 只要拿他们来衡量每天所做的事情与自己定义的成功之间的差距，就能看到离成功多远(或者多近）了，就能更加容易成功了。（当然了，还有的老板想要通过这些指标，了解员工是不是在偷懒 ：）这都是因为成功太难了，影响成功的因素太多了。
但是，指标的设立，是一件非常敏感的差事。一方面，需要记住，你测量什么，你就能得到什么；另一方面，没有指标，对任何项目都是非常危险的：因为从一开始，成功是什么就没有搞清楚。
在过去的一年中，我管理着三个web开发团队，一个devops组和一个手机app团队，总数有三十几个优秀的软件开发工程师。其中，web开发团队是真正的分布式的，跨国的团队：两个在东欧，一个在中国。当然了，语言也是以中英文为主。我们的所有的开发团队，都采用了ScrumBan的管理方式：每个团队有一个技术team lead。每个团队成员都轮流做scrum master。管理这样复杂的团队配置下的软件开发，我们使用了下面的指标。
燃起图（Burn-up chart）
在把开发任务按照优先级，组合成一个发布后，产品经理和工程师一起，评估要开发的任务。每个任务都有一个点数。这样，所有开发任务的点数的总和，就是该发布的总的工作量。然后，开发工程师会根据过往的迭代开发速度和总的点数，来预估发布完成需要多少个迭代。
如果把这个发布看作一个项目的话，燃起图就是用来跟踪项目实际开发进度与计划开发进度的区别。一个发布可能有包含多个迭代，燃起图可以帮助项目人员时刻关注项目的总体进展，而不至于陷入迭代的细节中。
燃起图每天都自动更新，反应了每天进度的变化。当实际完成的进度与计划的进度出现偏差的时候，在迭代回顾会议上，要分析原因，着手解决，保证最后能够按照计划发布。
跟燃尽图相比，燃起图有一个优点就是能够形象的表示项目进行过程中的需求改变(Scope Creep)。需求改变往往是不可避免的，所以需要很好的跟踪，以便能够及时调整项目发布的时间安排。不能够跟踪需求的改变，或者不及时调整时间预期，以适应需求的变化，会给项目的开发带来很大的风险。 燃尽图
工作流效率（Flow Efficiency）
对于一个工作流来说，效率这个指标是至关重要的，它反映了一个任务从开始到结束，有效的工作时间占总的时间的百分比。效率越高，说明团队在推动任务从一个状态到下一个状态的时候，遇到的阻碍很少，团队的主要工作都放在了价值产生上，而不是无谓的等待和浪费。
工作流效率的计算方法为
对于一个用户故事来说，它表示了它在从开始到最终交付，团队投入的的时间占总时间长度的比例。100%表示该团队在整个过程中，一直在处理，没有任何的等待(浪费)。 工作流的效率要紧贴项目开发中的用户故事的状态。以我们的状态为例：
记入工作时间(Work Time)的状态为：
记入等待时间(wait time)的状态为：
阻塞 (stuck)可以评审(ready for review)可以合并代码(ready to merge)可以测试(ready for testing)准备发布(launchpad)
要提高工作流效率，每个团队成员必须注意尽量减少等待时间，比如在同事的代码等待评审的时候，尽快安排时间审阅；在同事代码等待测试的时候，尽快安排测试。同事之间要互动起来，加强协作，减少因为不清楚，没看见造成的无谓的等待。另外，在发现一个任务处于等待时间太久的时候，要沈阳SEO采取措施往下推动。
工作流效率是一个非常敏感的指标，团队中遇到的任何阻碍，不管是显示的还是隐式的，都有可能非常显示的影响。比如，一个开发量不大，只有一两个小时的任务，如果协作不够有效，在等待评审，等待测试的状态时间超过总的开发时间，其效率就非常低。所以说，这个指标衡量了整个团队协作的效率。
质量评分(Quality Score)
这里的质量评分，衡量了在工作流过程中，用户故事的质量情况。软件的质量，一般用缺陷(bug)的数量来衡量。但是，在工作流中，每个用户故事的规模可能不一样，难易程度也不一样，很难用一个统一的指标衡量质量。
但是，无论是什么类型的用户故事，开发的时候，需要时间，出现了问题之后，也都需要花费时间来修复，所以，时间是天然的统一的衡量参数。我们采用了工作时间与总的开发时间（开发时间加修复时间）比值来作为衡量质量的标准。
质量评分的计算公式为：
对每一个开发任务，都有一个质量评分，日常工作中，要仔细理解需求，及时与产品经理沟通，并做适当的测试，减少bug的数目，是有效提高质量分数的方法。
生产周期 （ Cycle Time）
一个团队，如果效率很高，开发任务完成的质量也不错，是不是就一定能够满足业务的要求呢？不一定。从外界来看，一个团队能否快速交付开发任务，也是非常关键的。生产周期反应了一个开发任务从进入开发状态，到最后交付，整个过程的总的时间。一个团队的平均交付周期小，意味着能更快的响应外部需求的变化，从而更能够满足业务的需求。 所以，从理论上讲，生产周期越小越好。
对不同复杂度的开发任务，衡量生产周期的标准是不一样的。另外，一个团队百度排名从长期来看，对不同大小的开发任务，其生产周期往往是相对固定的。当一个比较小的开发任务，出现了比较长的生产周期，意味着在开发过程中，有些地方需要回顾，找原因。技术人员的技能水平和对业务的熟练程度对生产周期起着重要的作用。在实际生产中，如果一个开发任务效率比较低，常常伴随着比较长的生产周期。
速度（Velocity）
速度衡量了一个迭代的产出率，即一个迭代到底完成了多少工作任务，一般用总的开发任务的点数来表示（有时也计算了修复的缺陷的点数）。对于一个稳定的开发团队，其速度是相对稳定的。当出现速度发生比较大的波动的时候，需要在回顾会议中讨论分析一下原因。使用速度这一指标，要注意排除外界因素的影响，比如，迭代时间长短的变化（公共假期），人员的变动（个别开发人员请假）。当外部没有明显的影响因素，而速度发生波动的时候，很可能是团队内部的原因，比如，开发任务划分粒度不够小，导致一个迭代无法完成；开发人员试验了新的工程实践，比如让前端开发人员和后端开发人员结对编程 （这样的做法，从长远来看，是有益的，然而，从短期来看，肯定是要损耗速度的，管理人员要注意速度这一指标，平衡不同的工程实践，一方面保证项目的按时交付，降低风险，另一方面要安排时间，从深度和广度两方面来提高技术人员的技术水平）
总结
一个开发团队要关注的指标，跟团队，跟公司所处的发展阶段也是息息相关的。上面介绍的这些指标，是我们作为一个创业团队所选定的。当然，在选定的这些指标中，缺少了累积流图 (Cumulative Flow Diagram）造成的结果是，只有事情发生了，迭代要结束了，才能明确的知道有些地方出问题了。而累计流图可以在事前给出报警信息。好在我们的迭代只有一个周，所以没有累积流图，对我们的影响不是很大。
另外，要很好的利用这些指标，团队成员必须形成工作协议，及时的更新开发任务的状态，很好的协作。还有，一个比较好的敏捷项目管理软件也是非常必要的。常用的有JIRA，Target Process.
