2、项目沟通
      1.重要事项亲历亲为。
      2.每周的项目周报，除了知悉公司外，同步知悉客户。
      3.需求的分析及客户确认用原型图。需求的确认启动开发，必须是业务部、信息化部、公司三方达成一致。
      4.技术实现上会就会，不会就不会，和时间的多少没有线性关系。
      5.控制好工作节奏，多和领导沟通，自己的经历正是人家过去经历的重现。
      6.沟通项目存在的问题时尊重客观事实和软件开发规律，做不完的跟客户说明原因，该拒绝的果断。
      7.上线前的客户运作，除了项目层面的客户沟通，也请领导高层向客户高层沟通。
      8.强调需求变更会影响项目计划的执行，变更需要付出代价（优先策略：时间调整、功能调整、人力调整）。
      9.遵循‘做得少但质量好，忌讳做的多却质量差’的原则。
      10.项目风险且一时对得不到公司资源倾斜时，也可借助客户的力量（下下策）。
      11.客户的跟催，多耐心少急躁，多自省少借口，多客观少主观。
      12.交付时间的答复，不能当下给出的待评估后再给。

   3、项目流程：
      需求频繁且变更较多时，建议0.5周～1周一轮版本。每次汇报后产生的新需求、遗留需求、待开发的功能：
      1.整理《项目跟踪表》，含：新需求、遗留问题、关联影响（指导测试做关联模块的验证）
      2.测试人员将已明确的开发任务登记到BUG管理系统
      3.需求人员与开发、测试人员评审需求
      4.负责人牵头需求、开发、测试人员确定开发、测试、发布时间计划。
      5.与客户反馈交付时间点（对于小需求的交付时间可以直接答复、大需求要内部讨论再答复）。
      6.项目进度跟踪，以天为单位，测试人员更新《项目跟踪表》。
      7.需求验证介入
        1）开发提交代码后，需求人员、测试人员分别开展系统测试（业务角度，关注界面交互、主干流程、数据展现）、业务测试（系统角度，关注功能操作及边界、业务流程输入输出）。
        2）需求人员发现的问题，属于开发BUG登记到BUG管理系统、需求BUG与开发人员、甚至客户澄清，如不影响版本发布时间直接加入在研版本、如影响则提交变更请求，与客户沟通得到变更认可或与开发沟通得到变更认可。
      9.升级前，针对环境数据的准备，编写《升级注意事项（含数据清理、数据准备等）》给测试人员交代。
      10.升级后，需求人员在演示环境走业务测试（建议离正式演示前2天完成升级验证，提前1天环境冻结。）
      11.上线前，与客户沟通准备事项（含压力测试、工程部署、资料交付、培训计划、试运行计划等）

   4、客户汇报：
      1.小型汇报，前一天，系统冻结，不再做升级，只做业务验证、回归。
      2.大型汇报，前三天，系统冻结，不再做升级，只做业务验证、回归。
      3.汇报前，拿用户的笔记本做预演，防止操作系统、浏览器兼容问题。
      4.汇报思路：
        1）以一个业务主线，给客户讲故事,结合不同客户关注的角度出发，让平台能融入不同客户的日常工作。
        2）信息化前是什么样，信息化后是什么样（提高日常办公的效率、平台统计的数据提升客户的业绩等）
      5.项目初期注意界面UI友好，中期注意数据的规范及业务流程正确，后期注重统计数据的真实、准确。
      6.版本的技术问题、项目进度的问题、用户需求的问题、沟通协调的问题，实事求是汇报客户。
      7.汇报前与客户业务接口人沟通汇报内容、汇报方式，掌握领导听取汇报时关注的点。
      8.汇报前，关注业务部门的需求、信息化部门的建议、更要关注客户领导的关心点。

   5、业务关注：
      1.关注平台的数据输入、处理、输出数据的完整性、准确性、关联性。
      2.抓住平台的建设理念，所有业务模块围绕该理念开展需求分析、设计。
      3.降低线上复杂的业务操作流程（更多考虑结果数据的录入、留痕，流程多了很难同时在线协同办公）。
      4.技术实现的同时要考虑业务机制的配套。
      5.考虑现实性[在现有业务规章制度的环境下运行]、前瞻性[业务层面的发展方向]、可行性[技术是否支持]。
      6.关注和周边平台的数据结构一致和标准
      7.<待补充>

   6、时间评估：
      1.每天列出当天要做的工作、每天下班前回顾当天工作，每周列出本周工作成果、下周工作计划。
      2.任务时间评估 = [成员评估 结合 自评估] + 开发冗余（根据平台特性、开发人员经验及态度判断） + 测试冗余（根据平台特性、测试人员经验及态度判断） + 需求冗余（根据平台特性、需求人员经验及态度判断）+ 其他冗余（如请假、生病、开会等非项目因素）

   7、一些管理笔记：
      1.任务精准、给予空间
      2.狠抓住干、适当放权
      3.敢于承担、顶住冲击
      4.讲究诚信、承诺到位
      5.规则考核、理解包容
      6.用人不疑、疑人不用
      7.功劳大家、黑锅自己

内容如下：

错误一：错误的需求调研阶段，导致很多项目永远无法结束!

在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到，这房子你敢买么?除非你不是自己住！而在我们所学的软件工程概念模型中，这是三个阶段：需求调研、需求分析、概要设计。

在客户把他们想要管理的业务模块以及与之相关的业务数据、流程、表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，写出《需要规格说明书》就可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的5~10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。

有实施经验比较丰富的项目管理人员总结说，在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户来提需求作项目。这是一种很好的解决思路，但无法解决所有实施项目的难题。这种解决方案的前提，要么项目实施者有成熟的业务模型，要么有成熟的产品(包含了成熟的业务模型)，否则是不可能做到的。但如果没有3~5年在同一行业，同一领域的实施经验和理论总结，没有哪家IT企业能达到这样的前提要求。

其实得出这样结论的深层原因，是因为国内多数企业管理思想不成熟，更谈不上完善的业务模型，所以客户的思维一定程度是发散的，还未形成系统。甚至还有些客户的领导，脑子中有很多新鲜的点子，他都有可能想在企业信息化的实施过程中加进来，这对把控项目范围和项目实施效果来说，都可能是灾难的开始。

所以，要做好实施项目，实施者必须有很好的业务建模能力，快速的给客户展示合理的软件原型软件Demo。

请记住：软件实施项目，一定要给用户看到样板房软件Demo，才算需求调研结束!

错误二：IT技术人员不需要掌握项目管理

有这种看法的人不在少数。根据观察，之所以形成这种看法，一是对项目的真正概念不清晰，二是对管理的概念神话了，把管理理解成了高深莫测，非一般人能做的事情。首先有必要普及一下项目的概念。

对项目有很多人下过定义，项目管理圣经PMBOK第三版(2004版)的定义是：为创造某个独特的产品或服务，或完成某独特的任务所做的临时性努力。围绕这句话PMBOK做了详细的解释和举例说明，很严谨，想了解的请学习PMBOK。因为都是翻译过来的定义，翻译得过于术语化很容易把人绕进去，在国内不排除已经拿到PMP认证证书的专业人士还搞不清楚项目究竟是什么。笔者在这里只想用汉语最通俗的语言来说明什么是项目和项目管理。

项目，就是在限定的时间要人完成的事。记住三个关键字即可把握：人、时、事。

项目管理就是参与者用什么(知识、技能、工具、方法)来圆满地干好这件事。

明白了这些，你就会明白从日常生活的吃喝拉撒到国家管理，处处都是项目，处处都需要项目管理，也就能明白每个人都需要项目管理，也就能理解学会了项目管理将会多么受益无穷，娴熟运用项目管理思维将无往不胜!

但需要提醒大家一点，现在的PMBOK是把传统制造行业、建筑行业、IT行业等多个行业领域的项目管理知识糅合到了一起，大而全，但针对性不够好，所以很多人觉得PMBOK理论化太强，学完了觉得很多东西没用。现在国际知名的另外一套项目管理认证，IPMP是按照工作岗位能力进行了分级，也没有针对行业进行分解。所以，无论拿到PMP或者IPMP，很多人都会有同样的困惑。据了解，PMI已经准备做这样的改进，这是一个很好的消息。

错误三：忘记项目目标

你看到这个题目什么感觉?很多人会觉得这样的错误怎么会发生?几乎没有人会认为自己犯这个错误！忘记项目目标有两种情形：一是从开始接手项目就没弄清楚项目的目标是什么;二是虽然清楚项目的目标是什么，但却干着跟完成项目目标无关、甚至有害的事。

时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开。可是随着项目的逐步开展，尤其是复杂项目：人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的有：技术出身的项目经理会沉迷于技术细节，大量时间花在学习新技术或者一头闷在解决技术难题上;脾气火爆的项目经理会因为很多不值当的事情大发脾气，把团队搞得乌烟瘴气;小心眼、爱面子的项目经理会因为某个组员无意的顶撞而怀恨在心，从此总给其穿小鞋，搞得团队拉帮结派，毫不团结;还有更糟糕的，比如爱玩游戏的，爱喝小酒的等等。所有这些，无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那就是项目出问题，甚至失败。

项目经理最重要的一项任务就是跟踪与控制，时刻把握项目方向，保证项目计划得以顺利执行，偏差控制在可控风险范围内。但项目总是有太多意外因素，尤其是周期长的项目，人们常用夜长梦多来形容风险会随时间的延长而增加，所以项目经理一定时刻都要保持头脑清醒，对项目无益的事情不做，对项目有风险的事情更不能做。

任何项目在开展过程中都会不断面对机会和诱惑，项目经理一定要能明确项目大目标，才能清晰地识别哪些是使项目成功的机会，哪些是会给项目带来风险的诱惑，才会少走弯路，早日成功。项目管理者联盟，项目管理问题。

人是需要不断被提醒的，这由人性决定。智慧的人能够不断的反省从而自我提醒，愚笨的人会被挫折、外界的警示不断提醒，这就形成了成功与失败的差异。

错误四：计划不能变

怎样才能保证项目成功?计划，计划，再计划，这是项目管理的最佳实践！所以，做项目管理的一般都知道如何编制项目计划，并且很多人能熟练的使用Project工具，知道80小时或者40小时法则、WBS和关键路径的概念。每个项目经理都会记住计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响这个原则，也明白这样做不仅能够减少大量资源的浪费，产品的质量也能得到保障。所以，很多项目经理排斥，甚至拒绝改变计划。坚持原则，这貌似没什么错，但真的这样么?

要弄清楚一件事是否有必要做，首先就得弄清楚两个问题：一、这件事为什么要做?二、做了有什么好处?

