当老板喜欢研发过程规范化,该怎么办

目前所在公司很小,研发团队很小.也就是5-6个人.在我接手之前,老板自己管,他同时也是技术人员.明显的,他知道研发团队各自问题所在,但是他希望有人(就是我)帮助他发现和解决这些问题.当然解决问题的前提是不改变各个研发人员的待遇的基础上来做的.


    老板做事相对稳重,总想着把一切事情规范化,特别是开发过程规范化,比如新项目的如何开始,旧项目bug如何修改,以及任务之间发生冲突时又该如何?产品发布该如何? 人员变动又该如何?等等各种方面.


    可是我总觉得这些事情不太容易规范,我日常工作很多时候都是在协调.比如Bug的修改时间的确定,是否要马上修改还是日后修改,总的来讲是一个衡量目前做的工作的状况和旧bug带来的影响的对比结果.如果要把全部的衡量规范化,文档化,那么真正执行起来,总觉得不如现场判断下是否要马上修改,如果不是则增加一个任务记录.标注上最后修改期限.如果是就优先修改这个bug. 才这么几个人而已,而且随时都在. 硬要规范化这些操作,或者开发过程.是否有必要?

     不过就我而言已经不是有没有必要的了,而是一定要了.因为老板担心的事就是如果其他开发人员走了.源代码在.工作能够顺利交接. 如果我走了. 管理经验没有留下来,没有办法交接管理上的经验............................

     不知道各位有没有对于开发过程规范化,文档化有没有相关的经验可以参考下.
准备得写一大堆的,项目开发管理条例,bug管理条例,产品发布管理条例,源代码管理条例,人员培训条例,离职人员交接条例.... 等等这些了.:shock:
     怎么会有这种事情!

    PS:项目非常简单,一个开发人员,一个市场人员合作,能够搞定一切.

"研发过程规范化"的目地太阴险了 !

这种出力不讨好的事 还是用wiki blog应付一下吧.

目的阴险倒是不太觉得,不过对于小公司来说,研发过程的规范化有个明显的时效性的问题的.经常会变动.这个我觉得才是麻烦所在.如果一次写完推广,有效期能够比较长的,写写也无所谓.可明显这个稳定性不够啊.
当然人家让我干活的目的也是为了把一切事情规范下来,稳定下来.还真有挑战性.

to jack：
所谓的“研发过程正规化”其实只是一种心理上的感觉，其实有很多方法都能给老板带来“正规化”的感觉，问题是这个“正规化”是否真正有实效。比如严格遵照 PSP/TSP 的方法，每位员工每天写很详细的工作日志，10 分钟以内做的事情都必须记录在案。写工作日志对于改善管理确实还是有帮助的，但是对于改善工作效果（我是说，用户所看到的结果，这个评判权我们还是交给最终用户吧）的帮助并不是很大。正如以前我曾经引用过的，CMM/PSP/TSP 最多只能“记录成功”，而无法创造成功。
我不想跟某位“大师”或者“半仙”争论什么书本上对于软件工程是如何描述的。即使我读过一些书，我对于软件工程的理解从来也只出于我本人工作的实践经验。JavaEye 与 UMLChina 一类的论坛的区别就是我们的很多讨论都是出自一线开发人员的实践经验，而不是空对空地搬弄大师的名言警句。有些朋友对这里有“民科”的感觉，不过只要有实事求是的态度，我认为民间科学家还是应该多多益善的。
根据我的经验和出于一个老程序员实用主义的判断，XP 中的一些最佳实践是非常实用的。实践软件工程，同样要花费很大的功夫、同样要付出成本，但是实施 XP 比实施 CMM 能够得到的更好的效果。

持续集成：
按照 Martin Fowler 的说法，集成的复杂程度和两次集成之间时间间隔的平方成正比。也就是说，你每周集成一次的复杂程度不是你每天集成一次复杂程度的 5 倍，而是 25 倍。感谢 Martin Fowler，我们现在已经有一些非常棒的工具来帮助我们做好持续集成的工作。持续集成可以以比日创建（Daily Build）高的多的频率来做集成，如果你认为有必要，每天你可以 5 分钟做一次集成，不过一般是每次代码提交做一次集成。以前我在一篇文档中看到某个项目经理说，持续集成就是开发过程的心跳，我很同意他的这个说法。对于 C++ 项目来说，和 Java 项目一样，也有很好的工具来做持续集成这个工作。当然你们需要花些时间去掌握这些工具，天下没有白吃的午餐。

