自1999年起我就开始发掘一些科技公司，并帮助它们运营。我最近的一个公司是fabulis.com。下面是从干这行中得到的57条经验。我可以列出更多，但恐怕会令你厌烦。

1.做你个人有热情的事情。你是你自己最好的民意代表。

2.用户体验很重要。大多数产品做不到这些是因为用户弄不清怎样才能从这些产品中获得好处。很多产品做不到这些是因为过于复杂。

3.要懂技术。你不必去写代码，但你必须能理解它是如何被开发出来的，如何工作的。

4.创业公司的CEO必须，必须，必须担任产品经理。他/她必须对产品拥有功能性的用户体验。

5.对功能进行主次分级。不会有两个等同的功能。你不可能把它们一次全实现。要进行兵力优化。

6.使用缺陷跟踪系统，虔诚的用它来管理你的开发活动。

7.及时发布。除非真正的用户接触到你的产品并给予反馈，你永远都不会知道你的产品是好是坏。

8.尽快发布，经常发布。不要惦记着再增加一些其它功能。只要能达到可以用来收集用户反馈的最小功能集合，那就发布它。收集反馈信息，反复这个过程，发布下一个版本、下一个版本，越快越好。如果你3个月才发布出第一版面向用户的产品，你拖延的太久了。如果3个星期才发布一次更新包，你拖延的太久了。如果不能一周几次，那每周发布一次更新。每3周发布一次重大更新。

9.唯一有意义的事是你的产品的好坏。其它的都是鸡毛蒜皮。

10.对你的产品好坏的唯一判定来自于有多少用户使用它。

11.因此(补充第9、10条):产品初期决定你将来是否能成功的关键因素是你的产品的吸附力。把你主要的时间花在如何在你早期的受众中培养吸附力。如果你能启动这个过程，雪球会越滚越大。

12.如果你最初设想的50%后来证明可行有效，那你已经相当成功了。尽可能的听取你的用户。

13.不要依赖于你的用户代表去告诉你如何发展。用户代表可以告诉你如何定位，帮助你明确潜在的需要打磨的核心内容，但你仍然需要有能力汇总消化这些信息，知道哪里去找到你的用户。

14.大多数人真正主要使用的也就是5～7种服务。如果你想做一个重要的产品，成为一个大公司，你需要能清楚如何成为这5～7种服务中的一种，这样去让用户为你着迷，俘获他们的热情和信任。你需要给你的用户一个好的能够让他们在你的服务上花时间的理由。

15.尝试追逐正在进行的潮流，开创你自己的市场。如果可以的话，捕捉刚刚出现的趋势苗头，驾驭它。

16.找个“引路人”。有些人以前做过这些 — 融资，贸易，给创业公司工作。给这个人你公司的1%～2%作为报酬换取他的时间。借助他们打开未来市场的大门。把他当作企业发展的宣传媒介。不要让委员会去做这种事情。顾问部从来就没有提供过有用的东西。找到这样的人，把他们当作你的引路人，依靠他们。

17.在你的项目上尽量找最棒的人一起工作，不管他在什么地方。

18.有可能的话最好设立分部，但这需要你穿梭在几个地区之间使他们正常运作。在线合作最少3～4周一次，这意味着你需要几乎每月都要在这几个地方旅行一次。

19.跟你喜欢相处的人一起工作。这不是说你可以跟你不喜欢的人不合。

20.要像信赖你的家人一样信赖跟你一起工作的人。

22.摆放你的办公桌，使你能看到你的同伴，他能看到你。如果你们每天都没有兴趣看到对方，那你们选错了一起工作的人。

23.使用一个类似Yammer的内部分享工具，分享你们正在开发的东西。对很多人(特别是开发人员)来说，更新状态信息要比发送邮件更容易。

24.在团队中使用一个文件共享服务系统，例如basecamp。这对所有人都很重要，它可以记录所有的文件动态并发送到你的邮箱里。basecamp使你有了历史存档，有了一个集中式数据文档库。

25.认清楚自己真正擅长的是什么，把自己的精力主要放在这些事情上。让其他的人做其他的事情。

26.让你的周围围绕着能够弥补你的缺陷的人。让他们做他们擅长的事。你不要去做他们的事。

27.跟在某些方面比你更聪明的人一起工作。

28.跟那些会和你争论，反对你的人一起工作。

29.白天地狱式的奋斗工作，晚上回到家和家人相亲相爱。

30.跟那些热衷于解决你正要解决的某些特定问题的人一起工作。光热情于发展公司业务还不够；还要热情于你的客户，热情于解决他们的问题。