那我们首先问一下编制计划的目的是什么?我们知道计划是项目管理的最佳实践，计划是保证项目成功的一种手段和方法，做这件事只有一个目的，那就是为了保证项目成功，但前提是，这份计划是周密的、可行的。严格执行一份周密可行的项目计划才能保证项目成功。很多项目经理记住了上面的严格执行原则，但忘记了这个大前提。

第二个问题，计划有什么好处?项目管理的计划方法，把项目活动、持续时间、所需资源有机地结合在一起，并且有严格的先后次序、里程碑和关键路径，可以清晰地提醒项目所有成员在什么时间，做什么事情，保证每个项目任务都得以执行;通过对计划的执行跟踪，项目经理可以清晰地了解项目进展情况和偏差情况，评估并及时有效的控制项目风险，从而保证项目的成功。

明白了这两点，我们再来看IT项目。对多数IT项目，尤其是软件实施项目，启动时都存在范围不够明晰，需求不确定的情况。只有到软件Demo产生，才可能需求清晰，范围确定，这些情况就决定了IT项目计划需要根据项目的实际情况及时进行修正。如何压缩范围确定的时间，早日制定出周密可行的计划，是软件项目的一个重要课题。

制定一份周密可行的计划是项目经理优秀能力的体现，尤其是WBS的制定，对复杂项目有很大难度。在谈2008奥运项目的管理体会时，项目专家曹蕾就提到奥运会项目最难的一点就是WBS的制定(参见PMU网站对2008奥运项目的访谈)。要保证项目的成功，就要保证项目的每个活动都能得以顺利执行。所以，在项目情况发生变化，在原有的计划基础上有需求变更时，就要把新的任务补充到计划中，修正计划，确保WBS的完整，确保计划周密可行，之后的工作才是严格执行。

顺便提一句，有些项目经理会走另外一个极端：因为需求不确定，所以不制定项目计划。这同样是对计划的错误理解。即使计划不够周密，但它可以提醒我们项目的大目标是什么，保证项目团队所采取的行动不偏离大方向。任何一项大的项目，都可以拆分成很多小项目，WBS的渐进明细，也是项目必须完成的任务之一，所有任务的持续时间都是要估算的，即使不够准确，至少可以作为经验累积，为今后的准确估算做了准备。因此，项目的任何阶段都一定要有计划。

错误五：项目一定要盈利

项目一定要盈利，这句话被无数IT项目经理奉为真理，也就注定了要创造很多悲剧！为了达到这个目的，很多IT项目经理甚至都在悉心研究厚黑学，学习用什么办法把小弟搞得热情高涨，比民工累，从而用最低的成本创造最大的利润。

项目管理作为战术层次的管理手段，一定要服务于战略层次的大方向。商场如战场，有胜利就会有失败。为了战略胜利，很多战役要诱敌深入，必须打败仗。败仗不要紧，关键要弄清楚败到什么层次，损失到何种地步，明确本次战役的真实目标，再去打这场战役，就会做到驾轻就熟，从而不至于到最后形成不仅损兵折将，还未能诱敌深入的局面。

开拓市场、占领市场、站稳市场、挖掘市场，这是每个公司发展必不可少的步骤。很多项目，对公司来说都是为了占领市场，甚至虎口夺食。这样的项目，公司从战略层面首先要求的绝对不是盈利，而是如何能把市场占领，继而站稳，项目经理必须明白这个战略意图。

平衡是项目管理最为重要的一个思想，从过去的做好质量、时间、成本项目三要素的平衡，到现在满足相关干系人的需求，所有的最佳实践和理论研究成果，都绝不会提倡走极端，杀机取卵！利润只是项目的一个目标，并且一定要明白有短期利润和长期利润之分，过分单一追求利润的项目注定要失败，过分追求利润的公司也不会长久。

该花的钱不能省，不该花的钱一分也不要花，项目经理把成本控制在合理的预算范围内，就是成本控制的成功。万万不可为了把一个注定要赔钱的项目做得盈利而想尽办法、绞尽脑汁压缩成本，从而让组员加班加点，玩命干活，到最后，项目干完了，人也走/光了，还极有可能因为赶工导致项目质量不合格，客户不满意，那就真的赔了夫人又折兵!

项目组要能保持激情高效，不能懒散拖沓，项目经理一定要把握好这个度，绝不能走极端。平衡是一门艺术，也是展示项目经理能力水平的一个重要标尺！

错误六：记住了科学，忘记了有效

学以致用，就怕乱用。无论是产品、技术还是管理方法，都存在为了更先进、更科学而罔顾现实，盲目乱用的现象，结果先进和科学的技术、工具不仅未提高生产效率，却成了累赘，这样的情况到处都是，在IT项目中也为数不少。

国内大量失败的ERP项目就是这类错误的典型。有人把ERP项目归结为一把手工程，意思是只有领导重视并推动才能成功。领导支持是项目成功很重要的一个条件，但绝不是有领导支持就一定能够成功。有些项目就是领导决策失误盲目上的，从开始就注定项目要失败。一个信息化项目的实施，对很多企业来说就是一场大的改革，对所有员工从思维、技能到工作习惯等多方面都需要进行调整。如果企业的员工素质不能跟上，纵然有各种各样的培训，但不顾员工基础和学习曲线，用户不能真正掌握全新的系统，结果就只能增加用户负担，而产生不了期望的效果。

很多IT项目经理在学习了一些新的技术后，总想立刻在项目中实践，而不去仔细分析这些技术在这个项目中是否需要，是否适合。IT技术日新月异，不断有新的理论被提出来，被翻译引进到国内。有些项目经理在一知半解，对这些技术还不是很熟悉的情况下，就敢向人吹嘘他所掌握技术的科学性、先进性，进而强制要求在项目中实践。这可能是甲方的项目经理，也可能是乙方的项目经理。因为技术选择错误导致项目失败的例子在国内过去有，现在也还有!绝对不可准备不足，大范围引入全新的技术，待到项目时间过去一半了，才发现选择的技术不适用，那时候一切都晚了。掌握任何新东西都有学习曲线，项目的时间限制是项目经理必须时刻牢记的要素，把握不好就会给项目带来极大风险。

涉及到具体的IT项目管理，PMBOK的知识体系可谓博大，还有一些其他新的项目管理工具，不能说不先进，但是哪些知识、工具、方法适合本项目，需要项目经理根据实情，认真分析后进行筛选使用。

科学、先进、好用等等修饰头衔这些都不是要选择的首要理由，需要、适用和有效才是首要考虑的事情。很多IT项目经理因为年轻，初生牛犊不怕虎，胆量大，勇气足，敢于在实践中引入新的工具、方法。敢于尝试不是坏事，但试验的风险一定要控制好。对于项目经理来说，所有的决策都要围绕项目目标进行。项目经理的首要任务是保证项目成功，如果同时能引入新的技术、工具，增加组员的知识技能，提升项目组工作效率，提高产品的质量和可靠性，绝对是锦上添花，但绝对不能为了锦上添花而导致项目失控甚至失败，捡了芝麻，丢了西瓜!
转自：http://sd.csdn.net/a/20110819/303332.html

在IT企业里产品从创意到交付给用户，从整体上看是由技术部门负责，但如果深入到技术部门，会发现由不同的技术团队负责不同的部分或者阶段。一般会分产品团队、开发团队、测试团队以及运维团队，在互联网公司里，运维团队一般还分基础运维和产品运维两个团队，基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装，为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。

从产品策划到上线，一般是以下边的顺序经过各个团队：

1. 开发团队收集产品的需求，定下时间表并进行开发
2. 开发完后，交由测试或质量团队进行测试
3. 然后交给运维团队布署新产品或新版本
4. 运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复

在上面的每个阶段，对应的团队都是各做各的，一般是在最后才会把球踢给下一个团队，如果下一个团队发现问题又会把球踢回原来的团队。如果你深入到不同的团队中去，或听到不同的抱怨声音。

基础运维团队经常抱怨：

• 产品开发一点计划都没有，突然要上线机器，让我们措手不及。
• 每个产品都急着上线，谁催得急就上谁的，谁能说一下，到底那个重要？
• 动不动就要重装系统，坏了一块盘就着急去修，刚从机房回来，又要过去。
• 上线太突然了，没有交换机，没有机架，还需要搬别的机器腾地方。
• 那个地方有机架和交换机端口，但没有四层设备，他们又要放在四层后边，真的没有办法了。
• 刚跟他们上线到一个机房，他们又说要换到另一个机房，尽折腾。
• 他们怎么能那么用设备，把上连端口带宽都跑满了。

产品运维团队会说：

• 真没办法，上个线不是说没机架，就是没有交换机，还有就是说没有四层设备。
• 从来不告诉我们什么时候能设备能上线交付给我们，不派专人催着这事，一点谱都没有。
• 本来没有想好怎么用这些设备，先提前一个月申请上线，得我们想清楚了，他们却说又得换机房。
• 网络怎么老是出问题，他们怎么规划的。
• 开发的代码太不靠谱，一上线就引发用户投诉，只能回滚到老版本。
• 开发人员的技术能力不行，写不出能用的版本。
• 开发要求有一个跟生产环境一样的测试环境，这不可能有的。

而开发团队却说：

• 他们又不让我们碰线上的系统，生产环境是什么样，我们都不知道，没法开发代码。
• 我们辛苦开发几个月，上线出问题又直接回滚了，心情很不好受。
• 代码在测试环境或我的机器跑的好好的呀，怎么一上线就出问题呢。
• 测试怎么测的，那么多问题发现不了。
• 我们希望产品运维同事帮忙搭一个跟线上一模一样的测试环境。

另外，测试团队的人也许会说：

• 开发人员不写规定写单元测试代码。
• 想着能用一个自动的集成测试环境，因为开发的原因，老是实现不了。
• 测试环境跟生产环境不一样，好多问题才发现
• 还有那么多的bug没有解决，产品就催着上线。

二、技术团队之间配合不好的影响

上面看到的团队之间的冲突和抱怨问题虽然都不一样，产生的影响确是类似的：

• 产品上线的进度延误，整个团队很难正常交付新版本。
• 产品上线后问题很多，影响用户的访问。
• 团队的士气很差。

最近又发生了运维团队与开发团队之间的配合不好的问题，影响及原因如下：

