关于软件开发团队的一些思考
要给boss提一些建议，也顺便整理一些想法，写了一些字，下面是其中有关团队建设的内容，想请各位狂批之，在当下窃喜。这其中有许多是在经历CMM认证，以及MSF以后整理来的，有许多也曾在工作中应用过。
概述：
目前一些软件开发团队，特别是中小型团队，由于在低成本模式下运行，加之对软件过程管理的不尽规范，在团队建设上只重视代码开发，不重视设计，只重视编程技术，不重视需求分析、架构设计等技术，只重视开发过程，不重视测试过程，只重视任务，不重视风险等问题，是许多软件公司不能很好的以高效率模式开发出稳定可靠的软件产品的重要原因。
软件产品的开发，技术路线确定以后，团队组织以及过程管理就成为团队领导人的核心工作内容，项目负责人一般情况下也是技术决策人，这种角色的兼任对中小团队来说也是有效的，但问题出现在项目负责人大多都是优秀程序员出身，对软件技术有着很高的热情，但对项目管理以及更高层次上的团队建设方面就显得有些能力不足。这也会造成一些软件开发的高手做出来的产品却不尽如人意的尴尬局面。
其实在工作中，以公司的现有条件以及技术特点，在目前一些成熟的模型基础上建立个有公司自身特点的团队建设基本原则以及实施办法，执之以恒的加以贯彻执行，对公司产品目标的形成，公司核心技术的形成，公司核心团队的形成都会产品重大的影响。
具有一定普遍意义的风险：
在许多项目开发或产品开发中，失败的原因一般有以下几类，一是功能及性能没能满足应用的需求；二是需求变化导致项目成本的增加；三是技术水平不足导致项目成本的增加；四是团队出现重大变动，导致研发过程不能正常继续。
功能及性能方面：一般来说，功能及性能方面主要是需求目标没能得到充分重视，特别是性能、安全以及部署等非功能性需求；对核心业务本身，需求分析过程中是被关注最多的，但如何理解这些核心业务，如何用正确的架构完成核心业务的实现，这期间如果控制不当，也会产生许多导致成本增加、工期延长等许多不确定性结果。在需求分析阶段，对需求没有系统的过程控制，带来的风险是非常大的，这往往会成为项目失败在技术上的最先出现的原因；虽然所有的软件团队对需求分析都非常重视，但如果在方法及管理过程中不能有效的控制与管理，也很难避免由于需求阶段存在的风险给整个产品或项目带来严重的问题，几乎所有的中小型软件团队都会有过类似的经历。
需求变化：需求变化是当前软件产品或项目必需适应的，为了具备这个适应能力，除了在架构设计方面要考虑到系统的可维护性，可扩展性以外，对需求的变更管理及相应的风险评估经实践证明是比较有效的管理手段，在这方面技术与技术管理同样重要，缺少哪个环节，都会给产品或项目带来可能导致项目失败的隐患。
技术水平不足：在沈阳地区具有一定的普遍性，目前沈阳市软件开发人员资源并不丰富，大多数优秀开发人员都流向了北京、上海等行业发达地区，其它比较好的开发人员基本上都在大型企业中，根据近两年的经验，能在社会中用招聘方式组建的研发团队，即要有一定的实践经验，同时要保障在同一平台下工作，其质量很难达到快速开发的目的，即使是存在了许多年的团队，也会随着技术人员的流动对团队技术水平带来许多的不确定性；如何能有效的吸引高素质高水平程序员，如何有效的培养高忠诚度的核心员工以及如何有效的利用外部资源，这是目前大多数软件开发团队所面临的重要课题。
团队出现重大变动：这是个比较极端的情况，但却会经常发生，在对2003-2004两年政府项目就多次出现了因为项目团队中人员流动多大，导致项目无法进行的情况（如省民防办、新闻出版局等），这也是一个不容忽视的风险。
要有效的规避风险，在其变成问题前采取有效的措施，是风险管理的主要任务，这里并不做具体的风险评估，只是由于在团队建设方面存在的一些不完善，会成为这些风险（甚至不只是这些）存在的原因，所以才显得重要，其实说到底，就是软件产品不可能是小作坊式的开发方式能完成的，是否具备完善有效的控制能力，规避由其所带来的质量与可靠性方面引起的风险是关系到团队生存的大事。
团队模型的完善：
团队模型是软件开发队伍建设的基础，一个结构合理的团队，虽然不能保证项目一定成功，但却是保障产品长期稳定的保持高质量、高可靠性的基础。
这里所建议的团队模型，参考了敏捷开发和CMM、MSF等重要模型，并在实践中应用了两年以上，应该说是一个有效的中小团队模型；这个模型本身不是固定不变的，它应结合不同时期，不同团队的特点，加以完善，提高其可行性与有效性。
团队模型中的重要概念：
团队的基本构思：
为了弥补传统项目小组自上而下的层次结构的一些不足，研发团队应是小型、跨学科的小组，在这样的小组中成员们共同承担各项职责，权衡彼此间能力差异，以便将主要精力集中到手头上的工作中。他们拥有共同的项目前景，以部署产品为中心，坚持高标准的质量和沟通，保持乐意学习的心态。本文描述了小组中的各种角色群，以及他们的目标和职能领域。同时提供了指导，以便根据产品规模和复杂性来保障一个高效的团队。
清晰的责任，共同的职责：
将工作进行中需要共同承担的职责和确保工作如期完成需明确的工作责任结合起来。
团队模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点，但是没有哪个个人能够完全代表所有的不同质量目标。为了解决这一问题，把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。
在小组内部，每个角色通过对小组本身负责（也对他们各自所属的组织负责）实现该角色的质量目标。在这种意义上，每个角色都对最终解决方案质量的一部分负责。小组成员之间共同承担职责（根据不同小组角色指派）。角色之间是相互依赖的，有以下两个原因：首先，就其必要性而言，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们负责的直接区域以外的工作做出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到产品的构造里。项目的成功属于所有的小组成员；他们共同分享一个成功的项目所带来的荣誉和回报，他们也同时希望，即使是一项不太成功的项目，也能做到全心投入并从中吸取教训以完善他们的专长。
赋予小组成员权力：
在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，未来客户也能够认为小组将会兑现其承诺，并进行相应的规划。在最坏的情况下，小组也应该尽快地告知客户项目出现了哪些延迟和变化。
赋予小组成员权力，让其承担指派的承诺。这种授权包括向小组成员提供进行工作所需的各种资源；负责制定决策以有效影响队员的工作；理解队员的权力界限，并不断增加各种可用途径来处理越权问题。
准备好向其他成员允诺。这些准备包含了心态（进行面谈并乐意采取行动）、就绪，并理解承诺的内在含义以及它对当前工作量和资源的影响。这样做的结果就是，不到小组成员清楚承诺的内在含义，就不要作出承诺。相反，小组成员要提出一个更小的、他们能够理解的承诺，例如对这些承诺的内在含义进行研究，然后再迅速坚定地作出承诺。对较小承诺的成功交付将建立小组的信任。
清晰定义自己担负的承诺。这样可以避免一些可能会导致小组成员间信任危机的误会。
做出一切合理的努力来交付承诺的工作。如果一个小组有来自不同组织的成员，那么合理的期望也将因人而异。例如，某些小组成员可能认为在周末工作是合理的；而其他人则可能将他们视为例外或者可能在周末几乎不会去上班。
发现承诺陷入危机时进行真诚的沟通。有时将无法避免事情的变化，原因可能是某些任务的优先级调整、一个意外事件或仅仅是因为一项工作延期完成。及早的进行沟通将使与之相依赖的其他小组成员可以有机会制定相应的计划。也许他们还可以提出解决这些问题的途径。
这些行为应与企业文化是融合在一起的，队员们已经将它们视为一种文化，因此很少讨论它们。但是，团队有时需要与不同的组织一起工作，在这些组织中的相关的价值观念并没有被完全地了解和注重。这些组织常常呈现出一种高度推诿的文化，这种文化约束着应该开放的信息流。在这些情况下，团队领导应当根据这一点来清楚地陈述他们的期望并帮助新的小组成员适应这种工作方式。
共同的项目设想：
全力提倡采用一个共同的设想，以便把注意力放在小组的工作方法上，包括在一个操作环境里交付产品完整的解决方案及服务。
对项目和过程的目标有一个清晰的了解是很重要的。因为小组成员和客户都在猜测这项解决方案能为组织做些什么。一个共同的设想将使这些猜测明确化，并确保所有参与者都在为完成相同的目标而努力着。共同的设想是团队组织模型的基础之一。
当所有的参与者都了解了这一设想并朝着这一设想工作的时候，小组便能够根据成员使自己的决策与这一设想体现的更为广阔的小组意图相吻合，从而获得他们的权力。
没有共同的设想，小组成员可能出现与目标相抵触的观点，作为一个团体的交付将变得更加困难。并且即便小组完成交付，小组成员也很难确定自己的成功，因为这种成功依赖于他们评价成功的设想。
以客户为中心：
满足客户对任何优秀的团队来说都被看作是第一位的。在整个开发过程中，以客户为中心包含了小组对了解和解决客户业务问题的承诺。衡量以客户为中心的理念体系获得成功的方法之一是能否使设计中每一个特性都符合客户和用户需求。同样，实现客户满意度的一个关键方式是使用户积极地参与设计并在整个开发过程中提供反馈意见。这样，小组和客户都能的使期望和需求更加吻合。
零缺陷：
在一个成功的团队中，所有成员都感到要对产品的质量负责。产品质量责任不能由一个团队成员委托给另一个成员或部门。同样，每个成员都要作为客户的拥护者，在整个开发周期中考虑最终产品的可用性。
零缺陷理念是对质量的承诺。这意味着目标是尽可能最高效地执行工作，这样即使不得不在明天就交付产品，他们也可以交付出一些东西。这个想法是让每一天都有一个接近可交付的产品。这并不意味着交付不存在任何缺陷的代码；这意味这产品满足或超出了项目出资人的质量要求并在预想阶段被小组接受。
用自动机车装配线作类比最有力的描述了这一概念。传统上，工作人员将汽车由单独的部分组装起来并且为他们自身的质量负责。当汽车下线，一名检查员进行检查并判断该汽车的质量是否达到售卖的标准。然而在这个过程的后期，大量的时间将花费在查找所有的问题上，因为在此时进行纠错是极富价值的。同样，既然质量是不可预计的，在后期决定产品是否可售卖所需花费的时间也是不可预计的。
在当前的汽车制造业中，质量已经成为了“第一工作”。这意味着当工作正在进行时（例如正在装配一扇车门或是安装一部收音机），检查员同时审查该项工作以确保它符合为标准的汽车所定义的质量标准。只要在整个装配过程中保持该级别的质量，那么在后期为确保这辆汽车的质量可接受只需要花费更少的时间和资源。这使生产过程更可预测因为检测员只需要检查各个部分的整合处而不是所有个别的工作。
本文blog来源：http://okokwukai.cnblogs.com/archive/2006/06/06/418504.html
