软件特性开发的流程感想

过去的两年中经常对产品做一些新增功能，也就会经常思产品的特性是怎么来的，怎么开发的，怎么测试的，怎么维护的，如何做才能避免不必要的需求变更、设计变更、用例变更，如何提高软件工程师的开发效率。
本人供职于小的计算机产品部门，这种并没有像BAT等大型互联网公司有着比较完善的市场、解决方案、产品体验设计等部门。很多时候，开发人员要考虑更多的问题，比如用户需求分析、业务流程的设计、功能需求导入、用户界面设计等等
所以本文只是从一个一线开发人员的角度、一个小公司的角度来探讨适合自己的开发流程或者将方式。

1  市场需求

市场需求，就是市场人员在与客户沟通过程中发现，客户在某件事情遇到什么样的问题，或者存在某种欲望（当然是对种产品），非科班出身的市场人员就会把客户的这种问题或者欲望带回家，告诉开发人员，客户想要什么什么，有时候就是一句话，好的时候是一段话。所谓用例，都没有。
这种就是最原始的需求。
这种原始的需求，都会有人来分析，具体是谁，公司不同，角色不同。

2  功能需求调研

我们了解了客户的要求，即最原始的需求，此时，就要在市场上看看有哪些同类产品，哪些产品是比较经典的或者市场占有率比较高的产品，针对这些产品，了解他们是如何解决客户需求的，进行仔细，了解其优缺点（如果能推测其设计方案就更好了），然后基于对比分析，确定业务流程及我们需要实现的基本功能和扩展功能。
为什么增加业务流程，增加对功能需求合理性的正确度。
输出需求分析文档，需求分析文档要足够详尽，支撑测试用例的撰写；
如果包含GUI/UI管理系统，理应包含[b]GUI/UI Demo（如果有UXE，建议由他们来设计），并且每一项需求细节和[b]GUI/UI Demo都应经过产品经理或子系统OWNer、测试人员的评审通过。[/b][/b]
为什么要增加[b]GUI/UI Demo评审，目的是避免后期不必要的扯皮。[/b]
 

3  选型和原型开发

有了详细的需求，需要展开方案设计，没有一定完美的方案，但是可以有多种方案，需要对不同的方案进行对比分析，清晰的了解其优缺点，选择一种适合我们自己的方案。
然后对方案中的难点进行原型开发，对其中的风险进行评估，在接下来的方案设计中需要包括这些重难点分析和风险评估。在方案评审时，这部分需要评审人员重点关注。
类似于买保险中的“健康告知”。

4  方案设计

方案已经对比清楚，已知的困难点已经解决，已知的风险已经评估。
概要设计一般还包含：
（1）系统架构：一般来说会有个简单的架构图，并配以文字对架构进行简要说明；
（2）模块简介：架构图中如果有很多模块，需要对各个模块的功能进行简要介绍；
（3）设计与折衷：设计与折衷是总体概要设计中最重要的部分；
（4）潜在风险（可选）；
输出总体概要设计的时候，很多方案还是不确定的，需要在设计评审会议上确认。
总体概要设计重点在“方案折衷”，总体概要设计评审完毕之后，此时应该是所有方案都确认了，需要输出各模块的详细设计。
 
详细设计重点在“详细”：
(1) 总体概要设计结论汇总（可选）：达成一致的结论有个简要概述，说明详设是对这些结论的实现；
(2) 交互流程：简要的交互可用文字说明，复杂的交互建议使用流程图，交互图或其他图形进行说明；
(3) 数据库设计：这个是应该放在总设还是详设呢？
(4) 接口形式：有了数据库+接口+流程，别的同学拿到详设文档，基本也能够搞定了；
理论上输出了详细设计之后，无论谁拿到了这个详设文档，都是能够完成该项目的。
摘自百度，个人经验：
(1) 设计与折衷是总设中最重要的内容，总设评审中，主要就是讨论这些折衷的优劣；
(2) 评审过后，不但要邮件周知结论，还要在总设中进行更新，说明最终决定使用了哪种方案，为什么使用这种方案；根据自己的经验，接手别人的模块、项目，拿到代码和文档，设计方案对我来说完全是个谜！
(3) 有时候因为排期或者其他原因，不一定采用了最优的设计方案，此时更应该在总设中记录决策的过程与原因；
(4) 最后，设计折衷是一个很好的自我辩解的机会：因为项目进度，或者历史遗留问题，不得不采取了一个这样的设计。

5  代码开发

针对产品特性，最艰难一步已经完成，此时就是按部就班的代码实现。
此处强烈建议，增加他人review，可保证质量；又可增加特性备份owner（避免责任去职后的工作空白）。
考验软件人员的基本能力——编程开发。

 6  测试
根据功能需求，形成测试用例，覆盖全部功能，保证特性功能的质量。
开发人员的测试用例是根据需求分析文档撰写的，所以在需求分析评审结束时，是完全可以支持测试用例的撰写的，测试用例要做到完全覆盖。
 

7  发布

产品功能开发完毕，测试确保质量合格，特性功能发布。
  
接下来就是维护，维护功能。

特别注意的一点就是，任何一个特性的开发，一定会经历以上几步，只是在不同的公司，可能由不同的角色或者部门来承担，如果没有按照上述几步来做，就失去了做事的条理性。 

作者：Younger Liu，本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。