环境、现状与反思

1 咱们今日的窘境

1.1 环境

　　咱们所处的环境是一个追求“革命性技术”的业界。公司追求着多、快、好、省地解决问题的捷径，管理者关注的只是软件进度、发布版本、成本和利润，在他们背后，软件缺陷已经埋了下来。专一代码质量的程序员每每不受青睐，由于他们思考的更多，在开发进度方面每每不尽人意。当项目负责人没法评估或不关注代码质量时，客户只会获得一堆调试不良的代码。

1.2 人才流失

　　今天的程序员大多数都不会长期从事某一种技术，这与收入紧密挂钩。程序员会倾向与转型为更高收入的技术队伍，或者退出IT业。随着市场供求关系，各个阵营市场占有率，利润等多种因素左右着程序员的收入。即使是在某个技术上十分出众的程序员，面对经济上的现实差距，也没法抵抗金钱的诱惑而转投其余技术队伍。如今的市场，再也不尊重那些资深从业者，而是迎合“现学现卖”的投机者。归其根本在于，对代码质量的低要求，使得技术硬手无用武之地。

1.3 系统交互复杂

　　今日的信息化系统已经不能由独立的公司或软件产品承担，而是趋于多公司，多平台的相互协做与交互。现实的挑战就是，更大的系统，更多的平台，更繁琐的流程，更复杂的整合需求，以及更多的标准。

1.4 技术快餐

　　与以前不一样，现今的开发者更为大胆。他们勇于将未经验证的新技术应用与产品或项目。开发者可能通过短暂的学习（一周或者几天）就将学到的并不熟练的技术应用于项目，以后的风险所有转嫁的测试或者客户身上。而此后也再也不对这些新技术继续安排学习。程序的可靠程度和可维护性大大下降。

1.5 产品团队不堪重负

　　与项目不一样，产品的代码版本及分支路线更为复杂，其生命周期更长。当你进入某个产品项目，你极可能面临的是，缺失或低质的项目文档，多种风格并存的代码以及潦草的少的可怜的注释。那些最早搭建系统的前辈可能已经离职，开发团队组成也许已经通过几代，你听到的最多的是抱怨。面对那些延期的bug和新的需求，没人通晓这些堆积如山的代码，牵一发每每动全身。阅读和理解代码占据工做的大部分，面对客户的各类要求每每不堪负重。

2 一些成功的经验

2.1 提升代码质量 

• 改进QA流程 多数QA仅仅依靠大范围的人工测试来评价项目质量，即多数公司的QA依靠的是测试团队。理想状况下，大范围的测试并不会有很高的错误检出率。（若是你的团队，每次发布版本，大家的新建和从新打开的bug数量仍然很高，我只能说大家的公司尚处于软件做坊阶段，真正成熟的团队，是不会容许交付测试团队一堆调试不良的代码的，即使是在赶工时。）检查缺陷最有效，同时也是检出率最高的方法，就是——代码审查。所以，必须在计划阶段，就为代码审查预留时间，以便让开发人员参与进来。
• 激励手段 在绩效结构中，应该与质量、进度、复杂度等挂钩，而不是单纯地只看进度。
• 测试每个关键里程碑 理想状况下，测试每一个版本，测试用例作到100%的覆盖率。但现实中，出于时间、成本等因素，测试不可能细化到边边角角。但对每一个里程碑进行全面回归测试是最低的要求，这样软件的bug更少，开发团队更能受到激励（例外是测试报告不尽如人意）。
• 乐观的对待错误 不要把测试当成是对代码的鸡蛋里面挑骨头，不要埋怨为何测试如今才测试出以前某个版本的缺陷。PM必定要避免开发团队和测试团队之间的相互指责。
• 要求清晰、简洁、明清的测试报告 测试报告应该言简意赅，不要过于追求样式华丽，技术型文档可以用一句话说明白就别啰嗦。
• 使用缺陷核对表 “缺陷核对表”我也想不起它的出处了，也或许是个人主观创造，但从项目实践角度讲，“缺席核对表”可以有效下降缺陷数量。下列显示了一种简单的缺陷核对表：

