敏捷与功能规模——整合项目与产品

　　在这个行业里混迹了很多年，最近这几年我一直在想个问题：软件到底是什么？应该归类为——科学？工程？还是艺术？
　　最近看了西班牙软件专家Albero先生在MetricView杂志上的一篇文章——《敏捷与功能规模》，开篇就说道：尽管软件行业总是能够发明和创造一些新的技术，但是归根结底可以将其归属为艺术。比尔盖茨也曾经说过：软件是艺术与工程的伟大结合。
　　这篇文章给了我很多启示，我大致地给国内的朋友们介绍一下，并不会完全依赖于原文，同时也会夹杂一些我的感想。                                                                                   
　　怎么体现软件的艺术性呢？假设，有两个软件产品拥有相同的功能，表面上看来没有差别，但是内涵却截然不同，肯定其中有一个的性能更好；维护费用更低；用了更少的代码行；有更少的缺陷和风险。总之，有一个软件相比较会做得更加“艺术”。
　　软件是否艺术，取决于以下几个因素：
　　开发团队的技术知识；需求的质量；开发团队和管理团队的“常识（common sense）”。
　　在英文世界里，common sense，是个魔力词组。从公元前300多年，亚里士多德就开始思考，直到2000多年后的今天，很多人还是不能够理解其哲学思辨。

　　这几项要求有时候很简单，有时候也很难实现。
　　如果在开发的过程中，团队从技术视角来做决策和行动、存在狭隘的利益冲突、缺乏知识、存在大量的灰色概念。软件产品很有可能就沦落“平庸”。
　　这一点，其实国外的专家讲得还比较“乐观”，在国内，我们经常可以看到“这根本不是我想要的”场景。尽管这些软件已经“发版、上市、交付、验收”了，但是从某种意义上来讲，它们甚至都不能被称之为产品。
　　很有挑战性，也很有必要，我们要升级自己的观念，那就是要给“常识”增加一个定语——“卓越的常识（common sense excellence）”。
　　其中一个卓越的常识，其实在国内也不陌生，那就是要将目标SMART化。
　　软件开发和管理团队的目标——给用户、客户提供质量最好的产品；客户（外部客户，或者是内部客户）的目标——以最好的价格收获最大的价值。
　　这些目标就需要SMART(Specific明确，Measurable可度量，Achievable可实现，Relevant相关性，Time bound时限性)。
　　其中的这个M，就是度量，是一切科学管理的基础。这也是本文所要讲述的重点。
　　那么我们应该度量什么呢？
　　 IT项目只是个“一次性”的过程——我国有很多的PMP，对这个常识应该是不陌生。而IT的产品才能够给客户提供战略价值，或改善流程（更快、更便宜）。
　　所以，我们应该度量、监控的目标应该是产品，而不是项目。这个常识，国内了解的可能还不多。

敏捷——项目管理领域里春天的故事

　　2001年的2月中旬，在美国犹他州的“雪鸟”滑雪场，17位软件开发的思想者（thinkers）发表了著名的《敏捷宣言》。其全称应该是“敏捷软件开发的宣言”。
　　这个敏捷宣言，也是一个“卓越共识”。总所周知，宣言里包括了十二条“原则”。
　　仔细分析这些原则，其本质也是要强调：给客户提供价值。（我们的最高优先级就是确保客户满意——通过尽早并持续地交付有价值的软件）产品一定要满足用户真实的需要（needs），要做正确的事情，同时也要正确地做事，在所有的层面都要步调一致……
　　从“卓越共识”的角度来看，这个宣言其实并没有什么新意。但是有时候，尤其是我们困惑于的项目具体问题中，这些语句还是能够给我们指南的。
　　无疑这些年来，敏捷给项目管理领域带来春天。国内也是有越来越多的企业在尝试。但是其给我们带来的价值，很少有组织能够度量、统计。
　　这里还是要插一句，我以前看到的一个数据是：美国著名的IT咨询公司——Standish，从1996年开始，在每年的报告中都发布关于项目成功率的统计信息，在随后持续超过20年的时间内，虽然IT技术以及软件工程方法日新月异，但IT项目的成功率一直徘徊在40%左右。也就是说，敏捷并没很好地拯救IT项目管理领域。

要清楚4个概念

　　我们一定要清楚地分清两个概念：项目、产品，并且分别对其进行正确的管理和度量。尽管这个管理思想本身很简单，但是无论是大公司还是小公司，也无论中外，在实践中做得都不是很好。几乎所有的度量工作都集中于项目，甚至是合同。
　　客户要实现一个IT解决方案、产品、或者是增强包，可以与开发团队签署不同类型的合同（固定总价，单价，成本加成）。而开发团队既可以选择瀑布模式，也可以进行敏捷。所有这些工作都不会影响到最终产出物——产品。
　　只有IT产品，才能过为客户提供价值，并且核算最终的“有形成本”（可能包括了多个项目、多个合同、多个供应商、多个开发团队的费用）。
    另外两个重要的概念就是：工作量与规模了，对于这两个概念就很少有人混淆了。也许是因为两者之间的相似性很小，当然了，很多人都会有个误区——认为规模越大工作量越大，反之亦然。
　　无论是国外，还是国内，几乎所有的项目都会管理工作量，但是很多项目都不会去管理、度量规模。

　　在敏捷中，经常使用“故事点”来度量规模，并计算软件开发的工作量。故事点方法最大的问题就是太“随心所欲”（arbitrary）——从某种意义上来讲，这也是此方法的优点，相比较于“功能点”方法，学习成本、制度的管理成本要低很多。
　　但是，也正是由于这个特点，同一个公司的两个不同团队，对于同一个故事，会估算出不同的故事点数量。尽管如此，这种方法对于独立的故事而言，还是能够起到估算、计划、跟踪的作用。
　　国际著名的软件工程专家Caper Jones曾经总结出“软件度量的十三条准则”，故事点方法最多只能满足其中的四条。这个方法不能标准化，非常含糊其辞（容易引发歧义），不足以发布组织级的数据（例如：生产率），不适用于其他的新项目或历史项目，不能转换为其他相关的度量数据，不能适用所有的产出物，不能够支撑所有类型的软件，也不支持重复使用。
　　无论是敏捷的度量，还是传统的度量，都可以为我们打开“产品度量”的大门。如此度量得出的数据，可以作为其他战略性度量的基础。
　　相同的IT产品其“规模”肯定也是相同的，而不管是其创造的过程是敏捷，还是瀑布。也不管是用什么的合同类型。如果有可能，我们倒是可以做个对照试验，用不同的项目管理方式打造相同的IT产品，比较不同项目的进度、成本、质量等特性指标。