我们都知道,人对于世界的认识是一主观活动,它受到各U因素的影响Q得我们不能够一下子Ҏ要认知的事物有一个清晰的了解。具体到软g开发中来,我们会发玎ͼ你很隑֜开发之前弄清楚客户所有的需求。一斚wQ客户对自己惌什么可能ƈ没有一个明的xQ这好比在买衣服的时候,我们在专卖店里看C个衣服,会觉得自qh很帅Q但是你仍然需要把它真实的I在w上才能看到实际效果Q而在你看到这件衣服之前,你能够仅仅凭着惌在脑里ȝ件衣服的样子么?
其次QY件工业中我们讲究的是投入和出比QY件业的成本主要是人力资源的成本。这也是软g目Ҏ间特别敏感的原因。时间比计划廉一个月Q对于一个数十h的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软g是完无~的呢?于是很多时候我们必d已经开发的部分q行修正Q而修正就需要时间?/SPAN> 传统的开发方式下Q很多Y仉目都是在匆忙交付后发现用户不满意Q于是l修正,再次引发用户的不满意Q再ơ修正,在这样反复地拖g中,客户和Y件开发商都筋疲力?/SPAN>
我们需要P代开发,是因为我们深知对事物的认知就是一个探索的q程QY件开发也是一栗在温博根{探索需?/SPAN>---设计前的质量》一书中提到Q?/SPAN>
国W?/SPAN>34Lȝ艾森豪威上曾l说q,"计划本n什么都不是Q而编制计划的q程是一?/SPAN>"。我们认同这L说法Qƈ把它推广到需求过E:
产品什么都不是Q而开发的q程是一切?/B>
或用另一U方式表达:
发现什么都不是Q而发现过E(探烦q程Q就是一切?SPAN lang=EN-US>
软g目本n的意义就在于和用户一h索他们真正需要的东西q且帮助他们实现。而这U探索,如同在第一D中我们阐述的那P需要不断的反复Q如果我们没有做好P代和反复的准备,而是希望一ơ性的把所有工作都做完q且q做得非常好Q结果可能恰恰相反?/SPAN>
我们需要P代开发,是因为我们追求Y件质量的最大化。没有h可以刉出完美无缺的东西,但是我们可以通过不断的检查和反馈Q得那些不适合的东西在早期被暴露出来,q代l予了我们这样一U检查合反馈的机Ӟ让我们不必在事情l束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物?/FONT>
事实上在业界QP代开发的观念早已l深入h心,然而有多少团队在正地实施着q代Ҏ呢?有多团队通过q代得到了他们想要的东西呢?很多人简单的把P代理解ؓ开发的分阶D进行。我们常常看到有目l理们这栯Q我们打通过4ơP代完成Y件的开发,W一ơP代,完成需求分析和软g设计Q第二次q代Q完成多多模块的开发,W三ơ,完成其他多少模块的开发,W四ơ,配置Q部|Ԍ上线Q测试,修正软gbug。虽然我们言必称“P代”,但是q样的P代和q去传统的瀑布型开发有多少区别Q我们又能够从这L伪P代中得到什么好处呢Q?/SPAN>
在本文以下部分将对P代开发实践中几个关键斚wq行阐述Q这几个斚w我们概括Z下关键词Q?B style="mso-bidi-font-weight: normal">变化Q周期,目标Q反馈,合作?/FONT>
q代思想带给我们最重要的一个启C,是要适应变化Q要U极、主动地拥抱变化而不是拒l变?/SPAN>?/SPAN>
在过ȝ开发中Q我们常怼拒绝变化Q以需求分析工作ؓ例,有些目l在需求分析完成后会要求用L字,{到交付Ӟ如果客户有什么意见,他们׃拿出那䆾客户已经{֭L的文件来理直气壮地说Q这是你们签字过的东西,我们做的N不是和这里所说的一样么Q?/FONT>
是的Q开发出来的可能是和需求定义文件的内容一LQ但问题是:q䆾需求定义文件上描述的内Ҏ不是真正能够帮客户实现自q价值呢Q难道我们进行Y件开发的目的是让客户在一份他们根本不清楚有什么意义的文g上签字,然后用这个来反驳用户?B style="mso-bidi-font-weight: normal">真正需?/SPAN>么?我们在Y件立之前L会告诉用Pq个卛_开发的软g会帮助他们如何如何。我们有什么理׃ؓ我们做不到这一点而理直气壮地责备客户呢?客户亲笔{的需求文档难道不是我们整理出来ƈ且讲解给他们听的么?
如果一个Y仉目的目标是帮助客户实现某一斚w的增|但是q种增值的目的q没有达刎ͼ我们可以认个Y仉目是p|的。即使Y件厂商通过q个目辑ֈ了盈利的目的Q满腹牢骚的客户也会把自q意见传播出去。而如果Y件厂商认U事情是天经C的话Q那么它在以后的软g目中也很难帮助自己的客户实C们想要的价倹{?/FONT>
我们必须让自己具有适应变化的能力。因U变化是客户需要的Q因U变化能够让软g更能体现q价倹{我q不是说应该无条件地接受q种变化Q但是我们可以在事前p些问题和客户q行充分的讨论和沟通,让他们明白,世界L变化的,需求本w可能会变化Q而这U变化需要h力和物力的支持。让客户也能够适应自n的变化,q是非常重要的?/FONT>
软g开发中的每个h都应该对变化有着充分的准备。从事Y件业的h大都充满了自信,pȝ分析师会认ؓ自己可以把所有的需求搞清楚Q设计和开发h员会觉得他们做出来的东西完美地实C需求。所以,如果我们对一个开发h员说Q某某,你过d的这个模块不能用了,我们现在需要重新做P通常我们会得到积极或者消极地抵制?/FONT>
应该让h们认识到Q变化ƈ不是对过d作的否定Q而是着g未来Q工作更加完善的必要手Dc无论是需求,设计q是E序代码Q你不可能一ơ性就把它们做到完,而只能通过不断的修正,让它近于完。这个过E就是所谓的?B style="mso-bidi-font-weight: normal">重构”?/FONT>
有些团队Z保持开发的E_性,?/SPAN> “冻l需求”。所谓的ȝQ也是说在一D|间内要客h代表承诺不对已经开发中的需求进行变动。如果你打算做这件事情,首先必须意识刎ͼ需求本w就是需求,它是不会因ؓ一个承诺就真正地“冻l”了。如果目前的需求定义ƈ不能反映用户真正的愿景,在冻l的周期q去以后我们仍然需要对已经做完的工作进行修攏V当Ӟ如果需求变化太频繁Q在某些时候有必要寚w求进行冻l以便让开发更加^EI同时也给软g开发者和客户一个反思的旉。但如果是需求分析工作方法有误,那就有必要作一些检讨了?/SPAN>
要适应变化Q我们需要让客户和开发团队有心理上的准备Q从而能够以认真的态度来对待它。还需要有正确的方法来应对变化Q比如对变化的成本估,效果的跟t,如何快速有效的对各U变化进行反映等Q这是我们必L意的问题?/SPAN>
很多人简单的把P代理解ؓ开发的分阶D进行。有些项目经理会q样_我们打算通过4ơP代完成Y件的开发,W一ơP代,完成需求分析和软g设计Q第二次q代Q完成多多模块的开发,W三ơ,完成其他多少模块的开发,W四ơ,配置Q部|Ԍ上线Q测试,修正软gbug。在q里Q虽然他们言必称“P代”,但是q样的P代和q去传统的瀑布型开发有多少区别Q?/SPAN>
q代开发是要分周期分阶D地q行Q但是不能认为简单地把开发周期划分ؓ几个不同的阶D就是P代?/FONT>
很多人对于P代周期有一些误解,比如Q?/SPAN>
n 认ؓq代只适用于开发阶D,而需求分析和设计工作则不在此范围内?/FONT>
n 认ؓq代周期可以拉得很长Q比如两个月Q三个月Q甚至一个季度,半年?/FONT>
n 需求分析,设计Q开发,试Q部|Ԍ用户反馈Q修改当作完整的q代周期Qƈ要求在前一阶段工作完全Q或者大部分Q完成以后再q行下一步工作(q代Q?/FONT>
在一个P代周期内Q我们可以做什么事情呢Q可以说Q所有的事情。如果你认ؓq代需要在需求分析完成之后才能开始,或者系l集成必d所有P代完成之后才可以q行Q你会获得一个真正的瀑布程开发?/FONT>
一个P代周期意味着对一些特定功能(用例Q的探烦。“探索”一词可能随情况不同而有不同的含义。对于抽象别较高,模糊E度比较高的用例Q我们需要通过和用L讨论它逐渐分解为更加清楚和清晰的用例。对于目前我们认为已l得C详细定义的需求,需要选取合适的部分q行设计和实玎ͼ通过q些部分的实玎ͼ寚w求定义和技术可行性进行反馈。对那些在上ơP代中已经开发完的模块,应该可能快速地让用hZ们的意见Q以便了解是否真正解决了用户面的问题,以及q有没有可以改进的方面,再根据这些意见安排下一阶段的工作?/FONT>
我们是否可以在开发进行之前把需求或者设计全部弄清楚呢?我认为很难。因为通常来讲Q用户对于自q需求只有一个模p的概念。让我们假设一个饮食业的例子,有一天餐厅经理把你叫入办公室_马上设计一个新的菜谱,q个菜谱是ؓ某某特定人群定制的,你要让这些h感觉色香味俱全。不q在你把配料和烹调方法都设计出来之前Q我们不打算让大厨来具体做这道菜Q我们不允许p|Q所以你的设计一定要一ơ成功,你可以用调查问卷Q用户面谈等Ҏ获取最l用L需求,但是CQ你不能dq道菜?/FONT>
q样的事情你可能会觉得很滑稽Q但是在软g业,cM的事情h们却认ؓ是天l地义的?/SPAN>
q代允许我们开发本w也作ؓ需求探索的一部分Q通过用户对已l实现功能的反馈我们和用户都会逐渐明白什么样的Y件是我们最l想要开发的。所以,不要{到所有(或者大部分Q的分析完了才开始开发,而是早对已l捕获到的需求进行细化,早开发,以获得反馈?/SPAN>
在安排P代计划时Q应该指明,q次q代的目标是什么,在结束时应达到的里程是什么。如果有d提前辑ֈ了这个里E碑Q我们可以提前结束P代,或者顺便在剩下的时间内安排其他的Q务,但是要注意这U安排的合理性,不要因ؓq个而得P代周期被廉?/FONT>
在一ơP代到达所讑֮的结束日期时Q就必须审视各项d是否辑ֈ了里E碑的要求,如果有Q务没有达刎ͼ原因是什么,我们是否需要对需求和技术方案做整。对于没有达到里E碑要求的Q务,我们可以采取的办法有两种Q?/SPAN>
n 剩余的工作列入下一ơP代计划中去,
n 本ơP代的l束旉向后延迟Q等待Q务的完成
前一U办法适合于有很大工作量没有完成的情况Q这可能也同时说明计划的制定有问题,在制定下ơP代计划时应该考虑对Q务完成时间进行调整。后一U办法适合剩余工作量不是很大的情况?/FONT>
通常来说Q一ơP代完成以后应该有一个品的新版本可用。这也就意味着Q将集成和发布分散到每次q代中去。借助于一些自动化工具Q比?/SPAN>antQ,我们甚至可以做到每日构徏?/SPAN>
一个P代周期应该有多长呢?qƈ没有一个统一的说法,而是应该视目标和可用的资源而定。但是,q代周期不宜q长Q也不宜q短。P代周期过长的话,会g~反馈的旉Q可能将许多问题隐藏或是堆积了v来。P代周期过短,会让n心疲劻I事情难有大的成效。一般来_q代周期应该?/SPAN>2-6周之间。如果安排的q代周期过了两个月Q你可能必d视一下P代计划的合理性了?/SPAN>
不要认ؓ下一ơP代应该和上次q代的时间差不多Q刻板地把所有P代规定一个统一的时间是一个很坏的做法。但是你可以把以前P代周期中的工作效率作Z下ơP代时间的一个依据?/FONT>
一ơP代必L明确的目标:我们希望通过q次q代辑ֈ什么目的。在制定目标Ӟ应该同时考虑另外一个问题:如何查该目标是否已经达成。这是所谓的“里E碑”?/FONT>
q代计划必须有明而可行的目标。明的意思是它应该是可度?/B>的,不能太模p,因ؓ你很难检查一个模p的目标是否达成。比如,我们可以_q次q代的目标是?/SPAN>xxx斚w的需求作q一步细化和评审Q完?/SPAN>xxx模块的开发以加入到Y件的下一版本中去。这L目标是明而且可行的。反q来Q如果我们这栯Q我们要通过和用L讨论明确l大部分愿景Q同时要有一个初步的开发。“绝大部分”和“初步”这L词让人感到困惑:多少是绝大部分呢Q在总量未明确的前提下Q怎么能够知道完成的确是“绝大部分”而不是“一部分”?“初步的开发”似乎告诉我们这ơ开发量比较,但是具体开发哪个部分,或者开发到什么程度,q没有指Z个明的概念?/SPAN>
由此产生了一个困惑,软g目是一个不断探索的q程Q我们怎么能够明确地对未来的事情作安排呢?譬如在项目初始调查用h景时Qؓ了实现“明”的目标Q是否这样定义Q务:完成20%的用h景调查?
很显Ӟ用户愿景总量到底有多我们ƈ不知道,所以在q次q代完成以后如果我们问:是否真的完成?/SPAN>20%而不?/SPAN>15%Q很隑־到答案?/SPAN>
Z避免出现q种情况Q你必须换个角度来看问题Q比如我们可以说Q对xxx部门?/SPAN>yyy部门的用户做愿景调查。在q代完成后,可以查是否这两个部门所有用L访谈Q调查都已经完成Q是否这些部门每个h都认p达了全部的意思?/SPAN>
所以,如果你发现很隑֯制定的目标进行度量,那么换一个角度来看事情吧Q你可能׃扑ֈ一个合适的表达方式。如果你从所有的角度都看不到事情是可以度量的Q那么这可能意味着qg事情可能q没有到应该d施的地步Q这时你应该把它从P代计划中L。对于这U情况,有h可能会说Q那我们q次q代可做的事情就很少了,如果真是q样Q那p行一ơ小的P代吧Q可能把q次q代的工作做完了以后׃有更多的工作可以安排了?/FONT>
有些目l理在日E表上,很详l地写着Q第一ơP代,某月某日到某月某日,W二ơP代:某月某日到某月某日,W三ơP代。。。这L做法是不恰当的。因为它假设了后面几ơP代的d量,但是实际上,在前面的工作完成之前Q你很难对以后的工作得到一个明地概念。而且在这L计划上,可能q没有用于测量P代成果的里程,q样的P代最后很可能会演变成为瀑布式的开发。所以,在一ơP代完成之前,不要Ҏ着去计划下ơP代,特别是不要试囄定义下ơP代的旉Q因Zq下ơP代要做什么都q不清楚?/FONT>
Z么目标的可度量性这么重要呢Q在团队开发中Q很多信息因Zh与h的交不畅而无法得到正地反馈Q这让我们没有办法实时地掌握目的进展情况,退而求其次Q我们必阶D|地了解q些信息。如果目标难以度量,q代l束后我们很难明到底有哪些工作没有完成Q也无法看C情的问题所在?/FONT>
有些团队中会要求每个成员每天对自q工作q度以百分比的Ş式做汇报Q他们以为通过q样的方式可以确实的掌握事情的进展,但实际上q不行,因ؓ软g开发中存在很多不确定因素,有时候我们认Z情已l完成了一大半Q但是可能因为技术或者其他的原因发现q一大半工作方向是错的,q时候就要推倒重来,而且Z在汇报工作量的时候L会有一些感情的因素在里面,q就佉K些看似精的癑ֈ比打了个折扣?/FONT>
所以,我们需要更加实际和l致地划分工作,对目标的完成情况q行度量。这也是q代周期不能太长的一个原因:如果你把大量有前后关联的工作划分入一个P代周期,在设定的l束到来ӞH然发现只完成了一部分,q时候虽然亡补牢仍然可以,但是中间费了大量的人力和物力?/FONT>
一个男人在大街上走着Q他q没有发现裤子上的拉铑ַl松开了,虽然看到q个情况的h有很多,但他们有各种各样的担心,比如不想多管闲事Q怕让那个男h隑֠Q或者干脆就是想看笑话。结果就是这个hl箋I着一条敞开拉链的裤子在大街上行走?/FONT>
qg事情臛_带给我们两个启示Q?/SPAN>1Q得到反馈是重要的;2Q要惛_到正的Q有价值的反馈Q你需要其他h的配合?/SPAN>
对于用户需求来_没有用户及时地反馈,我们可能把那些不符合需求的开发l下去,׃软g中各U功能和模块的依赖性,q种不符合最后可能被攑֤到数倍。越q得到反馈,问题可能p大?/FONT>
软g开发中一个很重要的概忉|“可行性”和“合理性”,无论我们做需求,设计q是开发,集成Q测试,都会遇到q两个问题。有些事情的可行性和合理性是我们可以通过事前的分析进行判断的Q但是有些问题就必须有一定的实践作ؓ基础。这也是一个反馈的问题。譬如说在某目中技术架构师军_采取一个技术架构,但是l过一些阶D늚开发发现它有一些技术上问题不能实现用户的关键需求,q时候就必须攑ּ它?/FONT>
“反馈”意味着两个意思,对一件事情的调查和根据调查做出决{?/SPAN>
在意识到反馈的重要性之后,你会要求所有的人都对P代的成果做出反馈。可能存在的问题是,是不是所有的人都意识C反馈的重要性ƈ且认真地d了呢Q如果客戯Z们只需要对q代出来的品“看看而已”,那么你就很难了解他们一些深层次的想法。再比如一ơP代中某些模块开发的q度比较慢,开发h员可能会抱怨技术方案不能满求,而实际的原因可能是设计不合理或者根本就是有人没有认真工作?/FONT>
中国国家队前Ll米卢曾l说q“态度军_一切”,反馈作ؓq代开发中臛_重要的一个方面,必须得到_的重视?/FONT>
获得反馈的方式和对于反馈信息的分析是另外一个重要的斚w。一般来ԌҎ软g开发角色的不同Q我们非常关注的是两cMh的反馈:目l之外的客户和项目组之内的各U实施h员?/FONT>
软g目一般都会要求客h安排专门的业务h员进行配合,在P代开发中Q这U配合不只是q行需求的整理和发掘,q包括对已经完成软g版本的评。在q个q程中应该有需求分析师的配合?/FONT>
在每ơP代完成之后,软g目l应该有一些ȝ和分析活动。通过q些ȝ和分析,扑ֈ做得好和做得不好的方面?/FONT>
在非q代式的开发中Q也有反馈的环节。比如通常在Y件交付阶D会有一个试用期让用h出意见。而Y件团队在各种开发中都会有一些ȝzd。P代式开发的独特之处在于量早地引入反馈机制Q得反馈机制更加制度化Qƈ且,更加快速和灉|地分析这些反馈,把得到的l论应用C一阶段的开发中厅R?/FONT>
对于一些机制引L问题Q比如组l结构不合理Q角色分配不明确之类。最好有一个明的问题记录表。在每次q代完成以后这些问题记录下来,同时在下ơP代中努力改善它。如果相同的问题q箋出现在几ơP代中Q可能就说明目理Z问题?/FONT>
软g团队中的合作是h们一直都在提倡的。我们在q里提到“合作”的意思ƈ不只包含团队内部的协作,q包括和客户的合作?/FONT>
q代开发需要快速反应,q需要各U不通角色h员的配合。如果h们做事情L拖拖拉拉Q就会g~Y仉目的q度。而且每个人对自己在P代中应该做什么事情必d清楚Q这需要事前的准备和角色的合理分配?/FONT>
q代需要用L配合Q实际上最好能够有客户?B style="mso-bidi-font-weight: normal">真正的系l用?/B>参加到P代过E中来,因ؓ他们是最有发a权的。很多项目中会让目l理或是pȝ分析师担当客户代表的角色Q这样做有很多弊病。有时出于各U原因客L实不能到现场配合的,我们也可以通过其他的途径获得客户反馈。比如一个阶DP代完成以后,可以把相x作用截屏加文字说明的方式发给客户Q让他们对品有一个直观的印象?/FONT>
Z让团队能够有效快速地配合Q应该尽可能使用各种自动化工?/SPAN>。比如自动化试理工具Q以及配|管理,集成以及发布之类的工兗通过对这些工L有效应用Q得各个成员能够快速获得信息?/SPAN>
q代开发要拥抱变化Q主动适应变化。要让每个参与者都认识到这一点:不能够固步自,或者满于现有的成,不去思考可改进的地斏V从理者的角度上,必须重视每一个反馈信息?/FONT>
q代开发追求对d的度量。很多组l会把这U度量和员工的W效考评联系h。这U做法可能是合适的Q但是如果只是简单衡量工作量或者工作完成速度和质量,有可能会比较片面。毕竟Y件开发是一个环环相扣的q程Q表面上来看q个环节处理不好Q实际上可能是准备工作做得不好,或者其他h的配合不好?/FONT>
所以如果在q代q程中出C问题Q一定要客观地分析,特别是应该挖掘导致这些问题出现的深层ơ原因。譬如在一ơP代中试人员发现了一?/SPAN>bugQ但是两ơP代过MQ这?/SPAN>bug仍然存在Q这p明对bug的处理不够迅速(当然如果因ؓ某些原因q些事情被故意推q了的情况不)。这时就必须分析一下到底是什么原因造成了信息的不通畅。而不能简单地批评相关责Q人?/SPAN>
本文对P代开发的五个关键Q变化,周期Q目标,反馈Q合作)斚wq行了讨论。作ZU方法论QP代开发的好处在于它软g团队变得更加灉|。在实施q代开发的q程中,应注意不能流于Ş式化Q切实做好每个环节的工作Q这h能获得满意的l果?/FONT>
Email:jayliu@mail.csdn.net