问题描述	根本缘由	缺陷类型	严重程度	出现次数	解决方法
修改下拉列表内容后，进行操做会触发未处理异常。	数据完整性约束被破坏，阻止操做。	设计缺陷	严重	4	禁止修改下拉列表选项。
上传大文件报错。	服务端限流。	配置缺陷	通常	2	修改配置文件的消息大小限制。
...	...	...	...	...	...

　　这份表格是否好用，在于其更新的频率与用户群。它可以帮助PM及时发现bug集群，并能够经过例会或邮件打预防针，防止缺陷核对表上的bug蔓延。

2.2 为人才流失作准备

• 注重文档的积累并注重代码注释和编码规范
• 推进团队内部的交叉培训
• 在某些共识的环节上推进自动化
• 创建健全的雇员框架

2.3 一些成功的系统整合经验

• 组建跨职能团队 公司各个智能部门都有义务参与进系统整合，经过关键用户来平衡各部门的需求。
• 制定合理的进度计划 PM可以顶住压力，制定现实的计划，而不是经过削减范围或质量来迎合公司。
• 认真评估资源 不少项目须要外部开发人员参与，因此须要对这类资源进行能力评估，以便合理安排进度。
• 并行上线 在新系统没有经过最终审核以前，请保证旧系统的良好运做，同时维护好旧系统的数据。
• 作好打持久战的准备 不一样于制做网站或OA，整合项目牵扯到更多的需求，更复杂的系统和业务流程，所以，请作好需求频繁变动以及打持久战的准备，并让团队了解现状，防止团队由于长时间的开发和过少的里程碑而造成挫败感。

2.4 有效下降产品的维护成本

• 建立并维护文档 文档如代码同样是宝贵的组织过程资产。虽然敏捷软件开发注重能够工做的代码，可是，也不能打着敏捷的旗号来抵制文档。一些必须有的文档，好比：需求说明书、软件规格说明书、开发计划、设计文档、测试报告、变动控制等，须要归入到配置管理中去，而且在维护过程当中进行同步。
• 严格遵照编码规范 编码规范必须在项目组内部达成共识，因此开发人员必须严格遵照，有条件的推荐进行自动化的编码规范审查。
• 作好配置管理 请参考本人博文 SVN与SCM。
• 推进自动化 推进测试、发布、代码审查的自动化。
• 推进交叉培训 不要等到人员即将离职才分享他的经验，要在工做间隙，利用暗时间，推进团队造成交叉培训的习惯，使关键技术不会局限在单点。
• 快速处理产品问题 对于延期的bug要尽快处理，越晚处理，其修复成本越高，一旦开发者离职，让其接任人员来修复这些延期bug则有些强人所难。
• 对新技术提升警戒 评估新技术带来的风险与收益，选择那些知足企业宏观目标的技术，尽可能不要在高风险项目上引入未经实践的技术。对于技术探索项目，范围不要太大，并且，一次不要引入两个以上的新技术（也有保守的公司，规定技术探索项目，只能引入一个新技术点），以便能有效地评估收益和影响。在引入新技术的过程当中，通常用1/3的项目时间快速学习和吸取，用1/3的的世界培养团队自立，最后1/3的时间让团队成员彻底掌握。
• 完善项目管理 创建完善的项目管理流程，可以造成以客户为中心的，有完善体系的产品团队，即有效地协调需求、开发、测试、质管、实施等不一样资源，快速应对来自不一样客户的需求。

2.5 让团队成员参与项目管理

　　若是团队成员没能参与项目管理，则项目管理将大打折扣。为了让团队的每位成员都参与到项目管理中去，有如下建议：

