Software Engineering

   客户可以是顾客、最终用户、市场部门或者上司。 “在所有项目中，通过改善客户关系提高开发速度是一条普遍适用的原则”。 泛泛地说，   1.良好的客户关系(合作而不是敌对)，能够提高实际的开发速度   2.在开发时表现出明显的进度，则会增加客户对开发人员的信任度。 具体一点：   1.可以避免无谓的流程上的损失，比如通过沟通让客户清楚流程，让客户确定他们哪个人要在什么时刻做什么事   2.频繁反馈，开发出来的东西有不妥的地方时可以立即纠正，避免大规模返工   3.双方关系好，事情也好商量 面向客户开发的四个方面：   1. 计划     a.选择合适的生命周期模型     b.这个项目是要让业务部门满意（客户A）还是要让你自己的上司满意（客户B）？搞清楚这一点，再去投其所好     c.建立有效的客户沟通渠道，尽量让对方只派一个接口人，以节省沟通效率     d.注意与客户有关的风险   2. 需求分析：前期要挖掘出客户的真正需求，可以避免在后期出现相关的风险       3. 设计：你的设计要允许客户偶尔提出需求变更，这需要你理解清楚需求表面之后的隐藏信息，预料客户可能提出的变更。“我们尽量做到能够满足一些变更要求，当然这并不意味着可以无休止地提出变更，但我们会努力做到不让你们过分为难”。       4. 实现     a.代码应易读易改，以提高应对客户需求变化的能力     b.开发计划中多设置一些里程碑，让客户能感觉到项目始终在进展(我的经验：也可以使开发的“完成百分比”可视)     c.一个功能点可以先把界面做出来，让客户能够尽早地看到，有问题可以及早修正 合理控制客户的期望值    1.如果让客户产生了不切实际的期望，即使你做的很好，客户也会很失望，把你当成失败者，客户关系会受到损害    2.对一份不现实的进度计划表示同意，必然会使客户产生不现实的期望值    3.客户可能会认为某些功能很容易实现，或者认为某些功能不用明说开发人员也应该会实现，这些地雷都要提前扫清，否则客户到最后会很失望

“过紧或不合理的进度计划可能是软件开发过程中唯一最具破坏力的杀手” 误区之一：过于乐观的计划    真实案例：按Bill Gates要求，WinWord 1　计划一年完成(过于乐观)，实际上花了五年；而合适的周期应该是26个月。 　　 后果：       1. 计划的精确度会非常差，按期交付的概率会很低       2. 在乐观和侥幸的心情下，计划本身的质量会比较差，比如说，资源计划、风险计划的质量都不会高       3. 由于计划质量太差，可能导致大家在执行时干脆抛弃计划       4.前期某些关键步骤不得不匆忙完成，导致后期加倍偿还这些债务       5.计划不得不反复修订，让项目经理精疲力尽       6.让客户失望。客户会认为你们不行。       7.在压力下，收尾工作只能仓促完成，为日后的返工埋下伏笔 误区之二：超负荷的进度压力   后果：     1. 质量问题     2. 一厢情愿地相信风险不会发生 　　３. 疲于奔命，抑制创造性思维     4. 疲惫，打完鬼子后不愿再打共军     5. 有人干脆中途退出 　　６. 开发人员没时间学习，影响他们的成长     7. 影响士气，管理人员与开发人员成为敌人 解决问题的关键是说服别人接受合理的计划，要做到这一点，就 要提高开发人员的谈判能力 开发人员应采取的谈判策略： 有原则，并以双赢为目标     1. 站在管理者立场上考虑问题，以合作的态度建立良好的双边关系。对方发脾气了，也要耐心听完，并表示理解。     …

《快速软件开发》学习笔记 – Part 2.4　合理的进度计划 Read More »

不同类型的项目应采用不同的开发方法 你要在产品、费用和进度上保持平衡,通常你只能三选二 要走“快速开发”的路子，你要估好以下事情： 1.选择合适的软件生命周期模型  2.估算 3.进度计划 4.面向客户开发 5.激励 6.团队合作 7.团队结构 8.功能限定 9.生产力工具 10.挽救即将失败的项目

