“敏捷” 的三个指导原则
2025年03月24日
来源：
博洋达（深圳）咨询有限公司
CMMI高级认证中经常会提到敏捷，但我们必须知道的是：敏捷更多的是关于集体思维和团队文化，而不是关于离散的支持过程。许多敏捷驱动的项目都缺乏人们机械地走过场而没有理解和积极应用敏捷真正精神的能力。
根据不同敏捷团队的经验，深圳博洋达总结出了以下三个原则，帮助团队更好地实施敏捷。
原则1 ：持续不懈地管理业务目标，而不是任务
可以问问自己为什么企业关心这个问题。这虽然是个基础性地简单问题，但我们鼓励管理者不断挑战他们的团队，要求他们回答每一个功能请求和用户故事。虽然这看起来有点过头了，但在整个开发生命周期中提出这个问题可以帮助团队养成强化流程本身这一最终目标的习惯，有助于推动团队和外部利益相关者之间的协调。
例如，我们经常与客户合作，帮助他们实现技术堆栈现代化，帮助他们将应用程序迁移到容器编排或云原生平台。这虽然看起来像是一个目标，但实际上是一个实施细节，而不是我们可以衡量或跟踪的业务成果。要明白工具或技术是服务于业务目标的。
原则2 ：工具和流程应该促进交互，而不是阻碍
工具是达到目的手段，是为底层流程服务的工具。成熟的流程依赖于工具，但并不从属于工具本身。无论是简单的看板还是先进的项目管理系统（例如禅道项目管理软件），我们经常会看到很多团队只是将这些工具用作于描述“跟踪工作”情况。
如果没有完全成熟的流程，即使是最好的工具，都会让团队缺乏驱动工作的业务目标的动力。
敏捷的Scrum Master应该努力帮助他们的团队不断学习和探索：如何最好地服务于更广泛的业务目标。比如用于修正方向的过程指标应该是什么？需要的反馈来自哪里？应该多久收到一次反馈？团队和组织应该能够在不破坏现有地整个流程之下，合理地适应不断变化的需求。
原则3 ：关注“What” ，而不是“How”
最小可行产品(MVP)的概念是敏捷方法论的基础。推动 MVP 的目标是向用户提供新的软件功能，同时收集和整合反馈以继续改进产品。不过，由于团队负责人经常在不同的团队中工作，并考虑到不同的最终用户，因此此流程很容易与既定的业务策略不一致。
一个团队可能负责探索一种新产品或服务方法，并将使用精益/MVP 工具来确定解决方案。另一个可能强调在现有产品中添加或增强功能，而第三个可能负责改善开发人员体验或基础设施。
在敏捷的背景下，认识到工作开发方式的差异至关重要，尤其是考虑到组织内的工作节奏。我们经常看到基础设施自动化、站点可靠性和平台工程工作被硬塞到两周的 Scrum 节奏中，而工作的性质并没有完全落入两周的增量。
关键词：
敏捷,CMMI高级认证
相关新闻
请留下您宝贵的意见，我们尽快联系您