离职一个多月了。前几天进行了第一次面试，问了下你以为敏捷有什么好处，还一下把我给问住了，因此特来写篇博文梳理一下个人认识的敏捷。水平有限，敬请谅解。python
背景面试
在我入职前，大版本的开发和交付要经历较长的时间，质量很不稳定。因为对软件质量要求较高等各类缘由，没人敢乱动乱码， 可是新特性还要开发，致使整个代码臃肿不堪，上千行的函数随处可见。最后的最后，你们发现这不能忍啊，活无法干下去了。shell
敏捷介入编程
公司花重金聘请了敏捷顾问团队，跟项目组共同开发特性，进行一对一的敏捷培训。效果上说仍是达到了目的，开发效率，产品质量都有了很大提升，支撑了以后多个版本的稳定开发和交付。敏捷顾问撤离，仍是保留了每日版本构建，项目组持续集成，状态墙，TDD，结对编程，每日站会等敏捷实践和活动。框架
价值思考python2.7
其实这一点我后续的实际体会很少，都是从老员工的讲述中获得的。敏捷顾问当时很是强调从价值出发去考虑问题，再分析特性的时候，会以”这个特性有什么价值“、”这个特性不作会怎么样“、“这个特性要知足什么目的”，“这个特性有反作用”这样的思惟方式去思考特性的价值。这样想清楚了才会去思考方案有什么，哪一个方案最合理。经过价值思考能够明确特性开发完后软件的外部行为是什么样的，会引导你思考开发的代价，收益率这些问题。不过仍是作了不少没用的特性，咱们都知道价值不大什么没价值，可是，哈哈。。函数
作一个刚恰好的软件系统工具
在明确特性的价值和目的后，就要思考投入多少资源去作成什么样子了。一个仅仅用于演示和一个要在全球部署的特性固然是彻底不同的。一开始我以为在早期作的好一点会更好吧。可是在后面的实际工做中，发现你的精力，资源都是有限的、总有人会提出垃圾的需求作完后被废弃、还有就是把代码写好而后去拥抱变化吧。大型的软件系统应该是逐步演进，那么就没必要纠结于一开他有多简单了。单元测试
纵向划分story学习
在划分story的时候更习惯横向地思惟方式。拿切蛋糕来做比喻，story应该是一小块完整的蛋糕（可测试，可交付）；而不是被划分红水果层，奶油层，蛋糕坯。能够工做的软件赛过面面俱到的文档。
各类自动化脚本工具
敏捷不光有一组理念，一些支撑这些理念的方法论，一堆支撑这些方法论的实践，还有支撑实践地工具。有现成的各类单元测试框架，有持续集成工具cruisecontrol等等，但也有不少不适用于本项目组甚至没有的工具，就须要本身去开发不少脚本和工具来提升生产率。总之就是能用机器干的，就别手工劳动。经过工具能够很好地提升团队的开发效率，更重要的是承载了处理问题的宝贵思路和经验。
保证你们都清楚
早期开发和测试分家的时候，开发完了而后交给测试，而后各类bug，各类攻关关，各类延期，各类哈，身心憔悴啊。最崩溃的是开发认为这不是问题，可是测试以为这直接关乎x亿用户的正常使用啊。其实究竟是不是风险，影响有多大，谁知道呢，bug在运行几年后才随机出现，并且没法复现的状况有的是。因此理想的状况是开发，测试，项目经理，维护等各路人马对特性，目标，影响，潜在风险等都很是明了，甚至提出本身的意见使方案看起来是通过各个角度的深思熟虑的。后续由于实现、进度等缘由的变动也要及时知会，这样，辛辛苦苦写完代码推翻重来的风险大大下降。在大公司，沟通永远有着高昂的成本。
用例
我认为用例是设计、实现层面最好的书面材料和沟通媒介。经过用例详细描述特性或者问题修复后的软件外部表现，提供明确的运行结果，直观，无二义性，有说服力。后期若是能加入自动化用例库，至少在版本发布前你们内心都有底。若是护周期很长的软件系统有很长的维护周期，自动化用例库和团队内部使用的形形色色的自动化工具，是最宝贵的资产。
TDD
先写用例，再写代码。一开始的时候还真是把人给憋的，几十分钟写个用例还真是很痛苦。到后来不写几个用例还真不会写代码了。其实在写代码以前可否写出用例，能够说明是否理解了需求或方案，根据方案设计代码应有的执行结果，对代码的逻辑流程，异常输入的处理是否思考到位。而不是在写代码的过程才去取理解问题，并不断修改代码。听从TDD写出来的代码短小，逻辑清楚。可是也有一个问题，经过打桩，用例来驱动coding只是代码的写做方式，并非设计，一堆mock并不能解决缺少设计而致使的缺少灵活性，缺乏维护手段等问题。
结对编程
在老员工带新员工的时候效果不错。倒不是说对代码自己的学习，老员工高效率的工做方式让人受益不浅。不过我也看到过老员工之间及其默契的结对，当一我的还没明白为何用例失败的时候，另外一我的已经把代码修复了。至于提升代码质量上，我却是没发现有不可替代的价值。
迭代回顾
从我自身的经验来看，迭代回顾会议的效果十分有限。迭代回顾并不能解决各类老大难问题，不少问题几乎在每一个迭代回顾会议上都能听到。不过却是一个充分沟通的平台，至于下情可否上达就是另外一回事了。不过一些能当即实施的措施，经验却是能在迭代回顾会议上获得传播。不过只要团队的内部沟通顺畅，这都不是问题。我认为迭代回顾会议的目的应该是站在团队层面，对迭代中不符合预期的状况提出解决的方案，提高团队的效率，逐步完善团队能力。
更高的代价
敏捷对每一个人的能力要求仍是很高的，或者说要付出的代价是很大的。好比工具，敏捷仍是比较依赖工具的，在咱们产品内部，因为项目组较多，致使有各类各样本身开发的工具，有python2.7的，python3的，有tcl的，有shell的，有bat的等等等等，这维护代价。还有就是若是一个特性作出改动，一天甚至更多的用例修改也是让人感受厌烦的事情。