整体协同应用开发

这篇文章源于在https://codeproject.org.cn/Insider.aspx?msg=5279002#xx5279002xx中的一次对话，我建议我们应该提出一种新的、由开发者主导的方法来构建IT项目。当然，我的话有点开玩笑，但它们让我开始思考…

我在IT行业工作了超过25年，担任过从开发人员到管理大型团队的各个级别，包括在国内和国外的大型和小型组织，并且使用过我所能使用的大多数开发方法，例如ESD、RAD、Extreme、瀑布、敏捷等等。

感觉我们一直在努力寻找，但尚未完全实现一个完美的系统，该系统既能描述、记录又能指导开发过程。

问题在于，如果不盲目地坚持所选方法的原则，它们都无法真正发挥作用，即使坚持了，我也看到项目在为使其保持正轨而必须创建的官僚机构的重压下崩溃。整个行业都建立起来，以支持我们用来约束工作的烟雾和镜子。

我应该指出的是，我在这里没有任何特别的私心；我只是在阐述我的经验，并希望引导我们走向一种未来的方法，该方法将为我们提供一个可行的软件开发框架。

这引出了我为什么要现在写这篇文章：很简单，我是Code Project的长期常客，敏捷这个话题经常被提起，并且总是得出不可避免的结论，即 a) 它似乎不起作用，并且 b) 为已经负担过重的行业引入了另一层管理/技术术语。

对我来说，每种方法都有一些部分在某些时候起作用，而另一些部分根本不起作用。我这里的重点不是说我们应该采纳所有好的部分，因为我们最终只会得到一个由每种其他方法拼凑起来的拙劣方法。

相反，我认为现在是让那些在软件开发前沿工作的人们为我们的行业设计一个框架的时候了，该框架既要足够灵活以容纳任何规模的系统和任何持续时间的项目，但也不要依赖幼稚的术语来使我们能够讨论描述和记录过程的组成部分。

几个月前，一家大型金融机构向我提供了一个“Scrum Master”的职位（与我去面试的角色不太一样——想想看）。显然，我的职责是宣传该流程并在所有会接受它的部门中引入它。我确实考虑过，但意识到我根本不相信这个流程100%，因此无法充满热情地投入这项工作。

从那时起，我一直在思考敏捷。我现在所在的组织使用敏捷，并采用每日站会、故事、史诗、foo、bar、毛茸茸的小猫等等。

这是一种轻率的胡说八道，无助于流程的推进；相反，它引入了阻碍流程和道路障碍。是的，当然有一些项目和修复可以整齐地放入为期 2 周的冲刺或您选择的任何持续时间，但也有很多项目由于各种原因无法做到。那么，我们为什么要尝试将它们塞进一个强制执行根本没有帮助的纪律的流程中呢？

我们需要一个系统，该系统既要考虑到我们所做工作的复杂性，又要允许我们的上级能够进行计划和预算。但必须是开发才是最重要的，而不是流程本身。

那么，这个过程应该是什么？这是本文的目的；旨在引发和鼓励我们之间的讨论。我期待火焰，我邀请它们——它们将带来比现在拖累我们的更好的解决方案。

我想用最后一点想法来结束：我还没有遇到过一位显然乐于陷入敏捷泥潭的开发人员；相反，我们似乎都只是接受它，好像没有其他选择一样。过去，我每天醒来都充满活力，准备好享受又一天的编码。现在我必须考虑站会、故事、制品和史诗等等。

真是吸走了开发的灵魂。