不要想一次做到尽善尽美 ，多版本 。

敏捷与极限

谷歌技术有"三宝"，GFS、MapReduce和大表（BigTable）！
谷歌在03到06年间连续发表了三篇很有影响力的文章，分别是03年SOSP的GFS，04年OSDI的MapReduce，和06年OSDI的BigTable。SOSP和OSDI都是操作系统领域的顶级会议，在计算机学会推荐会议里属于A类。SOSP在单数年举办，而OSDI在双数年举办。

测试驱动开发
测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。Kent Beck先生最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。经过几年的迅猛发展，测试驱动开发已经成长为一门独立的软件开发技术，其名气甚至盖过了极限编程。[1]
一个生动比喻举个比较生动的例子，这个例子你一定已经在很多关于TDD的文献资料上都看到过，但它确实是一个不错的比喻。在此我进行了一些加工和扩展。盖房子的时候，工人师傅砌墙，会先用桩子拉上线，以使砖能够垒的笔直，因为垒砖的时候都是以这根线为基准的。TDD就像这样，先写测试代码，就像工人师傅先用桩子拉上线，然后编码的时候以此为基准，只编写符合这个测试的功能代码。而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。使用传统的软件开发过程就像这样，我们先编码，编码完成之后才写测试程序，以此检验已写的代码是否正确，如果有错误再一点点修改。你是希望先砌墙再拉线，还是希望先拉线再砌墙呢？如果你喜欢前者，那就算了，而如果你喜欢后者，那就转入TDD阵营吧！详细可参阅。[3]

一个生动比喻举个比较生动的例子，这个例子你一定已经在很多关于TDD的文献资料上都看到过，但它确实是一个不错的比喻。在此我进行了一些加工和扩展。盖房子的时候，工人师傅砌墙，会先用桩子拉上线，以使砖能够垒的笔直，因为垒砖的时候都是以这根线为基准的。TDD就像这样，先写测试代码，就像工人师傅先用桩子拉上线，然后编码的时候以此为基准，只编写符合这个测试的功能代码。而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。使用传统的软件开发过程就像这样，我们先编码，编码完成之后才写测试程序，以此检验已写的代码是否正确，如果有错误再一点点修改。你是希望先砌墙再拉线，还是希望先拉线再砌墙呢？如果你喜欢前者，那就算了，而如果你喜欢后者，那就转入TDD阵营吧！详细可参阅。[3]

测试用例测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例[1]（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

短周期迭代法
2实施要点和步骤
2.1 确定范围，总体规划
2.2 集中设计，原型确认
2.3 分批开发，持续改进
确定范围，总体规划
在项目启动之初，双方即确定工作范围，对争议内容在不影响项目可行性的前提下先搁置起来。、从系统架构到关键技术均要进行彻底分析，必要时先行解决
集中设计，原型确认
用原型法设计，要求原型达到可对照验收的标准需求确认方式，要求关键用户参与并对主体内容进行确认
分批开发，持续改进
每个任务的开发周期在1个月内(最长不超过2个月)，出现延迟可以及时调整改进每个任务采用瀑布式管理模式，要求严格遵循概要设计、详细设计、代码编写、测试、实施的相关规定。针对每个任务执行过程中出现的管理问题、需求问题、技术问题、人员问题，快速的在新的任务分派前予以解决

用户故事
[1]用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
　　1. 角色：谁要使用这个功能。
　　2. 活动：需要完成什么样的功能。
　　3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
　　用户故事通常按照如下的格式来表达：
　　英文：
　　As a <Role>, I want to <Activity>, so that <Business Value>.
　　中文：
　　作为一个<角色>, 我想要<活动>, 以便于<商业价值>
　　举例：
　　作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
　　需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
　　Ron Jeffries的3个C
　　关于用户故事，Ron Jeffries用3个C来描述它：
　　卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
　　交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
　　确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

有人在使用短迭代时遇到了困难。短迭代的拥护者Mishkin Berteig也提到一些潜在的问题 ：
“密集的工作回让人筋疲力尽。”我想这是团队选择何种工作方式的问题。周期短，不一定意味着工作就一定密集。短迭代可能仅仅意味着小时间盒；也就是说，每 个时间盒承诺交付的工作更少了。在工作密度上不一定有什么变化。其他的敏捷原则（特别是“可持续的步调”）就是为了防止发生筋疲力尽的情况。
“战略层面的思考很难跟日程相结合。”战略层面的思考跟每个迭代要做的具体工作没有太大干系。迭代是战术层面的。战略层面的思考是……呃，非战术层面的。这听起来更像是管理上的问题，而不是短迭代的特性之类的东西。
“ 每个迭代必须完成的、耗费管理成本的相关任务占用了短迭代的大部分时间。”这似乎又是一个团队如何选择工作方式的问题。我曾观察到挤压迭代时间长度而引 发的一个有趣结果：人们首先“发现”一些并不是非常必要的管理任务，然后就不再做它们了。最后，团队只做必要的事情，换句话说，他们去除了流程中的浪费。 实际上，这些观察让我对Jim Shore在Java Ranch上的发言持 保留意见。他认为更长的迭代给团队的压力更小，因此有经验的敏捷团队更适合用长期的迭代。我觉得我们不必在迭代规划上花费更多时间， 我认为迭代规划还可以更少些。我支持更短的迭代，如果客户可以采取拉式的方法以单件流 （single piece flow）的方式提出需求，这些迭代甚至可能逐渐消弭。
“对团队之外的资源或是人员的等待，这会使得工作的完成要跨越多个迭代。”组织上的约束造成了此类状况。如果试图采取的迭代长 度过短，以至于组织不能应 对，这样做并不合适。如果真这么做了，也就不能称之为“迭代”了，因为不可能在那样短的时间内交付工作结果，而组织也无法吸收这样的结果。要想有所进步， 我们必须识别出组织的约束。我并不认为临时的组织约束（它们是临时的，只要你真心愿意改变）就会使得短迭代不可行。简单么？没人会这么想。但如果组织的变 革很容易的话，那就没什么乐趣了，不是么？

鸟瞰、从宏观到具体、透视、焦点、视角。

观大局、断缓急、衡利弊、敢取舍。
胆子要大、方向要准、步子要稳。

http://www.axure.org/tools/tools.html

人才成长需要过程不能一蹴而就，一般过程是 先有脑 再长眼 zhang嘴之后才能长心。