最近读完敏捷著作中的经典《敏捷软件开发》，原名是Agile Software Development，感觉和以前看的有关软件工程的书都有些不同。这本书充分体现作者真正将软件开发过程管理视为一种可工程化的技术，书中的严谨与幽默，与国内要么千篇一律没有个人思考，要么完全是个人感悟无法形成理论依据，有质的区别。作者的认真严谨确实给我留下挺深的印象。这已不仅仅是思考，而是不断的完善，是一种希望最终形成体系的努力。

这里摘出整本书中个人感觉有道理的段落，也做些个人感悟，留待以后观用。

第0章
沟通的成功依赖于发送者和接受者有可以引用的共享体验（shared experience）
项目的任务不是努力达到完全的沟通，而是管理我们沟通的不完全性
三个层次——following，detaching，fluent
：书中最有趣的部分就是：那么，明天我做什么

第1章 创造和沟通的合作博弈
1.1 软件与诗歌：很贴切的比喻
想象一下，把50个人聚在一起，在有限的成本与时间内编写2万行的叙事诗
1.2软件是创造和沟通的合作博弈。
沟通的效果比沟通的形式更重要
模型就像任何一种沟通一样，只要它能使下一个人继续他的工作，这个模型就足够了。
应当对团队的工作产品进行度量的是它们在向目标组传达信息方面的充足性。
1.3
合作博弈的原则
软件开发是一个（有资源限制的）创造和沟通的合作博弈。博弈的首要目标是交付有用的，可工作的软件。次要目标，即博弈的沉淀，是为下一轮博弈做好准备。下一轮博弈可能更改或替换系统，也可能是创建一个相关的系统。
1.3.1
程序员只喜欢交流那些他们喜欢交流的事情。
在软件开发的课程表中，大学应该增加一些包含沟通密集（communication-intensive）课程。
1.3.3标志物与道具
中间工作产品成为我们用于反思的提醒物。他们提供了共享体验，以此来指向或者作为新想法的支持结构。
1.3.5
对于中间工作产品，需要进行的度量只有充分度（sufficiency）：它是否足以提醒相关的小组或足以激发相关小组的灵感。
1.4这对我意味着什么
观察：
设计团队的人如何构建他们的理论
进行最后调试或程序维护的人如何构建他们的理论
与前者相比较，后者的可用信息的不同
他们不同的理论如何在产生的程序中导致不同
你如何理解你的问题随着时间的变化而发生的变化，这些变化又是如何改变你对于所要构建的解决方案的理解的
察看你的项目，然后提问：
参与这一博弈的都有谁？
哪些人在进行有限的，追求目标的团队博弈
哪些人反而在进行他们自己的无限博弈
你的团队伙伴在什么时候一起创造，以及他们在什么时候留下一些踪迹好让其他人知道他们进行到了哪一步？连续五个工作日仔细观察这些事，注意他们如何一步一步进行。
把项目决策看作是博弈中的步骤。把它想象成一种不同的博弈，穿越沼泽：
回忆一下项目的准备活动，它们就像一个对沼泽发起进攻的初始计划一样。当出现了关于这片沼泽的特点和团队的能力的新信息时，计划就要改变。
观察每个人的贡献：探查更深或更安全的点，为了让其他人能穿越沼泽而制作地图或开辟道路。