敏捷是什么？ 敏捷度量什么？为什么需要度量？
敏捷是敏捷宣言中的四句话, 还是Scrum, XP? 有人说敏捷是一种状态，也有人说敏捷是一种心态。
我认可的是敏捷除了有Scrum之类的框架，XP等这类的实践外，更是一种组织或团队的状态，也是一种做事的心态。
如果一种状态，那么会有哪些状态，能定义一个A、B、C之类的状态吗？ 组织或团队又如何从Ａ状态到Ｂ状态呢？ 难道不同状态之间一定有一个好坏之分，其实也未必。
那么，可能会面临一个问题，既然我们在做敏捷，在转型3-6个月后，我们得思考团队到底变化了什么？如果靠主观感受，业务/产品侧可能会说，质量感觉还是没提升，只是感觉UAT的时间提前了2天，团队似乎矛盾少了一点。那么，你能说得清楚这个迭代与上一个迭代哪个更不好吗？再和进入转型前，到底有啥区别？或许，作为敏捷顾问，你可以事后列出团队一系列的变化，那么，这个变化是大家观注的关键指标吗？说到此，度量似乎不可避免，需要度量的理由也存在千万种。特别地，当你作为外部咨询进入时，怎么可能会没有目标。
接下来，我们看看可以度量些什么。我们听的最多的可能是：产能不足，质量太差。 听上去这个很有道理，我们来改善产能，提高质量。 我们清楚，度量存在主观感受和客观数据。一方面，我们需要主观的感受，另一方面，我们也需要客观的数据度量。 针对产能、质量，这是客户的关键痛点，我们需要针对这两个指标归属到客观数据的度量。 而这两个指标更偏向于结果指标，我们同时需要加上一些过程性指标，可以是主观，也可以是客观。如：我们可以度量 纪律性，节奏，需求变更的数量等。这里不具体介绍，具体方法可以参与 吴博士的 研发组织该如何设计绩效体系？
我们可以简单说一下产能和质量问题的思路。针对产能，哪怕研发天天加班，产能还是不足，我们需要建立一个度量标准，ACT中定义了需求的沙子、板砖和钻石，我们可以从认识需求积压的定义开始，让业务产品与研发达成一致的认可，一般至少达到板砖状态我才认可你这个需求是个积压，不然业务产品会发明无数需求，你永远的都是产能不足。针对质量，我们统计系统测试，回归测试，UAT，生产缺陷的具体数据，观注整个过程的缺陷并分析原因。不用害怕收集数据的烦杂，特别是生产缺陷，我们会发现，客户反馈的很多问题，都是类似的问题，另外，这些问题还有大部分是使用上的问题。如果你不加以统计分析，给业务产品的感觉是很多人反馈问题，给研发人员的感觉是怎么这么多傻X的使用问题，最后就是业务产品与研发互相不满意，或者研发觉得自己做得很不错，是产品经理设计的产品不方便使用。如果你在运营微信群里，相信你会有这样的感觉。所以，停止抱怨，行动起来，把度量做好，管理好产品经理们的预期和为团队制定一个可达的目标。
网友评论