有上百万种方法可以用来交付软件. 您选择的工具集将根据您要解决的问题而有所不同. 偶尔你会 混合不同的方法 找到最适合你和你的团队的流程.
但有时你会碰壁，可能会忍不住说:“这就是做不到。”. 许多交付经理和客户会说，将信息技术服务管理(ITSM)和敏捷相结合就是其中一个例子, 但我要告诉你，这不是真的! 别相信别人对你说的话，你 可以 拥有一切.
首先，让我们确保我们都在同一页上. 我所说的ITSM和敏捷是什么意思?
ITSM
信息技术服务管理.
ITSM是组织用来管理提供给用户的服务的一组活动和过程. ITSM也是一个由多个ITSM过程中的专家和专家组成的职业.
我们在生产应用程序支持中最常看到ITSM:需要维护的实时服务，以便用户获得连续性和高质量的服务.
敏捷
敏捷是一个涵盖性术语，适用于许多方法, 所有这些都是基于并引用 敏捷宣言:
个体和相互作用 > 流程和工具
工作软件 > 全面的文档
客户协作 > 合同谈判
应对变化 > 遵循计划
敏捷支持来自用户和涉众的快速输入，以及投资的早期回报.
的冲突
ITSM和敏捷之间的冲突在于各自如何衡量成功.
ITSM的核心是服务水平协议(sla)的度量，它包括围绕响应时间和正常运行时间的目标. 这些sla是签订合同的，是严格衡量的，如果没有达到，通常会受到惩罚. 这种方法与敏捷宣言中客户协作优先于合同协商的观点不太一致.
ITSM也遵循一套严格的流程. 其中包括使用支持层——服务台响应人员接收问题并对问题进行分类，然后将问题移交给解决程序组, 谁可以把它交给另一个解决方案组或工程团队, 即便如此，谁会把它交给外部机构呢. 这些移交是严格定义的，每个小组的责任范围是不灵活的, 几乎没有合作的余地. 当我们遵循敏捷宣言时，这些过程和工具是优先考虑的，而不是我们关注的个人和交互.
另一种选择
在这里需要注意的是，与ITSM和敏捷之间的冲突似乎势如雨下，但实际上根本不是与ITSM之间的冲突. 它们与ITSM存在冲突 传统上 实现. 好消息是，事情并不一定要这样.
通过实现蜂群ITSM方法, 服务可以由较小的专家团队来支持，这些专家团队嵌入了敏捷的工作方式，而不会影响服务的质量.
群体模型消除了层之间的严格规则，而是将响应人员的专业知识分组在第1层, 解析器在第2层，工程师在第3层. 然后，团队可以引入适合他们的敏捷方法.
在这一点上，他们可以与客户达成成功措施，优先考虑用户需求和用户体验，而不是响应时间. 最棒的是，这些团队还可以灵活地包含在生产应用程序支持中通常看不到的技能, 比如用户研究和商业分析. 好消息是，这可以帮助您在已有的持续维护期望之上，将持续改进嵌入到您的服务中.
这种替代方法允许您获得最佳的ITSM(连续性和服务质量)，同时也获得最佳的敏捷性(以用户为中心和快速的投资回报)。.
久经考验
“这在理论上听起来很棒，但并不那么实际。” 我听见你说. 我们在Made Tech实践了我们所宣扬的理念，并对许多客户使用了这种群体方法.
工程师团队就是一个例子, 代表政府部门支持关键应用程序的分析师和研究人员. 这个支持模型在第2级和第3级团队成员之间没有区别, 并使用群体方法来解决问题和事件. 团队已经证明，提供质量事件管理不需要严格的所有权和指导方针. 还有额外的好处——他们的蜂群现在被其他确信了这些好处的供应商十大正规博彩网站评级了!
通过使用群方法，团队已经确保这个关键服务具有100%的可用性(不包括计划维护)，并且所有影响用户的事件都得到了完全解决, 不仅仅是回应, 48小时内. 他们已经部署了对服务的改进，使常见的服务请求自动化, 与之前的供应商相比，将支持服务的成本降低了75%以上.
分层方法有时可能是正确的
说了这么多，分层方法可能仍然是适合您的组织的方法. 这不是一刀切的. 例如:
- 如果你支持50个产品，每个产品有5个,000个用户, 然后，有一个可以接收问题的一级人员是有帮助的, 筛选它们的重要性，并确保将其发送给正确的人进行修复. 然后，您可以设置一个两层方法，将问题向下传递以解决.
- 如果你是一个外包IT服务的组织，并且有一个多供应商的环境，那么传统的分层模型可能是你的朋友，因为它有助于平衡服务管理和供应商管理.
我们认识到传统的ITSM流程有其价值，但不应该是默认的. 通过这种替代方法提高效率，使公共资金能够专注于改善服务，而不是简单地“维持供电”，并最终帮助我们减少遗留技术的积累.
如果你想让更多的Made Tech内容直接发送到你的收件箱，请注册我们的月度 洞察时事通讯.
