在软件工程程序中识别瓶颈的方法是什么？
我正在从事金融服务的软件开发程序--有100名开发人员，加上测试人员、BAs、PMs和其他支持人员。
我们已经阅读了实现精益软件开发和凤凰工程，它们都谈到了如何识别流程中的瓶颈，并对其进行优化。(与项目中的关键路径有些相似之处)。
直观地，我们可以将瓶颈识别为:测试环境的数量、回归测试所需的时间和精力、monolith的大小、开发人员的数量等等。我们要做的是把它归结为阻碍其他一切的瓶颈。(就像一个制造流程)。
应用精益软件开发()讨论了价值流分析--但还不足以确定对整个系统至关重要的一个阻止因素。
我的问题是:在软件工程程序中识别关键瓶颈的方法是什么？
编辑:其他假设：
- 在我的环境中--资金分配给将在特定日期交付的大量范围。本质上，质量、范围和时间都是预先锁定的。(如果绝对需要的话，范围和时间有一些差异)。
- 这意味着没有“小部件通过系统”的概念。只有有很多故事的大型项目(60+故事--每个项目都有10天的工作时间)。
- 这是一个类似瀑布的环境(正如Sarbanes所规定的那样)，它有一个单独的系统集成测试和用户验收测试阶段。
回答 2
Software Engineering用户
发布于 2016-11-26 10:09:01
确定最重要瓶颈的一种方法是使工作项经过哪些阶段成为可见的。
首先，尝试遵循几个工作项(新特性、bug、改进等)。整个周期从项目开始为团队所知，直到它成功地部署到生产中为止。写下需要采取哪些步骤来完成整个生产过程，以及在哪里可以将票放在一堆上，等待其他人继续工作，或者等待其他原因。
所有这些都可以通过使用kanban板来显示。以其最简单的形式，kanban板由若干列组成，代表开发过程中的工作阶段和等待状态，以及工作项的粘性注释。
根据开发过程中的位置或等待的内容，每个便笺都会被全员移动。
使用kanban板，您可以通过查看列中的票堆，或者看到票从列中提取的速度快于新入场券的速度来识别瓶颈。
- 如果等待列的填充速度比票被删除的速度快，则表示票证等待的资源超载。
- 如果“正在做的工作”列包含的票子比可以对其工作的团队成员多得多，这表明团队同时处理太多的事情(由于上下文切换导致效率低下)，或者错过了等待状态。
- 如果一个排队的队伍经常空空如也(票出得比他们进来的快)，那么这就意味着拉着这些票的队伍使用不足和/或人员过多。
关键的瓶颈是列，其中这些影响是最明显的。
Software Engineering用户
发布于 2016-11-27 13:03:45
我认为Bart van Ingen Schenau的回答很好。它本质上是一个实时的价值流图。然而，我确实有一些其他的建议，可以帮助你在这个答案之上。
首先，考虑跟踪任务在每个状态下的时间。工具应该能够提供这一点。如果您的工具没有，或者您正在使用物理板，您可以写过渡日期的每一张卡。这将允许您获得平均时间，并确定需要很长时间的阶段。但是，您需要捕获的其他东西是等待时间和时间活动时间。再一次，在卡片上做笔记可以帮助你做到这一点，在循环结束时，你可以把卡片上的时间放到一些需要分析的东西上。
第二，考虑活动的规模。如果像Bart所建议的那样使用看板，您可能需要考虑使用更小粒度的列，或者为列内发生的事情创建值流映射。
一旦你知道了你的时间，首先优化最长的时间。首先，尽量减少“浪费”时间，或者是那些没有活动状态的时间。第二，试着减少过程中的时间。
https://softwareengineering.stackexchange.com/questions/336896
复制相似问题
腾讯云开发者
