正规军的军规1

下面的文章是我转自我的老大Anderson的邮件，是对我们team一些问题的总结和经验分享。我里面有很多是可以拿出来与大家共享，所以得到作者的同意之后我把原文贴到了这里。

PS：文章取名《正规军的军规》是稍微有些戴帽子了，但是我当前所在的team是确实是我工作以后最正规的一个team，而且我觉得我们通过cmm5并严格执行的开发团队也可以称得上是正规军了，从项目启动到项目发布每个过程都是很严格的，而且在我们team里面要求的更加严格，我们在整个项目里面是质量最高bug最少的一个team。不过文章的内容很多地方也仅仅是我们team内部的一些经验的总结，不同的team应该有不同的军规。

<!----><!----><!---->  <!---->

编码人员的误区

误区一：因为任务紧迫，所以没有时间想

有些人认为只有在领导规定的时间内完成任务才是最重要和最紧急的。至于方向是否正确，功能是否完整则没有时间去考虑。

这些人陷入了多写些代码和程序就会安全了的假象当中。殊不知方向错了，跑得越快，损失越大。

抱有这种想法的根本原因在于他们的不自信，不知道如何分析问题，找出最佳解决途径和细致的评估影响面，因而无法向上级提出一个更加合理的时间。

例如： Bulk Address feature 的设计者也是说时间紧，没时间细想。后来的结果就是这个 feature 的 design 和代码被一次又一次的推翻和重做。而我们的 leader 也因为反复的向 Jerry Lu 解释上次做错了能否接受我们新的 Solution 而招致了 Jerry Lu 的反感。

 

误区二：在最后一刻告诉 Leader 代码写完就算开发任务完成了

这种人认为只要写完代码告诉 Team Leader ，自己就可以交差了。

如果做错了，大不了重做；

如果漏做了，大不了补做；

如果 bug 很多，大不了 fix bug ；

自己没考虑到，还有 Team Leader

例如：分配给做 Multi Agency admin 端 code owner 的开发时间原本是足够的。但是他写完代码后，只验证了最基本的增、删、改、查功能，主要的业务逻辑和其他的边边角角的功能都没有测试，直到上级规定完成时间的最后一刻他才对 Leader 说任务完成了。

这样做的严重后果有 2 个：

<!---->l  <!---->由于这个开发人员缺乏责任心，导致我们不得不花了比原计划多出 30% 以上的时间去补做和补测

<!---->l  <!---->开发人员没有意识到之前他的 Leader 对他的能力不太熟悉，所以给他的时间会比正常情况下多一些。只要发挥出正常能力和应有的责任心就可以提前完成任务。结果他不但没有完成任务，还浪费掉了预留给他的时间。这种情况下他的 Leader 对他能力的评估只会更差，同时也增加了 Leader 对他能力的不信任。

 

误区三：领导说得都是对的，我没意见

例如：一个 Leader 在给组员讲解需求和设计时，希望大家都能够提出自己问题和想法。有个组员就对这个 Leader 说你的分析设计能力比我强，工作经验比我丰富，你说的都对我能有什么意见。

发生这种现象时，开发人员和 Team leader 都有需要改进的地方。

开发人员这么说，有下列几种可能：

<!---->1）  <!---->他当时心情不好正在闹情绪，这时开发人员应当注意控制好自己的情绪

<!---->2）  <!---->他真的是全听懂了，只要回答“我全明白了”就好了

<!---->3）  <!---->绝大多数内容他没听懂，这时他可以回答“我暂时还不能完全理解你说的所有内容。我下来再仔细看看文档，估计 30 分钟后再来问你好吗？”

Team Leader 对于那些能力比较弱的人可以采取如下措施：

<!---->1）  <!---->给组员一些准备时间，在讲解前告诉他们着重看那部分内容。

<!---->2）  <!---->讲解完毕后，可以让组员讲出哪些分析点是他之前没有想到的，怎样分析才能够分析的比较全面。

<!---->3）  <!---->如果组员的分析能力实在太弱什么也讲不出来，我们还可以鼓励他们说出哪些内容他们没听明白。

这样一来，我们对组要的要求就可以做到因人而异，且比较具体化。同时我们要求的也是组员能够做得到的。 Team Leader 要学会 Case by Case 的教导组员如何逐步提高。

 

