《火星人开发纪实：敏捷开发一千零一夜》第一个月：一个产品的诞生

（序言，之一，之二，之三，之四，之五）

 

第一个月：一个产品的诞生

 

没有国王，没有宰相，没有能讲故事的王后，也没有需求文档，开发就这样开始了：

为何不先写需求文档？

因为敏捷开发不写文档！不是的。

策划这个产品的时候，有一个大愿：就是用这个产品管理这个产品自己的研发。虽然这不等于没有“长得像”Word的文档的需求，但是我们仍然想尽量只用产品本身的功能来写需求。

所在在项目开始的那天，我们手里（确切说是脑海里）只有一个商业计划，外加这个产品的大致功能列表。

那怎么知道要开发什么功能？

         至少在开始的时候，这个问题不很重要。

         因为敏捷工具已经存在了至少10年了，里边到底应该有什么功能，在前辈们的网站上一搜，都能找到。但是，完成这些功能，乃至超越这些功能，都不是我们的目的。因为在软件界，一个已经做了10年的市场，本应是一个没有投资价值的市场。

除非，发现了全新的价值观。

一个产品是怎样诞生的？

限于商业机密，这里就不把我们当时发现的新价值观和商业策略写下来了。下面泛泛地讲一下一个产品诞生时应该发生的事情。

几乎所有产品，在开发出来前，都有类似的产品存在。

几乎所有产品，在开发出来后，都有类似的产品跟进。

几乎所有新公司，都比之前的前辈小，不可能追上前辈。

几乎所有老公司，都比之后的后辈大，很容易转向踩死后辈。

若不想被前面的骆驼拖死，又不想被后面的大象踩死，就要走一条骆驼或大象都不会走的路。这种路很少很少，以至于很多人花费很多年才能发现一条，但是幸运的是它不但被我们找到了，似乎还已经装好了路灯。

早期的开发，就是要证明这条新路可走，而不是把骆驼的路重新走一遍。所以在最一开始，我们并不需要一个完善的功能列表，而是要那个核心价值，以及一些能体现那个核心价值的功能即可。

这是新产品研发的核心原则。

那先开发什么呢？

         我们当时的选择，是“用户故事显示”功能。因为这是第一个我们会用到的功能。新增、编辑、删除，则直接在数据库里边做。由于选择了ASP.net、MVC2.0（现在用3.0）、LINQ等一票先进技术，第一周，故事就安然地呈现在屏幕上了。第一个愿望算是实现了。

又经过一个月的时间，增删改查都做好了，而且还做了一个集群编辑的界面，几十个故事一罗列，特宏伟。

这似乎预示着未来将是一帆风顺。