软件研发原则

这个是以前公司技术总监的文章，我这里给转载一下！涉及到公司名称的地方省略。

http://scorpioemissary.spaces.live.com/blog/cns!1613D1DB65D63A09!381.entry

 

 公司软件产品的研发应该遵循一些基本的原则和理念。这些原则在开发过程中的特定阶段或遇到问题时起到指导的作用，必须坚持贯彻这些理念才能开发出品质稳定的产品。这些原则和理念中的一部分同项目开发是一致的，部分则是相悖的，因此我们可以以项目的方式组织和推进产品研发，但是不能完全用对待项目的态度去对待产品。

以做“精”为目标
    一直以来，公司在产品研发中以实现功能为主要目标，尽力做到软件平台功能全、覆盖面广。毫无疑问，这样做是具有相当积极意义的，为形成市场影响力打下了基础。然而这些“完成”的功能有的具有试验性质，只是证明了技术路线的可行性；有的按照标准的方式，在假想完美的前提下实现功能，忽略了现实的各种异常情况。这样的功能在实际应用中显得很脆弱，会让用户很失望——在理论上指出了道路，但是实际上用产品却走不通。
    “实现”一个功能只是“完成”该功能的60%。完善的功能必须尽可能应对复杂的情况，在出错时具有优雅的表现。功能实现在不违背整体设计意图和概念的前提下，应尽可能考虑到输入的复杂性、异常性，用户使用该功能的上下文、习惯和意图。没有功能是独立的，它必然同某个工作环境或其它功能相关联，产品设计时需要时刻记住设计的是一栋宏伟的公共建筑物，而不是一块块砖头。
    只有设计和实现地足够“精”，完成了剩余的40%，用户才会觉得产品是实用的。“精”的标准是满足可用性和实用性的要求。这些要求除了来自真实的工作经历和最终用户的使用别无他途。认真收集和对待用户的反馈，建立专门的用户反馈和意见数据库，为软件的改进打下基础。当没有足够用户群时，通过考察具体的真实的用户工作环境，列举出不符合预期的情况和要求，检查功能是否能满足用户需求。
    功能做“精”必然要付出更多的成本，通常来说会和实现该功能相持平。当软件产品的研发进度难以保证时，“宁缺勿滥”是我们应对窘境的主要原则：就软件产品的用户来说，完成60%的产品等同于完成0%。

创造客户价值，维护客户利益
    软件没有被使用就没有任何价值。客户之所以使用软件，在正常情况下，是因为软件能够节约成本，创造价值。因此软件的价值就在于它为客户创造的价值，没有为客户价值而设计的软件是荒谬的。
    不能因为软件提供了诸多功能就说它能够为客户创造价值，是具有相当价值的产品。即使不考虑这些宣称的功能可不可用，如果设计产品的初衷不是基于为客户创造价值，如果产品不能为了客户价值持续改进，如果公司的研发团队漠视客户的利益和需求，如果公司的领导层不能围绕客户利益而决策，研发的产品必然是以公司自己为中心的，贪图快速的实现，省略异常情况的处理，忽视用户工作的具体情况，对用户的迫切反馈无动于衷。这样的产品绝不是有价值的产品，也不是可持续发展和改进的产品。
    创造客户价值，维护客户利益，这绝对不能成为一句空洞的口号。管理人员、设计人员和开发人员必须站在客户的角度，探索客户的行为作为工作的依据，作为产品改进的推动力。管理人员需要关注客户工作，不断思考我们提供什么功能才能为客户创造更多价值；设计人员需要关注客户的需求，不断思考功能如何交互才能使客户的工作更准确、便捷和高效；开发人员需要关注客户的行为，不断思考功能怎么实现才能带来更好的用户体验。同时，培养开发人员从系统整体出发，面向用户的态度是技术领导人员重要的职能。
    绝不能为了完成软件研发的任务而去设计和实现。在产品研发中，为何做，做什么、怎么做的初衷应基于用户价值和利益而决定，即使后期由于公司的具体情况可能会采取一些不同的方式，但是在向现实妥协的时候绝不能简单地忽略用户的价值。