误区四：凡事都有 Team Leader 帮忙检查

例如：有一次 Hikelee 让一个组员给他写一封需要回复给客户的邮件。很快这个组员就告诉 Hikelee 写完了。

Hikelee 就问他说“我是否可以不做任何修改就可以把这份邮件直接发给 Anderson ？”这个组员回答说不能。 Hikelee 就让他拿回去参看以往 Hikelee 发出的类似邮件去改，直到达到这个标准后再发给过来。

过了一会这个组员又说写完了。这次 Hikelee 又问他，是不是 Anderson 也不需要做任何修改就可以把这份邮件直接发给我们的客户？组员回答说不能。 Hikelee 就对他说在去看看 Anderson 以往是怎么回复客户这类问题的，找到差别修改后再发给我。

 

误区五：只提出问题而不负责解决，解决问题是 leader 或 PM 的事

例如：有些组员会问，我们这个 release 的加班好像是比上个 release 少了一点点，但是说实话还是太多太频繁，我们能不能少加点班？

问话的组员只是提出了问题，却没有思考是不是有些必须要加班才能完成的任务自己也有责任 ? 有的话原因在哪里，你认为怎样做才能够减少或避免类似的加班？

经过我们的分析，导致这类加班我们自身的原因主要有：

<!---->1）  <!---->用人不当，由能力不足的人作分析设计导致设计失误太多，必须要花更多的时间检查和修补

<!---->2）  <!---->缺乏有效的分析设计技巧导致和业务领域知识，导致 Effort 估计不足

<!---->3）  <!---->编码和 UT 素质较差，需要成倍的时间进行修补和返工

<!---->4）  <!---->工作效率低导致在规定的时间内未能完成任务而加班

<!---->5）  <!---->工作方法不当，一些无谓的等待导致了加班

根据不同的原因我们可以采取不同的策略来处理。

 

误区六：整天写代码太单调太没劲

有的开发人员觉得自己整天都在写代码， fix bug 没劲。对上级布置的任务也太当回事，抱着应付差事的心态在做事，你布置一件我应付一件，你说怎么做我就怎么做，反正办好办坏都一样。

实际上我们应该认识到无论是谁，无论能力高低都必须做到让领导对自己所做的每一件工作满意，才有可能接受更高难度和更有挑战的工作，他的职务薪资也会随他所从事的工作难度的提高而逐步提高。

例如：以我为例，在转到 Accela 部门前就已经是 Team Leader 了。但是我还是被安排到从基本的编码开始，独自负责一个 Feature 。我把这种安排当作是一次对我的考验，尽自己最大的努力做好。结果这个 feature 做得很好，并且在做的过程中体现出了优秀的技术能力、学习能力、沟通协调能力和很高责任心和使命感，证明了我做 Team Leader 。因此在这个新的部门做回了 Team Leader 的职务。在做 Team Leader 的过程中，也是因为我所带领的 team 战斗力强，队员素质提高快而被提升为 PM 。

一个开发人员，只有在他的代码写的很好的情况下，才能够获得需求分析和设计工作；只有在需求分析和设计做得都很好的情况下，才能够做 feature owner ；只有在 feature owner 做得很好的情况下，才能够获做 Team Leader 。

 

误区七：工作既然交给我做就应该信任我

要知道“用人不疑，疑人不用”只是个结果而不是过程。我们每个人都必须经过严谨的考验后，才能够逐步的取得领导的信任。在完成任务的过程中，领导可以观察出我们的能力水平。以后安排那些在我们能力范围内的任务时，他就可以比较放心，投入较少的精力。相反如果他安排了超出我们能力范围外的工作时，他就必须要投入比较多的精力来监管。因此，信任不是绝对的。

如果我们想要取得领导的信任，就必须要尽我们最大的努力来做好领导安排的每一项工作，提高领导对我们能力水平的认识，做到事事让领导放心。

 

误区八：因为一些在 bug 描述中没有提到过得 issue ， QA reopen 我们 bug 是不对的

例如：有这样一个 bug ， QA 只描述了在 Create Portlet 里有问题。后来 QA 在验证 bug 时发现开发人员只 fix 掉了 Create Portlet 里的问题， Search Portlet 也有同样的问题但没被 fix 掉，因此 reopen 了该 bug 。

