观念

我们首先从观念来看，提观念当然少不了敏捷宣言：

个体和交互胜过过程和工具；

可工作的软件胜过面面俱到的文档；

客户的协作胜过合同谈判。

响应变化胜过遵循计划；

敏捷开发改变了整个开发流程；

传统的瀑布模型是重设计，资深的架构设计师将设计事无巨细的做出来，然后让小兵来开发；在面对需求变更时，通常很无力；

敏捷反对通过设计来操纵开发，将重设计改为设计指导；

沟通

沟通是敏捷中最核心的部分，其中涉及到团队沟通、与客户的沟通。

要努力成为团队中的一个指导者，分享你的知识。在分享知识前，你有一个准备的过程，你需要把你知道的知识有条理讲给人家听，让他人听懂，你这个准备和讲解的过程对你来一种提升，之前一知半解的问题，在讲给他人听的过程，会理解透彻。

知识分享的过程不仅仅是通过讲解的方式，文字分享也是重要的一面；这里就提到了wiki的重要性，把你的知识纳入wiki，收益的就不仅仅是目前的团队成员，更有未来的团队，这样你的知识得到了传承，呵，多么了不起；

wiki写多了，也能够让你的工作变得轻松，比如同事向你请教问题时，你可以给他一个链接“看wiki去吧，这里面很详细”，那感觉，很棒不是？

关于wiki的好处，之前有过详细讨论, 传送门：公司内部wiki，你建立了么？

为了达到有效沟通，敏捷提出了两个有趣的会议：

第一个是每日站会，这是敏捷中必不可少的一个会议，就是每天15分钟出来，进行讨论，回答3个问题：

你这一天做了什么？

明天打算做什么？

遇到了什么问题？

这个站会上不是解决问题的场所，你只是提出你所遇到的问题，解决问题放在会后进行。

第二个是午餐会议，就是大伙很随意的吃饭聊天，可由特定的一个人，分享一些书籍。当然可以是非技术领域；当然这也是一个分享的过程，能够提升团队的凝聚力。

除了我们语言交流外，代码也是用来沟通的，要记住代码阅读的次数要远大于大于代码输写的字数。敏捷强调代码集体所有制，就是说，代码是大家共同所有，而不是某一个人精通某一块。

实现代码集体所有制的方法，是采用团队任务轮换；不再是某一个人，一直在做某一个特定的小领域；这样，能保证大家对整个项目都有所了解。

考虑到你写的代码就是给别人看的，在你会更加仔细的编写并合理的添加注释；

与客户沟通时要保证沟通工具的简洁易懂，比如我们日常使用的word和xls表格方式，不要使用过于专业的工具或术语；

当业务上的模糊的地方时，需要由客户来做决定，倾听客户的声音。不用担心客户的决定导致项目需求的变更，敏捷就是来适应变更的；

争取尽早的见到最终的客户，如果有条件，在每次迭代完成之后，给用户演示一下我们的模型，这样比文字上的沟通更为直观，也更容易发现客户真正的需求；

当客户发现这东西和他想要的不一样时，要快速的响应客户需求，尽快地把它放到下一个迭代中来。

讲编码最主要是第六章所讲的内容，其中谈到的规范和技巧不仅仅是适用敏捷。

比如要合理的使用技术，不能过份迷恋模式。如果为了模式而模式，反倒把系统搞复杂了，就得不偿失了。

这里提倡持续集成，频繁的集成。我们当天编写完代码，提交到版本库上；系统能将这块代码集成到我们的整个系统中，然后跑单元测试用例和集成用例，完成之后给出详细的报告；

可以看出，实现持续集成的前提是有一个自动化部署的环境，能让我们在提交代码后实现自动化部署集成，轻松增量式编程。

本书思维导图读书笔记: