敏捷宣言是通用的，但在制定细节时，敏捷实施的上下文是关键。为了有效采纳它，你需要知道你希望实现什么？所以，需要思考“我们如何根据期望的结果，结合最好的实践，创造一个个性化的成功秘诀？”
2004年公司让我做项目经理，带着20多个人开始做产品，但没做到一年我提出不做项目管理而去做技术专家的请求，因为我不喜欢管理，特别是管人。但2009年我开始学习并践行Scrum之后，我喜欢上了Scrum，从而喜欢上了敏捷，这也带给我了很大的改变，还践行了敏捷个人。Scrum的确是目前谈到敏捷中常说的一个框架，但就像我说企业架构、业务需求学科一样，其实没有独立存在的银弹，要解决客户的问题、激发客户的潜力，这都是多学科的综合体。最佳实践也都不是固定不变的，随着不同项目、不同企业上下文的变化，最佳实践本来就应该是因地制宜的。
下面给大家列举几个不同的敏捷项目来理解一下“敏捷宣言是通用的，但敏捷实施是不同的”。
01 自组织扩展以加快价值交付
敏捷软件开发团队的工作做得很好，但如果团队间依赖较强，而某个团队的交付速度不够快的话，可能价值交付就会遇到障碍。如果你在一个大的组织或企业，必须多个团队协同工作，那这种情况下，通过协作网络利用团队的力量是成功的关键。
案例
某银行进行转型，需要数字化信息系统。该机构需要通过重新设计和重新构建一套关键系统来提高他们为企业内部和外部客户提供服务的能力。在用一个团队验证了他们的方法后，企业迅速扩展到8个协作敏捷团队。
最佳实践
1. 一个Backlog
为每个系统维护一个单独的Backlog，以便所有团队在优先级和未来计划上保持一致。
2. 共享代码所有权
为每个系统维护一个单一的、共享的代码库，培养任何团队在代码的任何领域都可以工作的能力，并使用持续集成和部署（CI/CD）来获得技术决策的快速反馈。
3.减少依赖关系
有意识地组织工作以减少特性和团队之间的依赖性，并加速交付。
4.有效的可视化
清楚地显示每个团队和每个团队集合的所有工作，以便团队成员和利益相关者能够快速、轻松地识别状态（和障碍）。
5.团队自选
在组建新团队时，允许团队成员自组织和协作平衡所需的技能。这种加速的凝聚力培养了共同的身份，并创造了一种主人翁感。
6.加速学习的实验
将潜在的改进设想为实验，将它们可视化，让所有小组都能看到，并在小组中传播积极或消极的结果，以加速学习。
7.基于结果的指标
使基于团队的指标与期望的结果保持一致，并允许团队在如何最好地捕获和报告这些结果方面具有灵活性。
8.大规模Scrum节奏
通过一致的计划、进度和识别潜在改进的节奏，保持团队之间的凝聚力。
02 敏捷BI更快更好地做出决策
为了最大限度地提高效率，组织必须将其数据转化为信息。BI允许在当今复杂的环境中进行快速调整和预先解决问题。敏捷原则和实践可以帮助您构建满足您对可操作BI的需求的解决方案。
案例
某汽车集团架构规划部需要更好地了解其投资，更快地回应公司的询问并推动持续改进。通过敏捷BI可以改变了使用数据驱动决策的方式。
最佳实践
1.基于假设的实验
制定关于潜在技术和数据结构的假设，探索替代方案并评估结果，以确定最佳选择和设计决策。
2.快速成型
向用户呈现不同的格式和不同的可视化效果，以确定如何最有效地为他们提供所需的智能。
3.数据治理
为跨源系统的数据元素创建数据标准，以增强信息共享，加快智能生成并减少潜在的混乱。
4.Scrum框架
利用Scrum活动的规律性来计划工作，获得进度反馈，并改进流程。
5.看板
通过可视化和有限的工作来增强Scrum。这样可以提高注意力，加速交付，并使团队能够更轻松地处理与某些工作相关的不确定性。
6.管理变革
通过参与、演示和开放式活动确保新工具的顺利采用。
03 从客户驱动转向价值驱动
市场和客户不断变化，营销和沟通团队面临挑战，需要不断驾驭不可预测性和快速变化的优先事项。看板（Kanban）是一种依赖于可视化和有限在制品（WIP）的管理方法，适合于参与市场营销、沟通和其他快节奏学科的创意团队的连续、流动的工作流。
案例
某快消品企业有了一个思维转变：当价值驱动决策时，客户和团队都会更快乐。于是希望通过敏捷转型能够建立更快更顺畅的工作流程，提高沟通和团队效率，并清晰简洁的描述他们未客户带来的价值。
最佳实践
1. 看板
集中定位团队工作流程的物理可视化。
2. 看板卡
在看板板上定制卡片表示团队的工作，简要描述价值、优先级、交付时间、涉及的团队成员以及开始和结束日期。
3.明确的政策
明确定义工作流程的团队基本规则
4.在制品
在任何给定的时间内，限定工作流特定部分中的项目数，以保留容量并改进焦点和流动。
5.每日站立
一个15分钟的简短会议，回顾工作状态，突出障碍，并确定一天的计划。
6.即时交付
在工作产品完成后立即为客户提供价值，以提高响应能力和满意度。
7.度量
关键数据点的可视化，允许更明智的决策，例如不同类型的工作通常需要多长时间，何时采取新的举措，以及如何最好地组织起来完成这些任务。
8.回顾
每周一个小时的会议讨论潜在的改进和如何实施。
IT帮在第一季布道课中讲过一次企业级敏捷的课程，其实就能看到我们讲的并不是规范的方法，而是要综合考虑各种团队级敏捷方法（Scrum、看板、Lean、XP）与规模敏捷框架。就像我在 数字化转型两大抓手：产品敏捷+企业架构 中提到的，甚至还需要企业架构、产品管理、业务需求等学科来共同帮助我们的客户实施敏捷。
IT帮相信技术和方法的存在是为了解决挑战和发展思维，我们可以帮助您和您的组织找到更适合的敏捷组合。
作者：周金根，一个在企业架构、业务分析、软件需求、敏捷研发、自我管理、创新思维等多个领域构建体系，并自在快乐、勇于践行的布道者。资深教练和培训讲师，致力于通过践行并持续完善IT帮体系方法，帮助客户激活面向未来的能力。
推 荐 导 读
