敏捷开发案例
最新在博客园看到一篇博文,介绍一个混乱小项目的敏捷应用,作者利用XP(极限编程)的最佳实践完成了近乎不可能完成的项目,由于没有博客园的账号,不能在原文留言,转过来供自己学习参考。
原文地址:http://www.cnblogs.com/meil/archive/2007/03/13/672530.html
原文内容如下:
我们假设一个project中有以下状况: (1)需求不明确,没有完整、详细的需求描述。用户没有提供标准的需求文档。 (2)技术架构明确要求为J2EE,要求使用:Struts,Tile,EJB,DAO,OJB,数据库为Oracle 8i/9i,集成开发工具要求为WSAD,系统有大量的计算,对性能有明确要求。 (3)团队人数为6人,三人为刚大学毕业的新人,对上述技术架构和开发工具不熟悉。另外3人均不能full time参与。其中项目SA只能参与第一周(5天)。 (4)交付时间特别急,要求3周就必须完成。但是交付物只需要:SRS(软件需求描述)、源代码/安装包、安装文档,不需要概要设计、详细设计等文档。 (5)项目规模不大,业务需求约为12个左右,其中有5个非常简单的需求(增加、删除、修改,没有特别的计算)
基于上述状况,不能根据大概判断就直接拒绝,首先进行了风险识别(实际的Risk Management Plan就不show了): (1)项目范围不明确,特别是不明确最终用户的需求。 (2)没有确立变更机制,没有SOW(Statement of Work) (3)没有明确的验收条件 (4)没有合适的标准软件过程、开发模式、生命周期适合本项目 (5)对于上述的技术架构没有经过验证和测试,特别是OJB。 (6)项目组对于上述技术(J2EE)要求没有足够的开发经验,有经验的SA时间不能保证。 (7)项目组对于客户指定的WSAD不熟悉 (8)测试服务器的性能可能不能满足测试要求 (9)关键资源(SA和另外2位)不能确认能够参与的时间 (10)Team为全新,之前都没有互相进行团队并行开发 识别风险后对每一个制定了应对计划。 做到这里,已经可以跟Manager汇报说不可能了...
然后基于项目需求分解WBS(Work BreakDown Structure),找来SA进行历时估算,对每一个UseCase估算其开发时间,当然按照有相关开发经验的人员来估算的。得到了总共Effort以及Price。 根据最终的交付时间回溯列出了一个Schedule,设置多个重要的Milestone。
回来来Review自己做的Project Plan,仔细看看Schedule,可能吗?别忘了,我们还不能周六周日加班,-_-。
不管如何,这是个混乱的项目,进度、资源、风险,各个方面都有大的问题,抱怨是解决不了问题的,还是脚踏实地做下去吧。
回过头来,该做的事情还得继续做下去: 第一步,控制需求(Scope)。客户不是没有需求描述吗?我们自己根据其提供的需求原始文档编写,同时做出需求的UI原型,我们不确定的地方都做为Assumption。提交给用户审核,不必要的功能通过谈判砍掉:时间这么短,架构、性能要求高,怎么可能做出那么多需求来?很快需求控制住了,我们实现的功能很明确。 心得:这个项目能够控制住需求的原因有二:(1)采用需求原型开发,根据自己对需求的理解快速把UI整理出来。(2)仔细的编写SRS,把一些假设(Assumption)明确的写进去,避免后续的问题。
现在该回到主题:XP(极限编程)了。 (1)No Plan, then plan every day. 现在说自己写了一个项目计划,但是3周时间,这么短如何跟踪?所以每周制定一个Activities List,每天计划,每天跟踪!任务分配到个人并定义相关接口人员。 心得:(a)天天分配新任务并跟踪的做法对于Team members来说工作强度太大,压力也太大,不适合长时间项目使用。一般我会事先说好采用的时间段。在长时间项目中只在关键阶段采用该方法。 (b)天天计划要求PM对工作任务和技术方面非常熟悉,否则就是瞎指挥!危害很大,Team members背后可能都把你骂死了,你还自以为自己安排得非常好。因此首先需要征询SA或者Senior Enginneers的意见,在计划和分配时也需要得到相关members的同意。不要直接命令下去。 (c)理性对待Delay,过程中有2天的Delay,不要试图加班等初级手段赶上去,一般来说,赶只会越赶越慢。想想看有没有其它的解决之道。
(2)Continous integration:采用Smoke Testing的方法. 也就是冒烟测试,保证从项目初期到最后交付都有一个可运行的版本。指定一个配置管理员,负责每天将最新版本部署在测试服务器上,保证可以编译并运行。 心得:由于配置管理skills方面的原因,初期并未能run起来,之后才能得以跑起来。
(3)Simple Design:其实我想做详细设计也没门,因为SA只有一周的时间参与,怎么做?做一个例子,数据库上建一个table:product,然后从前台JSP,Tile ->Struts->EJB->OJB->DB能够跑通,可以在页面上add,delete,update。嗯,中间漏了DAO,可以以后加嘛。这个例子做好之后做为例子供其它Team member学习和熟悉。 心得:迫不得已的做法,但是的确有好的效果,在SA做这个例子的期间,其它人紧张的进行环境准备和技术准备,大家得以熟悉开发工具和开发环境以及必须的技能。有一个现实的例子,普通程序员开发起来心里更有底一些,自己设计会有问题,难道照着做还不会吗?
(4)Pair programming,当然有些变通,Pair programming的意思是两个程序员在一台机器上来开发代码。我的做法是将前台部分的功能(从Jsp,Tile,struts到EJB)根据不同特别分配给3位Entry SE(入门级软件工程师)。这部分工作量很大,大家的缺陷都非常多,但是通过互相检查和共享,效果很不错。进展快得人可以更快将功能集成进系统。 心得:如果采用水平分配任务,可能有的人能够做得好能够提前进度,但是任何一人出了问题,那么整个系统就没有一个功能可以run,同时在接口上的沟通成本会非常大。
(5)40-hours work, 在项目初期就先说好,前两周开发时间不要求加班,在最后一周集成测试时才要求晚上部分加班。 心得:象这类风险大的项目,如果全靠加班才能做好,那么肯定是初期有大问题。还是那句话:进度不是赶出来的,进度是plan出来的。
没有完全采用CMMi的一套Process,而是采用了XP的部分Best Practice,最终项目按时、按质提交,似乎完成了不可能完成的任务,但是当SQA来Audit的时候,报表很难看。所以采用这种方法有以下缺陷: (1)知识保存:所有的项目管理经验都在PM脑子里,设计理念在SA里,好的实现都在开发人员的脑子里和代码行间。项目结束后,不少项目组成员都到了其它项目组,后续项目(该项目有后续大的单子)得不到之前继承的知识。 只剩下了结果。 (2)Tracking:只有PM了解项目的真实情况,其它人都无法知道,SQA也没法检查(XP里面是没有SQA的)。
由于一直是在CMMi下面Lead项目,因此部分工作还是采用CMMi的Process,比如配置管理(CM),需求管理(Requirement Management),PMR(Project Management Review),Risk Mangement, Issue Management,DefectTracking等等。
从结果来看,作者的这个开发解决方案接近perfect,顺利完成了项目目标。虽然说过程资产缺失严重,但是这么短的周期,还能要什么自行车?如果按照正常项目开发流程,我想连立项恐怕都难以完成,更别提要交付给用户了。从整篇文章来看,作者对项目管理已经有了很高层次的理解,不仅是CMMi,还有敏捷开发,对不同类型,不同条件的项目也可以将从容应对,非常厉害。
在作者的实施方法中,有几点非常认同:
作者刚开始就针对需求做控制,把不确定的需求明确下来,确定项目范围,这点至关重要,在项目失败的原因中,需求的不确定是第一要因,更何况还是这么短的周期,需求稍微变一点,失败肯定是必然的。
每周制定一个Activities List,每天计划,每天跟踪!这招比较狠,每天每个人都有一个deadline,鸭梨山大,在这种情况下,每个人每天都很明确自己的任务以及完成时间,虽然有压力,但是我想效率应该会很高,而且在项目完成之后team member的成就感会很大,对士气的提升很有帮助。
简单设计,作者根据XP的实践准则结合自身项目特点,制定了适合自身项目的设计准则,比如由SA做DEMO,其他新人并行熟悉环境,随后再由新人参考DEMO来做开发。
也有不太认同的:
结伴编程,作者描述的太简单,木有看出来哪里有结伴。
40-hours work,项目时间紧急,又有很多不确定因素(比如需求、WSAD),虽然我很不赞同加班,但是这种情况下,开发周期不长,要求team member保持高效率、高产出比硬性遵守每周40hours更合适,如果下班之后,某个兄弟感觉自己依旧精力旺盛,又十分愿意主动加班,这个时候我想应该对项目,对团队来说都不是什么坏事,但前提是加班不是完全无偿的,至少要提供调休或者其他福利之类的,这样大家才会有动力,毕竟雷锋同志不是每个人都愿意当的。
统一编码风格这篇文章中没有说明,不知道在这个项目中有没有用到,这个项目中有几个新人,如果没有统一编码风格,很可能最后代码风格非常混乱,或者根本就没什么风格(有的童鞋编码从来不讲究风格),如果是这样,以后维护的童鞋有罪受了。