敏捷软件开发方法-探索敏捷型方法的合理性着重点并不是正规方法

敏捷软件开发方法敏捷软件开发方法

新方法学12新方法学MartinFowler过去几年中兴起的敏捷型agile软件开发方法以矫正官僚繁琐过程或者许可对过程进行自主调整为特征在软件业引起了极大的兴趣在这篇文章里我将探索敏捷型方法的合理性着重点并不是放在其轻重上而是于它们的适配性adaptive性质和以人优先的理念我在本文也简要介绍了一些敏捷型方法并给出了进一步的参考材料另外我还给出了一些你在决定是否要走这条刚踏出来的敏捷之路时需考虑的因素在SDEast上我作了一次演讲让软件恒软〔KeepingSoftwareSoft其材料就是基于这篇文章你若有充足的时间可浪费的化不妨一观此文的节略版发表于SoftwareDevelopmentMagazine软件开发杂志的2000年12月期1从无到繁重再到敏捷多数软件开发仍然是一个显得混乱的活动即典型的边写边改codeandfix设计领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计过程充斥着短期的即时的决定而无完整的规划这种模式对小系统开发其实很管用但是当系统变得越大越复杂时要想加入新的功能就越来越困难同时错误故障越来越多越来越难于排除一个典型的标志就是当系统功能完成后有一个很长的测试阶段有时甚至有遥遥无期之感从而对项目的完成产生严重的影响我们使用这种开发模式已有很长时间了不过我们实际上也有另外一种选择那就是正规方法methodology这些方法对开发过程有着严格而详尽的规定以期使软件开发更有可预设性并提高效率这种思路是借鉴了其他工程领域的实践这些正规方法已存在了很长时间了但是并没有取得令人瞩目的成功甚至就没怎么引起人们的注意对这些方法最常听见的批评就是它们的官僚繁琐要是按照它的要求来那有做太多的事情需要做而延缓整个开发进程所以它们通常被认为是繁琐滞重型方法或JimHighsmith所称的巨型monumental方法作为对这些方法的反叛在过去几年中出现了一类新方法尽管它们还没有正式的名称但是一般被称为敏捷型方法对许多人来说这类方法的吸引之处在于对繁文缛节的官僚过程的反叛它们在无过程和过于繁琐的过程中达到了一种平衡使得能以不多的步骤过程获取较满意的结果敏捷型与滞重型方法有一些显著的区别其中一个显而易见的不同反映在文档上敏捷型不是很面向文档对于一项任务它们通常只要求尽可能少的文档从许多方面来看它们更象是面向源码code-oriented事实上它们认为最根本的文档应该是源码但是我并不以为文档方面的特点是敏捷型方法的根本之点文档减少仅仅是个表象它其实反映的是更深层的特点·敏捷型方法是适配性而非预设性重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划然后依计划进行开发这类方法在计划制定完成后拒绝变化而敏捷型方法则欢迎变化其实它们的目的就是成为适应变化的过程甚至能允许改变自身来适应变化·敏捷型方法是面向人的people-oriented而非面向过程的process-oriented它们试图使软件开发工作顺应人的天性而非逆之它们强调软件开发应当是一项愉快的活动在以下各节中我将详细地探讨这些差别这样你可以了解适配性和以人为中心的过程是什么它们的好处与不足以及你作为软件开发人员或用户时是否应该使用它们2预设性与适配性21将设计与建造分离开来传统的软件开发正规方法的基本思路一般是从其他工程领域借鉴而来如土木工程模式对软件工程的影响较大这类工程实践中在实际建造之前通常非常强调设计规划工程师首先给出一系列的图纸这些图纸准确地说明了要建造什么以及如何建造包括部分和整体许多工程问题快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题如怎样处理一座桥梁的负荷图纸上都有说明然后这些图纸分发给另外一组人员通常是另外一个公司去建造这种方式其实已假定了建造过程将按图纸而来当然施工中也会碰到一些问题但这些都是次要的图纸其实就是一个详细的建造计划它说明了一个项目中必须完成的各项任务以及这些任务之间的依赖关系这样管理层能较为合理地制订出生产进度表和项目预算这种模式实际上也规定了建造者如何做施工这也隐含着建造者不须是高智能型的尽管他们可能都有非常高超的手上功夫在此我们看到的是两类非常不同的活动设计是难于预设的并且需要昂贵的有创造你的人员建造则要易于预设我们有了设计之后便可对建造进行计划了而有了建造计划后我们进行建造则可以是非常可预设性的了在土木工程中建造不论在经费上还是在时间上的花销都要比设计和计划大得多所以多数正规方法的途径是象这样的我们想要可预定的生产进度计划以便能使用技能较低的人员要达到这一点我们必须得把设计与建造分离开来因此在软件开发中我们得想法作出这样的设计使得计划一经完成建造将会是直接而明确的那么计划应该采用什么形式呢对许多人来说这是设计标识符号notation如象UML需承担的角色了如果我们能用UML作出所有主要的技术决定那么就可以用UML来做建造计划然后把计划交给程序员去编码即是建造活动但这里存在几个问题你是否能作出这样的设计使得它能够让编码成为一项建造活动如果能那么建造是否能在资金和时间上的花销都充分地大于设计而使得这种途径值得一用第一个问题是到底有多困难能使一个用类似UML作出的设计达到交给程序员就能直接编码的状态用象UML那样的语言作出的设计在纸上看起来非常漂亮而实际编程时可能会发现严重的缺陷土木工程师使用的模型是基于多年的工程实践并结晶在工程典章中更进一步来说一些设计上的关键部分如应力作用都是建立于坚实的数学分析定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析之上而在软件设计中我们对UML图纸所能做的只是请专家审阅这当然是很有帮助的但是往往一些设计错误只能在编码和测试时才能发现甚至于熟练的设计者我自认为我属此列就常常对在把设计变成软件的过程中出现的错误感到意外另一个问题是费用比较建一座桥梁时设计费用一般占整个工程的10％左右余下的90％左右为施工建造费用而在软件开发中编码所占的时间一般要少得多McConnell指出在大型项目中编码和单元测试只占15％这几乎和桥梁工程中的比例倒过来了即使把所有测试工作都算作是建造的一部分设计仍要占到50％这就提出了一个重要问题那就是和其他过程领域的设计相比软件设计到底是什么性质更有甚者JackReeves认为源码也应是设计文档而建造应该是编译和链接因为任何属于建造的工作都应当是自动化的这些讨论导致了下面一些结论·在软件开发中具体建造费用非常低几可忽略不计·软件开发的绝大部分工作是设计因此需要富有创造性的才智之士·创造性的过程是不太容易计划的因此可预设性不可能成为一个要达到的目标·我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉因为它们是不同类型的活动因此需要不同的过程22需求的不可预设性在每个我参加的项目都有这样一种情况开发人员跑来抱怨说这个项目的问题是需求老是在变而让我意外的是每个人都对此感到意外其实在建造商用软件系统中需求变更是常态问题是我们如何来处理它一种方法是把需求变更看成是因需求工程requirementsengineering没作好而导致的结果一般来说需求工程或曰进行需求分析是要在着手建造软件之前获取一幅已完全理解了的待建系统的画面然后取得客户认可签发并且还要建立一套规章来限制需求变更该方法的一个问题是要准确获取所有需求是困难的特别是当开发商不能提供某些需求的费用信息时例如你买车时想在你的车上装一个天窗而推销员却不能告诉你要在车价上只再加10元钱呢还是10000元如果不知道这点你如何能决定你是否愿意在车上加个天窗呢作软件开发的费用估算是不容易的这有多种原因部分原因是因为软件开发是一种设计活动因此难于精确计划部分原因是系统的基本材料变化非常之快部分原因是开发活动极大地依赖于项目参与人员而个体是难于预测和量化的软件的不可触摸性也是一个原因在系统建成之前有时很难判断一项功能的具体价值也就是说只有当你在实实在在地使用系统时你才能知道哪些功能是有用的哪些没什么用这样的结果颇具讽刺意味即人们期待需求应该是可变的毕竟软件应该是软的所以需求不仅是可变的简直就是应该变的要让客户把需求固定下来要花很大的力气特别是当他们参与了软件开发并且知道软件是多么易于修改但是即使你能把所有的需求都固定下来并不意味着你的开发就是阳光灿烂了你可能仍然会在昏暗之中在当今的经济形势下决定并推动软件系统功能特性的商业因素飞快地变化着现在一组很好的功能六个月以后可能就不那么好了商业世界并不会因你的系统的需求固定下来了而停止不动商业世界的许多变化是完全不可预测的如果有人不承认这一点要么他在撒谎要么他已炒股成了百万富翁了软件开发的一切都取决于系统需求如果需求不固定你就不能制订出一个可预设性的计划23预设性是不可能的吗一般来说不可能当然有一些软件开发项目中预设性是可能的象NASA的航天飞机的软件开发项目应是这样一个例子它需要大量的会议充足的时间庞大的团队以及稳定的需求毕竟这些是航天飞机的项目但我并不认为一般的商用软件开发属于这类系统所以你需要不同的开发过程如果你不能遵循一个可预性方法而你强装能够那么这是非常危险的通常一个正规方法的创造者不是很善于或乐于给出其方法的边界条件换句话说当这些边界条件不满足时则该方法就不适用许多方法学创造者希望他们的方法能够放之四海而皆准所以他们既不去了解也不公布他们方法的边界条件这导致了人们在错误的情形下来使用一种方法例如在不可预设性的环境中使用一种预设性的方法使用预设性方法具有强烈的诱惑力因为预设性毕竟是一个非常需要的特性可是当你不能达到预设性时而你相信你能够这将会导致这样一种局面你可以很早就制订出计划但不能适当地处理计划崩溃的情形你看见现实与计划慢慢的偏离而你可以在很长的时间里装着认为计划仍是有效可行的但是当偏离积累到足够的时候你的计划就崩溃了这通常是很痛苦的所以说在不可预设性的环境中是不能使用预设性方法的认识到这点是一个很大的冲击它意味着我们用的许多控制项目的模式许多处理客户关系的模式都不会再是正确的了预设性的确有非常多的好处我们很难就放弃预设性而失去这些益处象很多问题一样最困难的一点是认识到这些问题的存在可是放弃预见性并不意味着回到不可控制的一片混乱之中你所需要的是另一类过程它们可以让你对不可预设性进行控制这就是适配性的作用了24不可预设过程的控制那么我们如何对付一个不可预测的世界呢最重要也是最困难的是要随时知道我们在开发中的情形处境这需要一个诚实的反馈机制综治信访维稳工作机制反恐怖工作机制员工晋升机制图企业员工晋升机制公司员工晋升机制来不断准确地告诉我们这种机制的关键之点是迭代式iterative开发方法这并不是一个新思路迭代式开发方法已存在很久了只是名称不同如递增式Incremental渐进式Evolutionary阶段式Staged螺旋式Spiral等等迭代式开发的要点是经常不断地出最终系统的工作版本这些版本逐部地实现系统所需的功能它们虽然功能不全但已实现的功能必须忠实于最终系统的要求它们必须是经过全面整合和测试的产品这样做的理由是没有什么比一个整合了的测试过的系统更能作为一个项目扎扎实实的成果文档可以隐藏所有的缺陷未经测试的程序可能隐藏许多缺陷但当用户实实在在地坐在系统前来使用它时所有的问题都会暴露出来这些问题可能是源码缺陷错误bug也有可能是对需求理解有误虽然迭代式开发也可用于可预设环境但它基本上还是用作适配性adaptive过程因为适配性过程能及时地对付需求变更需求变更使得长期计划是不稳定的一个稳定的计划只能是短期的这通常是一个迭代周期iteration迭代式开发能让每个迭代周期为下面的开发计划提供一个坚实的基础迭代式开发的一个重要问题是一个迭代阶段需要多长不同的人有不同的答案XP极端编程建议一到两周SCRUM建议一个月Crystal水晶系列更长一些不过一般的趋势是让每一个周期尽可能地短这样你就能得到频繁的反馈能不断地知道你所处的状况25适配性的客户这类适配性过程需要与客户建立一种新型的关系特别是当开发是由一家签约公司来进行的时候因为当雇佣一家签约公司来进行开发时多数客户愿意订一个固定价格的合同他们告诉开发方他们所需要的功能招标签约然后剩下的便是开发方去建造系统了固定价格合同需要稳定的需求即一个可预设性过程适配性过程和不稳定的需求意味着你不能做这种固定价格的合同把一个固定价格模式弄到适配性过程将导致一个痛苦的结局最糟糕的是客户将与软件开发者受到同样的伤害毕竟客户不会想要一个不需要软件即使他们未付开发方一分钱他们仍然失去许多因此在可预设性过程不能用的情况下签订固定价格合同对双方来说都有危险这意味着客户须换一种工作方式在适配性过程中客户实际上能够对软件开发过程进行很深入细微的控制在每一个迭代阶段中他们都能检查开发进度也能变更软件开发方向这导致了与软件开发者更密切的关系或曰真正的伙伴关系但并不是每一个客户也并不是每一个开发商都准备接受这种程度的介入不过如要让适配性过程能很好工作这种合作程度是基本的要求适配性过程对客户最关键的益处是软件开发中的回应性很好一个可用的尽管是很小的系统能够尽早投入使用根据实际使用情况以及变更了的需求客户可及时改变一些系统功能3让人优先实施一个适配性过程并不容易特别是它要求一组高效的开发人员高效既体现在高素质的个体也体现在有能让团队协调一致的工作方式这里有一个有趣的和谐并非只是适配性过程需要很强的团队多数优秀的开发人员也愿意采用适配性过程31可兼容性程序插件传统正规方法的目标之一是发展出这样一种过程使得一个项目的参与人员成为可替代的部件这样的一种过程将人看成是一种资源他们具有不同的角色如分析员程序员测试员及管理人员个体是不重要的只有角色才是重要的这样一来在你计划一个项目时你并不在乎你能得到哪个分析员哪些测试员你只需关心你可得到多少知道资源数量会如何影响你的计划但这里有一个关键问题参与软件开发的人员是可替代的部件吗轻灵型方法的一个重要特征就是拒绝这种观点也许最明确地反对这种观点的当数AlistairCockburn在他的论文政研论文下载论文大学下载论文大学下载关于长拳的论文浙大论文封面下载人是非线性一阶的部件中他指出可预设性软件开发过程要求部件的行为也是可预性的但是人并非可预性的部件更进一步他对软件项目的研究导致了如下结论人是软件开发中最重要的因素下段摘自他的论文在本文的标题里我将人称为部件其实传统过程方法就是这样看待人的这种观点的错误在于人是非常可变的和非线性的不同的个体具备特有的成功或失败模式那些因素是一阶的不可忽略的一种过程或方法的设计者如不能充分考虑到这些因素那么其后果就是项目的无计划轨迹就象我们经常看到的那样--AlistairCockburnCockburn是最鲜明地主张在软件开发中应以人为中心其实这种概念在许多软件行业的有识人士中已是共识问题在于所使用的方法是与这种理念背道而驰的这造成了一个很强的正反馈机制如果你期望你的开发人员是可互替的编程插件则你不会去试着把他们看成是不同的个体这会降低士气和生产率并使优秀的人才跳到一个能发挥其个性特长的地方最后你倒是得到你所需要的可互替的编程插件决定使人优先是件大事它需要很大的决心来推行把人作为资源的思想在工商界是根深蒂固的其根源可追溯到泰勒的科学管理方法当管理一个工厂时这种泰勒主义途径是有效的但是对有着高度创造性和专业性的工作我相信软件开发当属此类泰勒主义并不适用事实上现代制造业也在脱离泰勒主义模式32程序员是负责任的专业人员泰勒主义的一个关键的理念是认为干活的人并非是那些知道怎样才能把这件活干的好的人在工厂中可能是这样原因是许多工厂里的普通工人并非是最具聪明才智和最富创造力的人员另一个原因也许是由于管理层和工人的的工资悬殊太大而导致的关系紧张历史证明这种情形在软件开发中是不存在的不断有优秀人才被吸引到软件行业中吸引他们的既有耀眼的光芒也有丰厚的回报正是这两样诱使我离开电子工程其他一些福利如对公司的股份持有使得程序员的利益与公司紧联在一起〔可能还有一个年代generational效应一些所见所闻让我想到是否在过去十来年中有很多的优秀人才转入软件行业如果是这样这可能是当今年轻人崇尚IT业的原因就象其他时尚一样其后总有一些实在的理由如果你想聘到并留住优秀人才你得认识到他们是有能力的专业人员因此他们最有资格决定如何干好他们的技术工作泰勒主义里让计划部门来决定如何干好一件工作的作法只有当计划者比实际操作者更能知道怎样作时才有效如果你拥有优秀的自觉自励的员工那么这点并不成立33面向人的过程管理敏捷型过程中以人为本的理念可以有不同的表现这会导致不同的效果而并非所有结果都是完全一致的实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程通常软件开发的过程是由管理人员决定的因此这样的过程经常受到抵制特别是如果管理人员已脱离实际的开发活动很长时间了而接受一个过程需要一种自愿致力这样大家就能以积极的态度参与进来这样导致了一个有趣的结果即只有开发人员他们自己才能选择并遵循一个适配性过程这一点在XP中特别明显因为这需要很强的自律性来运行这个过程作为一个互补Crystal水晶系列过程则只要求最少的自律另一点是开发人员必须有权作技术方面的所有决定XP非常强调这一点在前期计划中它就说明只有开发人员才能估算干一件工作所需的时间对许多管理人员来说这样形式的技术领导是一个极大的转变这种途径要求分担责任即开发人员和管理人员在一个软件项目的领导方面有同等的地位注意我说的同等管理人员仍然扮演着他们的角色但需认识并尊重开发人员的专业知识之所以强调开发人员的作用一个重要的原因是IT行业的技术变化速度非常之快今天的新技术可能几年后就过时了这种情况完全不同于其他行业即使管理层里的以前干技术的人都要认识到进入管理层意味着他们的技术技能会很快消失因此必须信任和依靠当前的开发人员34应用域专家的引领作用TheRoleofBusinessLeadership技术人员并不能包打天下他们需要应用系统的需求分析即他们需要与应用领域专家非常紧密的联系这是适配性过程一个重要的方面这种联系的紧密度远远超过了一般项目中应用领域分析人员的介入程度如果开发人员和应用领域专家只有偶尔的沟通那么敏捷型过程是不可能存在的此外这种沟通不是由管理层来处理的而是每个开发人员需要做的事因为开发人员在他们的行业里是有能力的专业人员因此他们能够与其他行业的专业人员同等地在一起工作这是由适配性过程的特点来决定的因为在整个开发过程中事情变化很快你需要经常不断的联系沟通以使每个人都能及时知道这些变化对开发人员来说没有什么比看见自己的辛勤工作白白浪费更让人痛苦的了因此开发人员能随时获取准确的高质量的应用系统的需求知识就显得很重要了4自适配过程到目前为止我谈到的适配性是指在一个开发项目中如何频繁地修改软件以适应不断的需求变更但是还有另一种适配性即是过程本身随着时间推移变化一个项目在开始时用一个适配性过程不会到一年之后还在用这个过程随着时间的推移开发组会发现他们的工作有些什么变化然后改变过程以适应之自适配的第一步是经常对过程进行总结检讨一般来说在每一次迭代结束后你可以问自己如下问题〔NormKerth·有哪些做的好的部分·有哪些教训·有哪些可以改进的部分·有哪些没搞清楚的部分这些问题会帮助你考虑在下一次迭代中如何对过程进行修正在样如果开始时使用的过程有问题的话随着项目的进行该过程会得以逐步的完善以使其能更好地适合开发组如果一个项目采用了自适配方法则可以进一步在一个组织内引入这种方法如果要深化自适配过程我建议开发人员专门用一段时间做一次更为正式的回顾总结象NormKerth所建议的那样这些活动包括离开工作地点到另外一个地方开2－3天的总结会这不仅是给开发组提供一次学习机会同时也给整个组织一次学习机会自适配性导致的结果是你绝不能期待着只用一个过程相反每个项目组不仅能选择他们自己的过程并且还能随着项目的进行而调整所用的过程公开发表的过程和其他项目的经验都可以拿来作为参考和样本但是开发人员需根据手中项目的具体情况而对其加以调整这也是开发人员的专业职责这种自适配性在ASD和Crystal水晶系列中都鲜明地提及XP的严格规则似乎不允许这样但这只是表面现象因为XP是鼓励调整过程的这一点上XP和其他方法的主要区别之处在于XP的倡导者建议在采用XP时先根据书本循规蹈矩不走样地做几个迭代之后再考虑调整另外回顾总结这点在XP中没有被强调也不是这个过程的组成部分尽管XP建议经常性的回顾应作为XP的实践准则之一5敏捷型方法好几个方法都可以归入敏捷型旗下它们有许多的共同特征但也有一些重要的不同之处在此简短的综述中我不可能列出这些过程所有的特点但至少我可以告诉你可以到什么地方去查找更详细的材料对大多数这些方法我都没有深入的实际经验我有很多工作是基于XP的也对RUP有些经验但是对其他方法来说我的知识主要是来自书本当然这是很不够的51XPExtremeProgramming－－极端编程在所有的敏捷型方法中XP是最为引人瞩目的部分原因是因为XP的领军人物们的卓越能力特别是KentBeck他能够把人们吸引到这种方法来并一直处于领先地位但是XP热也带来了一个问题就是它把其他一些方法和它们非常有价值的思想给挤了出去XP根源于Smalltalk圈子特别是KentBeck和WardCunningham在80年代末的密切合作90年代初他们在一系列项目上的实践深化扩展了他们关于软件开发应是适配性的应以人为中心思想从非正式的探索性的实践到形成系统化的正规方法的关键一步是在1996年春Kent被邀对Chrysler的一个工资管理项目C3的开发进度进行审核该项目由一个签约公司用Smalltalk开发正处于困境之中由于源码质量低劣Kent建议推倒重来该项目然后在他的领导下从头开始并成了早期XP的旗舰和培训基地C3的第一期系统在1997年初投