考虑非功能需求
    软件的非功能需求通常是隐藏的，用户一般也不会在需求中表述的相当明确和全面，甚至常常简单的将其省略。非功能需求可以分为质量属性和约束两类，前者通常和软件产品中的绝大部分功能相关，是系统的整体品质，而不是仅仅表现在某个功能内部；后者是软件设计中必须遵循的限制。软件产品的设计人员习惯于根据功能需求搭建软件架构，研发及测试人员也根据功能设计开发和测试。然而非功能需求——高效性、稳定性、可扩展性、跨平台性、高可用性、可重用性、安全性等，常常是对软件的架构具有最大影响力的需求。
    功能需求同用户沟通，具体实现方式可以千变万化，只要保证满足用户功能要求即可；非功能需求通常表现为系统的运行指标，如果软件架构先天不足，没有针对这些指标而设计或优化，那么功能需求无论如何都不可能满足指标要求。
    因此，在进行产品设计之前，不但要进行功能需求分析，更重要的是要避免遗漏重要的非功能需求。产品的架构人员主要通过分析最终用户得到这些内容，但是公司本身对产品的态度和发展战略、研发人员的状况都会影响到非功能需求的内容：用户如果期望产品能够7×24小时运行，则产品的鲁棒性必须在设计中得到保障；公司如果期望产品能够进入海外市场，则国际化特性必须在设计时考虑到；如果研发人员分散工作，则软件结构最好是松耦合的，易于并行开发。
    一旦忽略了重要的非功能需求，那么对于产品的打击是致命的，在研发期几乎没有挽救的机会。这种失误会大大削弱产品的实用性，甚至使产品的研发失去意义。

保持概念完整性
    软件产品从上到下，从设计到提交，都必须保持其概念完整性。产品的每个功能都必须符合产品的概念定义，绝不能随意的添加和删除功能。对于破坏产品概念定义的功能，即使工作量再小，实现地再好也绝不能添加到产品中。只有学会说“不”的时候，我们才算有了真正的产品。
    产品的概念完整性决定了必须由少数人设计产品的架构。思维的一致性在设计中必须得到完美的体现。无论在任何时候，我们必须确保自己工作的就是“这个”产品，而不是一个越来越变样的软件怪物。在设计或研发中常常会涌现出新的想法和需求，决策人员必须仔细分析，抵制随意增加功能或设计补丁的诱惑。这些新的内容可以作为软件下一个版本的研发目标，只是它们不能破坏正在研发的产品概念。如果涌现了太多不符合产品概念的需求，那么架构人员就有必要考虑自己的设计是否存在严重问题，需要重新定义产品架构了。
    ××的SDM产品可以作为保持概念完整性的例子。尽管多次有呼声要求SDM增加对本地数据文件的支持，实现数据库和本地文件的叠加。但是SDM及其前身TOSA的产品概念中完全没有涉及到文件，其核心对象的接口也是数据库化的。虽然将文件支持强行加入到SDM中是可行的，但是将会非常勉强并且严重破坏SDM数据模型的语义。因此，SDM及其前身TOSA一直不支持文件数据，对它们来说，作为其它更广泛意义的数据模型的实现可能更合适。