书中提到了很多种软件生命周期模型，这里我只列最常用的两种（这本书写成时“敏捷开发”还没问世，所以没把它包括进来） 选择合适的生命期模型：是瀑布还是其他？ 下图是瀑布模型和螺旋模型的比较：

没有准确的进度估算，再有效的进度计划也无从谈起 软件估算的特征：    1. 要承认，软件估算是困难的    2. 随着项目进行，估算才逐渐变精确。 如何估算？ 估算的关键步骤是估算功能点，然后累加后得出人月数，最后轻松得出进度 在估算的不准确性上和客户要求的准确性上取得平衡   1. 与其拍胸脯给出准确估计，不如给出一个范围：[估计值*乐观系数, 估计值*悲观系数]。如果客户一定要你给个精确数字，你要告诉他你也不知道，但要跟他说“一旦我知道了，我立即告诉你”   2. 如何向客户解释估算难的问题？可以用“盖房子”来比喻。刚开始接触时建筑公司并不知道客户的房子要确切地盖成什么样，等图纸出来以后才能给一个相对靠谱的评估；但即使到了这个阶段，一些细致末节如门窗、地砖的规格也仍然还没确定，这时的估算仍然不够精确。但好的一面是，随着项目的进展，估算会越来越准确。   3. 管理好客户的预期，让他们一开始就接受“估算是会被修正的”，发生修正并不等于进度被拖延了、项目出了问题。不过，估算的修正要显得有序，并且要可视化。   准确估算的技巧：      1.在没有估算之前，不要跟别人说“大概要一周”      2.花时间进行估算，必要时把“估算”活动本身当作一个项目规划好      3.参考以往项目的数据      4.让开发人员，尤其是本项目的开发人员来参与估算      5.Review      6.把功能分得足够细再估算      7.不要忽略小任务      8.使用估算工具      9.使用多种估算技术，然后比较结果，这样或许会让你发现一些遗漏 附：常见的修正时机和估计值的系数   

