客户：你们TW的敏捷根本不是敏捷
TWer：？？？
团队每天早上站会，晚上Code Review，有良好的TDD和pair机制，每两周一次Inception、一次外部Retro、一次内部Retro、一次showcase，我们不敏捷吗？
团队成员每天都呆在一起，频繁的进行沟通，BA每天都和客户待在一起聊需求，我们不敏捷吗？
我们有良好的CI流水线，定期上线，能够做到持续交付，我们不敏捷吗？
所以客户想说的敏捷是什么？
所以客户真的在乎敏捷是什么吗？
敏捷实践只是个辅助
当提到敏捷的时候，有人会提到XP、Scrum、看板等等，TW团队甚至是这几种敏捷实践的一个杂糅，包含了XP的结对编程、TDD、持续集成、随时随地重构、代码共享，看板中的工作流程可视化，scrum的站会、retro、inception、showcase、全功能团队。来到TW的第一天我就被告诉说要遵循这些实践，而当遵循这些实践变为了一种日常的时候，为什么要遵循这些实践，这些实践带来了什么好处有的时候却被忽略了。
XP、Scrum、看板这些敏捷实践其实都来自于敏捷思想，那么我们简单回顾一下敏捷宣言遵循的原则中关于客户的几条：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
现在回过头来看看上边的敏捷实践，在我们的敏捷实践流程中跟客户最相关的似乎只有showcase，因为showcase会向客户展示我们做了什么，这些东西对他们能产生怎样的影响，会减少他们多少工作量，让他们能赢得多少领导的好感度，能够帮他们挖掘多少商机，总之就是，价值。敏捷实践其实不直接产生价值，只是帮助我们知道什么是有价值的事。死板的遵循敏捷实践这件事其实也并不敏捷。
敏捷实践只是个辅助，很多时候却被我们错当成了ADC。
当客户说我们不敏捷的时候，可能这是一个信号，我们在表示不服之前，是否需要把敏捷宣言拿出来好好地反思一下，对于客户来说他是不是看不到价值点在哪。
万年野区的打野就只是个演员
在回顾项目的时候有一个很重要的实践是Retro，当听到别的项目失败的时候，通常会有一个问题：Retro的时候在干嘛？
在Retro的时候团队会提出各种各样的问题、指出看到的事实。有时候会有这种事，我们指出客户说：“你们TW的敏捷不是敏捷”这件事，得出的结论是客户不认可我们、客户不懂敏捷、客户过于challenge，最后的action是：我们要给客户做session讲敏捷。这个逻辑有错吗？没有错。一个打野去野区打野有错吗？
打野的目的是为了在前期吃掉野区的经济，快速发育起来去切对面的输出。万年野区的打野，没有杀人还吞掉了伙伴的经济影响了同伴发育，相当于对面的第六个人。
Retro很多时候会花费团队很多时间，在Retro的过程中甚至团队会产生各种负面情绪、无意义的争论，在此基础上如果Retro没有识别出真正的问题，没有产生合理的action，那么这次Retro不仅没有解决问题，还浪费了每个人的时间，甚至会让团队成员产生一定的挫败感和负面情绪。
回到上边的Retro的例子，当事实是客户说出的那句话时，我们要反思的是客户是出于什么心理说出了那句在我们看来非常challenge的话，他说这句话的背后想说的真的是敏捷吗？
杀对方个40：0为什么还是输
在推塔游戏里经常会有这样的吐槽：“那个鱼唇的ADC只知道杀人！”。所以怎样才能赢？推塔。杀人的目的是什么？能够愉快的推塔。
客户请我们做项目的目的是什么？产生他们想要的价值。敏捷实践的目的是什么？帮助我们快速的产生正确的价值。当团队有自信说，我们的产品没有bug，代码是高质量、可拓展的时候却还是遭到了客户的质疑，这个时候我们要反思的是，对于客户来说这个项目怎样才算成功，什么才是有价值的，怎样才能快速让客户看到价值。
有时候我们上项目、客户做项目的时候都有各种各样的目的和想法，小开发们一般是想要学习某些技术栈、得到某些成长，BA们可能是期望了解某些领域，客户有的可能是为了提升自己的部门地位、在公司中刷刷存在感、甚至有可能只是为了把预算花完。但是在这些纷繁杂乱的目的之上，有一个共同的目标，就是项目成功。
有的时候项目做到出现问题、团队充满了抱怨的时候，有时候会忘记项目成功这个目标。有时候对面会有队友说“对面快推！我给你们送俩人头。”。当项目不愉快、濒临失败时，一定好好思考，什么对于这个项目来说才是成功的，中间是哪里出了问题，现在这种情况下怎样才能走向成功。
带穿一路 vs 推三个一塔
快速迭代迭代的是什么？
我们总说2周一个迭代，这么说的时候其实是偷换概念。我们要迭代的是产品，不是时间。同样的，频繁上线不是为了上线而上线，而一定是有用户可以看到的东西上线才有意义。
做系统很多时候就像做个冰山，大多数都在水下，只露个尖尖在水面上。但是如果一个系统在一个迭代内做了很多水面下的事情，然后做了个上线，给客户花了一个小时做了个showcase，这一个小时和这次上线的意义是不是对于客户来说就是浪费了一个小时和积累了更多的怨念呢?
如果要做到快速迭代，需要的是将需求纵向的切分，在每一次迭代中能够让客户看到水面上的尖尖的一部分，这样他们才能够针对性的给出反馈，而不是闭门造车，将冰山下的一切准备好了之后再去做水面上的部分，不然这样的敏捷和瀑布除了多了一些繁琐的流程以外又有什么区别呢？
上星是个过程，你不会永远只呆在青铜
项目回顾到这里，我们几个小伙伴突然就倍感遗憾，我们突然发现其实很多事情在还没有定下来之前似乎都可以回头，很多东西如果及时的反思出问题点就能够很好地推下去。现在只好自我安慰一下，这是一个很好的过程，帮助我们在下一个项目中及时的发现问题，不再遗憾。
我们在上星的过程中会发现在每一个赛季自己的名次都会有所上升，最开始只是个青铜，然后上到了黄金止步不前，突然某个赛季发现上了铂金，然后一点一点爬到了钻石、星耀、王者。每一个赛季都会有所成长，然后在每一次失败中反思、总结。