充分听取意见，实施头脑风暴
    虽然是由少数人进行产品的架构设计，但是在设计之前广泛听取各方面的意见是非常重要的。就目前的产品状况，听取最终用户的意见，或者从事相关方向具体工作人员的意见尤为重要。这些意见、批评和反馈是进行产品设计和维护的重要依据，应该建立合适的机制使相关产品人员能够获取到这些信息。
    在建立产品概念的时候所有的信息都应该被毫无筛选的记录下来，尽可能广泛地实施头脑风暴。最终用户，行业权威人士，公司领导，公司研发人员，公司测试、技术支持和销售人员都在头脑风暴的实施范围内。这些信息最终由产品的主要实施人员综合整理和分类，逐一考察，最终筛选出部分需求作为待研发产品的重要特征和需求。通过这种方式，能够尽可能地避免设计人员遗漏重要的需求。
    在具体实施上，公司必须通过切实可行的方法达到上述目的：
 a. 就公司目前的情况而言，通常会由具有相当研发经验的高级技术人员总体负责产品的研发，实际上同时兼任产品经理和技术经理两个职位。但是最好同时应该从技术支持、测试甚至研发人员中委任一人担任产品经理助手。这个人员需要对产品的所属专业较为了解，最好具有专业背景，负责产品研发中的日常工作（信息整理、配置管理等），减轻总负责人的负担。助手虽然不负责产品的决策，却是众多看似琐碎实际重要的工作的责任人，对产品健康研发，持续发展具有重要意义，可以说是产品的“保姆”。
 b. 不定期的举办产品的座谈会，邀请销售、技术支持和相关专家参与，共同探讨产品的需求和规划。座谈会不能盲目召开，必须1)具有明确的目的。召集会议之前由产品经理及助手拟定会议探讨的主题、迫切需要了解的内容、待解决的问题以及参与会议的人员范围；2)会议的过程和结论必须由助手（绝不能临时指定某个人员）详细的记录下来，并且加入到产品的配置管理中，以备后查和分析。
 c. 由助手设计产品的调查问卷，针对不同的调查对象可能需要分别设计。这些问卷分发给目标群体后，由助手负责问卷的解释、收集和汇总并加入到产品的配置管理中。助手应分析所有的问卷，评价出质量较高的回馈上报产品负责人，最终公司可以给与一定奖励。
 d. 任何人员在任何时候都可以将自己对公司任何产品的意见和批评发送到××××通过在邮件标题中加入特定标签，如“[TitanImage]”、“[TitanSDM]”等，相关邮件会由特定的产品助手审阅和归档。产品助手必须确保所有的意见和反馈得到尽快地回应，绝不拖延。
 e. 信息的收集虽然重要，但是对其分析和整理后才能体现价值。产品助手将通过所有方式获得的信息进行整合，定期提交对这些信息的分析报告，指出哪些内容最受关注，哪些建议呼声最强，哪些问题影响最大等。

合理权衡研发三大要素
    对于软件研发来说，有三个因素对整个过程和结果具有至关重要的意义：
    用户需求
    产品质量
    研发进度
    这三者总是相互制约的，软件往往是开发团队就这三个方面的折衷。如果用一句话概括软件研发团队的任务，那么就是：在规定的时间内交付可以满足用户需求，质量合格的软件产品。
    虽然从理论上可以认为这三个因素同等重要，但是在实际工作中研发团队迫于压力常常不得不首先满足其中的部分因素，牺牲其它相对不重要的因素。对于项目研发来说，可能用户需求是最重要的，研发进度次之，产品质量最末；对于产品研发来说，可能产品质量是最重要的，用户需求次之，研发进度最末。每个研发团队必须认清主要因素，这样在面临压力的时候才能保持清醒头脑，作出科学的决策，保持团队前后一致的行为准则。
    将产品质量作为首要因素可能同以前的产品研发行为不太一致。这并不是说为了质量就可以无限制地削减功能或者推迟进度——这三个因素中的任何一个失败到一定程度都会使整个研发失去意义。产品质量作为首要因素是因为如果一个产品质量低劣，错误百出，那么无论付出多大的代价进行修补也不可能获得一个高质量的产品，除非重新设计软件的架构进行大范围的重写。因此，软件产品功能缺失在下一个版本还有机会补上，进度被延迟可以推迟发布，最终还是能得到期望的产品，但如果质量低劣那么前面付出的所有努力将化为乌有。所有成功的软件产品都有一次次不得不推迟发布的经历，但无论如何绝不会以低劣的质量发布给用户。
    虽然公司使用测试的方式进行软件质量的控制，但是就目前的实际状况而言起到的作用是相当有限的。测试团队应该发挥更大的作用，在整个产品生命周期内实现质量的控制：
 a. 测试人员必须在产品研发初期就介入，深入了解产品需求，理解产品概念模型，发掘产品的关键测试点。
 b. 在产品设计时测试人员需要把握设计，根据设计内容拟定重要的测试用例，区分重点测试内容和非重点内容，做到有的放矢而不是漫天撒网的测试。
 c. 测试人员需要科学的制定测试计划，测试行为应具有逻辑性、覆盖性，测试结果能从多个角度逼近问题所在。对每个测试内容都应明确可变的影响因素，一旦发现问题，可以尝试调整这些因素以缩小问题范围，例如错误描述“功能A输入数据X后会崩溃”对开发人员的帮助远不如“功能A输入具有特征Y的数据后会崩溃”。
 d. 测试人员在对专业功能测试之前，如果不具备专业背景知识必须预先学习。简单的操作测试虽然是必须的，但是不具有太大的实际意义。只有具有专业知识后才能分辨功能的正确性，设计有效和无效的输入，和同类软件在性能和精确性上做出判断，以及针对特有的限制测试。