31.促使你周围的人像你一样用心。

32.忠诚。培养和引导人们，而不是鼓噪他们。

33.你永远不会像你想象的那么正确。

34.每周至少去健身房或跑步4次，要想保持你的思维的体型，先保持你身体的体型。

35.不要在飞机上喝饮料，除非你的航程超过8小时。那会害了你，而且浪费你的时间。

36.你选择的投资者应该是你喜欢和他一起工作的，可以做朋友的，能够得到忠告的人。

37.不要按价值来选择投资者。淡化一些这方面的色彩，从长远看，不会有坏处，只要选对人。

38.创业初期募集资金越少越好。强迫自己进行严格的预算，认真使用每一块钱，就好象是最后一块钱。

39.一旦有了一些发展动力，募集一些多于你的需要量的资金，但你要清楚它们都将做什么。这有些技巧。不要在募捐活动上吝啬。

40.每分钱都要花的小心谨慎，就像那是你最后一分钱。

41.清楚你要做什么样的公司。像Google和Facebook这样的公司没几个。对于你的公司，也许1千万的回报额已经很好，也许2千万，也许一亿，也许什么都没有。计划好你要做什么样的工作。不要去做做不到的事情。看清楚你口袋里有多少钱，能做什么事情，两年赚取2千万期望值的20%要比5年赚取1亿期望值的3%要好。

42.跟41条有关，明白你的业务是否适合接受风险投资。风险投资一般会期望10倍的回报率。也就是说，你接受5百万，那就要提供5千万的回报。1千万的投资 = 1亿的目标。在签署接受风险资金时一定要想清楚他们在你身上期望的是什么。

43.把你的个人公司发展目标和你的投资者的目标保持一致。有目标公司才能成功。投资者没有魔力让事业成功。同样他们也没魔力让CEO用心。

44.会议一般来说都是在浪费时间。

45.微笑。大笑。穿有趣的袜子。我穿有趣的袜子，用来提醒我不要满足于平淡，要有创新。

46.做事情时，做任何事情时，都不要让你看起来像个机器人。让人们知道真实的你。

47.正视你的问题，化劣势为优势。

48.任何地方都穿着你公司的T恤衫。

49.成立自己的客户服务。

50.要会讲故事。

51.别说谎。永远不要。

52.在你周围的人身上寻找灵感。

53.每天都保持快乐。如果不高兴，那就别做。没人要你做。

54.销售中的那句话说的很对，你的成绩只跟最近的一次销售有关系。

55.犯错误，但要吸取教训。我犯了无数错误。

56.成熟，但不要长大。

57.永不放弃。

自从编程界的领袖们发表旨在通过接受需求变更，加强同用户合作，缩短软件提交周期来改善软件开发过程的敏捷软件开发宣言至今已近10年之久了。

敏捷宣言制定2001年2月，当时一群软件开发者聚集在犹他州，他们希望能找到一种可以替代那些由文档驱动的、“重型”的软件开发模式(如当时的被当作金牌标准的瀑布模型方法)的新方法。

尽管早在犹他州会议之前，敏捷开发方法就已经出现，但这次会议却被当作这种方法论推广进程中的一次分水岭事件。十年以来，敏捷开发已被众所周知，很多软件公司采纳了Scrum和XP(极限编程)等敏捷开发实施方案。尽管还存在着不可预知的问题，敏捷方法领域里的专家都认为，总的来说，敏捷方法的实施会给软件开发活动带来益处。

“我说过，我们改变了这个行业，”一位宣言的签署者、目前在Tektronix工作的Ward Cunningham这样说。由于敏捷的出现，关于计算机编程的没落和编程危机的讨论逐渐消失，他说：“我们已经再也听不到人们谈论这个话题了。”

敏捷宣言比实际预期要成功的多，IBM Rational部门的首席敏捷和Lean方法论导师Scott Ambler这样说。

“它对我们整个行业有着重大的影响，”Ambler说。“如今你已经很难找到有不想去试试敏捷方法的人了。跟传统的开发方法相比，人们希望使用敏捷开发和迭代开发来使项目获得成功的愿望要强烈的多。“

但是Kent Beck，同样也是一位宣言的签署者，并且是XP的创始人，在宣言签署的10年后，对敏捷开发所带来的好处去并不是那么认可：“对于这个问题我没有一个几句话的答案。”

