There’s a million methodologies that can be used to deliver software. 您选择的工具集将根据您要解决的问题而有所不同. And occasionally you’ll blend different approaches to find the process that’s just right for you and your team.
但有时你会碰壁，可能会忍不住说:“这就是做不到。”. 许多交付经理和客户会说，将信息技术服务管理(ITSM)和敏捷相结合就是其中一个例子, but I’m here to tell you that’s not true! Don’t believe what you’ve been told, you can have it all.
First, let’s make sure we’re all on the same page. What do I mean when I say ITSM and agile?
ITSM
ITSM = Information Technology Service Management.
ITSM是组织用来管理提供给用户的服务的一组活动和过程. ITSM也是一个由多个ITSM过程中的专家和专家组成的职业.
我们在生产应用程序支持中最常看到ITSM:需要维护的实时服务，以便用户获得连续性和高质量的服务.
Agile
Agile is an umbrella term that applies to many methodologies, all of which are based on and refer back to the Agile Manifesto:
individuals and interactions > processes and tools
working software > comprehensive documentation
customer collaboration > contract negotiation
responding to change > following a plan
敏捷支持来自用户和涉众的快速输入，以及投资的早期回报.
The conflict
The conflict between ITSM and agile lies in how each measures success.
ITSM的核心是服务水平协议(sla)的度量，它包括围绕响应时间和正常运行时间的目标. 这些sla是签订合同的，是严格衡量的，如果没有达到，通常会受到惩罚. 这种方法与敏捷宣言中客户协作优先于合同协商的观点不太一致.
ITSM also follows a strict set of processes. 其中包括使用支持层——服务台响应人员接收问题并对问题进行分类，然后将问题移交给解决程序组, who may then hand it over to another resolver group or engineering team, who even then may hand it over to an external party. 这些移交是严格定义的，每个小组的责任范围是不灵活的, leaving little room for collaboration. 当我们遵循敏捷宣言时，这些过程和工具是优先考虑的，而不是我们关注的个人和交互.
An alternative
在这里需要注意的是，与ITSM和敏捷之间的冲突似乎势如雨下，但实际上根本不是与ITSM之间的冲突. They’re conflicts with how ITSM is traditionally implemented. The good news is, things don’t have to be this way.
By implementing a swarmed ITSM approach, 服务可以由较小的专家团队来支持，这些专家团队嵌入了敏捷的工作方式，而不会影响服务的质量.
群体模型消除了层之间的严格规则，而是将响应人员的专业知识分组在第1层, the resolvers in tier 2 and engineers in tier 3. The team can then introduce an agile approach that works for them.
在这一点上，他们可以与客户达成成功措施，优先考虑用户需求和用户体验，而不是响应时间. 最棒的是，这些团队还可以灵活地包含在生产应用程序支持中通常看不到的技能, such as user research and business analysis. 好消息是，这可以帮助您在已有的持续维护期望之上，将持续改进嵌入到您的服务中.
这种替代方法允许您获得最佳的ITSM(连续性和服务质量)，同时也获得最佳的敏捷性(以用户为中心和快速的投资回报)。.
Tried and tested
“That all sounds great in theory, but it isn’t all that practical” I hear you say. 我们在Made Tech实践了我们所宣扬的理念，并对许多客户使用了这种群体方法.
One example is a team of engineers, 代表政府部门支持关键应用程序的分析师和研究人员. 这个支持模型在第2级和第3级团队成员之间没有区别, and uses a swarm approach to resolve issues and incidents. 团队已经证明，提供质量事件管理不需要严格的所有权和指导方针. 还有额外的好处——他们的蜂群现在被其他确信了这些好处的供应商十大正规博彩网站评级了!
通过使用群方法，团队已经确保这个关键服务具有100%的可用性(不包括计划维护)，并且所有影响用户的事件都得到了完全解决, not just responded to, within 48 hours. 他们已经部署了对服务的改进，使常见的服务请求自动化, 与之前的供应商相比，将支持服务的成本降低了75%以上.
A tiered approach may be right sometimes
说了这么多，分层方法可能仍然是适合您的组织的方法. It’s not one size fits all. For example:
- if you’re supporting 50 products each with 5,000 users, then it helps to have a tier 1 who can receive issues, screen them for importance and make sure it’s sent to the right people to fix. You can then set up a two tier approach that passes issues down to resolve.
- 如果你是一个外包IT服务的组织，并且有一个多供应商的环境，那么传统的分层模型可能是你的朋友，因为它有助于平衡服务管理和供应商管理.
我们认识到传统的ITSM流程有其价值，但不应该是默认的. 通过这种替代方法提高效率，使公共资金能够专注于改善服务，而不是简单地“维持供电”，并最终帮助我们减少遗留技术的积累.
如果你想让更多的Made Tech内容直接发送到你的收件箱，请注册我们的月度 Insights newsletter.
