Active Record
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

有充分的理由你还需要决策吗？如果决策真的是一件简单，明显，不需要费脑筋权衡的事情，这个东西还能叫决策吗？

既然是必须做出的决策，你还这么选择？
而且作为一个项目自始至终都存在一个最大的决策，那就是这个项目是不是还有必要和可能进行下去。你是如何得到这个决策的。

决策并不是说不能更改，这一点是瀑布和迭代的根本区别。同时我十分不明白为什么会快速决策，痛苦执行？是因为决策有错误？你不好修改这个错误吗？你不

好快速验证你的决策吗？
缓慢决策，迅速执行？本身软件开发就是一个充满决策的权衡利弊的过程，所谓的执行其实就是以系列的决策。
什么叫乱动？没有目标，没有方法，没有步骤，就是乱动。而很多不动，往往就是因为没有目标，也不知道如何应对的方法，还没有可以操作的步骤，这本身就

是一种乱动。

那么这个价值是谁去判断的呢？

首先你的理解就有偏差。难于解决不仅仅是技术问题，还有业务流程问题，法律问题，社会反响问题等等。比如一个客户需求做一个网上支付，那么他们是不是

就有能力构建这个平台呢？这个问题，恰恰应该在早期进行决策（技术的、法律的、业务的、社会的等等多种因素的权衡）。任何一个项目都会面对一个最大的

决策，那就是这个项目是不是有必要做，是不是能够做。这个决策不仅仅是开发者面对的，而且也是甲方最关心的。

而客户价值的判断是不是就只能依靠客户自己来判断呢？显然如果客户能够明了软件的结构和技术的风险，他们对于价值的判断，同他们不明了这些风险做出的判断是不同的。因为收益总是等于收入减去支出，而难于解决的部分往往就是项目是不是可以真正的构建起来的关键。客户是希望你今天就告诉他，你的这个项目不可能成功，还是你几个月之后才告诉他？

这不是越俎代庖，而是客户协作。客户有弱点，这就如同开发者也有弱点一样，大家都要承认都不是完人，这才是合作的基础。而协作需要我们互相理解，并且

努力为对方的完成工作多做一些事情，而不是被动的坐在那里等待。因为本身agile强调的就是客户协作，而不是开发者和客户的对立。

我觉得你已经不可能提出新的观点了，散会了。

首先我们都承认如果没有充足额信息，做出的决策，无疑会带来偏差和错误的可能性大大提高。于是瀑布的做法就是，那么就等待这些信息被我们得到之后，条件成熟了，我们再做决策；要么就是做出种种长期的预测，从而进行决策。

而以敏捷为代表的迭代方法则采用有勇气的探索决策的方式。首先我们在当前迭代中安排的是对于客户最有价值的，最难于解决的，最模糊不清的，最难于取舍的部分进行开发。

而实际上迭代方式则认可即使部分输入不清晰，也可以开始行动，而等待结果出现后使用正负反馈来修正输入和输出，从而开始新一轮的循环。