现代软件项目开发流程

在传统的瀑布式开发模式中, 我们发展出各种复杂并且严格的生产流程, 期望将软件开发的模式给彻底固定下来. 于是, 我们发明了各种开发流程的标准, 也提出了各种”看似很合理”的工业化模式. 可惜, 软件开发的世界, 没有银弹, 我们很快就发现, 所谓那些严格制定的标准和模式, 最终反而成了阻碍生产力的一大弊病. 面对这种状况, 我们又开始走了另外一个极端, 提出了各种敏捷开发的模式, 彻底否定了瀑布式. 大力提倡看板的作用, 开发者们试图用一种自己其实并不理解的工业化生产中提取出来的生产模式, 应用到自己的产品生产中来. 但是, 大部分 称是敏捷开发的项目中, 真的完全做到了敏捷模式的流程吗案是否定的.

解决之道就是不解决 

那么, 问题来了, 我们该使用何种模式去指导实际的开发过程呢实, 大部分团队在项目实践中, 早就给出了答案, 那就是不给出一种严格定义, 而是边做边看. 这样说可能显得非常不负责任, 一个没有解决之道的说法, 是解决不了实际问题的. 其实, 在那些没有指定标准规则的团队中, 并不是没有自己开发模式的, 只不过, 这种开发模式, 隐藏在我们实际的生产过程中了. 这个应用在实际中的开发模式, 是瀑布式开发嵌套着敏捷式, 在整体流程中, 我们采用的瀑布式, 而在瀑布的每个过程中, 使用敏捷模式嵌入其中, 偶发性的破坏瀑布式流程, 但必然保证整体上, 保有瀑布式的样子.

我们做开发工作的, 面临这种问题, 最好的办法, 是努力指定一套适合自己团队的流程规划, 然后在项目中应用, 并且收集经验, 修正模型, 在所有项目的生产中, 变得越来越得心应手.

整体流程 

下面我给开发流程的各个时期做一个定义, 这只是我定义的内容, 仅作为一个参考. 上面我说了, 我们必须要在自己团队适合的基础上去制定规范, 而不是一味的照抄我的定义, 这样反而失去了我所表达的本意.

确定这个流程, 并不是说这个流程的本身的必然性, 而是有了一个参考模型, 提醒我们下一个项目, 我们是不是错过了什么. 人的惰性和急功近利, 必将让我们失去某些正确的判断, 转而做一些简单的, 对自己有利的工作, 结果, 会让项目变得不受控制.

下面, 就列出每个流程期的工作内容.

各个时期的工作 
立项期 

可行性分析1 . 预估产品的市场接受度 2. 判断产品技术难度 (1). 技术点可实现性评估, 明确哪些技术点可以做, 哪些技术点不可以做 (2). 效益与可实现性比例评估, 针对一些相对比较困难的技术点, 就要评估效益可实现性比, 如果这个比率过小, 那么就要放弃甚至延期. (3). 规模化评估, 某些技术点难度并不高, 但是, 工期成本会很高, 针对这种点, 需要做技术判断. 
3. 判断产品人员控制难度 每个开发人员的实际可实现性, 需要具体罗列出来. (1). 每个开发人员的自我时间评估. (2). 综合时间评估, 确定自我评估和团队领导对个体能力的组合评估. 
需求收集1. 判断面向的用户群体和群体分析 2. 确定主体实施功能 3. 提供需求收集袋, 并且整理需求点 (1). 寻找同类产品, 分析其可能使用的技术手段和特点.(2). 确定新技术, 分析可能带来的用户效益. 4. 权衡需求, 确定产品大致模型 
工期预定1. 预估和判断工作量(由项目主管评估)重点要争取测试时间, 这一点比开发时间更加重要. 2. 组织参与人员, 进行工作量的校验评估(由项目工作人员自我评估) 
设计期 

在设计期, 工作的重心变成了对自我的深度了解. 团队的主管一定要明确在这个阶段, 我们能做到什么程度, 在这个程度之上做优化, 而不是无止境的讨论和深入. 举个例子, 很多团队, 开发人员暂时只具备做成一个产品的能力, 而不具备做一个优秀产品的能力(那要涉及到美术感知能力, 系统层绘图, 络安全设计, 数据稳定性处理等各方面都有所猎及), 这时候, 如果在设计期非得要安排好做一个细节程度非常高的产品, 那就可能会导致整体产品严重延期. 碰到这种情况(事实上, 这是一种非常常见的情况), 我们应当先仔细了解团队内部人员的情况, 在现在能力基础之上, 适当做突破, 以抓需求重点为主线, 然后逐步增加细节.

