前面几篇文章主要聊的是项目管理的重要性。谈到具体的项目管理，就肯定要谈敏捷。接下来我会分享下我对敏捷的一些思考和实践。王宇老师前几天发了一篇公众号文章 《什么是敏捷》 ，分析地非常透彻，推荐大家阅读。今天我也来分享下我敏捷的看法。
开篇之前先跟大家讲几个故事。
大概10年前，我去广州给一位客户做培训。我在台上给人家客户讲《敏捷宣言》，讲Scrum，讲得也是洋洋洒洒，舌灿莲花的。晚上客户老总做东请我吃饭，聊起来这家客户每年在Google投放的广告要差不多上亿。而我当时只不过是十多个人团队的一个小小的创业者，就有点受刺激——如果按照是否采用了Scrum、极限编程等实践来讲，禅道团队是要比这家客户敏捷一些的。但这又如何呢？人家生意做得比我们大很多个数量级，人家没有采用敏捷的实践又如何呢？
还有另一个客户，也是广州的，做游戏机起家，这是我唯一辅导过的一家公司。公司的李总很有前瞻性，2013年的时候就在做一个迷你音乐KTV的项目，跟后来的唱吧很类似。我去给他们辅导了两周，效果还是很明显的。我带的两个小组成功地跑了两个迭代，也完成了交付。但这又如何呢？我一离场，就没有人会来严格执行敏捷的实践和流程了。
再讲几个跟敏捷圈大佬的故事。
十多年前与敏捷圈里面的一位大佬交流，他问我们有没有用物理白板。我说我们用禅道，没有用白板，就被批判为不敏捷。然后这位大佬又问我们做不做TDD，我说我们现在只做到代码评审，然后又被鄙视。这位大佬还非常自豪地跟我秀了秀他的一个项目，是用TDD开发的。测试用例的方法名很长，大概是testXXXWhenXXX这样的路数，方法名就是用例。然后他说后面会开源出来让大家参考。故事讲到这儿，肯定有反转了：这个“非常敏捷”的项目很长时间也没有上线；而我们没有那么敏捷，但基本上保持了两周一个版本发布的节奏正常发布。
这件事还有后续。我们赞助了一个敏捷圈的活动，跟这位大佬谈好了，禅道提供讲师的赞助差旅和一些礼品赞助。后来活动快开始了，我们的信息还没有出现在活动网站上。问了一下，说是因为我们是做工具的，和敏捷不符，就把我们赞助这件事情取消了。取消就取消，人家不带我们玩，也能理解。但能不能提前跟我们说一下？我们的礼品都准备好了，物料也都发过去了，还是追问之下才告诉我们取消了。
现在DevOps大行其道，背后做支撑的就是各种各样的工具。估计现在不会再有人说用软件来做项目管理就不敏捷了吧？站在今天往回看，发现我们过去对敏捷的看法已经变化了。同样来推理，我们站在未来的某一天回过头来看如今对敏捷的看法，也肯定是有变化的。
聊到这里，终于可以说，究竟什么是敏捷？我的定义： 敏捷是一种能够持续快速地交付有价值有质量的产品或者服务的状态。

首先敏捷是一种状态。 这种状态背后是需要有人力、能力、流程、资源、工具等一系列的支撑达到的一种状态。但达到这种状态是否必须用Scrum、是否必须用Kanban、是否必须用DevOps，都不是关键因素。只要一个组织，一个企业能够达到这种状态，我认为它就是敏捷的。
这种状态下团队做的一定是 有价值有质量的交付 。做的东西有用，做的东西还有质量保障，这样的交付才有意义。谈到项目管理，我们经常说是多快好省，这种说法是有问题的，我认为应该是 好快省多 。做得东西首先要好，有价值，有质量，这是大前提。在这个前提下，再能够 快速交付 ，并能够控制成本，客观的结果自然就是多的。
一个团队短期内做到这种敏捷的状态我认为是不难的。比如经过敏捷教练的培训辅导，或者有一位比较有经验的Scrum Master来带领实施敏捷，都可以在短期内做到比较明显的改善。但难就难在是否能够持续地保持这种状态。这就像一个运动员如何保持自己的竞技状态一样，很有挑战。一个团队要想保持这种状态，就需要持续地在人、流程、工具这三个方面保持并提升能力。持续不断地 做人才的成长培养，做流程的优化，做工具的整合 。
所以，我对敏捷理解会更加开放：不拘泥于某一种特定的模型或者方法，根据实际的情况动态地调整团队策略。这就是我所理解和践行的敏捷，欢迎各位朋友交流讨论。