《敏捷软件开发》书评

敏捷宣言

个人和交互胜过过程和工具可工作的软件胜过全面的文档客户的协作胜过合同协商对于变更的响应胜过遵循计划频繁的交付可工作的软件欢迎变动的需求【很惭愧】业务人员和开发人员每天工作在一起【不是不想,...】使用有主动性的人来组建团队。给他们所需的环境和支持，信任他们能够完成工作【阿喀琉斯之踵】不断的追求技术上卓越和优秀的设计

守破离是这本书的精髓

不知道是翻译问题，还是书的内容的确比较高深，初翻时，感觉不是一般的晦涩。比如将“博弈”的概念用在软件开发上，让我着实迷惘了一阵子，这个概念一般还是用在兵法谋略上的。本书提出的一个核心理念是：“软件开发是共同创建和沟通的过程”，因此本书的全部内容，都是基于如何创建和沟通来展开的。作者开头就阐明一个基本观点，沟通的不可能性。这意味着在传统软件开发过程中，我们以往靠严谨的结构化文档来进行充分沟通是严重不靠谱的。而失效的沟通技术，则会导致计划、设计、编程、测试及发布各环节衔接的问题，过程出现了问题，则以靠过程产生的软件自然也好不了。书中紧接着提出了解决的方式，这个答案里既有关于个人成功和失败习惯的方面，也有团队之间信息辐射的方面。作者认为，只要个人保持成功的习惯，并将整个团队放置在一起工作，就能达到良好沟通的目的。沟通只是软件开发的问题之一，问题之二是创建问题。这个问题实际上是由创建过程引起的，而创建过程又是由方法集来支持的。作者在讲解方法集的时候，充分印证着自己守破离的观点，即任何方法集都不是唯一正确的，所谓瀑布发和敏捷谁更正确其实是个伪命题，凡是纠结于这的同学，显然是并不了解方法集只是解决特定问题的过程集合这一基本事实。我对敏捷方法集的看法是，它其实将瀑布法中的顺序阶段，打包到几个迭代的过程中而已，当然在每个迭代过程中都会对顺序阶段做调整，比如将严格的顺序执行变化为并行执行等。我对书中的并行观点很倾佩，利用这个观点，我们很容易将自己的过程改造的更敏捷，而无需担心自己变成另一个先烈。因为书还没看完，所以不能完整的领略作者关于敏捷的所有核心要义，但我希望在今后的阅读中，能够明白如何通过人+方法集的方式，应用到软件产品的管理上，而不仅仅是软件产品的研发上。希望能通过领悟作者的精神，利用举一反三的技术，找到一个比较正确的答案来。出于对守破离的致敬，希望终有一天，我能将这本书付之一炬：）

敏捷运动——被阉割的革命

本书是一本非常好的学习敏捷开发方法的书。书中列举了大量的事实，详细的介绍了如何在软件开发过程中实现敏捷方法，作者对敏捷的一些感悟等等。如果对敏捷方法没有深刻的认识，可以在看过敏捷宣言以后，仔细研读这本书，作为对敏捷方法的入门。我在这里不想过多的来吹捧这本书的优点，我想谈一下就这本书透露出来的敏捷运动的不足。我第一次了解敏捷大约是在4年以前，最开始只是了解了敏捷宣言，后来又了解了敏捷的前身—XP。本来我对敏捷运动报着很大的希望，因为敏捷宣言里面提到了一些在传统软件开发方法中没有注意到的思想，这些思想是真的可以为软件开发方法带来革命。而事情发展到今天，这场革命在各种因素的综合作用下，事实上已经失败了。现在大多数人提到敏捷（包括很多资深的敏捷运动成员），都认为敏捷仅仅只是对传统软件开发方法的改良，而非革命，它仅仅只是把传统软件开发过程中好的元素综合起来了而已，而最开始，事实并非如此。虽然敏捷宣言最开始有12条，但是事实上其中只有三条是核心“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意”“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作”“即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势”。这3条意味着，和传统开发方法相比，敏捷开发方法是一种用户驱动的开发方法，它事实上是通过用户最快速度的使用，让用户明白计算机可以为他做什么，然后再由用户重组他对目标解决方案的设计。进而，为了快速的达到这一目标，其他的方法最大限度的加快了软件开发速度。从软件工程的发展趋势上来看，敏捷方法将原来用户和软件开发人员相对剥离的状况转变为一种紧密结合，将软件开发过程看做是双方之间的协作而非双方之间的买卖。是的，这本来是一个革命性的思想，这个思想甚至意味着全行业对软件需求认识上的改变。然而最终，什么变化都没有发生，敏捷打开了一扇大门，又最终把它关上了。现在任何一个组织都宣称自己是敏捷的，甚至连敏捷本来的死对头UP也宣称自己是敏捷的，就连敏捷自己，也在实践中逐渐迷失了自己最重要的特性，最终泯然众人了。拿IBM的Rational平台来说（09年《程序员》3月刊28页），其宣称自己是敏捷的，甚至宣称自己是大规模敏捷的，但是就其介绍，我们丝毫看不出这个敏捷和紧密结合用户的思想有什么关系，而此所谓的“敏捷方法”，事实上是通过提供统一平台，提高实现级别来实现的，这实质上是一种减小含混性的方法，而并非敏捷宣言的初衷。这本身是两种完全不同的思想，却在他们的介绍下被莫名其妙的混在了一起。敏捷运动为什么失败了？是因为在最初其革命性太强了。敏捷方法一出，号称颠覆了传统的所有软件开发方法，其宣称的不写文档也确实存在大量拥护者。但其方法本身只是一个从实践走过来的方法，其缺乏扎实的理论根基和与其配套的完整理论体系（比如一种更好的客户开发人员的交流方法等）。相比于早期的UML，先从图形化入手，提供一套便于传统软件开发方法上手的工具，进而逐步向UP甚至模型转换方向发展这种稳定的步伐，敏捷一出来就锋芒壁炉，结果在锋芒中迷失。甚至直到今天，敏捷方法也没有拿出一个靠得住的需求获取方法，而这可是最初12条宣言中最看家的本领。敏捷失败了，未来会怎么样？从软件工程发展的历史上来看，从最初的自己自足，到混乱型，到瀑布模型，到原型法，到迭代方法，敏捷方法等等，其本质沿着混乱，到流水线，到一次迭代，到多次迭代，到用户主导，将来必然会更加趋向于协同合作，而非独立自治。而在实现级别上，由最开始的机器码，到汇编，C，面向对象语言，动态语言，SOA，甚至未来可能到达的模型转化，其实现的级别越来越高。未来的软件开发方法，必然更加强调用户主导，快速响应，协同工作，甚至随需而变，而我们的精力必然随着实现级别的拔高，不断的向更高层次的目标转移，不断的去挖掘用户的潜在目标，形成完整的软件服务链。敏捷虽然失败了，但是下一次变革必然带来更强烈的交互协同，这个大趋势是不会变的，必然会存在着一天，用户和开发者将摆脱当前这种被动的交流状态，转变为相互主动的交流，共同完成对目标的优化。