“AI助手”助力行业升级换代

Ehm说：“工程人员喜欢反复钻研，但是要想真正发挥工具的潜力并将其引进流程中，这是艰苦的工作，你必须在变革流程上孜孜以求。如今，我更加关注员工本身，更加关注如何使他们处在一个将技术发挥到极致的场合。”

3. 拖沓的会议

敏捷实践放弃了冗长的正式会议，转而倾向于短暂的集体会议和类似的活动，但是积习难改。例如，Ehm说，他发现，一些本该持续15分钟的Scrum会议却持续了45分钟之久，与会者利用这段时间来解决所有它们所关注的问题和话题。

Ehm说：“会议必须有一个非常具体的目的，但很多人对此并不习惯”。他说，管理者需要让团队知道这样一件事，即在采用敏捷方法并需要管理者强行对时间和话题施加限制时，那就要让他们知道会议真正的运作方式。

Ehm说：“现在，我们在会议上仅讨论一件事。”

4. 只要能自由选择工具和流程就永远能提高速度

尽管现代实践鼓励各个团队选择适合自己的方法，但美国运通全球商务旅行(American Express Global Business Travel)的工程总监Amit R Bhandarkar却认为这种方法存在弊端。

Ehm说，他的团队最终使用了不同的持续集成/持续交付(CI/CD)工具，其中一些工具使用开源的解决方案，而另一些工具则使用由不同供应商提供的产品。“他们以不同的方式实现了相同的结果并且影响了敏捷性;Bhandarkar说：“有些团队表现十分出色，而另一些团队则在苦苦挣扎。”

作为回应，开发团队进行了标准化，转移到一个高度一致的环境中，这个环境能维持高度一致的成功率并减轻了开发人员的维护负担。

Bhandarkar认为这是一个经验教训。“只要有选择，你就必须对自己的方法进行规范;无论这是你想要的特定方法或是冲刺的时间，你都希望保持规范性和一致性，以便每个人都彼此同步”，他这样说道。

5. 我的团队足够灵活

贝恩公司(Bain & Co.)的合伙人兼《正确实施敏捷方法(Doing Agile Right)》的合著者Steve Berez曾经与一家航空公司合作，该航空公司需要工程师为飞行操作创造各种新的功能，同时需要减少客户系统的工作。但是能够进行飞行操作运营的工程师数量有限，这使IT部门对不断变化的业务需求的响应能力大大降低。

Berez说，这是一个十分普遍的问题，他还补充说“工程师不是说取代就取代的。”

Berez说，首席信息官可以通过在业务的不同部分增加对通用技术的使用以及对员工的交叉培训来解决此问题，以便员工可以使用多种技术。

Berez解释说：“这往往意味着使用微服务进行新的开发任务并对那些微服务使用相同的开发语言，即使在不同的功能领域也是如此。”

6. 该规则不适用于我们

与所有方法一样，敏捷框架主张使用一系列最佳实践。

但West发现许多组织并不遵循某些规定的流程，它们认为自己不受这些流程的限制——之后却想知道自己为什么没有获得期望获得的好处。

例如，West已经发现组织从敏捷团队中排除了一个特定的业务组(例如市场营销)，理由是这在他们的公司中是行不通的，因为他们的流程太独特了，而实际上这只是一场没有人愿意为之奋斗的地盘之争。

（编辑：阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!