敏捷与精益Word文档格式.docx
- 文档编号:21739827
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:18
- 大小:166.26KB
敏捷与精益Word文档格式.docx
《敏捷与精益Word文档格式.docx》由会员分享,可在线阅读,更多相关《敏捷与精益Word文档格式.docx(18页珍藏版)》请在冰豆网上搜索。
重新制定关键项目的计划并接受延期发布,或者将新需求推迟到下次软件发布才完成。
精益管理模式下敏捷开发过程则提供了一个诱人的替代方案:
软件系统总是被持续地交付,并且在这种开发过程下改变需求的代价也很合理。
这是通过如下三个主要的技术来实现:
∙关注软件持续生产的新的软件生产技术。
这些技术被统称为“敏捷”。
它们的一个关键特性是更容易适应变化,并且最小化对任何以后可能会被废弃的大型的设计或架构所做的投资。
这些技术极大地减少了产品上市所需要的时间。
∙管理软件持续生产和发布的软件开发管理过程。
精益管理就提供了这样的一种管理过程。
精益管理来自于制造业,早期被称为JIT(Just-In-Time)。
精益管理关注反馈周期以及利用不同训练等级的工作者来更快速地交付更高质量的产品。
一般而言,精益管理过程能够降低50%的制造成本,降低事务性流程(订单处理)90%的成本。
∙将(几乎)所有的重复劳动自动化,包括软件产品的生产、测试和集成。
把计算机的能力应用到这些事情上缩短了反馈周期并让工作者把精力放在生产性任务上。
比如在传统开发过程中,可能一个月也就把所有软件模块集成一两次,但是在敏捷项目中,这样的构建过程每天都要做很多很多次。
敏捷/精益过程所产生的影响的早期结果是极具震撼性的。
人们分析了一系列的敏捷项目,其结果表明,产品上市时间平均减少了69%,成本降低了57%,工作量降低了62%。
此外,质量也同样令人印象深刻:
致命缺陷平均减少了80%,普通缺陷减少了60%。
这些结果与精益管理过程取代传统方式方法时所取得的进步是一致的。
结果是如此令人振奋,或许大多数人会认为敏捷方法应该被广泛采用了。
敏捷/精益过程需要引入完全不同于瀑布模型的组织结构和运作方式:
∙瀑布模型中的进度是分阶段标记在甘特图上的;
而敏捷中的进度则是通过当前实际开发的软件来度量的。
∙瀑布模型的管理关注最大化每个工作者的生产力;
精益管理则关注优化整个过程的产出。
∙在瀑布式过程中,发现问题的办法通常是在过程中添加额外的检查或权衡;
而在精益管理中,问题是通过缩短反馈周期或者去除冗余步骤来发现的。
∙瀑布模型鼓励发展出超级专家(比如,WebUI架构师);
但是精益管理推崇能有效率地完成多种任务的工作者,在不同任务之间来回移动以优化整体产出。
∙瀑布模型鼓励创建和管理专业化的部门,每个部门负责流程一个阶段的所有工作;
敏捷/精益管理则鼓励创建跨技能领域的工作环境,让所有工作者都可以在其中学习所有必要的技能。
那么,如果敏捷/精益管理是那么好,它不是应该在很久之前就该被采用了吗?
瀑布模型方法论在今天就不应该占据主导地位了。
有几个主要原因导致了为什么敏捷/精益管理没有在几十年前出现:
∙技术――支持敏捷的软件开发技术和语言直到近十年(Java,C#)才出现。
制造业的JIT式生产过程还没有往其它领域移植。
让过程自动化的大型处理能力还不存在或者因为太昂贵而在应用上受到限制。
∙应用软件自身的特性――大型应用软件的规模每十年就会增大十倍。
大型公司所需要的软件,其代码行数已经超过了一亿行,随之而来的复杂性逐渐达到了现有软件开发过程能够控制的极限。
要对这样的庞然大物做出一些改变,瀑布式开发过程就完全无能为力了。
∙市场――新兴的全球市场如雨后春笋般涌现出来,而只有具备迅速反应能力的组织才能抓住机会以避免被淹没在竞争者中。
(例如:
体育新闻现在是已经成为一种实时服务了,这是报纸所达不到的;
机场的签入和坐位的选择在旅行者到达机场之前就可以完成了。
)业务,特别是大型业务,必须对稍纵即逝的机会作出迅速反应,否则就会失去重要的新收入来源。
从瀑布模型转移到敏捷/精益管理的影响是重大而深远的。
这种改变需要时间,特别是对于那些瀑布式分阶段的组织关系根深蒂固的组织而言。
但是正如通用汽车公司的麻烦是源自丰田在二战之后的那段时间所发明JIT式生产过程,这种改变是不可避免的。
因为它们自身令人窒息的组织结构而不采用敏捷/精益管理的印度企业,会在将来面对世界上那些今天采用了敏捷/精益管理方法的公司的猛烈竞争,并且可能会陷入与通用公司所面临的相似危机。
那么中国应该追求并仿效包括印度的软件公司吗?
包括它们的组织结构和做事方式也照搬过来?
我们的建议是“不”。
相反,正在日益发展壮大的中国软件公司应该拥抱敏捷开发方法,精益管理的做事方式,以及一种不同于以往的软件开发者能力模型。
通过这个方式,这些采用了敏捷与精益的公司将有能力更快速地交付低成本、高客户满意度的软件产品。
这样的公司将有能力在市场上积极地显示其与众不同。
这也就指出了一条恰当的同印度软件公司竞争的道路。
起初……
二十世纪六十年代到七十年代,大型程序不过区区千行代码。
一个好的程序员就能设计和编写整个程序。
当程序变得越来越大时(操作系统就是最早这样的程序),就需要好几个程序员一起来开发程序。
这种更大一些的程序的交付变得非常的难以预料。
软件就像建桥
大型公司对这些早期系统无法预测的延期行为非常烦恼。
于是由他们那些具有机械和土木工程背景的开发执行人提出了解决方案:
像建设桥梁那样来编写软件。
他们建议使用工程学的原则来构建软件,并因此催生了软件工程的“瀑布式”方法。
图例1–像建设桥梁那样构建软件
方法成功了。
软件交付变得可预测了。
越来越大的系统和应用程序被成功地构建出来。
但是同时也有很多是失败的。
并且即便成功交付了,系统和应用也往往不是客户真正所需要的。
如果你把这些客户不满意的案例考虑进去,失败率是高得惊人的,大约三个项目中就有两个是失败的。
要理解这些失败背后的原因,就必须去观察程序开发环境本身。
打个比方来说就是,需求总是像“雨”一样下个不停。
这些需求可能是对竞争对手的反击,可能是尝试采用新的技术,或者干脆是仅仅有了更好的主意。
为了使用分阶段瀑布式的方式来开发,必须保护过程不被需求变更一炮接一炮地打中。
接着上面的比喻来说,你必须搭一个棚子来使得过程不会受到持续改变的影响,如下图所示:
图例2–开发中需求总是如“雨”一样下个不停的
当开发在保护伞下不受需求变更的影响不断向前进的同时,这些“雨水”也被储积了起来,等着发布的将是一场大洪水。
确实,可能这就是真正的“瀑布”。
因此,项目持续时间越长,失败的可能就越大。
软件开发项目的高失败率(三分之二)也就不那么令人惊讶了。
降低失败率
软件项目居高不下的失败率孕育出了新的产业。
它们致力于对瀑布流程提供严格的控制。
CASE(计算机辅助软件工程,Computer-AidedSoftwareEngineering)工具应运而生。
这些工具基于以下前提:
更加严格的获得流程中每一个阶段的信息;
通过审查这些时期产生的文档来保证准确度;
只有当缺陷被解决时才继续进行开发。
CASE工具很昂贵,很多开价高达每个程序员数千美元。
浪费是显而易见的,因为大规模的开发团队通常会毫不犹豫地采用这些工具。
一旦这些工具被部署,公司或者团队就开始忐忑不安地期待这些工具所带来的高生产力以及项目成功。
经过统计之后,成功率被计算出来,遗憾的是看起来每三个项目中仍然有两个项目失败。
毫无变化!
很快这些工具被废弃,那些大量生产这种工具的小公司由于业务原因被迫关门,或者以很低的价格被收购。
这个时候,很多公司回到他们最初的瀑布模型。
另一些,对瀑布模型低成功率已经不抱什么希望,彻底放弃了正式流程。
很快,当失败率开始接近100%的时候,这些团队不得不恢复部分流程。
后来,CMM因为它给出了提高交付成功率的办法而大受青睐。
CMM注重过程本身、其度量标准以及重复性。
CMM大力鼓吹只要把CMM的原则应用到瀑布式过程中去就可以改善软件项目的交付状况。
从某种意义上说,CMM确实让交付变得更加可以预测,并且在某些特定情况下,一些变更造成的影响也变得更加可预测。
但对于客户满意度是否提高了则还很难说。
仍然频繁出现的是,交付的应用并不是客户真正想要的。
印度软件产业
印度软件产业出现有几点原因:
∙英语技能
∙新兴的呼叫中心业务
∙有吸引力的全球劳动力价格
∙专注工程实践,将毕业生与行业直接挂钩的教育系统
∙在印度,个人声望与是否在大公司工作、职位是否重要相关
似乎是与西方的价值观“高质量就意味着高价格”相背离,印度软件提供商最早最积极地采纳软件过程标准。
他们让市场认为CMMi特别是CMM5,意味着能够可靠可预测地交付高质量的商业软件。
那些已经被劳动力价格诱惑得蠢蠢欲动的西方买家,很快就接受了CMM、高质量、可预测这些信息。
软件开发工作以惊人的价格潮水般地涌入印度,这使得印度软件公司很快成为应用开发,应用维护、系统集成与运营等与软件相关的各方面的主角。
影响是如此深远,以至于所有的大公司都迅速在印度开设部门。
印度软件公司是流程方面的天才。
他们采用了6-Sigma实践,并且十分关注评估和持续改进现有流程。
流程的主管直接向公司的最高层汇报。
这些公司甚至在销售和签约合同阶段都有流程模型。
在软件产业,劳动力模型定义了具体的职业发展路线。
工作直接与瀑布式过程中的阶段相关联。
公司内的升迁就是沿着这些阶段往上爬,直到最后的管理层。
以下的因素造就了这些印度大型软件公司的强大的竞争力:
∙明确定义过程
∙如饥似渴般地对过程持续改进(6-Sigma的根本)
∙规划明确的职业生涯吸引着越来越多的当地劳动力
不满的根源
按阶段方式定义流程(瀑布模型)的根本在于一个假设,即客户知道他们将来需要什么。
参考图例2,客户必须在分析阶段就决定具体功能的内容。
这个决定就是一个猜测,它会继续为项目持续实践不断产生需求。
在项目的某些点,客户可能会感到对变更的需求非常强烈(单个需求或者所有小变更的集合),以至于需要项目必须适应这些变更。
客户能做的选择少得可怜:
交付时间延期,付更多的费用;
或者开始考虑第二个版本。
这些选择精确地反映了开发团队的现实。
为了将变更放到这个版本中,他们需要了解这些变动对已有工作造成的影响。
这些变动将会给分析阶段的需求造成哪些影响呢?
它们会如何影响已经精心设计的架构和设计呢?
已有代码对这些新的变更能否兼容?
我们拿建设桥梁打的比方比最初设想得还要精确.建桥所用的过程是为建设一个坚固耐用的产品而设计的。
这种产品一旦建好就能用很多年。
但对于重要的软件而言,一旦当前版本完成,它就需要改变。
因此,对于那些建立在工程学原理之上的软件过程方法不能很快地适应变化就毫不令人惊讶了。
因为适应变化根本就不是其关注的东西。
解决方案的本质
瀑布方法的问题,即无法预测未来,早在二十世纪七十年代晚期就被人们认识到了。
人们提出了许多解决方案,但多数都类似于下面描述的这种方案。
图例3-螺旋模型
在螺旋模型、开发周期一直很短。
有机会停下来,研究研究天气、调整下内容,然后继续开发下去。
这样解决问题吗?
不幸的是,交付的问题并没有消失。
模型的第一周期的会进行得不错。
当下一部分需求被考虑的时候,开发小组发现自己已经身陷困境。
第二阶段新的需求并不适合第一阶段对系统的设计。
的确,看起来最好的解决办法是重写应用。
这肯定是项目的投资人不想听到的。
小的逐渐增加的成本和快速反应市场需求的承诺很快便烟消云散了。
虽然很不情愿,大多数螺旋模型的倡导者和支持者还是回到了瀑布式过程。
印度公司所面临的冲击
印度公司遭受了客户事后的强烈反感。
交付是更可预见了,但客户的反响却不那么好。
有时软件符合规定的要求了,并且也按时交货,但客户却不满意。
因为交付的软件并不符合客户当前的需求。
然而,CMM5过程的严格确保了客户的不满完全是客户自己的责任。
交付的软件做到了合同中规定的一切。
有时客户意识到需要改变需求,并且要求印度公司适应这些改变。
CMM5定义了一个变更需求的过程来评估相应的花费和工期上的影响。
费用经常使客户犹豫,他们并不理解重新审查并修改架构和设计所带来的成本。
新的西方买家逐渐开始讽刺CMM,这反映在CMM新的定义上:
CostsMoreMoney(花更多的钱)。
除了越来越多不满意的客户,印度软件公司还有更多其他的挑战:
∙大量人员更替。
大型印度公司实际会要求新进员工分期偿还他们的培训开支。
有些公司会以高薪水聘请竞争对手公司的员工。
刚开始还不错的项目,可能由于关键人员转移到新项目中,而接手的是没有经验的人员导致项目每况愈下。
∙有经验程序员的缺乏。
职业发展模型并不鼓励聪明的程序员一直做开发工作。
不但薪水少,而且职位声望也不如管理岗位。
事实上,有五年经验的程序员很可能是一个差劲的程序员。
∙过多的不合格程序员。
能提供中等收入的IT产业成为印度年轻人的首选职业。
出现在街头每个角落的技术学校满足了这个需求,但同时也降低了质量。
由于对程序员劳动力的需求是如此强烈,以至于那些没怎么认真培训的程序员们很快就出现在了二线软件公司的办公室里。
大公司会分包一些合同给这些公司。
而这些公司的程序员中大多数人对编程技能缺乏概念上的认识,并且永远不会在软件公司的职业发展路线中上升。
∙缺乏创新。
对流程是有创新,但在软件或者解决方案方面则乏善可陈。
问题的一部分原因是流程阻碍了程序员的成长。
另一部分原因是小心控制任务分配的管理风格使得交流只能在管理者之间进行。
还有一部分原因是在开发周期的早期就得做出重大的架构和设计方面的决定。
敏捷解决方案
敏捷成功实现了螺旋模型。
案例研究
举一个例子来说明这个改变。
在一个项目中,ThoughtWorks与印度一家大公司同时竞标。
这家印度公司是首批达到CMM5的公司之一,并且从那之后,大部分提案的核心都是围绕着CMM来做的。
ThoughtWorks则被邀请以敏捷的方式对同样的系统进行竞标。
印度公司提出以每小时28美金的人力费用,历时12个月,总共200万美金完成整个系统。
ThoughtWorks的混合劳力成本(包括美国和印度的价格)为每小时88美金,但ThoughtWorks能够只用8个月就完成整个系统。
在这个8个月里,ThoughtWorks将交付三个版本,其中第一个版本的交付只需短短的三个月。
最后,总投标额为110万美金。
由此可见,敏捷过程能够以更低廉的价格,更快地交付。
三倍于CMM5方案的每小时人力价格,敏捷方案却以一半的总价交付了整个系统。
敏捷过程是如何比世界上最好的CMM5公司的效率高四到六倍的呢?
适应变化
敏捷开发者采用灵活的工具和技术进行开发,他们更容易对程序进行改变。
与此相反,分阶段的方式发现问题更迟,使得修复问题的成本更高。
想象一下如果变更不会增加加班时间。
开发者会更自由的专注在手头的工作,几乎不会考虑未来需求的影响。
如果开发者不需要花费多余时间考虑下一个版本,这个版本将会被迅速的发布。
敏捷程序员常常利用面向对象编程技术达成容易改变的目标。
不要被Java或者C#迷惑使用这些技术。
在上面的案例中,一个遗留系统需要被取代Thetechnologystackofthelegacysystemwasidenticaltothatofthereplacementsystem。
更换的动机是旧的系统已经不能适应变化。
旧的系统有79个Java类(被建模实体)。
替换后的敏捷系统经统计有1400个Java类!
在新的系统中,一个新的需求影响了大约10-20个现有类。
但是其余的1380多个保持不变并继续工作。
这种风格的面向对象编程,在学校或者世界上的其他的什么地方很难教好。
它是一种风格,诞生自1970晚期的Smalltalk编程者。
实在是一种巧合,十年前同样的这群程序员开始了敏捷运动。
因此对于开发者的建议就是:
"
无视未来"
,避免出现在复杂项目中开发团队为了了解项目的整体或复杂的问题而争吵,从而导致”分析瘫痪”的僵局,这些事情花时间做就是一种浪费;
专注在手头的任务上;
所使用的技术能适应将来的任何改变。
精益管理模型
当在开发中采用了源于工程学的分阶段方法,项目经理们也会采用与项目的工程过程相关的项目管理实践。
绘制甘特图,分配任务并下达,跟踪项目进度。
但是敏捷过程是持续不断的生产软件。
如果一样使用甘特图对软件生产的每一部分都进行跟踪,敏捷过程需要的项目管理者比程序员还要多。
由此看来,敏捷方法需要一个管理模型,但是上述的工程模型好象不适合敏捷过程。
所以,敏捷过程就去制造业中寻找适合它的管理实践。
首选的制造管理过程是JIT(Just-In-Time,准时制生产),该过程现在也被称为精益制造。
精益制造开始是只是一个用于生产线管理的方法,由于精益制造如此行之有效,丰田在设计方法中也开始使用它了。
并且,精益方法没有停滞不前,它已经革命性的改变了制造业之外的其他商业领域。
精益方法所获得的广泛成功,提示我们应该用“制造软件就像制造汽车”的思路来代替以往的“建造软件就象修建一座桥梁”的思路。
文献中指出了精益方法的巨大影响:
能够提高制造作业效率50%以上,能为订单承接过程节约90%的成本,这实在令人惊愕。
在上述案例中所列举的各种资源节省很符合这些业务的需要。
在敏捷开发中,也可以考虑运用精益方法的相关原理。
反馈是质量之源
精益方法提倡关注反馈周期,提倡最小化事物从生产到被使用的时间最小化。
在这样的定义中,对设计进行评审就不是一种反馈,用代码实现设计才是真正的反馈。
在二十世纪七、八十年代(特别在美国),丰田汽车的质量之所以相对其它品牌有了一个彻底的飞跃,就直接是因为对反馈周期的关注。
我们会返回头讨论与软件生产相关的反馈周期。
而且,反馈是可以持续度量和提高生产周期的循环次数。
实际上,精益方法的关注点是从最大化个体的表现转移到优化整体生产能力。
通过对整体生产能力的关注,上文提到的种种节约就不言而喻。
识别和减少浪费
精益方法永远在寻找那些能被节约的时间和能被减少的步骤,缩短反馈周期。
精益方法鼓励对生产周期进行检查,调整,再检查。
这个过程不要停止,不要给生产周期贴上“标准”或者“已批准”的标签,使得对它的调整停滞下来。
为了找出在生产中发生的浪费,首先必须了解生产过程。
既然我们不是在制造汽车,我们必须认识到我们在制造什么。
在敏捷开发中,我们在实现特定的需求,这些需求经常被称为“故事(story)”。
所以,让我们来看看一个故事的“生命周期”。
图例3-故事的生命周期
故事首先被写成一个短语,被写在电子表格中或是其他形式的文档中。
这个短语是对故事准备做的事情的一个简略声明。
接下来叙述故事,也就是用一小段文档来描述需求的细节。
有些人把故事叙述比作是用例场景。
故事的叙述形式是多种多样的,而故事的测试计划也经常是在这一步完成的。
测试计划确定测试团队如何验证这个故事是正确的。
接下来是划分任务,故事被分解为多个任务,用于明确程序员需要完成的工作。
故事在规模上涵盖了一个很宽的范围,那么它的任务也要覆盖同样的范围。
此时,故事就可以拿来做开发了。
代码可以根据一个个的任务被写出来。
在编码工作完成之后,我们可以运行测试来确保需要的功能已被成功地实现了。
也许会发现Bug,如果发现了,就进行修正。
最后,故事被交给客户或是客户代表,进行最后的评审和验收。
了解了故事的生命周期,我们现在就能够找出浪费了。
我们的目标是最小化生产故事所花费的时间。
我们分析了一些敏捷项目,这些项目在10到12周内完成了从故事叙述,到开发完成并获得客户的批准的过程。
这让采用瀑布方法的人们看来是很不错的成绩。
但是在上面提到的那个案例的最后,我们从开始叙述故事到获得客户批准,平均花费的时间减少到了7天!
最容易识别的消耗是花在等待上的消耗。
每一步间的空闲时间是被算在整个周期中的。
看一个具体的例子,是关于编写故事叙述的。
在传统的方法(瀑布方法)中,要求在架构或设计之前,需要先有详细的规格说明。
在敏捷方法中,我们不会在故事叙述刚一完成,程序员还没有打算实现故事时就编写详细的规格说明。
这样可以更有效率:
∙业务分析师只是将用户的大致需求记在脑子里:
在他们头脑中的需求细节是最新鲜的。
这样做可以更好地与开发团队相互沟通,从而选择成本更低的实现方式。
∙由于有时,业务分析师碰巧不在,我们可写出简单写写故事的叙述就可以了,不需要面面俱到。
∙故事叙述是基于最新正在运营出来的系统,而不是建立在一个假想的系统之上,所以它能更精确。
∙在我们能肯定一定会实现这个故事之前,我们不会投入资源去叙述它。
在瀑布方法中,被仔仔细细编写出来的许多需求会由于成本或者时间的因素,不被开发,这就浪费了需求编写的时间。
这在测试和开发过程中也是一样的。
整体来看,关注于减少和消除浪费是敏捷方法能够高效工作的主要来源。
多面手强于专家
当丰田创立了JIT方法后,生产一辆汽车所需要的专家被大幅度减少。
丰田认为如果你可以拧上一个挡泥板,你就可以安装一个车门。
在敏捷方法特别关注了循环次数后,同样的现象也发生了。
敏捷方法通过以下做法受益匪浅:
引入既能够设计又能够编写代码的架构师,引入既能写故事也能为故事编写验收标准的业务分析师,引入在需要的时候能够协助他人的项目经理。
一个团队中如果有大约30%的人是多面手的话,就有能力通过调节团队每天的活动来适应生产需要。
考虑一下当今软件开发人员的头衔——业务分析师,架构师,设计师,程序员,测试工程师。
这些头衔其实反映的是他们在瀑布方法中的工作阶段!
进一步来说,对于在敏捷项目中的人员,这些可能不是正确工作头衔。
再论反馈
有了这样的背景,当进行一个敏捷项目时,我们可以看一看精益管理所提倡的反馈周期
∙频繁的发布——业务分析师认为他们知道用户的需要。
但是能真正验证它的是向客户提供软件并观察客户对它的使用。
∙迭代——故事被分成一个个小组,并被分配一小段一小段的时间来完成它们,这称为“迭代”。
由于软件是逐步被生产出来的,用迭代来划分阶段可以让项目经理度量生产速度。
敏捷项目的项目经理比那些使用瀑布方法的项目经理要更
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