1、按业务场景做系统分析/系统设计,测试以设计文档为测试依据.设计文档是否符合需求,由需求的提出人也就是产品经理去校验。
测试以原始需要为测试分析测试用例设计是产生设计缺陷最大的问题根源;
设计没有按照业务场景设计,是代码实现的时候才发现业务流程跑不起来而需要导致修改设计的罪魁祸首。
设计没有按照业务场景设计,所以咱们在测试期才发现原始需求就模糊在测试阶段还在和产品经理讨论需求。
2、现有核心子系统核心模块的业务知识、代码实现知识的沉淀,让人先把现状了解清楚。不清楚业务,不清楚现有代码,是开发慢(需要理解或迟迟不敢下手),是出BUG,是开发不满足设计的罪魁祸首。
3、平台提供稳定性保证机制,这样上层子系统就少出BUG。时间主要耽误在修补BUG。
4、多提供代码审查工具(要能做出工具必然前提是把现有版本中的BUG有彻底的分析和理解),这就BUG出的少。时间主要耽误在修补BUG。
5、开发Leader在功能设计中期开始参与代码骨架编写与设计,借此手段深刻理解业务,深刻理解业务怎么通过修改现有代码进行满足,深刻理解现有代码怎么小心翼翼的改才不会引出更多的麻烦错误。咱们现在修改一个功能莫名引起其他模块出BUG是最头疼的。通过开发Leader的综合经验技术功底来保证。
也只有这样,开发leader才能深刻理解业务需求,才能真正做好数据库设计与修改管理,才能把性能隐患在前期就找到,把性能在设计期就保证了,这样就不需要在后期花大量时间在性能优化。
这5步,本质上来说是通过分工,通过方法论来得到实现的,所以咱们思考问题解决问题,要用方法和机制去达到长久保证,而不是人海战术加班战术严控战术经验人战术。
武汉做设计方法论的优化、设计与测试的一体化配合、设计与开发leader的分工配合、开发Leader和普通开发的配合、平台的保证、业务知识/代码实现知识的沉淀、代码审查工具/现有版本BUG彻底逐条分析,这是关键。
希望大家对这些关键都有明确的关键行动、行动计划到人到时间,只有这样才能执行,才能达到咱们的目标。想法好,方向对,也能真正去做了才能成功。
在这个基础上,再去尝试SCRUM的一个月迭代冲刺一次、单元测试与自动化测试/同步持续测试。
1182

被折叠的 条评论
为什么被折叠?



