积跬步，致千里

 

积跬步，致千里

 

记得中学的时候学过荀子的《劝学》，里面有两句话：“不积跬步无以至千里，不积小流无以成江海。”道理其实非常的简单，谁都看的懂，但就像所有的常识一样，谁都明白它的道理，但认真去按照平常道理做事情的人总是聊若晨星，（我也是一样^_^），大多数人总是知道他知道的，然后却又做他所做的，所以成功的人总是那么的少，失败的人总是那么的多，世界也总是那么的平衡。

但是真正想做实事，并做好，做成功，一般还不得不靠浅显的道理。以前在学校的时候，在图书馆看软件工程的书，看着看着总觉得就像隔靴搔痒，怎么也看不明白，到底怎么将整个软件项目工程化。从各大网站，IT媒体得来的信息也告诉我，似乎中国的软件并没有多少依靠了什么软件工程，极端的说，就是人人都在说，人人都不用，同时各种新的软件工程方法也层出不穷，像敏捷开发、极限编程、结对编程、重构等等新的名词，新的术语，新的方法不断的涌现出来，似乎让人并不痴情的脚步永远也赶不上软件工程变心的翅膀。

在这里，我并不是说这些新的方法没有用，而是说很多新东西只能用来锦上添花，而不能雪中送炭，想要飞，必须先会跑，一步一步走好前面的路才能让成功的肩膀承载新方法的浪漫。　

软件工程也许离学生时代的我太远。现在工作这么长时间了，算是对软件工程有一些实在的认识了，相信公司实施的软件工程流程并不仅仅适合我目前从事的行业。软件工程到底是怎样控制软件质量，软件流程的？以前总是纸上谈兵，现在终于有一些实战经验了。现在我觉得，软件工程就跟我大学时代学的建筑工程非常的相象，只是研究生时代的我很难去理解：一群做软件的程序员怎么和一群做建筑的工程师联系起来。现在也许我知道了，软件工程的核心就在于六个字：“积跬步，致千里。”或者说是“冰冻三尺，非一日之寒。”

当然怎么去实施它，远远要比说明它难的多。

知道道理的人太多了，因为道理都是不难的，但知道怎么去运用它的人却很少。结合我的工作，我来谈谈公司是如何实施软件工程的，它是如何使一盘散沙凝聚，如何让一群都认为自己聪明的人（没有哪个程序员心里承认自己笨的。）分工协作，如何让他们按部就班的完成项目。

成功的开始应该是有一个好的计划。

公司的项目开发采用了严格的工作量估计和进度控制来保证软件的质量。无论何时，向前走都必须在完成前一步的基础上，盖空中楼阁是不可能的。

软件开发首先是提出需求，这个过程我并不是非常的清楚，因为目前我不可能参与这个过程，就我所知道的，由产品线经理和专门领域专家（Subject Matter Expert）共同提出，他们根据查看国际规范文档，并和客户交流沟通来提出需求规范，这个部分可能是最难的。

毫无疑问，专门领域专家肯定是在电信领域有多年工作经验的技术专家，但是产品线经理也不是那么的简单，也是多年在一线从事编码的经验，并有很好的沟通能力，然后才可能提拔上去的。我所知道的一个刚刚被提拔为产品线经理的技术经理在这里工作了三年半，说到他的技术水平，坐在我旁边的来了一年半的同事对他非常佩服，跟我说，问他的关于我们现有一个软件开发框架的问题，他总是能够讲的非常清楚，包括很多的细节。当然他的英语也非常的好，否则也不会在工作两三年后就被提为技术经理。也就是说，提出需求的人都是有很强的技术背景，并对问题和客户需求，规范都非常了解的，软件需求的质量必须得到很大程度的保证。

软件需求确定之后，就会按照每个技术经理下面的每个员工能力【可以参考《持续成功》】，来具体的安排项目（这里叫feature），每个项目一般都会交给有工作经验的老员工做项目主管（Prime），然后会安排工作经验较少的员工和刚来的新员工参与，具体人数根据项目可能的难度来决定。

下一步就是具体项目的调查阶段，一般是几个星期（这个时间是安排好了的），在这个阶段，就由项目主管带领下面的人工资源一起做需求调查，把主需求拆分成几个子需求，分析每个子需求的难度，并写成详细的文档记录（包括调查到的所有代码，补丁，以及其他的各种调查记录）。

跟着就是需求规范文档回顾（review），项目的主导者，技术经理，制订需求规范的人会预定一个时间对这份规范文档进行讨论，项目主管根据自己的调查记录，提出自己的子需求项目和相关的难度估计，大家讨论之后达成一致，然后就根据子需求的数目，难度，和做这个项目的人数来估计整个软件开发的流程的时间，和其中每一个路标的时间，并提交到专门的管理网页。

然后就开始整个软件的设计开发了，首先进入第一个路标DS（Design Start设计开始）。

在这个阶段完成的工作是：

1．需求规范已经回顾，并得到确认。

2．项目安排，具体的需求项目安排给具体的设计主导人（Design Prime）。

3．人工资源报告提交并分配各自的相应工作。

4．在项目管理器（专门的网页管理软件）中产生项目ID和每一个路标预测完成日期。

5．在文档库中为具体项目打开文档提交路径。

6．在项目管理器由设计主导人（Design Prime）填写设计开始的实际日期。

完成之后，跟着就进入下一个路标，称为FR（Functional Reviewed解决方案通过）。

在这个阶段完成的工作是：

1．提交给客户的功能描述文档段落完成。基于需求规范，设计测试段落要包含相关的功能列表。

2．所有跟需求规范相关的文档都被准备，以便讨论。

3．功能描述讨论通知被发出，并被存储在事件管理器中。

