5个隐藏的敏捷障碍可能阻止您的转变
在敏捷转型方面，每个组织都必须找到一种方法来克服阻碍组织敏捷能力的一切。敏捷障碍在许多层面上都存在，但是大多数大规模的转换现在都要求技术实践比以往任何时候都更加合适。
As strategic priorities shift toward a focus on technology, hiring Scrum coaches just isn’t going to suffice to使敏捷工作。尤其是当您遇到毫无障碍的整体遗产软件的复杂且看似不可能的过程时。现在必要的是一种端到端解决方案，用于围绕声音技术实践建立基础架构。
问题是，没有人谈论的整个DevOps考虑因素，它们秘密地杀死了许多组织释放敏捷潜力的能力。在此博客中，我们将查看大型组织中通常被忽略的DevOps障碍的五个障碍，因此您可以为它们进行计划并准备克服它们。
敏捷障碍1：包装软件
您的包装解决方案将如何在您的新环境中工作？
当您经历转换时，通常您会试图达到减少发布时间，增加发行频率并以较短的增量工作的地步。包装软件解决方案的开销和测试这些包装的解决方案都可以做到这些事情。此外，您必须在首次安装它们时必须进行集成，迁移数据和自定义这些解决方案所做的所有工作，每次都必须重新测试它们there’s a new version, patch, or release—another time consuming task.
软件包并非孤立地放置。因此，如果您没有围绕软件的测试策略，在集成，更新和测试之间，那么很难进行频繁部署或连续集成管道。手动测试可能需要几个月的时间。
然后有更新。一些组织发现，很难与包装软件发行的最新保持最新状态，以至于他们在版本上落后了多年，因此实际上，供应商甚至不再支持这些版本了。获得最新版本所需的时间将花费基本上安装它所需的时间。
敏捷障碍2：员工技能
您在当前人民的当前技能中要实现的目标是您要实现的目标吗？
不可能挥舞魔杖，并突然确保团队或组织中的每个人都拥有您想要的所有新技能，并且需要转变后。改变人们的工作方式可能需要花费数月或几年。但是，不幸的是，花几个月或数年的时间改变人们的工作方式通常与任何人的转型路线图/时间表不符。因此，拥有没有必要技能的员工可以适应组织的改变方式可能是到达那里的主要障碍。
For example, there can be a lot of engineering skill difference in releasing once a quarter vs releasing once a day. You’ll need people who can help you to automate everything currently done manually. You’ll need software engineering skills for Test Driven Development, code reviews, and they need to be able to support the speed of implementation.
有很多方法可以处理此操作，但是它们都需要额外的腿部工作，有些腿部工作比其他更多。您可以培训和指导您的团队需要的新技能，雇用已经具有这些技能并准备好跑步的新朋友，或者可以从早期职业职业职位上获得学徒，或者通过外部供应商增加员工。
Agile Impediment 3: External Vendors
您的供应商会以正确的技能支持转型计划吗？
许多组织通过外部IT服务供应商增加员工，以供可变人员配备。但是，随着组织变得敏捷，外部供应商通常不提供您需要的控制。当您从供应商那里吸引人们并将他们带走以帮助您获得更好的结果，使他们加快他们需要的新技能，然后供应商将人们旋转出去，这是一个很大的浪费时间和金钱。如果您通过供应商增加员工，则理想的情况是推动供应商再培训或为人们提供技能而不是将其旋转。
有时，有可能重新协商当前合同，因此供应商在挂钩上以提供您在转型背景下所需的东西。您不一定必须要求它们敏捷，而是可以为他们提供最小的要求，以使它们在一起工作时如何使您的敏捷性。
如果您的供应商不这样做，那么切换供应商可能会更有优势，因此您实际上可以帮助您步入正轨。
敏捷障碍4：职业激励措施
您人民的职业目标是否与您的转型保持一致？
类似于技能障碍,人们当然可以have personal career goals. But the company also has goals to meet. How do you measure people against your organization’s new and changing goals? Typically there’s an agreed upon metric for measuring how your people are working toward their own goals and also those of the organization. But what if those are no longer in alignment when the company begins to change?
例如，一个大型金融组织在转型期间所做的变化很难使整个安全团队陷入困境。团队不希望安全性自动化，他们想手动拥有该过程。不幸的是，这只是与组织的前进方向不符。现实是，这取决于他们的测量方式。如果这项工作是自动化的，那将违背他们在公司内部职业轨迹的年度目标。
您需要意识到这一点，因为这是一种特别隐藏的障碍，可以轻松地将自己掩饰为另一种问题。在书面协议和合同下的工会工人和IT员工中，这尤其普遍。许多组织的衡量任务和小时数量要比结果和成果要多。他们的人民在变革期间可能会陷入困境。准备枢纽并重新建立新的目标和职业道路，以便您的员工可以与组织的转型成果进行重新调整。
敏捷障碍5：缺乏自动化
您是否使所有可以自动化的一切自动化？
当您的转型旨在更频繁地发布和较短的增量时，您的流程中任何手动的东西都将是一种障碍。诸如手动将代码投入生产之类的东西都将妨碍这种情况。
在许多组织中，诸如入职开发人员和建立环境之类的事情通常需要数周才能开始工作。但是，一切都应该在几分钟之内（最多甚至是小时）来衡量，但不是在几周内。不仅需要自动化的测试或部署，而且实际上，从登机到安全测试，设置环境和应用程序本身。能够快速获得业务价值，并且在所有必要亚博vip9通道的地方都没有自动化的情况下，质量就无法做到。
您需要以DevOps的心态来处理此操作，在该心态下，团队最终负责所有事情，而不是设置团队进行交接，手动质量检查和/或手动测试。创建一个未自动化的所有内容的积压 - 开发人员编写代码和投入生产的功能之间，并开始致力于自动化每一部分。这也与以前的隐藏障碍有关。您的员工是否有合适的技能来支持更多的自动化？您的供应商也可以支持您的计划吗？
最重要的是，您想自动化所有内容。而且，如果您需要获得外部帮助才能做到这一点，那是值得的。考虑这一变化为投资，而不是费用。自动化很快回报。
充分利用敏捷
即使这些障碍是最常见的障碍，但它们显然是可以提前知道的。因此，现在您就知道了它们，并且知道您想充分利用敏捷，您需要的是如何将它们纳入转型的计划。诚实地说明自己的目标和技能如何与您的敏捷目标和需求保持一致。确保您的供应商也堆积起来。并将自动化作为优先事项，而不是奢侈品。尽早实施正确的实践意味着它们可以通过您的敏捷能力成熟。