1. 新产品上线延误了两个星期，正常情况下一天就可以上线。原因是开发考虑不周，测试环境中没有发现，到上线前才发现部署到多台机器上后，按开发原先计划的方式多台机器无法协作完成任务。还有就是在设计阶段没有考虑生产环境的状况，在上线的过程中需要做出对应的代码调整。
2. 上线后质量不稳定，出现多次紧急修复。原因同上。
3. 临时增加硬件投入。新产品中有个组件采用全新的技术方案，跟原来的LAMP体系不兼容，所以需要新增机器，单独部署。
4. 除低了服务可用性标准，并产生了遗留问题。因为临时需要增加硬件，而恰好又只有一台，这样就形成了单点，如果该机器出现故障，服务将全部中断。另外，由于开发前设计上考虑不周，跟别的组件集成时产生别的单点。所以这些降低了服务的可用性，以后还得想办法解决。除此之外，组件采有新的软件，安装、服务起停以及软件配置的管理都是纯手工打造，以后还得找时间纳入到自动配置管理中。
5. 影响了团队士气。在上线过程中开发、测试和运维都觉得不舒服，相互之间产生了抱怨。如果不处理好，会影响以后的配合。

虽然，有些问题确实需要靠某些团队提高自身的人员技能才能解决好，但这些团队能够形成一股合力的话，同样的人员组合肯定会产生更好的效果。

三、过去解决团队配合问题的方法

第一次碰到团队之间的配合问题时，我们还没来得及解决的时候，公司战略调整，整个开发和系统运营团队转给了另一个大部门。但我们在别的地方重新梳理技术团队时，后来又没有出现这种问题，回想起来，我们的做法是：

• 部分开发人员有生产环境中服务器的帐号，可以观察代码的运转情况，少数核心开发人员还有sudo权限，当然他们也不会随便修改服务器的设置
• 开发时一开始就会跟系统运维团队沟通，在代码中增加数据收集的接口和监控接口，这样上线后，很容易收集产品的性能数据，并能方便地对运行状态进行监控与报警
• 生产环境中也有沙箱与beta环境，这样大的版本从测试中过渡到生产环境前，先在沙箱环境中适应一段时间，这样能相对平稳过渡到生产环境
• 部分开发人员临时转到系统运维团队工作一到二个季度，跟系统运维同事一起上线产品，解决产品在运行中发生的问题，这样更好地了解代码如何在生产环境中运行，回去之后能更好地运维同事沟通，开发出来的代码更容易在生产环境中运行

这样，不同团队之间虽然有职责上的明确分工，但在中间的配合的部分做了不少柔性处理。另外，开发、运维与测试等团队中的核心人员之间本身就有认同感，大家一开始的目标就是奔着公司能成功来的，这是没有出配合问题的根本原因。这一点其实跟DevOps的核心点类似，既然如此，何不重新审视一下DevOps，并参考着解决团队之间的配合问题呢。

四、DevOps

DevOps是2010年从欧洲传过来的概念，最先是由一群有着跨学科技能的工程师提出来的，为了解决下面的问题：

• 推出新功能和解决老问题的周期过长
• 新产品或新版本上线充满风险，代码能否在生产环境中稳定运行，没有人有信心，只能艰难地推上去，再看是不是有问题
• 不同团队相互隔离，配合差。如开发人员收到问题后，第一反应是“在我的机器上工作得好好的呀”

我认为DevOps的核心是不管你是开发者、测试人员、管理者、DBA、网络工程师还是系统管理员，大家都是一起的，只有一起努力给客户提供稳定而高质量的软件服务，实现公司的商业利益才会有别的，包括自己的工作机会。

所以，DevOps实际是给各个团队之间搭桥，让他们不仅仅是依靠上线申请单这样的鸿雁传书工具进行沟通，而且经常离开自己的孤岛，走到别人的岛上去，了解别人，并提供自己的想法，帮助对方。

DevOps更象是一种运动，每家公司都需要根椐自身的特点进行借鉴，推动团队之间的协作与合作。需要在三个方面努力：

1. 人员

一方面对现有人员进行培训，鼓励他们了解别的团队的工作、面临的挑战等，让他们用自己的特长去审视和帮助别的团队，另一方面也想办法招一些全面的技术人才，在不同团队之间搭出一些适用的桥来。

2. 流程

在研发的前期，让系统运维同事参与起来，一起搭建测试环境，验证想法，或者也可以在一些项目团队中直接配有系统、开发和测试以及产品人员，一起为产品的上线努力。出现问题的时候，一起想方法找到问题的真正根源，避免相互推托，将解决方案落实在以后的研发过程中。从绩效考核流程上也需要考虑协作因素。

3. 工具

说实在的，大家针对DevOps在工具方面其实讨论得更多，这里面跟敏捷有些类似之处。快速的系统部署和自动化产品代码发布方面的工具显得尤为重要了。

为了避免校弯过正，走向另一个极端，也需要避免下面的对DevOps的常见误解：

1. DevOps意味着要给开发者root权限

可以给开发者加sudo权限，运行指定的命令，比如重启web服务。让开发者更多地了解生产环境和产品的运行状况，但并不意味着让开发者象管理员一样的去管理机器。

2. 所有系统管理员需要写代码，所有开发者需要上架机器

在系统管理和开发者各个领域仍然需要各自的专家，如存储、网络、安装、javascript等专门的人才，DevOps并不意味着让大家不做自己专长的事情。

3. 你一定要用某个工具，不然就不是DevOps

一些技术和自动化的工具对推动各个团队之间协作很有帮助，但是还是需要聚焦于要解决的问题，根椐问题和组织的特点选择合适的工具。

4. 我们需要招聘DevOps

DevOps不是一个新的岗位

五、结合DevOps，解决团队配合问题

管理人员关注团队之间的沟通机制及氛围：

• 以新版能在生产环境中可靠稳定运行为目标，形成协作的氛围。
• 在项目的早期，立项之间，运维、开发与测试就进行沟通，可能的话坐在一起，面对面沟通。
• 在项目上线前，除了测试功能，还要关注部署、备份、监控、安全以及配置管理，在早期发现的问题越多，越能尽少后期的问题并避免影响用户体验。
• 建立各个团队的核心成员定期沟通机制。
• 团队之间的协作纳入绩效考核过程中去。

让开发人员了解运维工作、关注点及挑战，并从开发视角帮助运维：

• 开发人员参与运维团队的内部培训，了解线上的系统。
• 了解运维如何定位并解决故障、如何监控系统的运转情况等。
• 少数开发人员可以跟运维一样发版本到生产环境中，让开发人员关注并了解自己代码的运行情况。
• 从运维的视角修改代码，方便运维人员进行日常的变更与调整，监控与报警。
• 帮助运维人员修改puppet配置模板。
• 帮助运维人员编写与修改产品的发布脚本，提高自动化水平。

让运维人员了解开发过程的关注点及挑战，并从运维角度改善开发过程：

• 运维为开发在公司搭建基于虚拟机的测试环境，虚拟机的安装、配置管理以及代码的发布采用跟生产环境一样的方式。
• 开发人员与测试人员象运维一样发布版本到测试环境中。
• 鼓励开发与测试人员修改puppet配置与模板，管理自己的虚拟机。
• 在生产环境中建立了beta环境，开发人员可以直接发版本上去，让代码在最终上线前多一层缓冲。
• 运维去了解代码的模块结构，从运维的角度修改代码，让产品上线后更方便运维与适应生产环境的特点。
• 运维参与到持续的集成测试中，用自己的自动化知识帮助实现自动的集成测试等。

文章了来自：http://www.infoq.com/cn/articles/lxh-teamwork-devops

被问的时候，可能项目才定下来，仅仅知道大概的功能模块，非功能性需求还模糊不清，甚至团队成员都没到位。但是上级、销售、客户急切地要知道，这个项目什么时候才能完成？

被问的时候，也可能项目已临近结束，或者说临近当初计划的交付日期。然而待完成的功能还有一堆，测试出来的bug有一大堆，客户又提出了新的需求，团队正有人要离职 …。但是上级、销售、客户非常急切地要知道，这个项目到底什么时候才能完成？

这还不算糟糕。更头疼的问题是：“再有三周，项目应该完成了吧？”

因为后者根本不是问题，而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目；或者说明在三周内，能够完成什么。

我们都用过MS Project， 但是那上面的漂亮表格对这样的困境毫无帮助。相反，正是Project 中的甘特图和日程表，埋下了陷阱。因为，在Project 中无法预估需要多少工作日才能完成模糊不清的需求，也无法体现实际情况发生变化后对进度的影响。

当我们讨论进度的时候，其实包含了两个未知的变量。第一是完成需求所要的工作量，包括需求定义、开发内容边界；第二是团队的工作能力，包括成员的行业知识专业技能，成员之间、成员和外部的沟通能力，等等。

关键就在于，这两项都是变量。如果任务是搬一千块砖头，每分钟每人能搬10块，那么结果是显而易见的。

在敏捷开发中，采用相对估算和迭代求精的方法来处理项目进度的问题。

首先是工作量。用估算代码行数或者界面元素的方式，就像论斤卖书一样，只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮，而是可靠易用的功能。

在敏捷开发方式中，先由用户和设计人员粗略估计各个功能模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是10分，那么查询模块可能是15分，而修改为20分。

下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要10人天，从而得出单位分值对应的人天为1；那么，整个项目就需要45人天。

这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有偏差？没关系。接下来通过迭代来求精。先来实现显示模块，如果事实上花费了12人天，那么根据比例关系，剩余内容的估算大约就是42人天。

当然，比例关系也不是一成不变的。随着模块的逐个完成，项目经理对项目的认识也在加深，他可以再调整剩余模块的相对分值。

在实际操作中，项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分，再选择分值最小的模块开始开发。统计总工作量时，按比例累加其他模块的工作量，并加一定的调整系数，因为模块的复杂度不是线性增长的。每次迭代开发完成后，逐步降低调整系数。通常4~5次迭代后，可以将调整系数归零。

在上面的例子中，第一次估算的初步结果是45人天，因为完全是凭经验，因此要给较大的调整系数，比如说0.4，因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见，项目经理上报的工作量为70人天。

第二次估算，剩余内容的初步估算为42，调整系数下降为0.3，因此给出估算区间为30到50人天之间。依此类推，通过不断迭代，对剩余工作量的估算将越来越精确。

这样估算的好处在哪里？

首先，工作量变量的很大一部分因素，存在于非功能需求，例如界面的美观程度。而同一项目的不同模块之间，非功能需求往往是一致的，相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然，随着项目的进展，成员的开发能力应该有一定的上升，但随着加班出差等因素，投入程度也可能下降，因而会相互抵消。总之在周期6个月以内的项目中，很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。

其次，迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的，但只要团队稳定，没有大的需求变动，估算范围将迅速收缩。这比一次性报数更准确。

它的额外好处是，敏捷开发是遵循优先级的，即使对剩余时间（即低优先级模块的开发时间）的估算不十分准确，影响也不是非常大。

对比一下甘特图方式，在开发初期就要把各个模块的开发时间估算出来以统计总量，这就是瀑布开发的模式。

进度问题的另一方面，是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后，项目经理如何做到心中有数，估算任务实际完成时间。

