封闭式开发小记(5):封闭式开发的敏捷开发


    封闭式时间紧、任务急,而且是好不容易向老板那里要来的资源。还有,没有其它的干扰,所以对于我们这个Team来说,应该是没有任何借口的,不管这是一个产品研发,还是一个项目开发,都不容许有任何差错。

 

但是在前期没有客户直接接触,确切的说,只有一个产品经理获得了一些基本的客户需求时,我们怎么做出成绩,或者相对的能做出一些被认可的东西来了呢?思来想去,我们没有按原来的从需求分析到测试到编码的传统流程。

我们使用了敏捷。

这里不敢说完全按照了Scrum,或者其它的敏捷过程管理,因为在敏捷开发的群集中,我们毕竟还算新手,但是为了能轻装上阵,速度取胜,我们尽量的把一些省时省力的,而且轻文档的好的实践引入到封闭式开发中。在这个时间段,我们只有把减轻文档,从开发的平行化转为开发的纵向化,即从流程为主导转向以业务为主导

      

                                               瀑布过程 


    原来的以过程为主导就是先把需求做细,向各方确认,然后由产品经理汇总,再交于界面交互设计师和架构师,再经确认后再交给开发去编码,最后功能点全都达标后,再交给测试,最后是QA。这样有个问题,好多文章都说了,错误到最后才这发检查出来,或者直接被否定了,郁闷。

封闭式开发是不容许出现这种问题的,我们只有一个目标,做出客户想要的。所以,我们只能从业务导向,把一个需求从基本的描述到开发,到测试,深入的做好一个个需求,到给客户看的时候,我们就能拿得出手,讲的好听点,我们可以随时拿出一个可以演示的版本来给产品经理去做演示。而不是原来的到提交测试前一天,开发人员的代码都是写好的,可是没有经过验证,因为测试没过。每个功能点的完成度都是90%多,没有一个版本是拿得出来的。客户急了,我们的老板更急。

                                                    scrum过程  

上面讲了一些闲话,主要是说明了为什么在我们在封闭式开发中要引用敏捷,下面着重介绍几种比较好用的几条建议

1.       轻文档描述

不要复杂的,重量级的需求说明书。每个需我们简单的用一段话,或一个小小的流程图来说明,有时候直接写到了笔记本上,根本没有电子化。

下面是简单的一个用户故事。假设我们开发的是一个类似于QQ的即时通讯项目,这里描述的是一个创建群的故事:

故事描述:

作为一个使用我们产品的客户,我需要建立一个群组,并且选定群组的人数和群组名称,以用来向这些群组内的所有人发送相同的消息,而不用为每个人发送。

简单流程图:


用户接受测试:

点击创建群组按扭,输入群名称,指定群成员,创建群,系统返回成功或失败。

 

2.       单元测试

每个小组对于自己开发的模块在给其它小组调用的时候,都要至少通过单元测试,这里特别要强调对于输入验证和输出格式返回。有时候当接口的参数十分特别的时候会减少反复的时间。

   如果Team中的其他人调用到你的接口,出现了问题,你可以及时把这个bug转化成单元测试,下次提交的时候则同一样的错误不会重犯。如果有时间多的话,可以提高下代码覆盖率,也是一种不错的选择哦。

同理,如果你发现了其它小组提供的接口中有些bug,则也可以为这个bug编写一个单元测试用例。这样,使这个bug重复出现的成本变成零,也方便验证那个小组在重构后会反复的问题。

3.       代码交流(TDD

如第2点所示,我们之间的调用和被调用,都被固化在了单元测试中,不用直正到产品中的代码中才能发现或被调试。小组间不再花更多的时间在争吵或者改没改上面,只要原来的测试能满足,现在却不能满足了,谁的问题,也就没有争的必要了。

4.       每日构建

这个十分十分的重要,要及时给大家汇报,我们现在完成的故事是多少了,现在能看到结果是哪些,时间安排[l2] ,我们每天都有一个小时专门用于汇报和讨论,在这里大家能及时看到完的业务故事情况。也方便进行讨论。如果一个版本比较稳定,我们会打一个版本,并且发布到外网上去。并在源码上做好版本的标记。

5.       编码规范

我们是用REST的模式进行开发,所以要对URL进行规范,每个小组在开发时,都需提前把自己的URL头,和可能用的到列表都发给一个人进行管理。

功能说明

URL

QQ/增加群

http://abc.com/qq/addgroup

QQ/增加用户

http://abc.com/qq/adduser

QQ/登录

http://abc.com/qq/login

Weather/查询本地天气

http://abc.com/weather/local?areacode={0}

Weather/查询温度差

http://abc.com/weather/tmp?areacodes={json:0}

代码编写和命名规范是直接用公司的统一规范。

6.       主动索取任务

原来是经理对所有开发人员说,你的任务是什么,你的是任务是那些。现我们一开始在讨论会中把所有的任务都列了出来。然后,我们自己规划这两周能做哪任务。化备动为主动。

7.       互相帮助

由于每个开发人员开发效率不同,可能有的先完成任务了,有的还没完成。由于我们不再像原来的那样,数据库开发只管数据库开发,前台只管前台,框架只管框架。如果后台人员完成开发任务了,会主动帮助前台进行开发。像我虽然是后台通信开发小组的,可是在完成自己的开发任务后,我也参与了样式布局和前台脚本的开发。任务是我们自己选的,一定要一起完成他。

8.       代码审查

按照编码规范去查看代码,一个迭代大概花半天时间。再半天时间重构代码和用测试去验证。

9.       白板讨论

我们讨论的时候不再纸上画,我们也可以用白板。画简单的流程图或序列图。这样让更多相关人员都能进来。

不足之处:

1.       集成测试

由于我们是基于单个故事开发,到集成测试的时候,可能由于每个小组进度不一,而时间会有所拖延。所以至少要花半天时间来做这个工作,而不是原先期望的半小时内。在这个时候,接口会有所调整,要及时编写对应的单元测试进行验证。

2.       代码覆盖率

由于时间不足,这部份没有达到理想的90%以上。只能80%多吧。

3.       文档不足

我们大多以代码为文档,把命名做好了后,几乎没有写什么文档,需要多方确认的需求除外。如果有时间多,还是需要把这些基本的故事整入backlog中。以备做战斗力评估和团队成长的记录。

     

 

思路决定出路!


      目录: 

    封闭式开发小记(1):封闭式开发的基本装备

   封闭式开发小记(2):封闭式开发的时间安排

   封闭式开发小记(3):封闭式开发的人员配备

   封闭式开发小记(4):封闭式开发的架构设计

   封闭式开发小记(5):封闭式开发的敏捷开发

   封闭式开发小记(6):封闭式开发的文档管理

   封闭式开发小记(7):如何和谐沟通、提高士气(结合开发实际冲突来深入讨论合作与沟通)

   封闭式开发小记(8):封闭式开发的项目讨论(10.9)

   封闭式开发小记(9):封闭式开发的最后一天(10.10)

   封闭式开发小记(10):封闭式开发的项目汇报(10.11)

   封闭式开发小记(11):封闭式开发的测试发布(10.12)   

posted @ 2010-10-07 20:50  刘寅  阅读(2328)  评论(0编辑  收藏  举报