【IT168 案例】
2008年8月到2008年12月,作者参加了某省级无线运营商的网上营业厅3期项目的开发,并担任项目经理的职位。网上营业厅是该无线运营商的省级网上门户,是其电子化营销渠道的重要组成部分。本文结合作者的实践,以网上营业厅3期项目为例,讨论了敏捷需求管理在敏捷过程中的应用。在论述过程中,主要指出了敏捷需求方法如何帮助作者解决了一个时间紧迫的困难任务,最终快速地交付了可用的软件,从而给客户带来可观的商业价值。同时还展示了敏捷需求方法对于项目迭代的重要意义。除此之外,作者还说明了如何使用Redmine项目管理工具进行敏捷需求的管理,以及使用此工具的心得和体会。最后,作者指出了在使用Redmine进行需求管理时存在的不足,并给出了预期的解决方法。
2008年8月到2008年12月,我参加了某省级无线运营商的网上营业厅3期项目,在这个项目中,我担任了项目经理的角色。
网上营业厅是该运营商的省级网上门户,是电子化营销渠道的重要组成部分。其主要功能包括:企业形象宣传;新业务、新活动推广;客户进行业务查询和办理等。随着客户对电子渠道认知度的提升,原有的网上营业厅2期在硬件方面,已经无法满足日益增长的客户数。在软件架构方面,已经无法快速响应频繁复杂的需求变更。因此,该运营商提出了对于网上营业厅3期项目的建设计划。3期建设的预期目标为:把网上营业厅的注册客户数从200万提升到500万,并从硬件、软件等各方面保证客户正常使用。
该项目的人员组成包括:1名项目经理,1名软件开发经理,1名系统实施经理,3名程序员,2名页面制作,2名系统实施共10人。项目的开发平台为J2EE。
该项目的硬件大体情况为:14台IBM BCH ,安装apache,作为 web前端服务器。6台IBM P52A,安装weblogic,作为应用服务器。2台P570作为身份认证服务器。2台P570,安装oracle,作为数据库服务器。操作系统使用了红帽企业版 linux 5,以及AIX5.3。
目前,网上营业厅3期成功通过终验,并按时上线。在月初、月末的业务办理高峰期,能够保证客户的正常访问。此项目得到了该省级无线运营商和我所在公司领导的认可。
我们的团队采用敏捷过程进行管理,这是由项目的性质所决定的。第一,网上营业厅项目有40多个业务需要开发,但业务和业务之间的关联度很低,有些甚至没有任何关联。第二,临时业务需求随时会出现,往往是时间紧迫,让人措手不及。第三,3期将要与2期并行运行,众多业务将会一部分一部分地上线。敏捷需求的特点就是要把需求分出轻重缓急,总是着眼于当前最紧迫的任务,并快速地交付可用的软件来为客户创造商业价值。除此之外,敏捷需求还需注意需求的可持续性和可叠加性。就算初期交付了可以工作的软件,如果这个需求不是可持续叠加的,就将面临被推倒重来的危险,敏捷需求也就失去了其原有的价值。下面,我将结合网上营业厅项目,进一步阐述敏捷过程是如何把握客户需求的。
网上选号是网上营业厅的一项业务。此业务是一个典型的时间紧,任务急的例子。在这个例子中,敏捷需求的理念得到了充分的发挥。对于无线运营商来说,在网客户数量就是其商业价值的根本。所以,不同的无线运营商在争夺客户资源方面都花尽了心思。网上营业厅项目的时间表恰好跨越9月份这个各大院校开学的日子,所以,该无线运营商要求我们开发一个网上选号的业务,并且要让即将开学的大学生们能够在网上进行选号。然而此时,已经是8月25日,离交付日期仅有6天时间。
该运营商的市场经理向我们提出了以下几个需求。前台有:网上查号及选号、靓号竟拍和号码预约。后台有:物流配送、网上开机和统计分析。这些需求是市场经理在上级领导的巨大压力下,花了整整一天的时间想出来的,他希望我们在剩下的6天里统统实现。
其实,就算只有“物流配送”这一个需求,我们也恐怕也无法在6天里面完成。于是,我建议这位市场经理再仔细地梳理这些需求,并进一步了解上级领导的心理底线。“物流配送”的难点恐怕还不是在软件开发上,而是在于协调SIM卡、物流、客服等资源上。就算是以前和物流商有过协议,但也不能一概而论。后来,该市场经理通过和以前合作过的物流商联系发现,仅仅让物流商进行代收费一事,就基本上是不现实的了。最后“物流配送”改成了由该无线运营商的流动服务车配卡,然后由学生自行取卡。最复杂的需求就这样被消除了。
虽然,我和这位市场经理不熟,但我还是拿出了令他信服的项目组迭代速度。以此证明,在6天的时间里,我们仍然不可能完成剩下的所有的需求。经过进一步的沟通,最终我们确定了最紧迫的两个需求:“网上查号及选号”和“网上开机”。只要这两个需求能够在6天内被交付,那么,此业务就能够顺利地在9月1日上线。虽然结果可能并不那么吸引人,但这样仍然完成了市场经理及其上司的心理底线。所有剩下的需求都将作为较远期的迭代目标,项目组仅仅给与较模糊的考虑和认识即可。最后,我们把这两个需求分解为可度量的功能点,并又一次去掉了几个琐碎的,难以实现的,并且对交付成果没有太大意义的功能点。除此之外,我们还商定了验收测试用例,并以文字形式保存下来。
在接下来的6天里,我们按照以往的速度平稳推进,并成功地在9月1日完成这次迭代,该无线运营商也抢在了其他运营商前面占领了市场先机。项目组备受鼓舞。
除了敏捷需求的获取之外,我想再说明一下对于敏捷需求的管理。我们在网上营业厅项目中,采用了轻量级的项目管理工具Redmine作为需求管理工具。虽然Redmine不是专业的需求管理工具,但经过我们的实践,把它用在敏捷需求的管理上特别合适。
Redmine以“问题”作为管理的基本单元,在敏捷需求管理的意义上,就是一个可度量的“功能点”。功能点具有发起人、紧急程度、状态、指派给、相关问题、开始日期、结束日期、预计工时、跟踪者和描述等属性。通过把从需求中分解出来的功能点记录下来,就可以对所有的需求问题进行结构化的管理。这样一来,开发人员面对的就不是以往那种文档化的功能点,而是可追溯的,易跟踪的以及结构化的功能点。这对于软件开发的组织和管理有着举足轻重的意义。
通过Redmine对于需求的管理,我们还获得了很多额外的好处。其中最重要的一项就是,开发人员每天对于所参与的功能点的“耗时登记”。这些数据提供了项目组的可以量化的迭代速度。这个可量化的速度对于以后的需求获取和功能点的分解有着很强的说服力。
通过以上的论述,说明了敏捷需求管理对于网上营业厅项目的重要意义。虽然项目的进展十分顺利,但需求过程当中仍然存在一些缺陷值得思考。其中一个就是对于需求的自动化验收脚本的使用。由于项目的复杂性和特殊性,自动化验收仍然面临着众多障碍。这其中包括对于验证码图片的识别、页面文字的正确性、统一计费环境的本地模拟等等。因此,网上营业厅项目的验收测试在很大程度上仍然依赖于人工。好在无线运营商拥有庞大的客服体系,使得此问题并没有阻碍项目的进度。另外有一点遗憾就是在Redmine中,无法对功能点打包。也就是说,它不能够以“用户卡片”或“用例”来组织功能点。不过Redmine是一个开源的工具,我们将在以后的项目当中,结合自己的实践,尝试对其进行改进,使其更加适合敏捷需求的管理。