封闭式开发小记(5):封闭式开发的敏捷开发
但是在前期没有客户直接接触,确切的说,只有一个产品经理获得了一些基本的客户需求时,我们怎么做出成绩,或者相对的能做出一些被认可的东西来了呢?思来想去,我们没有按原来的从需求分析到测试到编码的传统流程。
我们使用了敏捷。
这里不敢说完全按照了Scrum,或者其它的敏捷过程管理,因为在敏捷开发的群集中,我们毕竟还算新手,但是为了能轻装上阵,速度取胜,我们尽量的把一些省时省力的,而且轻文档的好的实践引入到封闭式开发中。在这个时间段,我们只有把减轻文档,从开发的平行化转为开发的纵向化,即从流程为主导转向以业务为主导。
瀑布过程
原来的以过程为主导就是先把需求做细,向各方确认,然后由产品经理汇总,再交于界面交互设计师和架构师,再经确认后再交给开发去编码,最后功能点全都达标后,再交给测试,最后是QA。这样有个问题,好多文章都说了,错误到最后才这发检查出来,或者直接被否定了,郁闷。
封闭式开发是不容许出现这种问题的,我们只有一个目标,做出客户想要的。所以,我们只能从业务导向,把一个需求从基本的描述到开发,到测试,深入的做好一个个需求,到给客户看的时候,我们就能拿得出手,讲的好听点,我们可以随时拿出一个可以演示的版本来给产品经理去做演示。而不是原来的到提交测试前一天,开发人员的代码都是写好的,可是没有经过验证,因为测试没过。每个功能点的完成度都是90%多,没有一个版本是拿得出来的。客户急了,我们的老板更急。
scrum过程
上面讲了一些闲话,主要是说明了为什么在我们在封闭式开发中要引用敏捷,下面着重介绍几种比较好用的几条建议:
1.
轻文档描述
不要复杂的,重量级的需求说明书。每个需我们简单的用一段话,或一个小小的流程图来说明,有时候直接写到了笔记本上,根本没有电子化。
下面是简单的一个用户故事。假设我们开发的是一个类似于QQ的即时通讯项目,这里描述的是一个创建群的故事:
故事描述:
作为一个使用我们产品的客户,我需要建立一个群组,并且选定群组的人数和群组名称,以用来向这些群组内的所有人发送相同的消息,而不用为每个人发送。
简单流程图:
用户接受测试:
点击创建群组按扭,输入群名称,指定群成员,创建群,系统返回成功或失败。
2.
单元测试
每个小组对于自己开发的模块在给其它小组调用的时候,都要至少通过单元测试,这里特别要强调对于输入验证和输出格式返回。有时候当接口的参数十分特别的时候会减少反复的时间。
如果Team中的其他人调用到你的接口,出现了问题,你可以及时把这个bug转化成单元测试,下次提交的时候则同一样的错误不会重犯。如果有时间多的话,可以提高下代码覆盖率,也是一种不错的选择哦。
同理,如果你发现了其它小组提供的接口中有些bug,则也可以为这个bug编写一个单元测试用例。这样,使这个bug重复出现的成本变成零,也方便验证那个小组在重构后会反复的问题。
3.
代码交流(TDD)
如第2点所示,我们之间的调用和被调用,都被固化在了单元测试中,不用直正到产品中的代码中才能发现或被调试。小组间不再花更多的时间在争吵或者改没改上面,只要原来的测试能满足,现在却不能满足了,谁的问题,也就没有争的必要了。
4.
每日构建
这个十分十分的重要,要及时给大家汇报,我们现在完成的故事是多少了,现在能看到结果是哪些,时间安排[l2] ,我们每天都有一个小时专门用于汇报和讨论,在这里大家能及时看到完的业务故事情况。也方便进行讨论。如果一个版本比较稳定,我们会打一个版本,并且发布到外网上去。并在源码上做好版本的标记。
5.
编码规范
我们是用REST的模式进行开发,所以要对URL进行规范,每个小组在开发时,都需提前把自己的URL头,和可能用的到列表都发给一个人进行管理。
功能说明 |
URL |
QQ/增加群 |
|
QQ/增加用户 |
|
QQ/登录 |
|
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中。以备做战斗力评估和团队成长的记录。
思路决定出路!
目录:
封闭式开发小记(7):如何和谐沟通、提高士气(结合开发实际冲突来深入讨论合作与沟通)
封闭式开发小记(8):封闭式开发的项目讨论(10.9)
封闭式开发小记(9):封闭式开发的最后一天(10.10)
封闭式开发小记(10):封闭式开发的项目汇报(10.11)
封闭式开发小记(11):封闭式开发的测试发布(10.12)