在混乱的小项目中应用XP(极限开发)

软件工程 专栏收录该内容
13 篇文章 0 订阅

我们假设一个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等等。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值