1、软件工程文化培养,软件工程文化及其创建 1、问题的提出Tom DeMarco,Timothy Lister在Peopleware一书中提到：程序员之间的能力比为10：1甚至有的研究得出的结果为20：1DeMarco,Lister还研究了92个软件开发组织：个人产出比为11：1 结论：软件开发组织必须采取有效的方法解决这一问题。,2、软件文化的概念 The American Heritage Dictionary:“Culture” as “the totality of socially transmitted behavior patterns,arts,beliefs,institutio
2、ns,and all other products of human work and thought characteristic of a community or population.”可见，文化包括：一组共享的价值（观）、目的和原则， 它们指导人们朝着一个共同目标工作的行为、活动、优先的 思索（priorities）和决策。-有的文化是由不同的观点和行为表征的，而不是由“价 值”表征的。-共享一种文化是相当困难的。-每一组织均有自己的文化，但有的文化与其它文化相比 则是具有生命力的。,2）面向质量的文化关注质量的文化，是“健康”的软件文化。这一文化有三个基本成分： 个人承诺（comm
3、itment）：每一个开发人员承诺，通过系统化地应用有效的软件工程实践，创建有质量的产品； 组织承诺：所有层次上的管理者承诺，提供一个环境，在这一环境中，软件质量是一个基本的成功驱动，并且，该环境能够使每一个开发者达到这一目标。 所有人员承诺：不断改善他们所使用的过程，由此不断改善他们所创建的产品。,3）软件工程文化与组织“目标、活动、优先思考的问题 以及技术实践”之间的关系。,项目目标,技术实践,每个人的活动,软件工程文化,管理的优先考虑,隐含（imply）,定义（defines）,增强（reinforce）,增强（reinforce）,系统帮助（helps set）,增强（reinforc
4、e）,基础（is foundation for）,其中： 开发组成员所具有的价值观和信仰，定义了质量和 生产率的目标； 这一目标隐含了实现这一目标所采取的实践； 这些实践活动的一致应用，以及表明实现所期望结 果的能力，增强了所致力的软件工程的文化。 文化提供了决策和活动（action）的基础； 一致地应用这一文化，进一步增强了该文化的价值； 并且，该文化可以帮助该组织的管理人员建立他们 优先思考的问题。, 在该组织的所有层次上，管理者通过发送消息所传 达的一致的优先考虑的问题，共享了有关软件质量的承诺。 这些增强的反馈环，支持该软件文化的演化，以改善其性能。 由此可以看出：在具有软件工程文化环
5、境中工作的人们，进行的是应用 开发，而不是单编（hacking out）一个程序。即针对应用问题，通过使用的不同工具和技术，集中于 开发有用的应用，而不是简单地编写程序。应用开发包括项目计划和管理、问题域分析、需求规 约、体系结构和程序设计、验证以及建立文档等任务。-为可靠的编码奠定了基础。,3、文化的培养 1）文化不能“购买”，而只能培育原因：-每一个开发队伍工作在不同技术背景，不同的应用领域， 面对不同的用户期望并受约于不同的管理。其中不变的事情是：关注质量的态度和健全的工程过程。-对于创建一个软件工程文化，不存在一个简单的“处方” 或“核对表”，仅存在：一组有助于建造质量软件产品的技术实
6、践；应用于这些实践的个体的原则；以及培育关注质量文化的领导阶层的行为。,2）培养一种软件工程文化，需要一个过程这一过程由很多步骤组成（但没有现成的步骤可循）， 其中每一步骤将建设性地贡献于这一文化，贡献于改善该 组织内人们所创建的产品。原因： -在一个队伍中，如果没有共享软件优点的目标，那么就没有一个人将感 到需要改变。-解除过程改善的努力，这是很容易发生的事情。为什么？存在抵触的种子，如一些成员喜欢以新的方式工作，而其他成员 抱怨他们是工作的阻力。当该组中大多数人朝着软件工程的未来社会稳步前进时，不具有新的文化 的那些人可能会产生一些抱怨，其结果：离开这一文化和社会；或可能努力拖 带这一队伍
7、返回到他们自己感到安逸的水平。,途径：（1） 同一原则和价值-提供了改善工作环境和工作结果的机遇 例如：通过小组的集体讨论训练，或正式的过程评定，可以最好地团结组内成员共同地行使改进活动。由该组选出的代表一起工作，标识较好的方式，来执行该组的软件任务。软件管理者不可以简单地裁决需要做的改变，并期望任意具有建设性的事情发生。他的任务是把握该队伍朝着关键改进域-建立软件工程文化的下一步骤-方向工作。,（2）训练可重复、可度量的开发过程- 一个共享的文化训练可重复、可度量的开发过程是实现软件过程成熟的必要 基础。随着一个组织为了改善它的规程和过程，系统且仔细地 工作，一种公共文化就自然形成。在这一过
8、程中，面向质量的文化可以使所有成员发挥他们 全部能力，经过个体的努力和有效的合作来建造优秀的产品。工作在这一文化中的人们，知道使用定义的过程开发软件 并没有抑制他们的创造，而将他们的创造力转换力到开发生存 周期的其它方面，如需求工程和软件设计。,一旦改善过程受到控制并且已成为做事情的正常方式的 一部分，则可以更加关注产品本身。公司和组织不提出过程 -他们创建产品的过程，就不要期望取悦于他们的客户。当该文化支持过程改善-作为正常的事，人们就不必消 耗精力抵制有益处的改变；反而，会使用改进了的技术，集 中其创造力，建造新的、更好的软件产品。尽管一个组织文化的多个方面可以以文档记录之，但真 实的文化
9、是由该组中的每一个人的行为所揭示。其中，写出任务陈述、想法、价值以及原则是最有激情的事情。任务陈述可以帮助该组中的每一个人理解他们在合作的方案中的任务，有助于统一于描述长远目标的想法，也提供了关注持续不变的功绩。,（3）文化的“定型”-规范企业的运行 企业文化的确可以通过一类实用的、有意义的、共享 的文档予以“定型”，它们为创建企业文化提供了有用的 工具，而不是小组偶尔思考的结果。,结论（1）一个健康的文化是通过实践培育的。从一个角度来讲，文化是“到底是如何做事情”。其中，避免： 标榜：使用一些陈词滥调。例如，“我们重视对他人的忠诚、正直和尊重”。“我们是世界级的软件供应商”。“我们将生产零缺
10、欠的产品”。实际上，没有几个是和这样崇高的目标不一致的。但它们是现实的吗？它们可以予以度量吗？它们对在组内工作的人们有任何影响吗？领导实行了“墙壁上鼓吹的口号”吗？ 期望与实践脱节：一个组织所期望的行为被记录在一个满架子上的软件开发标准中。但一是并没有遵循并努力实施；二是这些标准对过程改善和产品质量的提高并没有什么价值，而只是开发人员之间的一些玩料；三是这些标准与潜在的组织文化是不一致的，也就是说，这些标准没有考虑组织成员之间的信任和尊重，没有体现管理者和团体成员言行一致的品质。,（2）走向一种软件工程文化的路径，涉及小组行为的 改变，他们遵循已证明了的、产生上好软件的实践。通过朝 着每一个成
11、员可以有效地应用最好的软件工程方法这一环境 发展，则该小组就享受了改进质量和生产率的乐趣。当开发 人员真正掌握了软件工程的概念，那么这些概念就定义了 构造软件的方法（a way），而没有定义有的人可以有选择 地构造软件的方法。有趣于软件工程实践的开发者可以使 用这些概念-如果方便的话，但从业于软件工程的开发者， 尽管这些概念在有些时候并不是方便的，也应遵循一种有 纪律的途径。,4、健康软件文化的体现一个软件组织的文化是通过个体、小组、管理者的 行为揭示的，并作为一个整体，存在于该组织的特征之 中。一个真正作好软件工程为目标的团体和管理者，应 该具有以下特征：个体行为 每一个个体在每一个项目的某
12、些方面比以前更 加明显地努力工作，在持续的发展中体现出个人的贡献。 大方地鼓励组内成员向其他同事提交工作产品 以便复审，接受工作中发现的错误并吸取教训。 花费一定的个人时间阅读软件书籍，定期地掌握 最新的技术，并不断寻找应用上好技术解决问题的方法。,团队行为 开发者之间相互尊重，允许开展有生气的讨论，而不 是压制之。 新来的成员从那些具有更多经验人们的指导中，有效 地得到益处。 小组成员使用通用的工程规程和工具，以便更有效地 的合作。合作是规则，而不是反对。 广阔地复用现存的工作产品，包括编码，因为最大的 生产率来自已经做的工作。 该组共有一种态度-第一次就作好。在质量方面，强调 是预防缺欠，
13、而不是当客户或测试人员抱怨时祢补它们。 收集并分析小组的软件产品和过程的数据。以寻找在以后的项目中做得更好的方法。 在软件需求规约和设计中要以软件产品的用户为中心,管理行为 管理者和公司要为开发人员提供继续学习的条件，例如 举办讲座、付费送大学学习，和定期地购买一些技术书籍等。 管理者者应购买一些先进的工具，并在项目进度中安排 适当的时间进行新技术、新方法的培训。培训是项目进度的 要素。 高级的、非软件技术的管理人员认识到优秀的软件工程实 践与公司所期望的业务结果是一致的。 管理者是言行一致的。他们了解软件工程前提（premises） 并且他们表彰那些一直实践好的人员。,组织行为 不断致力于过
14、程改善。所有小组成员参与改善活动， 作为正常任务的一部分。 “拱型”事务（overarching business）和信息技术策 略，为组织、决策以及优先设置等的演化提供了一种框架。 所编制的可控的软件开发规程，被组内成员所采纳并 有规则的遵守。在这里描述的理想完美的境界可能真正并不存在。实 现这一境界是一项艰巨的工作，需要有创意的领导，并需 要小组持续不变的工作一个很长的时间。在你的环境中可 以发现其中的一些特征，对未来的雇员将更有魅力，他们 希望工作在一个质量驱动的文化中。,5、不健康的软件文化 个体行为团体成员之间的个人保守意识很强；编程员只按自己的方式工作，丝毫不考虑团体的目标和 利益
15、；当项目出现麻烦时，不靠集体解决，而只靠“聪明 才子”的英雄来解决；没有时间实施简单的质量控制措施，例如相互审查、系统测试、文档编制等；项目经理为了赢得主管和客户的满意，将项目管理当作一种游戏，如随意同意不可能的交付日期等。,管理行为没有系统的、以管理驱动的努力，来提高软件质量；一直迫于项目进度的压力；进度永远比质量重要；总是证明Brooks的名言：将个人力量加到一个已经推迟的项目上会更迟；管理者对雇员不诚实，为了团体利益总是不顾雇员的个人目标；贫乏的领导能力、繁重的工作量以及不现实的进度安排导致了很低的周转率。,企业行为不断地尝试新的技术、工具，企图寻找一种“神奇”的解决方案，使项目得到突破
16、性进展；开发人员陷入永无止境的辣手问题之中，没有机会得到发展成长；高强度的工作和不良的经济环境，导致开发人员和管理人员总是承受很大的心理压力；企业没有任何关于如何开展工作的规定，导致每个人按自己的方式进行工作；对完成的项目不进行分析，致使增大了失败的可能性。,6、表怔不同文化的组织范型（按改变工作方式所产生的结果）(Larry Constantine 1993) 封闭型（CLOSED） 按传统的责任层次体系，在这样的体系中，决策总是由上级作出追求稳定和持续发展；开发型（OPEN） 其主要特征为：具有创新的稳定发展，个人服从集体的利益，有合作、有弹性；随意型（RANDOM） 其创新有团体成员表现
17、之；企业在个人的创意中自发的改变；成员可能是有创造性的、有活力的，但决策是个人自发的行为；同步型（SYNCHRONOUS） 个人目标和企业目标是一直的，不欢迎不一致的行为发生；组织成员在角色、责任分工上是很默契的。 注：这仅仅是一种分类，说明不同的改进技术可能在不同的环境中会得到成功，而不是说明一种文化比其它的文化好。,封闭型（CLOSED） 开发型（OPEN） Hierarchical innovative Top-down decision collaborative Traditional authority sharing Stable secure negotiating Less
18、innovative flexible consensus decisions同步型（SYNCHRONOUS） 随意型（RANDOM） Harmonious independent initiative Quietly efficient creatively inventive Smooth operation less stable Slow to change informal Visionary leadership autonomous,对以上4类企业选出好的特征，可以形成一个结构良好的团体，如下所示：结构良好的、开放的团体所具有的特征,7、对管理的挑战一个高效的领导应更加关注工作环
19、境、开发人员的工作态度和行为，并非过分追求自己的管理期望； 管理者是在为他的职员工作，而不是职员在为管理者工作 管理者的责任是使职员发挥作为软件工程师的最大潜力，同时达到顾客、项目和企业的目标；管理者不应花费很多时间去处理委员会的事务，完成上级的吩咐，以导致项目过程的停滞，职员士气的不足；一个高效的领导对如何在项目中实施软件工程有着自己的设想，并列出计划以实现之；其中，必须针对工作环境，采用特定的方法，实现过程改善计划，并让所有成员参与过程改善，使他们有着适当的压力；必须使每一活动都找到工作和提高的平衡点。,8、为形成软件工程文化奠定基础的原则 （1）不要屈服于老板和客户的压力去做不好的工作；
20、 （2）每个人的工作都需要被别人承认； （3）继续接受教育是每个成员的责任； （4）客户需求是软件质量的关键因素； （5）最大的挑战是最终产品与客户的设想是相同的； （6）不断地改善软件开发过程是重要的，也是必要的； （7）记录软件开发过程是形成文化的最好方式； （8）软件质量是优先考虑的问题，从长远看，高质量的必然结果是生产率的提高；,（9）让同事发现错误，而不是让用户发现错误； （10）软件质量的关键是多次反复地实践除编码之外的其他过程；（11）很好地管理“发现错误”和“需求改变”是质量控制和维护的重要因素；（12）经常评估自己的工作，会使以后的工作做得更好 ； （13）做有意义的工作，而
21、不是求助于条条框框； （14）在所有需要改变的事情中，确定能够产生最大效益的改变，并立刻实践之。,总结 （1）尽管事实已经证明，先进的软件工程方法可以提高软件质量和生产率，但还是有许多开发者使用过时的技术，导致了低质量的产品和不可预测的结果。 （2）管理者和项目经理面临的最大挑战，是让开发人员在健康的、有支持和回报的环境中坚持实施软件工程的实践活动。 （3）不同类型企业文化的改变需要采取不同的方法。 （4）一个高效的领导，将团队目标和上级对产品过程的统一，可以驱动企业各方面的进步。,文化的建造者和杀手 文化的建造者项目组成员之间关于使用新方法、新技术经验的讨论-为开发人员提供了学习新技术解决问
22、题的机会，或吸取别人教训的机会。为新来的开发人员提供以前产品的相关资料，包括需求规约文档、测试计划、系统说明书等-可以帮助开发人员尽快熟悉软件工程文化，以找到更好的开发方法和合作方式。当项目陷入困境，也要做好其中一部分工作-可以调动开发人员的士气，并有助于了解问题所在。,文化的杀手作为管理者，即使收发电子邮件，在办公桌上也使用最好的设备，以显示在集体中的地位。 对不懂得软件和软件工程的上级，不花费时间说服他们对软件过程改善增加投资。 上级认为员工不需要接受继续教育掌握更新、更好的技术，员工也不提出这方面的要求。,软件项目的“五维”在一个软件项目中，必须管理以下“五维”：特性 （feature）
23、，质量（quality），成本（cost），进度 （schedule），人员（staff）。,feature,quality,cost,schedule）,staff,五维之间并不是没有关系的。例如，如果增加了人员，则 进度就可以缩短，而且成本可能就要增加。一个更通常的 交换是，缩短进度或增加特性，并牺牲了质量。这五维之 间的交换，不是简单的、线形的。对于每一个项目来说， 我们必须决策哪些维是关键的，以及如何与其它维平衡，如 此才能达到项目的关键目标。 每一为又可以具有三种角色之一，这三种角色为：驱动角色， 约束和自由程度。驱动角色是项目的一个关键目标。对于一 个必须按时交付以满足市场机遇的产
24、品，进度是一个驱动角 色。商业桌面软件，例如字处理系统和电子表格，他们常常 以特性作为驱动角色予以开发。,约束是一个限制要素。它不在项目领导者的控制之内。 如果一个固定人员的小组分配给一个项目，那么人员则成 为一个约束。在一个固定价格的项目中，成本是一个约束， 而对一个管理医疗设备软件或飞机飞行控制系统而言，质 量将是一个约束。有时，可以把成本或作为一个约束，或 作为一个驱动角色，因为它既可以是一个基本的目标，又 可以是一个限制要素。类似地，一个特定的特征集合，可 以是该项目的基本驱动角色，但如果这一特征集合不是可 以通过谈判解决的，则不能把它看作是一个约束。,既不是驱动角色又不是约束的项目维
25、，则成为一个自由程度。这些要素可以被项目领导予以调整，并达到某种程度的平衡，以实现整个项目的目标。例如，在一些内部的信息系统项目中，驱动角色是特征和质量，人员是一个约束，如此自由程度则成为进度和成本。这一轮廓意味着由用户所要求的特征将全部被包含，但该产品的交付时间可以比预期的晚一些。这一模型的一个重要方面并不是说明在一个项目中哪一维是驱动角色，哪一维是约束，重要的是该项目组、客户以及管理，预先商榷相关的优先考虑的维。这一商榷过程有助于定义规则和项目的边界。正如在大多数游戏中，我们可以根据任意一组规则来玩，但所有人必须了解并同意这些规则在任何特定的时间内是有效的。,如何把每一维划为哪一种角色的方
26、法，是去思考项目领导关于那一维所具有的“弹性”。一个约束实质上没有给项目领导任何弹性，一个驱动角色有较低的弹性，一个自由程度提供了一个较开阔的范围，以便将这一维与其它四维进行平衡。描述这一问题的图形方法是使用Kiviat图，该图允许我们划分一些不同的值（五个，参见下图），在一组规则的轴上，像一个不规则的多边形。对于一个特定的项目，在轴上每一点的位置指出那个维的相关的弹性度：数值范围从0（完全是强制的）到10（完全是灵活的）。,上图是一个弹性Kiviat图。该项目强制配置固定的人员， 因此在人员轴上有值为0。该项目被驱动以满足一个期望 的进度，因此在进度轴上的点有较小的值。该项目围绕 组成初始版
27、本的特征改变弹性，改变产品质量和成本超限 的范围。因此，这些自由程度的值在它们的轴上是较大的。,feature,quality,cost,schedule）,staff,0,2,4,8,10,内部信息系统的弹性图,该图是针对一个假定的项目，其中，质量是一个驱动 角色，而进度显示了最大的自由。对于一个竞争激烈的商 业软件产品，可能如同下图：,feature,quality,cost,schedule）,staff,0,2,4,8,10,质量驱动的应用之弹性图,feature,quality,cost,schedule）,staff,0,2,4,8,10,质量驱动的应用之弹性图,在这一图中，必须包
28、含一个特定的特征集合（一个 约束），进度被强制为一个特定的交付期，质量恰是不管 怎样的。在这些例子中，多边形的样子提供了一个可见的指示 -每一项目的重要方面。如果向内拖动轴上的一个点，减少 该维上项目领导所具有的自由度，一般来说就必须调整其 它维以予赔偿。可以应用这一类分析使管理了解这一变换 和他们必须作出的决策，以满足项目的关键目标，商榷每 一项目真正可以达到的承诺。像图2.5的形式，可以用于记录商榷的目的-用于“驱 动维”，用于约束维的限制，用于与自由程度维关联的那 些值的范围。在图2.5中给出的描述是图2.2所示的那个项 目的弹性图。,Project name: new informat
29、ion system Assessed by : Date assessed:,dimension,Driver (state objectives),constraint(state limits),Degree of freedom(state range),cost,features,quality,schedule,staff,release 1.0 must be delivered wi- thin 4 months,4.5 full-time staff available for du- ration of the project,up to 20% overrun from
30、initial estimate is acceptable,60-90% of priority 1 features must be in release 1.0,release 1.0 can contain up to 5 known major defect,常常，我们仅关注驱动方面（通常是特征或进度）， 没有注意到驱动角色对其它维的影响。这是一类行为-导 致这些软件工程没有像听到的那样惊讶。客户、管理者、 以及市场部门必须接受：不可能具有他们所希望的那些 特征-没有错误，很快地交付，缩小了开发队伍的规模还 有不高的成本。五维模型还可以应用于当整体改变时的重新商榷。 如果在即将发布时出现了必须包含的新需求，则就要问 以下管理者，应当调整什么以适应这一要求：, 应当推迟那些特征？ 进度允许推迟多长时间？ 可以增加人员或增加超时的费用，以满足新的进度？ 或，正常地，可以“饶过”质量？因为优秀的过程和 质量控制实践由于这一紧迫的工作而被忽略了。对此的特定回答还不如讨论更为重要，这一讨论是当 项目领导和开发者在任一维上“拖向”没有预料到的改变 时发生的。客户和管理者必须了解这样的改变对其他维的 影响，如此他们才能作出正确的决策。,谢 谢！ 并望开展有意义的讨论,
