详情
本书以叙事传记的形式，借助敏捷武林大会的故事情节，讲述敏捷实践中的各种“坑”，然后通过“漂流瓶”的暗喻，总结和提炼正确的实践。首先，本书回顾了敏捷实践的发展历史，帮助读者快速了解敏捷的演进历程；其次，通过每日站会、迭代回顾、需求管理、迭代计划和工程实践5个方面的内容，重点阐释各种敏捷方法在实践过程中的常见错误及应对措施。
本书语言风趣，内容丰富，寓教于乐，适合敏捷实践者、敏捷爱好者阅读。
书名：敏捷漂流记——实践避坑指南
ISBN：978-7-115-65102-0
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 王立杰 黄 隽 等
责任编辑 秦 健
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书以叙事传记的形式，借助敏捷武林大会的故事情节，讲述敏捷实践中的各种“坑”，然后通过“漂流瓶”的暗喻，总结和提炼正确的实践。首先，本书回顾了敏捷实践的发展历史，帮助读者快速了解敏捷的演进历程；其次，通过每日站会、迭代回顾、需求管理、迭代计划和工程实践5个方面的内容，重点阐释各种敏捷方法在实践过程中的常见错误及应对措施。
本书语言风趣，内容丰富，寓教于乐，适合敏捷实践者、敏捷爱好者阅读。
2023年年初，非常意外而又惊喜地收到王立杰老师的邀请，约我为他参与合著的新书作序。我感到高兴的同时又很有压力。王立杰老师参与合著的书写得太好了，珠玉在前，我内心惶恐，唯恐班门弄斧。
十几年前，我刚创业，负责开发禅道项目管理软件，偶然间发现了《敏捷无敌》这本书，买回来后一口气读完。在这本书中，王立杰老师与许舟平老师非常巧妙地将敏捷开发的各种实践和问题融入主人公的日常工作中，为我们讲述了一则非常美好的爱情故事，同时系统地介绍了敏捷开发。这是一本非常好的介绍敏捷开发的书，给了我很多启发。后来王立杰老师创业，和其他3位老师共同创办了IDCF（International DevOps Coach Federation，国际DevOps教练联合会）。IDCF举办了DevOps黑客马拉松，出版了《敏捷无敌之DevOps时代》，又推动中国DevOps社区的建设。这种不断精进、不断提升且好玩又有趣的状态，不正是Agile（敏捷）的精髓吗？
我们所处的乌卡时代真是越来越乌，越来越卡了。突如其来的战争、贸易战、技术大变革，每次突变都令人措手不及，更何况是一连串的巨大突变。以前，“黑天鹅”事件是小概率事件，可以预见，未来“黑天鹅”事件会越来越多，出现“白天鹅”事件的概率反而会越来越小。面对这种情况我们应该怎么办？站在当下来思考这个问题，或许22年前17位敏捷大师已经为我们提供了“敏捷真经”，可以帮助我们应对乌卡时代的挑战。
22年过去了，拥抱敏捷、践行敏捷已经是行业共识。包括老牌的CMMI、PMBOK等模型框架也都在积极地融合敏捷。可以说敏捷开发发展到了一个崭新的阶段。越来越多的“敏捷修炼者”掌握了敏捷开发的基本框架，可以熟练应用敏捷开发。但是，在实际应用中，大家不免会遇到各种各样的实际问题，例如，开每日站会时总有人迟到怎么办？在回顾会议上大家不发言怎么办？代码质量一直比较差怎么办？这些都是一线敏捷从业者遇到的具体问题。那么有没有一本可以帮助我们解决这些问题的秘籍？
于是《敏捷漂流记——实践避坑指南》来了。王立杰老师和中国DevOps社区的其他17位老师携手推出了这本敏捷实操指南。这本书延续了王老师讲故事的风格，为我们呈现了一个异彩纷呈的敏捷武林世界。这本书以我们喜闻乐见的武侠小说的方式，对敏捷开发过程的每日站会、迭代回顾、需求管理、迭代计划和工程实践5个领域中的常见问题做了深入阐述和讲解。天泽观、白云轩、丹鼎院、造物派等各派高手轮番登场亮相，向“敏捷修炼者”披露独家心法。他们提供的秘籍、锦囊、药丸、漂流瓶等神奇工具如下。
● 通过发红包、倒立、请全体喝下午茶等方式给参与每日站会迟到的成员一些“奖励”。
● 通过MVP方式发布产品。
● 通过头脑风暴解决团队协作中的问题。
● 通过Ask and Answer方法保证大家参会的专注力。
● 通过控制WIP（在制品）数量提高吞吐量。
● 通过产品路线图规划产品版本。
……
更多的我就不剧透了，再剧透的话，估计王立杰老师的“无敌追杀令”就要来了。总之，这是一本敏捷从业者都应该收藏并精读的敏捷修炼秘籍。熟练掌握其中的各种秘法，必可助你成长为真正的敏捷高手。
对了，书中还有彩蛋，传说中的敏捷一姐在书中惊鸿一现，并传道授法，赶快来寻宝吧。
王春生
禅道软件（青岛）有限公司创始人
2023年于青岛
2019年3月18日，为推动DevOps在中国的蓬勃发展，我们一群有着相同价值观与理念的人，正式宣布“中国DevOps社区”成立。当天，我们通过社区的微信公众号发布了如下社区宣言，社区伙伴以在微信公众号留言的形式共同签署宣言。
作为有理想的中国DevOps社区志愿者，我们一直身体力行，传播DevOps文化，落地DevOps实践，并帮助他人学习与实践DevOps。与此同时，我们建立了如下价值观。
不仅要让社区中立，更要保持开放宗旨。
不仅要去响应需求，更要创造社区价值。
不仅要有专业技能，更要包容百家思想。
不仅要与多方合作，更要建立伙伴关系。
也就是说，左项固然值得追求，右项更加不可或缺。
©2019，著作权为签名者所有，此宣言可以任何形式自由地复制，但其全文必须包含上述声明在内。
在中国DevOps社区成立之初，我们讨论并定义了社区的使命与愿景。
社区使命：传播DevOps文化，落地DevOps实践。
社区愿景：成为中国DevOps运动的领航人与催化者。
白驹过隙，4年时间匆匆而逝，在这么短的时间内，从0到1打造一个技术社区，自然是一件非常艰难的事情，但在所有人的共同努力下，截至2023年3月，我们已累计在22座城市举办128场DevOps Meetup、7场DevOps行业年度峰会，传播1000余篇DevOps实践案例，影响十余万名软件研发从业者。
截至今日，我们终于可以自豪地宣布我们已经成为中国DevOps运动的领航人与催化者。
为了持续地为中国DevOps运动添砖加瓦，我们在2022年年初筹划并推出了电子读物，取名《守望者》。守望指看守瞭望。守望者是指在城墙上昼夜看守城池，为城内的人提供危险预警的人。
生命需要守护者，就像森林需要护林人、灯塔需要守护人、麦田需要守望者一样，DevOps运动也需要守望者。尽管他们的人影总是寂寥的，但是他们一直固守着自己的精神家园，他们始终与时代潮流保持着一定的守望距离。在发生变迁的时候，在人们转移目光甚至迁离、逃避、逐新时，他们坚守在原地，时刻关注着、体验着、思考着—这就是守望者精神。
守，即守护，寓指守护过去珍贵的事或物；望，即期望，代表着未来，期望未来变成所希望的样子。守与望合在一起，就是守护着以前美好的事物，同时期望着这件事物将来能变成所希望的样子。做一个有坚定信仰、对回归本初有执着追求的守望者，一定是非常不容易的，这不仅需要无私奉献，更需要追求真理，还要有前瞻性的眼光。
“不管怎样，我老是在想象，有那么一群小孩子在一大块麦田里做游戏。几千几万个小孩子，附近没有一个人—没有一个大人，我是说—除了我以外。我呢，就站在那混账的悬崖边。我的职务是在那儿守望，要是有哪个孩子往悬崖边奔来，我就把他捉住—我是说孩子们都在狂奔，也不知道自己是在往哪儿跑，我得从什么地方出来，把他们捉住。我整天就干这样的事。我只想当个麦田里的守望者。我知道这有点儿异想天开，可我真正喜欢干的就是这个。”[1]
[1]摘自《麦田里的守望者》。
我很喜欢这段话，这样的理想也许并不远大，可是我们的生活中难道不是真的需要这样的守望者吗？而我们每个人其实也是某块麦田里的守望者。这样的工作虽然枯燥，但是我们首先得把这样的小事情做好才行—每个人的心中或许会有一种一剑寒九州的英雄主义情结。我很喜欢看《士兵突击》，尤其对主人公许三多说的“有意义的事就是好好活，好好活就是做有意义的事，做很多很多有意义的事”这句话颇有感触。我们坚持做DevOps运动的守望者，这也是一件非常有意义的事。
自《守望者》电子读物发布以来，在前5期中我们重点安排了与敏捷核心实践相关的内容。广大读者对这些内容一致好评，并期望将这些内容整理成册，以图书形式正式出版。在本书出版的过程中，非常多的人付出了辛勤工作与巨大努力。首先感谢各位作者，他们是陈文峰、方正、巩敏杰、黄隽、黄震、黄鹏飞、胡帅、李岩、刘陈真、刘志超、王艳、王洪亮、王东喆、王英伟、朱婷、成芳和张思琪；感谢人民邮电出版社的图书编辑团队，他们针对本书的创意、故事结构、规范化、内容整合等提出了非常多的宝贵建议；感谢禅道公司对本书出版的赞助，感谢禅道公司创始人王春生为本书撰写推荐序，感谢禅道公司的郑乔尹、刘诺琛、程家乐等小伙伴为本书绘制的优美插图；感谢中国DevOps社区的运营伙伴成芳对《守望者》电子读物做的封面和排版工作，以及对本书初稿的收集整理和项目管理工作。
谨以此书献给中国DevOps社区的志愿者、粉丝、赞助商及生态伙伴。感谢大家伴随我们一路前行，一起建设社区，一起为DevOps在中国的推广作出贡献。
做DevOps运动的守望者，是一件非常有意义的事。期待你的加入，跟我们一起守望。
王立杰
中国DevOps社区第一届理事会主席
王立杰
资深敏捷创新教练，IDCF联合发起人，中国DevOps社区第一届理事会主席，华为云MVP，北京大学光华管理学院/新华都商学院MBA特邀讲师，曾任京东首席敏捷创新教练、IBM客户技术专家、百度高级敏捷教练，指导过京东、OPPO、小米、京东方、百度、招商银行等企业的研发效能提升工作。《敏捷无敌之DevOps时代》《京东敏捷实践指南》等图书作者。被广大读者戏称为“无敌哥”。
王洪亮
资深敏捷教练，可视化需求分析体系创始人，优普丰首席敏捷教练、合伙人。指导过浦发银行、招商证券、中金公司等企业的敏捷及DevOps的导入和研发效能提升工作。《会说话的代码—书写自表达代码之道》作者。
胡帅
中国联通集团高级技术专家，中国DevOps社区精英译者。他曾是多个DevOps 平台及微服务平台的核心设计者与产品架构师。曾供职于IBM中国开发实验室，参与IBM全生命周期协同管理产品、软件效能分析产品设计与核心研发工作，并担任数据分析智能平台Actuate BIRT社区的顾问。曾为中国旅游集团、万达、招商银行、中国建设银行、中国工商银行、广发银行、平安银行、美国通用等大型企业提供方案设计、研发管理等战略咨询服务。
黄隽
资深工程效能/敏捷专家，江湖人称“黄岛主”。敏捷江湖桃花岛社区创始人，Exin DevOps授权讲师、高等院校讲师，中国DevOps社区核心组织者，中国DevOps社区大连地区牵头人。致力于推广敏捷、DevOps和数字化转型，曾在世界500强和大型集团公司担任资深工程效能/敏捷专家、项目经理/总监、副总经理等。在多所高等院校或企业授课100余场次。拥有丰富的咨询、课件研发、业界峰会出品和分享布道经验。
陈文峰
资深项目管理者、研发效能实践者，中国DevOps社区核心组织者，珠海敏捷&DevOps社区负责人。在移动通信、交通运输、市政建筑、协同办公等行业或领域有近20年的软件研发、项目管理、团队管理和效能提升经验。致力融合项目管理与工程实践以促进研发效能的提升。《运维困境与DevOps破解之道》《DevOps悖论》译者。
李岩
项目管理专家、敏捷教练，花名“老道”。曾供职于美团、网易云音乐。敏捷转型实践者，熟悉精益、Scrum、LeSS、SAFe、DevOps、效能度量等，拥有PMP、ACP、CSM、SAFe DevOps Practioner（SDP）等认证。
王艳
资深产品经理，DevOps产品专家，中国DevOps社区核心组织者。拥有十余年开发、产品、项目管理工作经验，专注研发效能、DevOps、精益敏捷领域知识的落地和推广，梳理相关流程并建设DevOps研发效能、容器云等技术平台。拥有软考高项、ACP、NPDP、DevOps Master（DOM）等认证。《DevOps悖论》译者。
方正
产品总监，敏捷转型践行者，中国DevOps社区核心组织者，广州社区负责人。拥有十余年toB领域软件研发、项目管理、产品管理、团队管理经验，致力于以业务价值驱动团队敏捷转型，促进研发效能提升。拥有PMP、ACP、PRINCE2、软考高项、DOM、NPDP等认证。
刘志超
华为云研发管理人员，云原生探路者、云服务架构师/专家，中国DevOps社区核心组织者、精英译者，深圳HDZ筹备组核心成员。专注于最有价值的事情，秉持“高效工作，快乐生活”的理念，期望让研发更简单，让生活更美好。
张思琪
敏捷教练、敏捷转型践行者。中国DevOps社区上海社区组织者之一。拥有十余年toB领域软件研发、项目管理、产品管理、团队管理经验。曾负责爱立信上海研发中心BU Multimedia的敏捷转型。致力于研发效能、DevOps、精益敏捷领域知识的落地和推广，打造以业务价值驱动的高绩效团队。
成芳
资深开发者社区/生态运营人员，多个开发者社区核心组织者。专注于软件研发趋势观察与优秀实践经验传播，整理并出版过多本软件研发实践案例图书。
黄震
资深敏捷教练、信息系统项目管理师。擅长敏捷开发方法和DevOps工程实践，并在元宇宙、外企金融行业大规模敏捷转型、数字化升级等领域拥有丰富的实施经验。专注于敏捷课件研发、数字化转型辅导、组织效能提升等。
王东喆
产品总监，敏捷践行者，长春敏捷社区组织者，中国DevOps社区志愿者。拥有20年toB领域软件研发、项目管理、产品管理、团队管理经验，致力于以业务价值为导向，构建有幸福感的高效能团队。擅长Scrum、KANBAN、XP、LeSS、Scrum@Scale、DevOps等实践。《看板方法官方指南》译者。
王英伟
某商业银行敏捷创新工程师，中国 DevOps 社区核心组织者，华为云MVP，云上软件工程社区技术专家，敏捷/DevOps咨询顾问。曾任职于电信、自媒体、互联网等领域的科技公司，历任研发工程师、技术经理、架构师、咨询顾问等，拥有丰富的开发、项目管理、DevOps实施经验。参与了《DevOps悖论》《SRE文 集》等图书或资料的翻译、审校工作。
刘陈真
敏捷教练。从事IT工作15年，专注于敏捷落地与实践、研发效能提升和质量管理，曾参与Expedia、穆迪、百丽、华为、汇丰银行等企业的IT项目交付和敏捷转型工作。拥有丰富的一线软件研发和企业敏捷转型项目经验。
巩敏杰
企业敏捷教练、系统组织教练，ACT（敏捷教练工具箱）Group Leader，敏捷社区组织者、志愿者和行业会议话题分享者。为公安、医疗、汽车、金融、互联网等多个领域的客户提供敏捷、管理、产品等方面的咨询辅导、培训和教练服务。
朱婷
高级信息系统项目管理师，中国DevOps社区核心组织者，银行金融业资深敏捷教练。深耕项目管理及敏捷项目管理领域长达12年，擅长团队质量管理提升与敏捷项目管理转型。
黄鹏飞
PMO团队负责人，敏捷践行者，资深项目经理。熟悉精益、Scrum、LeSS、SAFe、DevOps、效能度量等。技术出身，熟悉软件开发的各个环节，擅长从全局出发、从细节着手，陪伴个人和团队成长，助力企业和组织实现目标。拥有PMP、ACP、CSM、PBA等，以及ISO 2000内部审核员、华为云超级工程师认证。
你们的敏捷试点彻底失败了，大家对敏捷的价值充满了怀疑。
你们热火朝天地敏捷了半年，业务部门依然认为你们没有敏捷。
在你们公司，老板把敏捷当作一个让员工加班的手段。
多个敏捷小组互相依赖，互相指责，“内卷”严重。
人越招越多，但效率却越来越低，原来的密切协作氛围再也找不到了。
你们的每日站会没有任何价值，大家每天都在行尸走肉。
大家认为敏捷就是开会，浪费了大量的时间。
计划会开了半天，制订了一份大家都不认可的计划。
每天忙于“救火”，在缺陷中找缺陷，每天都加班，大家疲惫不堪。
你们的持续集成亮红灯了，但好久没人修复，也没人关心。
需求优先级不断调整，相互冲突，每天一个说法。
你们也在不断地总结回顾，但是问题依然还有很多。
你们搭建了工具链，强迫大家使用，但敏捷还是老样子。
你们花大价钱请了咨询团队，他们一走，你们立刻回到老路。
……
对此，你是否也心有戚戚焉？
你抱怨！
你困惑！
你迷茫！
你失望！
谁动了你的“敏捷”？
也许你自己说不清，也许你更期待高人能指点迷津，或许我们可以先回顾一下敏捷的发展简史，从敏捷先哲的探索之路中找到答案。
1967年，Conway提出了康威定律（Conway’s Law），他认为“系统的架构受制于产生这些设计的组织的沟通结构”。反过来理解就是“如果系统架构不支持，你无法建立一个高效的组织”。后来这条定律成为划分敏捷协同团队及产品架构设计的重要理论依据。[1]
[1]摘自头条号“振振有词abc”的文章《通过一篇文章来了解“敏捷”的发展历程》。
1970年，Winston Royce发表“Managing the Development of Large Software Systems”（管理大型软件系统的开发）论文，第一次正式描述了瀑布模型。如图0-1所示，瀑布模型将软件开发的各项活动规定为按照固定顺序连接的若干个阶段，一级一级，自上而下，形如瀑布流水，因此得名瀑布。
图0-1 瀑布模型
1974年，E. A. Edmods通过论文介绍了自适应性软件开发（Adaptive Software Development，ASD），提倡拥抱变化，借助协作和学习来应对复杂系统的开发。
1975年，Fred Brooks出版《人月神话》，提出软件开发“没有银弹”（No Silver Bullet），与此相关的软件危机问题激发起软件行业从业者对轻量级方法的探索。他提出的“Brooks定律”，即“投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟”，虽然没有得到大多数人认同，但依然抑制不住大家向落后项目中增加人手的冲动。直到后来，动态系统开发方法（Dynamic System Development Method，DSDM）提出了著名的敏捷倒三角形模型，强调有限时间、有限资源情况下，只做有限需求，需要对需求进行优先级排序，方才有所缓解。
1976年，Glenford Myers的著作Software Reliability（《软件可靠性》）出版。这本书阐述了一条“公理”——“不应该由开发者来测试自己的代码”，这意味着需要多个角色协作才能保证质量，这跟后期的“全面质量管理”运动不谋而合。
1980年，由Harlan Mills主编的文集对增量开发进行了实质性讨论。Dyer在文章中明确指出“软件工程的原则是，每次迭代完成的功能要尽可能地与其他迭代解耦”。
1980年，源于丰田公司生产系统的“可视化控制”（visual control）概念是“信息辐射器”（information radiator）的最早概念，现在我们经常提及的“基于经验的过程控制”的三大支柱——透明、检视和调整，其实都跟可视化直接关联。
1984年，随着对“瀑布”顺序式开发模式的批判，作为替代物的“增量方法”变得越来越突出。一个很好的例子是《软件工程中基于知识的沟通过程》中的一篇文章倡导使用增量开发，具体原因是“不存在完整和稳定的需求规格”。
1985年，Tom Gilb提出了首个有明确命名的、用于替代“瀑布”的增量开发方法——进化交付模型（Evolutionary Delivery Model），绰号是“进化”（Evo）。
1986年，Barry Boehm提出了“软件开发和优化的螺旋模型”，提倡通过合适的方法（尽管展示的“典型”例子是基于原型，但不仅限于原型法）来识别和减少风险。
1986年，竹内弘高和野中郁次郎在《哈佛商业评论》发表了他们的文章“The New New Product Development Game”（新新产品开发游戏）。这篇文章描述了一种类似橄榄球队工作模式的方法，即“产品开发过程是在一个精心挑选的多职能团队的持续互动中产生的，团队成员从头到尾都在一起工作”“这种团队自我组织、自我管理，有能力决定如何开展工作，并获得了根据自己决定做事的授权”。据说这篇文章是Scrum框架的灵感来源。
1987年，Ivar Jacobson成立Objective Systems公司。他吸纳了增量迭代的思想，开发出Objectory过程，并且把过程当软件卖，单份售价达到2.5万美元[2]。
1988年，“时间盒”（timebox）被描述为Scott Schultz的“快速迭代开发成型”法的基石，这种方法应用于杜邦公司的副业——信息工程协会。现在笔者在讲述Scrum框架的起源时会经常提到时间盒。[3]
[2]1美元合7.24元人民币。
[3]参考Cyh的博客文章《敏捷十年简史回顾——影响敏捷开发历程的27件事》。
1991年，James Martin在其著作《快速应用开发》中描述的RAD（Rapid Application Development，快速应用开发）方法或许是第一种把时间盒和迭代（较宽松意义上的“整个软件开发过程的一次重复”）紧密结合在一起的方法，第一次对时间盒进行了细节描述。
1992年，Larry Constantine在一次拜访Whitesmiths公司的过程中创造和报道了“活力二人组”（Dynamic Duo）这个术语，即“每一台终端前有两位程序员。当然，实际上只能由一位程序员操作键盘来编辑代码，但他们两个是并肩作战的”。这其实是关于结对编程最早的记录，现在我们经常用“你开车，我导航”来比喻，但是其中的核心是“并肩作战”。
1994年，在Rational公司工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后，Jacobson带着他的OOSE方法学也加入了Rational公司，一同参与这项工作。他们3个人被称为“三友”（three amigo），一起开发UML，最终提出了“Rational Unified Process”（RUP，Rational统一过程）及4+1视图模型。RUP的中心思想是用例驱动、架构为中心、迭代和增量。RUP过程如图0-2所示，共分成4个阶段—初始（Inception）、细化（Elaboration）、构造（Construction）和交付（Transition）。这项工作对整个业界造成了很大的冲击，因为在此之前，各种方法学的拥护者都觉得没有必要放弃自己已经采用的方法，而接受统一的流程，但RUP在国内外还是影响了很大一批人。这也是吸引我后来加入IBM Rational团队的关键点。毕竟在软件工程领域，虽然RUP最终败给了敏捷，但IBM Rational团队在方法论及工具方面的沉淀，还是独领风骚很多年，因此，RUP成为软件开发团队中流传最广的软件过程模型，也成为团队学习软件工程和实施过程改进的重要资料。
图0-2 RUP过程
1995年，Alistair Cockburn发表文章“Growth of Human Factors in Application Development”（应用开发中人类因素的增长），提出迭代方法会逐渐被接受的主要原因之一是软件开发的瓶颈正在转向（个人和组织）学习，并且人类学习本质上是一个迭代和试错的过程。
1995年，在OOPSLA’95会议上，Sutherland和Schwaber联合发表了一篇论文。该论文系统地介绍了Scrum方法，这标志了Scrum的诞生。Scrum框架目前能够成为团队级敏捷的主流框架，跟它对各种关键实践的兼收并蓄有着极大关系。
1996年，Kent Beck为了挽救Chrysler Comprehensive Compensation（简称C3）项目而创建了XP（eXtreme Programming，极限编程）过程。虽然Chrysler最终取消了该项目，但是随着Ron Jeffries和Ward Cunningham等人参与到XP的工作中，从此奠定了XP的历史地位。
1997年，Ken Schwaber描述了“每日Scrum站会”（Daily Scrum）〔这在其早期的著作中并未出现，如1995年的文章“SCRUM Development Process”（Scrum开发过程），这项活动后来被Mike Beedle重新整理到第一本Scrum图书中，成为现在广为流传的实践。〕
1997年，Alistair Cockburn受IBM公司委托，开展了一个关于团队规模的研究项目，正式提出了Crystal（水晶）方法。Alistair建立了一个二维坐标系，其中，垂直因素是舒适度（C）、可自由支配资金（D）、基本资金（E）和项目寿命（L），水平因素是“团队规模”，划分出不同颜色的水晶，用于代表不同的团队规模。对水晶方法的细分能够帮助团队更加高效地完成软件开发与项目管理，其中透明水晶（Crystal Clear）是敏捷小团队的适宜模式。
1998年，Jeff De Luca和Peter Code正式提出FDD（Feature Driven Development，特性驱动开发）方法。FDD方法非常适用于团队成员水平参差不齐的情况，因为最有经验的可以做主要编程人员。不过，如果一个小团队中大家的水平都差不多，可能会出现资源浪费的情况。
1998年，持续集成和“每日站立”（daily stand-up）被列入极限编程的核心实践。
1999年，Martin Fowler的著作Refactoring: Improving the Design of Existing Code（《重构：改善既有代码的设计》）[4]出版，对敏捷开发中的“重构”实践首次进行系统化阐述。
[4]该书由人民邮电出版社引进出版，ISBN：978-7-115-36909-3。
1999年，Kent Beck在其著作Extreme Programming Explained（《解析极限编程》）中创造了术语“大可视化图表”（Big Visible Chart），尽管后来他把此归结于Martin Fowler。
2000年，Ken Schwaber在美国富达投资集团工作时，试图为Scrum团队提供一个简单的工具包，于是发明了“燃尽图”（burndown chart），并在其网站上正式描述相关概念。
2000年，术语“团队速率”（velocity）被添加到极限编程，用于替代先前被认为过于复杂的概念——“负载系数”（load factor）。
2000年春，Kent Beck组织了一次会议，地点是美国俄勒冈州的罗格里夫酒店，参会者包括极限编程的支持者和一些“圈外人”，正是这次会议促进了后来在雪鸟滑雪场举办的聚会。在罗格里夫酒店的会议上，参会者宣称对一系列“轻量”方法论的支持，但没有发表正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程，其中很多都提到“轻量级方法论，如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现，没人真正喜欢“轻”这个名号，但这似乎是当时约定俗成的称呼。
2000年9月，来自芝加哥Object Mentor公司的Bob大叔用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期两天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖汇聚一堂。你们都被邀请了。如果你们觉得还有谁该来，请告诉我。”Bob建立了一个Wiki网站，大家开始在上面热烈讨论。很快，Alistair Cockburn通过一封书信加入了讨论，他表达了对“轻”这种提法的不满：“我不介意用‘轻’来描述方法论的轻重程度，但我并不愿意因参加一个轻量级方法学的会议而被看作轻量级的。这听起来有点像一群干瘦、低能且无足轻重的人在试图回忆起某个特定的日子。”关于会议地点的争论最为激烈。芝加哥让人不爽，既冷又无趣；犹他州的雪鸟，虽然也冷，但至少对那些想滑雪的人来说还挺有意思，像Martin Fowler，他在第一天滑雪时就摔了个脚朝天；加勒比的安圭拉岛，暖和又好玩，但路途太远。最后，还是可以滑雪的雪鸟胜出，不过有些人（例如Ron Jeffries）还是希望下次能去个暖和点的地方。
2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17位从事软件开发或者帮助他人从事软件开发的人相聚一堂，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是Manifesto for Agile Software Development（《敏捷软件开发宣言》）。参会者包括来自极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特性驱动开发、实效编程的代表们，还包括一些希望找到文档驱动、重型软件开发过程的替代品的推动者。如图0-3所示，由全体参会者签署的《敏捷软件开发宣言》成为重要标志，因为这么大一帮人能聚到一起实在不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心‘宣言’能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”从此，敏捷方法正式诞生。[5]
[5]摘自Scrum中文网的文章《敏捷宣言诞生记》。
图0-3 《敏捷软件开发宣言》内容（来源：敏捷宣言网站）
2001年，Ken Schwaber和Mike Beedle出版第一本Scrum图书《Scrum敏捷软件开发》。该书系统地介绍了Scrum开发方法，这标志着Scrum方法得到完善。回想2004年，笔者也是一边读这本书，一边带着团队尝试Scrum，可谓无知者无畏。
2001 年，Cruise Control 作为第一款“持续集成服务器”（continuous integration server）在开源许可协议下发布。它能自动监测源代码仓库，触发构建和测试过程，并把执行结果和测试报告档案发送给开发人员。（注：虽然Jenkins目前更流行，但是Cruise Control代表着持续集成实践的真正落地，在后面内容中会展开介绍。）
2001年，Bill Wake在一篇文章中指出敏捷团队所使用的两种不同喜好的估算——相对估算（relative estimation）和绝对估算（absolute estimation）。
2002年，计划扑克的当前形式在James Grenning的一篇文章中被列出，这正是2001年相对估算方式的落地实践。
2002年，Bill Wake的早期文章提到团队成员对于一些常用术语的理解可能不一致的问题，例如“完成”（Done）。这一概念后来被扩展为“完成的定义”（Definition of Done）。
2003年，Mary和Tom Poppendieck夫妇的著作《精益软件开发》将“敏捷任务板”（Agile task board）描述为“软件看板系统”（software kanban system）。同时，他们提出了精益软件开发的7项原则（消除浪费、内建质量、创建知识、推迟决策、快速交付、对人尊重和整体优化），第一次将精益理念系统地引入软件开发中。
2003年，Bill Wake在一篇文章中介绍了可以用于快速评估用户故事的INVEST（Independent，独立的；Negotiable，可协商的；Valuable，有价值的；Estimatable，可评估的；Small，小的；Testable，可测试的）检查单。该文章还为用户故事分解得到的技术任务改写了SMART的缩写（Specific，具体的；Measurable，可衡量的；Achievable，可实现的；Relevant，相关的；Time-boxed，时间盒的）。（需要注意的是，这里的T与一般的SMART中的T不一样。）
2004年，Kent Beck将“完整团队”（Whole Team）作为之前名为“现场客户”的实践的新名称。这应该是把“现场客户”纳入完整团队来看待了。
2004年，INVEST准则成为Mike Cohn的著作User Stories applied（《用户故事与敏捷方法》）中推荐的技术之一。
2004年，David Aderson的第一个软件看板系统在微软公司XIT软件维护团队中实施。这为后续看板方法的提出奠定了实践基础。
2005年，计划扑克技术在Scrum社区中开始流行，这归功于Mike Cohn的著作Agile Estimating and Planning（《敏捷估算与规划》）。这是制订敏捷计划的技术之一。
2005年，术语“Backlog梳理”（backlog grooming）开始流行。该术语最早的使用记录源自Mike Cohn在“Scrum开发邮件列表”上的观点。几年之后，这个实践才被正式描述。
2005年，Alistair Cockburn和Jim Highsmith领导的小组撰写了项目经理原则的增补版《敏捷项目管理》，向项目经理介绍敏捷开发方法。这本书对于敏捷社区的影响还是很大的，现在被美国项目管理协会（Project Management Institute，PMI）列为官方ACP（敏捷专业人士认证）参考资料之一。
2005年，Jeff Patton在文章“It’s All in How You Slice It”（这完全取决于你如何分割它）中明确表达了“故事地图”（story mapping）的概念，但当时并没有给出这个现在广为流传的名字。
2006年，Esther Derby和Diana Larsen创作的Agile Retrospectives（《敏捷回顾》）填补了敏捷回顾实践的空白。
2007年，敏捷社区发布了看板团队的几份实践报告。这些团队使用了一套称为“看板”（KANBAN）的特别修订方案：没有迭代，没有估算，持续地带着在制品限制的任务板。这些报告包括来自Corbis（David Anderson）和BueTech（Arlo Belshee）的报告。这其实也是对基于迭代的敏捷方法的极大补充，毕竟之前的方法论都是以迭代为主的。KANBAN方式提出这种基于流的工作方式，更加灵活，增量可大可小。对于不好制订计划的敏捷项目，这是一个福音。
2008年，Cem Kaner给出了“探索性测试”（Exploratory Testing）的一个新定义。这反映出这种测试方法在不断完善。
2008年，Agile 2008大会专门设置了一个论坛来讨论“用户体验”（User Experience）的相关实践，例如可用性测试（usability testing）、用户画像（personas）及纸上原型（paper prototyping）。
2008年，Jeff Patton的文章“The New User Story Backlog is a Map”（新的用户故事待办事项是一幅地图）图文并茂地描述了“故事地图”实践。
2008年，虽然最初提到团队开始使用“就绪的定义”（Definition of Ready）的时间是在年初，但第一次正式的说明似乎是从10月开始的，并且该术语很快就被纳入了“官方”的Scrum培训材料。
2009年，我携手许舟平老师，创作了国内第一本小说体敏捷著作《敏捷无敌》。该书以主人公阿捷学习敏捷的艰难历程为主线，展示了一个团队实现敏捷转型的全过程。
2009年6月，美国圣何塞，第二届Velocity大会上一次名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”（每天超过10次部署：来自Flick开发和运维人员的协作）的演讲轰动世界，后来几乎所有和DevOps相关的资料都会把这次演讲作为 DevOps 萌发的标志。这次演讲提出了 DevOps 的“一个中心，两个基本点”，即以业务敏捷为中心，打造能适应快速发布软件的工具（tools）和文化（culture）。
2009年，持续部署（continuous deployment）实践开始流行，尽管仍有些争议，特别是Timothy Fitz的文章“Continuous Deployment at IMVU”（IMVU的持续部署）。争议是什么不重要，但这篇文章不仅在敏捷领域变得非常重要，在创业圈也很火热，因为IMVU就是写出《精益创业》的Eric的创业项目。
2009年，Don Reinertsen创作的The Principles of Product Development Flow（《产品流式开发的原则》）揭示产品开发流的本质，并提出相匹配的175条原则，讨论了排队论、延迟成本、加权最短作业优先算法等。这本书对于后来很多规模化敏捷方法论都产生了深远影响。
2010 年，David J. Anderson 创作的KANBAN–Successful Evolutionary Change for Your Technology Business（《看板方法：科技企业渐进变革成功之道》）正式出版。该书的出版代表KANBAN方法作为一个正式敏捷方法论日臻完善。
2010年，《持续交付》的作者Jez Humble参加了第二届DevOpsDays并做了“持续交付”的演讲。从本质上说，《持续交付》中所提到的实践为开发团队如何与运维团队协作提供了最佳实践。如果《持续交付》早两年问世，也许就不会出现DevOps这个术语。然而，随着DevOps理念的传播，DevOps概念的外延越来越广，已经超出了持续交付本身所涵盖的范畴。
2011年，“Backlog梳理”实践升级为Scrum的官方元素，并被纳入The Scrum Guide（《Scrum指南》）。
2011年圣诞节过后的一场大雪，作为当年的初雪，比以往来得要晚一些，几个程序员在麦当劳的豪华包间里做出了一个艰难的决定：mv -f hudson jenkins（将Hudson迁移至Jenkins）。于是，影响整个敏捷界的持续集成工具Jenkins诞生了。这段历史充满了戏剧性，正所谓惹谁千万不要惹怒程序员。Jenkins的前身叫作Hudson，最初是由Sun公司在2004年夏天开发的（就是开发Java的那家公司）。2005年2月，Hudson开源并发布了其第一个版本。当时，Cruise Control在持续集成领域占有率排名第一。但是很快，大约在 2007 年，Hudson的占有率已经超越Cruise Control。2008年5月，在JavaOne大会上，Hudson获得了开发解决方案类的Duke’s Choice奖项。从此，Hudson成为持续集成的代名词。然而，2009年6月，Oracle公司收购Sun公司后，发生了一件令所有人都惊呆的事情。2010年9月，Oracle公司将Hudson注册为商标。这一行为在2010年11月被Hudson社区的核心开发人员发现，引发了他们的强烈不满。随后，双方进行了不太友好的谈判，不出意料地谈崩了。于是就出现了前面的场景。[6]
[6]摘自CSDN网站的文章《Jenkins简介起源介绍》。
2012年，敏捷大师Gojko Adzi在Impact Mapping（《影响地图》）一书中提出，通过Why→Who→How→What 4个层次的分析法，以结构化的形式显示业务目标（Why）和产品功能（What）之间的联系。这种方法可以帮助团队清晰地看到每个功能对实现业务目标的具体影响路径，确保团队开发的每一个产品功能都是有价值的。
2014年，Jeff Patton创作《用户故事地图》。他在这本书中对用户故事地图实践进行了系统化的阐述，为业界对产品待办事项的梳理方式打开了一扇新的窗口。该方法促进了不同角色之间的协同工作，并有效解决了长期困扰团队“只见树木，不见森林”的问题。
2017年，Janet Gregory和Lisa Crispin重新定义了“敏捷测试”（Agile Testing），这是对该主题首次提出的简洁定义，并且已经被敏捷社区广泛接受和认可。
1996年，Scrum of Scrums模式首次在IDX Systems（现为GE Healthcare）项目中实施。当时Jeff Sutherland 是该公司的工程部高级副总裁，而Ken Schwaber作为顾问，协助推广Scrum实践。该项目涉及8个业务部门，每个部门都有多个产品线。每条产品线都有自己的Scrum of Scrums。一些产品线甚至有多个层级的Scrum of Scrums。每条产品线都被要求在3个月或更短的时间内推向市场。所有产品线每6个月必须进行一次完全集成、升级和部署，以满足像斯坦福医疗系统等区域性医疗保健供应商的需求。由此可以看出，可以存在多个甚至是并行的Scrum of Scrums，而每日Scrum of Scrums站立会议也可以根据各自的焦点划分为独立的子会议。[7]
[7]摘自CSDN网站的文章《[Scrum模式语言5]Scrum of Scrums》。
2001年，最早提到Scrum of Scrums的出版物是Cutter IT Journal，同时它也出现在2011年的Scrum论文中。
自2005年以来，Craig Larman和Bas Vodde与多个组织合作，将Scrum、精益和敏捷开发扩展到大型产品组。他们将从这项研究中获得的经验和知识转化为一个名为“大规模Scrum”（LeSS）的敏捷框架草案。虽然许多思想领袖已经提出了这样的想法，但Craig和Bas认为，Scrum作为一个框架，具有有效采用敏捷所需的所有要素，而不管规模如何。因此，他们制定了LeSS，力求简洁，没有额外的术语或复杂的描述。
2011年，Dean Leffingwell作为SAFe（Scaled Agile Framework，规模化敏捷框架）的首席方法论专家，正式发布了 SAFe 的 1.0版。在随后的几年内，SAFe融入了敏捷、精益、系统思考、设计思维、精益创业、DevOps等核心理念，形成了四大核心价值观及十大原则，覆盖了团队、项目群、解决方案和投资组合 4 个层级。特别是敏捷发布火车（Agile Release Train）的概念和项目群增量计划会议（PI Planning）实践，在规模化敏捷方向非常具备代表性。（题外话：其实，Dean与RUP是有非常大的渊源的，因为他创立的RequisitePro公司被Rational公司收购，后来他成为IBM Rational的副总裁。在他推出SAFe时，社区有人戏言“曾经的RUP小子又回来了”，借此批评SAFe过于庞大、不够敏捷，不过这种看法因人而异。）
2012年，还在IBM Rational团队的Scott Ambler与Mark Lines提出了规范敏捷交付（Disciplined Agile Delivery，DAD）过程框架，这也是一个规模化敏捷框架。是的，你没看错，又是出自IBM Rational团队。当时，行业认为采用DAD方法会比传统的RUP方式在企业级软件生产与交付时拥有更高的效率，而且得到了Gartner的特别推荐。
2012年11月，知名敏捷教练Henrik Kniberg发布了一篇博文“Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”（Spotify的部落、小队、分会和公会式的大规模敏捷）。这篇文章及后面将介绍的Spotify研发过程、工程文化的另外两篇文章一起构成了“Spotify模式三部曲”，一时成为坊间要闻。创造了规模化敏捷的Spotify模式成为很多公司竞相模仿的一种形式。
2015年，Ken Schwaber对外发布Nexus规模化敏捷框架，并认为“规模化的Scrum框架（Nexus）仍然是Scrum”。这句话听起来很熟悉，因为另一个规模化敏捷框架宣称“LeSS也是Scrum”。
2016年，SAFe推出4.0版。该版本从收集到的案例数据中总结出在生产效率、产品上市时间、交付质量、员工满意度等多方面成效显著的方法。
2018年3月，CMMI 2.0明确提出支持敏捷。
2018年，Jeff Sutherland跟Scrum联盟合作，一起创作并发布了Scrum@Scale。它结合了最小可行的管理机构。这是Mozilla和Spotify推广的一种敏捷开发方法。
2019年8月，美国项目管理协会宣布收购DAD，算是在ACP认证之外补全了规模化敏捷。
2019年12月，SAFe推出5.0版，正式提出了业务敏捷的七大能力。其中，双操作系统概念令人眼前一亮，受到众多500强公司的追捧。在国内，SAFe的推广离不开李建昊老师的杰出贡献。他不仅最早创立了中国的SAFe社区，还发起了SAFe四季峰会，并培养了多位SPC（SAFe咨询师）。我也是那会儿成为SPC的。同年，Dean Leffingwell来中国，作为非时空交集的IBM Rational团队的同事，我、许舟平老师、Dean Leffingwell一起合影留念并交换了对敏捷的看法，如图0-4所示。与Dean一起回忆IBM Rational团队的往事和趣闻，我们依然有很多共同的话题。
图0-4 许舟平（左）、Dean Leffingwel（中）、王立杰（右）合影
2020年4月，Jeremiah Lee（Spotify前员工）在自己的博客中发表了一篇颇具争议的文章“Spotify doesn’t Use‘the Spotify Model’and Neither should You”（Spotify自己没有采用Spotify模式，建议大家也不要乱用）。真可谓一石激起千层浪。Lee回忆说，2017年他在斯德哥尔摩总部面试产品管理职位时，招聘人员曾告诫他不要指望 Spotify 是一个敏捷的“乌托邦”。加入公司后，他亲眼见证了公司的规模在18个月内翻倍至3000人。他认识到， Spotify 著名的Squad（小队）模式只是一种理想状态，而且该模式从来没有完整实施过。他还观察到，随着公司领导逐渐转向更传统的管理结构，组织内部出现了混乱。
2021年7月，备受期待的《项目管理知识体系指南》（PMBOK）第七版正式发布。新版本增加了与敏捷相关的内容。据称，在新的PMP考试中，敏捷将会占据一半内容。这可以说得上是一次极大的革新与颠覆，打破了唯项目管理讲项目管理，纳入了许多通用管理学、管理心理学、产品设计理论的知识和理念，例如，新版本中提到了“神奇的数字7”，建议敏捷团队的成员数量最好控制在7±2。
敏捷的发展简史终于回顾完了。我肯定还遗漏了很多内容。不知道你有没有注意到，许多人为了寻求“敏捷”，一直在坚持不懈地努力，或自己亲身实践，或帮助他人，他们的脚步从未停止。毕竟，“敏捷”只是一个目标，其实，我们所有人都在追求“她”的路上。
Being Agile（持续敏捷）!
现在你明白谁动了你的“敏捷”吗？
其实没有其他人，那个人只能是你自己。
在这个不断变化的世界中，“敏捷”也在不断演变。无数的人正在创造无数种“敏捷”。
或许你不信，接下来我们会给你讲一个叫“敏捷漂流记”的故事，里面有很多有趣的敏捷江湖人物，他们都特别喜欢玩一种叫“漂流瓶”的游戏，每次遇到奇遇，就会用自己的独家心法写出来，放入“漂流瓶”，发布于敏捷江湖，以求扬名立万。
让我们一起去捡起这些漂流瓶吧。
属于你的“敏捷”没准会出现在这些漂流瓶中，也可能在你自己之后的行动中，还可能来自你自己的思考。无论如何，只要你保持开放的心态，享受求知之路的乐趣，一定会找到属于自己的“敏捷”。
王立杰
中国DevOps社区第一届理事会主席
江山代有人才出，各领风骚数百年。
自17位敏捷大师共同签署《敏捷软件开发宣言》以来，为了更好地推广敏捷，其中的10位大师出面组建了敏捷联盟，同传统的开发方法论形成掎角之势。敏捷联盟提倡采用敏捷纪元法后，影响力日盛，这让“敏捷”二字在江湖上引起了不小的震动。面对这股新兴的力量，各大门派的反应各异，有拒绝的，有观望的，有不屑的……唯有中小门派有研习的，有欣然纳入囊中的，亦有半遮半掩的。各家态度截然不同，不乏一些精心研究的，已然小有所成。更有传言：得敏捷之真经者得天下。此话一出，瞬间引起江湖中的新一轮骚动。
在东华胜州，研习敏捷的门派日益增多，并逐渐形成不同分支。其中以Scrum分支的门徒最为众多。Scrum门徒乐善好施，毫不吝啬地传授和与人切磋，并形成Scrum联盟，势头已经盖过早几年成立的敏捷联盟。在敏捷联盟日渐式微的情况下，Scrum联盟本可一统江湖，奈何因为利益与正统之争，内部出现了分裂，又搞出了几处分舵，相互制衡，让其他门派看足了热闹。
见此情景，敏捷联盟想重振敏捷雄风，计划3年后举办一场敏捷武林大会，届时，将要评出十大敏捷门派，同时会选出一位敏捷盟主，以号令整个敏捷江湖。在这场敏捷武林大会上，比拼的不仅仅是内力和剑术，同时还有人才储备，而敏捷力更是重中之重。研习敏捷的小门派逐渐壮大，他们放出狠话，誓要把守旧的十大门派挑下马。各大门派已经按捺不住，争相派人学习，不甘落于人后。
天泽观，掌门秦冲玄，该派第十代传人。虽天泽观的弟子300有余，但秦掌门的宝贝女儿秦倩唯独对敦厚老实的大师兄郭宇飞青眼相看。秦掌门见女儿属意，也愿意成人之美，已将二人亲事定下。作为近年迅速崛起的一个门派，天泽观想借本次敏捷武林大会一举扬名，故对本次大会尤为重视。周逍遥是秦掌门的师弟、秦倩和郭宇飞的师叔。该人性格豪爽，武功高强。虽然一把年纪，但童心未泯，未曾娶妻，更是把秦倩视如己出，呵护有加。秦倩曾秘密拜访Scrum的创始人，并在其隐退之前跟随学艺数年，现已深得其真传。
白云轩门主萧楚费尽心机把师叔俞邦风请出山，打算利用其与17位敏捷大师的往日情谊，邀请几位大师来做白云轩的客卿，以大力发展教派的敏捷力。俞邦风虽然白发苍苍，但是童心未减，喜欢热闹，同时酒量惊人。萧楚这些年没少闭关，意图修炼一部新的功法，将日常事务交给门下大弟子丘仁和打理。萧楚的妻子汪蓉爱好敏捷，熟知各大门派的敏捷心法，对各家独到之处相当了解。针对门内敏捷导入事宜，萧楚经常咨询汪蓉的意见。
天仙阁属于闲散帮派。阁主向宫筱多年前便把帮派事务交给了4位长老。长老们不遗余力，将帮内事务打理得井井有条，然而，随着时代的发展，新兴事物层出不穷，在应对环境的变化上，长老们难免因循守旧，不够开放，导致近几年天仙阁的发展停滞不前。向宫筱和长老们商量，决定趁着准备参与本次敏捷武林大会的时机，大胆培养和起用新人，将新思想落地，以期大展宏图。帮内大弟子张衍，虽出身平民，但勤奋好学，武功精进神速，被寄予了厚望。
丹鼎院院主祁粱头脑聪慧，凭借对炼丹的钻研，在炼丹行业打开了一片天地，成为新一代的炼丹宗师。丹鼎院研制的丹药不仅可以延年益寿，而且能够大力提升敏捷力。这些丹药只有预约才能买到，而且售价已经翻了几番。祁粱膝下有三子，各有所长：长子祁云江继承了父亲的炼丹技艺；次子祁云海自幼不喜炼丹，早早离开丹鼎院，拜入昆仑门下，学习刀法；幼子祁云天唯独对各种游戏感兴趣，天赋超人。
造物派擅长造就各种奇妙机械，在新门主诸葛和诚的带领下，这些年发展迅猛，门内弟子更是精英辈出。这些弟子不仅理念超前，更是因为制造的敏捷工具而在江湖上声名显赫。
乌羌派是东华胜州的小众门派之一，其掌门人达瓦尔年仅二十二，野心勃勃，麾下猛将如云，多骁勇善战，但早年因缺少谋略之士，并未在江湖上引起重视。自从在一次敏捷盛会中求得敏捷教练戈尔霍的辅佐，力推敏捷变革，乌羌派的战斗力迅速提升，成为江湖上一股不可小觑的力量。同时乌羌派接连向其他门派发起挑战，力图一统江湖。
渡真门，传言乃是若干年前从西域迁来的门派，寓指渡到东方，寻求真经。掌门吴启贤已经是第八代传人。该派的门人虽然不多，但均是智谋超人之辈，常被其他门派邀请担任客卿，影响力颇大。门下弟子中，唯属刘雁依最为出色，号称“智多星”，对敏捷力的领悟之深，俨然有直追17位敏捷大师的势头。
雪月城，城主司空长风，江湖人称枪仙，司空千落的父亲，萧瑟的师父，前任朱雀守护，手持乌月枪。司空千落，继承父亲“银月枪”，性格直爽泼辣，敢爱敢恨。对萧瑟一见倾心，再见定情。萧瑟，北离六皇子，永安王，手持无极棍、天斩剑。
黑风崖，乃南派新秀，位于南方临海一处神秘地带。所谓海纳百川，近年来此地依托独特的海域风光和创新包容的文化氛围吸引了大批武林后起新秀，其中以陈峰、叶不凡和楚天等敏捷实践派人物尤为亮眼，与之相邻的桃花山庄在其带动下也混得风生水起，成为江湖英雄们谈酒论道的好去处。
除了这些新兴门派以外，丐帮、武当、少林、峨眉、华山等传统门派亦对本次敏捷武林大会非常重视，从掌门到弟子，均摩拳擦掌，精进武功，发展敏捷力。
正所谓天下大势，分久必合，合久必分，敏捷江湖风云起，数风流人物，还看今朝。备战敏捷武林大会期间，各门派均使出浑身解数，精进武功的同时大力发展敏捷力，“敏捷漂流记”的大幕就此拉开。敏捷能否如滔滔洪流席卷江湖，掀起波澜，让我们拭目以待。
作者：黄隽
秦掌门闲来无事，在天泽观所在的天泽岛上搞了一个互联网项目，从江湖上招募了10名侠客，组建了“天泽真经游戏”项目研发团队，研发地点就设在天泽观。新团队采用了江湖盛传许久的敏捷方法，不过每天早上开站立会议时经常有人迟到，迟到的时间为3~8分钟。对此，秦掌门束手无策，恨得牙根痒痒，要不是因为互联网时代的舆论汹涌，这几个迟到的家伙应该不知道吃了几次“天泽白骨爪”。因为这件事，秦掌门闷闷不乐，起初每逢夜幕降临，面对大海还会吹起“天泽索命曲”，到后来连箫都懒得拿出来了。
回岛省亲的秦倩看秦掌门天天如此焦虑，暗暗察访了一番，了解到图1-1所示的内幕。
图1-1 秦倩了解到的内幕
待摸清内幕后，秦倩飞鸽传书，直接找到足智多谋的敏捷界一姐赵敏。
不到一日，赵敏的回复如下。
秦倩看过信后，茅塞顿开，觉得“天泽真经游戏”项目研发团队真正的问题是如何解决迟到现象，不浪费时间给迟到者同步信息，如何做到遵守时间盒和提升每日站会的效率。
于是，秦倩亲自下厨做了几道小菜，翻出一坛桃花酿，请秦掌门小酌，随后与其确定了几个练功心法的优化方案。
方案一：秦掌门首先召开一次针对经常有人迟到现象的沟通会。侠客们在回顾会议上可以认真分析原因，重新征求意见。
大多数人更喜欢在开始工作之前召开每日站会，讨论完谁在做什么之后投入工作。然而，人们不是同一时间到达天泽观的，得找一个适合所有人的每日站会时间。
为什么每日站会的开始时间一定是日出9时？凭什么非要听秦掌门的？经过讨论，大家选择了9时。
方案二：促进侠客们形成自觉按时到场的意识和尊重别人的意识。大师兄（会议主持人/Scrum Master）要按照预定的时间、地点准时开始会议，而不管其他没有到场的侠客。另外，每天同一时间、同一地点也有助于养成准时参会的行为习惯。
方案三：即使有侠客迟到，也不要同步信息给迟到者，否则会传递“可以迟到”的信号，同时这也是不尊重他人时间的表现。（毕竟正常准时参会的侠客已经知晓这些信息。）
方案四：对于经常迟到的侠客开展谈话活动，尝试理解他们的问题，以及是否有真正的困难，关心团队成员，一起帮助解决困难。
方案五：建议为迟到的侠客准备一些“奖励”，例如发红包、倒立、请全体喝下午茶等。这些“奖励”的措施和数量由全体侠客事先共同商定。如果是发红包，如何支配由团队共同决定，避免由秦掌门或大师兄决定并让团队执行。相比别人给出的规则，大家更愿意执行自己制定的规则，履行自己的承诺。如果说发红包和请全体喝下午茶这样的“惩罚”对某些“土豪”来说缺乏约束力，那么可以考虑把“惩罚”做到可视化。例如，在天泽观的墙壁上划定一个特定区域，每次迟到就在该区域贴上迟到者的画像，次数累加。这个特定区域作为迟到信息的扩大器，可以让更多的侠客看到。俗话说“人要脸，树要皮”，相信会使某些人有所收敛（此方法要多考虑成员性格是否开朗，避免过度伤害其自尊心）。
方案六：如果迟到现象严重到团队无法解决，可以试着从天泽岛岛规方面着手，严格执行岛规。这虽然是不得已的措施，但并不符合敏捷的自管理思想，也不是真正解决问题的最佳方法。侠客们应该深刻理解每日站会的价值，自组织并积极参与每日站会，这才是根本之道。
处理完这次小风波后，侠客们对每日站会的热情被彻底激发，再也没有发生迟到的现象。秦掌门终于重拾箫，一口气谱出了“每日站会交响曲”，同时对敏捷每日站会有了新的感悟。
那么，该如何让新侠客们理解每日站会的重要性呢？
或许，以后新侠客上岛后得先参加一次针对基本功的培训活动。
首先，让新侠客理解每日站会是一次检视、同步和适应性制订每日计划的活动，可以帮助自组织团队更好地完成工作。通过参与每日站会，侠客们可以了解项目进展，知道发生了什么事情，冲刺目标的进展，以及当天工作计划的调整和可能遇到的问题或障碍。有些侠客可能认为每日站会是用来解决问题的，是传统意义上向秦掌门汇报练功状态的会议。这些理解其实都是不准确的，或者说误解了每日站会的核心意义和价值。
其次，要让他们理解每日站会对于集中精力在正确的任务上是十分有效的。在团队成员面前作出的承诺往往能够促使侠客们更加认真地对待自己的责任。通过在团队成员之间形成一种精神激励，可以增强成员对每日工作目标的承诺。此外，每日站会还可以保证大师兄和侠客们可以快速识别和处理障碍，培养团队协同作战的文化。这种文化让每个成员都意识到“整个团队在一同战斗”。
