创业公司的研发架构：规范化研发流程

国内IT公司多如牛毛，但研发流程真正做到规范化的少之又少，很多公司看上去很“大”很NB，但却只可远观，细看内部作业却惊叹于庞大的躯壳下只是一个又一个的“小作坊”，毫无团队间协作分享可言。大中型公司如此，小公司创业公司更不用说了。

在我大天朝很多公司的产品拼的不是技术不是功能而是关系，所以研发流程规范这档子事不是企业必需品，尤其在传统行业游弋的那些国有控股公司。但随着竞争加剧、互联网化浪潮的洗礼，“高内耗低产出”的粗犷型作业势必会走向灭亡，“短平快”的精细型研发作业流程势必越来越受重视。

有感而发，扯了些废话L，言归正传，规范化研发流程的作用不言而喻，但对于创业公司来说现实的问题是要先生存再图发展，前期没有太多的精力在流程管控上，所以一个好的适合于创业公司的规范化研发流程一定要足够的省事简单且效果明显。

梳理一下我们的痛点就是“人少事多时间紧，需求变更快人员流动大”，一个好的研发流程要能解决以上的问题，怎么做？

免打扰：脚手架的活让工具去做，不要让开发管理人员被流程所累；
小版本快迭代：尽早地让领导/客户发现需求偏差，以便及时修正；
需求共享及知识库建设：让所有开发人员都了解产品的需求并建立知识库记录学习开发心得，最大限度减少人员流动带来的研发不可持续性；
自组织，弱化管理：不要在管理上浪费太多时间，屁大的团队开发人员远比纯粹的管理人员重要。

综上实际上很多人发现这些理念与Scrum多么雷同呀，不错，我们实践下来觉得用裁剪后的Scrum做为流程规范是很好的选择，但完整的Scrum对开发人员要求过高，创业团队往往不具备那样的员工，所以一定要裁剪。

拿目前我所在的公司“聚路销科技”举例（不同的公司有其个体差异，仅供参考），下图是我们研发流程的TOP图：

我们整体上基于Scrum并适度裁剪，如Scrum要求Story时间点要所有开发人员在Sprint计划会议中投票决定，我们试行几次下来实际需要时间与估算时间会严重不符合，为什么一个原本为更准确计算工时的做法却得到适得其反的效果？原因在于创业期招聘的开发人员经验不足，考虑问题不够全面，普遍低估了各个Task的要求，所以在Story用时上我们往往是技术经理做评估并在Sprint计划会议时和开发人员确认修订。

基础研发流程与Scrum无异，关键步骤如下：

步骤名	参与人	产出	涉及工具
1.设计用户故事	产品经理	Product Backlog	Redmine 用于记录 Product Backlog
2.Sprint计划会议确定Sprint周期、人员及要完成的故事	所有人	Sprint Backlog	Redmine 用于记录 Sprint Backlog Raneto 用于简述产品及Sprint信息形成知识文档
3.编码开发	开发人员	Code	Gitlab 用于版本控制 Jenkins 用于持续继承，自动化测试发布 Sonarqube 用于代码质量检查 Redmine 用于记录变更
4.每日站立会议	所有人	阻碍列表、Story、Task或Code修正	Redmine 用于记录变更
5.Sprint回顾会议	所有人	Sprint封包代码、版本发布	Gitlab 建立版本 Redmine 完成Sprint Raneto 总结经验形成知识文档

工具选择的几点看法：

在Scrum管理工具上我们尝试过白板、Trello、Redmine With Agile Plugin，各有优劣吧，白板直接，大家都看得到，很方便，但不便于任务收集整理，Trello是个好东西，它有个开源实现版本（http://git.libreboard.com/libreboard/libreboard），看板视图，可定制化流程，但统计上比较弱，Redmine With Agile Plugin（http://www.redminecrm.com/projects/agile/pages/1）嘛比较重，但功能强大，用它主要是我们的绩效考核需要记录每个开发人员每个Sprint的工时、每个Task的技术系数、Task的重要程度等指标。

版本控制上一般公司用SVN，我们用Git，说二者有多大的区别嘛，对小团队而言还真看不大出来，但我们鼓励开源，要求员工都要发布自己的开源作品，所以用Git比较接地气 :)

知识库工具这里用Raneto，这是个很简单的Markdown文档web化工具，你只要指定一个有MD文档的目录它就可以把这些文档Web化显示，用的是NodeJS驱动，它还支持"GitHub Flavored Markdown"，可以显示表格：

我们流程是在Gitlab中建立知识库项目，大家都clone这个项目，用自己喜欢的IDE撰写MD文档并push回Gitlib，然后Jenkins会自动clone出变更项到workspace下，我们又在Linux中建了定时任务把Jenkins workscpase下的文件sync到Raneto的目录，这样就可以显示修改的文档了。

Jenkins 与 Sonarqube没什么可说吧，同一领域应该找到其它更好的工具了。

另外补充一点是创业团队硬件资源也比较有限，而管控工具不少，个人推荐用Docker去虚拟化这样环境，好处是使用方便，不用安装一大堆基础环境（如ROR环境），安全明了，做到资源隔离，不会因为一个工具的问题导致其它工具被Hack。这方面有机会再单独讨论。附我们目前的Docker容器：