《小型软件团队过程改进方法》由会员分享，可在线阅读，更多相关《小型软件团队过程改进方法（54页珍藏版）》请在金锄头文库上搜索。
1、过程塑造（小型软件团队过程改进方法）一、从方法到编码这是一篇偏重于介绍方法学（特别是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。 本系列包括： 知识接力、 代码是最终目、 一致性的思考、 活跃和混乱、严谨和死板、 短期利益和长期利益的权衡。软件管理和和软件开开发是截截然区分分的吗？ 对于于项目经经理来说说，其职职责是软软件项目目的管理理，而对对于架构构师、编编码人员员来说，其其职责是是软件设设计和开开发。虽虽然在一一些
2、小型型的团队队中，这这两种职职责有时时候是同同一个人人担任的的，但两两种角色色的区分分是必要要的。从从事过软软件开发发的人都都能或多多或少的的感受到到软件管管理和软软件开发发之间客客观存在在的沟壑壑。 我常常听到到来自两两个方面面的声音音。一边边抱怨说说设计师师、编程程人员阳阳奉阴违违，难以以管束，导导致已订订立的软软件过程程形同虚虚设。另另一边抱抱怨软件件过程存存在诸多多不恰当当的地方方，变成成了软件件开发的的绊脚石石。 现代的方法法学理论论以及相相应的过过程实践践为我们们奠定了了软件开开发科学学管理的的基础，个个中的翘翘楚包括括RUPP和XPP，纵观观这些方方法、过过程，都都非常强强调过程
3、程的流畅畅、生命命周期的的延续。而而在实际际的应用用中，我我们却常常常能够够看见对对它们的的不恰当当的理解解，不正正确的使使用。尤尤其是那那些希望望在自己己的软件件团体中中引入新新型的方方法过程程新手们们。对于于他们来来说，最最容易犯犯的一个个错误就就是忽视视了如何何利用一一个软件件过程来来创造一一个成功功的软件件。关于如何建建立一个个软件过过程的资资料很多多，但是是这些资资料并没没有把为为什么需需要过程程，过程程的目的的是什么么之类的的问题说说清楚。而而这些资资料的读读者们，往往往需要要花费大大量的时时间，亲亲自进行行实践之之后，才才能获得得这些问问题的答答案，而而付出的的代价是是教训和和挫
4、折。同同样的，我我和我的的伙伴们们也经历历了这样样一个过过程。因因此，我我希望把把我在过过程应用用、过程程改造中中涉及到到的问题题例举出出来（采采用过程程模式的的方式）。如如果大家家能够利利用到这这些经验验（哪怕怕是一些些），那那本文的的目的也也就达到到了。因因此，本本文并不不是一篇篇专门讨讨论如何何建立过过程的文文章，也也没有涉涉及建模模、设计计、编码码等方面面的内容容。但是是本文中中所讨论论的内容容都可以以对以上上的活动动起到部部分的指指导作用用。敏捷？敏捷捷！ 从从开始研研究软件件工程，我我就对敏敏捷过程程的概念念情有独独衷，但但是随着着学习的的深入（所所犯错误误的增多多），我我发现敏敏
5、捷是无无处不在在的，她她是一种种尺度，一一种处于于混乱乱和死板之间的的平衡艺艺术。有有句俏皮皮话说的的是一一放就乱乱，一管管就死，这句句话很好好的点出出了软件件过程的的一种无无奈性。如如果没有有严格的的规定，软软件开发发就陷入入一种混混乱、无无序的状状态，但但是如果果制定了了过于严严格的规规定，软软件人员员的思路路又受到到极大的的约束，管管理成本本也随之之上升。敏敏捷正是是一种处处于两个个极端之之间微妙妙平衡的的艺术。这这种艺术术难以完完全表述述，但是是可以通通过一些些指导，来来帮助大大家达到到这种境境界。 因此，我们们可以推推想的到到，敏捷捷是见仁仁见智的的。每一一个软件件团体都都有自身身的
6、特性性，其敏敏捷过程程必然都都不尽相相同。如如何设计计出成功功的敏捷捷过程，来来保证软软件团体体的成功功呢？本本文通过过一些过过程模式式的讨论论，揭开开了问题题的一角角。关于于过程设设计的完完整的讨讨论，大大家可以以参考敏敏捷软件件开发Aliistaair Cocckbuurn一书（该该书近来来将有中中文版面面世），该该书详细细的描述述了过程程设计的的来龙去去脉，以以及如何何根据组组织的特特点来选选择适当当的过程程。 因此，虽然然本文中中并没有有特别提提到敏捷捷的字眼眼，但是是所讨论论的内容容无不在在敏捷思思维的范范围之内内。 MDA推动动软件可可重用框框架的建建立 我我有一个个梦想，希希望有
7、一一天能够够不用在在诸多的的平台之之间摇来来摆去。虽虽说Jaava语语言的口口号就是是跨平台台。但事事实上，我我们还是是无法完完全摆脱脱平台的的束缚。 在UML22.0的的规范中中，提到到了一个个MDAA（Moodell Drriveen AArchhiteectuure）的的概念。在在众多的的软件平平台中不不知该如如何选择择，已经经演变为为当今软软件开发发的主要要难题。MMDA的的存在目目的就是是为了解解决这个个问题。通通过MDDA技术术，一个个UMLL的模型型可以是是平台无无关的，称称为PIIM（PPlattforrm-IIndeepenndennt MModeel），也也可以是是和特定定
8、平台相相关的，称称为PSSM（PPlattforrm-SSpeccifiic MModeel）。利利用平台台技术的的软件商商，可以以专注于于自己的的领域，集集中描述述业务功功能，业业务规则则，而无无须考虑虑特定的的技术，构构建出一一个PIIM，然然后，通通过支持持MDAA的工具具，将PPIM转转换（通通过不同同Proofille进行行映射）为为一个或或多个PPSM。这这时候的的模型仍仍然是UUML的的。但是是，这个个转换过过程虽然然有工具具的辅助助，但仍仍然需要要外力的的介入。接接下来，开开发工具具将会从从PSMM中产生生可执行行代码。这这就是MMDA的的思路，它它把以往往以程序序为中心心的开
9、发发模式转转变为以以设计为为中心的的开发模模式。 以往的重用用，往往往是基于于代码的的，例如如算法的的重用、界界面组件件的重用用，却往往往没有有将重用用提升到到设计的的层次上上。MDDA为我我们建立立可重用用的框架架提供了了一个很很好的指指导。注注意上面面的这副副图，最最外面的的两层就就表达了了MDAA可以用用于设计计重用的的基本理理念。倒倒数第二二层的含含义是利利用MDDA来进进行通用用软件（例例如事务务、目录录服务）的的模型设设计，倒倒数第一一层则表表示MDDA可以以用于特特定业务务领域的的设计建建模。可可以想象象，今后后软件公公司中的的最有价价值的资资产，就就是这些些设计模模型。 本文并
10、不打打算详细细讨论MMDA，除除了简单单的介绍绍MDAA的思路路之外，更更重要的的一点是是企业可可重用框框架的建建立。软软件企业业的核心心在于知知识，如如何有效效的将人人脑中的的知识存存储起来来，并不不断的使使用和发发展，是是软件企企业成功功的关键键。本文文提到的的可重用用框架，指指的就是是将软件件开发相相关知识识存储起起来的框框架。这这个思路路是本文文的一个个核心思思路。在在本文看看来，可可重用框框架不但但包括了了设计模模型，还还包括了了过程和和方法。软软件开发发是在这这个框架架之内运运作的，同同时反过过来影响响着框架架的完善善和改进进。 过程塑造模模式语言言下述的模式式都是从从软件开开发过
11、程程中，围围绕着可可重用框框架的建建立整理理出来的的一些经经验，之之所以整整理为模模式的形形式，是是因为这这种方式式有利于于类似情情况的鉴鉴别和对对其进行行必要的的扩展。在在软件开开发中会会遇到各各种各样样的问题题，以上上模式中中讨论到到的问题题都是我我们在实实践中，或或是和其其他开发发团队沟沟通中反反复遇到到的。因因此坚定定了我们们将之整整理为模模式的信信心。目目前我们们得到的的模式并并不多，但但是随着着经验的的增加，我我们会得得到更多多的积累累。 本文介绍的的模式都都比较注注重权衡衡的艺术术。我们们认为这这是敏捷捷思维的的必然结结果。世世界上并并没有什什么绝对对的事情情，尤其其是目前前多变
12、的的社会中中，昨天天的标准准并不适适合于今今天的环环境。因因此，我我们的平平衡点也也在不断断的变化化。 传统、经典典、学术术的瀑布布模型为为我们建建立了软软件开发发的基本本过程，虽虽然有各各种新的的生命周周期模型型的提出出，但是是基本的的过程并并没有太太大的变变化。例例如，增增强性的的瀑布过过程是在在瀑布模模型的基基础上增增加了回回溯到上上一个阶阶段的能能力；迭迭代式过过程的每每一次迭迭代都是是一次微微小的瀑瀑布生命命周期。在在这个生生命周期期模型中中，信息息在初始始需求收收集阶段段生成，并并通过分分析、设设计、编编码、部部署等阶阶段转化化为用户户最终需需要的软软件。在在这样一一个延续续性极强
13、强的周期期中，我我们如何何保证信信息能够够得到正正确的传传递呢？我们用用什么方方法来避避免信息息传递的的失真呢呢？我们们如何在在这样一一个过程程中处理理人与人人之间的的交互呢呢？在正正确传递递信息的的情况下下，我们们又如何何保证投投入的最最小化呢呢？这些些问题正正是 知知识接力力模式所所重点关关注的。 我不只一次次的见过过为过程程而关注注过程的的情况。产产生这种种结果的的一种原原因是“过程麻麻痹症”。过程程一旦定定型，就就不再改改变，即即便当初初制定过过程的环环境已经经发生了了变化也也是如此此。过程程的制定定一定是是针对特特定的目目标的，这这个目标标就是开开发出成成功的软软件，如如果不能能够服
14、务务于这个个目标，遵遵循过程程又有什什么意义义呢？另另一种原原因是过过程被分分割为彼彼此独立立的片断断，每个个开发人人员只关关注自己己的职责责，而忽忽略了最最终的软软件。过过程的 代码是是最终目目的，开开发过程程中的所所有活动动都围绕绕着这一一目的而而展开。如如果没有有最后的的用于交交付的代代码，软软件就无无法成为为软件。因因此，必必须保证证过程能能够产出出代码，而而且是优优秀的代代码。 一致性原则则是软件件开发中中重要原原则，也也是最令令人困惑惑的原则则。做到到完全的的一致性性将会导导致高昂昂的成本本，而不不一致又又会导致致项目出出现各种种各样的的问题。可可以想到到，这又又是一个个需要权权衡
15、的问问题。软软件项目目中的一一致性大大致可以以分为两两种，一一种是不不同工件件之间的的一致性性（例如如设计模模型中的的类名称称和实际际代码中中的类名名称的一一致性），一一种是工工件和软软件过程程的一致致性（类类名称需需要满足足命名标标准）。我我们如何何考虑这这两种情情况下的的一致性性呢？ 人们说管理理既是科科学也是是艺术，这这句话用用来形容容软件工工程再适适合不过过了。如如果说这这里有什什么不够够恰当的的地方的的话，我我倒觉得得是软软件工程程的这这个提法法有些许许的欠妥妥。软件件工程的的思路源源自于人人们渴望望软件开开发能够够像土木工工程那样样成熟。但但是几十十年的经经验下来来，大家家可以肯肯
16、定，软软件开发发和土木木工程有有着太多多的不同同：开发发人员和和建筑工工人也有有着截然然不同的的差异，知知识的组组装和钢钢筋混凝凝土更是是天差万万别。（但但为了保保证延续续性，我我们在本本文中仍仍然延续续软件工工程的提提法。）因因此，软软件工程程需要在在科学和和艺术之之间求得得权衡，科科学的一一面包括括了软件件开发规规范、准准则、实实践、过过程、方方法；而而艺术的的一面则则囊括了了人员的的激励、协协调，组组织的设设计等因因素。因因此我们们需要审审视我们们的规则则、过程程、方法法，它们们是否能能够发挥挥出人的的创新性性？或是是它是否否足以约约束人的的行为？这就是是 活跃跃和混乱乱、严谨谨和死板板模式所所要告诉诉我们的的。 应该说，本本文中所所讨论的的模式更更适合于于使用面面向对象象技术的的开发团团队。尤尤其是 短期利利益和长长期利益益的权衡衡模式。和和大多数数人一样样，我们们最早也也是过程程式编程程阵营的的
