观念

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

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

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

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

响应变化胜过遵循计划；

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

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

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

沟通

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

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

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

wiki写多了，也可以让你的工作变得轻松。比方同事向你请教问题时，你可以给他一个链接“看wiki去吧，这里面非常具体”，那感觉。非常棒不是？

关于wiki的优点，之前有过具体讨论, 传送门：

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

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

你这一天做了什么？

明天打算做什么？

遇到了什么问题？

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

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

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

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

考虑到你写的代码就是给别人看的，在你会更加细致的编写并合理的加入凝视；

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

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

争取尽早的见到终于的客户，假设有条件，在每次迭代完毕之后。给用户演示一下我们的模型，这样比文字上的沟通更为直观。也更easy发现客户真正的需求。

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

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

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

这里提倡持续集成。频繁的集成。

我们当天编写完代码。提交到版本号库上；系统能将这块代码集成到我们的整个系统中，然后跑单元測试用例和集成用例。完毕之后给出具体的报告；

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

本书思维导图读书笔记:

下载：()

转载于:https://www.cnblogs.com/yfceshi/p/6873893.html

你可能感兴趣的文章