高效敏捷之道
前言
本人从15年就开始接触敏捷，并参加了李国彪老师的培训课程，李国彪是当年国内能公开培训敏捷资格的几个老师之一，课程的内容一直受用到现在，一提到敏捷 很多人都有误解，觉得敏捷就意味着快，意味着提前交付，所以导致有种错觉，不管干什么都很着急，导致开发逐渐抵触，觉得敏捷就是在压榨自己，其实不是的， 很多时候是我们过于关注某些细节导致的，这篇文章的内容是来自高磊华大佬分析的电子书，也许会解答一些问题，我用不到一天的时间通读一下，然后总结了这篇文章 用书中的话开篇，敏捷不是目的，而是手段，只要某个手段适合某个场景，有助于提升质量，提高交付能力，提高开发者水平等等，总而言之，有好处的事情，我们尽管 做就对了，何必在乎这来自敏捷呢？
高效软件开发之道
中国有句老话：哪里跌倒了就从哪里站起来，就很敏捷，敏捷提倡复盘会，就是为了找到下次迭代能直接执行且改进的地方，从而不断优化迭代过程。 在软件开发的领域中，项目开发过程出现的需求变更，且是永远在变化，防不胜防，以至于我们每次迭代都要面临不同的挑战，最终导致无休止的加班赶工，搞得大家筋疲力竭，痛不欲生，996就这么来了，ICU也同样欢迎你。难道敏捷可以解决这些问题吗？也不一定，但它会给你更好的工作氛围，给你更好的做事原则，给你更好的应对变化的能力。
敏捷从何而来？
谈起敏捷从何而来，就要从2001年2月讲起，当时有17位志愿者，包括作者之一Andy在内，聚集在美国犹他州雪鸟度假胜地，他们讨论出了一种新的软件开发趋势，这个趋势被不严格的称为“轻量型软件开发过程”。 我们都见过因为开发过程的冗余、笨重、繁杂而失败的项目，世上应该有一种更好的软件开发方法：只关注最重要的事情，少关注那些占用大量时间且无意义的不重要的事情上去。 这些志愿者给这个方法起名：敏捷，他们最终发布了敏捷开发宣言：
- 一种把以人为本、团队协作、快速响应变化和可工作的软件作为宗旨的软件开发方法。
敏捷方法可以快速响应变化，它强调团队合作，人们专注于具体可行的目标，这就是敏捷的精神，它打破了那种基于计划的瀑布流式的软件开发方法，将软件开发的实际重点转移到了一种更加自然和可持续的开发方式上。 它还要求每个人都具备职业精神，并积极地期望项目能够成功，它并不要求所有人都是有经验的专业人士，但必须要有专业的工作态度（每个人能够尽自己最大可能的做好本职工作） 敏捷其实意味着，你不会在项目结束的时候才开始测试，不会再月底才能进行一次系统集成，也不会在一开始编码就停止需求的收集和反馈。
态度决定一切
- 做事
- 欲速则不达
- 对事不对人
- 排除万难，奋勇前进
学无止境
- 跟踪变化
- 对团队投资
- 懂得丢弃
- 打破沙锅问到底
- 把握开发节奏
交付用户想要的软件
- 让客户做决定
- 让设计指导而不是操纵开发
- 合理地使用技术
- 保持可以发布
- 提早集成，频繁集成
- 提早实现自动化部署
- 使用演示获得频繁反馈
- 使用短迭代，增量发布
- 固定的价格就意味着背叛承诺
敏捷反馈
- 守护天使（单元测试）
- 先用它再实现它
- 不同环境，就有不用问题
- 自动验收测试
- 度量真实的进度
- 倾听用户的声音
敏捷编码
- 代码要清晰地表达意图
- 用代码沟通
- 动态评估取舍
- 增量式编程
- 保持简单
- 编写内聚的代码
- 告知，不要询问
- 根据契约进行替换
敏捷调试
- 记录问题解决日志
- 警告就是错误
- 对问题各个击破
- 报告所有的异常
- 提供有用的错误信息
敏捷协作
- 定期安排会面时间
- 架构师必须写代码
- 实行代码集体所有制
- 成为指导者
- 允许大家自己想办法
- 准备好后再共享代码
- 进行代码复查
- 及时通报进展与问题
走向敏捷
- 只要一个新的习惯
- 拯救濒临失败的项目
- 引入敏捷：管理者指南
- 引入敏捷：程序员指南
- 结束了吗