“敏捷开发是让人们更加认真仔细的思考如何开发软件，”Beck说。然而，并不是每个人都在敏捷开发上走对了路，他提示说。“仍然有很多人喜欢把读来的一些建议指导应用到他们的项目上，其实那些根本不是所谓的敏捷开发，“Beck说。

敏捷开发的条件

敏捷开发很难学，Cunningham说；”在你能够使用这套方法论前你必须掌握精通各种技巧。“

敏捷开发需要你扎实的技术功底，Cunningham强调道。”有很多人闯进这个领域后发现编程枯燥乏味，不再想学。“Cunningham说:”你要有兴趣做它，想把它做好，这样才有助于你成功。“

“来自企业组织的阻碍会在敏捷方法论的实施过程中显现出来。敏捷开发鼓励更加频繁的交付软件，鼓励把事情分解成小块，而不是把整个项目看成一块。”Skip Angel — 工作于BigVisible Solutions的一位敏捷顾问这样说。”我想这些对于一些企业是个挑战，这些企业的运营方式并不能使他们可以做敏捷的交付。“

项目在一些耗时的过程中很可能会陷入泥潭，Angel补充道，开发人员应该使用持续集成来避免这种瓶颈。

敏捷开发不是银弹，Ian McLeod–做应用软件生命周期管理工具的SmartBear Software公司的执行副总裁这样说。”你需要把事情做对 … 你的敏捷开发可能做的很失败，“ 他说。

Beck回忆起1997年用敏捷开发方法成功的开发出JUnit Java单元测试工具。他们团队使用短周期迭代，大量的单元测试，紧密和客户进行沟通。

”它使我们开发的更快，使我们更好的清楚需要去做的事情，“Wade Weston — 开发标准化交流系统的AttainResponse公司的CEO 这样说。”AttainResponse每周进行开发工作的sprints。我们的sprints周期很短，我们把精力高度的集中于本周要做的工作。“Weston说。

“‘可是让每个人都能上手仍然是个问题，’我的一个兄弟经常对我这样说，他喜欢更详细明确的需求。我一直告诉他，我们之所以开发的这么快，就是因为我们没有明确的需求，”Weston说。等待核心的需求说明基本上是浪费时间。他补充道。

”有些时候，一些开发人员说他们在做敏捷开发，可事实他们根本不是，“Damon Poole — 提供敏捷开发项目管理软件的AccuRev公司的CTO 这样说。“有些开发人员2周都不能把开发的东西(或“故事”)完整的编译集成，”他说。“如果你真的是做敏捷开发，那2周的时间足够把用户故事发布了。”Poole说。

敏捷编程的多种实施方案

Scrum 和 XP 是两个最具有代表性的敏捷方法论。Beck把XP描述为更注重开发的技术方面的方法。“XP说的更多的是告诉程序员应该做什么，相对比，Scrum是一种项目管理方法论”他说。

”XP的与众不同之处在于它是一种体系，而不是一种解决方案。“Cunningham — 一位推动XP发展的贡献者这样说。”它是一种有计划的编程方式。“

Scrum专注于如何管理和交付你的产品，而XP却是考究于如何去做你的工作，Angel说。

Poole指出，”很明显Scrum和XP是目前两种主要的方法论，你经常能看到Scrum团队会采纳XP技巧，而XP团队也会使用Scrum概念。“

另外一种敏捷方法论是Kanban，它起源于制造业生产流程和Lean软件开发概念，Poole说。Kanban里的约束很少，它关注于如何使价值反馈给客户的过程，他解释说。Lean关注于组织效能优化，价值优化，降低浪费，确保正确的好的生产过程，Angel补充说。

RUP(Rational Unified Process)也被人们称作为一种敏捷方法，尽管这种说法有待商榷，McLeod说。RUP的特点是有一大堆的文档，它可能是针对敏捷方法中的各个步骤的，他解释说。RUP可以是一种敏捷方法，Ambler说：”RUP给予我们的是流程上的架构准则。它完全依赖于你是如何制定的。“

Ambler同时提到了DSDM — Dynamic Systems Development Method — 一个敏捷领域里的失败的案例。SDSM有点像RAD [rapid application development]，但在里面增加了一下额外的处理。RAD跟敏捷开发的不同之处在于它只关注开发迭代，而不考虑促进合作，他指出。

McLeod认为各种敏捷方法论和迭代开发过程很相似。”它们之间没有太多的区别，“他说。

“敏捷”这个术语，Cunnigham说，是在犹他州会议上选出的一个词，人们通常把它引用为”轻量级“的方法，他回忆到。但”轻量级“这个词从表面意思上看也承载着一些负面的含义，他说。