个体软件工程读书笔记

今天学习看到了一篇关于个人软件开发过程改进的文章，颇有感触，遂记录下来，以备以后参考并鞭策自己执行。

很多人都在抱怨自己所在的公司的开发流程不够规范，项目管理混乱，文档不够齐全，个阶段该有的记录没有，该产生的工件也没有。这一切可能都源于公司的管理，但更大程度上是来自于项目的压力，使得我们对精细、严格的流程心有余而力不足。那么是不是在这样的公司就没有发展了呢？其实我个人觉得软件工程的思想以及软件开发流程的控管和它所依赖的群体没有关系，如果我们真的理解了软件工程，那在我们自己的开发过程中去实施、去应用，在应用之后做一个分析、对比。如果成效显著我们当然可以拿来与同事分享，从而影响他人。

个体软件工程也就是将自己的开发工作看做是一个项目来做，既然看作一个项目，那它必然要有多个阶段：计划、需求、设计、编码、测试、维护。当然我们也可以选择其中的几个重点来提高自己的能力。比如我个人比较看中其中的计划、需求、设计、测试。其他的在开发中受关注程度会少一点。

下面我按照软件开发的流程来说说个体软件开发过程中的自我管理。

l 计划与跟踪

无论是管理学还是工程学都很强调计划的重要性，在项目管理中编写项目计划也是一个

重头戏。在正规项目管理中，计划阶段我们需要对工作进行分解，也就是WBS，然后对活动进行细分、排序、标识活动的时间、查找关键路径、估计项目时间、成本、人力等。然而在我们简化版的个体软件工程中，我们把重点集中一下（因为毕竟精力有限），我觉得有几个动作是必须做的。

首先，识别活动，也就是对自己的开发工作中的各个活动有一个标识，最好加上自己的描述，这样会为我们的工作做个记录，以免我们遗忘或者漏掉该做的工作。

其次，在识别活动后我们要对活动的工作量进行评估，也就是预测该活动需要的实际工作时间，可以参考类的个数、数据库表的个数、界面的个数来估计（这可能是经验的积累，对我们以后做真正的项目管理有很大帮助）。在这个阶段做详细的记录是必须的，因为这里的记录代表了你现阶段的项目计划能力。

最后，在工作完成后，用实际的工作时间与预期的估计做个对比，以次来提高自己的估计能力，相信在以后会有很大的作用。其实在这个计划与跟踪过程中，还有一点不要忘记就是要做好自己的时间管理，最好记录下每天你在项目活动中所耗去的时间，不要太细，但是可以在一周结束后得到自己一周40个工作时中有多少有效项目时间（可能我们的基数不是40：））。这样也有助于我们以后估算项目时间。

l 需求确认

我们开发中的需求可能因自己职位的不同而来源不同，可能直接来自客户，也可能来自

业务分析员或者系统分析员。但不管来自哪儿，我们都应该做一个需求确认的动作，我觉得几个重要的检查点：

首先，看现在我们所得到的信息是否对我们的设计、编码工作已经足够。

其次，需求的优先级应该清楚的给出。

另外，需求不明确的时候一定要搞清楚再去开发，以免返工（虽然有的时候即使明确了也得返工，因为需求的变化：（）。

l 设计

如果我们是程序员，而且是流程特别规范的公司的程序员的话，我们可能接触不到设计，

我们的需求文档可能是详细的不能再详细的详细设计了（象在说绕口令），这种情况我们的发挥余地可能不多，但是如果你接手到的设计文档是很泛泛的，那么就应该在设计上多下点工夫了。我个人觉得对于我们开发人员，这里的设计可能重重之中是用例的细化，详细的状态图、活动图以及代码级的结构设计，比如组件设计、重构、抽象。这些估计大家都是高手。

l 测试

不知道大家开发的时候公司的绩效考核有没有千行BUG率的指标，我们有！所以提交

QA测试的话不可能不去做测试，可能我们习惯做的测试是单元测试，但是就我个人而言，做单元测试也是随性的，不可能有测试计划、不可能有测试记录、更不会有测试分析。但是现在这一切在个体软件工程中都成了必须的：）有四点我觉得应该有改进的余地：