开发人员就说“不对， QA 你没有提到过 Search Portlet 也有问题，这个 bug 不该被 reopen ，你应该提一个新的 Search Portlet bug 。”

这种思想是错误的，原因如下：

<!---->1）  <!---->不要急着先说人家 Reopen 不对，首先自己要先核实 Search Portlet 里的 bug 和 Create Portlet 的 bug 是否无关。如果确实无关再耐心的和 QA 解释为什么应该提一个新的 bug

<!---->2）  <!---->但是无论如何出现这种状况，我们的开发人员自身也有问题。他们不了解， fix bug 不是头痛医头，脚痛医脚。我们首先要找到 bug 的成因，然后分析这个 bug 成因的潜在影响面，最后彻底的 fix 掉这个 bug 。另外， bug 有个扎堆的原理，当你发现一个地方有 bug 时，往往周围出现 bug 的几率就会比较高。所以我们一定要在这个 bug 的周围多做一些测试。

<!---->3）  <!---->不懂的只有高标准严要求，才能激励自己更快更好的发展。

<!---->4）  <!---->这种工作人员的工作心态也有问题，错了就是错了，不要对自己的错误做过多的辩解。知道自己错误，错在哪里，然后下次能够改进就好了。因此我们需要及时的调整好自己的心态。

 

误区九：上班时浏览技术网站学习新的技术没有问题

我们不反对组员学习新的知识。但是应当是在自己当天的任务已经完成的前提下。如果研究的内容与我们的工作有关，我们还会鼓励。

例如：为了提高 fix bug 的效率我们要求在 Fix bug 阶段，确认一个不能重现的 bug 最多不能超过 2 个小时。这个规定早上刚刚讲完，我们就发现有个组员确认了 2 个不能重新的 bug 后，就去上网学习新技术去了。

 

Team Leader 的误区

误区一：处理客户问题和处理一般开发任务没有区别

有些 Team Leader 或 Feature Owner 认为，处理客户问题和处理一般开发任务一样，都是把代码写完并完成 UT 就好了。

例如：有个组员在处理 Andrew D 要求增加实现 Filter Service 功能时，代码做完了就报告给 PM 说任务完成了。他忽略了 Andrew 提出这个要求的目的是为了在 IST 站点上给他的客户进行 Demo 。

因此我们不仅需要在 QA 和开发站点上测试，还需要在 IST 站点上更新和部署相关的代码和配置 (EMSE Script) 以验证 Andrew 不需要做任何配置就可以看到这个新的功能。最后在 IST 站点上也验证通过后，还要回复 Andrew 一封邮件，告知他问题已经解决。

 

误区二：任务分配出去后 Owner 有问题就来找我，但是我很忙没时间找他

Leader 要对自己管辖所有 Feature 心里没数，在分配给组员去做之前能够预见到可能出现的风险，提前告知 Owner 预防风险或者密切观察 Owner 是否能够自己发现和规避分风险。如果问题出现了，我们要帮助组员认识到导致问题的原因是什么，哪些方面的能力和技巧他需要学习和改进。

平时也要多和组员沟通，不要误认为组员不来问我就代表没事。

例如： Hikelee 自己在做 Dynamic Web Service feature 的 Expression 部分，就把 Bulk Address 和 Alter ID Mask feature 分给了他的 2 个组员去负责，中间几乎很少过问和检查 feature 的状态。结果两个 feature 双双都出了问题。

 

误区三：工作态度好，工作年限多的就可以做 Feature Owner

不是只要工作态度好，工作年限多或者希望当 Feature Owner 的人就可以做 Feature Owner 。这个问题的本质是用人要当量才而用。例如，有的人做事认真，但是面向对象的分析和设计能力较弱，就不能安排他去做分析设计工作；有的人分析能力较强，但是考虑问题不周做事常做一半，处事和沟通技巧欠佳，就不能安排做 Team Leader 。

 

 <!---->

