项目管理绕不开敏捷，但终究什么是“敏捷”？

前面几篇文章主要聊的是项目管理的重要性。谈到详细的项目管理，就肯定要谈敏捷。接下来我会分享下我对敏捷的一些考虑和理论。王宇教师前几天发了一篇公众号文章《什么是敏捷》，分析地非常透彻，推荐大家阅读。今天我也来分享下我敏捷的看法。
开篇之前先跟大家讲几个故事。
大约10年前，我去广州给一位客户做培训。我在台上给人家客户讲《敏捷宣言》，讲Scrum，讲得也是洋洋洒洒，舌灿莲花的。晚上客户老总做东请我吃饭，聊起来这家客户每年在Google投放的广告要差不多上亿。而我当时只不过是十多个人团队的一个小小的创业者，就有点受刺激——假设依照是否采用了Scrum、极限编程等理论来讲，禅道团队是要比这家客户敏捷一些的。但这又如何呢？人家生意做得比我们大很多个数量级，人家没有采用敏捷的理论又如何呢？
还有另一个客户，也是广州的，做游戏机起家，这是我唯一辅导过的一家公司。公司的李总很有前瞻性，2013年的时候就在做一个迷你音乐KTV的项目，跟后来的唱吧很类似。我去给他们辅导了两周，效果还是很明显的。我带的两个小组胜利地跑了两个迭代，也完成了交付。但这又如何呢？我一离场，就没有人会来严格执行敏捷的理论和流程了。
再讲几个跟敏捷圈大佬的故事。
十多年前与敏捷圈里面的一位大佬交流，他问我们有没有用物理白板。我说我们用禅道，没有用白板，就被批判为不敏捷。然后这位大佬又问我们做不做TDD，我说我们如今只做到代码评审，然后又被轻视。这位大佬还非常骄傲地跟我秀了秀他的一个项目，是用TDD开发的。测试用例的方法名很长，大约是testXXXWhenXXX这样的路数，方法名就是用例。然后他说后面会开源出来让大家参考。故事讲到这儿，肯定有反转了：这个“非常敏捷”的项目很长时间也没有上线；而我们没有那么敏捷，但根本上坚持了两周一个版本发布的节奏正常发布。
这件事还有后续。我们赞助了一个敏捷圈的活动，跟这位大佬谈好了，禅道提供讲师的赞助差旅和一些礼品赞助。后来活动快开端了，我们的信息还没有出如今活动网站上。问了一下，说是因为我们是做工具的，和敏捷不符，就把我们赞助这件事情取消了。取消就取消，人家不带我们玩，也能理解。但能不能提早跟我们说一下？我们的礼品都准备好了，物料也都发过去了，还是追问之下才告诉我们取消了。
如今DevOps大行其道，背后做支撑的就是各种各样的工具。估计如今不会再有人说用软件来做项目管理就不敏捷了吧？站在今天往回看，发现我们过去对敏捷的看法已经变化了。同样来推理，我们站在将来的某一天回过头来看如今对敏捷的看法，也肯定是有变化的。
聊到这里，终于可以说，终究什么是敏捷？我的定义：敏捷是一种可以持续快速地交付有价值有质量的产品或者效劳的状态。
首先敏捷是一种状态。这种状态背后是需要有人力、才干、流程、资源、工具等一系列的支撑到达的一种状态。但到达这种状态是否必需用Scrum、是否必需用Kanban、是否必需用DevOps，都不是关键因素。只要一个组织，一个企业可以到达这种状态，我认为它就是敏捷的。
这种状态下团队做的一定是有价值有质量的交付。做的东西有用，做的东西还有质量保证，这样的交付才有意义。谈到项目管理，我们经常说是多快好省，这种说法是有问题的，我认为应该是好快省多。做得东西首先要好，有价值，有质量，这是大前提。在这个前提下，再可以快速交付，并可以控制本钱，客观的结果自然就是多的。
一个团队短期内做到这种敏捷的状态我认为是不难的。比如经过敏捷教练的培训辅导，或者有一位比较有经历的Scrum Master来率领施行敏捷，都可以在短期内做到比较明显的改善。但难就难在是否可以持续地坚持这种状态。这就像一个运发动如何坚持自己的竞技状态一样，很有挑战。一个团队要想坚持这种状态，就需要持续地在人、流程、工具这三个方面坚持并提升才干。持续不时地做人才的长大培养，做流程的优化，做工具的整合。
所以，我对敏捷理解会更加开放：不拘泥于某一种特定的模型或者方法，根据实际的情况动态地调整团队战略。这就是我所理解和践行的敏捷，欢送各位朋友交流讨论。
更多分享：

• 禅道软件设计六大原则
  
• 项目管理领域三阶段：从流程到人再到工具
  
• 用项目管理的思维驱动你的工作和生活