已经 快到年终岁尾了，此时InfoQ 编辑以及其他人被问及敏捷的状况，结果我们就把那些意见整理在此。
“敏捷”现在已经是一个全球认可的品牌，这个术语首先于 2001 年在软件开发领域提出，它已经推动了软件构建方式在全球的变化。在其核心，敏捷是关于构建产品的、需要强化训练的一种方法，它认为软件开发是一种协作活动，需要人的创造力、沟通和想象力，那样才能够成功。
最近我们在包括 InfoQ 编辑、顾问和培训师的人群中做了一次小型调查，询问他们对采用敏捷的状态的看法，以及在 2014 年底，哪些想法、实践和技术正在兴起或者被认为有用。这并非是很科学的研究，更多是意见的信息收集。
以下是我们收到的反馈中需要着重关注的一些点：
- 在创新采纳曲线方面，敏捷的采纳已经“越过了那道鸿沟”，处于主要阶段的早期，大多数组织至少在某些软件开发项目中使用敏捷技术，还有少数已经把敏捷作为主要甚至是唯一的开发方法，他们已经完成了思想上的转变，而且具备强大的技术实践，并肯定已经在推向市场的时间、产品质量以及客户满意度方面看到了可以衡量的改进。
- 软件匠艺是一个热门话题，人们意识到，如果没有很强的技术实践，那么做敏捷将会是一场灾难。
- 在很多组织中，人们认为经理和高管层是采纳敏捷的阻碍——领导力文化、思维和命令 - 控制式的管理风格会扼杀创造性。
- Web 和移动技术对于创建跨职能的特性团队（例如：专门研究用户体验、前端 UI 开发、Android/iOS/Windows 移动平台的等）提出了挑战。
- 对于很多组织来说，采纳敏捷的第二轮风潮正在逼近，这次会专注于规则和技术实践，重点是“这次要合适地完成”。
- 使用回顾会议来真正做检查和调整，会让团队和组织变成学习型实体，并采用持续改善的方法。
- 在很多层级上大规模都是一种挑战——需要指出哪里需要调整，在采纳的深度和广度方面都意味着什么，如果有的话，在大量不同的大规模框架中应该选择哪个。可选的框架包括 Scrum 之 Scrum、LeSS、DAD、Spotify 的部落模型、squads 和 guilds。
- 大型项目的时代已经要过去了，慢慢变成基于流程而不是大爆炸驱动的样式，或者是迭代式的敏捷。
- 敏捷实践和原则开始在 IT 部门中传播，而业务敏捷在接下来的几年间将会是热门话题。
- 评估还是一个热门话题，不需评估的方式尽管获得了一些推动，但在大多数组织中还是很大的挑战。
- 预算之外（Beyond Budgeting）以及 Stoos 网络也获得了一些推进，可能在将来会成为可用的管理方法。
- 看板越来越常用，可能是与敏捷一起使用（例如 Scrum 板），或者作为一种单独的方法，来改善开发团队内外部的工作流程。
- 更广泛的项目管理社区开始理解为什么敏捷方法能够支持人们达成更好的项目产出。他们开始把握采纳敏捷实践给传统项目管理方式在工作和度量成功方面所带来的变化——从三个约束到敏捷价值的三角。
- Portfolio 看板和其他 PMO 级别的方法已经开始缩短关于项目优先级和资金方面的决策过程。
- 精益创业正在走进企业，有些组织采用了“试验思维”来设计敏捷的试验，设计思维和精益项目需要假设测试和“分析”，用来直接从已经实现的系统获取信息。
- 出现了越来越多的认证项目，很多相互竞争的认证都提供了类似地证书： ICAgile、Scrum.org、PMI-ACP、看板大学、SAFe、Scrum 联盟、DSDM 等等。
- 互联网设备（包括可穿戴设备）将会以无法想象的方式影响开发团队。最大的影响之一会在测试社区中——测试的复杂性会提升一个数量级，那会强烈推动更多的自动化测试来应对这种状况。
- 开发活动之外的敏捷意味着，保持工作流程存在于团队中会有更大压力，那会造成影响，使得组织从基于项目的资金支持转向产品或特性的资金支持。
- 类似地，更快开发的能力意味着 DevOps 将会成为组织必需做的工作，因为他们想要利用来自于快速开发所带来的敏捷性。
有这么多值得期待思想需要关注，但在信息技术和业务敏捷性方面，2015 年都将是敏捷的好年头。
以下这些人都贡献了自己的观点： Shane Hastie、Glenda Mitchell、Horia Slușanschi、James King、Steve Barrett、Craig Smith、Katherine Kirk 和 Ben Linders。
评论