敏捷开发过程中，由开发人员自己来估算完成该任务所需要的时间。当然，每个人的能力不同；每个人的心态也不同，有的人保守，有的人乐观。没关系，还是靠迭代来逐步求精。

在每天的例会上，开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间，敏捷方式只关心这项任务还需要多少时间去完成，直到归零，然后再来统计实际的工作时间。

为什么？因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同，也许昨天用了8个小时没有一点进展，今天一旦想通了就事半功倍。我们真正关心的，就是到底还需要多少时间来完成任务，而不是已经花费掉不可恢复的时间成本。

在每天例会中，项目经理需要注意时间曲线保持水平的成员，他是不是遇到瓶颈了，是否需求帮助？也要留意时间曲线下降幅度过大的成员，他发现了什么好的办法，有没有低估需求？这样，项目经理会更面向结果，只要按计划保证质量完成任务就行，成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容，第一是因繁琐而失真。其次，一旦上级发现某人工作时间不够（即便他完成了任务），忍不住会派新任务，从而造成越干活越多，反过来打击程序员的积极性。

敏捷估算的关键之处，是把成员能力这个变量的估算，交给最合适的人去做，即程序员本人。然后通过比较历次迭代时的预估和实际时间，给出校正系数，以避免程序员过于保守或过于乐观。这肯定不是绝对准确的，但效果往往比项目经理自己拍脑袋估算，然后强行指定deadline 要好得多。

在敏捷开发中，做计划比计划本身更重要。项目经理需要时刻向前考虑，考虑各种动态因素，而不是死报着计划本身。在进度估算的时候，项目经理应该在不同阶段，根据实际情况，给出合乎情理的回答。

完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如 1.0.0。

版本号升级原则：

主版本号：功能模块有大的变动，比如增加多个模块或者整体架构发生变化。

次版本号：和主版本相对而言，次版本号的升级对应的只是局部的变动。但该局部的变动造成了程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。

修订版本号：局部的变动，主要是局部函数的功能改进，或者bug的修正，或者功能的扩充。

*****************************************************************************************

各种软件的版本号是怎么确定的，怎样的跨越才能算是由bate到正式版？

原则上，自第一个稳定版本发布后，修订版本号会经常性改动，而次版本号则依情况作改动，主版本号改动的频率很低，除非有大的重构或功能改进。对于小项目而言，甚至可以简化为：>.<次版本号>.<修订版本号>。

版本号比较自由，至于Beta版或者是正式版跟版本号之间并没有任何关系，只要达到正式版的要求的话，即使版本号是1.0或者0.1都可能是正式版的。

* Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。

* Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。

* RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。

* Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。

2. 版本命名规范

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

3. 版本号定修改规则

* 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

* 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

* 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

* 日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

* 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

*******************************************************************************************

软件版本号

IMEI 号和软件版本号

软件名称后面经常有一些英文和数字，如：QQ 2007 Beta，这些都是软件的版本标志，通过它，我们可以对软件的类型有所了解。版本控制比较普遍的 3 种命名格式 :GNU 风格的版本号命名格式、Windows 风格的版本号命名格式、.Net Framework 风格的版本号命名格式。

α版

　　此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug较多，普通用户最好不要安装。

β（beta）版

　　该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。

γ版

　　该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。

RC版:软件正式发布的候选版本

　　Release Candidatem,含义是"发布候选版"，它不是最终的版本，而是最终版(RTM=Release To Manufacture)之前的最后一个版本。广义上对测试有三个传统的称呼：alpha、beta、gamma，用来标识测试的阶段和范围。alpha 是指内测，即现在说的CB，指开发团队内部测试的版本或者有限用户体验测试版本。beta 是指公测，即针对所有用户公开的测试版本。然后做过一些修改，成为正式发布的候选版本时叫做gamma，现在叫做RC（Release Candidate）。

trial（试用版）

　　试用版软件在最近的几年里颇为流行，主要是得益于互联网的迅速发展。该版本软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。有些试用版软件还在功能上做了一定的限制。

unregistered（未注册版）

　　未注册版与试用版极其类似，只是未注册版通常没有时间限制，在功能上相对于正式版做了一定的限制，例如绝大多数网络电话软件的注册版和未注册版，两者之间在通话质量上有很大差距。还有些虽然在使用上与正式版毫无二致，但是动不动就会弹出一个恼人的消息框来提醒你注册，如看图软件acdsee、智能陈桥汉字输入软件等。

demo版

　　也称为演示版，在非正式版软件中，该版本的知名度最大。demo版仅仅集成了正式版中的几个功能，颇有点像unregistered。不同的是，demo版一般不能通过升级或注册的方法变为正式版。

　　以上是软件正式版本推出之前的几个版本，α、β、γ可以称为测试版，大凡成熟软件总会有多个测试版，如windows 98的β版，前前后后将近有10个。这么多的测试版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量减少了软件中的bug。而trial、unregistered、demo有时统称为演示版，这一类版本的广告色彩较浓，颇有点先尝后买的味道，对于普通用户而言自然是可以免费尝鲜了。

　　不同类型的软件的正式版本通常也有区别。

release

　　该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，对于用户而言，购买该版本的软件绝对不会错。该版本有时也称为标准版。一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号?，如windows nt? 4.0、ms-dos? 6.22等。

registered

　　很显然，该版本是与unregistered相对的注册版。注册版、release和下面所讲的standard版一样，都是软件的正式版本，只是注册版软件的前身有很大一部分是从网上下载的。

standard

　　这是最常见的标准版，不论是什么软件，标准版一定存在。标准版中包含了该软件的基本组件及一些常用功能，可以满足一般用户的需求。其价格相对高一级版本而言还是“平易近人”的。

deluxe

　　顾名思义即为“豪华版”。豪华版通常是相对于标准版而言的，主要区别是多了几项功能，价格当然会高出一大块，不推荐一般用户购买。此版本通常是为那些追求“完美”的专业用户所准备的。

reference

　　该版本型号常见于百科全书中，比较有名的是微软的encarta系列。reference是最高级别，其包含的主题、图像、影片剪辑等相对于standard和deluxe版均有大幅增加，容量由一张光盘猛增至三张光盘，并且加入了很强的交互功能，当然价格也不菲。可以这么说，这一版本的百科全书才能算是真正的百科全书，也是发烧友们收藏的首选。

professional（专业版）

　　专业版是针对某些特定的开发工具软件而言的。专业版中有许多内容是标准版中所没有的，这些内容对于一个专业的软件开发人员来说是极为重要的。如微软的visual foxpro标准版并不具备编译成可执行文件的功能，这对于一个完整的开发项目而言显然是无法忍受的，若客户机上没有foxpro将不能使用。如果用专业版就没有这个问题了。

enterprise（企业版）

　　企业版是开发类软件中的极品（相当于百科全书中的reference版）。拥有一套这种版本的软件可以毫无障碍地开发任何级别的应用软件。如著名的visual c++的企业版相对于专业版来说增加了几个附加的特性，如sql调试、扩展的存储过程向导、支持as/400对ole db的访问等。而这一版本的价格也是普通用户无法接受的。如微软的visual studios 6.0 enterprise中文版的价格为23000元。

其他版本

　　除了以上介绍的一些版本外，还有一些专有版本名称。

　　update（升级版）

　　升级版的软件是不能独立使用的，该版本的软件在安装过程中会搜索原有的正式版，如果不存在，则拒绝执行下一步。如microsoft office 2000升级版、windows 9x升级版等等。

　　oem版

　　oem版通常是捆绑在硬件中而不单独销售的版本。将自己的产品交给别的公司去卖，保留自己的著作权，双方互惠互利，一举两得。

　　单机（网络）版

　　网络版在功能、结构上远比单机版复杂，如果留心一下软件的报价，你就会发现某些软件单机版和网络版的价格相差非常大，有些网络版甚至多一个客户端口就要加不少钱。

　　普及版

　　该版本有时也会被称为共享版，其特点是价格便宜（有些甚至完全免费）、功能单一、针对性强（当然也有占领市场、打击盗版等因素）。与试用版不同的是，该版本的软件一般不会有时间上的限制。当然，如果用户想升级，最好还是去购买正式版。

准备做一个产品，首先要了解用户的希望和要求，这也就是所谓的‘用户调研’所要做的工作。需求分析人员就是要从客户的角度出发，在理解客户的要求的基础上，将之转变成一种程序人员识别的文档。下边说一下用户调研需要注意的几点：

首先，要选好调研对象。调研对象的选择要有代表性，最好能选某个区域里的典型行业，具有行业特色，这样才不会片面，至于客户的选择，可以找当地的代理商进行了解后再确定，或是通过市场调研过滤后进行选择。

其次，要深刻挖掘用户需求。在找好调研对象后，要对其行业背景进行了解，然后根据需要制定调研计划，最好能写一个比较细致的调研目标，这样去了才会有的放矢，不至于太盲目。可以针对客户的行业特色，引导用户说出尽量多的业务场景，并做好记录；另外还要收集一些用户的业务数据及资料，带回以备研究。

再次，要有一定量的客户调研，避免片面性。在做一个产品要尽量多的了解客户实际需求，为了避免片面性，同一行业最好多找几家；针对不同区域，客户需求可能不同，对于做产品，要满足大部分客户需求，就要找不同区域进行调研，这样产品才会相对全面，市场覆盖率才会广。

刚说的是做产品之前调研很重要，但在需求分析阶段，也可以有针对性去调研，针对某个问题或某些问题，找相关领域客户进行详细了解，这样分析出来的需求会更接近用户的真实要求。

调研完成之后，在理解用户真正需求的基础上，就要将调研内容形成报告，以备对其进行详细分析，转化为程序员可阅读性文档（业务需求文档），由于各公司风格不同，可能要求会不同，不论哪种，只要写出来后续环节的人员可以看懂即可。另外在此想提一下的是，由于产品划分模块的不同，可能会有一些公共的东东，这些东东最好是先出具，然后再出各业务需求，这样不至于重复劳动，也会为后期的变更打下好的基础，减少变更量。另外在做产品需求分析过程中，还要‘取长补短’，顾名思义就是要学习友商产品的长处。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/aiunong/archive/2009/03/26/4028121.aspx

   软件项目一般来说可以分成两种：

A.     客户定制系统

B.     研发产品化系统

目前，国内绝大多数的都是在做A类型的客户定制系统，从接客户的单，到做客户的需求，拿到客户的合同，做开发，做实施，做后期维护之类的工作。

另外一种B类的，做产品研发的工作，国内涉及的人不多，而且它的项目估算里面涉及的问题很多，这里就不展开谈了。

做一个正常的软件项目，作为经营者和管理者，都想清楚地知道，这个软件项目有多大，要花掉多少成本，我能拿到的利润有多少，所以能不能准确地估算出软件项目的规模就显得很重要的。

