Robert写了一篇很好的“Ideas 的演变 ― How to kill too many ideas ”，里面提到ideas是如何从少到多，然后又从多到少，以及如何用scrum来管理ideas。我也经历过这个少-多-少的过程，所以看了以后很有共鸣。另外我也想说一下scrum的利弊。
先说ideas的成长过程。我看来，想法数量的变化，是随着对业界的了解逐步加深而变化的。在涉足互联网之前，我因为对计算能力的追求，一度沉迷于计算机体系结构。开始对提高计算能力，只局限于使用嵌入式汇编；等对计算机的体系结构有了了解，就深入到存储体系，以及针对流水线进行优化；后来接触到超长指令计算机，以及可配置计算，终于触及了数据流计算机；这个时候回头看看，忽然发现，原来很多的性能提升，其实并没有摩尔定律这么坚定有效，可以预测。于是很多对计算能力提升的想法，就变得不那么实际了，这个时候，ideas就少了。
对web也是一样。我对web的着迷，同样是出自对数据和算法的迷恋，开始接触web的时候，想法还不多，等对行业有了了解，想法就喷涌而出，但是像Robert说的，等到用自己的资源这把尺子去衡量的时候，实际的想法其实只有那么几个。这个时候，也才真正理解了业界前辈的叮嘱：idea is cheap。也就是到了这个时候，才认真的翻检所剩无几的几个想法，挑一个自己最有热情的，埋头做下去。这个时候，别人问起我有什么idea，我一般也说不出什么，倒不是不想分享，主要原因，是这个时候已经不是虚无缥缈的想法了，而是一个可以执行的行动计划，只需要机械的去执行，中间按计划修正目标就是了。
再说Scrum。Robert提到，把ideas按照和目标的轻重缓急，以及资源是否充足来排序，把不重要的ideas放到backlog里面。这个就是scrum的方法。这个我完全同意。我这里想说一下scrum以及敏捷开发的一些体会。
Scrum和敏捷开发的好处是灵活，但是也要注意，任何形式都是有优缺点的。Scrum的一个问题，就是很容易不停的因为目标变化而重新设计，最终导致不能交付。所以在Scrum的培训里面，会着重提出：要把系统进行“垂直”分割，做成有相对独立功能的，可以使用的模块，尽早完成某些分割，提交用户使用。这个原则放在典型的三段论web应用里面，就是要交付一个包括数据源，商业逻辑和web界面的完整子系统，这个子系统因为资源不足，功能不全，但是交付的功能可以供用户使用。这样的好处很多：可以快速开发，迅速获得用户，更重要的 - 获得用户反馈，维系团队斗志，探索新的方向等等。
当然这种垂直划分，也不是绝对的。因为应用不同，各个模块的份额和相互关系不同，机械的垂直划分，容易陷入困境。事实上，用户未必是公司或者团队以外的人，如果把团队内部的不同分工也当成客户，那么对应用的划分，就可以不那么机械了。