架构定义1. 定义子项目关联模型, 确定服务结构 2. 确定产品的硬件系统搭配 3. 确定产品的软件系统的技术要点(如开发平台, 语言, 数据库等) 
产品设计1. 规划设计语言, 确定设计元素要点 2. 确定软件界面流程 3. 输出产品概念图对于其中的弱逻辑, 一定要严格把握, 弱逻辑指的是一些主逻辑之外的逻辑点, 这些点非常不显眼, 所以很多产品设计人员只看重主逻辑, 对于那些弱逻辑, 他会给出答案, 直接参考某某软件之类的做法. 这样做会带来一些逻辑模糊, 甚至会导致逻辑不自洽, 一定要争取产品概念图中有足够自洽完毕的逻辑环. 4. 进行产品设计的可行性验证工作(1). 开发人员需要参与到设计工作中来, 评估产品设计是否偏离了最初的设计目标.(2). 事先争论, 很多开发人员, 初期不重视设计输出, 在开发过程中, 开始产生争论, 针对这种情况 ,一定要事先做好可行性验证, 保证开发起来的顺畅. 
功能和描述规划1. 确定功能的细节点 2. 提供产品所需的业务资源 
接口/数据结构设计1. 设计数据库中的数据结构 2. 确定数据库中的数据逻辑 3. 提供接口设计的规范 4. 设计主体接口(完整的接口, 会在实际的开发期反复调整) 
生产期 

与设计期不同, 生产期需要将工作的重心, 变成对外部的了解, 尤其是对市场和用户的理解上. 很多美术人员和开发人员都有一个弊病, 那就是只要设计期确定的事情, 照本宣科的去做, 这样的结果是, 做得好, 最多能达到的需求和体验也只能做到设计期的水准(事实上往往都不如). 作为团队主管, 一定要让参与人员时刻保有用户的心态, 所谓用户心态, 有两种, 一种是当一个正确的场景出现的时候, 体验舒畅, 一种是当一个错误的场景出现的时候, 能够获得安抚. 工作人员往往只在乎自己要做的部分, 只在乎要做出场景来, 没有任何体验舒畅的设计, 也没有考虑任何错误的场景, 更遑论在错误场景发生时安抚用户的设计. 关于这部分, 我会详细写一个博客来补充, 有很多需要考虑的点, 来解决这些问题, 但是, 最核心的一点, 是生产者一定要时时自我测试, 只有充分的自我测试, 才能保证用户心态的理解, 否则, 只做设计, 只做开发, 是体会不到用户心态的一面. 作为团队的管理者, 这时候一定学会带头作用, 建立某种测试规范流程, 或者定期开会组织测试汇 , 总之, 一定要让参与者理解到, 测试大于生产这一点. 对市场的理解, 那是更深的层次, 但是, 它的基础一定是先让参与者建立用户心态,只有让所有的生产者建立用户心态, 产品才会有提高的可能性.

静默期是指产品上市之后, 推广之前的一段时间, 这一段时间非常重要, 我们需要在这段时间内, 获取到真实的用户留存率和增长率, 从而安排后续的推广手法, 从而设计好完整的盈利通道. 有些团队, 不为产品设置静默期, 只是想着产品一上市就推广, 这时候, 遇到的问题就是推广没有具体方向, 没有自己核心方向定义, 最终推广就是浪费钱, 也很难获得快速增长能力.

用户信息收集1. 确定产品在实际市场中的受欢迎人群 2. 完成用户真实需求点的挖掘 3. 确定真实赢利点设计 
错误修复1. 从用户反馈错误内容 2. 有针对性的重构/优化代码 3. 解决产品使用过程的障碍 
推广策略设计1. 寻找推广渠道 2. 建立针对群体使用场景设计 3. 保证自然增长率的有效性 4. 研究技术市场演进状态 
推广期 

这是项目的最后一个时期, 这个时期, 我们的工作方向就转为自省了, 从现有的项目中获取反馈, 然后作为下一个版本项目的基础. 同时, 也是建立盈利流程的过程, 最终为企业获得增长机会.

开启推广渠道1. 以有效递增的模式进行推广 2. 测试不同的渠道 3. 建立售后服务准则 4. 为推广做技术配置 
新版本需求收集1. 建立版本需求管理池 2. 从当前版本中, 获取新需求灵感 3. 从用户反馈中, 获取新需求灵感 
财务与市场分析1. 做精准的财务分析(明确到未来2年的规划) 2. 产品的后续市场规模增长模式判断 3. 市场拓展的设计 4. 提供财务运作的协同作用 
项目的总结 