下面我们来剖析一个小小的软件项目的规模估算。

[项目的需求文档]

   假设现在，我们接到了一个项目，项目的名称是×××会员综合管理平台，决定采取传统的B/S架构来设计，我们首先要干的事情就是具体的分析这个项目的需求文档，只有在熟悉需求的情况下才能知道整体的规模。

   具体的需求文档参见：

附件---系统的需求文档
 

[项目规模的概算]

   我们大家都知道，正常的软件开发模式，比如瀑布开发模式的话，会分成

A.     需求分析

B.     基本设计

C.     详细设计

D.     Codeing

E.     UT

F.      CT

G.     RT

H.    后期维护

这么多阶段和步骤。但是根据，我所了解到的，国内除了少部分对日的大型公司会严格按照这种流程来做事情之外，绝大多数的国内公司还是随着自己的性子来。其中不乏，东软，联创之类的著名企业。所以我在制定项目概算的时候，还是按照国内的开发步骤来做：

大项目
 中项目
 小项目
 人日
 
系统设计
 数据库设计(大概10张表左右)
 ------
 6
 
系统结构设计
 ------
 6
 
画面demo
 ------
 10
 
系统开发框架搭建
 ------
 3
 
开发作业
 会员管理子模块
 会员开卡画面
 1.5
 
会员开卡确认画面
 0.5
 
会员信息检索画面
 1
 
会员信息修改画面
 1
 
会员休息修改确认画面
 0.5
 
批量生成卡号
 1
 
会员积分输入和修改
 2
 
会员卡延期画面
 2
 
会员卡挂失画面
 2
 
商品管理子模块
 商品录入画面
 1
 
商品录入确认画面
 0.5
 
商品检索画面
 1
 
商品信息维护画面
 1
 
库存管理
 库存检索画面
 1
 
库存新建画面
 1
 
库存修改画面
 1
 
库存信息确认画面
 0.5
 
～省略～
 
测试作业
 测试数据和计划的准备
 ------
 3
 
分模块测试
 分画面测试
 ～省略～
 
后期维护
 系统上线安装
 硬件安装，布线
 1
 
环境安装，项目部署
 1
 
简单的客户培训
 3
 
维护
 日常数据的维护
 4
 
BUG的修正
 5
 
总计
 大约7人月以上
 
           

 [结论]

软件公司在算钱的时候有几种方法：

A.       国内的比如联创之类，用项目分段方法收钱，做到哪一个阶段，或者完成了一个模板的上线就算前

B.       外包公司一般采用一个人月多少钱来收钱，比如对日外包一般是1万～2万一个人月。

对于老板而言，他要计算出项目的成本，也要这样算，比如以下：

（总人月：7人月）
 项目成本
 对客户收费
 
总价
 7万(市价：1万/人月)
 >=8万
 

# 为什么项目成本里面，一个人月会有1万呢

  因为如果我们假设项目的成员构成如下：

  职位
 月工资
 
PM
 60,00
 
SE
 45,00
 
PG(5人)
 25,00×6
 
公司日常运营费用(包括文职人员，会计，场地租金，旅游福利，公司上层的工资，电脑设备，和客户打交道的关系费-----)
 500,00
 

于是我们就能得到：

月开销合计
 75,500
 
平均一个人月
 10,786
 

# 为什么项目最后的售价一定会大于8万呢

在今天的IT市场上，一般来说作客户定制系统的公司，利润率只有10%～20%，厉害一点的比如联创，日恒一般也就15%。

 特别是现在每年5%的通货膨胀率，如果一个企业不拿到10%以上的利润，那这个公司一定会完蛋。

 所以，7万×(最起码的利润率)10%>=8万。

 证明完毕

-----以上------

以下软件管理相关文章，欢迎大家访问

========================================================

《对日外包项目 管理十日谈》

http://blog.csdn.net/nanjingjiangbiao/archive/2010/01/31/5274307.aspx

《对日外包项目管理十日谈 之 第一日 接活》

http://blog.csdn.net/nanjingjiangbiao/archive/2010/03/10/5364523.aspx

========================================================

【附件---系统的需求文档】

系统需求：

模块名
 处理机能
 机能详细
 
会员管理子模块
 会员卡类型管理：分为储值型返现型、计次型、普通型。
 储值型返现型属于预付费型会员卡，例如充100实到帐120。

计次型属于预付费型会员卡，例如500块/20次。

普通型分为两种：一种属于预付费型会员卡，在开卡之际需要充入一定的现金；还有一种仅是用于代表用户拥有某个商户的会员身份，仅用于积分或打折使用。

每种卡类型都有相对应的积分与消费折扣率。
 
会员卡管理：包括会员开卡、会员信息维护、批量生成卡号等功能。

 
 会员开卡：会员首次办理会员卡时需录入会员的信息并生成相应的卡信息与会员信息对应。

会员信息维护：会员信息的查询，会员卡、会员身份信息的修改。

批量生成卡号：可以事先生成一批卡号，当用户需办理卡时，直接录入即可。无论是单独生成还是批量生成卡号，都需屏蔽不吉利的号码。

 
 
充值管理：有储值的会员卡在金额消费完毕后，需进行续费，若未续费，则会员卡暂不可用。

 
 储值型返现型、计次型为开卡前一次性充值。使用完毕即结束，再次充值时，所充金额按卡类型的限止进行充值。

普通消费型：可充入金额不等，具体金额由商家自行确定。

 
 
会员积分

 
 会员积分是一个可以灵活配置的功能。例如开卡送多少积分，不同类型的会员卡在消费时增加多少积分，在兑换礼品时减少多少积分等等。
 
会员卡延期
 无论是哪种类型的会员卡，在建卡之初都会设置相应的结束时间，在结束时间到来时，若尚有余额未使用，用户可以申请延期，延期具体时间由商家自行决定。
 
会员卡挂失：用户在无意中丢失卡片后可以向办理卡片时的商户申请挂失。

 
 挂失：用户凭办理时输入的密码与证件进行挂失。

取挂：用户若找到了丢失的卡片，可以取消挂失。

补卡：用户在挂失一段时间后，可以申请补卡。补卡时用户的会员卡号有可能会变，但会员卡编号是唯一的，不可变的。
 
商品管理子模块

 
 商品类别管理：商家为自己的商品创建相应的类别。商品的类别分为真实商品与虚拟商品两种。
 真实商品是现实中存在的商品，例如：香烟、酒、饮料等。

虚拟商品为空间或时间上的概念。
 
真实商品管理：

 
 商品信息录入：各商家自行录入商品信息。

商品信息维护：包括商品信息的查询、修改、删除等功能。
 
虚拟商品管理：

 
 商品管理：例如某个球场。3小时/100元。某种服务，100元/1次。
 
库存管理

 
 库房管理
 创建、维护、查询、删除本商家的库房信息。

 
 
供应商管理
 创建、维护供应商信息。供应商名称，电话，具体联系人，销售产品等。
 
入库管理
 新进商品的入库操作。商品的名称，数量，对应的供应商，存储的库房，保持期，最低库存告警点等。

 
 
出库管理
 商品销售过程中，系统会对商品的数量进行自动的减少。
 
库存告警
 当某种商品库存量低于设定的水平时，给予明确的告警。
 
消费管理子模块

 
 预订管理
 用户以电话的形式联系商家,并预订下到达的时间和所消费的服务。商家通过系统创建预订单，预订单中包含用户的联系信息或会员卡号、计划消费的服务、使用的场地等信息。
 
消费单生成
 用户来到商家消费后，若是事先有预定则此时转化为相应的消费单，若是当场消费，则现场生成消费单。消费单中保存了用户在商户的一切消费行为，当最终进行费用结算时，若用户是会员则可将消费单与会员卡对接。

 
 
添加真实商品
 为已正式生成的消费单添加商品，包括商品的数量，单价，消费时间等。

 
 
增加虚拟商品
 为已正式生成的消费单添加虚拟的商品，虚拟的商品不同于真实商品，未必以数量为单位，可能是以时间或次数为单位。系统会详细记录会员消费的起始时间或次数，到会员结帐时自动根据记录计算出结果。

 
 
费用结算管理
 系统会根据各商户所生成的消费单上的内容进行结算。这包括真实商品的数量与单价的乘积，虚拟商品所用时间或次数的计算结果，或者是二者之和。在计算出结果后，若用户持有会员卡，系统会根据会员卡的类型、商品的类型等进行打折、积分。
 
联合结帐
 在上面结帐管理的基础上，可以将不同的消费单关联，并设置其中一张消费单为主结算单进行费用结算。
 
商家自助管理子模块

 
 商家信息管理
 对商家自身信息的管理、维护。商家充值功能。

 
 
员工管理
 新建、维护员工。包括员工登陆系统的帐号，初始密码，有效期等。

 
 
员工销售情况统计
 查看每个店内员工的商品或服务销售情况，可以借此衡量员工的业绩。

 
 
员工操作日志
 查看每个店内员工的操作行为记录。

 
 
交班管理
 员工与员工之间交班时的一种操作，主要是对上一班员工的各类数据的一个总结，新一班员工数据的重新开始录入。
 
提醒管理
 分为两种提醒，一种是程序控制的提醒，在某些点上加入，到达限定条件即提醒(待议)；一种是可配置的提醒，如，某年某月某日要做些什么。
 
短信群发申请
 商家编辑短信的内容提交至管理员处统一发送。

 
 
邮件群发管理
 可以从数据库中随机掏出指定人数用户向其发送邮件。

 
 
公告管理
 针对店内员工的公告信息
 
计量单位管理
 每个商家可以添加属于自己的计量单位，例如：个，次。这种仅限于页面展示，与价格换算无关联。
 
密码修改
 对登陆系统密码的修改
 
统计报表
 待定
 
系统管理

 
 角色权限管理
 平台中有众多商家，他们所包含的员工都有相应的角色，不同的角色所看见的功能不一样，角色由管理员统一创建。
 
商家管理
 所有商家皆由此添加，在有效期到来之前，商家均可正常登陆系统进行操作。
 
地市信息管理
 系统初始数据，一般不做变更，主要包含江苏省13个地市的信息。
 
提醒管理
 分为两种提醒，一种是程序控制的提醒，在某些点上加入，到达限定条件即提醒(待议)；一种是可配置的提醒，如，某年某月某日要做些什么。
 
短信群发管理
 可以从数据库中随机取出指定人数用户向其发送短信。审批后,因按短信的条数扣除从商家的帐户上扣除一定的金额,若金额不够则不能审批。
 
邮件群发管理
 可以从数据库中随机掏出指定人数用户向其发送邮件
 
公告管理
 向所有的商家发布公告信息
 
密码修改
 对登陆系统密码的修改
 
