[部分整理]
Getting Real是什么：
Getting Real 是小规模、快速、高质量的web 系统开发方法。
Getting Real追求精炼，更少的代码，更少的功能，更少的文档，更少的无所谓的东西。
Getting Real从界面开始，从世界的用户体验开始，在你的软件误入歧途之前得到正确的用户界面。
Getting Real是快速迭代和降低变化成本的方法。
Getting Real只交付客户所需要的，摈弃客户不需要的。
Getting Real是省略形式主义，而注重现实的方法。
优点：
Getting Real能够交付最好的结果，强迫你处理真正要解决的问题，而不是空想。
Getting Real注重实际的用户界面，而不是各种说明书和文档。只有真正的页面呈现出来，相关的功能才是可信的。
需要安装的软件迟早要过时的，web软件能够以天为单位持续改进。Getting Real就是来提升这类web应用的价值。
做的比对手少：
靠做得比对手少来打败对手。少而简单，少而快速变化，少而学习简单。
做的越精益改变越容易：
web应用必须是简易和低廉的。如果不能飞一样的改变，就会失败给能做到的竞争者，这就是追求小质量的原因。
质量变大的原因，长期合同、多余员工、固执决策、多余会议、笨重流程、封闭的格式、长期的计划、内部斗争
质量变小的原因，必要及时的思考、多面手的团队、更少的软件和代码、更小的特征、小规模团队、简单、开源、开放格式、开放文化
减少改变的成本：
如果改变过于昂贵，你已经死了。大团队话费数周才能改变的，对于小团队可能只要1天。低廉和迅速的改变是小团队的秘密武器。
所有的现金，所有的营销策略，所有的世界上的优秀人物，都买不到小带来的敏捷。
敏捷的法则--顺其自然，你无法预见它的出现，不可能为它做计划和时间表，但可以为它营造一个环境。
规则简单，导致的结果是美好的。规则复杂（比如国家的税法），往往导致愚蠢的结果。
把事务绑的越紧，留给创新、顺其自然的解决方式的空间就越少。不管是在需求被完全理解前就锁定了需求，还是最终用户使用系统前就设想了用户的行为场景,结果都是一样的,一个过分复杂和愚蠢的系统,而不是顺其自然而带来的清洁和优雅的系统.
保持小/保持简单/顺其自然
用3个人构建1.0
一个设计者,一个开发者,一个超人(全能),开发1.0版本. 如果不能用3个人建造第一个版本,那么你要缩减初始版本的需求.
理念才是伟大
竭尽全力将你的软件定位在一个点上. 这个理念会引导你的每个决定,不偏离航线. 理念必须简介.
先粗后细
成功和满意来自细节.永远都要从大到小的做事情.
不要把时间浪费在还未成为问题的问题上
过后才去做规模调适
先把一个伟大的产品推出,然后才担心它成功了以后该怎么办的问题.
构建一半产品,而非产品有一半缺陷
专注于真正必须的,好点子可以尽量坦白,摆出产品应该成为什么样的任何电子,然后砍掉一半. 减少功能直到只剩下最必要的功能,周而复始.
不轻易实现功能
每对一个功能说yes,你正在收养一个小孩,必须带着他通过一连串的事件(设计,实现,测试).一旦这个功能出现,你就被拖了后腿. 尽量少发布一个功能,再看客户是否愤怒的离开.
尽快推出一个真实的产品,尽快的运作起来
在不断反复中工作
别期望一开始就做的很好,让软件自然成长.你可以尽快的推出一个积极的产品,不要一味追求一出门就完美的产品.结论是由真实的世界里的反馈,真实的目标来引导你的注意重心 .
反复能解脱你
如果你知道过后总是要重来一遍,你就不需要追求一开始就达完美.
从灵感,到草稿,到原型,到代码
脑力激荡,先要有个点子. 草稿是迅速的,实用的和便宜的. 用你最熟悉的(ppt/viso/ax)构建原型. 最后才是代码实现,无设计不开发.
要帮你的客户决定一些小处的细节
比如每页显示多少条信息?是升序还是降序?如果通过"高级"选项来由用户自己配置,表面看起来你是在帮客户的忙,实际上你会让客户更忙.你要拿主意替你的客户下简单的决定.你可能下了一个不太好的决断,没关系,你可以做调整.Getting Real 说的就是灵活修改的道理.
做一个执行者
事业的成功 = 点子 * 执行
糟糕的点子=-1 ; 脆弱的点子=1 ; 普通的点子=5 ; 好点子=10 ; 伟大的点子=15 ; 超闪光的点子=20 ;
没有执行=1 ; 脆弱的执行 = 10 ; 普通的执行=100; 好的执行=1000; 伟大的执行=10000; 超强的执行 = 10万 ;
在现实中使用中测试你的软件
让真人真实的环境中使用你的软件,获取真实的数据,真实的反馈,然后在这些信息的基础上改进.
要快
决定它是否值得做,如果是,尽快去做,不需要完美,只需做下去,发布,看别人的反应.让用户的反馈来引导下一部的修补工作.
做几周甚至几个月的预期是不现实的
你无法预见那么远的将来会发生什么状况,变化是一直存在的.
小任务和时间表
给开发人员三周完成一个任务,他会拖拉2周,然后用一周完成. 给开发人员一个下午解决一个小模块,他就会有办法把它赶出来,然后进入下一个任务.
为了让事情做好,人需要不被打扰的时间
少开会
寻找和庆祝小的胜利
每天发布点什么,日拱一卒
给延期的项目添加人手只会更加拖延进度
寻找全面发展的人
选择能快速学习的多面手,而不是专攻一面的专家
选择快乐和技术水平中等的,而不是令人不满的专家. 寻找充满热情的人.
开始编程前先设计界面
设计开始于核心功能页面然后外展
这意味着,一开始忽略细枝末节的东西(导航/页脚/配色/标识),先设计页面最重要的东西.一开始就关注最重要的部分,先做必须要的,在做其他的.
不要写功能定义文档
功能定义文档不反应真实情况,一个应用只有在被构造时,被设计时,被使用时才是真实的.功能定义只是纸上谈兵. 功能定义文档只能达成虚幻的共识.功能定义文档逼迫你在拥有最少咨询时作出最重要的决定. 功能定义让你无法变通,一个功能一旦得到认同,即使在开发阶段你就意识到它是个坏主意,你也不得不照做.
让注册和注销毫不费力
不要勉强留住用户,如果他们要离开,就让他们带走在你网站上创造出来的全部内容.
规避长期合同和注册费用
谁都不喜欢长期条款. 别企图找高明的方式赚更多的钱.