印象最深的19建议之二：
7、Release early. Release often.
13、Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
第一句和移山之道中的一句有共同之处：尽量先完成一个可以运行的东西，这样可以提高团队的积极性。事实上我们团队也是这样做的，尽量在比较短的时间内把最简单的功能 实现了，在运行的过程中寻找需要增加或者需要改的地方。在平常生活中，我经常有这样的经历：实际情况与计划的相差十分大，甚至大到几乎无法再继续下去的程度。有时会在实践的过程中发现原来计划的问题就相当大，其实有着更好的方法。于是就推倒重来，最后还效果还相当好。Release early. Release often.这样会让我们更好的发现工程中的问题，有时候可能在使用或者在之前实现一些功能的时候有了更好的想法只是未能实现而已。
第二句让我想到了很多东西：计算机组成原理中讲到的指令集、电脑的设备等。指令集从开始的时候是非常少的，然后人们又添加了很多的指令，结果发现效果并不如想象中的好，精简指令集的出现更是让复杂的指令集毫无用武之地。完美并非什么都有，而是什么都不能少。包含所有必需的功能就已经相当好了，其他的功能是否完成并不是十分重要。在pairwork中，我们在一开始的时候想到了很多的问题，最后在开始写的时候才发现很多东西是不能修改的，至少和我们想象中的相差十分大。如果我们从一开始就尝试着去做，可能会完成的更好。在大一的计算机导论上，熊璋老师让我们想电脑还缺什么设备，最后评出来的最**奖中有一个是：鼠标和键盘是多余的，应该去掉！这真的是我一开始没有想到的，不过仔细想想觉得十分有道理，这不就是当今的平板吗？现在的平板已经能完成pc能完成的绝大多数功能了，甚至有的功能pc就无法完成。我们的团队目前也只是完成了一个十分简单的爬虫而已，我们一起运行这个程序的时候就在讨论什么功能是应该有的，什么功能是必需有，什么功能是可选的，然后对整个项目就有了一个更好的理解。
我认为瀑布模型适合于大公司和大项目，敏捷开发更适合相对较小的团队和项目。原因很简单，在小的团队和项目中出现预期和实际不符的可能性更大，而且一点点的灵感就可能会让这个项目的难度大大改变，无论是变难或者是变简单。而大公司和大项目则不同，他们需要考虑的东西更多更全面，面对问题宁可错杀也不能放过，将所有能想到的可能出现的问题都提前计划出来，这样的开发过程会比较平稳，更容易控制项目的进度和量化考核。在我们团队项目不能说使用了这两种方法的哪一个，但至少和敏捷开发的过程相似度更高。如果使用瀑布模型的方法，我想我们的开发过程可能会在一开始就面临着无法开始的问题。
