《产品研发过程实践》 36 研发过程 概述

在这里，我们将简要描述一下研发过程的一般过程，在每个阶段的主要工作，人员投入，以及产出是什么。当然，采用这样的描述方式，我无意于误导大家采用瀑布模型来进行研发过程。瀑布模型不是说一点用都没有，但是，在实际中实用瀑布模型将把你们的项目拖入一场灾难中，因为他有意无意地排除了一个最重要的因素：沟通。在现在商业软件的开发过程中，缺少这个因素，什么都做不好。

然后，我们用PM的9个知识体系，作为我们的纲，来简要地说说，在研发过程中的项目管理。这里之所以用PM的9个知识体系，不是我企图抄书，而是综合看起来，这9个知识体系，总结得还是很不错的。你可以把几乎所有的内容放入这个框架中。所以采用。

OK,让我们开始吧。

首先，对于研发过程来说，我还是前面说过很多次的一种概念，不是说，我们懂得了理论上应该如何，就一定能够做好管理的。如果你的团队连SCM什么的都做不好，和一个已经能够执行日集成的团队。管理方式绝对是不一样的。所以，无所谓别人最佳实践是什么？要看，是否适合你的团队，是否能够为你团队带来效益。

下面，首先说说我对于三种程度不同的团队的一个建议，当然这仅仅是个人的看法（更加专业的，恐怕是CMM的5层模型，呵呵，也值得大家看看，多看看不同意见总是没有太多坏处的），说这些的最大作用是，需要你根据团队不同情况，抓不同的重点，不要胡子眉毛一把抓，最后恐怕什么都剩不下来：

对于混乱型团队：典型的做法是，听一点，做一点；带头的哥们站起来在办公位上大喊一嗓子：“改改！错了！”。然后大家就按照这个哥们的意见改。今天过来一个同仁，看看，说：“这不好！改改！”，明天那个同仁说：“那不好，改改！”，于是不断的镀金现象在无控制的情况下不断出现了。团队成员的日常工作似乎就是构造软件和修改软件，若有若无的测试使得软件质量根本无从谈起。对于这样的团队，我的建议是做好三件事情：需求管理（你说范围管理也成，显得专业一些吧）、版本管理、和测试管理（质量管理）这三块。当然，我并没有任何的暗示说，只要做好这三点就可以了，比如你们团队的日程安排什么的，该如何做还是如何做，我们只是在这个阶段重点做这几件事情，我觉得就不会错得特别离谱了。

在需求管理中，做好初始的需求。在这个时候，还是老老实实一些，尽量做得详细一些（当然，你做得越详细的需求，越细节的需求，都可能导致在变化面前，成本急剧上升，因为这份文档维护的成本就越高，而过于细节的需求，存在一个边界效能降低。但是在这个阶段，是一个约束的过程。也就是说，实际上，你的团队目前的状态，根本无法应付快速变化的极限项目，所以，先打好基本功，然后再考虑将来如何改进，比较好一些）。做好需求变更，至少让你的需求变化了以后，保证整个团队都知道，并且经过基本的评估，知道这个需求的变化，可能对软件造成多大的影响。然后逐步落实这些需求变更。这样做最重要的目标，是使得项目目标能够始终置于项目的中心位置；同时，提升项目组团队中的沟通过程，为后面的阶段做准备。

做好版本管理，至少使得大家知道Check IN和Check out的时候，应该是一段已经经过了调试的代码，我们所需要的所有文档和所有代码都能够找到一个唯一的地方。每天执行入库、出库操作是必须的。即使作为项目经理，你在这个阶段投入精力也多少是值得的。虽然这个目标看起来很容易，但是真的做到这一点，并不是那么简单。你需要发布你的SCM计划，告诉大家文档编号，告诉大家入库位置，告诉大家发布方法等等，并且一点一点来落实，并不是很多人想像得那么容易。而且，SCM这一块如果做不好，任何的管理都是胡扯。

做质量管理这一块，按照我的经验，主要从测试尽早切入项目，然后评审测试点、测试大纲入手。重点抓项目关键点上的内容。并且推进测试计划和Bug填报制度。前一部分是为了使得测试尽量有序化，后一块是为了将来的质量分析。如果Bug填报制度不完善，任何的Bug分析等等都是空话，那么最后的质量监控等等，很多程度上将落空。因为一般来说，我们总是不会自己去做具体的测试工作的（因为工作量实在太庞大了），那么如果缺少一个监控的手段，这一块就全完了。

这就是混乱团队情况下，需要抓的几块。而且通过这几块的工作，你的project日程的定义等等，计划的调整等等，也可以慢慢拉起来的。

