软件开发管理建议

公司开发管理建议

本文的目的

1．希望工作氛围有所改善

2．希望工作效率得到提高

回答如下问题

1．为什么疲惫

2．工作如何分工

3．代码版本控制

4．工作环境文档化

5．新人的培训与成长

6．当前该怎么做

为什么疲惫

什么样的工作容易疲惫？不是加班，有时加班往往带来的不是疲惫，而是充实和成就感；导致疲惫的元凶是工作中的不确定性和琐碎。

不确定性源于自身能力与所做工作的差异，说白了就是不会；可是EDA行业到哪里找那么多会的人呢，优秀人才大都在现有公司有一定地位，很难撬到，正确的做法是搞好分工，让适当的人做适当的事，这样就不会面临招人难的困境了，优秀公司的人才都不是挖来的，而是自己培养起来的。

琐碎源于分工的交叉或是工作多。工作琐碎不仅仅是导致开发人员的疲惫，对产品质量的影响很大，容易制造Bug，而新的Bug又导致工作更繁琐，陷入恶性循环。

我并不是反对压力，对某些人来讲，压力是促进成长的催化剂，但新一代年轻人承受压力的能力越来越差。最重要的是：如果我们能够轻松的做完事情，何必选择压力呢。轻松代表了游刃有余，也暗示了我们能做更多的事情，如果已经绷紧了，就没有回旋余地了。工作的愉悦性是能留住人的重要砝码。

工作如何分工

软件开发的迭代流程是：需求分析，概要设计，详细设计，编码调试，测试维护。

需求分析：

不管做什么事，开头都是最重要的，所以需求分析是最重要的，它贯穿整个开发流程，当工作进展到测试阶段时，突然发现需求没有弄清楚，等于是整个工作从头再来，这不光降低了工作效率，而且对于开发人员的情绪打击很大。

重要的事情自然要由重要的人来做，应当安排经验丰富能力强的人来做需求分析。

新人考虑问题不周全，势必增加返工的次数，对软件质量危害很大，而且还会干扰其他人的工作，进而影响到整个公司的效率。

必须加强对需求的跟踪，我们的需求零散的分布在Bug Tracer，文档，Email里，对QA工作和工作交接都很不利。

每一次需求变更会影响到整个软件过程，所以在定义需求时要充分考虑，定义需求的工作自然也应该由经验丰富的人来做。

概要设计：

概要设计跟需求分析关联很大，需求分析要做的工作就是理清需求，决定由哪些模块协同完成，需求分析和概要设计由一个人来做会更方便。

概要设计包含了接口定义，一旦接口定下来，软件的框架就确定了，从而约束了后面的风险。接口变更带来的附加工作很多，接口制定的重要性是很明显的，还是那句话：重要的事情由重要的人做。

详细设计/编码调试：

在接口定义下来之后，接下来就是实现了，详细设计描述基本的实现算法和模块的子结构。

概要设计的输出就是详细设计的需求，这个需求是开发人员容易理解的。详细设计和编码应该有一个人来完成，因为这两部分结合紧密。

详细设计的目的：

1．评审，概要设计人员和同行可以对详细设计进行评审，以控制风险。

2．维护，当需求发生变更，或有Bug，详细设计可以给与指导。

3．交接，在人事变动和工作变更时，有详细设计文档可以方便的交接代码。

打铁要趁热，编码之后要立即进行调试和测试，一些明显的Bug应该在这个阶段被发现。

测试维护：

测试的核心价值是发现Bug，是以写CASE为主。

对CASE的整理很重要，CASE和需求是相关的，有必要将CASE与需求点对应并编写成文档，方便查找，在后续的修改中，开发人员可以通过这个文档找到相应CASE，对修改进行验证。

很多公司要求在需求确立后编写测试计划，这听上去很完美，但如果需求总是变更，很多工作将被浪费，所以我建议在开发进入到一定阶段的时候开始进行相关测试，因为这个时候需求相对稳定，而且符合打铁趁热的观念。

写到这儿，我对比一下两种开发方法，从而说明上述软件过程的必要性。

当前公司的开发模式有点类似于下图：

