软件工程 |识别软件开发指标

它可能还不是机器人和飞行汽车的设想未来时代，但人们无法反驳这样一个事实，即技术确实为自己创造了一个不容忽视的整洁空间。软件已经吞噬了每一个工业空间，以至于今天的软件和业务齐头并进。这种大小组织的骨干都是通过严谨、勤奋和创造性的发展创造出来的。公司将相当一部分资源投入到推动组织运行的技术发展的昂贵员工身上。因此，必须通过赋予团队跟踪效率的能力来探索和量化衡量此类投资的绩效。该任务被委派给指定的软件开发经理。

那么软件开发经理如何衡量他的团队的生产力呢？如果没有指标，经理应该如何衡量？
本文讨论了一些指标，并确定它们是否可以作为软件开发经理可以自信地就交付项目的最有效方式做出决策的手段。

计算代码行数：
我们可以将开发人员的质量与贡献的代码行数联系起来吗？虽然更大的贡献确实可以评估更多的工作，但它不一定归因于更好的工作质量。我们不能假设一个贡献了更多代码的开发人员正在有效地工作。
目标是用尽可能少的代码实现功能。因此，虽然代码行数表示一致性和工作进度，但它并不是评估生产力的有效指标。这将我们引向下一点，即功能是关键。
函数点：
功能似乎是编写代码的关键目的，函数点代表了实现所需功能的一步。我们可以监控开发人员开发和交付的用户功能以评估性能吗？还有一些任务跟踪工具，如广泛使用的 Bugzilla 和 JIRA，可以消除管理进度的手动工作。
那么我们可以不计算使用这些工具完成的函数点数量吗？好吧，这里的问题源于每个函数的动态特性。每个函数都不同。虽然有些可能非常简单，但有些则需要更多的努力和时间。虽然一种编程语言中的函数可能很容易实现，但对于另一种语言来说，它可能更具挑战性。因此，完成了更大函数点的开发人员不能在团队的其他成员之上进行权衡。此外，这样的指标会妨碍团队合作，因为开发人员可以轻松地挑选简单可实现的函数点。因此，这不能作为可靠的判断指标。
故事点：
与函数点类似，故事点也经常在软件开发阶段使用。在敏捷方法中经常采用，故事代表项目的业务需求。根据手头任务的工作量、复杂性、风险和不确定性，计算所需的工作量，并相应地为每个用户故事分配一个大小。这个大小代表故事点的数量。燃尽图通常用于估计故事点的进度。在这里，编码工作量的衡量标准是统一因素；再一次，该度量标准存在谬误，因为分配大小的初始估计由经理自行决定。
例如，一个应该为 2 的故事点可能被不准确地测量为 4，因此发展缓慢。那么开发人员是否可以因任务完成而获得更大的荣誉呢？该指标提供了一个合适的衡量标准来确定工作进度，而不是工作效率。衡量编码工作量似乎是获得可靠指标的正确途径，但手动估计故事点的大小会使该指标不可靠。
编码努力：
正如前一点所讨论的，衡量编码工作量似乎是评估工作进度而不是工作效率的方法，因为它经常被错误地估计，从而导致故事点的大小不准确。需要更好地估计所需的编码工作量，并且为此目的设计了 blue optima 等工具。该工具通过分析代码提交之间的编码工作量来衡量开发人员的速度。然后它给出了每单位时间成本的度量。每小时成本与每小时编码工作量的比率给出了每个编码工作量的成本比率，它提供了对团队效率的有价值的洞察力。
通过分析该指标，组织可以获得有关各种函数或故事点所需的实际编码工作的情报，这将使经理能够更好地估计故事点的大小并胜任地交付项目。

由于项目规模、依赖关系、风险和时间限制要求，软件项目交付在企业层面遇到了许多障碍和挑战。组织必须尽最大努力确保项目顺利交付，以最大限度地减少对业务的影响，软件开发经理有责任保护开发列车在其轨道上运行。通过确定合适的指标，可以实现具有成本效益和可靠交付的指南，