对于中等程度的项目团队来说，这种团队一般具有这样的素质：他们能够很关注需求、并且日常的SCM管理已经不需要管理者花太大的精力去应对了。质量相对来说，有了一些保证，而不是糊里糊涂地就出去了。但是，这种团队会出现一些问题。比如，在项目研发过程中，不够透明；任务分配以及回收上略显得随意，项目成员对项目过程提出各种想法，并且期待能够从这些改进中得到流程的改善。他们会把主要的注意力放在客户方面，而不是技术方面。一般来说，这种团队的组成人员应该基本上由工作2-5年的人员组成，经历过不少项目了。一般对于这样的团队，我会企图做好一件事情。就是Release Plan的工作。这时候，我们希望我们的项目是可以按照阶段来进行监控的，并且项目的进展相对的来说，是比较直观的。我们会首先定义一些Release版本的目标，然后针对这些目标，来监控整个项目的进展。比如我们说，在某个时间点，我们会集成某几个新的功能，修复掉某些Bug，并且随着这个版本的产出，希望能够随着产出客户文档等等内容。通过这种方式，使得项目最后时期的风险小很多很多，而且如果项目发生Delay或者成本超支，也会在第一时间暴露出来，而不会在最后阶段突然爆发风险。但是，如果你希望如此来执行，那么最好有一点准备，因为这会和你没有执行这种做法之前不同，你会发现你的项目在不断Delay。而且，你能够真正理解到，为什么一个Delay下去以后，就很难追回来了。这样你会面临一次一次的内心的折磨，因为好像你在不断说：我又Delay了，我又Delay了。但是这时候，请注意一点，你必须能够咬住牙关，不要因为人为地赶一些进度，而削减一些版本的目标（比如，去掉某些文档的要求，认为以后再统一去写好了；比如降低代码验收的要求，只要能够Run起来，就算通过的版本等等），因为现在降低要求，你出产品的时候，这些要求是不可能降低的。所以，该Delay还是Delay吧。总好过最后的时候，突然爆出太多问题。而且，使用这种方式的时候，你一定需要能够分离出来一定的版本迭代，如果你说：对不起，我无法提供中间版本，我觉得，这就是你的失职。如果你的程序是1000行以下，就无所谓了。但是如果是更大的规模，就应该能够切分出来，认真回去考虑，而不是简单说一句：不能做！

对于相对比较高级的团队，他们已经能够自觉地做好流程的定制，并且已经能够比较注重从流程中获取历史数据，对产品的出厂标准等等都有一套比较好的规范的时候，我建议是采用每日创建的方式来进一步提高软件质量和过程的透明性。顺便说一句，这一点，我只有一次使用过，而且规模很小的项目。所以对于这一点，我的体会不深刻，下面所叙述的内容，很大的程度上，是和执行过这种研发方式的项目经理进行沟通的一个结果。所以，很可能并不是很成熟。仅仅是想提供一种思路，如果有些许启发，那么就最好了。

一般来说，这种项目需要面临很高的软件质量标准，并且在暴露在外面的内容比较少，很多的关键性代码在埋藏在看不见的地方；而且相对来说，系统比较复杂。那么在执行这种项目的过程中，你首先最好使得你的团队的成员，具有相对比较多的经验（不是说项目不能由经验较少的新手参与，但是你的核心团队必须是经验比较丰富的开发工程师）。然后，你在设计之初，就需要考虑好这个系统应该如何进行测试，并且由研发主管或者测试主管去建立自动化测试系统，在版本提交的时候，首先需要通过这个自动化测试系统的测试，作为一种简单冒烟的标志。这些自动化测试框架将会使得你的程序多了很多的保护，因为你可以知道，至少在模块级别的地方，你没有出现太多的问题。事实上，如果你真的使用了这种方式，再让你回到缺乏这种手段的方式进行工作，你将对项目的质量出现很多担心。当然，这种方式的确会增加成本，但是需要指出的是：这只不过是我们把潜在成本，以一种显在的成本模式体现出来。事实上，质量低劣的软件，将给你带来更大的成本和风险。

Daily build模式，将需要你有一个自动集成框架，自动化的测试框架，以及团队成员对于集成计划、版本控制等等做得比较好以后，才能推进，不然，仅仅是其中一个问题，都将使得你焦头烂额。当然，即使是一个团队已经具备了以上的特征，在第一、第二次执行的时候，也是困难重重的，但是到后面的集成过程中，就会相对比较好了。