统计报表
 待定
 

本文来自CSDN博客：http://blog.csdn.net/nanjingjiangbiao/archive/2010/03/04/5346859.aspx

    本文档反映的是SpringSide 团队的编码规范，同时推荐所有使用SpringSide框架的开发人员遵循。

    本文档基本遵循Sun's Coding Conventions，补充了其中没有说明或者有所改动的地方。

版权声明   

    本规范由springside团队维护，相关评论与意见请发至springside@gmail.com，转载请注明出处。

规范等级说明

• 级别I:   默认级别，要求所有项目中的所有成员遵守。
• 级别II:  建议所有项目中的所有成员遵守。
• 级别III: 鼓励各个项目根据实际情况执行。

1.格式与命名规范(Formating and Naming Conventions)

1.1  缩进

  使用Tab缩进，而不是空格键--将缩进2，4，8字符的选择权留给阅读者。

1.2 换行

   每行120字符--因为已是1024*768的年代。

   if,for,while语句只有单句时，如果该句可能引起阅读混淆，需要用" {"和"}"括起来，否则可以省略。

//错误，需要使用花括号{}括起来
if (condition)
if(condition) doSomething();
else
doSomething();

1.3 命名规则 

• 不允许使用汉语拼音命名 
• 遇到缩写如XML时，仅首字母大写，即loadXmlDocument()而不是loadXMLDocument()
• Package名必须全部小写，尽量使用单个单词
• Interface名可以是一个名词或形容词(加上'able','ible', or 'er'后缀)，如Runnable，Accessible。
  为了基于接口编程，不采用首字母为I或加上IF后缀的命名方式，如IBookDao,BookDaoIF。
• 页面部件名建议命名为：btnOK、lblName或okBtn、nameLbl。(II)
  其中btn、lbl缩写代表按钮(Button)、标签(Label)。
• 局部变量及输入参数不要与类成员变量同名(get/set方法与构造函数除外)

1.4 声明

• 修饰符应该按照如下顺序排列：public, protected, private, abstract, static, final, transient, volatile, synchronized, native, strictfp。
• 类与接口的声明顺序(可用Eclipse的source->sort members功能自动排列): 
  1. 静态成员变量 / Static Fields
  2. 静态初始化块 / Static Initializers
  3. 成员变量 / Fields
  4. 初始化块 / Initializers
  5. 构造器 / Constructors
  6. 静态成员方法 / Static Methods
  7. 成员方法 / Methods
  8. 重载自Object的方法如toString(), hashCode() 和main方法
  9. 类型(内部类) / Types(Inner Classes)

     同等的类型，按public, protected, private的顺序排列。

2.注释规范(Document Convertions)

2.1 注释类型

2.1.1 JavaDoc注释

  略。

2.1.2 失效代码注释

  由/*...*/界定，标准的C-Style的注释。专用于注释已失效的代码。

/*
 * Comment out the code
 * String s = "hello";
* System.out.println(s);
 */

2.1.3 代码细节注释

  由//界定，专用于注释代码细节，即使有多行注释也仍然使用//，以便与用/**/注释的失效代码分开

  除了私有变量外，不推荐使用行末注释。

class MyClass {
private int myField; // An end-line comment.

public void myMethod {
//a very very long
       //comment.
       if (condition1) {
//condition1 comment
          ...
} else {
//elses condition comment
          ...
}
}
}

2.2 注释的格式

• 注释中的第一个句子要以（英文）句号、问号或者感叹号结束。Javadoc生成工具会将注释中的第一个句子放在方法汇总表和索引中。
• 为了在JavaDoc和IDE中能快速链接跳转到相关联的类与方法，尽量多的使用@see xxx.MyClass，@see xx.MyClass#find(String)。
• Class必须以@author 作者名声明作者，不需要声明@version与@date，由版本管理系统保留此信息。(II)
• 如果注释中有超过一个段落，用<p>分隔。(II)
• 示例代码以<pre></pre>包裹。(II)
• 标识(java keyword, class/method/field/argument名，Constants) 以<code></code>包裹。(II)
• 标识在第一次出现时以{@linkxxx.Myclass}注解以便JavaDoc与IDE中可以链接。(II)

2.3 注释的内容

2.3.1 可精简的注释内容

    注释中的每一个单词都要有其不可缺少的意义，注释里不写"@param name -名字"这样的废话。
    如果该注释是废话，连同标签删掉它，而不是自动生成一堆空的标签，如空的@param name，空的@return。

2.3.2 推荐的注释内容

• 对于API函数如果存在契约，必须写明它的前置条件(precondition)，后置条件(postcondition)，及不变式(invariant)。(II)
• 对于调用复杂的API尽量提供代码示例。(II)
• 对于已知的Bug需要声明。(II)
• 在本函数中抛出的unchecked exception尽量用@throws说明。(II)

2.3.3 Null规约

   如果方法允许Null作为参数，或者允许返回值为Null，必须在JavaDoc中说明。
   如果没有说明，方法的调用者不允许使用Null作为参数，并认为返回值是Null Safe的。

/**
 * 获取对象.
 *
 * @ return the object to found or null if not found.
 */
Object get(Integer id){
...
}

2.3.4 特殊代码注释

• 代码质量不好但能正常运行，或者还没有实现的代码用//TODO: 或 //XXX:声明 
• 存在错误隐患的代码用//FIXME:声明

3.编程规范(Programming Conventions)

3.1基本规范

1. 当面对不可知的调用者时，方法需要对输入参数进行校验，如不符合抛出IllegalArgumentException，建议使用Spring的Assert系列函数。 
2. 隐藏工具类的构造器，确保只有static方法和变量的类不能被构造实例。
3. 变量，参数和返回值定义尽量基于接口而不是具体实现类，如Map map = new HashMap();
4. 代码中不能使用System.out.println()，e.printStackTrace()，必须使用logger打印信息。

3.2 异常处理

1. 重新抛出的异常必须保留原来的异常，即throw new NewException("message", e); 而不能写成throw new NewException("message")。
2. 在所有异常被捕获且没有重新抛出的地方必须写日志。 
3. 如果属于正常异常的空异常处理块必须注释说明原因，否则不允许空的catch块。
4. 框架尽量捕获低级异常，并封装成高级异常重新抛出，隐藏低级异常的细节。(III)

3.3 代码度量

3.3.1 耦合度度量

• DAC度量值不要不大于7 ( III )
  解释：DAC(Data Abstraction Coupling)数据抽象耦合度是描述对象之间的耦合度的一种代码度量。DAC度量值表示一个类中有实例化的其它类的个数。
• CFO度量值不要不大于20 ( III )
  解释：CFO(Class Fan Out)类扇出是描述类之间的耦合度的一种代码度量。CFO度量值表示一个类依赖的其他类的个数。

3.3.2 方法度量

• 方法（构造器）参数在5个以内 ( II )
  太多的方法（构造器）参数影响代码可读性。考虑用值对象代替这些参数或重新设计。
• 方法长度150行以内 ( II )
• CC 度量值不大于10(III )
  解释：CC(CyclomaticComplexity)圈复杂度指一个方法的独立路径的数量，可以用一个方法内if,while,do,for,catch,switch,case,?:语句与&&,||操作符的总个数来度量。
• NPath度量值不大于200 ( III )
  解释：NPath度量值表示一个方法内可能的执行路径的条数。

3.3.3 其他度量

• 布尔表达式中的布尔运算符(&&,||)的个数不超过3个(III) 
• if语句的嵌套层数3层以内(II)
• 文件长度2000行以内(II)
• 匿名内部类20行以内 ( II )
  太长的匿名内部类影响代码可读性，建议重构为命名的（普通）内部类。

3.4 JDK5.0

1. 重载方法必须使用@Override，可避免父类方法改变时导致重载函数失效。
2. 不需要关心的warning信息用@SuppressWarnings("unused"), @SuppressWarnings("unchecked"), @SuppressWarnings("serial") 注释。

4.自动代码检查

   使用Eclipse与 Inellij IDEA的代码校验功能已经排除了很多问题。

   再配合使用Checkstyle，PMD，FindBugs三重检查，总共五层的校验涵盖了Java编码大部分的Guide Line。

   如果要求不苛刻，可以只使用Eclipse或IDEA 搭配 Checkstyle的两重保湿效果。

1. Eclipse：在Windows->Preferences->Java-Compiler->Errors/Warnings中，按本文档将一些原来Ignore的规则打开。
   也可以将springside团队预设在/tools/codereviewer/eclipse.check.prefs的内容拷贝到项目的.setting/org.eclipse.jdt.core.prefs 文件中。
2. IDEA：在Setting->Errors中设定规则，调用Analyzer->Inspece Code进行校验。
3. CheckStyle：安装CheckStyle的Eclipse插件，在Windows->Preferences->CheckStyle导入springside团队预设在/tools/codereviewer/springside_check.xml的规则。
4. PMD：安装PMD的Eclipse插件，Windows->Preferences->PMD清除原来所有规则，导入springside团队预设在/tools/codereviewer/springside_pmd.xml的规则。
5. FindBugs：安装FindBugs的Eclipse插件，在项目属性->FindBugs中，取消下列警告MS/EI/EI2/ ， SnVI/SE/WS/RS ，ST/NP/UwF/SS/UuF|UrF|SIC。

5.参考资料

1. Sun's Coding Conventions Sun MicroSystem；
2. The Elements of Java Style  Scott W. Ambler 等著；
3. 代码检测工具的规则： checkstyle，pmd ，findbugs

   文章来自springside官网

       在官方文档中用例图包含六个元素，分别是：执行者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。但是有些UML的绘图工具多提供了一种直接关联关系(DirectedAssociation)。

        用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，执行者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。

一、执行者（Actor）

       1、执行者概念

    是指用户在系统中扮演的角色。如图1-1是一个用户管理的用例图，图中的用户、管理员就是用例的执行者。

                    图1-1

         2、从业务中找出执行者

    获取系统用例首先要找出系统的执行者。我们可以通过用户回答一些问题的答案来识别执行者。可以参考以下问题：

1. 谁使用系统的主要功能（主要使用者）？
   
2. 谁需要系统支持他们日常工作？
   
3. 谁来维护、管理系统使其正常工作（辅助使用者）？
   
4. 系统需要控制哪些硬件？
   
5. 系统需要其他哪些系统交互？这里包含其他计算机系统或者应用程序。
   
6. 对系统产生结果感兴趣的是哪些人和哪些事物？
   

       3、执行者之间关系

因为执行者是类，所以多个执行者之间可以具有与类相同的关系。在用例图中，使用了泛化关系来描述多个执行者之间的公共行为。如果系统中存在几个执行者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在执行者超类中描述的场合。特殊化的执行者继承了该超类的行为，然后在某些方面扩展了此行为。执行者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。图1-2

                    图1-2

