Agile Software Development

导师让学习敏捷编程概念，并指定了《Agile Software Development》这本书作为学习教材，每天固定学习1到2个小时。
首先目前的学习方法是非常肯定的，每天学习固定的内容，然后晚上下班之后大家坐在一起交流下学习的感悟。
今天看了前言和第一章的部分内容。给我感悟最深的有三点：
一：在项目中对于人的肯定：
   在现在的工作中，我们很多的公司很多项目组往往更加看重于流程，我想主旨在就是建立铁打的营盘从而尽量降低流水的兵的影响。这无可厚非，本来IT就是个人力流动相对频繁的行业，所以流程的完善和细化有助于公司保持持续的发展。然后在敏捷项目开发中，更多的是强调人的作用，给予参与者足够的支持和信任，提供符合参与者个人品味的开发环境等等，从而最大限度的激发参与者的能够，进而促进项目的开展。

二：不到万不得已，不要写文档；
   这个给我的印象也非常之深。因为目前的公司改革中很重要的就是强调文档的重要性，要求大家凡事要落实到文档。而这里却强调不到万不得已，不要写文档。首先因为写文档的工作量巨大，如果要写必然要有格式，然后在梳理内容，往往简单的东西也要写半天；其次强调不更新的文档更危险，这点的确很重要，我们在完成文档后往往忽略对其更新，而且我们的项目有时候又不规范，代码编写者对代码享有更新权力，在做更新后如果没有更新相应的文档，那文档就变成了骗局，你从文档中获取到的反而是错误的内容；然后就是让代码尽量的自解释，这点我觉得也非常重要，让代码本身具有自解释性，可以通过看代码了解功能的细节远远要比看文档更直接有效，因为代码是不具有二义性的。

   为了少些文档，所以只是宏观的设计内容才落实到文档，尽量忽略细节内容的文档；同时项目内部人员通过更多的面对面的沟通来达到知识的传递而非看文档。

三：持续交付：
   这点现在应用的比较广泛了，包括Daily Build就是非常典型的应用。这是在项目内部的，而对于客户方面，就是能够以较短的周期持续的提供可运行的程序给客户试用，同时尽量多的接收到客户的反馈然后根据反馈来调整自己的产品。这样可以使项目更贴合客户的使用需求，

   

   现在只看了一点儿，记录下想法，后续深入学习后再更新