上面说了三种团队，我们推荐做好的事情。再重申一次，这不是一定正确的，因为团队的差异性等等，使得你可能有更好的选择去走。对于对某几件事情的抓取，我的建议仅仅是：找到关键点。这个关键点需要有以下特征：你可以通过这个关键点的达到，实现某几个关键能力的提升。而且，这些关键点一定不能太多，比如你要一下子推开包括代码规范，研发规范，新的集成计划，新的设计à代码的转移等等，这个难度将是非常非常大的。而且不易持久。特别是团队在碰到难以推进的时候，会否定太多的事情。与其那样，还不如做好能够做好的事情，暂时做不好的，就不妨放一下。企图一下子做好所有的事情，这对於管理者来说，是一件偷懒的事情，毕竟要求总是好做的，但是，是否效果最好呢？这就不好说了。我举一个现实的例子：开车的哥们基本上都经过驾校考驾照吧（拿假证的哥们，我表示鄙视，你不仅仅是蔑视自己的生命，同时，对于别人来说，也是一种不负责的做法），在你刚开始摸车的时候，你即使拐弯不打蹦灯儿，教练也不会说你，因为他这时候，需要你开车不跑轮而已；然后慢慢的，会加入越来越多的规则，直到你学会为之。同样的，如果我们给一个团队一下子就加上太多的规则，出现的一种现象就是：管理者越来越不耐烦，不知道为什么团队就是做不好一些事情，于是把这些归咎于团队的执行能力。但是实际上，这是管理者没有分析一个团队目前面临的问题，没有给团队一个提升的轨迹导致的。

做好能够做好的事情！

好了，针对不同的团队，我推荐做好的几件事情就是如此了。主要想要表达的一个观点是：不要教条、不要学院，我们要实际！针对不同的团队，需要不同的方式。在管理上千篇一律，往往不是最好的管理方式。

然后，我简要叙述一下一个普通项目中，我们所使用的研发过程。当然，首先需要说明的是：并不是所有的项目都适合采用这种研发过程，对于一些大型项目来说，以下的研发过程过于简单；而对于一些微小型项目来说，以下所说的又过于复杂了。仅仅提供一个参考而已。

假设我们面临一个产品迭代周期中的阶段，我们面临的是10-15个工程师（包括研发和测试工程师），周期为3-4个月的项目。对于这种中小型项目，我们一般会如下处理：

首先，我们会获取基本的需求List，这时候，我们会根据经验，大致给出一个时间和成本的估算（当然，这时候的估算是非常非常不准确的），风险列表；作为第一个阶段的项目输入；

然后，我们会聚集起来项目中的核心人员（比如PM、技术主管和测试主管、需求人员等等），进行一个为期2-3周的Prestudy阶段。这个阶段的主要工作任务是：产出明确的需求规格说明书，说明这个项目将要完成的任务，以及这个任务的产品形态是什么，并且根据Prestudy的工作成果，更新成本和时间估算。说白了，这个阶段是一个明确需求过程。当然，如果存在非常明显的风险，我们就会在在这个阶段试图来验证风险可能克服的程度。比如如果我们极其大的性能或者稳定性压力，那么在这个阶段，我们会进行一系列的Demo或者试验工作，来获得一个原型。当然，这时候你的Prestudy时间可能会拖长。然后，在Prestudy完成以后，我们会进行正式的立项。之所以不在Prestudy过程进行立项是因为：某些时候，根据预研以前的很不准确的成本、时间估算（即使是一个优秀的项目经理，在这里也会出现50%-200%的成本、时间估算误差），进行立项，实在是意义并不是很大的。当然，为了计算整体项目成本的必要，对于Prestudy阶段的工作，进行一个简单的立项工作也是必要的。当然，对于微小型项目来说，你实在没有很大必要把Prestudy阶段和正式项目阶段进行分离。而且，这种分离可能导致一定的负面影响：一般来说，高层对于Prestudy时间的投入或者Delay比较容易容忍，毕竟这时候很多目标没有细化，风险没有暴露；但是对于进行研发阶段以后的成本超支和时间超支会变得比较难以容忍，因为这时候，可能为了配合，我们的宣传已经开始动作了，所以有时候项目经理为了避免后期的风险因素，会倾向于拉长Prestudy阶段的时间。但是对于整体项目进展来说，这未必是有利的。如果希望尽量避免这种情况发生，对于Prestudy阶段，即使不太容易进行监控，也是必须进行比较严格的控制，并且明确Prestudy的产出，等等。

然后进行项目正式立项，这时候，一般来说，如果这个项目还没有决定是否做，那么就比较复杂，需要包括技术分析，成本分析等等，如果是已经决定做了，那么相对的就很简单了。列出：

你的人时计划（说明从人时成本上来说，你的成本为多少？），在必要的时候，一般我们还提供其他的成本因素，比如出差成本，比如外包成本等等。这是成本因素。

从时间因素上来说，我们一般会提交一个Project图（一般对Project的使用，我只是使用他的时间维度，对于成本维度，我很少使用；但是这老实说是个坏习惯，因为你在实际工作过程中，往往因为这样做，而割裂成本，时间两个维度，使得一方面工作量上升，另外一方面，概念上有时候考虑不完全）；

风险列表计划：重点描述项目面临的风险，比如很普遍的一个风险是人员风险等等，说明你将如何避免，如果爆发了风险，你将如何处理等等；

