开发管理

1、说说开发管理

奶爸十几年的IT生涯，作为开发负责人的时间其实并不长，大概有1年左右的时间，所以对开发管理谈不上理解很深，但也有些自己独到的见解。

我今天抛个砖出来，供大家参考，我当时管得开发团队大概有10个人左右，2个设计人员，其余都是水平不等的开发人员。

奶爸认为开发管理最重要的就是要做到精细化，开发程序不是做产品、做需求，必须要有一套非常精密的逻辑才能做得下去，所以对应的开发管理必须也要精细化。

我认为作为一个开发负责人，要从几个方面做好开发管理：开发规范、开发计划、沟通机制。

2、开发规范

作为开发人员要明确开发团队需要使用的开发规范，我觉得最重要的有2个规范“编码规范”和“前后台开发规范”。

这两个规范一般在公司产品线级别就会定义好，不同开发团队只要根据项目的实际情况剪裁使用就可以了，如果很不幸你们公司没有，最好自己也要定一个简单的开发规范，保证整个研发团队有共同的沟通语言。

编码规范是为了让代码清晰整洁、增强可读性，对程序员而言尤为重要，主要有如下几个原因：

（1）一个软件的生命周期中，80%的花费在于维护；

（2）几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护；

（3）编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码；

编码规范包含文件命名规范、文件组织规范、缩进排版规范、注释规范、变量声明规范、语句编写规范等。

下面我举个例子说明一下，比如变量声明的规范：

变量声明规范

前后台开发规范，主要是为了规范研发过程，是团队合作的主要参考资料，包含前台的界面规范及后台的服务开发规范。

以客户端开发规范示例如下：

客户端编辑按钮1 客户端编辑按钮2

3、开发计划

开发计划的分解和执行监控是两个最关键的问题。

开发计划制定，如果要做到精细化，每个开发任务的工作量要细化到小时的量级，如果开发团队分为前后和后台开发人员，还需要将前台和后台的开发任务分开。

还有很很重要的一点就是，某个项目开发可能涉及到架构组的人（架构组的人都是技术大牛，是公共资源，N多个开发团队都在抢着用），需要单独排计划，免得影响开发进度。

开发计划的执行，奶爸推荐一个比较不错的工具叫JIRA，所有的开发任务、测试bug、生产bug通过JIRA可以展示的清清楚楚。

开发进度有延期还能发邮件、发短信提醒，非常方便。

JIRA对BUG的管理非常规范，按照bug的严重性，从上到下，分别为Bloker、Critical、Major、Minor、Trivial。 

我当时对不同类型bug的定义如下，作为一个小点，供大家参考。

Bloker ----严重错误，包括以下各种错误：

（1）由于程序所引起的死机，非法退出

（2）死循环

（3）数据库发生死锁

（4）因错误操作导致的程序中断

（5）功能错误（需求未实现）

（6）与数据库连接错误

（7）数据通讯错误

Critical----较严重错误，包括以下各种错误：

（1）程序错误

（2）程序接口错误

（3）数据库的表、业务规则、缺省值未加完整性等约束条件

Major ----一般性错误，包括以下各种错误：

（1）操作界面错误（包括数据窗口内列名定义、含义是否一致）

（2）简单的输入限制未放在前台进行控制

（3）删除操作未给出提示

（4）数据库表中有过多的空字段

（5）打印内容、格式错误

Minor ----较小错误，包括以下各种错误：

（1）界面不规范

（2）辅助说明描述不清楚

（3）输入输出不规范

（4）操作未给用户提示

（5）提示窗口文字未采用行业术语

（6）可输入区域和只读区域没有明显的区分标志

Trivial ----测试建议性问题

4、沟通机制

奶爸推荐研发负责人，建立晨会制度，每天通过晨会的沟通，再次明确当天的开发任务，有问题的地方提出来，大家共同解决。

我认为晨会制度最重要的价值，就是建立仪式感，通过这个仪式，让大家尽快聚焦，进入角色，提高生产效率。

就像有些大作家，在写作之前必须先要沐浴更衣，这样才能更有创作灵感，才女林徽因就是这样的人，每次写作之前都要焚香插花，沐浴更衣，想必人间四月天，就是在这样的情境下写出来的吧。

---

开发管理远比这要复杂，是个系统工程，我只是截取了几个我认为比较重要的点和大家分享。