测试驱动：
持续集成需要得到自动测试的支持，如果没有自动测试，那么就无法验证创建的正确性，那么创建就没有多大的意义。在 XP 中，关键是这一切工作都能自动完成，敲入一个命令，一两分钟后，就能看到反馈的结果，而不是需要手工去作这些测试。
测试驱动是一种非常好的开发方法，可以有效地保证代码的质量。学习测试驱动是一个长期的过程，比掌握持续集成工具要复杂的多，不可能一蹴而就。
C++ 我相信也有工具来支持进行测试驱动式的开发。例如像 Ant 这样的工具和 CppUnit 的测试框架。

重构：
有了上面持续集成环境和测试驱动开发方法作为基础和良好的支持，现在你们就可以放心地对代码进行重构了。自动测试所建立的安全网可以保障你们重构的安全。当然单元测试很多时候是针对接口来进行的，为了有效地进行单元测试，好的 OOP 实践，即面向接口编程是很有必要的。面向接口编程虽然在 C++ 中有些难度，但是也是完全可以做到的。这里我所说的接口是广义的接口，在 C++ 中一般使用抽象类来实现。

迭代：
开发过程一定要建立在迭代的基础之上。迭代是所有现代开发方法的核心，一种可以称之为“开发方法”的东西如果不支持迭代开发，我就认为它是一种远古的即将灭绝的恐龙（其实我想说的正是 CMM）。迭代的前提是你们对于业务非常熟悉，可以把一个大的项目划分为多个彼此相对独立的功能子集。

其它的最佳实践：
有了上面的基础，还可以开展更多的最佳实践，不过 XP 中技术含量最高的其实就是上面这几种最佳实践。其中的持续集成其实就是软件工程中强调的配置管理。配置管理是软件工程的基础和最重要的部分，一个团队，在没有做好配置管理之前就不要奢谈什么其它的 KPI。配置管理包括三个部分：
版本管理：我们可以使用 CVS/SVN 来做。
创建管理：我们可以使用 Ant/Maven+JUnit+CC（还有一个可选的工具 Dashboard） 来做。其中包括自动的创建、测试和部署。
问题跟踪：我们可以使用 CVSTrac/Bugzilla/JIRA 来做。
正如以前 o6z 所指出的，配置管理是任何一个企图“正规化”的开发团队首先必须做好的工作。

需要指出的是，虽然以上这些实践我是参考 XP 来写的，但是其实适用范围不仅仅局限于 XP。XP 其实跟其它很多种类的敏捷开发方法都是兼容的。上面这些实践我相信在 RUP 中也可以很好地开展。

如果你的老板并不是很在意取得实效，并且非常关注在短期之内获得心理上的满足感（既然这样，为什么不去吸毒？），那么你根本没有必要花很大的工夫去研究上面这些最佳实践，随便糊弄一下这家伙就可以了。比如，明天就开始记录工作日志，或者每三天开一次评审会议。CMM 中的花架子实在是太多了，直接拿来用就可以了。

实际上就我自己的工作而言,我很重视下面的一些东西.
1.员工做的任何事情,上头必须要有反馈.

比如每日工作日志,开会这些东西,如果研发人员花时间搞出来的东西,上头没有任何反应,那么无论花的时间再少,我也不希望他们去做.因为每日工作终结,和每周工作报告这些,我都可以代替他们完成.
而且一般情况下,如果没有任何反馈,特别是这种让研发人员写各种报告的事情,那么这样的任务会被自然淘汰.

2.做微小的改变.慢慢的导向到目标上去.

我一直认为,如果事情或者工作环境或者工作流程,工作方法这类内容改变的过于巨大,就有个反抗成本在里面.换句话说,变化越大执行成本也就是越大.

3.任务强迫+自愿原则

分配任务时候,80%的强迫性,20%的自愿性.
就是大部分时候都是强制分配任务的,但是还是有少量的机会让他们去选择自己想要做的事情. 这里关系到一个执行力度的问题. 如果任务无法顺利执行,那么事情也就不要做了. 一味的自上而下不行,一味的照顾下面也不行.

