知“敏捷”易，行“敏捷”难
最近公司在研发过程导入敏捷模式，周围同事也开始谈“敏捷”，细听下来由于大家站的角度不一样，对敏捷的理解都不尽相同。正好前几年也对敏捷做过一些了解，在实际项目中也对敏捷所倡导的理念做过一些实践，有波折也有些许收获，下面谈谈自己对敏捷的一些理解。
image.png
为什么出现敏捷？
在说敏捷之前有必要先说下软件开发的发展过程。
上世纪七八十年代开始，随着软件应用领域的逐步增加，软件规模有逐渐扩大，为更好的进行软件开发管理，软件开发进入了软件工程阶段。
软件工程中明确了经典的瀑布开发模型，把整个软件交付过程人为分成了收集需求、定义产品、系统设计、编码、测试、发布等阶段，每个阶段设定明确的目标和标准，达成后再进入下一个阶段，整个过程沿着可预测性逐步增加的方向前进，可以避免资源的无效投入，并有效地保证开发质量。
瀑布开发模型有两个前提条件：
【条件一】瀑布模型严格定义开发阶段，上一个阶段的输出作为下一个阶段的输入，各阶段之间有强烈的依赖关系。其中一个阶段的输出质量不高，会影响后续各阶段的输出质量，并在各阶段之间逐步放大质量不高的负面效应。
image.png
【条件二】瀑布模型作了一个假设，就是认为在产品之初就可以获得明确且被客户认可的需求。在传统软件行业中，该要求是理所当然的；进入互联网和移动互联网时代后，准确收集获得用户认可的需求基本上是不可能的。
image.png
有数据显示有70%采用瀑布式开发方法的软件开发项目均以失败告终。原因在于，随着互联网特别是移动互联网的飞速发展，市场的需求瞬息万变，很难实现产品需求的明确且完整地收集。
同时，技术的发展也日新月异，对于所定义功能的可实现性也面临着多重不确定性的因素。所以当需求收集和产品定义等前置条件工作无法有效的完成时，瀑布式开发也就无法摆脱高失败率的命运。
总结来看就是当产品需求的不明确性和工程实现的不确定性超出一定范围之后，瀑布开发模型这种严格定义阶段的开发方法便不再适用。
敏捷是针对传统的瀑布模式的弊端而产生的一种新的研发理念，核心思维模式从计划模式向价值驱动进行转变，瀑布模型是根据研发各阶段计划来进行按部就班实施，敏捷则更强调通过给客户逐步交付价值的反馈来及时进行调整优化价值，目标是提高开发效益，而不仅是开发效率。
这是敏捷吗？
有相当一部分同学说，敏捷不就是开项目迭代会、以用户故事来拆分需求、进行看板管理、每日团队站会、按固定周期来发一个版本吗。
image.png
团队学会了这些规则和仪式，团队就是按照敏捷的方式在运作吗？
不一定，因为这些只是敏捷的表象，为了更好的进行敏捷实践，我们非常有必要知道这些仪式是如何实践敏捷的理念和原则的，如何给软件交付带来正向反馈的。
遵循敏捷的原则和价值观才是敏捷的核心，简单的模仿其它团队的行为和做法不会让你的团队变更更为“敏捷”。
只有这样我们就能根据团队实际情况对敏捷实践进行改进调整，以便可以更好的与团队实际情况进行融合，发挥出敏捷理念应有的价值。
接下来我们必要探讨下敏捷到底是什么？
“敏捷”是什么？
“敏捷”是什么，敏捷 = 4个理念 ≈ 12条原则。
什么是“敏捷”，2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法，主要是4个开发理念：Individuals and Interactions，Working software，Customer Collabration，responding to charge。
image.png
敏捷理念过于抽象，为了让敏捷变得简单易懂好执行，他们又提出了敏捷开发的12项原则：
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意；
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化；
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外；
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标；
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；
7、可工作的软件是进度的首要度量标准；
8、敏捷过程倡导可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续；
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强；
10、以简洁为本，它是极力减少不必要工作量的艺术；
11、最好的架构、需求和设计出自自组织团队；
12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。
大家可以看出，敏捷不是迭代会和看板管理，不是方法论和开发规范、也不是框架或过程，敏捷只是提出了一些软件开发的理念和原则。
敏捷强调在软件研发过程中向用户持续交付价值和获得反馈，不断进行迭代优化让产品逐渐完善。不同的团队、不同的人、不同的经历对12项原则有不同的感受和理解，不同产品阶段对各项原则的执行也有轻重之别。
其中个人对如下几点感触较深：
1）尽早交付价值，并持续迭代优化的模式来让客户满意，确保产品经受市场检验而获得强大的生命力，而不是在团队内部进行精雕细磨，极易迷失方向。
2）识别有效需求，业务和产品对用户反馈的需求进行甄别，钻石需求优先响应、合理需求纳入TODO清单，不合理需求与客户沟通协商拒绝，坚决不能将就，对需求质量把握的高低直接决定着研发生产效率的高低。
3）以简洁为本，在软件复杂度越来越高的今天，能把产品使用做简单不仅体现客户优先的服务态度，更是体现产品是否专业的直观表现，这需要对客户使用场景的换位思考和抽象。
应用敏捷的三个阶段
在应对快速变化市场需求的背景下，倡导灵活性、持续改进和尽早交付的敏捷受到了在国内外研发团队极高的追捧。
下面介绍产品生命周期中三个典型阶段的敏捷应用，分别是探索产品方向阶段、交付产品价值阶段、完善功能任务阶段。这三个阶段对产品目标、组织结构、团队构成等多方面有不同的要求，这也就需要在进行敏捷导入时进行考虑，并根据情况进行适当调整。
探索产品方向
团队需要打造一款全新的产品，此时思考的是客户和用户是谁、他们的痛点是什么、是否愿意付费、我们如何获得收入、我们如何触达客户等问题。
image.png
这个阶段敏捷理念的最佳实践就是精益创业，输出最小价值产品（MVP）来进行市场验证，尽早获得客户的反馈和了解团队的能力边界。
此时输出的所谓产品，大部分和通常大家看到的产品有较大区别，因为此时输出的所谓产品仅仅是为了得到市场和用户的有效反馈。
此时产品形态不是最重要的，一切均是为了获得客户真实有效的反馈，产品可能是一个可交互的原型图、一段介绍产品模式的视频、一个粗糙的移动App、甚至可能只是一个想法。在产品初始阶段，做正确的事比正确的做事显得更为重要。
有人可能会有疑问为什么我们不把产品做好才交付到市场中去，这样客户的反馈就更真实准确吗？原因就是其中我们的绝大想法和创意都注定了会以失败而告终，MVP就是把超出团队认知外的想法及早让客户来帮忙淘汰掉，而不是投入成本研发几个月再被市场否决掉，这会造成资源浪费和错失其它机会。
记得有一个朋友说，精益创业就是“尽快失败”，在探索产品的最初阶段它确实如此；每次的失败都不是终点，而是一个新的起点，只有找到产品方向和价值才算结束。
最近团队有做票据超市的新创意，内部评估都认为值得一试，此场景就可以应用精益思想来进行实践。此时很多产品同学肯定会说我们用MVP思想做一个最简单的产品出来让客户进行体验就可以了？
道理没错，但到底这个产品多小才是最小呢？正所谓没有最小、只有更小。对票据超市产品核心价值的不同理解，就会有不同的最小产品方案，只要对产品核心价值不产生重大折扣的功能都没必要进行进行前期开发投入。此时就要求大家对产品价值的理解和识别，敏捷的理念和原则可以快速掌握，但对产品价值的识别则需要时间培养。
交付产品价值
这个阶段主要目标是在现有产品基础上追加新的价值，团队将以目标为导向，相互协作思考达成目标的方案、衡量目标达成的尺度、方案需要的支撑功能等等。
图片来自网络
此时团队要被赋权且可以问责，被赋权是指协助团队制定目标，然后交由团队来寻找达成目标的最佳方法，而不是安排具体的工作任务。
比如，团队不是被告之需要为灵活用工行业开发哪些功能，而是“目前灵活用工行业客户交易规模偏少，新客户拓展不快且已上线客户上量也较慢，希望解决该问题成为灵活用工行业排名前三的资金处理服务商！”。
此时整个团队需要协同寻找解决方案，并进行尝试，当实践A方案后未达成目标，则团队会总结再出发尝试B方案，直至最终达解决问题达成目标。
在落实具体方案的过程中，敏捷团队会对实施方案行拆分或分解形成一系列的行动计划，然后按计划逐步进行价值交付，并及时获得客户的反馈对计划进行修正调整，确保产品经受市场洗礼而获得较强的生命力，而不是在团队内部进行精雕细磨。
大家是否也觉得这种授权模式和OKR似曾相识，其实是否叫OKR并不重要，这种赋予目标的工作方式，可以极大的调动团队的能动性，以更为积极和主动的心态开展工作。
完善功能任务
这个阶段主要目标是进行高效产出，此时团队需要做的工作任务是明确的，有一个很长的TODO清单，这些清单主要是对产品进行常规优化和升级，从而给客户交付更稳定、可靠、易用的产品，目的对现有产品的价值进行放大。
图片来自网络
由于功能任务是明确性，研发的关注点就是高效产出交付，提高产出效率。Srcum、看板等敏捷模式将有助于协同团队的工作步调，以用户故事粒度对需求进行拆解、对研发过程进行可视化管理，进而以类流水线方式高效稳定的进行功能发布。
再就说下迭代节奏，大部分团队采用的是每2周交付一个版本，工作节奏和交付频率较为适中，大部分团队均可以接受；有些初创团队采用每1周发布一个版本的节奏，团队工作压力也非常大，对团队的技能和工具均有较高的要求。
结束
在市场瞬息万变和技术日新月异的背景之下而产生敏捷，它和瀑布开发一样都有其适用范围，它也不是救世主并不能解决所有开发过程中的问题，但它一定会给你带来新的思考。
《人月神话》的作者弗雷德·布鲁克斯有一个观点，那就是：没有任何单一的技术或过程可以带来软件开发效率的显著提高。对“敏捷”来说也同样适用，并不是实践了Scrum或者看板就一定可以解决你的问题，先对目前面临的问题进行识别是关键，然后去找到适合你的那些实践，谨慎选择和勇敢尝试，希望大家都得偿所愿。