项目的总结是非常重要的一个步骤, 在这个步骤中, 我们可以补充或调整上述的工作流程, 让这个流程, 更好的为下一个项目提供参考功能, 减少了同一个团队内, 项目反复走弯路的错误. 所以, 在做项目总结的时候, 必然要重新制定一次上述的流程表, 甚至于, 每次项目的总结都会导致这个流程表面目全非, 这就需要我们花费更多精力, 为自己的团队整合出一套更合适的流程出来.

附录1 开发编码规范(Swift语言向) Common 

驼峰式命名为主

类命名 Class 

界面控制器—XxxVC

子View继承 — XxxView

控件继承 — XxxControl [继承自UIControl]

XxxButton [继承自UIButton]

XxxLabel [继承自UILabel]

XxxText [继承自UITextField或UITextView]

…

逻辑控制器 — XxxManager

数据模型 — XxxModel

子模型/数据Struct/枚举 — Xxx (不加任何后缀)

函数命名 Function 

标准函数, 以动词作为函数名, 或者动词加宾语作为函数名.

如果是动词就是小写开头 xxx, 如果是动词加宾语, 就是小写开头, 之后还是驼峰结构, xxxXxx

全局函数, 不在任何类内部,必须以大写开头, 以区分普通的函数.

事件回调函数, 必须在前面添加on, 比如onClickXxx, onTimerXxx

数据格式转换函数, 必须在前面添加to, 比如toXxx

数据生成函数, 必须使用build做前缀, 比如buildXxx

界面配置函数, 必须使用setup做前缀 比如setupXxx

数据格式或内容检查函数, 使用check作为前缀, 比如checkXxx

数据加载函数, 使用load作为之前缀, 比如loadXxx

一个函数的内部执行函数, 使用do作为前缀, 比如doXxx

属性命名 Property 

标准属性, 采用名词作为属性名称, 或者名称加上其它内容, 采取第一个字母小写, 后续驼峰的格式

单例 shareInstance

条件判断 isXxx

格式转换 xxxValue

对象命名 Object 

全局对象 g_xxxXxx

静态对象 s_xxxXxx

一般对象采取第一个字母小写, 后续驼峰的格式

项目组织规则 

ViewController, 放在最外层, 直接展示

控件, 表格Cell, 放在View目录下

配置文件和内容, 放在Config目录下

资源文件, 放在Resource目录下

逻辑代码, 放在Logic目录下

第三方库, 放在ThirdParty目录下

每个项目独立的资源代码 

UIColor+Def.swift 配置本项目所需的色彩定义

Notification+Def.swift 配置本项目所需的消息定义

Appearance+Def.swift 配置本项目所需的所有界面配置定义

UIButton+Fast.swift 配置一些本项目独有的按钮快速配置定义

UIView+Fast.swift 配置一些本项目独有的View快速配置定义

Xxx+Fast.swift 配置本项目独有的其它界面所需的快速配置定义

附录2 美术产品输出规范 设计稿 

最好是以HTML的格式输出, 开发者可以根据设计稿进行界面细节的配置和调节.

每一份设计稿目录, 都有一个时间后缀, 比如”测试程序设计v1-20170101″, 表示这是2017年01月01日的设计稿.

设计稿中的页面, 最好有一个分割, 而不是所有页面全部平铺展示.

切片输出 

输出的结果, 需要x1, x1.5, x2, x3几种格式, 由开发人员自取.

切片的目录, 同样要有一个时间后缀, 比如”测试程序切片v1-20170101″.

Logo/宣传页 

Logo以1024×1024为准. 如果Logo需要有圆角, 为Android输出的, 要独立做, iOS会自切圆角, 不需要设计师提供圆角图片.

宣传页一般以1242×2208为准, 具体尺寸需求, 由开发人员需求决定.

设计规范文稿 

每个项目, 都必须有一个标准的设计规范文稿, 这个文稿定义了如下内容:

色彩定义表, 有16进制RGB色值(如:FAFAC2), 10进制RGB色值(102,230,12), 10进制HSB色值, 以及这个色彩所用的地方. 
按钮状态定义, 分别针对标准状态, 按下状态, 无效状态做出符合本项目的具体描述. 
圆角尺寸, 在页面内容上, 要有一个标准的圆角尺寸规范, 设定圆角的大小. 
文本规范, 在界面的各个文本内容展示区域, 标明文本的规范, 包括字体, 子类型, 大小, 色彩, 字间距, 行间距等. 
阴影尺寸, 在涉及到阴影的地方, 规范阴影的长度, 色彩, 偏移等信息. 
内容区域规范, 事先定义好内容展示区域和页面整体区域之间的留白尺寸.