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