• PM须要从团队成员角度思考某些问题 PM须要理解和接纳程序员的某些工做风格和激励因素。
• 适度的受权 对有能力的成员受权，不只能提升其积极性，也能让PM能专一于其余业务。
• 常开会，开小会 常常与成员沟通，了解项目现状，但不要开那种冗长的会议。
• 对于团队性决策力求达成共识 PM不要以权压人，对于如编码规范这类影响较大的规定，须要促成团队成员的共识，而不是自个人专断专行。若是PM搞独裁，那团队成员也会玩非暴力不合做。
• 在员工入职培训时强调项目管理 在入职培训课程中，明确项目组的各类规定，流程以及工做各类辅助管理软件的使用。

3 IT治理

　　IT治理就是要明确有关IT决策权的归属机制和有关IT责任的承担机制，以鼓励IT应用的指望行为的产生，以联接战略目标、业务目标和IT目标，从而使企业从IT中得到最大的价值。

3.1 IT治理成败20条

10条有效运用资源的方法：

1. 针对IT治理价值，与开发者保持坦率的沟通，解决其中问题而不是压制言论。
2. 组建公司级跨职能IT治理委员会，保证治理顺利推行，保证技术体现客户最大利益。
3. 创建量化指标，利用公认的指标评估治理进度。
4. 保证IT基础设施各部分的透明。
5. 将公司IT治理策略延伸到外包商。
6. 创建能表现业务目标的全景视图。
7. 将IT治理视为促进企业成长的基石，利用奖金引导员工的正确行为。
8. 对公司员工和团队内跟不上变化，相关技能欠缺等等迹象多加注意。
9. 在软件开发周期的每一个环节都实施IT治理，以防留下盲区，致使差错。
10. 推动自动化，但不抛弃人工评审流程。

10种白白挥霍资源的行为：

1. 未经解释就强制推行的官僚流程。
2. 架屋叠床的监督层级。
3. 无人能懂的报表。
4. 被隔离于代码以外的开发者。
5. 仅限于单个部门的努力。
6. 企图一切尽善尽美的紧张神经。
7. 仅在一两个方面实施IT治理的开发流程。
8. 缺少跟踪IT管理的支出和效果评估。
9. 重复创造的策略。
10. 对IT治理资源充足程度的盲目自信。

3.2 衡量IT治理和相关投资成效的10个问题

1. 管理层是否支持和实施IT治理？
2. 开发者是否参与其中？
3. 是不是公司的主动战略行动？
4. 是否增长了企业透明度，使部门和员工权责分明？
5. 是否让引入新技术和企业合并时的基础设施融合更加容易？
6. 可否帮助员工改进行为？
7. 是否给全部干系人提高价值？
8. 可否作到极尽精益和高效？
9. IT基础设施能否随时抽检，而保证没有问题？
10. 是否减小了软件缺陷？

4 杂谈——终结IT业七大流言

1. 信息技术是精确的科学 现实是， 创建应用依靠的是程序员的代码，而编码是一门艺术，程序员是匠人，信息技术一样须要工艺。
2. 下一个版本能解决这些问题 软件开发商的经常使用伎俩。
3. 开箱即用 企业级软件每每很难达到开箱即用，这每每是软件厂商的吹嘘。
4. 代码文档完善 现实是，开发人员被进度和变动压榨了120%的时间，无力维护文档。
5. 文档说明一切 文档质量良莠不齐，有时不得不聘请外部顾问。
6. 团队不须要“黑客”和“牛仔” 前者指那些擅长安全技术的人员，后者则指那些技术强硬但特立独行的人员，他们的共同特色是技术过硬，工资不菲。其实开发团队中若是有掌握安全技术的成员，能使你开发的系统更安全；而若是能驾驭牛仔，他将能帮助团队冲破围城。
7. 最大的安全威胁在公司外部 现实是，绝大多数攻击源自公司内部。

 

参考文献：

　　《差错 软件错误的致命影响》