从开始编程实践之前，就一直对敏捷开发，精益生产的理念特别敢兴趣，比较好的是，我个人从来对最后那个众所周知的开发速度快感兴趣，而是被敏捷方法所包含的理念所吸引，团队合作、高质量、精益求精，这些都是我自己特别感兴趣的。所以几年来，一直不断的在追求如何实现真正的敏捷，阅读了很多书籍，文章，亲自在工作中实践。2016年刚刚开始，正好结束了之前系统的开发一段时间，总结一下自己的感想和收获。
现在谈到敏捷开发，应该是混合了XP和Scrum，就像马丁福勒说的，现在已经没有人单独谈论XP，就像谈论很多其他历史上的理念，不是因为不重要了，而是变得像空气一样自然，所以没有感觉了。而现实中几乎所有人都看到了敏捷的好处，都渴望敏捷带来的优势，不谈敏捷仿佛就是异教徒；但是不幸的是，更多的听到的声音是，我多短的时间做了这么多功能，这个一定是敏捷了，看我也敏捷，这里面肯定有一部分已经像空气一样自然的敏捷，但是很多人其实完全忽略了团队才是敏捷的核心，高质量是敏捷的自然结果，而做出来的系统，代码质量本身反而是最先被牺牲的，这样的实践当然不是敏捷。
我自己的实践
代码审查
在保证代码质量上，代码审查是必不可少的，只有审查才能确保像缩进、循环嵌套层数这样的错误能够被及时纠正，通过大量的审查，至少保证代码整体水平任何时候都是团队当前能达到的最高水平；另外在团队建设，尤其是培养新人，形成新的架构的过程中，代码审查也是最高效的。
碰到的问题是，有的时候代码质量很低，几乎会整个推翻重写，效果是提高了，但是开发效率降低非常明显。
结对编程
在敏捷软件开发(原则模式与实践)中，提到了结对编程的一些意义，例如互相发现问题、提高专注度、还有编写测试
对敏捷的一些总结
高水平的团队
我心中理想的敏捷，首先要明确一点，人是核心，以人为中心去打造团队和架构，只有最顶尖的人理念相通的团队，才能最高效的去沟通，并且有绝对的执行力；就算暂时还不是顶尖的高潜力人才，也要通过团队的敏捷实践，加速新人融入团队。这种情况下的结对编程，不管是熟悉的人和不熟悉的人结对，还是测试驱动，都是达到最佳效果所必须的。
可持续的开发
敏捷一定是倡导可持续的开发，在很多地方，其实这个反而是最难做到的，不但要求开发人员的高效率，个人实践管理，技术和知识的提升还有规划和设计；在团队和企业层面上，也面临巨大挑战，通常的情况是，以快速出成果为名，在完全看不到细节的情况下，不经过设计，拍脑袋一个进度出来，然后去赶这个时间，结果可想而知，没有规划自然不知道怎么检查反馈，定出的进度和期限，必然严肃性就和指定一样，结果就是加班来修改代码；没有精心设计，最终的质量可想而知，没有想明白要做什么就开始写代码，逻辑上的正确性几乎是没有保障的，我的总结，就是看着需求文档直接写代码。
全面的自动化
从开发，测试到构建、集成、部署、运维，整个生命周期的自动化，是支持敏捷开发的基础设施，全面自动化，将开发和运维人员从各种复杂多变的环境配置迁移同步和管理中解放出来，高效率的像流水线一样让系统运转起来，开发人员和测试人员、运维人员，就可以减少很多沟通成本，还有不必要的重复劳动，专注于业务逻辑的设计、实现，把时间花在功能设计和开发上，就有了更多的时间来推进测试驱动开发。
良好的设计
无论是功能的实现、程序的质量、还是自动化测试，都离不开良好的设计，从用户故事开始，需求和代码之间还有太多的细节，有巨大的鸿沟，只有通过各种层次的设计方法，不断的进行沟通，才能够真正设计出好的程序，只有经过两好设计的程序，在测试、部署，开发和用户体验上，才可能有高质量。
沟通和协作
任何理想的想法和强大的工具，还是规范，都不可能打造出卓越的团队，不能自动完成质量的程序，只有付出努力的辛勤的不断尝试，让团队能够有效的进行写作，不断反馈，才有可能实现改善，以1+1大于2的方式去开发。
