抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
对于大型项目来说化解风险最根本的一条是将大的项目***成为很多个相对独立的部分，而后分别完成每一部分，将风险控制在一定范围内。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS具有4个主要用途：
* WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。
*WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
*WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
*WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被***为WBS，是因为较好的工作***可以：
*防止遗漏项目的可交付成果。
*帮助项目经理关注项目目标和澄清职责。
*建立可视化的项目可交付成果，以便估算工作量和分配工作。
*帮助改进时间、成本和资源估计的准确度。
*帮助项目团队的建立和获得项目人员的承诺。
*为绩效测量和项目控制定义一个基准。
*辅助沟通清晰的工作责任。
*为其他项目计划的制定建立框架。
*帮助分析项目的最初风险。
WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点：
*工作包可以分配给另一位项目经理进行计划和执行。
*工作包可以通过子项目的方式进一步***为子项目的WBS。
*工作包可以在制定项目进度计划时，进一步***为活动。
*工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。
*工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
1. 创建WBS的方法
创建WBS是指将复杂的项目***为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：
（1）使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。
（2）类比方法。参考类似项目的WBS创建新项目的WBS。
（3）自上而下的方法。从项目的目标开始，逐级***项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。
（4）自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。
2．创建WBS的基本要求
（1）某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
（2）WBS中某项任务的内容是其下所有WBS项的总和。
（3）一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
（4）WBS必须与实际工作中的执行方式一致。
（5）应让项目团队成员积极参与创建WBS，以确保WBS的一致性。
（6）每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。
（7）WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。
3．WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。
在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。
4．WBS的***方式
WBS的***可以采用多种方式进行，包括：
（1）按产品的物理结构***。
（2）按产品或项目的功能***。
（3）按照实施过程***。
（4）按照项目的地域分布***。
（5）按照项目的各个目标***。
（6）按部门***。
（7）按职能***。
5．创建WBS的过程
创建WBS的过程非常重要，因为在项目***过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：
（1）得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。
（2）召集有关人员，集体讨论所有主要项目工作，确定项目工作***的方式。
（3）***项目工作。如果有现成的模板，应该尽量利用。
（4）画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
（5）将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。
（6）验证上述***的正确性。如果发现较低层次的项没有必要，则修改组成成分。
（7）如果有必要，建立一个编号系统。
（8）随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。
检验WBS是否定义完全、项目的所有任务是否都被完全***可以参考以下标准：
（9）每个任务的状态和完成情况是可以量化的。
（10）明确定义了每个任务的开始和结束。
（11）每个任务都有一个可交付成果。
（12）工期易于估算且在可接受期限内。
（13）容易估算成本。
（14）各项任务是独立的。
6．WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。
当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作***结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。
WBS、OBS、RBS、职责分配矩阵比较：
WBS 是工作***结构，下面都是工作包，都是成果，不包括具体人员、具体资源信息；
OBS 是组织***结构，里面是部门、单位或团队, 不包括具体工作内容、工作职责，工作职责通常在职责说明书里面；
RBS 是资源***结构，包括人的信息，因为人也是资源，不过不包括工作内容和所属部门。
职责分配矩阵，是把WBS和OBS结合起来，显示工作包和团队成员之间的关系。
7．WBS的实践经验
WBS字典：超大型项目需要，WBS字典有助于追踪所有的概要和详细的活动，包括一个简短的说明、WBS数字标识符（1.1、1.1.1、1.1.2等）和预计的努力。如果你把WBS字典输入到一个专门的工具中，这个工具还有助于追踪WBS的变化。
让最后的详细活动以行动为导向：WBS中的详细活动（不能进一步***的活动）最终会转移到你的进度表中；因此，如果WBS中的详细活动以行动为导向会更加方便。
典型的WBS实践流程：
1. 制定工作产品清单（PL）。
工作产品（Working Product）是项目需要产出的工作结果，可以是项目最终交付成果的组成部分，也可以是项目中间过程的产出结果。以软件开发为例，软件中的用户管理模块是最中软件产品的一部分，软件的需求分析文档是软床过程中的文件，都是软件开发这个项目的工作产品。工作产品有大有小，有的相互关联，有隶属的关系。列出工作产品清单的过程，可以是头脑风暴的方法，项目组共同完成。
2. 制定工作产品***结构（PBS）。
工作产品大大小小列出了很多，大型项目有几百项，几千项。工作这些工作产品的属性和关系，用结构化的方法组织这些工作产品，形成一个自顶向下的逐级细分的工作产品***结构（PBS：Product Breakdown Structure）。这就是制造业内的产品物料表（BOM），说明一个产品有多少个零件组成。
3. 制定工作任务***结构（WBS）。
有了PBS，只要把获得工作产品的任务明确，就可用根据PBS的结构，得到WBS了。注意同样的PBS，可用有不同的WBS，因为获得同样工作产品的任务可以是不同的。例如软件开发中的用户管理模块，是PBS中的工作产品，对于到WBS中，可以是不同的任务，一种是采购一个用户管理模块，另一种可以是项目小组开发一个用户管理模块。
4. 制定组织***结构（OBS）。
WBS中的任务确定了，完成任务的责任人也就可以明确了。因此由WBS则可以形成整个项目的组织***结构，由那些人来完成项目的任务，得到工作产品，并完成项目。
其中的关键是***的结构，PBS、WBS和OBS是同一个结构，只是从不同的角度来阐述这个结构。关于这个结构的***方法，常用的有组件***方法和过程***方法。典型的组件方法就是制造业中把一个完整的产品，逐级***到零件。典型的过程***方法可以是软件开发从需求到设计、编码、测试的一个过程。项目***中，这两种方法往往交替使用，其最终是把项目***到一个个具体和细小的工作任务。
/ 浏览 (0 / 98)
分类:
博客分类：
抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
项目管理是通过利用项目管理知识、技能、工具和技术将输入（资源等）创造出结果，以实现项目目标。
过程组：启动、规划、执行、监控、收尾，和戴明环PDCA类似。
大型项目可以分阶段或子项目进行，每个阶段/子项目都有自己的过程组。
===================================================================
一、启动
1、项目章程：项目目标、初步的项目范围、资源投入、建设和制约因素；项目经理得以任命、权利得以保证；项目章程由Spo or或PMO颁发。（INPUT：合同、项目工作说明书、事业环境、OPA）
2、项目初步范围说明书，这个主要是为验收提供依据，不是必须的；为项目提出粗略定义，包括可交付成果的要求、产品要求、项目边界、验收方法和高层范围控制。
二、规划
识别依赖关系、要求、风险、机会，明确范围、进度和费用（滚动规划）。项目团队应创造利于利害关系者做出贡献的环境。
项目管理计划（计划的计划）和沟通管理计划有自己明确的内容，其他“管理计划”基本为方法论。
项目规划从“制定项目管理计划”开始到出最后的“进度表制定”结束，中间可能涉及20个过程，下面分4大类展开：
1.1、范围规划：范围管理计划（方法论，如何确定、核实和控制项目范围）
1.2、范围定义：范围说明书（产品范围＋项目范围，跨知识域的更新需要走“变更”流程）
1.3、制作WBS：根据可交付成果进行***
2.1、活动定义：可交付成果需要的具体活动
2.2、活动排序：识别活动间的逻辑关系
2.3、活动资源估算：活动需要的资源类型和数量（含设备、人力资源，不含费用）
2.4、活动持续时间估算：活动需要的单位工作时间
2.5、进度表制定：分析活动顺序、持续时间、资源要求及进度制约，形成进度表（甘特图）
3.1、费用估算：估算活动（工作包）所需各种资源的费用
3.2、费用预算：资金计划（汇总费用估算、储备资金、制定费用基准）、形成资金分配表
3.3、质量规划：质量管理计划（方法论：明确方针、设立过程，识别质量标准与项目关系）
3.4、人力资源规划：识别项目角色、责任、报告关系；制定人员配备管理计划
3.5、沟通规划：识别信息、传递信息（利害关系者）
3.6、采购规划：确定采购战略，形成采购管理计划
3.7、发包规划：具体采购战术，形成RFP
4.1、风险管理规划：风险管理计划（方法论、模板）－如何对待、规划和执行项目风险管理活动
4.2、风险识别：风险登记册－识别风险
4.3、定性风险分析：风险分级
4.4、定量风险分析：高优先级的进行货币损失评估
4.5、风险应对规划：增加机会、规避风险的行动方案
三、执行
按计划整合并实施项目活动、协调人与资源、处理项目范围说明书中明确的范围、实施经过批准的变更。
偏差来源：活动持续时间、资源生产率与余缺、未曾料到的风险
偏差影响：偏差分析－变更－项目管理计划－新基准
1、指导与管理项目执行：可交付成果、变更、工作绩效信息
2、实施质量保证：验证过程、树立信心
QA：Quality A urance质量保证：对工序、工艺、方法进行验证，管理有效性的验证
QC：Quality Control质量控制：对成果进行检验、消除未达标原因
3、组建项目团队：将配置的人力资源组成工作团队
4、建设项目团队：改善能力和团队合作、提升绩效
5、信息发布：按流程向利害关系者广播信息
6、询价：价格、方案和供应商反馈
7、卖方选择：开标、商务谈判、合同
四、监控
Monitor：仪表盘，Control：油门＋刹车
观察项目执行、及时发现潜在问题并在必要时进行纠正。
1、监控项目工作：根据项目管理计划和实施基准，识别风险、绩效等
2、整体变更控制：变更、纠正/预防/补救措施
1、范围核实：验收可交付成果
2、范围控制：WBS、范围基准
3、进度控制：进度模型数据、进度基准、活动清单和属性
4、费用控制：对造成偏差的因素施加影响、控制项目预算变更（发现缺陷、消除成因）
5、质量控制
6、项目团队管理：跟踪绩效、解决问题
7、绩效考核：收集和发布绩效信息形成绩效报告，含状态、进展和预测（干的怎么样？花的代价？），是支持监控工作的一种手段
8、利害关系者管理：问题统一出口
9、风险监控：跟踪风险、评估资源、实施应对计划并评价其有效性
10、合同管理：管理合同内容和合作关系
五、收尾
正式结束项目/项目阶段的所有活动，交付完成的成果。
1、 项目收尾：乙方内部关闭项目的全部动作，总结、评估、释放人力资源、交付成果。
2、 合同收尾：关闭与甲方合同关系的动作。
/ 浏览 (0 / 65)
分类:
博客分类：
抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
SOW：Statement of Work工作说明书
SOW通常作为合同的一部分，对提供的产品或服务进行表述。SOW在很高层次上说明项目的用途、范围与途径。实际上，SOW是客户与供应商之间的高层共识，将帮助沿着正确的方向安排策划工作，是WBS的基础。
SOW通常包括：对项目技术的目标与宗旨的描述，必须满足的成本和进度方面的约束，实际存在的资源约束，以及客户与供应商在开始时应该理解的有关假定。
1、范围陈述（系统的目的与范围陈述）
2、约束陈述（包括开发和实施知识管理体系的成本预算、完成的时间、具体质量陈述等）
3、责任陈述（包括知识获取和工具选择的责任问题）
4、要求陈述（比如客户要求）
5、交付使用陈述（比如陈列、培训、文件）；签名（包括项目经理、项目发起人、客户）等
SOW的三个特征：
1、SOW是一份简短的文档。它既不是一份设计文档，也不是一份完整的法律合同。它应该是在高层商抓住要点。SOW的作用是奠定工作范围、开始定义最终产品。
2、保证客户与高层管理者能充分评审并批准SOW，然后才有可能切实地着手进行项目的其他活动。
3、一份SOW获得批准、便应对这份文档进行版本控制，并将它作为项目计划的一部分。
========================================================================
工作说明书（SOW）模板
工作说明书主要包括以下内容
前言、服务范围、方法、假定、服务期限和工作量估计、双方角色和责任、交付资料、完成标准、顾问组人员、收费和付款方式、变更管理等。
1. 前言
对项目背景等信息作简单描述。
2. 项目工作范围
详细描述项目的服务范围，包括业务领域、流程覆盖、系统范围及其他等。
3. 项目工作方法
项目拟使用的主要方法。
4. 假定
项目进行的假定条件，具体内容需双方达成。
5. 工作期限和工作量估计
项目的时间跨度和服务期限，对于按人天计算费用的项目，需评估服务工作人天，并估算项目预算。
6. 双方角色和责任
分为供应商的职责和公司的职责，并对关键角色的工作职责进行描述“如：项目经理”。
7. 交付件
列出项目的主要交付资料，并对交付件的内容与质量要求进行描述。
8. 完成以及验收标准
列出项目的完成标准和阶段完成标准，完成标准作为项目验收的依据内容。
9. 服务人员
请列出供应商的人员名单，及顾问资格信息。供应商人员的变更：描述在什么情况下可进行供应商人员的变更。
10. 聘用条款
对聘用供应商人员的级别要求、经验要求及其他相关条款。
11. 收费和付款方式
项目的付款方式、费用范围、涉税条款等。
12. 变更管理
项目变更的管理过程、相关规定与约束条件等。
13. 承诺
双方承诺均已阅读，理解并同意遵行上述协议书及其条款的约束。而且双方同意，所提到的服务条款及其附件(包括工作说明书和变更授权以及任何为双方协议中独立完整的陈述)，取代所有的建议书或其它在此之前的书面或口头协议以及有关的其他交流。
14. 保密
遵守保密协议（保密条款另行签署）
15. 签署接受
XXXXXXXXXX公司（供应商） xxxxxxxxxxx公司（发包商）
授权签名：_______________ 授权签名：_________________
姓名：_________ 日期：______ 姓名：_________ 日期：______
职位：___________ 职位：___________
/ 浏览 (0 / 119)
分类:
博客分类：
一、简单直接就是生产力，就选 rapid
1. 最佳实践
（1）尽量删除没用的东西
生成器帮你生成的东西有时你是并不需要的,如一张表只有查看,而没有增删改功能,那么你应该将edit.j ,create.j 等无用的东西删除,UserAction.save(),UserAction.edit()等方法也都删除,只保留需要的东西,以保持代码的整洁.避免后来者在这些无用东西上产生不必要的误解而增加维护成本.
（2）一个项目一套生成器模板
* 因为各个项目的UI都有可能是不一样的,而UI模板也可能需要根据不同项目要进行不同的定制,所以你的项目需要自带一套模板.而Dao,Service等模板则可以通用.
* 你可能会有一个自己的脚手架及公共的模板,并且会持续修改.但是由于现在使用生成器的项目已经在开发,当前项目使用的模板很有可能赶不上你自己的公共脚手架中的模板修改.所以项目通常自带一套模板并持续维护.
（3）拒绝重复生成代码的诱惑
本人实践,代码只生成一次,后面全部是手写代码. 初始生成的代码已经可以为你减轻很大的工作量.
* DAO层以上代码重复生成一点意义也没有,只是帮你生成一个骨架(生成的代码与框架结合,已经是十分精简),然后自己再填空编写业务逻辑
* 后台的话可以直接生成UI页面,生成一次以后自己就手工编辑,页面千变成化,只能适应一般需求,没有万能的模板适应所有需求.
* 如果你陷入要重复生成,势必为造成模板复杂,后期会难以维护.
（4）构建你自己的脚手架?因为rapid是一个更加通用的脚手架(dao层，web层都可切换不同组件),因而也限制其现在的发展，而你可以构建属于自己的项目脚手架(如 ring_rest+ ring_jdbc+free打***发任务：400-188-6666
您的位置：
任务稿件
关注人数
浏览人数
ebay商店开发经验调查 任务编号：8771
买家：
信用等级：
本页推广地址：
任务要求
温馨提示
任务结束后买家有7天时间选稿，如逾期不选，将由系统代为选稿。
查看附件时请先确认外部链接以及附件的安全性，建议开启杀毒软件。
调查一下，有国外ebay商店开发经验的朋友请过来留个言。 交稿要求： 写明网店的店名，并附带网络连接。每人只接受一个交稿。谢谢 任务圆满结束
中标卖家获得了任务的80%赏金
任务圆满结束
中标卖家获得了任务的80%赏金
任务赏金：
(中标可获任务赏金的80%)
开始时间：
2008-08-18 16:28:03
结束时间：
2008-08-30 17:28:03
赏金已托管，买家保证选稿
只要稿件有效买家都会选稿
赏金已托管，买家保证选稿
只要稿件有效买家都会选稿
1.买家已经将赏金全额托管到猪八戒网
2.只要稿件是有效稿件，且数量满足中标模式要求，买家就必须选稿。
3.任务结束后买家有7天时间选稿，如逾期不选，将由系统代为选稿。
中标模式：计件付费
合格一个就奖励一个
中标模式：计件付费
合格一个就奖励一个
任务提醒：
您还未登录，不能进行任何操作。立即
正在加载数据，请稍候...
所有稿件
排序：
搜索：
稿件编号:
交稿时间:2008/08/25 17:33:25
发布者已浏览
分享到：
买家评分：
http://www.ebay.com/ 美国ebay网
开发经验：
作者 Randy Shoup译者 郭晓刚
在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（1015或250）来计算——可伸缩性是生死交关的问题。
在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。
可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。
最佳实践 #1：按功能分割
相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你把它叫做SOA、功能***还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。
在编码层次，我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等，都是用来隔离和抽象功能的机制。
在应用层次，eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行，投标功能由另一组负责，搜索又是另外一组服务器。我们把总 共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗，单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。
在数据库层次，我们也采取同样的做法。eBay没有无所不包的单一数据库，相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样，这种做法让我们得以单独为某一类数据伸缩其数据库设施。
最佳实践 #2：水平切分
按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系 统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载***成许多我们有能力驾驭的小单元，让每个单元都能维持良好 的性能价格比。这就是水平分割出场的时候了。
在应用层次，由于eBay将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是 均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。
数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户 数据目前被分割到20台主机上，每台主机存放1/20的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID尾数为1的放到第一 台主机，尾数为二的放到下一台，以此类推），有些是按照ID的区间分割（1-1M、1-2M等等），有些用一个查找表，还有些是综合以上的策略。不过具体 的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。
最佳实践 #3：避免分布式事务
看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的***是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的***是，对于不相关的系统，放宽对它们的跨系统事务的保证。
左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Co istency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于24x7运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate co istency）。
在eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual co istency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement atches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。
对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。 最佳实践 #4：用异步策略解耦程序
提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分 必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就 是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此 时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。
整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Drive Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程***为阶段（stage or hases），然后将它们异步地连接起来，这是伸缩的关键。
最佳实践 #5：将过程转变为异步的流
用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部***成异步运行。任何可以晚点再做的事情都应该晚点再做。
还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平 均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从 异步处理中得益。
最佳实践 #6：虚拟化所有层次
虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各 种分割增加额外的虚拟层次就成为重中之重。
在eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后，我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。
搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。
以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。
最佳实践 #7：适当地使用缓存
最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能 随着时间而改变。
最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay，我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。
好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一 点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否100%正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。
做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好 会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。
可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为0的需求，比一切需求的优先级都高。
希望以上最佳实践能对你有用，希望能帮助你从新的角度审视你的系统，无论其规模如何。
英文原文：
Scalability Best Practices: Le o from eBay
At eBay, one of the rimary architectural force we contend with every day i calability. It color and drive every architectural and desig decisio we make. With hundred of millio of user worldwide, over two illio age view a day, and etabyte of data i our ystems, thi i ot a choice - it i a ece ity.
I a calable architecture, resource usage hould increase linearly (or etter) with load, where load may e measured i user traffic, data volume, etc. Where erformance i about the resource usage a ociated with a ingle unit of work, calability i about how resource usage change a unit of work grow i umber or ize. Said another way, calability i the hape of the rice-performance curve, a o osed to it value at one oint i that curve.
There are many facet to calability - tra actional, operational, development effort. I thi article, I will outline everal of the key est ractice we have learned over time to cale the tra actional throughput of a web-based ystem. Most of these est ractice will e familiar to you. Some may ot. All come from the collective experience of the eople who develo and operate the eBay ite.
Best Practice #1: Partitio y Function
Whether you call it SOA, functional decomposition, or imply good engineering, related iece of functionality elong together, while unrelated iece of functionality elong apart. Further, the more decoupled that unrelated functionality ca e, the more flexibility you will have to cale them independently of one another.
At the code level, we all do thi all the time. JAR files, ackages, undles, etc., are all mechanism we use to isolate and a tract one et of functionality from another.
At the a licatio tier, eBay egment different functio into eparate a licatio ools. Selling functionality i erved y one et of a licatio ervers, idding y another, earch y yet another. I total, we organize our roughly 16,000 a licatio erver into 220 different ools. Thi allow u to cale each ool independently of one another, according to the demand and resource co umptio of it function. It further allow u to isolate and rationalize resource dependencie - the elling ool only eed to talk to a relatively mall u et of ackend resources, for example.
At the database tier, we follow much the ame a roach. There i o ingle monolithic database at eBay. I tead there i a et of database host for user data, a et for item data, a et for urchase data, etc. - 1000 logical database i all, o 400 hysical hosts. Again, thi a roach allow u to cale the database inf 抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
对于大型项目来说化解风险最根本的一条是将大的项目***成为很多个相对独立的部分，而后分别完成每一部分，将风险控制在一定范围内。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS具有4个主要用途：
* WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。
*WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
*WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
*WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被***为WBS，是因为较好的工作***可以：
*防止遗漏项目的可交付成果。
*帮助项目经理关注项目目标和澄清职责。
*建立可视化的项目可交付成果，以便估算工作量和分配工作。
*帮助改进时间、成本和资源估计的准确度。
*帮助项目团队的建立和获得项目人员的承诺。
*为绩效测量和项目控制定义一个基准。
*辅助沟通清晰的工作责任。
*为其他项目计划的制定建立框架。
*帮助分析项目的最初风险。
WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点：
*工作包可以分配给另一位项目经理进行计划和执行。
*工作包可以通过子项目的方式进一步***为子项目的WBS。
*工作包可以在制定项目进度计划时，进一步***为活动。
*工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。
*工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
1. 创建WBS的方法
创建WBS是指将复杂的项目***为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：
（1）使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。
（2）类比方法。参考类似项目的WBS创建新项目的WBS。
（3）自上而下的方法。从项目的目标开始，逐级***项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。
（4）自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。
2．创建WBS的基本要求
（1）某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
（2）WBS中某项任务的内容是其下所有WBS项的总和。
（3）一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
（4）WBS必须与实际工作中的执行方式一致。
（5）应让项目团队成员积极参与创建WBS，以确保WBS的一致性。
（6）每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。
（7）WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。
3．WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。
在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。
4．WBS的***方式
WBS的***可以采用多种方式进行，包括：
（1）按产品的物理结构***。
（2）按产品或项目的功能***。
（3）按照实施过程***。
（4）按照项目的地域分布***。
（5）按照项目的各个目标***。
（6）按部门***。
（7）按职能***。
5．创建WBS的过程
创建WBS的过程非常重要，因为在项目***过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：
（1）得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。
（2）召集有关人员，集体讨论所有主要项目工作，确定项目工作***的方式。
（3）***项目工作。如果有现成的模板，应该尽量利用。
（4）画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
（5）将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。
（6）验证上述***的正确性。如果发现较低层次的项没有必要，则修改组成成分。
（7）如果有必要，建立一个编号系统。
（8）随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。
检验WBS是否定义完全、项目的所有任务是否都被完全***可以参考以下标准：
（9）每个任务的状态和完成情况是可以量化的。
（10）明确定义了每个任务的开始和结束。
（11）每个任务都有一个可交付成果。
（12）工期易于估算且在可接受期限内。
（13）容易估算成本。
（14）各项任务是独立的。
6．WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。
当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作***结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。
WBS、OBS、RBS、职责分配矩阵比较：
WBS 是工作***结构，下面都是工作包，都是成果，不包括具体人员、具体资源信息；
OBS 是组织***结构，里面是部门、单位或团队, 不包括具体工作内容、工作职责，工作职责通常在职责说明书里面；
RBS 是资源***结构，包括人的信息，因为人也是资源，不过不包括工作内容和所属部门。
职责分配矩阵，是把WBS和OBS结合起来，显示工作包和团队成员之间的关系。
7．WBS的实践经验
WBS字典：超大型项目需要，WBS字典有助于追踪所有的概要和详细的活动，包括一个简短的说明、WBS数字标识符（1.1、1.1.1、1.1.2等）和预计的努力。如果你把WBS字典输入到一个专门的工具中，这个工具还有助于追踪WBS的变化。
让最后的详细活动以行动为导向：WBS中的详细活动（不能进一步***的活动）最终会转移到你的进度表中；因此，如果WBS中的详细活动以行动为导向会更加方便。
典型的WBS实践流程：
1. 制定工作产品清单（PL）。
工作产品（Working Product）是项目需要产出的工作结果，可以是项目最终交付成果的组成部分，也可以是项目中间过程的产出结果。以软件开发为例，软件中的用户管理模块是最中软件产品的一部分，软件的需求分析文档是软床过程中的文件，都是软件开发这个项目的工作产品。工作产品有大有小，有的相互关联，有隶属的关系。列出工作产品清单的过程，可以是头脑风暴的方法，项目组共同完成。
2. 制定工作产品***结构（PBS）。
工作产品大大小小列出了很多，大型项目有几百项，几千项。工作这些工作产品的属性和关系，用结构化的方法组织这些工作产品，形成一个自顶向下的逐级细分的工作产品***结构（PBS：Product Breakdown Structure）。这就是制造业内的产品物料表（BOM），说明一个产品有多少个零件组成。
3. 制定工作任务***结构（WBS）。
有了PBS，只要把获得工作产品的任务明确，就可用根据PBS的结构，得到WBS了。注意同样的PBS，可用有不同的WBS，因为获得同样工作产品的任务可以是不同的。例如软件开发中的用户管理模块，是PBS中的工作产品，对于到WBS中，可以是不同的任务，一种是采购一个用户管理模块，另一种可以是项目小组开发一个用户管理模块。
4. 制定组织***结构（OBS）。
WBS中的任务确定了，完成任务的责任人也就可以明确了。因此由WBS则可以形成整个项目的组织***结构，由那些人来完成项目的任务，得到工作产品，并完成项目。
其中的关键是***的结构，PBS、WBS和OBS是同一个结构，只是从不同的角度来阐述这个结构。关于这个结构的***方法，常用的有组件***方法和过程***方法。典型的组件方法就是制造业中把一个完整的产品，逐级***到零件。典型的过程***方法可以是软件开发从需求到设计、编码、测试的一个过程。项目***中，这两种方法往往交替使用，其最终是把项目***到一个个具体和细小的工作任务。
/ 浏览 (0 / 98)
分类:
博客分类：
抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
项目管理是通过利用项目管理知识、技能、工具和技术将输入（资源等）创造出结果，以实现项目目标。
过程组：启动、规划、执行、监控、收尾，和戴明环PDCA类似。
大型项目可以分阶段或子项目进行，每个阶段/子项目都有自己的过程组。
===================================================================
一、启动
1、项目章程：项目目标、初步的项目范围、资源投入、建设和制约因素；项目经理得以任命、权利得以保证；项目章程由Spo or或PMO颁发。（INPUT：合同、项目工作说明书、事业环境、OPA）
2、项目初步范围说明书，这个主要是为验收提供依据，不是必须的；为项目提出粗略定义，包括可交付成果的要求、产品要求、项目边界、验收方法和高层范围控制。
二、规划
识别依赖关系、要求、风险、机会，明确范围、进度和费用（滚动规划）。项目团队应创造利于利害关系者做出贡献的环境。
项目管理计划（计划的计划）和沟通管理计划有自己明确的内容，其他“管理计划”基本为方法论。
项目规划从“制定项目管理计划”开始到出最后的“进度表制定”结束，中间可能涉及20个过程，下面分4大类展开：
1.1、范围规划：范围管理计划（方法论，如何确定、核实和控制项目范围）
1.2、范围定义：范围说明书（产品范围＋项目范围，跨知识域的更新需要走“变更”流程）
1.3、制作WBS：根据可交付成果进行***
2.1、活动定义：可交付成果需要的具体活动
2.2、活动排序：识别活动间的逻辑关系
2.3、活动资源估算：活动需要的资源类型和数量（含设备、人力资源，不含费用）
2.4、活动持续时间估算：活动需要的单位工作时间
2.5、进度表制定：分析活动顺序、持续时间、资源要求及进度制约，形成进度表（甘特图）
3.1、费用估算：估算活动（工作包）所需各种资源的费用
3.2、费用预算：资金计划（汇总费用估算、储备资金、制定费用基准）、形成资金分配表
3.3、质量规划：质量管理计划（方法论：明确方针、设立过程，识别质量标准与项目关系）
3.4、人力资源规划：识别项目角色、责任、报告关系；制定人员配备管理计划
3.5、沟通规划：识别信息、传递信息（利害关系者）
3.6、采购规划：确定采购战略，形成采购管理计划
3.7、发包规划：具体采购战术，形成RFP
4.1、风险管理规划：风险管理计划（方法论、模板）－如何对待、规划和执行项目风险管理活动
4.2、风险识别：风险登记册－识别风险
4.3、定性风险分析：风险分级
4.4、定量风险分析：高优先级的进行货币损失评估
4.5、风险应对规划：增加机会、规避风险的行动方案
三、执行
按计划整合并实施项目活动、协调人与资源、处理项目范围说明书中明确的范围、实施经过批准的变更。
偏差来源：活动持续时间、资源生产率与余缺、未曾料到的风险
偏差影响：偏差分析－变更－项目管理计划－新基准
1、指导与管理项目执行：可交付成果、变更、工作绩效信息
2、实施质量保证：验证过程、树立信心
QA：Quality A urance质量保证：对工序、工艺、方法进行验证，管理有效性的验证
QC：Quality Control质量控制：对成果进行检验、消除未达标原因
3、组建项目团队：将配置的人力资源组成工作团队
4、建设项目团队：改善能力和团队合作、提升绩效
5、信息发布：按流程向利害关系者广播信息
6、询价：价格、方案和供应商反馈
7、卖方选择：开标、商务谈判、合同
四、监控
Monitor：仪表盘，Control：油门＋刹车
观察项目执行、及时发现潜在问题并在必要时进行纠正。
1、监控项目工作：根据项目管理计划和实施基准，识别风险、绩效等
2、整体变更控制：变更、纠正/预防/补救措施
1、范围核实：验收可交付成果
2、范围控制：WBS、范围基准
3、进度控制：进度模型数据、进度基准、活动清单和属性
4、费用控制：对造成偏差的因素施加影响、控制项目预算变更（发现缺陷、消除成因）
5、质量控制
6、项目团队管理：跟踪绩效、解决问题
7、绩效考核：收集和发布绩效信息形成绩效报告，含状态、进展和预测（干的怎么样？花的代价？），是支持监控工作的一种手段
8、利害关系者管理：问题统一出口
9、风险监控：跟踪风险、评估资源、实施应对计划并评价其有效性
10、合同管理：管理合同内容和合作关系
五、收尾
正式结束项目/项目阶段的所有活动，交付完成的成果。
1、 项目收尾：乙方内部关闭项目的全部动作，总结、评估、释放人力资源、交付成果。
2、 合同收尾：关闭与甲方合同关系的动作。
/ 浏览 (0 / 65)
分类:
博客分类：
抄来抄去，不知谁是原版正宗了，反正我不是原创，为了方便自己阅读，调整了一下版面。
SOW：Statement of Work工作说明书
SOW通常作为合同的一部分，对提供的产品或服务进行表述。SOW在很高层次上说明项目的用途、范围与途径。实际上，SOW是客户与供应商之间的高层共识，将帮助沿着正确的方向安排策划工作，是WBS的基础。
SOW通常包括：对项目技术的目标与宗旨的描述，必须满足的成本和进度方面的约束，实际存在的资源约束，以及客户与供应商在开始时应该理解的有关假定。
1、范围陈述（系统的目的与范围陈述）
2、约束陈述（包括开发和实施知识管理体系的成本预算、完成的时间、具体质量陈述等）
3、责任陈述（包括知识获取和工具选择的责任问题）
4、要求陈述（比如客户要求）
5、交付使用陈述（比如陈列、培训、文件）；签名（包括项目经理、项目发起人、客户）等
SOW的三个特征：
1、SOW是一份简短的文档。它既不是一份设计文档，也不是一份完整的法律合同。它应该是在高层商抓住要点。SOW的作用是奠定工作范围、开始定义最终产品。
2、保证客户与高层管理者能充分评审并批准SOW，然后才有可能切实地着手进行项目的其他活动。
3、一份SOW获得批准、便应对这份文档进行版本控制，并将它作为项目计划的一部分。
========================================================================
工作说明书（SOW）模板
工作说明书主要包括以下内容
前言、服务范围、方法、假定、服务期限和工作量估计、双方角色和责任、交付资料、完成标准、顾问组人员、收费和付款方式、变更管理等。
1. 前言
对项目背景等信息作简单描述。
2. 项目工作范围
详细描述项目的服务范围，包括业务领域、流程覆盖、系统范围及其他等。
3. 项目工作方法
项目拟使用的主要方法。
4. 假定
项目进行的假定条件，具体内容需双方达成。
5. 工作期限和工作量估计
项目的时间跨度和服务期限，对于按人天计算费用的项目，需评估服务工作人天，并估算项目预算。
6. 双方角色和责任
分为供应商的职责和公司的职责，并对关键角色的工作职责进行描述“如：项目经理”。
7. 交付件
列出项目的主要交付资料，并对交付件的内容与质量要求进行描述。
8. 完成以及验收标准
列出项目的完成标准和阶段完成标准，完成标准作为项目验收的依据内容。
9. 服务人员
请列出供应商的人员名单，及顾问资格信息。供应商人员的变更：描述在什么情况下可进行供应商人员的变更。
10. 聘用条款
对聘用供应商人员的级别要求、经验要求及其他相关条款。
11. 收费和付款方式
项目的付款方式、费用范围、涉税条款等。
12. 变更管理
项目变更的管理过程、相关规定与约束条件等。
13. 承诺
双方承诺均已阅读，理解并同意遵行上述协议书及其条款的约束。而且双方同意，所提到的服务条款及其附件(包括工作说明书和变更授权以及任何为双方协议中独立完整的陈述)，取代所有的建议书或其它在此之前的书面或口头协议以及有关的其他交流。
14. 保密
遵守保密协议（保密条款另行签署）
15. 签署接受
XXXXXXXXXX公司（供应商） xxxxxxxxxxx公司（发包商）
授权签名：_______________ 授权签名：_________________
姓名：_________ 日期：______ 姓名：_________ 日期：______
职位：___________ 职位：___________
/ 浏览 (0 / 119)
分类:
博客分类：
一、简单直接就是生产力，就选 rapid
1. 最佳实践
（1）尽量删除没用的东西
生成器帮你生成的东西有时你是并不需要的,如一张表只有查看,而没有增删改功能,那么你应该将edit.j ,create.j 等无用的东西删除,UserAction.save(),UserAction.edit()等方法也都删除,只保留需要的东西,以保持代码的整洁.避免后来者在这些无用东西上产生不必要的误解而增加维护成本.
（2）一个项目一套生成器模板
* 因为各个项目的UI都有可能是不一样的,而UI模板也可能需要根据不同项目要进行不同的定制,所以你的项目需要自带一套模板.而Dao,Service等模板则可以通用.
* 你可能会有一个自己的脚手架及公共的模板,并且会持续修改.但是由于现在使用生成器的项目已经在开发,当前项目使用的模板很有可能赶不上你自己的公共脚手架中的模板修改.所以项目通常自带一套模板并持续维护.
（3）拒绝重复生成代码的诱惑
本人实践,代码只生成一次,后面全部是手写代码. 初始生成的代码已经可以为你减轻很大的工作量.
* DAO层以上代码重复生成一点意义也没有,只是帮你生成一个骨架(生成的代码与框架结合,已经是十分精简),然后自己再填空编写业务逻辑
* 后台的话可以直接生成UI页面,生成一次以后自己就手工编辑,页面千变成化,只能适应一般需求,没有万能的模板适应所有需求.
* 如果你陷入要重复生成,势必为造成模板复杂,后期会难以维护.
（4）构建你自己的脚手架?因为rapid是一个更加通用的脚手架(dao层，web层都可切换不同组件),因而也限制其现在的发展，而你可以构建属于自己的项目脚手架(如 ring_rest+ ring_jdbc+free打***发任务：400-188-6666
您的位置：
任务稿件
关注人数
浏览人数
ebay商店开发经验调查 任务编号：8771
买家：
信用等级：
本页推广地址：
任务要求
温馨提示
任务结束后买家有7天时间选稿，如逾期不选，将由系统代为选稿。
查看附件时请先确认外部链接以及附件的安全性，建议开启杀毒软件。
调查一下，有国外ebay商店开发经验的朋友请过来留个言。 交稿要求： 写明网店的店名，并附带网络连接。每人只接受一个交稿。谢谢 任务圆满结束
中标卖家获得了任务的80%赏金
任务圆满结束
中标卖家获得了任务的80%赏金
任务赏金：
(中标可获任务赏金的80%)
开始时间：
2008-08-18 16:28:03
结束时间：
2008-08-30 17:28:03
赏金已托管，买家保证选稿
只要稿件有效买家都会选稿
赏金已托管，买家保证选稿
只要稿件有效买家都会选稿
1.买家已经将赏金全额托管到猪八戒网
2.只要稿件是有效稿件，且数量满足中标模式要求，买家就必须选稿。
3.任务结束后买家有7天时间选稿，如逾期不选，将由系统代为选稿。
中标模式：计件付费
合格一个就奖励一个
中标模式：计件付费
合格一个就奖励一个
任务提醒：
您还未登录，不能进行任何操作。立即
正在加载数据，请稍候...
所有稿件
排序：
搜索：
稿件编号:
交稿时间:2008/08/25 17:33:25
发布者已浏览
分享到：
买家评分：
http://www.ebay.com/ 美国ebay网
开发经验：
作者 Randy Shoup译者 郭晓刚
在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（1015或250）来计算——可伸缩性是生死交关的问题。
在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。
可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。
最佳实践 #1：按功能分割
相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你把它叫做SOA、功能***还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。
在编码层次，我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等，都是用来隔离和抽象功能的机制。
在应用层次，eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行，投标功能由另一组负责，搜索又是另外一组服务器。我们把总 共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗，单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。
在数据库层次，我们也采取同样的做法。eBay没有无所不包的单一数据库，相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样，这种做法让我们得以单独为某一类数据伸缩其数据库设施。
最佳实践 #2：水平切分
按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系 统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载***成许多我们有能力驾驭的小单元，让每个单元都能维持良好 的性能价格比。这就是水平分割出场的时候了。
在应用层次，由于eBay将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是 均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。
数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户 数据目前被分割到20台主机上，每台主机存放1/20的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID尾数为1的放到第一 台主机，尾数为二的放到下一台，以此类推），有些是按照ID的区间分割（1-1M、1-2M等等），有些用一个查找表，还有些是综合以上的策略。不过具体 的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。
最佳实践 #3：避免分布式事务
看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的***是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的***是，对于不相关的系统，放宽对它们的跨系统事务的保证。
左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Co istency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于24x7运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate co istency）。
在eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual co istency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement atches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。
对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。 最佳实践 #4：用异步策略解耦程序
提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分 必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就 是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此 时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。
整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Drive Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程***为阶段（stage or hases），然后将它们异步地连接起来，这是伸缩的关键。
最佳实践 #5：将过程转变为异步的流
用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部***成异步运行。任何可以晚点再做的事情都应该晚点再做。
还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平 均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从 异步处理中得益。
最佳实践 #6：虚拟化所有层次
虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各 种分割增加额外的虚拟层次就成为重中之重。
在eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后，我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。
搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。
以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。
最佳实践 #7：适当地使用缓存
最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能 随着时间而改变。
最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay，我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。
好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一 点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否100%正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。
做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好 会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。
可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为0的需求，比一切需求的优先级都高。
希望以上最佳实践能对你有用，希望能帮助你从新的角度审视你的系统，无论其规模如何。
英文原文：
Scalability Best Practices: Le o from eBay
At eBay, one of the rimary architectural force we contend with every day i calability. It color and drive every architectural and desig decisio we make. With hundred of millio of user worldwide, over two illio age view a day, and etabyte of data i our ystems, thi i ot a choice - it i a ece ity.
I a calable architecture, resource usage hould increase linearly (or etter) with load, where load may e measured i user traffic, data volume, etc. Where erformance i about the resource usage a ociated with a ingle unit of work, calability i about how resource usage change a unit of work grow i umber or ize. Said another way, calability i the hape of the rice-performance curve, a o osed to it value at one oint i that curve.
There are many facet to calability - tra actional, operational, development effort. I thi article, I will outline everal of the key est ractice we have learned over time to cale the tra actional throughput of a web-based ystem. Most of these est ractice will e familiar to you. Some may ot. All come from the collective experience of the eople who develo and operate the eBay ite.
Best Practice #1: Partitio y Function
Whether you call it SOA, functional decomposition, or imply good engineering, related iece of functionality elong together, while unrelated iece of functionality elong apart. Further, the more decoupled that unrelated functionality ca e, the more flexibility you will have to cale them independently of one another.
At the code level, we all do thi all the time. JAR files, ackages, undles, etc., are all mechanism we use to isolate and a tract one et of functionality from another.
At the a licatio tier, eBay egment different functio into eparate a licatio ools. Selling functionality i erved y one et of a licatio ervers, idding y another, earch y yet another. I total, we organize our roughly 16,000 a licatio erver into 220 different ools. Thi allow u to cale each ool independently of one another, according to the demand and resource co umptio of it function. It further allow u to isolate and rationalize resource dependencie - the elling ool only eed to talk to a relatively mall u et of ackend resources, for example.
At the database tier, we follow much the ame a roach. There i o ingle monolithic database at eBay. I tead there i a et of database host for user data, a et for item data, a et for urchase data, etc. - 1000 logical database i all, o 400 hysical hosts. Again, thi a roach allow u to cale the database inf