避免软件失败的7个关键实践

 

实践1. 邮件列表：把邮件列表作为主要的团队交流途径

前提是：摒弃仅以口头为主的交流方式，要用邮件备忘

口头的东西，有以下的缺陷：

容易产生误解；

容易遗忘；

无法对成果进行确认；

让我们：

白纸黑字，将功能（ Feature ），约定（ Commitment ），日程（ Deadline ）明确地写下来吧；

其中， Wiki ， BBS 等也是辅助的共享的手段。既是交流，也是证据。

好记性不如烂笔头

实践2. 配置管理：

对代码 / 测试程序和文档使用 CVS 管理

一般的公司对代码会有版本管理，但对文档就差一些了，而文档的版本恰恰是分歧的关键

CVS 配置管理的重要性，有哪些？很显然，

各归其位，变更有序；

清晰显示团队开发的所有代码；

实现测试数据管理自动化；

无需担心文件版本，文件名称的变更

但真正做到的很少

特别是，文档、测试数据的版本管理

例如，你提交的项目客户不认可，你的场景测试数据却不是原来的

谁都不会认同你

这里提及的 7 个实践都是最基本，但却做不好的地方

实践3. 需求管理：持续地整理、记录和跟踪用户的需求

这个说的简单，什么是客户需求

真实准确地把握客户的需求很难

例如， UI 每个人的看法还不一样的

尽量做到，“以客户为中心”，真实准确“抽引”出需求；

工具是辅助的也是必须的，但核心是执行

可以使用需求管理工具 (ExcelorMantisorDoors)

Mantis 是开源的

还有 IBM 的 ClearQuest

商业的都比较昂贵

实践4. 编码规范：遵循基本的编码规范书写代码

编码规范很基础，但有的公司编码规范有 50 条，基本不可执行了、太复杂、人记不住的

通常编码规范容易被忽视

要避免源程序当做“草稿”

源程序生命周期高于开发周期的，要尝试让他人阅读你的源程序

以免自己也像后浪骂前浪一样，写得是狗屎啊

拿一份印度的代码，高中生的，中国的程序员基本都会汗颜

对于前人太烂的代码，可以考虑敏捷的一些方法，尝试一下“代码重构”的方法

MartinFowler 是重构的鼻祖，很实践的方法，大家可以从书店找到他的书

实践5. 缺陷跟踪系统（BTS ）：使用jira 、mantis 、butterfly 、clearquest 等工具来管理测试中的缺陷

避免 BUG 反复出现；

快速及时找到 BUG ；

管理测试生命周期中各种烦心事

特别是客户提的问题，一定要反馈到这个系统上

用项目交付后的 bug 率来考核测试人员，用测试 bug 率考核开发人员，一切质量问题都迎刃而解

有的公司我知道，例如华为，一个客户反馈的 bug ，从一线到项目负责都会直接扣 500 以上的工资

实践6. 计划和周进度会议：制定计划并每周审查本周的成果和课题

避免失败的基本要素：

过分的乐观是 IT 开发早期的致命伤；

当心小偏差造成大问题；

时刻关注潜在的风险和危机；

每周一次的自我检查和诊断（ 5W2H ）

whatwherewhenwhyhow 。。。

要细致 review 不是简单的例会问一遍

实践7. 书面表述：准确完整地描述需求，成果和课题

程序员可以不注重文档，项目经理必须把文档当做基本功

重视文档的技术含量

需求文档、设计文档、阶段点的文档汇报等都体现的功底

将长句简化为短句，不要双重否定

文档就是用于理解的，而我们经常看到的文档是一段都是逗号，最后一个句号。

给评审人、领导设置障碍啊，呵呵

以上我们提了避免失败的 7 个实践，我们从正面谈持续成功的策略有哪些？

1) 开发的过程化

2) 标准化和分工

3) 自动化方法：自动化测试 / 自动 build 环境

4) 知识总结：留下知识和数据。

5) 人员能力的训练：不仅仅是过程

6) 经验的持续积累：强大的体制力量

ok 以上就是这个话题的分享结果