1.选择商品化的技术
2.关注技术风险和市场风险
3.选择没有技术风险的想法
4.累积技术债务，快速将产品推向市场
5.仅当被黑了才重视安全
6.忘掉可扩展性
7.对好的想法说 “不”
8.没有笨重的语言
9.速度高于质量
10.用户体验高于用户界面
抽象化是一种非常的不同于模糊化的东西 … 抽象的目的并不是为了模糊，而是为了创造出一种能让我们做到百分百精确的新语义。
除数学外，对本土语言的异常的精通会是一个计算机程序员的最宝贵的财富。
程序应该是写给其他人读的，让机器来运行它只是一个附带功能。
性能的关键是精简，而不是一堆的优化用例。除非有真正显著的效果，否则一定要忍住你那些蠢蠢欲动的小微调的企图。
原型的价值就在于它对你的教育，而不是代码本身。
原文地址：http://blog.csdn.net/DL88250/archive/2007/10/16/1826713.aspx
一．UML简介
UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支 持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动 图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来 全面描述我们将要开发的系统。
二．用例建模简介
用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为 用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1． 用例图
参与者不是特指人，是指系统以外的，在使用系 统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示 人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆 借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是 UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、 描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。 
系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
2． 用例描述
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
三． 用例图和用例描述设计实例
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下： 
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：
| 用例名称：网站公告发布 |
| 用例标识号：202 |
| 参与者：负责人 |
|
简要说明： 负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。 |
|
前置条件：负责人已经登陆家教网站管理系统 |
|
基本事件流： 1．负责人鼠标点击“修改公告”按钮 2．系统出现一个文本框，显示着原来的公告内容 3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告 4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改 5．用例终止 |
|
其他事件流A1： 在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告 |
|
异常事件流： 1．提示错误信息，负责人确认 2．返回到管理系统主页面 |
|
后置条件： 网站首页的公告信息被修改 |
补充:
用例之间也可以存在包含、扩展和泛化等关系：
（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
图2.3给出了一个扩展关系的例子，在还书的过程中，只有在例外条件（读者遗失书籍）的情况下，才会执行赔偿遗失书籍的分支流。
（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。如在图2.4中，订票是电话订票和网上订票的抽象。
————————————————————
泛化、包含和扩展
泛化（Generalization）在面向对象的技术中无处不在，它的另一个名字也许更为著名，就是“继承”。下图给出了一个使用泛化的用例图：
可知，在用例图中，角色和用例都能够泛化。角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。如下图：
一线架构师的6个经典困惑：
4个实际问题的困惑
- 将系统划分模块，如何更合理
- 大系统架构设计，如何起步？
- 总觉得需求很糟糕，影响了架构设计
- 非功能需求重要，但如何设计？
两个职业发展的困惑
- 架构新手：缺乏指导，架构设计不知所措
- 架构老手：缺乏总结，仍“怕”下一个项目
本书的四个核心主张：
- 方法体系是大趋势
- 质疑驱动的架构设计
- 多阶段方法
- 内置最佳实践的方法
质疑驱动的架构设计
架构设计实际上“质疑驱动的过程”：需求，被架构师的大脑（而不是自动）有节奏地引入架构设计一波一波的思维活动中。例如，架构到一半时，你可以明显感觉到：这个架构设计的中间成果，还须要进一步“质疑”引入更多“质量属性”，以及“特殊功能场景”来驱动后续架构设计的开展。
质疑意识，是架构师最宝贵的意识之一。
多阶段还是多仕途
架构设计的多视图方法很重要，但是架构设计方法首先应当多阶段，其次才是多视图的。一句话，先做后做——这叫阶段，齐头并进——这叫视图。
Pre-architecture阶段的使命，可以概括为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。
需求验证的目标是尽可能暴露问题，而不是证明无错。
架构设计不仅要求考虑支持功能、满足质量要求，还要重视各种约束性需求。关注约束，要趁早。
软件架构师不必是需求捕获的专家，也不必是《软件需求规则说明书》的专家；但他一定应在需求分类、需求折衷和需求变更的研究方面是专家，否则他和优秀架构师相比就输在了“起跑线”上。
重大需求塑造概念架构。
细化架构是相对于概念架构而言的。
面向对象或结构化——逻辑架构：职责划分、职责间协作
面向控制流——运行架构：控制流、控制流组织
面向文件——开发架构：程序单元、程序单元组织
面向Table或文件——数据架构：持久数据单元、数据存储格式
面向节点——物理架构：物理节点、物理节点拓扑
许多架构师，言架构必谈OO。在他们的思想里，认为OO方法已经完整涵盖了架构设计的所有方法和技巧，这种看法是相当片面的。
概念性架构就是对系统设计的最初设想，就是把最关键的设计要素和交互机制确定下来，然后考虑具体技术的运用、设计出实际架构。
概念性架构应该抓大局，不拘小节。
虽然概念性架构都跳不出“架构=组件+交互”的基本定义，但他们描述架构的具体方式还是有比较大的差异：有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看上去似乎就是一些设计元素的组合。同步的概念性架构图中，“连接”代表的含义千差万别：有的依赖方向，有的依赖控制方向，有的是数据流向，因此必须根据具体情况而定。
概念性架构界定系统的高层组件，以及他们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。根据定义，我们注意到如下几点：
概念视图，有时候称为“逻辑视图”，这种视图显示了系统的主要部分以及它们之间的相互关系。
如果只考虑“功能需求”来设计概念架构，将导致概念架构沦为“理想化架构”，这个脆弱的架构不久就会面临“大改”的压力。
从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略，再进行细化架构的设计，以保证为开发提供足够的指导和限制……这符合人类解决问题的规律，因此被广泛采用。
细化架构和概念架构之间存在如下典型的差异：
周末在看温昱的《软件架构设计》其中一节讨论到“框架”，整理了《软件架构设计》和我看过的书的其中相关内容。
我总结的框架的定义是：框架是可以通过某种回调机制进行扩展的软件系统或者子系统的半成品。
首先，框架是半成品，这是他和其他所有软件组件的本质区别。这涉及到“软件重用”的一对内在矛盾：“重用几率”大小和“重用所带来的价值量”大小之间的矛盾。简言之，软件单元的粒度越大，则重用所带来的价值量越大，但重用几率越小；反之，粒度小的软件单元被重用的几率越大，则重用所带来的价值量越小。框架的智慧在于此：为了追求重用所带来的价值量最大化，将容易变化的部分封装成扩展点，并辅以回调机制将它们纳入框架的控制范围之内，从而在兼顾定制开销的同时使被重用的设计成果最多。
框架不一定都必须用面向对象编程语言实现，如C语言等传统编程语言可以通过函数指针作为参数来实现回调机制，而面向对象编程语言利用抽象方法。
可以将框架分为技术框架和业务框架。
技术框架致力于解决某一技术领域的通用技术问题，并提供定制和扩展机制。例子很多，例如Hibernate就是解决ORM问题的技术框架。
业务框架则是特定业务领域内通用的框架，比如工作流领域的框架、CRM领域的框架。
框架是一个可实例化的，部分完成的软件系统或子系统，它为一组系统或子系统定义了架构，并提供了构造系统的基本构造块，还为实现特定功能定义了可调整点。在面向对象环境中，框架由抽象类和具体类组成。
框架是构成一类特定软件可复用设计的一组相互协作的类。例如，一个框架能帮助建立适合不同领域的图形编辑器，像艺术绘画、音乐作曲和机械。另一个框架也许能帮助你建立针对不同程序设计语言和目标机器的编译器。而再一个也许能帮助你建立财务建模应用。你可以定义框架抽象类的应用
相关的子类，从而将一个框架定制为特定应用。
框架规定了你的应用的体系结构。它定义了整体结构，类和对象的分割，各部分的主要
责任，类和对象怎么协作，以及控制流程。框架预定义了这些设计参数，以便于应用设计者
或实现者能集中精力于应用本身的特定细节。框架记录了其应用领域的共同的设计决策。因
而框架更强调设计复用，尽管框架常包括具体的立即可用的子类。
这个层次的复用导致了应用和它所基于的软件之间的反向控制(inversion of control)。当
你使用工具箱(或传统的子程序库)时，你需要写应用软件的主体并且调用你想复用的代码。而
当你使用框架时，你应该复用应用的主体，写主体调用的代码。你不得不以特定的名字和调
用约定来写操作地实现，但这会减少你需要做出的设计决策。
你不仅可以更快地建立应用，而且应用还具有相似的结构。它们很容易维护，且用户看
来也更一致。另一方面，你也失去了一些表现创造性的自由，因为许多设计决策无须你来作
出。
如果说应用程序难以设计，那么工具箱就更难了，而框架则是最难的。框架设计者必须
冒险决定一个要适应于该领域的所有应用的体系结构。任何对框架设计的实质性修改都会大
大降低框架所带来的好处，因为框架对应用的最主要贡献在于它所定义的体系结构。因此设
计的框架必须尽可能地灵活、可扩充。
更进一步讲，因为应用的设计如此依赖于框架，所以应用对框架接口的变化是极其敏感
的。当框架演化时，应用不得不随之演化。这使得松散耦合更加重要，否则框架的一个细微
变化都将引起强烈反应。
在 Rickard Öberg（WebWork 的创造者和JBoss 创始人之一）构建最原始版本
WebWork 的时候，他曾经说过：“框架的强大之处不是源自它能让你做什么，而是它不
能让你做什么。”Rickard 所说的话解释了什么是框架：框架使混乱的东西变得结构化。
而Web 应用程序框架则鼓励开发人员使用一系列框架所提供的基础类和类库，从而避免
杂乱的JSP 所造成的混乱。
我们再来打个比方。框架就像是一间有很多屋梁的房子，当你需要扩建房子的时候，
譬如增加新的房间、窗户和过道或者在卧室增加一个壁炉，由于屋梁的限制，你并没有
什么其他的选择。虽然较少的屋梁和架构会让你有更多的选择，但是当台风来袭或者发
生地震的时候，你让家人住在这样一间只有屋顶的房子里，恐怕不会觉得安全吧。总之，
框架是在结构和创造力之间的一个精确的天平。
由于框架要求更多的结构，你的创造力所拥有的发挥空间开始收缩了。一种极端是
框架消失了，一片混乱；而另一种极端就是框架留给你的选择是如此之少，以至于你无
法完成你的应用程序。很明显，一种完美的中间状态存在于这两个极端之间的某一处，
而这种中间状态就是WebWork 和所有其他MVC 框架所梦寐以求的。
框架通过预先把众多组件组织在一起的方式，封装了处理流程的控制逻辑；因此开发者就不用控制逻辑来组织组件之间的交互了。
平行四边形法则-共点力的合成法则
这一法则通常表述为：以表示两个共点力的有向线段为邻边作一平行四边形，该两邻边之间的对角线即表示两个力的合力的大小和方向．
由力的平行四边形法则可知，两个共点力的合力不仅与两个力的大小有关，且与两个力的夹角有关．当两个力的大小一定时，其合力的大小将随两个力夹角的改变在两个力之和与两个力之差范围内变化．
运用平行四边形法则求一共点力系的合力时，可采用依次合成的方法．例如求三个共点力F1 、F2 和F3 的合力F，可先求出 F1和F2 的合力F4 ，然后再求出F3 和F4 的合力F ， 即为三个共点力的合力F． 平行四边形法则不仅是共点力的合成法则，也是一切矢量合成共同遵循的法则。
今天在班车上看的《壹百度》——李彦宏管理思想29条的专题，总结的很好的，所以做了转载。原文的PPT中还有精彩的插图。
原文PPT：http://bbs.21manager.com/dispbbs-250595-1.html
新浪专题地址：http://tech.sina.com.cn/z/baidu/index.shtml
内心的喜好是推劢事业迚步的最大劢力，它能帮你克服困难，坚持到底；而如果你喜欢的事情有徆多，要挑选自己最擅长做的事，这样就能在感受快乐的同时也取得赸乎常人的成就。
第一，做自己喜欢做的事情。因为如果你做的事情自己丌喜欢，碰到困难徆有可能就退了；第二，做自己擅长做的事情。
认准了，就去做讲的是判断力和行劢力——要正确地判断形势不机会，一旦看准了，就要付诸行劢，患得患失只能坐失良机；
不跟风，不劢摇讲的是进见不定力——能看到机会的人徆多，但能坚持到底，丌为眼前利益所劢，丌因一时困难变节的人即徆少，所以多数人的成功都是昙花一现的。
无论是企业戒个人，都应该与注亍自己的领域，幵坚持到底。
因为人的精力是有限的，企业可利用的资源也是有限的，唯有与注如一，将所有的力量施亍一点，才能赸赹别人，取得持久而非凡的成就。
一家公司想要成为市场上的领导者，首先要有领导者的心态，那就是要坚信你做这件事能比所有人都做得好徆多。在这种心态下，把每件事情都做到极致，你就能最终成为领导者。
在对别人做出承诹的时候，一定要求实，讲真话，做得到再说。如果在承诹不交付的结合处画一条水平线的话，那么我们对别人做出的承诹应该低亍这道线，而交付给人的结果则要高出这道线。
因为做到的，永进比豪言壮语更有力量。
“我觉得这些数据徆好地表达了用户对hao123的真实态度。看来，我们以前的做法都太想当然了。”在2008年初一次例行的产品委员会的讨论上，Robin严肃地向大家提了这个他观察了徆久的“课题”。
我们的每一步都应该是在解决问题的过程中前迚。
当一个新的idea产生的时候，请先问一下自己，做这件事我能解决什么问题？然后，又会出现什么问题，如何解决？如果一个创意丌能解决仸何现实存在的问题，它就没有实现的价值。
一个有活力不创造力的组织，一定会鼓励一线员工坚持自己的观点幵敢亍直接表达——卲便这可能有悖于某些上级戒权威的观点。只有这样才能让每个人的与业性不责仸感真正发挥出来，避免企业犯经验主义的错误。
组织内最有效率的沟通方法，莫过于实事求是、坦诚相待了。
坦诚地说出否定意见，需要的不仅仅是勇气，还有一颗公正的心——只关注事物本身的对错，而不是根据这件事是谁做的来给出不同的诂判；同时，也丌要把对一件事情的诂判直接引伸为对人的诂价。
勇亍创新和灵活应变，是企业持续发展、克敌制胜的原劢力。
然而随着企业觃模的扩大和业务的成熟，多数公司都会自然而然地倾向安亍现状、保守行事。因此，如何永葆组织的创新激情不灵活求变精神，成为企业管理者的一项长期仸务。
伟大的创新有时就存在亍某些看起来丌成熟的想法里，所以要鼓励员工的每一次创新，舍得给他们机会去试错。有时候明知风险徆大，仍然可以让他们去做。可以小觃模地尝试，如果结果丌好，退回来就是了，但试错中得到的宝贵经验即可以让团队大步成长。
在飞速发展的互联网行业里，产品是以用户为导向在随时演迚的。因此，在推出一个产品乊后要迅速收集用户需求迚行产品的迭代——在演迚的过程中注入用户需求的基因，完成快速的升级换代裂变成长，才能让你的用户体验保持在最高水平。丌要闭门造车以图一步到位，否则你的研发速度永进也赶丌上需求的变化。
在快速发展变化的时代里，如果丌能够丌断学习，就会被市场所淘汰。所以，企业的每一位员工，都应该保持求知若渴、虚心若愚的学习心态。这是企业发展和迚步的根本劢力。
“拿来主义”，是学习的一条捷径。工作中遇到新事物戒新的困难时，丌妨先看看别人是怂么做的，这可能少走徆多弯路，比自己闭门造车效果好得多
在戓场上，要想取得胜利，英明的将帅和具有顽强作戓能力、能够迅速准确执行命令的军队缺一丌可。在时间决定成败的互联网时代，企业也是一样，仸何正确的决策是否能为企业带来优势，最终还是取决亍整个团队的执行效率。
世界上没有一劳永逸的事，问题总是千姿百态，层出丌穷，但我们永进应该做制造印钞机而非手工打制铜钱的事情。遇到问题，多问几个为什么，找到根源，用系统的解决方案根除它，才可以为组织丌断增强免疫力和提升工作效率。
一个高效的组织，应该讲究协同作戓，作为组织中的一员，在做项目的时候，应该想到，你拥有的丌仅仅是自己部门的资源，身边徆多其他部门的资源都可以为我所用；而在你的日常工作中，也应该随时想到，自己的工作是否可以为身边的其他同事戒团队提供帮劣。当组织中的每一个成员都这样做的时候，这个组织的整体效率就会是最高的。
随着公司觃模逐渐增大，本位主义不部门利益高亍整体利益的现象也会自然而然地滋生。而这，也必将成为组织发展最大的阻碍。要想让几千人甚至几万人的公司仍然保持小公司的效率，公司各阶层的管理者们就必须丌断去打破那些部门间的围墙不疆界。
一个人的知诃不阅历再丰富，其覆盖面也总是有限的，在一个真正的团队里，每个人都应该向后来者无私地分享团队已有的知诃、经验不教讪，让他/她站在前人肩膀上迅速成长。如果每个人都能做到主劢分享，我们在一起就丌再是加法，而是乘法了，团队的效率不“智商”才会丌断提高。
企业对人才的选择往往决定着这个企业能走多进，如果要做一个世界级的优秀企业，那就要力争在全世界范围内找到最优秀的人才。
所谓管理者的职责，就是为优秀人才搭建一个自由、宽松的平台，因为人只有在自由的穸间里，其创造力才能真正释放出来；也只有在独立自主地面对不解决问题的过程中，才能得到最高速的成长。
诂定一个人是否称职戒是否应该被提拔的最佳方法只有一个，那就是先给他一个平台、一仹责仸，看他是否能拿出实实在在的工作成果来证明自己。
面对快速变化的外部环境和快速发展的产业，如果能及时准确地把握产业机会，就可能觃避风险幵快速获得成功，这一切都取决亍一个人的判断力。
勿以善小而丌为，公司里仸何一处小的丌完美，都是你可以劢手去改善的地方，而对公司而言，如果员工都愿意把公司的每件小事当成自己丌可推御的责仸，那么这家公司就没有理由丌成功。
一个成功的企业应该注重营造这样一种氛围，让每一个员工都觉得自己是企业的主人，将个人的事业发展融入企业目标中，不企业荣辱不共。
如果你的技术是丌被市场所需求的，那么它的价值就会徆低。丌要为了自己的喜好戒虚荣心而开发炫酷的产品戒技术，决定一个产品好丌好，一个技术是否有价值的，永进是用户，他们有需求，你就做，他们没有需求，你就丌要做。
决策是一个先民主后集中的过程——理赹辩赹明，一定要听取最广泛的意见，包括公司内外的一切与家不相关人士，然后不做这件事的核心人员商量，但最终的决定只能自己来做。是所谓谁负责，谁做主。
百度对这个社会最大的价值就是帮劣人们最便捷地找到所求。这些人丌仅包括我们的用户，也包括我们的客户，以及我们客户的客户。正是在丌断帮劣别人的过程中，百度逐渐发展壮大起来。
无论一个公司取得多么大的成功，都别放下危机意诃——哪怕片刻。所以，请记住，最好永进把自己当做一家胸怀进大理想的小公司。
作者：周金银
博客：http://www.cnblogs.com/zhoujg/
原文下载地址：敏捷方法之Scrum v0.2原文下载
软件复杂度有三个主要因素：业务、技术和人员。《agile project management with scrum》（中文书名：Scrum敏捷项目管理）一书中有一个复杂度的图。
X轴表示技术（成熟度），Y轴表示业务（一致度）。从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。 技术和业务最终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。
这些复杂性将导致开发过程中存在很多不确定性，所以项目初期制定的计划其实基本上不能真正的坚持下来。而当项目开发遇到困难时，项目组可能会为了表明自己做计划的能力，或者不想经历复杂的变更过程，而继续努力的坚持这个已经错误的计划。范围、时间和成本，这 个金三角几乎没有领导不知道，而项目组为了保证”遵循计划“，对外宣称项目组运行状况良好，保证当前人员在预计时间肯定能保质保量的完成开发。而代码质量 只有开发人员知道，领导们容易忽略和难以控制这个环节，所以最后一味的遵循计划就势必导致提供给客户的是一个不满意的产品。
Waterfall VS Agile
瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划，在过程与工具支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。而敏捷开发是价值驱动，通过自组织团队在短期迭代过程中不断的交付对用后有用的功能来进行产品开发。从上图的正反三角形图形可以看出两者的驱动是不同的。
客户协作 胜过 合同谈判
虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。
响应变化 胜过 遵循计划
虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了,反而我们需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通 过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调 整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。
个体与交互 胜过 过程与工具
一个使用普通工具的优秀人员会比使用优秀工具的普通人 员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时 和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径 解决开发过程中遇到的问题。
可以工作的软件 胜过 面面俱到的文档
虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流， 也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够就行了。
Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。
Prodcut Backlog
产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。
Product backlog应该由Product Owner来制定
怎么拆分故事
很大的故事基本上都能进行拆分，只要确定每个小故事莹然可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
“更好的定义是：‘在大多数成功的软件项目中，从事该项目的专家开发人员对设计系统的设计存在共识。这种共识被称为 “架构”。这种共识包括如何将系统分为组件以及组件如何通过接口进行交互。’”
有三个问题可能会产生偶发复杂度。我已经讨论了第一个：由于日程或其他外部压力而导致临时大量削减代码。第二个是复制，The Pragmatic Programmers 中称其为对 DRY（不要重复自己，Don’t Repeat Yourself）原则的违背。复制是软件开发中最能让人在不知不觉中降低软件质量的因素，因为在开发人员甚至还没有觉察的情况下，它会蔓延到许多位置。一个明显的例子是复制并粘贴代码，但是也存在大量更复杂的示例。
偶发复杂度的第三个诱因是不可逆性。您做出的无法逆转的所有决定都将最终导致某种程度的偶发复杂度。不可逆性将同时影响架构和设计，尽管它的影响在架构级别上比较常见并且比较有破坏性。尽量避免作出不可逆转或者难于逆转的决定。我的一些同事信奉在最后责任一刻 做决定。这并不表示您应当把决定推迟得太久，只要推迟得比较久就足够了。什么时候才是决定某些架构关注点的最后责任时刻？做决定的时间拖得越晚，您为自己留下的可能性就越多。问问您自己：“我是不是现在就需要做那个决定？” 以及 “我做什么能让我推迟那个决定？” 如果在决策过程中应用一些技巧，那么您将会对您可以推迟的内容感到十分惊讶
Big Design Up Front 设计方法学的支持者在开始编写代码前，要花费大量的时间确定当前应用程序的所有必需的设计元素。编制的文档中的大多数内容对于解决方案的总体设计仍是重要的。但是，在实现软件的过程中，会不断遇见意外。实现的每个设计元素与其他设计元素相互联系，形成极端复杂的依赖和关系网络。代码中有些方面本以为平常不过，但是一旦要实现系统中其他所有必需的部分时，复杂度又随之放大。由于不能理解代码中不同设计元素之间复杂的相互作用，导致在估算完成解决方案所需的努力时困难重重。在软件方面，估算仍是一种玄妙的 “黑色艺术”，因为对于如此复杂的耦合和交互网络，实在是难以理解，因而也难以分析。
依赖于紧急设计的敏捷方法学则尝试一种不同的方法。敏捷架构和设计在编写代码前也不会避开设计，但是它们的实际工作者已经知道，只有等到实现了重要的部分后，才能彻底地理解整个问题。紧急设计中的开发技巧使您可以推迟做决定，直到掌握了更多的上下文。精益软件运动（见 参考资料）有一个很好的概念叫做 最后可靠时刻（last responsible moment）：不是将决定推迟到最后时刻，而是最后可靠时刻。越是往后推迟设计决定，就能掌握越多的信息，从而可以做出更精妙、更符合实际的决定。
Webwork是一个优越的框架，它的设计基于这样一个基本原理：完成通用任务应该是简单的，而构建高级的设计也应该是可行的。
Webwork是一个MVC框架，但同时它也是一个轻量级容器。
在Rickard Oberg（Webwork的创作者和JBoss创始人之一）构建最初版本Webwork的时候，他曾说过“框架的强大之处不是源于它能让你干什么，而是它不能让你做什么”。Rickard说过的话解释了什么是框架：框架使混乱的东西变得结构化。
我们再来一个比方。框架就像是一间有很多房梁的房子，当你需要扩建房子的时候，譬如增加新的房间、窗户、或者卧室增加一个壁炉，由于房梁的限制，你并没有其他的选择。虽然，较少的屋梁和架构会让你有更多的选择，但是当台风来袭或者发生地震的时候，你让你的家人住在一间只有屋顶的房子里，恐怕也不会觉得安全吧。
由于框架会要求更多的结构，你的创造力所拥有的发挥空间开始收缩了。一种极端的情况就是框架消失了，一片混乱；而另一种极端就是框架留给你的选择是如此之少，以至于你无法完成你的应用程序。很明显，一种完美的中间状态存在于这个极端之间的某一处，而这种中间状态就是Webwork和所有其他MVC框架所梦寐以求的。
很多人认为从需求分析到架构设计之间的过渡遇到很多问题，究其根源，可能是以下的原因造成的：
- 用例是面向问题领域的，而设计是面向机器域的，这两个‘空间’存在映射。
- 用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式。
- 用例规约采取自然语言描述，而设计采取形式化的模型描述，描述的方式不一样。
从来不怨 命运之错，
不怕旅途多坎坷，
向着那梦中的地方去，
错了我也不悔过！
人生本来 苦恼已多，
再多一次又如何？
若没有分别痛苦时刻，
你就不会珍惜我！
千山万水脚下过，
一缕情丝挣不脱。
纵然的时候情如火，
心里话儿向谁说？
我不怕旅途孤单寂寞，
只要你也想念我！
我不怕旅途孤单寂寞，
只要你也想念我！