SCM计划：这个计划是有必要的，呵呵，虽然我有时候也在事后来补这个计划；但是这个计划不确立，那么你后面的事情将变得太多了，因为团队成员没有一个明确的文档可以参考，将导致你在项目后期，需要花比较多的精力去规范这些东西；而且可能发生大家理解不一致，而导致的版本覆盖等等，这就很令人难受了；

当然，如果是更细节的内容，你还必须说明人员投入的时间，退出的时间；以及你在项目中将准备进行的集成点，Mailstone等等都是需要描述的；另外组间协同计划，流程定制的模型等等，有时候也是必须的。

你可以把立项的过程看成给项目划一个大致的模型，然后，当然我们的项目面临着变化，将来只是按照这个模型进行调整而已。

然后我们会进入并行的几个工作：

UI设计工作：主要从需求中开始设计操作流程，并且制作UI原型，以便于给项目组提供明确的操作顺序和流程图，为客户提供第一个可见的软件模型；

框架设计工作：主要从需求出发，进行各种软件的框架设计，确定开发的模块划分，技术体系结构等等；后面的设计工作将参照此展开。虽然我们不建议进行非常详细的设计过程（因为这样一方面很难做得很好，另外一方面，使得开发时间推迟太多，明确说一点，对于快速变化需求的软件，进行太详细的设计，纯粹给自己找麻烦！），但是框架设计工作，我还是建议独立进行。抽取团队中相对有经验的人员进行这方面的工作；非常差劲的设计，将使得你后面的各种修改恶心不已呢。产出的标准一般是package级别和接口协议方面；以及数据库设计，部署方案形态确立等等；

测试点设计工作：这时候测试主管介入，开始进行测试点设计；

需求的更改工作：从理论上来说，这时候，需求需要暂时封闭，但是实际上是很难做到的；因为随着分析的细化，我们还是会发现一些需求不明确的地方（比如测试主管提出的某个需求，不具备可测试性要求等等），还是需要进行需求的变更的；

以上三项工作并行展开，最后产出的文档的框架设计文档、测试方案和测试点说明、UI原型。

这是项目的第一个阶段。第一阶段完成以后，记得Review你自己的计划，这是一个大的里程碑，需要看看是否成本、时间估算有过于乐观的情况等等；风险计划也需要更新了；

后面，我们会进入第二个阶段，进行相对详细一些的设计工作（一般我们设计到Class逻辑级别，再深入，实在感觉意义不是很大了）；

同时并行展开的，是测试大纲的撰写；从已经评审完毕的测试点和测试方案展开，进行测试大纲的撰写工作；另外，如果有必要，需要在这时候规划和设计自动化测试的框架，并且建立起来了；

同时，需求的更新和设计的随之变更恐怕也是需要的；

这是第二个阶段，产出的主要是Detail一些设计文档和测试大纲；

然后进入研发阶段，我们根据计划，每周的推进，集成。这就没有什么好说的了。只要坚持三点基本上就可以了：

第一、坚持阶段性的集成，没有集成的所谓项目管理，我不认同，那是文档管理员的工作！

第二、坚持Bug修改优先级高于新功能的添加，我不要虚假的进展；如果有Delay，我希望第一阶段就明白Delay了……，而不是到最后，突然死的莫名其妙的。当然，这需要你能够顶住压力。

第三、项目所需要的内容随时并行展开，比如最好不要到最后才进行用户手册、部署手册等等的撰写。我们一般想当然得认为最后阶段，开发人员会比较空闲一些。但是实际上，往往并不是如此。所以，用户手册、部署手册等等，随着一些新功能的添加等等，该写的就写上去吧。既然这个成本是必须要花的，那么还不如一点一点做出来，同时提交给测试人员，这样会更容易看清楚推进的步骤。

然后在项目过程中，按照一个周期开始提交项目阶段性总结和周报，更新各种计划等等；这没有什么好说的，大家都在做。

最后阶段，主要是测试阶段了。我们整体的软件都提交了，而且前面已经进行了很多轮的测试了。这时候，主要进行各种后期的测试工作；这时候，要特别强调加强沟通；推进修改就可以了；

当然了，某一些一直贯穿的工作，我没有独立去提及，比如和客户之间不断的反馈和沟通等等。

以上就是一个非常简略的过程了。

下面就要开始讨论各个部分了。讨论的方式是：首先给出一个定义，说明这个管理内容是什么，然后把涉及这方面中，我认为比较重要的东西讨论一下。我不会事无巨细地讨论，我认为一些理所当然大家都会做的事情，就不会作为重点讨论。

在项目管理的9个知识体系讨论完毕以后，我会对研发过程中的典型的几种情况，单独拿出来，作为一个一个小的Topic来讨论一下。

好了，让我们开始吧。

文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags: