软件协同设计-团队建设.doc

第三章 软件协同中的角色与目标 3.1为什么团队中需要区分角色? 国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中间有一个技术“大拿”，剩下人辅助他，把这个产品的所有代码写完，则软件就算完成了。“大拿领衔制”脱不去小作坊的味道，虽然保证了“技术大拿”的创造性，却失去了软件研发过程应有的规范。 为什么在一个TSP开发团队中团队成员需要区分角色呢？角色提供了一套已定义和可接受的工作框架。有了角色，团队成员就能专注于特定的目标，把注意力放在工作的特定层面上；有了角色，每名成员都可以支配整项工作的特定子集，他人无需为此担心。当然，为了整体的高效，每名团队成员不仅要了解自己的角色，也要熟悉所有的其他角色。 不论是足球、篮球、棒球还是橄榄球，运动员在上场前总会被安排在特定的位置。与之相类似，在TSP进程的初始，团队成员被安排担任不同的标准角色，在所有成员之间将主要团队职责进行了划分。通过将占据每项关键领域的团队成员确定下来，确保了运营团队的过程中，一般问题能够迅速高效的解决。团队之中没有真正的“权利大小（谁管谁）”，只有成员紧密沟通。笼统地说，正如其他人类制度一样，分工自身也同时具有益处和代价。如果允许一个空泛的概括，分工的优点至少有：1）集中特定的知识、技能——想想自己左右手、左右脑的分工，我们也许就可以理解这对提高生产率的重要性；2）职责明确，不同职责的人为自己做出的决定负责；3）增进交流：各个角色之间为确保顺畅的协作，必须要求高质量的交流，这也就能使很多原本不言而喻的事情书面化、明晰化。但分工也有其自身的弊病。首先，不少人天性追求完满，要让他们接受分工，只完成整个工作的一个枝节部分，可能是非常痛苦的事。我记得自己刚刚参加工作后参与开发的一个系统，直到开发接近尾声，项目经理才在一次每周例会上说：“大家开发了这么久，对整个系统的用途可能还不很清楚，今天我们简单谈谈”——这时我才知道自己参与的是整个店铺系统的销售子系统的订货部分的一个底层数据模块。?另外，分工往往导致等级制度和不同角色间的疏离。既然分工的要义是把高要求的工作集中在少数人手中，在少数和大多数之间，不同的工种之间，必然会导致等级差异和隔阂。《人月神话》中也谈到，在区分了产品设计和技术实现之后，单纯的实现者会感到仅仅听命于人，常常缺乏独自开发时的“成就感”。这也是素朴的、混沌未开的开发过程一旦引入分工，就必然产生的异化。如果说，上面谈到的这两点还应该算是人类各种分工制度共有的“必要的恶”，软件开发中的分工还有一种特有的弊端：细致的分工与“重量级方法论”之间有很强的亲和性，倾向于导致更高的开发成本和开发风险。对于产品设计和系统构架设计来说，将决策权集中在产品经理和系统架构师手中，意味着一种集权式的专制体制。这也要假设，这些负责人对产品或系统构架具备了充分的、无遗漏的了解。整个系统从他们头脑中的理念萌芽演化，再通过文档等介质，最终被实现为软件产品。如果产品经理确实能够从一开始就清晰、完整地把握客户需求，选定的开发平台、技术对系统架构师也不存在任何难点，那么类似的集权制可能是合理而且高效的。但软件开发往往充满革新和变数，客户需求一日千变，开发技术也日新月异，大量不确定因素的引入，使集权体制变得非常可疑。如果需求和设计无法自顶向下、一步到位的给出，而是需要多次反复、迭代才能渐趋完善，那么一个多级的、细分工的开发体制与扁平的、粗分工的体制相比，就需要更大的初期代价（initial investment），更多的文档和交流，并缺乏后者灵活、自适应的应变能力。 一旦了解了需求并且把需求文档化，分析员就与设计人员一起工作，以生成系统层描述（系统要什么）。然后，设计人员与程序员一起工作，以程序员能够编写实现指定需求的代码行的方式来描述系统。 生成代码之后，必须对它进行测试。通常，第一次测试由程序员自己完成；有时，也使用另外的测试人员帮助程序员发现他们忽略的错误。当代码单元被集成为一组运行的功能时，测试人员小组与实现小组一起工作，以验证随着将各部分组合起来构建系统，是否它能够正确运行，以及是否符合规格说明。 当开发团队对系统的功能和质量感到满意时，注意力就转向了客户。测试小组和客户一起验证整个系统是否是客户想要的系统。他们通过把系统如何工作与最初需求规格说明进行比较，来完成这项工作。然后，培训人员向用户说明如何使用这个系统。 如果在系统已经验收之后发现了故障，维护人员就会修复它们。另外，随着时间的推移，客户的需求可能会发生变化，系统也必须进行相应的改变。因此，维护可能涉及分析人员，由分析人员决定增加或变更哪些需求；还可能涉及设计人员，由设计人员确定改变系统哪个部分的设计；还可能涉及实现这些变化的程序员，确保改动后的系统仍然正确运行的测试