- 敏捷宣言
- 实践
- 计划
- 测试
- 回到开发本身：敏捷的设计
- 认清处境：敏捷团队走向成熟的三个阶段
- 认清边界：目管理铁三角：质量，价值，约束条件
- 敏捷的最终交付，代码和软件
- 微服务与敏捷开发
- 参考资料
如今软件开发离不开“敏捷的话题”，既然离不开，那我们来深入的聊聊，到底什么是敏捷。
关于敏捷我感觉我一直没有深入理解，敏捷到底在敏捷什么？我不由自主的有了一个疑问，一次评审，负责研发的同事说我们根本没有敏捷，于是我便有了我这次的问题和理解。
敏捷宣言
从软件开发的历史：瀑布模型，增量开发,CMMI 等等软件从开始到结束经历的周期越来越长，开发过程越来越臃肿，现代的商业活动要求产品更快的能触达到用户并在现实环境中接受验证并作出适时调整，持续完善。为了解决膨胀的过程带来的痛苦和不确定性，敏捷概念油然而生，敏捷的原则和价值观构成了一个可以打破搓成膨胀循环的方法，敏捷的过程有XP极限编程， SCRUM，自适应软件开发 等等其中应用最多的便是scrum
最终的目的是交付用户可用的软件，结果导向，落地，变想法为现实，在这个前提下变有了一下知道的原则
1. 个体的交互，团队的协作和沟通胜过过程和工具
过程为结果服务，人是获取成功的关键，团队不一定非要一流的程序员，但要是优秀的团队成员，他能够友好的和他人合作，沟通，这些比编程能力更重要，不然一个项目很大程度上会跑偏，因为任何一个人未完成，整个就不算完成
不要试图单纯的借助工具和外力来解决当前之问题，要从问题的内在出发，去打通问题的核心流程，工具是外在的，内在恰如其分的架构和设计才是解决问题的关键，不要认为更好更大的工具能为你自动的解决所有问题
- 不要试图引入一个高性能的数据库除非迫切且必要
- 不要试图引入一个收费的商业工具除非迫切且必要
- 人与人之间交互是复杂的，人不是插入即兼容的编程装置，上下文切换和多线程不会让人的生产力有良好的促进，人需要聚焦，于此同时人一旦融入了场景之中发挥主观能动的时候人的潜力似乎是不可限量的
2. 可工作的软件胜过文档，文档也不是关键
直到十分迫切和意义重大时才编制文档
3. 客户和做胜过合同谈判，从一锤定音不支持修改到拥抱变化持续优化，客户和研发更紧密和频繁的交流打在软件从原型到雏形到成品，合同指导了这种写作而不是视图规定项目的范围和固定的成本
- 任务列表是相当于一个合同，这个一定要是可以灵活变动的，不然就会有为了进度牺牲质量和一系列其他东西
- 需求入组，产品和研发已经紧密的协作了
4. 响应变化：计划不能太过远，环境是变化的，需求可能也会跟着改变
当这些改变的时候，我们的看板，大白板，进度和进程就会不在适用，721原则，我们2周内做了详细的计划，并且有任务队列和优先级下一个月甚至下三个月都有一个模糊的范围
对于迫切的任务有详尽的计划，2周之外的计划部分仍然保持灵活性准备结合环境来做出适时的调整
我们的客户仍然不是最终付费的客户，客户是我们的需求开发人员，我没又有走到价值的第一线去，这么来说，我们的敏捷算不算真正的敏捷？？？不算吧
原则
1. 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意，因为价值是由人来定义的
- 功能越少，质量越高（变动和风险在较小范围内）
- 交付越频繁，质量越高（变动和风险在较小范围内）
2. 即便到了需求开发的后期也欢迎需求的变化，利用敏捷的过程为客户来创造竞争优势
- 改变需求是好事，团队学会如何满足市场的需求
- 优秀的架构就是用来相应变化的不然那么模式和设计毫无发挥之地，也促使开发提升
3. 交付间隔越小越好，交付满足客户需要的软件
4. 业务人员和开发人员在一起工作，业务人员对软件项目进行持续不断的引导
5. 激励团队成员提供他们所需的环境，资源和支持，信任他们可以完成工作
6. 团队内部最有效率的沟通就是面谈，而不是文档
7. 能够工作的软件是进度的衡量便准，代码即文档
8. 要可持续发展，责任人，开发，用户能够长期，恒定，敏捷不是短跑而是马拉松，需要保持能量和精力
9.不断关注优秀的技能和良好的设计，增强敏捷能力
10. 完成工作最大化的艺术是简单，简单是高阶的复杂
不要尝试整那些花里呼少的东西，用最简洁，最高效的方式完成任务
11. 最好的架构和需求和设计皆出自于自组织的团队
如鱼饮水冷暖自知，面临什么问题，需要什么效果，我们由哪些限制，我们由哪些挑战，这些第一现场做事的你最清楚，只有你从心出发，用心思考，才能达到恰如其分的优雅
12. 跟上情境的变化，每隔一段时间要进行反省，PDCA检视并调整自己，组织方式，规则，规范，关系，随环境一起变化，让自身保持敏捷
我们的相关方是雇主和客户，满足他们的需求，为他们提供可工作的软件，增强他们在市场的竞争力是软件开发人员的职业目标
敏捷方法并不会让涉众得到他们想要的，不过它意味着能够以最小的代价获取最大的商业价值
实践
1. 客户是团队中的成员，参与软件开发，引导软件朝着预期的方向构建
2. 频繁的交付并给客户演示，得到反馈并修正
3.使用自动化和反复的验收测试方式，提效验证环节
4. 敏捷模式下任务项目信息要透明，大家可以互相补位，互相评审和勘误，每个人不会被限制在特定的领域，模块没有负责人，大家共同参与UI开发，数据库设计，等等
5. 敏捷模式下优秀的工程师，技术不一定是最好的但是一定是善于沟通的
6. 持续构建，持续继承，自动化发布开发完成的功能
7.可持续的开发速度，不加班，保持精力和能量，保持旺盛的活力和敏锐的警觉应对今日的变化，做出抽象，简洁的设计应对今日之需求，响应明日之变化
8. 简单的设计，如无必要，保持简单
- 使用能够工作的最简单方案
- 只有真正需要的时候在引入先进的工具，模式设计，等等
- 单一职责原则，多提炼抽象
9. 持续不断的重构，持续的代码持续的变化，跟上需求的变化，保持简洁和表现力
10. 使用隐喻来将整个系统联系在一起，形成全局视图，它将指导软件按照蓝图来构建
我们用装卸卡车运垃圾来比喻整个系统，缓冲区是小卡车，屏幕是垃圾场，程序员是垃圾制造者
所有名字互相吻合，这有助于我们从整体上进行思考和设计整个系统
计划
1. 任务故事不能用数字表达就是不了解，就无法度量
2. 迭代任务要有弹性不是计划了都要必须完成，这样会导致牺牲软件的质量和稳定性，并为自己在将来埋下隐患
3. 任务分配要灵活，721法则 ：7 经典业务，2 创新和尝试， 1 非功能改进
4. 迭代过程中段与客户一起对任务进行检视和调整，确保迭代完成能够完成所有的任务和故事
5. 演示过后，客户可以使用新的故事来提交反馈和改进
测试
自动化测试促进系统的高内聚低耦合，测试驱动的方式，会促使开发人员开发更加抽象和解耦的软件，促进模块之间隔离，从而改善整体软件的设计和质量
代码即文档，单元测试和验收测试也是一种可编译可执行的文档
回到开发本身：敏捷的设计
在前面叙述了那么多，算是给敏捷的定了个性，什么样的是敏捷的，什么样是不敏捷的，那我们既然要向敏捷靠近，那应该如何做到呢？
认清处境：敏捷团队走向成熟的三个阶段
我们貌似还是停留在第一阶段
认清边界：目管理铁三角：质量，价值，约束条件
清华大学管理学教授宁向东一针见血地指出，管理，其本质就是关于如何“破局”的智慧。所谓“局”就是管理者周围的各种资源相互联系，相互作用的一种状态。以上约束，也是软件工程表现出来的组织复杂性，也是一种局。
在日常开发过程中，我们需要要找到固定的一条边或两条边，然后去调整剩下的边，最终达到平衡。
敏捷的最终交付，代码和软件
优秀建筑师可落地的是宏伟的建筑，优秀的厨师能够做出美味的大餐，那敏捷的开发人员能够产出什么呢？
敏捷是在开发过程中敏捷，那最终产出还是代码！
先前讲了敏捷的原则和实践，敏捷的判断标准，敏捷过程中的流程和协作方式，那回到软件本身，软件是由代码组成的，那开发人员构建什么样的代码才是敏捷的？
软件构建是软件交付最本质的要求，你得做出来先呀！那我们做出来的东西如何评判是好还是坏呢？
假如我们是给客户加工蛋糕的小工厂，那用什么样的机制保证自己能够交付优质且美味的蛋糕呢？我们得有一套最佳实践和评判和勘误的标准，告诉我们怎么做才能做出好的东西，做出来后我们怎么样来确认我们确实做好了
当当当当当当，感谢无数软件的先驱，软件的前辈们已经总结出了一份标准告诉我们什么样的代码是有臭味的，这样的代码和设计会阻止你走向敏捷
僵化性
脆弱性
牢固性
粘滞性
不必要的复杂
不必要的重复
晦涩
敏捷的设计是一个过程，持续的应用原则，模式，实践来改进软件的结构和可读性，保持系统往简洁，干净，富有表现力的方向发展
微服务与敏捷开发
微服务与敏捷十分适合的搭配
个人曾经思考了一个问题与大家分享和交流：敏捷开发倡导无需专人负责，代码平权大家都可以提交，微服务的核心在于高内聚业务领域也就是说要持续的投入和深耕不断重构才可以，这二者有没有冲突？
基于这个问题，经由思考并结合团队目前的状况来看，必须每个模块有人负责才行，业务领域需要持续的深耕和投入和打磨才能达到恰如其分的架构设计，现实中也是有几个服务被几个人共同开发，但是没有人负责在这上面持续投入，导致这里复制粘贴的代码很多，代码有粘连性，不精简，几乎没有任何模式和设计，这块功能后续势必给整个系统带来隐患。
但深入思考下，每个人的维护方式和编程范式和习惯不一样，要如何能协同一个系统朝着既有的蓝图和设计进行演化呢？
这就需要有顶层设计，从整个业务和架构角度对系统进行规划，划分，约束和限制。
参考资料
绩效考核 – 敏捷转型的鸿沟