一般来说我们的软件项目中通常有各种流程规范,比如:
- 开发人员不能直接在生产环境中修改代码操作数据库,必须在本地先测试验证后,由运维操作
- 代码需要review通过才能合并到主分支
- 代码需要遵守各种规范,向命名、格式,还有缩进用几个空格还是tab的细节问题
- 遇到bug,先提交bug跟踪系统
一、为什么要有流程规范?
从某种程序上来说,流程规范确实是一种约束:约束了我们如何做一件事,约束了我们用什么标准做事,约束了我们用特定的顺序做事。
既然如此约束我们,为什么还要有流程规范呢?
1.1 提升团队效率
从个体来看,因为流程规范的存在,确实可能存在效率降低的情况,但是从团队的角度来看,好的流程规范反而能提升效率。
这其实很像我们生活中的红绿灯,用一个简单的规则:红灯停绿灯行,来约束车辆行人按照指示灯行进。
从单个车辆来看,看似是因为红绿灯的存在而影响了效率,但是从整体来看,因为红绿灯的存在,避免了拥堵,反而提升了大家出行的效率。
其实红绿灯除了能提高效率,还有其他好处:
- 红绿灯这样有效的管理交通的经验,形成流程规范后,就可以让全世界共享这种先进的经验
- 红绿灯不再到处依赖人指挥交通,而变成了让红绿灯的规则来指挥交通
软件项目中的流程规范是不是也有这样的效果呢?
- 以代码审查规范为例,对于技术高的程序员来说,代码审查可能会耽误一点时间,但对整个团队来讲
- 即使是水平高的程序员,也可能会被发现有错误,代码审查可以降低出错的概率,保障质量
- 对于水平低的程序员,可以通过代码审查学习和成长,代码被高水平程序员审查之后,可以有效提高质量。
软件项目中这样的例子还有很多,类似的还有遇到bug要提交bug跟踪系统,还需要配合重新步骤说明,看起来繁琐,但是却让bug可以有效跟踪,让开发人员可以重现和定位,从而高效的修复bug
1.2 将好的实践标准化流程化,让大家可以共享经验
我们知道,在运动项目上,有些运动员特别有天分,总能拿好的成绩,而这些运动员的动作,会被反复的研究学习,最终形成标准化动作。而其他天分一般的运动员,按照研究出来的标准动作练习,也能取得非常好的成绩。
软件工程也是这样,早些年的软件项目,就是个人英雄主义盛行的时代,项目的成败极其依赖于个别厉害的项目经理或者技术高手,而这种牛人,总是稀缺的存在。
所以后来很多编程高手写代码的方式,甚至写代码的格式,也会被研究,最终形成一套套的代码规范。其他水平一般的程序员,按照代码规范,也能写出不错的代码。
代码规范还有个好处,就是大家写出来的代码看起来差不多,换个人接手别人的代码,也能很快上手。
1.3 借助流程规范,让项目管理从人治到“法治”
管理就是管人和管事,而管人,就要借助流程规范来管理。
因为如果在项目管理中,过于依赖人的管理,项目经理就会成为瓶颈,大事小事都需要项目经理来决策。再说项目经理也不能保证每次决策的正确性,如果决策失误,会很可能导致一些冲突。
而好的项目管理,不需要直接管人管事,而是管理好计划和流程规范;项目成员不需要按照项目经理的指令做事,而是遵循计划和流程规范。
比如敏捷开发中,项目成员日常从看板就可以知道要做什么任务,代码审查、自动化测试可以有效保证质量,项目文档可以保证新人加入时能快速上手,结对编程可以保证新人遇到问题可以得到直接的帮助。
还有一个常见场景就是需求变更,产品经理想加一个紧急需求,这通常是让项目经理为难的事情:加吧,影响项目进度,开发人员有意见;不加呢,可能客户或者产品经理有意见。一个不小心就两边都得罪了。
如果你有一个大家认可的需求变更流程,就不再需要靠项目经理一个人决定该不该加需求,而是通过流程,来大家一起决策是不是要加这个流程。
二、如何制定好流程规范?
在项目管理中,难免要去制定流程规范。即使你不是管理者,也可以提出合理的流程规范,帮助把项目管理好。
有一个科学的制定流程规范的方法,可以让你更好地制定出好的流程规范。
2.1 制定流程规范的四个步骤
第一步:明确要解决的问题
要制定一个流程规范,第一步就是明确你是要解决什么样的问题。项目中很多问题,都可以思考是不是能通过流程解决。
比如说有程序员在生产环境操作,误删了数据表,造成了严重问题。如果只是对程序员进行处罚,寄希望于小心谨慎避免类似问题,那么下一次还有可能会有类似的事情发生。
如果说在流程上规范起来,例如:数据库操作之前先备份数据库,事先写好 SQL 语句,需要有人审查,测试环境先测试通过,最后再生产环境执行,那么就可以避免以后再出现不小心删除数据表的事情发生。
第二步:提出解决方案
对于问题,也不用着急马上就想着用流程规范,可以先思考解决的方法,有了方法后再进一步思考是否能提炼流程规范。
那么方法和流程规范有什么区别呢?
相对来说,方法更有针对性,可能只适用于特定场景或者特定人,而要将方法上升到流程规范,则需要有一定的普适性,能变成具体的步骤或者标准,让每个人都能执行。
比如说服务器部署后出现问题,高手可能就直接上服务器操作,直接修改代码编译解决,这是一个解决方法,但这不能成为一个流程规范,因为换一个水平不行或者对代码不熟悉的人来做,可能会搞出更大的问题。这时候回滚操作就是一个相对普适的方法,可以变成一个部署后出现问题的流程。
在提出解决方案,制定开发流程时,可以参考借鉴软件工程中,大家公认的好的实践。比如说:
- 敏捷开发的流程:虽然你的项目不一定采用敏捷开发的方式,但是敏捷开发中一些好的流程是可以借鉴的,例如参考看板、站立会议、持续集成,这些好的工作流程,都可以借鉴。
- 代码规范:其实很多公司都公开了他们的代码规范,可以直接基于这些规范制定团队的规范。
- 源代码管理流程:现在的源代码主流是 git,而基于 Git 的代码管理已经有很多成熟的流程规范可以参考
- 部署流程:十年前,每日定时构建还是很时髦的部署流程,而现在,主流的部署流程已经变成了持续部署,每次代码合并到主分支都可以触发一次自动部署,这样一有问题,就能马上知道发生在哪个环节。
第三步:达成共识,推广执行
在流程规范提出后,还需要得到大家认可,只有大家认可,达成共识,才能共同遵守,保障制度的执行。
对于大家都认可、很重要的流程规范,一定要让大家严格遵守,必要的时候需要配合一些奖惩制度,以保障其执行。
比如说流程规范的执行和绩效考评挂钩,对于没有执行的需要私下沟通提醒,严重的需要批评教育。否则流程规范会形同虚设,没有太大的意义。
第四步: 持续优化,不断改进
流程制定后,在实际执行的时候,难免发现一些不合理或者不科学的地方,这时候就需要对其进行调整。
还有一些流程规范,随着时间推移,可能已经不能适合要求了,也需要考虑改进甚至抛弃,不然反而会成为一种阻碍。
比如说以前采用瀑布模型开发时,项目经理因为需要了解进度,所以每个项目成员要写日报,如果有站立会议了,日报这种形式就可以完全被站立会议替代,没有再存在的必要。
2.2 将流程规范工具化
应该尽可能借助技术手段来推动甚至替代流程规范。
- 例如说代码规范,以前代码规范的执行,主要靠反复的教育宣传和代码审查中一个个去检查。而现在,借助 VSCode 这种强大的 IDE,以及 ESLint 这种代码检查工具,可以方便的检测出不符合规范的代码,甚至于可以帮你直接格式化成满足代码规范的格式。
- 还有像保证代码质量的问题,早些年必须依赖测试人员大量手工的测试,而现在借助CI(Continuous Integration,持续集成)、自动化测试和 Git,可以保证代码必须在通过测试以后,才会合并到主分支,从而很好的保证了代码的质量。
“软件工程”不要过于依赖流程和管理手段,要思考怎么通过技术手段去解决问题。
三、总结
- 流程和规范,就像红绿灯一样,不是一种约束,而是牺牲一点个体利益,提高团队效率;流程和规范将好的实践标准化流程化,让大家可以共享经验;流程和规范,让项目管理从人治变成“法治”。
- 要制定好项目规范,先明确要解决的问题,然后提出解决方案,看是否可以通过流程规范来解决,有了方案后需要团队成员一起达成一致,最后再推广执行。在执行过程中需要持续的优化,不断改进。
- 对于需要手动操作的流程,可以思考是不是能采用技术手段自动化,通过技术手段去解决。