- 这个话题有 6 回覆, 5 声音, 最后更新 8 年份, 11 月 前 通过
.
-
帖子
-
软件生产力社区在衡量 IT 项目的生产力方面取得了长足的进步. 在 1980 年代初，衡量生产力的方法包括将程序长度除以所花费的精力. 在 1990 年代，工业界很清楚，通过计算程序长度来衡量生产率存在严重问题 (c.f. Edsger Dijkstra 关于计算代码行数的说明). 结果，替代的产出衡量标准变得流行, 其中功能点成为主导标准.
由于功能点计数的主导地位已经引入了许多增量改进: 更严格的计数规则编纂 (导致 IFPUG 和 Nesma 的计算实践手册), 功能点测量理论性质的改进和测量尺度的改进 (导致 UKSMA 的 Mk II 标准), 将功能点计数应用于早期项目阶段 (例如. NESMA 计数规则的快速计数规则), 采用嵌入式系统的计数规则 (COSMIC COSMIC 功能点标准) 以及功能点计数的部分自动化 (OMG 的自动化功能点标准).
然而，这些改进并没有解决我们衡量 IT 生产力而不是 IT 项目的业务生产力的基本问题.
IT 项目的业务生产力可以定义为 IT 项目对组织目标的贡献程度. IT 项目要么降低开展业务的成本 (即. 提高效率) 或增加组织产出的价值 (例如. 更好服务的更好产品). 在过去, 在尝试分析 IT 项目的输出时, 过分强调效率部分 (降低成本) 太少强调 IT 项目对组织服务或产品价值的影响.
我认为，缺乏对 IT 项目对组织输出的附加价值的重视可能与这样一个事实有关，即改进的产品或服务的价值只有在组织及其流程也发生变化时才能实现. 这使得将业务价值归因于 IT 项目总是有点难以捉摸.
尽管如此，当我们不衡量 IT 项目对企业的真正价值时，我们将永远无法确保我们的 IT 项目有效地为企业增加价值. 如果不更加关注业务的附加值，IT 对业务将无足轻重，业务将把它视为麻烦而不是资产.
我们如何衡量 IT 的业务生产力?非常感谢 Joost Schalken 和 Joost Koen 在他们的研讨会上提出这个主题 企业生产力 在 2014 IWSM Mensura会议在鹿特丹.
这个问题现在很热门, 特别是随着越来越多的组织正在对其开发方法进行现代化改造, 尤其是业务和 IT 之间的沟通. 敏捷和精益开发的共同点主要是改进 效力, 即. 发展 (只要) 需要什么 现在. 但随着, 说, 功能点和人时, 我们主要测量 效率. 为了显示: 一个项目开发 100 FP 其中只有 60% 交付时按原样使用. 另一个项目开发 100 其中的FP 90% 是有效的, 但需要 20% 更多时间这样做. 哪个是 “更好的”? 这个问题甚至还没有涉及到业务层面的有效性. 在一天结束时, 您需要评估您的业务案例.
我也在寻找一种测量方法 效力.
坦率, 你能分享一些研讨会的成果吗? 我会很感兴趣.
好点安德烈亚斯和我完全同意不同的重点领域 (效率/效力) 在这些现代方法中 . 但我确实认为，成本“即时有效”总是有一个临界点’ 从长远来看，这是不可持续的.
我同意测量程序或过程中思维方式的最大变化应该在业务有效性和目标领域，而不仅仅是在 IT 部分, 但我确实认为这不是问题 “或者”.. 但它的有效性 “和” 效率. IT 通常是业务的重要组成部分, 并且由于流程效率低下，业务价值和收益会降低! 低效的流程可能导致更长的交货时间, 低质量等. 也缩短了上市时间, 客户满意度等.也, 哪个敏捷团队自己决定组织可以更好地建立一个单独的团队来开发或实施另一个应用程序来替代他们自己正在开发的应用程序? 或者哪个敏捷团队可以客观地说他们的成本是另一个团队的 10 倍 (无论他们在目前的情况下有哪些有效的论据!) 而商业价值或客户满意度 (或组织最重视的其他业务度量) 其他团队可能只低 1.5 倍?
我的观点是，团队可以“学习”’ 一种 “业务和端到端/客户对客户的心态” 跨越多个 IT 应用程序和业务流程, 但总会有更多抽象的“层次”’ 或‘意见’ 在需要其他类型的决策时需要. 在这些情况下，我真诚地认为客观的效率措施与有效性措施一样重要.那说, 我认为企业生产力的衡量标准更具动态性，因为它们可以根据时间点的目标而变化. IT的业务价值/目标/生产力之间也可能存在差异, 以及组织的真正业务目标/价值观. 该 “IT的业务生产力” 在这个时间点可能非常好，因为应用程序非常灵活并且非常好地支持业务流程以及非常高的客户满意度, 但是如果软件平台需要退役，因为 IT 环境需要更加标准化，因为组织收购, 在不考虑当时的实际业务目标的情况下，IT 业务生产力的意义何在？?
另一个例子, 对于组织目前拥有的有限客户群，什么是良好的客户满意度, 当战略业务目标是获得更大的客户数据库时 (扩大市场份额, 引入新市场, 产品多样化) 然后在 2 几年也许会再次提高质量.最后，我认为没有一种非常标准化的方法来衡量诸如生产力/目标之类的业务 它的. 也许不应该有? 因为要有效，措施需要根据当前的业务战略和目标进行调整, 考虑到复杂多变的环境.
您可能是对的，标准化业务生产力的衡量标准非常困难. 但是，如果具有业务视角的人使用软件指标来比较他们对业务价值的看法与软件的价值，这可能会非常有用. 我刚刚发布了一个单独的主题，说明为什么业务方面的人不这样做 “买” 功能点, 叫 “开发人员不需要功能点“.
这个话题与我最近几次问自己的问题有关: 如何衡量商业价值. 现代软件开发方法论, 像 DevOps, 专注于提供商业价值. 但那是什么… 商业价值? 我以前以为是功能… 如果软件团队提供更多功能, 这应该会带来更多的商业价值, 对? 但也许它更复杂, 因为某些功能可能真的会有所作为 (例如. 能够在您的应用中实际购买东西) 而其他功能很不错, 但不一定会导致销售 (例如. 您可以在应用程序中查看产品, 但仍需要通过电话拨打您的订单). 也, 将修复缺陷算作创造商业价值? 也许是一种没有人遇到过的化妆品, 但是阻塞缺陷呢? 或者我们是否应该将解决缺陷视为创造商业价值？, 而是为了防止业务损失. 我认为这是一个非常有趣的讨论，我希望在这个话题中看到更多的想法!
- 您必须登录才能回复此主题.