才看了两点就发现两个大问题，其他的就以后在看吧。
第一，是不是会想，不完全是时间紧张不紧张问题，而完全是你们的组织和方法要求的问题，这很少与开发者自身有关。很多时候，一些企业希望把底层人员放在一个隔间里面叫他们完成自己的工作，而不叫他们相互交流。你在那边没见过这样的企业吗？反正国内是很多。在这中企业中不鼓励大家思考自己小隔断以外的事情，而且他们的所作所为完全是被规定好的没有半点商量的。
而且越是这样的企业，通过cmm高级评估的可能性越是大，而且在某些人看来只有这样才是正规军。不过确实他们也想军队，因为他们不需要有脑子。
当指挥员发出冲锋指令之后，战士们玩命快跑是应该的。他们究竟应该跑向什么方向，应该是指挥员负责的事情。
当然如果你的企业没军事化喜好，是另外一个问题。
而这个时候，就不应该有什么时间紧的问题。因为你既然叫别人对某些事情负责，就该给他们相应的资源。

第二点就不是人是的问题，而是你们实施方法的问题。
一个开发者的进度情况，不应该是依靠他们自己主动的汇报，而应该是依靠leader主动搜集。搜集有各种不同的方法，不断的去询问是一种低级的做法。依靠scm等系统自动的获得数据才是应该追求的。

其实从这两个地方看，所谓的agile跟cmmi的结合就是概念罢了。当然我的这些发言完全是针对Anderson说的。楼主自己没什么问题。

2 我是一个喜欢工具的人，如果有工具可以自动做，我绝对不亲自动手。所以要是有好的scm系统（scm是指Suply Chain Manage吧），我才懒的收集进度呢。但是这里就又有了新的问题了。
一 不断的询问不仅仅是询问进度，更重要的是讯问有没有遇到什么绊脚石，我就经常在询问的过程中发现队员也许被一些我曾经遇到过的问题所卡住了，或者被一些外来因素所干扰，我可以很快的帮他踢开绊脚石。我觉得询问是一个有效的管理方法。agile中的master也是这样一个角色，帮助大家踢开绊脚石。
二 我在一个公司曾经使用过jira，当时jira给我的感觉是无形中增加了我的工作，作为开发人员，有时候下班都在研究一个问题，然后就关机走人了，这时候就很容易忘记去填写状态信息。在agile中，也没有使用什么强大的系统来收集，而是用卡片加每日站立会议的方式来收集状态信息。

最后，说句实话，我对cmm并没有o6z那样系统的学习，我的方式是参与到其中来实际体会他的优劣（不过我们的实践是否准确这就是另外的话题了。），在实践的过程中我确实发现了不少问题，很多工作在我看来是没有价值不大的，但是在后面的过程中我发现一些我人为价值不大的东西恰恰在出现冲突的时候起到了关键的作用。我觉得这就是cmm的问题吧，臃肿，肥胖，但是安全，稳定。而且我也认为cmm和agile是水火不容的，cmm和agile都不应该是一个简单的规则去判断是属于agile还是属于cmm，两个东西都仅仅是为了提高软件开发速度，准确，和能力的一个概念罢了，比如说我可以在充分沟通后用需求规格书来要求用户approved他的要求就是这样的（cmm的做法），我也可以在沟通过程中使用user story的方式来并且使用‘存在缺失调查问卷’来明确需求和需求级别（agile的做法）

就第一个问题，我觉得核心点在于是不是应该应用战士和指挥员这个方式，和应用这个方式需要一些什么条件。而在军事指挥中一个最大的特征，就死战士基本没有要求资源的权利，他们也没有做出决定的权利。而一旦他们可以要求资源，那么这个模式实际就已经不存在了。传统思维方式的问题就在这里，那些希望调和两种方式将传统引入现实的做法，也往往绕不开这个陷阱。在这个模式的特征战士思考是有罪的，指挥员是负责一切的。战士是不需要考虑对错的，指挥员的命令就是一切的尺度。战士越是不思考，这个体系越是有效。

