什么是开发工序管理
所谓的开发工序管理，就是把开发人员的工作步骤管理起来，以期其产出的代码达成组织期望的代码质量。
为什么需要工序管理
DevOps的理想和现实面前，有一个开发工序管理的鸿沟。
很多组织落地DevOps时，只把工具链、平台都搭好了，但并没有项目在这个平台上按照DevOps期望的节奏运转，也就是不能快速发布，价值并不能持续的流动，基本上都是卡壳的。
这是由于开发人员不能生产出可以快速回归的软件，自然不能快速发布，就算是快速发布了，也是可能有质量问题隐藏在其中。
这个问题持续不能解决的原因是因为开发人员缺乏开发者自测试的能力，需要规模化写测试的能力，否则我们无法形成可快速回归验证的软件。如果不能规模化写测试的能力的话，DevOps的落地最后就是开着敞篷跑车上太空，就算你飞上过去一次，也不应该有第二次。
规模化之前，我们先看一个胜任的个体是什么样，我们横向比较一个开发者自测试能力强的和一个这方面弱的程序员的工作就会发现他们的工作步骤完全不同。
强的开发人员能够按照架构设计把需求分解为可测试步骤组成的工序，并能按照工序高效得写出有测试保护的代码。弱的人则只能拆解为写代码的步骤，至于能不能测试，就不再考虑范围之内了。尽管他们后续的工作时间都差不多，但是产出的代码一个有测试，一个没有，而且也很难加。
而在我们过去的过程改进经验中，能够按照架构设计把需求分解为可测试步骤这件事，并不容易，需要特定的胜任力——分析型思考和少量的概念性思考，而这两者在软件开发人员当中是很稀缺的。于是导致前一种工序很难被推广开来，而不解决这个问题，我们产出的软件始终是一个难以快速回归的软件，所以我们需要工序管理，可以帮助我们规范开发人员的行为，规模化的使开发人员可以高效的产出有测试保护的代码。
怎么做工序管理
在讲解怎么做工序管理之前，首先要讲一个概念：杠杆率。
杠杆率就是我们认为胜任的高级人员（后面称之为Sr.)和不完全胜任的初级人员（后面称之为Jr.）之间的比率，比如一个Sr.带着5个Jr.杠杆率就是5，称之为杠杆率高，反之，如果2个Sr.带1个Jr.杠杆率是0.5，称之为杠杆率低。
那么介绍这个概念的目的自然是，在杠杆率不同的情况下，工序管理的手段是不同的。
如果杠杆率比较低，也就是初级人员是宝贝，高级人员团队里到处都是，那么就不用费劲了，给初级人员设置个导师，一个不过瘾还可以多设置几个。一副江南七怪教郭靖的架势（这个比喻应该还不算过时吧……），一群老师盯着你输出的代码耳提面命，我就不信你学不会。
这也是为什么早期的工程实践方法论里，较少提到这个概念的原因，因为在当时的西方社会里，低杠杆率是普遍现象。
然而在中国，这个现象则完全不成立。我们这个行业以25%的增长率暴增了这么多年，现在的情况是，不但杠杆率高，而且Sr也未必胜任。这个时候我们就需要针对目前的现象进行更适合中国特色的工序管理。
首先我们要聊一聊架构，因为架构是指导如何进行工序分解的，对于我们怎么做日常编码工作是有强烈的指导意义的。如果架构本身就不是容易测试的，那么对应的工序也就很难形成，或者其中某些步骤的测试成本过高。由于我们这个行业发展过快，我不确定我们现在的架构师们，是否在这件事上是普遍胜任的，从现状来看，普遍不胜任可能更接近事实。可能工序管理的第一步还是先帮助架构师搞出可测试性比较高的架构才行，起码别跑个测试还要上硬件或者部署到UAT环境，那就不太合适了。
接着，我们需要给我们的Sr人员进行培训，让他们的可以做到“按照架构设计把需求分解为可测试步骤组成的工序，并能按照工序高效得写出有测试保护的代码”。然后由初级的人员，按照工序编写代码。
接着，就是工时管理，我们拆分出的每个任务，都应该在一个固定的时间内完成，如果没有在固定的时间内完成，我们则视为是一个事故，需要针对该事故做分析并提出改进计划。通常就可以发现要么是工序拆解的有问题，要么是初级人员的能力有问题，都可以针对性的进行能力建设。
落地的细节
架构师是否拆解工序
架构师首先应该学会这件事，毕竟他要能解决工序如何拆分的问题。所以还要打个样，看看工序怎么拆分，是不是可以拆为生产可测试代码的工序。然后他自己也要写一下代码，看看工序映射为代码的过程是否会遇到障碍，有时候自己写一下会发现之前很多关键细节没有想清楚，这对于架构师也是有好处的。
Sr首先自己要胜任
这点其实也不是很常见的一件事，毕竟不胜任在我们这个行业太普遍了。Sr首先自己要能拆出来可以测试的步骤，而这一点其实并不容易。首先是对于很多人来说，能够分解为可测试的每一步就已经很挑战了，而当把这些步骤映射为代码时候，我们会发现更多的人根本不能按照自己所划分的任务进行正确的映射。写代码的步骤可能和划分的步骤完全对不上，更不要说每一步都可测试了。这里是能力建设的一个关键点。
优化无止境
通过对工序的完成时间进行追踪，我们不但可以得到高效的个人，还可以发现效率的瓶颈，进一步的改进工序，比如开发一些工具。
工序管理是否复辟了软件蓝领的概念
先说结论，并不是。因为软件蓝领是只写代码，把程序员压缩在编码在一个小环节里面，不端到端考虑问题，不管需求，不考虑怎么测试。
而工序管理只是压缩在了一个更小的问题域里，但是这个问题仍然是需要理解、需要思考、需要测试的。
我们要承认普通开发人员可能在当前阶段的认知水平不高，所以我们的工序管理是一个生手和熟手配合的工作方式，是追求一种更大杠杆率的生手和熟手配合的场景。
通过高级别人的人一种更高效的传帮带的方式教会普通开发在当前业务下、当前架构下进行工序分解的能力。当生手的认知能力变得提高之后，他可以自然的去解决更大的问题，而不是把开发人员从高级工作中隔离出来，异化为一个可以随时被替换的螺丝钉。
比起软件白领与软件蓝领的关系，高级开发人员和初级开发人员更像师傅带徒弟的关系或者是教练和运动员的关系。