首先说一下对敏捷开发的印象。现在的软件开发很重视前期设计（其实这也是人们吃够了无设计的苦总结出来的），并在这上面投入了很长的时间。敏捷性开发则忽视了这些前期对需求的理解和设计，直接针对最终的需求把功能通过一次次的迭代过程逐步实现。那为什么最早期人们毫无计划开发出的代码就是一坨屎而敏捷性开发开发出来的东西就不一定是呢？是因为人们采用稍微聪明但是也很笨的招数，我开发一点我就进行测试，其他功能回头再说，这样保证开发出来的东西都是有用并且有意义的，这样就避免了开发出一坨屎。而很多开发人员搞的设计，则是希望通过前期预见和规划避免自己的东西变成一坨屎。
所以作者一开篇的一个小标题就是“从无到繁重再到简洁”。这是有道理的，但是这个简洁我认为也绝不是最简洁，而是相对繁重的简洁。假如‘无’能开发出来的话，毫无疑问，‘无’是最简洁的。敏捷性开发的方法迭代。怎么说呢，我感觉这其实是一种很笨的方法，本着一个萝卜一个坑的原则，我写一个功能，我就对项目进行一遍最终的调试，然后确定实现了这个功能。所以说这个方法也就是相较于漫无目的的进行开发相对较优，但绝不能说是最优，因为这差不多耗费了最多的工作量。
并且作者得到了四条结论。1.在软件开发中，具体建造费用非常低，几可忽略不计。2.软件开发中所有工作是设计，因此需要富有创造性的才智之士。3.创造性的过程是不太容易计划的，因此，可预见性是个不可能达到的目标。4.我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉，因为它们是不同类型的活动，因此需要不同的过程。
那我来评价一下这些结论，未必是按照顺序评价。首先说预见性是不可能的，我觉得这句话过了，过于强调创造性。那如果真的那么有创造性，又为何要去适应别人的需求，而不是想乔布斯一样给别人创造需求呢？预见性的不容易，只是因为需求的变化是不可预期的，但是只要定期与客户商讨需求，那么在需求已知的情况下你还不知道自己大概会怎样完成工程的话是不是说你的能力不足呢？对于第四条我倒是满认同的，对传统方法保持足够的警觉，这是不同的过程。过度的计划等于没有计划，实践才是检验真理的标准。对于第二条来说，需要富有创造性的才智之士，不敢苟同。不管怎么说，我们写出来的代码都是为了某一个目标的，富有创造性对这有帮助吗？对于第一条，那就更不能认同了。具体建造费用很低，即可忽略不计。那如果建造费用真的如此低的话，那为什么我们不先开发出一个简易的模型出来，然后客户说怎么改，我们就怎么改。反正建造费用低啊，改也好改。这样是不是效率更高。
敏捷性开发需要适应性的客户。我只能说，这是一个可行的办法，但绝不会是最优的办法。因为这相当于把开发人员的工作交由客户去做，甚至于我需要从我的公司中抽出一名业务熟练，业务目标明确的工作人员专门配合软件开发者的工作。也就是说我除了花费雇佣你们的钱以外还额外支出了一笔费用，我所得到的仅仅是与预计目标差不多的一个东西。从外行的角度来看，这显然是不划算的。
敏捷性开发提到不能把人看成一种资源，他们具有不同的角色，如一个分析员，一些程序员，测试员及一个管理人员。我不知道老师的意思是不是提倡敏捷开发这种方式，在我们实际的team中，我们恰恰是按照传统模式来做的。
最后总结一下敏捷开发需要的东西，一个是超配合你的客户，另一个是每个组员都超高素质的团队。（话说这两点都满足的时候采用什么方式又有什么关系呢）
我对敏捷开发的看法。软件设计现在还是一个无根之木，找不到一个立足点，一个理论支撑点。所以现在人们最求的都是与其最优，不如最实在，就比如敏捷开发，我就开发一点测试一点，这样肯定没错。但这也好比我们编程序的时候不但用了暴力搜索还得回溯，一看就是一个低效能的一个方法。所以我觉得敏捷开发和传统开发都具有各自的有点，但由于人并不善于取一个中间值，用一种中间的方式来进行问题，所以两方的优点无法结合在一起，反倒是人们觉得要做就做到底更简单一些，由此也就有了xp之类的东西。但是我们开发过的东西太少了，无论是哪种开发过程都是值得我们实践的。并且对我们来说，建造费用可不低啊，比设计测试神马的都要大多了。同时我也期待着一些根本性方法的突破，而不是像现在一样，只能停留在口水战，最核心的要求还是高素质的人才。