而今一步有一个问题，几乎是没什么关注的。那就是cmm高级别实施制定的目标计划几乎都是可以被完成的，这一项是被认为是cmm的优点。并且很多反对cmm的人一再绕开这个关键点。而实际上这才是cmm这种方法是非理性的，非科学的，非管理学的，以至于非道德的。实际上为什么要计划，为什么要指挥，为什么要管理，根本原因就在于目标是不一定被实现的，并且是很可能不能被实现的。一个好的体系，不是保证你完全的完成你能够完成的目标，而是叫你能够不断的提高，去完成本不能完成的目标。好的方法和方式是教你不断的寻找极限并突破极限进行前进，而不是叫你原地踏步，以至于为了实现目标的高实现性逐步后退的。就好比你派一个1000人的部队，去一定确定的地点消灭一个5个人组成的没有武器非战斗不防御的小组，这样的目标你实施100次就应该成功100次。以这种方式进行指挥绝对不是一种好的指挥方式。
同时请注意我认为cmm的一个致命缺陷是其对于度量的支持不好，也就是进度的把握和显示不好，这一点一会我会在介绍软件度量的时候可能涉及到。

第二点也很有些地方需要深入思考。
拿传统的行业来说，一般情况下在生产中都会有工作记录，这个记录不仅仅是来自一线工人的实际用笔或者其他工具的记录，还有各种设备自动完成的记录。而好的方式，是通过设备自动完成来实时的掌握生产状态，而不是通过工人的汇报。比如你的生产出了问题，好的情况是你马上通过你的数据自动收集和处理系统掌握了情况，并进行针对性的处理。而差的则是，一线工人通过层次汇报才叫你知道已经有了问题。一个好的管理者应该是去建立这样一个自动化的实时系统；而差的管理者则会选择建立一个人和人沟通的系统。这里一个明显的缺陷是，通过逐级上报的方式，效率提高了，严密性就会下降；而严密性上升，就会带来效率的下降。你还需要在这个地方权衡和把握调整，付出的太多了。
你使用jira的抱怨我认为是正常的，但是你说你们使用过这个工具还是叫我失望的。因为你说了Anderson是你的老大（当然如果我没理解错，应该是写过一本书那个，至少上面的文字我看起来像的很），这样一个团队，不试图建立一个自己设计的项目管理系统绝对不是啥好事情。因为一般情况下，要么团队会选择一个最简单的软件系统，然后依靠其他手段进行管理协同。要么就是使用一个大的系统（现在做这个的公司不少，貌似MS也开始进入这个领域了），叫自己的过程完全满足这些系统的要求。而我觉得这都是没有在准备完善自己开个过程的操作中，逐步开发出一个自己的管理系统来的合适。因为你开发这个系统，就是在完善自己的流程，而完善自己的流程就等于在建造这个程序。
最后我对应用一个属于cmm还是agile的方法做判断十分反对，我认为应该应用传统的企业管理的手段来对这两个方法以及他们的做法做评估。应该尽量有物理的指标和计算，至少要有财务计算。在没有财务指标说明的情况下，究竟谁好谁会都是苍白的。而至少在直觉层面，敏捷方法在财务上占有优势。

呵呵，与高手交谈真的可以感触到很多。其实这几个月在cmm的team中工作，让我最为反感的就是估计与度量的问题。我们在开发前要对MD进行估计，在开发后要对bug数量进行估计。计划和进度是依赖与你的估计并要求严格执行的，一旦发生实际过程中与计划冲突的地方，那么只有自己啃下这些骨头，因为估计是你自己估计的。这样的压力会让我在估计的时候在原始的估计值上再乘以一些系数，用来保证我能够有足够的调整时间。（实际上这里还有一个利益的问题，我们这个外包项目是卖MD的，那么只要你能用充足的理由说服客户，一个feature自然是MD越多越好。）。所以在我看来，从cmm的角度来说，也许1000个人去打5个人并不是一个好计划，但是是一个不可能失败的计划，而cmm是不允许失败发生的，尤其是在外包公司，一旦某个项目失败，那么损失将会很惨重。当然，我要强调的是从cmm的本质来说，它是为了保证项目不失败而产生的方法论，这种方法论对于团队，对于个人来说也许不会有进步，甚至会产生退步，但是关键的是，项目最终成功了。

