“过程债务”是人们使用的术语吗？
作为回顾的结果，我们发现了更糟糕的软件开发方法。我们有一个想法，我们认为我们是伟大的，并尝试了它。我们在开发一个主要的更新过程中，花了3个月的时间与它一起工作。在与维修工程师进行了回顾之后，我们的想法对他们并不适用(在我们尝试这个想法之前，我们与他们进行了讨论，而且他们也认为这是一个好主意)。我们达成协议了，最好回到原来的情况。更新的团队已经解散，维护工程师没有时间这样做(尽管他们的项目经理已经同意投入时间)。
我们现在的情况是，维护工程师支付利息，每次一个小版本必须作出。这与技术债务非常相似，但与产品本身无关。这是所谓的过程债务，还是将其置于技术债务一词之下？什么是处理这一问题的好方法？(有其他或具体的想法让产品经理看到吗？)
PS的想法是将一个4产品的VSS数据库迁移到SVN。数据库很大程度上依赖于共享文件，需要清理和注入可用的SVN结构。这是非常违反直觉，但似乎有些东西更好地保存在VSS中。
回答 5
Software Engineering用户
发布于 2012-01-18 07:52:27
我希望我对这件事的理解是正确的，我称之为技术债。软件不仅仅由源代码组成。源可能不到SDLC的10%，也不超过SDLC的20% (至少在商业层面)。如果您不能可靠和轻松地构建和部署您的源代码，从而导致问题和成本下降，那么它与难以维护、错误和缓慢的源代码没有什么不同。
事实是，你尝试了一些不同的东西，但它不如你留下的东西那么好，也改变不了任何事情。由于所选择的技术(VSS与SVN) --技术债务，软件现在处于比以前更难维护的状态。
你所指的过程债务无疑是存在的，但这是因为这个过程让你去做不再需要的事情。例如，如果您有一个流程需要手动运行并在每个版本上标记打印的测试簿，但是您已经实现了自动化测试，这将是进程债务，因为由于工作方式的改变，它不再具有相关性。
Software Engineering用户
发布于 2012-01-18 10:58:24
过程中的“债务”不可能存在，当然也不会累积。
在你的过程中，你有一个“差距”，B组做“更多”的工作，因为A组做的工作“较少”。
这不算了。只是工作量的转移。
如果有什么事情发生了，那么一年后，B组就会有大量的事情要做。等。这是积压的技术工作。这就是技术债务。
“流程债务”将是必须执行的过程步骤的积压。结账-结账？电子邮件更新说有什么即将改变吗？那太傻了。也不太敏捷。
Software Engineering用户
发布于 2012-01-18 20:09:57
听起来你在描述穆达，来自精益软件工程的废物。显然，你想尽量减少浪费.
https://softwareengineering.stackexchange.com/questions/130656
复制相似问题
腾讯云开发者
