在前几篇文章中，我们讨论了敏捷性的定义和管理敏捷性的潜在矛盾。作为解决方案的一部分，我创造了 "管理良好的敏捷性"这一短语。有人问我为什么在这个短语中使用 "良好 "一词。简而言之，任何人都可以说 自己是敏捷的。任何人都可以说 自己管理敏捷。但关键是两者都要做 ，而且要做好 。
关于如何做好一般管理，我将留待以后再谈。今天，我将专注于变革过程的管理。
管理敏捷性最重要的部分是由一个人（或一个团结协作的小团队）负责敏捷性。理想情况下，这个人（我称之为敏捷管理者）应该具有足够的知识和敏感度，能够理解以下几点
1) 利益相关者想要什么、
2) 利益相关者需要什么
3) 实现上述两点所涉及的问题。
项目对敏捷经理的要求很高。它要求敏捷经理能够深入利益相关者的内心，真正了解他们不仅想要什么，还需要什么。有时，甚至连利益相关者自己都不知道他们需要什么，直到他们看到了（或错过了）。敏捷性经理还必须了解在实际满足这些需求（包括截止日期）的过程中，开发方面存在的问题和权衡。
一些常见的敏捷性挑战包括
- 建模的系统发生变化（可能是设计发生了变化，也可能是 "假设 "的方面刚刚被发现）
- 利益相关者的目标发生变化（日期、建模细节、建模目的）
- 发现建模问题（建模或数据收集可能比预期更困难）
诸如此类的变化往往会使当前的计划失效。当然，利益相关者希望得到这一切，而许多认真负责的建模人员也希望说 "是"，以满足利益相关者的要求。
要做好这项工作，敏捷性经理必须了解上述所有方面，并能从更广阔的视角来确定哪种行动最符合利益相关者的要求？例如，在没有时间或资源的情况下，增加功能 A 与更彻底地实施现有功能 B。或者，当项目进度落后时，是安排额外的工作、删除某些功能，还是推迟交付日期？只有知识渊博的管理者才能通过仔细权衡每项行动的好处/回报，正确做出这些决定。
更妙的是，最有效的管理者会尽量避免做出类似上述的重大决策，而是对日常出现的无数类似的小决策做出正确的判断。在今后的文章中，我将讨论 "例行公事 "的管理，以及一些有助于实现这一目标的工具和流程。
戴夫-斯特罗克
产品副总裁 -Simio LLC