[软件工程]一个故事, 分析陷入焦油坑的软件项目

author: selfimpr

blog: http://blog.csdn.net/lgg201

mail: lgg860911@yahoo.com.cn

copyright: 转载请声明原出处.

本文的创作源于一位产品同事的质问: "Bug反反复复出现, 这是为什么呢?", 因此, 文中很多观点/场景是针对作者当下正在参与的项目的.

简单介绍下该项目一些主要的关注点:

项目类型: 互联网社交类网站

2012年3月26日之前: 用某开源项目二次开发主站(该开源项目代码凌乱, 质量偏低, 面向中小型用户)

2012年3月26日-2012年4月9日: 我和我的团队加入, 初期尝试对之前产品做结构优化, 后迫于时间压力中止, 忙于Bug修复

2012年4月10日-2012年6月1日: 需要针对客户端(ios/android)提供业务接口, 团队讨论后决定开发新的框架做这块业务, 后同样因为时间压力, 框架有不完善的地方, 但相对主站, 已经足以称道.

2012年6月2日至今: 优化/修Bug/新需求, 进入了焦油坑...每天的Bug和新需求让优化成为一句空谈.

基于上面前提, 本文的描述会基于一个具体的项目, 因此, 不是完全项目无关的软件工程理论分享.

正文:

在收到产品同事"Bug反反复复出现, 这是为什么呢?"的质问后, 和我的直接上级xp进行了简单的沟通, 晚上回到家又回想这个问题, 我想起了小学时候老师讲过的一个故事.

故事是这样的:

一个x国的研究团队, 在全世界各国做一个试验, 让7个小朋友, 每个小朋友拿一个用绳子串着小球, 绳子在小朋友的手中, 7个小球在同一个瓶子中, 瓶口大小只够一个小球同时进出, 当研究人员说开始后, 大家要在最短的时间内把所有小球以最快的速度拉出瓶子.

故事的末尾说只有在中国, 7位小朋友鱼贯而出, 用最短的时间拉出了全部小球.

相信大家都听过类似场景的故事, 我们不去关心究竟是哪国的小朋友用了最短的时间. 而是以此模拟目前项目开发的场景.

目前研发团队的人力资源(主要包括人员素质和团队规模)就是那个瓶口, 研发团队的任务(主要包括产品需求/Bug修复/代码优化/文档完善/流程完善/技能提升)就是那些小球.

我们的目标稍微复杂一点, 需要不断有小球进入, 也不断有小球被拉出, 最终目标是没有可再放入的小球或放入/拉出速度比例达到平衡点.

我们所作的第一件事是把当时已知的小球放进一个瓶子, 迫于时间压力, 我们随手捡起一个瓶子就开始放入小球.

现在, 我们发现瓶口太小了, 它的极限不足以应付小球的流量需求.

问题已经出现了, 下面就是解决方案:

1. 砸烂瓶子, 释放所有的小球, 很不幸, 游戏规则说这样是失败;

2. 一开始就选择更合适大小的瓶口, 不幸的是, "开始"已经成为过去, 我们无法改写历史;

3. 既然我们不能改变"开始", 那就改变现在的瓶口

大家都知道, 当历史已经造成的时候, 我们应该选择第三个方案, 可惜的是, 事情并不是那么简单

瓶口在改造的过程中仍然必须承担运输的责任.

上面标黑的观点, 我想大家都应该是认同的!

所以, 所有期望这件事更好的完成的人, 目标, 认知其实都应该是一致的.

可是, 在对上面观点保持赞成的同时, 我们还应该认识到另外一个观点:

瓶口在承担运输责任的同时进行改造, 那么, 运输责任越大, 改造成本越高, 改造质量越低, 改造时间越长, 改造中车祸越多.

这个观点, 我想已经属于常识了, 就像运行中的高速公路一样, 它要进行维修, 必然也符合上面的规则.

责任是谁的?

一个可能有的错误认识是:  既然这样, 那责任必然在于选择瓶子的人.

不错, 责任在于选择瓶子的人; 但一定需要分析那个执行选择瓶子这件事的人, 是否出于本人专业素养/经验/常识等原因完全自主选择瓶子.

不过, 事情往往不是这样, 每一件事情, 执行者的意识干预通常都不是全部, 这一点在团队协作时尤其明显.

因此, 我们可以去观察很多事情, 意识的形成会受到各种环境因素的干预, 比如: 时间, 成本, 承诺, 合作者, 竞争者, 用户, 前置事件等等.

那么, 通常来说, 这个观点更加适用:  事件执行意识的产生, 由所有参与者共同决定(哪怕某个参与者自始至终没有一句话的沟通交流).

因此,  责任是整个团队共同的.

我相信这样分析, 大家会认同上面的观点.

如果你仍然不认同上面黑体大字描述的观点, 那么下面的内容将不会有任何意义.

如果你目前认同上面黑体大字描述的观点, 我们就用这些观点分析我们自己团队/项目的问题

场景映射:

1. 产品团队负责将小球放入瓶子

2. 研发团队负责将小球拉出瓶子

3. 瓶口主要受限条件为: 已有程序架构, 已有代码质量, 研发人员平均技能, 研发团队规模, 研发团队激情, 决策者等等.

限于开发之初的各种环境因素, 瓶口大小目前固定.

产品团队意愿: 增加瓶口流量, 加大单位时间完成量.

研发团队意愿: 放缓瓶口流量, 花更多精力拓宽瓶口.

矛盾聚焦:

产品团队: 当前响应速度满足不了用户, 到时候没用户你自己玩啊?

研发团队: 水库的闸还不稳当, 一旦开的过大, 必然导致无法控制, 到时候谁玩谁啊?

说到这里, 观点其实很明确, 经常和xp讨论问题, 最终都会归结到" 度"的问题.

当研发感觉到需求过多, 无法控制开发过程的时候, 要么 崩溃, 要么 降低质量, 要么 拒绝服务.

当产品感觉研发响应慢时, 必然满腹牢骚.

接下来谈谈关于问题的解决方面, 我的观点.

首先, 请不要和别人比, 在团队素质/团队规模/时间压力/成本投入等各种环境因素对等的条件下, 任何团队都可以做到!!!

当前的问题, 正如<人月神话>中所言, 我们和很多团队一样, 陷入了 焦油坑.

这种情况下, 我们应该和<人月神话>中谈到的 外科手术队伍一样, 有一个 主刀医生, 在研发团队中, xp正在扮演着这个角色.

说的具体一些, 我们的产品需求和线上Bug应该有 明确的优先级, 不过, 很多时候, 当研发团队提出这个要求的时候,  "所有的产品需求都会变成高优先级", 或者说,  "高优先级任务会很快突破研发瓶颈", 因此, 面对这些问题, 考验的不仅仅是研发团队, 因为我们所有人都在做同一件事情, 如果各顾各, 不会有长久的美景...

有一种工作方法叫做"Get Things Done", 还有一种方法叫做"Pomodoro", 它们更多的用在个人工作分片及时间的组织管理, 在写完上面的文字之后, 我觉得它们其实就是在防止" 过多高优先级任务干扰视听"的发生.

最后, 引一句<人月神话>提到的, 新奥尔良Antoine餐厅菜单上的笺言: " 美食的烹调需要时间; 片刻等待, 更多美味, 更多享受".