不过要感谢O6z的是，你的解释终于让我明白了agile中XP的来源，其实学了agile这么久我还一直都没有弄明白为什么叫XP，而不是simple programming，accurate programming 什么的。当然，我也认同，agile的确是高于cmm的管理方法论。不过我产生的一个新问题就是，在美国agile是在经历过cmm这种软件工业化才产生的，而我们国内根本就没有经历过所谓正规的软件工业化，如何实施才能保证我们不会误入歧途。那么就好比一个小孩还不会走，就让他学跑这样的拔苗助长方式。甚至我在javaeye里面看到很多人把agile和加班工作挂钩，做一个crud的模板方法就认为是agile了。呵呵，我喜欢agile也崇尚agile，但是我也很担心我们本来就单薄的软件底子会不会就这样因为agile而走火入魔了。而且，要明确的是，国内真正懂得agile的技术人员并不是很多，更别说如何有效的实施了。我认为我就是这样的一个人，我学agile是受了李默和徐浩的洗脑，但是后来都主要是自己的自学和不断碰壁不断总结，我觉得我这一路走过来是一路曲折，也是一路乐趣。但是我认为如果要是kent或者flower这样的人能够带我的话，我将少走很多弯路。

就度量问题需要做专门的讨论，而且这个是一般必须的讨论。这个问题可以说是现在软件开发工程方面一个最迫切需要解决的问题，注意是问题不是问题之一。现在虽然有一门学科叫软件工程，但是实际上这门学科还算不上是工程学科，原因就在于度量方面还没有到达标准。这个方面主要有两个方向需要去做，一个是寻找更多的物理参数，一个是寻找将现有物理参数进行组合以与软件的某些属性应对。而现在最迫切的一点是如何把现有的软件属性跟原有的企业经营系统进行连接。这个链接不是一个为连接而连接的事情，而是应该有理论有实际统计做基础的连接。比如人们常拿软件工程跟建筑工程类比，也有很多人反对这样的对比。现在的工作就是要将这两个学科进行对比和联系，当然是要有说的通的方法和原理方面的印证。比如说建筑的设计如何如何，软件的设计如何如何，那么是不是考虑到了建筑的设计在投资和资源分配的比例同软件开发中设计的差别这个关键的问题。在比如说建筑工程如何如何文档化，那么是不是考虑到建筑工程的文档化支持所付出的成本与软件工程文档化付出的成本之间的差别。这些东西如果你不考虑，不解释。仅仅单纯的凭外观去对照，就跟中医说的以型养型仅仅只能是一种模糊的说法（其实就是吃什么养什么，比如吃心养心，吃肝养肝，是没有科学依据的）
对于国内是否有正规化不是问题，因为我们还没有到已经讨论明白究竟是什么才能决定是正规化。其实就如同你说的正规军这个词，我很难接受，因为正规军并不能代表军事素养和战斗力，而仅仅是指其具备正式军队的资格和组织形式。而真正决定军队能力和素养的是职业化。实际上有很多正规军军队是由业余人士组成的，而很多非正规军是由雇佣兵这样的职业军人组成的，比如当初的非洲。忘记在什么书上看到了，说一个好的程序员的效率是坏的28倍。一个职业人士组成的团队，就将比一群业务人士组成的团队的效率高几个数量级呢？这既是一个软件度量问题，也是一个软件管理问题。在这些深层次的理念没有得到解决之前，谈改造和改变都还远点。

早上自由时间不多，中午再上来聊聊，首先先说明一下，这个Anderson可能不是你认识的那个，他是中国人，而且也不经常来社区。但是工作能力很出众，我觉得国内应该有不少这种能力不错，但是不经常来社区的人（这话的浅台词是国内的工作压力太大了，能力越强，通常给你分配的工作越多，而且不鼓励上班时间做与工作无关的事情，我一直在羡慕google那个20%的不工作时间，呵呵），另外jira是我在前面一个公司使用过的，和我现在工作的这个公司无关。

回到问题上来，软件开发和生产线是不可以类比的，因为生产线的工人每天做的工作都是单一重复的，但是软件开发从需求-分析-实现-测试-发布这个长过程来看想通过类似生产线的方式收集信息是困难的。不过这里引发了我新思考就是也许可以做一个这样的系统把整个开发过程串联起来，开发人员只需要提交各个阶段的材料，系统自动收集信息和判断状态，这似乎是个不错的idea（如何实现就是另外一个问题了）。再回到工具的问题上来，工具是严密的，但是日常出现的情况和状态是变化多端，那么一个再好的工具是否能够覆盖日常出现的所有状况呢？当然这个问题可以通过工具的持续改进来完成，但是工具的实现和改进的成本又该如何来衡量呢，这里面是否又违反了80|20法则了呢。

