ACM通信
软件业务
在区域:需要灵活的角色
区域防守:防守一个区域，忽视假动作，观察四分卫，去球的方向，不断后退，保持在球和球门线之间．1
人们试图使软件开发更有效的方法之一是定义角色:如果我们能把正确的人放在适当的位置上，有充分理解的职责和明确定义的接口，通过传递清晰的信息来做出有效的决策，那么我们的项目就会成功。当然，如果我们能做到那就太好了。但是，如果精确的角色定义如此有用，为什么它没有更频繁地出现呢?即使我们可以预先定义人们应该做什么，这有那么大的帮助吗?也许不是。
通过这个专栏，我一直在探索软件作为知识媒介和软件开发作为知识获取过程的概念。我们可以把软件开发活动看作是使已知的和未知的东西都可执行。这些已知和未知分为四类:
先前已知知识的转移和实现这可能是编程语言原语、库函数、预定义对象、重用软件和任何类型的重用可执行工作产品的可执行软件知识形式。或者它可能以书籍的形式出现，如系统文档、系统模型、过程模型、模板、项目计划，甚至教科书和方法。它也可能以经验丰富的开发人员从以前的项目中继承知识的形式驻留在大脑中。
特定未知量的定义当系统变量的存在和它们的范围已知，但它们的具体值不知道时，就会发生这种情况。通常这种知识获取与第一种类型或活动相关，为了使用以前获得的知识，我们必须理解来自“标准”形式(如在功能重用中)或“经验丰富”形式(如在经验丰富的开发人员中)的差异。为了使这些知识可用，必须回答一些定义良好的问题。
未知量的发现这种情况经常发生，当我们试图“证明”上述知识类别时，我们发现了我们根本没想到会发现的东西。事实上，这就是我们测试系统的主要原因。
发现和证明以前未知的过程或方法这可能是前面类别的结果，也可能是项目事后分析和过程计划的结果。当我们探索为什么我们之前的知识并不适用于我们认为适用的时候，或者什么样的过程可能在未来更好地揭示类似系统的未知方面时，我们就会发现这一点。
角色分配的问题是，它们可能成为灵活性的障碍。个人、团体甚至组织都可以躲在他们的工作描述后面玩“不是我的工作”的游戏。
读过以前专栏文章的读者会意识到这是解决了五阶无知中的前四阶。
当我们看明确和严格的角色定义时，很明显，它的有效性是可变性的逆函数，如表格在这里。严格定义的流程及其相关角色只能在前两种情况下真正有效。在发现的情况下，它们几乎肯定是不那么有效的，并且在过程发现的情况下是非常不相干的，因为角色的定义是主要的输出的活动。角色定义的有效性是定义角色时存在的未知数的数量和类型的函数。在前两种情况下，内在的可变性很低。这意味着几乎没有什么未知的东西，实现由战术活动组成，要么应用我们已经知道的东西，要么为我们已经知道的特定问题获得特定的答案。当我们不知道我们将会找到什么，或者我们不知道找到它的方法时，任何预定义角色的有效性都必须受到怀疑。
我们可以将项目描述为映射到开发组织中的通用域。举个例子，在图1，有两个相交的轴。首先，“需求连续体”表示知识保理活动的范围，从客户需求的最高级别向下到需求满足的详细证明(通常在后期的系统测试中)。水平轴，“组织连续体”，表示分配给服务客户需求或维持开发组织的组织资源结构的范围。它包括为服务特定客户需求而分配的专门资源，以及跨组织运行并由所有客户群体共享的通用技术支持功能。这个例子不是一个组织域的决定性的，但是它确实有助于解释区域防御的概念。中给出了这个连续体上预定义组织组的典型映射图2一个．
人盯人的防守
图2一个被描述为人对人防御，即建立特定的组，具有特定的职责、报告渠道和与其他组的接口。当变数或未知因素很少时，这种方法很有效。当我们发现活动不完全适合预定义的角色时，就会出现问题。这通常发生在我们发现意料之外的知识时。没有一个小组被指派负责处理这些项目，因为它们是没有预料到的。那么是谁做的呢?除非一个团体选择修改其预定义的角色并接管这些职责，否则它们不会得到解决。如果两个组接任务，就会有一些重复的努力，组之间可能会有一些竞争。当团队调整以适应不断变化的责任时，他们也改变了任务的动态。但是在作业不断变化的情况下会发生什么? What is the value of highly detailed role assignments at the start, when we know they will change to invalidate the assignment?
角色分配的问题是，它们可能成为灵活性的障碍。个人、团体甚至组织都可以躲在他们的工作描述后面玩“不是我的工作”的游戏。
区域防守
借鉴足球游戏手册，我们可以将小组设置为区域联防。在图2 b，我们看到与中描述的相同组织结构的区域防御版本图2一个．与明确的角色和接口(无论如何都会改变)不同，这些组由具有适当技能、能力和态度的人组成。每个技能领域都倾向于一个规程，但实际的任务分配是松散定义的，并根据需要进行分配。这种有意设计的松散结构的一些特征包括:
- 指导方针的存在，而不是明确的角色和过程定义。
- 随需应变的任务优先级。
- 团队为责任的变化做好了准备，并且拥有思维模式和变化管理工具集来驾驭不断的变化。
- 愿意跨越名义上的团队界限支持人们。这意味着当变化的环境修改了(比如说)测试/验证组的任务，并且确定了一个更高优先级的活动时，另一个组可能会调整其优先级，以补充测试/验证组的一些原始职责。
- 更广泛的优先级映射跨较大的组，而不是严格地在较小的功能组。
- 对改变的期望。
- 积极合作与协作的氛围。
- 小组之间广泛而有效的网络。
- 仔细管理通信基础设施，既不过度通信，也不不足通信。
- 接受责任和责任，而不是赋值的责任。
在许多情况下，软件业务就像足球或篮球比赛一样流动。
最后一点似乎很关键。许多管理方法都倾向于对工作的仔细划分和对个人和团队责任的精确分配。如果可以定义这样的责任，这是很好的。在发现活动中，在某种程度上所有的软件开发都是这样，这通常不能达到必要的精确度。
责任的分配和责任的接受之间的区别是微妙的，但非常重要。如果分配给我一项任务，但我不能预测任务是什么，或者我必须依靠别人来完成任务，我可能会因为“没有错”而失败。当任务没有完成时，我可以指出失败的“罪魁祸首”是谁。相反，如果我和我周围的人，接受责任，我们不会让自己失败，如果我们，集体，有能力成功。这可能意味着我改变了我的优先级来完成一项不分配给我的任务，也许你改变了你的优先级来承担我的一项责任。经典的项目管理分配过程往往太慢，无法在合理的时间框架内完成。
蚁山项目
几年前，我教了一堂关于项目评估的实验课，课上使用了一些最流行的评估工具。参加课程的一个小组最近完成了一个电信项目。他们中的8人花了9个月的时间，交付的系统没有任何缺陷。我们将他们项目中的已知值插入到评估工具中，这些工具非常一致:使用任何现实的参数，他们都不能做他们刚刚做的事情。这项工作至少需要18个月的时间。即使有了这个时间表，工具预测他们应该交付大量的缺陷。但他们没有。显然，这些工具并没有按照这个团队能够达到的性能水平进行校准。但他们是怎么做到的呢?
他们的项目设置非常有趣，如图所示图3．从探险家刘易斯和克拉克那里得到了启发，队伍中出现了两个平等的队长。他们都是技术熟练、经验丰富的工程师，碰巧也是好朋友。团队的其他六名成员有不同程度的技能和经验。共同领导在系统架构方面提供了广泛的技术指导，但选择不关注或指导团队成员的任务。
对这些成员的授权很简单:做你认为需要做的事情。团队成员被赋予了几乎完全的自由，可以从事他们认为最关键的任务。如果通过完成这些任务，他们决定自己应该完成其他任务，那就这样做吧。如果团队成员需要指导，他们可以询问团队领导。如果他们觉得自己有能力决定自己应该做什么，他们就可以继续做下去。团队成员之间和团队领导之间应该讨论他们对任务的选择，但即使这样也不是必须的。此外，还安排了一项合同，对于关键的项目(由提问的人确定)，其中一个团队领导将在10分钟内提供答案。
该项目的设置非常像客户机/服务器应用程序。当来自“服务器”级别(团队领导)的知识被传递到团队“客户端”级别时，团队使用该通道的需求就减少了。几乎完全缺乏任务指导意味着，处于完全发现模式的团队可以立即对个人或团队变化的环境做出反应。然而，高度的技术指导意味着人们的设计更有可能相互吻合。这与传统的有时间限制的项目相反，在传统的项目中，任务管理是从上面定义的，控制到15分钟的间隔，但技术指导是由个人掌握的。这个项目更像是一个蚁丘，而不是一个结构化的系统，每个团队成员都以一个渐进的最优速度贡献、学习和发现。他们的结果不言自明。
保护区域
除了区域联防，还有区域联防。在描述特克斯·温特斯的“三角进攻”时，篮球教练菲尔·杰克逊说:“为了让这个战术发挥作用，所有五名球员必须同步移动，这样当防守过度延伸时，他们就可以利用空位。”2
在许多情况下，软件业务就像足球或篮球比赛一样流动。我们需要一个全面的计划，我们需要知道实现这个计划我们的角色是什么，但我们也需要学会灵活地适应不断和越来越快速变化的环境。当我们明白我们所做的大部分都是发现活动时，我们就会发现严格的角色和规则可能不起作用。当我们能够例行公事地设计项目和组织结构，它们具有内在的弹性，能够灵活地满足我们不断变化的情况的需要时，我们就会进入状态。
图2。(一)人盯人的防守。(b)区域防守。
©2003 acm 0002-0782/03/0500 $5.00
允许为个人或课堂使用本作品的全部或部分制作数字或硬拷贝，但不得为盈利或商业利益而复制或分发，且副本在首页上附有本通知和完整的引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2003 ACM, Inc.
没有发现记录