SST项目流程改进方案1.0(草案)
王晓恬2011/7/29
目前在项目开发、发布、部署、测试过程中,发现有如下问题:
1.项目部署非常不方便,目前的方式是,先上传文件到服务器,然后手动修改tomcat
的配置文件,令其指向web应用的根目录,这样会带来如下问题:
a). 如果存在多个测试环境,由于每次部署都需要修改tomcat的配置,因此很难保证多台测试环境的配置完全同步,容易出错
b). 无法自动化部署,对于自动化测试是一个隐患
c). 由于不是以包的形式存放,因此软件产品库管理非常不方便,相应的,版本库管理也非常不方便
d). 这种形式不是标准的J2EE容器部署形式,将来如果采用其他web容器,那么会存在隐患
e). 随着web应用的越来越多,在各个方面(比如代码控制,版本控制,成品控制)等方面会越来越难管理,而且也会越来越难部署。
f). 较难替换和撤销,以及备份存档
2.目前测试过程中的产品不稳定因素:
a). 目前测试开始时候,开发还在进行,那么会导致测试版本永远是过期的,测试需要一个一定时期内相对稳定的版本。
b). 测试版本并不是从版本库中得到,这样会导致一个问题:测试版本永远以发布版本者本机的代码为准,这样的测试是无效的。
c). 在测试进行阶段,开发者还在不断的提交代码,这些代码并没有经过冒烟测试和集成测试,那么在进行分阶段开发的时候,会造成产品的不稳定性。
d). 在发布测试版本前,并没有进行冒烟测试和集成测试,这样的结果会导致第一轮测试在很大程度上进行了这两项测试,而这两项测试应当是发布测试版本前就应该完成的,只有完成了这两项测试,才能发布一个可测试的版本。
e). 测试环境应当彼此独立,互不影响,并且在测试开始前必须有一致的初始条件。
f). 目前一些较难测试的地方,并没有有效的测试方案和测试用例.
g). 缺乏专业的配置管理和版本管理,造成开发不知道自己开发的是什么版本,目前开发到哪个版本,上一版本的遗留问题,此版本的目标和解决方案,以及目前在哪个分支上进行开发,相应的,测试的过程中也不知道目前测试的是哪个版本,以
及重点测试和有针对性测试的功能,此版本的遗留问题,以及新功能的测试。
h). 为了保证产品质量,要进行代码覆盖率测试和回归测试。
i). DB的修改,需要通知所有人得知,并且在冒烟阶段,就要把DB没有更新导致的问题解决掉
目前适合我们团队以及项目的开发流程:
目前团队现状:
1.新技术掌握快。
2.团队合作不错。
3.团队成员技术全面。
4.团队缺乏开发、测试、配置管理方面知识。
5.对于已掌握的技术缺乏研究深度,不能有效控制风险。
6.沟通渠道过于单一,每个成员现状以及工作进度并不透明,这样无法有效调配资源
互相协作。
基于以上状况,敏捷开发(agile)的短周期的迭代(iteration)开发流程比较适合我们团队和项目,下面来介绍一下这种开发模式具体的过程(methodology),顺便说一下,这种模式并不是瀑布模型,任何时候可以推倒重来,比较灵活。
一个period包含若干个iteration,在period完成后,要进行较完整的测试和代码review以及项目回顾。
Period 从某种意义上来说也是项目的里程碑。
1.首先拿到原始需求,进行可行性评估
2.可行性评估之后,需要确定技术开发框架(infrastructure),以及开发环境、测试环
境、商用环境、部署方案、服务器配置、数据库等。
3.确定high-level的架构,主要就是开发框架以及解决方案的制定,此方案需要评估。
4.确定迭代周期,一般来说,一个iteration的周期为2周。
一个period周期为2个月
到半年
5.制定一个iteration内部的流程,以及每天工作的流程。
6.假设在有需求的情况下,将需求分为若干块,分别为requirement1, requirement2,
requirement3…….。
每一个需求工作量不超过一个iteration,需求优先级排序主要以业务的重要程度为主。
7.工作量不能安排太紧,必须保证质量,并且可以采用2人一组开发互相纠错的形式
进行,必须保证每个周期结束后的产品是可迭代的。
8.在一个iteration内部,遵循high-level design,部分的设计(detail design)和编码交
由开发人员,如果出现开发人员技能出现瓶颈,那么由这方面开发经验相对较熟的开发人员2人一组进行架构和开发。
9.在一个iteration开始前,需要的依赖关系(dependency)有:
a). 此迭代周期内明确的需求,该需求在此iteration里面不发生变化并且是明确的,如果发生重大变化导致无法推进,则可以中止此iteration。
b). 明确的high-level architecture以及high-level design,包括任何会block开发过程的因素都要到位
c). 上一次iteration的输出(代码和文档,以及设计,遗留问题),因此这一次iteration是基于上一次开发的,因此上一次iteration的一个有效版本是至关重要的。
d). 建立此次iteration的畅通的沟通渠道,以及追溯、检查(check)方式。
一个iteration必须有一个负责人进行定期的check保证任何风险是可控并且保证资源分配最大化。
10.Check和评估每天都要进行一次,早上开例会,团队成员需要汇报工作风险,申请
资源,以及手头任务进度报告。
11.针对每一次iteration的output:每一次iteration的output在此iteration开始前就需
要确定,iteration的结束以是否符合预期的output为准,测试方面,需要通过单元测试和功能测试
12.如果需要进行功能测试和集成测试,那么也可以安排到一个iteration中完成,
iteration可以是任意的工作安排,不一定是开发阶段,此外,iteration的时间是可以变更的。
13.需要对每期的iteration执行情况,bug数量进行统计,发现问题并相应的修改
iteration。
14.如果在iteration执行过程中,发现重大问题,那么可以随时中断此iteration,评估
问题并快速开展下一个iteration。
15.在经过一个period之后,需要对项目整体需求,架构进行重新评估。
16.在每次iteration开发过程中,需求方可以不断更新和修改需求,所有需求都可以快
速反应到下一个iteration里面。
附录:
产品发布流程。