二、用例（Use Case）

         1、用例概念

    用例就是外部可见的系统功能，对系统提供的服务进行描述。

         2、从业务中找出用例

    找出系统的用例，我们从执行者入手，对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例。可以参考以下问题：

1. 执行者要求系统提供哪些功能（执行者需要做什么）？
   
2. 执行者需要读、产生、修改、删除或者存储系统中的信息有哪些类型？
   
3. 执行者必须提醒系统事件有哪些？把这些事件表示成系统用例。
   

         3、用例之间关系

二、用例之间关系

        1、关联关系（Association）

关联关系是连接执行者和用例，表示该执行者代表的外部系统实体与该用例描述的系统需求有关。

图1-3

        2、包含关系（Include）

包含关系是来自于用例的抽象，即从数个不同的Use Case中，分离出公共的部分，而成为可以复用的用例。

图1-4

        3、扩展关系（Extend）

    扩展关系表示某一个用例的对话流程中，可能会根据条件临时插入另外一个用例，而前者称为基础用例后者称为扩展用例。

                图1-5

4、泛化关系（Generalization）

    一个用例可以被特别列举为一个或多个用例，这被称为用例泛化，如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。

继承

指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性；

实现

指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；

依赖

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用；

关联

他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

聚合

聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

组合

组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖；

在谈到架构师的角色时，Hollander指的是“解决方案架构师”或者应用架构师。他不是指企业架构师或者其他的专业人士（专精于特定的领域，例如消息或基础设施）。

Hollander的团队采纳了由4周迭代以及最后的稳定阶段（几天代码冻结的时间）组成的流程，实施了每日站立会议、每日构建与自动化测试的持续集成等实践，并采用了许多角色：

• PjM——项目经理，类似于Scrum Master，确保团队遵循了流程
• PdM——产品经理，也被称为客户或Product Owner，决定产品应该是什么样子
• 架构师——解决方案/应用架构师
• 开发人员——开发团队
• 测试人员——测试团队
• 用户体验设计人员（UX）——用户体验团队
• 发布人员——承担构建和发布的职责，负责维护构建的流程

Hollander针对解决方案架构师如何在敏捷团队中取得成功，提出了最重要的十件事情：

1. “正好足够”的预先设计——除了非常简单的项目，一定时间的预先设计（例如，1到2周）是绝对必要的，其时间长短会取决于应用的类型——网络应用程序、智能客户端（smart client）、移动或批处理，基本的功能需求是什么，是长期的解决方案抑或是折衷的、暂时的方案，都要弄清楚。预先设计的目的是要决定：使用什么技术——例如，ASP.NET或MVC，应用程序是什么类型——2层、3层抑或是面向服务的应用，如何访问数据库——存储过程、实体框架、LINQ、依赖注入（DI）。一篇简短的文档就可以包含所有这些信息以供大家参考。
2. 从垂直分片开始——是指从一小块功能开始（例如登录页面），尽可能地在垂直方向把它切分为很多层，从而把前一阶段所决定的所有技术结合在一起。这将验证设计决策的正确性，而且所有的技术可以一起工作，并且将向开发者展示在开发新代码时可以遵循的模式。如果发现最初的设计决策不当，此时是一个合适的修改时间。
3. 在每次迭代中的Just-in-time设计——在每个4周迭代的中段，项目经理、产品经理和架构师应该聚在一起讨论在下一个迭代中要完成的需求，确保他们每一位都同意这些需求，重要性更高的事情放在了前面处理，而且每个人对一切事情都非常清楚。这些讨论在当前迭代中会以不太明显的方式延续一个星期。接下来的一周，也即当前迭代的最后一周，架构师复审下一次迭代的需求，作出必要的设计决策，以便团队可以在下一个星期基于这些决策开展工作。如果需求与以往相当不同，那么，架构师会开发一些原型，编写一些代码来证明概念，绘制一些图表，然后把所有这些东西集编为5页的文件以供参考。这不是为了制定出有利于开发人员的详细设计方案，而是要确保新的需求满足全局的要求。
4. 信任你的团队...但要跟他们在一起——这关乎架构师与开发人员的关系。架构师需要确保他没有逾越自己的角色，没有独占所有“做决定”的乐趣，使得开发人员的工作变得无聊。与此同时，架构师需要给团队提供指导，解决那些可能会导致开发人员停顿的困难问题。架构师每天都应该与每位开发人员接触，获悉他们在做什么，并且在他们遇上编程问题的时候给予帮助。特别是当开发人员不喜欢寻求帮助，试图花上整整一个礼拜的时间来自行解决问题的时候，这种帮助尤为需要。这种关系也适用于PjM和测试/构建/发布团队。
5. 编写代码！——架构师应该知道代码的质量如何，这样才会对他做出的决定所产生的影响有更好的理解。他也可以整明白何时重构是必须的。 编写代码的架构师在开发团队中有更好的声誉。也就是说，Hollander并不认同（设计和开发）职责的泾渭分明。他还认为，架构师仍然是架构师，他不一定要像普通的开发人员一样擅长于编写代码。
6. 参与一切——架构师参与所有与项目有关的会议：设计、开发、代码评审、需求规划等，这是有好处的，因为他能够以更广阔、更清晰的视角看待正在发生的事情，而且他能够通过告知产品经理其决定的潜在后果，从而帮助他/她避免在早期阶段做出错误的决定。
7. 推动质量文化——一个成功的团队，一个人人都想成为其中一分子的团队，是建立在质量文化之上的：没有人偷工减料；没有人提交拙劣代码；如果设计中有一个重大的缺陷，它绝不会不知不觉地混过关；所有人都是诚实和开放的，寻求整个团队达到最佳的结果。Hollander承认，建立这样一个团队很难，但并非不可能。首先，架构师应该在一开始就创建一些规则，这些规则不会因为开发人员不喜欢就随着时间而改变。比如决定编写单元测试，再比如在每次提交以前都要进行代码评审，包括由架构师提交的代码。如果评审人员（可以是团队中的任意一位）不认可代码，代码就不能提交。
8. 知道何时需要改变——架构师应该非常灵活，随时准备好在设计需要改变的时候去改变设计。早期的解决方案也许不再适合，抑或是新的需求需要不同的方法。
9. 屏蔽来自外部的随机请求——虽然这通常是项目经理/Scrum master的职责，但架构师可以保护团队不受外部请求的影响，这些影响往往会分散团队的精力和浪费真正工作的时间。举个例子：业务团队可能想要以某种特定的方式完成某些特定的事情，而他们的请求并不全然合理，也并不是必须实现。 
10. 撰写文档...但只有当有人需要阅读它们的时候——Hollander并不提倡记录一切，也不提倡根本不撰写任何文档。他认为有必要取得一个平衡——只编写一定数目真正有帮助的、有人会去阅读的文档。文档在记录详细设计的决定（比如数据模型）方面是很好的载体。迭代的设计决定，虽然它们由整个团队在迭代开始之初讨论得出，但我们仍然建议将它们记录在5页的文档之中，以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开项目、加入其他项目之后，新加入项目工作的人也能借助于这些文档理解某些决定的来龙去脉。 

综上所述，Hollander指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码，而只是其中一小部分，他不去测试或部署这些代码，但他要确保整个流程的顺利进行。
转载自：http://www.infoq.com/cn/news/2010/09/Tips-Architect-Agile-Team

二.需求正确性
需求文档描述的内容，除了要求清晰的，还要保证内容是正确的。我们可以从以下方面进行检查：
1.功能是否正确合理
任何一个需求都不会凭空而降，都有它背后的理由。考虑问题的时候换位思考，运营/pd推出该需求的动机是什么，明白了背景，再去思考需求是否能满足背景要求，是否有损害到真正用户的利益。
2.与现有系统业务是否冲突矛盾
如果需求是和现有的业务紧密联系的，需要对现有业务进行一个梳理，确认新的需求不会和已有的功能是冲突矛盾的，或者与原有的业务意图是背离的。
3.用户对象是否正确
用户对象，会涉及到用户权限的问题，主要是看功能涉众描述是否正确，避免错乱和遗漏。

三.需求完整性
需求完整性包含描述不细致、不完整和缺失。
1.需求不细致
需求文档对一个功能点进行了描述，但是颗粒过于粗糙，细节信息没有被传递。比较常见的是页面元素的处理。比如这样的一个描述说明：点击网点名称，打开网点详细信息。网点详细信息页面需要输出哪些内容是不明确的，面对这样一个需求，开发可以根据自己的理解对信息进行输出，但是可能会与PD的预期有出入。
2.需求不完整
不完整是指需求文档有说明，但是没有给出明确定义说明。比如某个PRD文档中，有文字提及下单模式有预付金下单和非预付金下单，但文档中有详细描述的只有预付金下单，非预付金下单还没有来得露脸就消失了，让读者完全搞不懂这是一种什么样的下单模式。
3.需求缺失
需求缺失则是彻底的遗漏，整个文档都没有出现，又可分为业务规则缺失和功能缺失。要找出需求缺失问题，必须熟读需求文档。
查找业务规则缺失问题，需要有业务基础，对现有的相关业务知识进行学习了解，对需求的背景进行剖析，在明确需求目的前提下，对需求已经提及的业务规则分析，查找是否有遗漏。
查找功能缺失问题，可以通过画系统功能模块框架图和活动图，明确各个功能是否能完整的流转，如果有数据是不能到达终点的，则是存在缺失的功能点。
 
原文地址：http://qa.taobao.com/?p=8781

   

Java项目开发过程中，由于开发人员的经验、Java代码编写习惯，以及缺乏统一的标准和管理流程，往往导致整个项目的代码质量较差，难于维 护，需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。

如图1所示，敏捷开发过程经历需求调研，用例分析和用例分解，进入开发迭代阶段。在每个迭代过程中，可以采用以下步骤来保证和提高整个项目的代 码质量：统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。

图1.敏捷开发中的Java代码质量保证步骤

步骤一：统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性，但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同，这可能是由于不同 的经验习惯或者缺乏编码规范方面的学习造成的。这样一来，其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图，所以制定 并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面：

◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。

◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范

◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。

◆编程规范。例如异常、并发、多线程等方面的处理方式。

◆其他规范。例如日志格式、属性文件格式，返回值和消息格式。

项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定，可供参考的书籍有《Java编程风格》(英文书 名为：TheElementsofJavaStyle)。编码规范要形成文档，而且要简洁明了，并组织项目成员一起学习，确保所有成员正确理解所有条目。

一旦编码规范确定，就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是，点击Eclipse的 Windows->Preference菜单项，在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2)，该项 和它的子项允许您对Java代码的样式进行控制。