另外，我们都知道软件生产是一个智力劳动，智力劳动将会产生的信息也是复杂并变化的，那么使用僵硬的工具来处理变化的信息这种方式是否合理呢？

最后我想问一个我感兴趣的问题，在我一直的概念中，我觉得agile是不便于财务管理的，但是我看到你说agile在财务上占有优势，这个是我没有经历过的，能否给我说一下是如何操作的呢？我以前做过的公司有卖项目的（最简单），有赔本赚吆喝的（互联网创业公司），有卖MD的（外包公司的方法）。但是我真不知道agile在财务上是怎么来操作的，是按照故事点来计算的吗？

我觉得这个度量的问题聊的很深入，这里不知道是不是你想推翻我这个标题的‘正规’，其实这个标题是为了独特一些吸引眼球的而已（不过我对正规军这个词并不含任何感情色彩，国民党还是正规军呢...）。在没有明确度量的问题之前，正规与否确实是一个没有意义的概念。因为没有标准来进行衡量。可能所谓的区别就是我们的文档多一点，我们的review多一点，我们每进行到一个阶段都知道下一步应该做什么。但是有了这些不代表就有了战斗力，甚至很多时候，这些东西是消耗战斗力的。

关于我脑子想到的问题我不知道是否值得讨论，就是如何更物理更加有效的度量，我使用过最简单的MD，使用过bug数，使用过代码行还有使用过agile的故事点，但是所有的方法都不能够让我对度量有更多的信心，所得到的数据在我看来都是不能够准确的说明具体的工作价值。所以这个问题是不是一个无解的问题，根本就没有，也不可能有物理性的参数来进行度量（突然想到是不是可以用生物性的参数呢）。那么如果要是一个无解的问题，我们的软件工程，就没有标准，没有标准就没有相对的改造，那么任何一种对自己团队有效的方法是不是都可以用‘正规’这个形容词呢？再扯远一点，正规这个词究竟是什么意思呢？是否适用于软件呢？

就度量我在说点，算是回答吧。
数据存在多种，一是直接的物理数据，一是经过推导的间接数据。比如距离和时间就是直接数据，而速度是间接数据。当然直接数据和间接数据之间是可以转换的，因为他们之间是可以互相推导的。也就是速度也可以是直接数据，时间和距离也可以是间接数据。具体在一个场景下是什么类型的数据，要看这些数据收集的方式，如果收集的方式是物理的，那么就是直接方式，如果是经过逻辑推导的，那么就是间接数据。同时这些数据是用来说明事物的一些特有属性的，而有些属性是人们还没有发现或者关心的，并且与之相关的数据也是并没有被认可的。比如速度的概念就不是一早就有，而有了之后也是先有快慢，没有具体的数字数据，最后到了物理发达的阶段才有了秒每米这样的说法，而加速度这个概念都是更晚才被人们认识到的。说不定过段时期，人们又会搞个加速度变化的趋势的概念出来。软件的问题现在就在是人们对软件的基本属性还认识不到位，一个方面是对现有已经认识到的基本属性认识不到位，另外一个是对现在还没认识到的基本属性认识不到位。比如质量究竟应该用什么数据做对照参考，规模应该是数据做参照系；另外这些数据间的关系是什么，什么是可以互相推算的，什么是可以通过物理收集的，什么是不能通过物理收集的；有些属性到底需要什么样的数据才更能被认识和理解，从而形成一种直觉式的反应，比如我们直觉性的就知道10米/秒速度是1米/秒的速度的10倍。
实际上度量研究的过程，就是对软件属性认识的过程。可以说软件开发过程的改进，是一个研究过程。这点请务必理解到位。
而我说我喜欢职业化这个词，其中也包括了究竟应该什么是职业化的一个思考。同时正规化也是一个过程的基本属性，不同的项目需要不同的正规化水平，超出或者低于这个范围都是不好的。而职业化要求就不一样，只存在对职业化要求的最低水准，而不存在上线。这就好比，一个好的职业兵，既应该可以在游击队里面战斗 ，也应该可以在正式部队里面战斗。他只可能不能去某种特种部队，因为那个地方职业素养或者职业技能要求更好，他达不到。当然他也有自己喜好的正规化范围，但是这个不是强制性的范围。