在这种模式里，每一项工作几乎从头至尾由一个人来完成。在这种模式下，人员之间的协同很少，高级员工和普通员工在工作性质上没有本质差别，由于工作不一样，高级员工不方便给与帮助，软件的质量由员工个人能力决定。由于能力差异，开发进度也很难控制。在这种开发模式里，看不到开发团队的影子。而且，到哪里招能独立开发的人员呢，招人难，用人难的问题突出。软件规模受到限制， CMM 认为，这种开发模式的人员极限是十几个人，源笙这么些年来，开发人员规模一直在十人左右停步不前甚至萎缩，恐怕就是这个原因。

当人员离职时，接手那一部分工作的人恐怕能做的就是祈祷别出问题了。因为从头到尾只有他一个人知道，他不需要写文档，所以没有文档留下来，他的代码没有人跟踪，所以质

量如何根本不知道。

我建议的开发模式图如下：

从上图中可以看到，每一项工作都是由一个团队协同完成的，开发人员根据能力资历的不同在团队中担任不同的任务，高级员工和普通员工共同开发，高级员工可以方便的给与普

通员工帮助，促进普通员工成长为高级员工，从而促进团队成长。软件的质量由团队的质量决定。

因为概要设计的输出就是下一步的需求，所以这种模式不受软件规模的限制，当软件规模扩大时，可以想象成由子需求形成的一个个小项目逐级开发。越是高层的概要设计越重要，称之为架构师，微软最重视的就是架构师，据说微软有一个架构师拥有7部豪华跑车。

用人问题得到解决，高级员工把需求分析成开发需求，在高级员工的帮助下，普通员工可以完成开发，并在其中成长为高级员工，团队得到成长。

那是不是说，高级员工就不需要作编码了呢，一些涉及流程控制，模块间交互的代码可以由高级员工掌握，这些模块的开发模式看上去跟前一种一样，从头至尾都由一个人完成，但本质是不同的，这属于高级员工的多角色担当，对于小型软件是很普遍的。

显然，高级员工就是一个工作团队的老大，一项工作是由高级员工带领一个团队完成的。代码版本控制

我们当前方式，所有人都往一个Branch里check in代码，这会造成相互干扰，所以每天检查regression成为一项繁重的工作。Regression每天都跑，服务器负担大，Regression 的邮件从早到晚几乎都没有停过，而且大部分的是Fail的，而检查这些Fail的工作量大部分是浪费的，因为很可能Fail只是一个人造成的。

更好的做法是：

开发人员在一个基准版本的基础上开发，隔一段时间做一次整合，生成一个新的基准颁布，开发人员再更新基准版本，每次集成测试都建立在基准版本上。开发人员在开发过程中进行单元测试，保证集成单元的质量。基准版本不是频繁更新，Regression不需要天天跑，没有更新就不需要跑，QA人员可以把精力用在写CASE上。这样，不管是单元测试还是集成测试，都遵循有更新就测试的原则，同意个CASE在同一个代码上跑一次就行了。

严格杜绝一个源文件多个人写的情况发生，一旦有人操作不当，对工作的干扰很大。事实上，采用上述的分工方式，也不会发生这种情况。

这样的话，我们需要如下几个Branch：

1．工作Branch，开发人员在这个Branch里开发，这个Branch不Make，只是用来保存所有的代码历史，不同开发人员拥有不同的源文件；除了自己拥有的文件

外其他的文件可以从基准版本里Link过来或者直接复制在用户目录，因为基准

版本不是频繁变更的，所以每次基准版本变更时更新一次就可以了，这就杜绝

了因为他人导致的编译不通过的情况发生。与他人发生交互而要更新别人的代

码时，开发人员协同完成，这是可控制的。工作人员在开发时，要进行单元测

试，保证单元内部的软件质量。

2．集成Branch，集成时，由负责人统一将工作Branch中的Code更新到集成Branch 中，这个工作没有难度却不容出错，不建议新员工做，这时负责人还可以通过

比较工具检查代码，对于较小的改动，很少的Coding Review工作非常有价值。

集成Branch有了之后，由QA进行集成测试，开发人员在这个时间集中解决问

题。

3．集成Branch测试稳定之后，生成新的基准版本，发布，通知所有开发人员更新基准版本。只有发生严重Bug才需要临时更新基准版本。

另外，使用Label而不是最新版本来获取代码，通过Label，可以在CVS里取得以往的所有版本。进行集成时，开发人员的代码也是以Label的形式提交的，当开发人员编码完成，