任务细致化，进度公开化
    产品研发的进度控制和任务划分是产品负责人的重要责任。符合进度要求的产品能够给公司带来巨大的竞争力。控制进度首先要求对进度要有科学的估计，进度的制定是依据待研发的产品目标而定的，产品负责人应作为主要的决定人。公司从销售方面提出的产品研发进度要求只应影响到产品的研发目标，产品负责人需要考虑这些要求以裁减功能。
    研发过程中每个开发人员的工作任务需要划分到一定的粒度，不能过于庞大，便于管理和记录。通常每个开发人员的单项任务应该在5个工作日内可以完成，需要更长工作时间的任务应该被进一步划分。产品负责人分配的每个任务都应编号并记录下来，这些记录是测试人员在同步测试中的主要依据。产品负责人需要时刻关注每个研发人员的工作进度情况，帮助其解决技术难点，避免出现研发工作停滞的现象。
     研发人员的任务完成情况是评定其工作成果的主要依据，必须在工作汇报，如周报中体现出来。公司技术负责人必须定期审查这些提交的汇报，并有权针对其中内容提出质疑。
    产品研发在总体上应该划分为多个里程碑，每个里程碑具有较为明确的时间节点。在里程碑之间可以包含一定的设计工作和集中测试工作，类似于独立完整的软件研发过程；作为主体的开发则以较小粒度的，可快速推进的任务构成。在里程碑结束后必须进行总结，评价每个研发人员的工作成绩并进行相应的奖励。
    产品研发的进度并不应该仅仅由产品负责人或高层领导掌握，而应该公布给公司的所有员工。这种公布并不是说强制要求每个人都了解，其主要目的还是为了促进研发人员的工作进度。可以由专人，例如产品助手，将研发的甘特图张贴在研发办公室的墙上，如门口或饮水机旁，显示每个研发人员已完成和正在进行的任务，其状态——按时、拖延、提前分别以不同的形式表现出来。这种方式迫使负责人更加合理地分配任务，研发人员的工作成绩也体现的一清二楚。张贴的甘特图不用每周重复打印，可以采取贴纸条的方式更新其内容。

始终重视代码质量
    在产品的研发过程中，产品负责人需要时刻关注整个产品的代码质量。虽然产品的架构设计和详细设计是保证质量最根本的因素，但是作为细节的代码实现对软件的效率、维护性和健壮性也具有决定性的影响。
    代码质量的控制应该在产品研发的初期开始。在这个阶段需要确定产品的代码风格，建立保证质量的实现约束，规定代码的组织方式。所有的研发人员必须达成一致的共识，遵守共同的约定。
    在研发过程中，产品负责人需要检查所有研发人员的代码状况，一旦发现代码质量问题立刻做出响应。对于普遍存在的问题可以召集所有研发人员共同分析，集体改进。产品负责人对代码的检查可以以周为单位，但是通过在研发人员的计算机上安装定时运行的脚本程序，可以自动通过工具软件，如PC-Lint，检查研发人员当日更新代码的质量，并且把检查报告发送到产品配置库中。产品负责人每日检查这些报告，对质量问题特别严重的研发人员应及时提出改进意见。
    代码质量控制必须贯穿整个项目研发的始末，包括后期的集中测试时期。产品负责人作为主要的技术领导人员，可以把这个工作同提高研发人员编程技能结合起来，使每个员工在产品实施中获得自身的进步。