4.良好的交流环境

除了用各种方法引导相互交流,比如开会,比如聊天等等.同时也关注某个人员的本身交流能力是否够好.也就是会不会说话,能否顺利的接纳别人的意见等这些. 如果这些人员的本身交流能力有些问题,也会适当的教会他们一些交流技巧.
没有良好的交流环境,气氛就过于沉闷,如果没有良好的交流技巧,气氛容易过于火爆.甚至带来负面作用.

5.士气
尽可能的让他们有成就感,少做些无用的事情.这个和第一条有点接近,不过是不同的方面了.

可能还有有些其他的.相对来说,我都是比较注意一些软性的东西.而不愿意做的那么死或者条条框框话

当然Dlee的建议也不错.如果真的想糊弄,方法也的确不少.比如定短期目标,定培训计划,定各种东西. 但是问题在于不是应付老板. 这些东西总要实施的,那么实施带来的负面影响不小的.

目前得搞一套方法,能够给老板带来"安全感",而又不至于太骚乱研发这边.对于这样的小型公司骚扰的太多了,效率下降的一定明显的很,士气这种也一定下降的很.又是一个得小心权衡的地方.

to jack：
其实 XP 就是对于开发人员影响最小的软件工程实践了。XP 中的绝大部分最佳实践都能得到开发人员的认同而不是抵触。如果软件工程实践无法得到开发人员的认同，甚至受到抵触，那么我们还有把握实施好软件工程吗？显然，肯定是会失败的。软件工程不是阳春白雪或者精英治国，可以由精英们在闲暇时间随意把玩的东西。
我相信认真实践 XP 是一种开发过程正规化比较好的做法。最好的反馈方法就是自动的单元测试所获得的反馈。

这三个部分的确是一个研发团队所必须规范化的三样最重要的事情.
我也准备适当的选择其中一部分的东西,搞出这样一套操作规则出来.
但是由于前面的严重不规范操作,这些事情研发人员完全的没有概念.
所以 版本管理和创建管理需要对研发人员做不少的培训.前面我也提到,由于项目过于简单,那么搞这些东西并不会一定增加效率效果,反而会减少效率,反而会出现抵触心理. 所以都是想用的人个别培训,然后再使用.
这样就没有表面上的"政绩工程"了,老板觉得你没有在规范,怨啊


问题跟踪:的确想上去,不过市场人员的培训是个问题,项目外部测试之后,产生的bug一般都是直接反馈给研发人员,现场改的.如果是产品推出后使用发现的bug,那么会根据紧急程度来决定是否修改.多了问题跟踪,也就多了一件事情.效率更加低.

以上这些配置,目的都是为了减少交流成本,减少变动成本. 但是我这边可是有超低的交流成本,极少的变动. 如果强制搞这些东西. 反而就是"麻烦大了"

的确我的政绩工程没有做好.看来得往这个方面下功夫了.

XP的确是在我的考虑中了.为了我的政绩工程,为了减少对于研发的人员的影响,为了....
的好好研究下,然后裁减成我们可以接受的内容了. 

jack，有些事情其实是一劳永逸的，只需要做一遍。也不需要很多人去研究，只需要你辛苦一些，把这些东西研究清楚。一旦这套持续集成的环境和机制建立起来以后，后面的难度就小很多了。
关于持续集成工具 CruiseControl，张辰雪和夏昕写了一篇非常好的文档，有空了可以看看。
http://www.xiaxin.net/blog/OpenDoc-CruiseControl.pdf

的确 集成的好处我是知道的,而我总觉得不太适用目前的公司,就一直没有动.
看来这个想法是错误的.集成本身就是为了更加规范.更加的有序.也就是研发规范化的一部分.准备好好实行了.还是太善良了.
.
这篇文章我得好好看下.
PS 这个地址打不开,google搜索OpenDoc-CruiseControl.pdf只有一条,指向和你同一个连接.
不过也没有关系,除了自动测试这块有难度之外,其他的集成都能够找到代替的东西.或者实现相同和相近的功能.实在不行 自己batch文件多写几个也是一样的.