图2.Eclipse代码样式设置窗口

例如，为了使用自动格式化工具，可以在Eclipse提供的默认代码格式配置的基础上建立自定义的格式。在Formatter面板中，点击 New，输入新的名字并选择一个默认的配置作为初始化格式，如图3所示。

图3.创建新的代码格式配置

单击OK后就可以在新打开的窗口中进行修改定制自己需要的格式。如图4所示。

图4.创建新的代码格式配置

修改完成后点击Apply保存所作修改。同时可以点击Export将当前的格式定义导出成一个XML文件，这样项目组的其他成员就可以很方便通 过点击图3中的Import按钮来导入该XML文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过Eclipse界面里的Source->Format菜单来对代码进行格式化，从而 使整个项目的代码具有相同的格式。同样可以通过对CodeStyle下的其他项目进行设置来帮助对Java代码的样式进行控制。将所有这些样式文件导出成 XML文件后，同编码规范一起归档，供所有项目成员使用。

步骤二：静态代码分析

在完成源代码的开发以后，下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外，还能利用一些静态分析工具来快速、直接地 提高代码质量。静态代码分析工具并不需要运行代码，可以直接对Java文件和Class文件进行分析，通过一些检查条件的设置，快速找到代码中的错误和潜 在缺陷。现在的静态分析工具很多，有FindBugs、PMD、IBMRationalTool，等等。在这里，选择FindBugs作为静态代码分析工 具。FindBugs可以和日常开发工具Eclipse进行集成，在开发过程中，就可以方便的开始静态代码的检查。通过检查Class文件或者JAR文 件，将字节码和一组缺陷模式进行对比，来发现可能存在的代码问题。在Eclipse的开发环境中，用插件安装的方式安装了Findbugs后，在 Eclipse的配置选项中就会多出来FindBugs的配置选项。可以对自己的项目进行配置，选择需要的Detector检查代码。

图5.FindBugs的配置选项

设置好自己的规则后，在需要检查的代码文件夹上点击右键，就可以启动FindBugs检查。代码可以是一个项目，也可以只是几个文件。

图6.运行FindBugs

检查完毕后，会出现FindBugs视图，把所有检查的结果根据错误分组展示。点击结果里面的每一个错误，会自动打开对应的代码。当根据规则改 正了所有的错误，或者说潜在错误，这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件，也可以是文本文件，便于项目的集成管理 和检查保存。

图7.FindBugs检查结果

步骤三：单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节，在此环节中，设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具 体考虑要对哪些代码单元进行测试，被测单元之间的关系，测试策略，以及单元测试用例设计等，并最终输出《单元测试用例设计》文档，用来指导具体的单元测试 执行。在用例设计中，通过对代码单元输入和期待输出的定义来保证该单元的功能正确性，边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配 方法来衡量用例设计的完整性。

在用例设计完成之后，下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的，用例评审可以借集体之力，对用例设计进入查漏补缺， 进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴，它主要通过对代码的逻辑结构进行分析来设计测试用例，因此，评审员的选择最好以理解代码逻辑 结构为前提，如果评审员来自相关模块，还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中，开发人员自己的代码往往需要和其他的代码模块或系统进行交互，但在测试的过程中，这些需要被调用的真实对象常常很难被实例化，或 者这些对象在某些情况下无法被用来测试，例如，真实对象的行为无法预测，真实对象的行为难以触发，或者真实对象的运行速度很慢。这时候，就需要使用模拟对 象技术(Mock)，利用一个模拟对象来模拟我们的代码所依赖的真实对象，来帮助完成测试，提高测试覆盖率，从而提高代码质量。模拟对象技术利用了在面向 接口的编程中，由于代码直接对接口进行调用，所以代码并不知道引用的是真实对象还是模拟对象，这样就可以顺利的完成对代码的测试，模拟技术有很多种，如 jMock，EasyMock，Mockito，PowerMock等等。其中Mockito消除了对期望行为的需求，避免了这些代码的大量初始化。

图8.Mockito示例

在模拟对象过程中，先模拟一个需要调用的List对象LinkedList，再设定这个对象的行为，当调用get(0)的时候，返 回”first”。这样，测试代码就可以利用这个对象来测试我们的功能代码，需要调用和返回值的时候，可以顺利的得到模拟对象的返回值。也需要对模拟对象 进行错误情况的模拟，保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围，需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路径 覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定，以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进 度。

EMMA是一款比较流行的开源Java测试覆盖率分析工具，支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析，支持将覆盖率分析结 果导出为多种格式的报告，并采用多种颜色来高亮显示不同的覆盖率状态。EclEmma是一款基于EMMA的Eclipse插件，方便在 EclipseIDE中进行测试覆盖率分析。如图9，在测试用例写好后，可以在右键点击测试类，选择CoverageAs->JUnitTest。

图9.运行测试覆盖分析

单元测试跑完后，Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后，可以看到高亮显示的覆盖分析结果，如图10所 示。红色代表测试没有覆盖到该行，黄色表示部分覆盖，绿色的行表示该行在本次测试中被覆盖到。

图10.查看测试覆盖分析结果

在Coverage视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式，例如HTML。

图11.导出测试覆盖分析结果

图12显示了导出的report。

图12.测试覆盖分析报告

为了保证单元测试的有效性和质量，可以规定一个测试覆盖率的下限，例如所有的包和类的覆盖率必须达到80%以上。不过值得注意的是，不要单纯追 求高覆盖率，要同时注意测试用例的质量，如果测试用例本身就写的有错误，那么即使测试覆盖率很高也没有意义。

步骤四：持续集成

持续集成(ContinuousIntegration)是利用一系列的工具，方法和规则，做到快速的构建开发代码，自动的测试化，来提高开发 代码的效率和质量。利用自动构建工具，随时都能把提交的代码构建出来，提供一个可以测试使用的版本，让用户和开发人员同时看到相同的功能，尽早的发现问题 和错误，也可以尽快的得到测试人员和用户的反馈。

要做到持续集成，就要利用一系列工具，把开发过程中的重复工作自动化。搭建自动的构建服务器， 自动的进行单元测试和发布新版本，一个集成的服务器可以提供构建过程的结果报告，自动通知开发人员构建结果，并且保存历史数据。 IBMRationalTeamConcert(RTC)可以提供工作任务的管理，项目计划的安排，代码版本管理控制，自动构建可用版本，生成构建结果报 告。这些过程构成了项目的持续集成过程，其中，版本的自动构建和代码的自动单元测试是持续集成的关键过程，RTC在这些过程上提供了有力的支持。

自动构建

RTC提供了buildengine来负责构建build，首选，启动buildengine，并和RTC服务器建立了连接。再创建项目的 build定义。在这个定义中，需要设定编译哪些模块的代码，需要跳动哪个ANT文件来启动编译，和一些编译过程中的参数的设 定。当这些都准备好了，编译对于项目而言，就变成一个简单的事情。

可以看到，通过在build定义上，点击请求构建，就可以触发一次构建过程。选择需要的构建参数，这个过程就会在后台运行。每一个开发人员，做 了稍许的代码改变和提交，都可以触发新的构建过程，来保证我们代码的有效性。申请一个新的构建的过程如图13、图14所示。

图13.申请一个新的构建

图14.构建申请界面

当构建结束后。RTC服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。

图15.构建结果

整个开发过程中，构建版本的过程应该是无数次的，通过每次构建，都可以得到当时代码的编译情况，并且可以得到一个可运行的软件版本。在构建定义 上，RTC支持设置构建计划。定时自动的触发一次构建。

图16.构建定义

自动单元测试

构建可以自动了，重点提高代码质量的单元测试呢？如果每一天的代码，每一个版本的代码，都已经通过了我们的单元测试，这样我们就能对代码的质量 有了基本的保证。在构建脚本的自动调用过程中，通过ANT的脚本，可以加上JUnit，EMMA，FindBugs的ANT脚本调用，每一次的构建，都可 以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告，RTC不能提供这些报告的展示，就可以利用Hudson这个开源工具，集成测试报告 来方便查阅。

图17.自动测试报告

步骤五：代码评审和重构

代码评审(CodeReview)是Java项目开发过程中的一个重要步骤，代码评审可以帮助发现静态代码分析过程中无法发现的一些问题，例如 代码的编写是否符合编码规范，代码在逻辑上或者功能上是否存在错误，代码在执行效率和性能上是否有需要改进的地方，代码的注释是否完整正确，代码是否存在 冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解项目，促进经验分享，同时也能保证项目成员的良好沟通。代码评审主要包括两种形式，同级 评审(PeerReview)和小组评审(GroupReview)。同级评审主要指项目成员间的互相评审，小组评审是指通过召开评审会议，项目成员一起 对项目代码进行评审。

为了提高代码评审的有效性和效率，可以借助一些外部工具，比较常用的代码评审工具有Jupiter和CodeStriker。Jupiter是 一款开源的Eclipse插件，允许成员将评审意见定位到真实代码的具体行，由于代码评审的结果以XML文件的形式保存，所以可以把结果提交到版本管理服务器进 行共享。图18显示了使用Jupiter进行代码评审的界面。

图18.Jupiter代码评审界面

在代码评审任务创建后，Jupiter将代码评审分成三个阶段，个人评审阶段(IndividualPhase)、团队评审阶段 (TeamPhase)和问题修复阶段(ReworkPhase)。在个人评审阶段，评审成员将发现的代码问题或者缺陷记录下来，每个问题都会作为一个记 录保存在评审表格中。在团队评审阶段，团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性，如果问题确实存在，就将该问题分配给某个成员去解 决，并在Jupiter中将该问题设置成相应的状态。在问题修复阶段，团队成员会修复属于自己的问题，并将相应的记录设置成已解决等正确的状态。

Codestriker是一款基于Web的常用代码评审工具，对代码的评审可以针对某一具体行，也可以针对整个代码文件，评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论，代码作者也可以针对某一具体的评 论回复。Codestriker支持邮件通知，还可以同版本控制服务器进行集成，以跟踪和显示文件内容的改变。图19显示了Codestriker的界 面。

图19.Codestriker报告界面

在实践中对所有代码进行小组评审会比较费时，所以可以根据实际情况来挑选一些核心代码进行小组评审，或者在项目的前期安排较多的小组评审，等项 目组的成员对代码评审的标准和要求有较好的理解，进行代码评审的经验提高后，就可以逐渐减少小组评审的次数，从而达到大部分代码即使只进行同级评审也能保 证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉，较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成，不同项目 成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作，例如整个项目层面的代码组织形式的改变需要由整 个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法，希望大家能从本文得到启发和收益，结合您的实际项目特点，实践以上步骤和方法，并加以完善和改 进，共同打造高效高质量的Java代码，为您的项目成功奠定坚实的基础。