4．召开功能描述会议，发出会议记录（存储在事件管理器中）。

5．所有来自讨论的具体解决方案被记录在方案数据库中。

6．所有的“高”优先级方案讨论通过，并在方案数据库中关闭，不在更改。

7．根据讨论会议结果，功能描述文档被更新，新版本存入文档数据库，并清楚改变痕迹。

8．在项目管理器由设计主导人设置FR（解决方案通过）的实际日期。

下面就是具体的设计以便完成需求的工作，每个项目所花的时间都不一样，所有难度估计是要靠经验的。接着进入D C （Design C ompleted设计结束）路标：

1．文档在打开状态，以便完成设计分档部分，并标注相应的改变痕迹。

2．详细设计通知发出，并存储在事件管理器中。

3．召开详细设计会议，发出会议记录（存储在事件管理器中）。

4．所有来自讨论的具体解决方案被记录在方案数据库中。

5．所有的“高”优先级方案讨论通过，并在方案数据库中关闭，不在更改。

6．根据讨论会议结果，功能描述文档被更新，新版本存入文档数据库，并清楚改变痕迹。

7．在项目管理器由设计主导人设置D C （Design C ompleted设计结束）的实际日期。

上面这个阶段是比较难的，但按部就班也并不吃力，最难的部分已经过去，现在进入 C I（ C ode Inspection代码检查）路标：

1．根据详细设计，生成改变的模块列表和具体的变化痕迹。

2．代码提交通知发出，并存储在事件管理器中。

3．召开代码提交会议，发出会议记录（存储在事件管理器中）。

4．所有来自讨论的具体解决方案被记录在方案数据库中。

5．所有的“高”优先级方案讨论通过，并在方案数据库中关闭，不在更改。

6．在项目管理器由设计主导人设置 C I（ C ode Inspection代码提交）的实际日期。

设计人员的黑盒测试和部分白盒测试，尽可能的覆盖所有的可能性。进入TR（Testcases Reviewed测试用例通过）路标。 测试由具体的测试组完成，每一个工作事先都分配好具体的测试组，测试讨论要跟相应的测试组讨论。

1．在测试用例数据库中申请测试用例ID。

2．文档在打开状态，以便完成设计测试部分，并标注相应的改变痕迹。

3．测试用例讨论通知发出，并存储在事件管理器中。

4．召开测试用例会议，发出会议记录（存储在事件管理器中）。

5．所有来自讨论的具体解决方案被记录在方案数据库中。

6．所有的“高”优先级方案讨论通过，并在方案数据库中关闭，不在更改。

7．在项目管理器由设计主导人设置TR（Testcases Reviewed测试用例通过）的实际日期。

测试用例编写完成，并通过测试。进入DT（Designer Testing C ompleted测试完成）路标。

1．测试结果提交给测试用例数据库，所有的测试用例都要通过，除非异常情况加以说明。

2．对于所有涉及到的模块，代码更新请求被提出并通过。

对于设计过程的最后阶段，进入LA（Load Available for PV装载运行提交给测试组）。

1．所有的代码更新被提交并装载。

2．所有的具体解决方案条目在方案数据库中被关闭。

3．得到校验的模块将进入下一个版本。

至此，所有的步骤走完，产品交给具体的测试组校验，主要进行白盒测试。

这就是这个设计组的具体过程，当然对于具体的项目，每一步里面的步骤有可能不会全都有，但是DS（Design Start设计开始），FR（Functional Reviewed解决方案通过），D C （Design C ompleted设计结束）， C I（ C ode Inspection代码提交），TR（Testcases Reviewed测试用例通过），DT（Designer Testing C ompleted测试完成），LA（Load Available for PV装载运行提交给测试组）这整个过程是一步也不能少，对于大的项目，一般是需要七、八个月的时间，对于小一点，大概也需要一、两个月时间。

测试部门的整个测试流程跟设计部门差不多，也有一套完整的质量控制流程，每个路标也都必须走到。

在测试的过程中也一样会发现软件缺陷，这个时候，测试组就会将其提交给这个项目的具体设计者，设计者会请求打开一个“改变请求”（Change Request）,然后得到具体模块主管者的答应之后，将改变好的代码再一次的提交。“改变请求”都完成之后，项目就算结束了，以后就是可能的维护工作了。

我开始工作也只有半年，开始三个月主要是适应环境和学习基本的业务逻辑流程，后面才参与具体的软件开发，现在所在的这个项目由于比较大，“设计描述”现在才由一个老员工刚刚写完，不过我明天就回家了，“设计描述”讨论的时间等春节过去一两周才会正式开始，所以对于“改变请求”的过程不是非常清楚，不过听说那段时间在不用解决Change Request的时候，就是学习阶段，为下一个项目做准备，比较轻松，可以用来休带薪假了。

软件工程目的就在于整个软件开发过程的控制，成功的软件流程就在于压力和任务的平衡，绝大部分情况下每个人只需要工作五天，每天不到八小时就够了。程序员首先应该是一个正常人，其它时间应该享受更多自己的生活，不是吗？毕竟做火锅、逛街、打乒乓球也有很多不同的乐趣。在这个基础上锦上添花当然好，但是如果每天的压力和任务不能得到很好的调配、分散和解决，也许再多闪亮的新方法也难治愈千疮百孔病入膏肓的软件项目和安抚疲于奔命焦头烂额的程序员。

大的成就是有小的成就积累的，每天的进步就够成了每年的进步，每年的收获也就组成了一辈子的收获。

 

由于公司的文档全是英语，因此很多术语，感觉不好表达，很难找到贴切的对应，只能尽自己的能力尽量避免英语的出现。

吴桐写于2004.1.11

最近修改2004.1.16