Granville Miller 暂时放弃需求收集主题，着手讨论另一个引人入胜的主题：子整体软件编程。让我们找找这个方法如何补充和扩展灵活开发运动原则，以及它在主流开发界中的出现如何可能改变软件开发者的教育和软件开发实践。请在讨论论坛与作者和其他读者分享您关于本文的想法。
在我早期专栏的结论中（请参阅参考资料），我曾许诺此专栏将会专门讨论灵活开发过程中需求收集的各种方法。然而，当我开始着手那个专栏时，我意识到可能值得从灵活软件开发这个较大的讨论开始。但当我开始着手那个主题时，我发现自己渴望去讨论子整体软件开发这个相关主题。
这并不奇怪，因为我相信子整体软件开发是灵活软件开发的下一步。我对此十分雀跃，我选择改变我的路线，并且引入我非常独特的子整体软件开发宣言。我们将在下一次返回需求收集这个主题。
灵活软件开发
灵活软件开发运动对软件工程的理论和实践造成了巨大的冲击。它的拥护者成功的挑战和驳斥了实践证明的优秀的系统开发准则，并用自己的来代替它们。运动的基础在于四个核心价值，在灵活软件开发宣言中第一次对它们进行了概述（请参阅参考资料）：
个人和交互优于过程和工具
有用的软件优于综合的文档
客户合作优于合同协商
对更改作出反应优于遵循计划
实际上，这些价值标志着对那些受传统软件开发方法支持东西的背离。最高目的在于创建一个更有益于成功的软件开发环境。的确，灵活运动在软件开发的历史上留下了自己的印记。然而，虽然灵活运动具有革命性，但它毕竟只是更复杂更有益的开发实践的第一步。子整体软件开发才是下一步。
过程是第一位吗？
在工业革命时期，Frederick Winslow Taylor 先生对人的工作方式进行了研究。他进行了时间和动作的研究，目的在于优化身体技能的使用，有效的创造产品。Taylor 的出名在于他对效率原则的执著。他著名的引述概括了他对工业时代工人的心情：“过去，人是第一要素，而将来，系统很可能会成为第一要素。”
效率的追随和系统第一或者说过程第一原则是现在我们称为质量管理的两个基本组成部分。质量管理就是研究和实现那些正确的实现就会提高质量的活动。关键词是正确的实现。这些词组成了质量管理的安全港湾式表述。可以肯定的说如果您的业务、制造或工程实践不能提高质量，您就没有正确的实现它们。
虽然我不相信软件开发中存在质量管理危机，但我的确看到了失败正在我们的行业中产生。这些失败往往是过程和技术造成的，理由在于过程没有被正确实现或技术不成熟。不过我觉得把失败归咎于过程和技术常常是一种逃避。尤其当您考虑 Alistair Cockburn 的断言 ― 在成功的软件开发中过程和技术是第二位要素（请参阅参考资料）的时候。
人是任何软件开发项目的第一位要素。任何好的第一线管理员知道他或她的小组成员是项目首要和最有用的资产。一个永远不会被取代的软件开发准则是优秀的人编制优秀的软件。不过，如果这样的话，开发项目失败时，我们该归咎于人吗？答案是否定的！
子整体（holon）
我相信，寻找能反映优秀的软件开发技巧的行为的最佳地方是不太可能的。只有战场。对于导致单个士兵取得巨大成功最有用的两个准则是训练和主动性。最棒的军队允许单个士兵在战斗期间对于如何达到他们的目标作出决定。许多战斗胜利是通过许多士兵作为个体思考和行动、同时又作为团队一起战斗而取得。
一个维持自身独立性、同时又作为整体的部分发挥作用的实体称为子整体（holon）。这个术语是 Arthur Koestler 通过把词整体（holos 或者说“the whole”）和部分（on 或者说“the part”）相结合而发明。子整体曾用于描述社会、细胞和组织的行为，还有最近的制造行为。我相信子整体的（holonic）行为是软件开发者实际的并且很可能是理想的工作方式。
事实是，在开发软件时，我们继续遵循了 Frederick Winslow Taylor 的思想。时间和动作的研究提出了学术上软件工程周期的令人惊异的规律。然而，软件开发，就像信息时代许多其它要素一样，已经和时间和动作无关了。与之相关的是创造、革新和人。
对于软件开发，我们继承了工业时代诞生的思想 ― 死守着基于制造业的装配线生产的思路和环境。在这个环境中，个人是成不了气候的。他没有授权制造变革，也因此在要求变革的生命周期（软件开发周期）失败时，不该归咎于他。或许，是时候停止把过程和技术作为第一位要素了，让真正的第一位要素 ― 人 ― 作为中心。
子整体软件开发
软件工程是一种手艺。它需要运用智慧。它的准则很复杂且需要知识。最好的准则仍处于开发状态。因为软件工程领域如此广博，没有哪个人可以完全“掌握”它。还因为这一领域在不断发展，知识的保持需要不断努力和学习。
如果您是个优秀的开发者、建模者或管理员，您该知道我的意思。您曾面对多种技巧，然后例行公事的选出一种用于工作的最好的技巧。您在危机中调整并设法找出一种解决方案。您使子整体具体化。您需要一个在任何给定时刻指定您接着该做什么的软件开发过程吗？根本不需要。
真正的子整体软件开发组织承认不同的人有不同的思维方式。有些人的思维方式是抽象的、其他人是具体的；有些人是战略上的计划者，其他人则以行动为取向。子整体组织使用的技术使人们在选择完最佳工作方法的同时共同工作。这些组织允许人们用他们发现的最佳方法工作。简言之，子整体软件开发要求不断的学习和个体适应。它鼓励差异。
培训模型
我作出这些警告的断言 ― 我们的培训没有像它应该的那样成熟。与之相比，士兵的训练可以回溯到几千年前（最保守估计）。它已经发展成熟了许多个世纪。新的技术改变了我们作战的一些方法。但战争的很多基本模式没有因技术的改变而改变，士兵的训练也是如此。在我们接纳技术上的改变时，还要适应这些永恒的教训。
有效战斗训练的一半是提供士兵一个可供选择的战役战术库。另一半涉及到教它们随着训练创造出自己的战术。同样，我要郑重宣布软件开发者有效教育的一半在于知识和技能的获得。另一半在于学习对变化进行处理、在不断变化的领域中快速前进。简言之，去革新。
没有安全网的软件开发
许多软件开发过程几乎不提供安全网。有些人提议重复过程自身，就好像不断重复查看同一个状态图最终就会得到更多信息一样。重复我们的助诊文件可以改善它们，但只有引入反馈方法后才生效。当有必要知道我们在何处有可能误入歧途时，简单的重复是不够的。
补充活动
一种可以结合进来以纠正预期错误的活动正成为一种成长趋势。这种活动称为补充。例如，我们用域分析权衡用例建模以确保随后的对象模型不起作用。这些补充性的活动可以让我们不犯常见错误。
没有了补充活动，第二位要素如过程和技术成为我们唯一的安全网；如果我们陷入困境，我们可以归咎于它们。因为大多数软件开发过程最多只有两维，或许这种归咎是它们应得的。的确，除了给我们控制的感觉，过程再无其它用途，它是一张虚假的安全网。
过程？什么过程？
这是不是意味着您可以抛掉软件开发过程并真的在没有安全网的支持下开发呢？除非您有准备接受项目失败的责任。
在另一方面，如果您没有在适应，您就不会尝试做事情的新方法。如果您不尝试新的东西，您就不会学习、发展并成为最优秀的。这是个不断探索的过程，我们中没有哪一个人有可能在任何时候立刻完成。
即使您选择了已建立过程的安全网，您也不一定在完全的遵循它。除非小组的每个人的想法相同才不会这样。如果您的确找到了小组中每个人都觉得最佳并适用于您所从事的所有项目的终极过程，请发送给我。然而，我并不期待收到许多满足上述条件的过程，因为 Jacobson 定律表明这种过程不存在。我相信即使在高度团结的小组中，也没有哪个过程会适合每个人的思考方式。我们之间存在着太多的差异。
结论
子整体软件开发是灵活运动的逻辑扩展。它需要高度理解用于编制软件的技术，还需要开发者对交付使用系统负责。子整体软件开发小组把过程用作指南，而不是支柱。该小组并不墨守成规，或者说当常识起支配作用时忽略过程。
本文不是一篇定义，而是宣言。其中提出了一种较好的交付使用软件系统方法的见解，此方法利用许多灵活过程中定义的活动。同样，我考虑了软件开发的最佳准则和作为开发期间纠正错误方法的紧迫的补充活动。
我们将在下一专栏继续讨论这个主题，其中我们会返回已许诺的关于用例、功能和用户情景的讨论。我将向您展示如何让这些元素成为您子整体软件开发工具箱的一部分，并且还将描述这些元素如何支持一种前载的、平衡的或后载的编制软件方法。请别离开。
参考资料
请参与有关本文的讨论论坛。
有关前载与后载软件开发过程对比的讨论，请参阅 Granville Miller 的文章 “