实现快速开发的 四大基本策略（“and”关系）：   1.避免典型错误 (必须）   2.找好开发基础 (必须）   3.管理风险，以避免灾难的发生 （必须）   4.采用面向进度管理的实践 （有用但不是必须） 影响软件项目成功的四个维度：   1.人员。如组织架构，开发人员水平，激励等   2.过程   3.产品。如产品规模   4.技术 四个维度必须都要给力，不能偏废 书上提出了一个概念叫做“有效开发”，这种风格强调成本、进度与功能的平衡；当然，它并不是唯一的路，如果你觉得进度最重要，那可以更多地采取面向进度的实践 本书不提倡的快速开发方式：code-like-hell，不做细致规划+拼命加班。它的缺点有：   1.加班未必就能及时交付   2.长期激励问题。老让人加班意味着不停给甜头，否则人家走人   3.不可重复。这个项目加班加多了，下个项目可能就会怠工   4.无组织无计划造成开发组织与其它组织沟通混乱，冲突增多 本书提倡的策略是：   1.周密地计划   2.有效利用时间。用心工作而不是辛苦工作。   3.采用基于进度的实践  

  本书一个观点：项目成功往往不是因为你做了多少正确的事，而是因为你避免很多错误的事 下面就是作者眼中的典型错误，我们可以看看哪些对我们有帮助： 与人员相关的典型错误：   1.挫伤积极性   2.人员素质低，无法胜任   3.对有问题的人员没有采取措施，任由他破坏项目   4.英雄主义。导致风险，削弱多个角色的合作   5.项目后期加入人员 (why not?)   6.办公环境拥挤杂乱（这也不行？）   7.开发人员与客户之间发生摩擦(缺少沟通)   8.不现实的预期：三个月就要完成怀孕生子   9.缺乏管理层支持 10.缺乏各种角色的齐心协力 11.缺乏用户早期介入 12.一味搞管理、搞政治，忽略了实际的产出 13.自欺欺人地作出假设：“我敢肯定客户不需要这个功能” 与过程相关的典型错误： 1.过于乐观的计划. Mission Impossible. 2.缺乏足够的风险管理，没有主动预防典型错误 3.对承包方不加认真管理 4.缺乏计划 5.放弃计划 6.“项目前期工作”没有做好时间管理 7.不切实际地跳过需求、设计等前期工作 8.设计低劣，过多workarounds 9.缺少QA 10.缺少管理控制，项目追踪 11.太早或过于频繁的集成，导致浪费时间 12.估算时漏掉必要的任务：“这个东西很快就可以做好，可以不计入” 13.功能变化时不是去修订计划，而只是追赶计划 14.直接进行编码 与产品有关的典型错误 1.开发不需要或者不重要的功能 2.失控的需求变更 3.开发人员想玩新酷技术 4.在进度改变的同时加入新的功能（为什么说这错了？） 5.不是在做软件开发，而是在做软件研究（不确定性太多） 与技术有关的典型错误 1.盲目采用别人宣传的"银弹" 2.过高估计新技术、新方法带来的节省量 3.项目中间换用新工具，忽略了高昂的学习成本 …

《快速软件开发》学习笔记 – Part 1.2 避免典型错误 Read More »

项目成功的关键是：“打好开发基础”，这里的“开发基础”是指跟软件过程相关的基础设施和规则是不是够完整、够成熟。 具体来说这包括管理、技术和QA三方面的东西。 　１.管理原则： 计划制定，准确度量，计划跟踪都要有   2. 技术原则： 需求管理要正规，不要轻易略过设计步骤，开发规范要做好, SCM也要做好   3. QA原则：  “最少缺陷的产品也就是开发时间最短的产品”，提测前要充分自测，鉴别出易错模块并重点考察其质量，做单元测试，Review

风险管理的目标是预防风险和消灭产生风险的根源 风险管理主要分两部分：   1.风险评估。     a.识别风险，包括计划、管理、开发环境、客户、承包商、需求、产品、法律、产品、人员方面的风险（原书中文版68页详细列出了常见的风险）     b.分析风险：评估风险发生的概率及其破坏力     c.评定风险的权重，以区别对待     d.可以制定风险列表   2.风险控制。常见手段有：    a.不冒险    b.预先确认好，打好招呼    c.把风险分摊到别人头上    d.让利益相关人预先知道风险发生的后果，万一发生了他们也不会太吃惊    e.制定B计划    f.在项目执行过程中使用风险监控手段,比如定期回顾风险列表

下面以一个完整的例子，介绍MS Project 2007的使用。它基本覆盖了Project在项目管理中的典型使用（成本相关除外） 1. 项目信息设置   a.创建一个Project，命名为“经典软件项目.mpp”   b.修改日历: 工具->更改工作时间，调整一下国庆、元旦等相关的节假日 2.　 创建资源（干活的人）    a.视图->资源工作表，创建两个资源，Jack 和　Jones   b.把Jones的最大单位置为50%，因为我们假定她只能投入50%的日常时间到这个项目中来 3. 创建任务列表   a.显示顶层的摘要任务和大纲数字： 先切换到甘特图，然后工具->选项->“视图”选项卡，勾选“显示项目摘要任务”和“显示大纲数字”   b.加入“工时”列   c.在摘要任务下依次添加四个任务及它们的子任务，设定工期，分配资源，并根据任务间的逻辑关系(先不考虑资源竞争问题)设定它们的依赖关系。        如下图：       d.观察一下3.1，你会发现　工时8 = 工期2天　* 8小时 * Jones的50%    4. 调配资源    你会发现Jack在18号既要开发注册模块，又要开发登录模块，这不合情理。(可以切换到“资源工作表”视图看看报警信息)     你可以把注册模块变成登录模块的后续任务，但这并不灵活，因为注册与登录本没有逻辑先后关系，强行设定一个逻辑关系后，一旦来了个新资源，为了让他跟Jack一个做登录一个做注册，就得去掉这种逻辑关系。     正确的做法是让Project自动帮你调配资源。点击：工具->调配资源，选择“自动”(每次调整任务后都不用再手工调配了)，“调配顺序”设为“只按标识号”(为什么要用这个？试试别的选项就知道了)，去选下面四个选项，点“开始调配” 5. 准备跟踪    计划做到这里就差不多了。项目开始后的追踪就是用实际执行情况跟原计划对比，因此有必要把原计划保存为“比较基准”(又称基线)。    工具　 -> 跟踪　-> 设置比较基准    …

例示MS Project 2007的使用 Read More »