由 superadmin 于 2024/04/03, 16:10 最后修改
从版本< 28.1 >
由superadmin编辑
在2022/01/07, 13:50上
到版本
由superadmin编辑
在2021/12/29, 23:54上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -47,10 +47,9 @@
47 47  
48 48  表格 3.1 交付方式
49 49  
50 -(% style="width:526px" %)
51 -|(% style="width:106px" %)大爆炸|(% style="width:417px" %) “大爆炸”方法涉及到一次交付所有集成。这对测试有潜在好处，因为整个系统在正式推出前即已就绪。但与软件开发一样，使用这种方法交付的集成项目可能会变得过大和复杂，从而可能导致故障排除等问题。因此，该方法适用于集成系统较少、集成风险更低的简单服务实施。
52 -|(% style="width:106px" %)增量交付|(% style="width:417px" %)增量交付是一种更敏捷的方法，用于集成多个组件，其中以预定义的顺序分别引入新的集成。增量交付减少了了每个独立交付到生产的规模，从而可以对部署后的问题执行故障排除并予以解决。这种方法可以在大多数情况下使用。然而，由于在每个集成就绪前总体服务仍不完整，所以服务测试可能需要大量的模拟考虑未交付的元素。回归测试的负担也可能很大.
53 -|(% style="width:106px" %)使用（价值）流直接集成|(% style="width:417px" %)直接集成允许各个集成在准备就绪后立即部署，而不需要预先确定顺序。直接集成提供了更大的敏捷性，并支持快速的初始进展。像增量交付一样。该方法可能需要大量的仿真促进足够的测试。整个服务的全局测试，甚至其中功能链的子集的全局测试，只能在服务实现的后期运行。
50 +|大爆炸| “大爆炸”方法涉及到一次交付所有集成。这对测试有潜在好处，因为整个系统在正式推出前即已就绪。但与软件开发一样，使用这种方法交付的集成项目可能会变得过大和复杂，从而可能导致故障排除等问题。因此，该方法适用于集成系统较少、集成风险更低的简单服务实施。
51 +|增量交付|增量交付是一种更敏捷的方法，用于集成多个组件，其中以预定义的顺序分别引入新的集成。增量交付减少了了每个独立交付到生产的规模，从而可以对部署后的问题执行故障排除并予以解决。这种方法可以在大多数情况下使用。然而，由于在每个集成就绪前总体服务仍不完整，所以服务测试可能需要大量的模拟考虑未交付的元素。回归测试的负担也可能很大.
52 +|使用（价值）流直接集成|直接集成允许各个集成在准备就绪后立即部署，而不需要预先确定顺序。直接集成提供了更大的敏捷性，并支持快速的初始进展。像增量交付一样。该方法可能需要大量的仿真促进足够的测试。整个服务的全局测试，甚至其中功能链的子集的全局测试，只能在服务实现的后期运行。
54 54  
55 55  **ITIL 故事: 集成和数据共享**
56 56  
... ... @@ -152,26 +152,25 @@
152 152  
153 153  表格 3.2 支持敏捷方法的工具和方法
154 154  
155 -(% style="width:593px" %)
156 -|(% style="width:92px" %)**工具或方法**|(% style="width:500px" %)**说明**
157 -|(% style="width:92px" %)使工作可视|(% style="width:500px" %)(((
154 +|(% style="width:118px" %)**工具或方法**|(% style="width:1103px" %)**说明**
155 +|(% style="width:118px" %)使工作可视|(% style="width:1103px" %)(((
158 158  使用实物板和地图、颜色和图形可视化手头的工作，展示团队计划如何处理工作，并绘制和记录其在工作流中的旅程。尽管许多信息技术工作管理系统包含大量数据，但很少可被轻松查看或使用。瓶颈可能不会被注意到，要解决时为时已晚。
159 159  
160 160  隐藏在视野之外的工作或问题可能会被延迟或未解决，要么是因为没有人意识到，要么是因为这些工作或问题超出了指定的责任范围，要么是因为很少有人拥有知识或有能力解决。
161 161  )))
162 -|(% style="width:92px" %)在基于主题的论坛工作|(% style="width:500px" %)(((
160 +|(% style="width:118px" %)在基于主题的论坛工作|(% style="width:1103px" %)(((
163 163  虽然电子邮件在工作场所的管理工作中仍然占主导地位，但个人文件夹、重复信息、丢失附件等特性隐藏在巨大的、嵌套的电子邮件链中，意味着经常会浪费时间搜索重要信息。
164 164  
165 165  好的协作工具以论坛的方式，让个人和团队可以直接参与讨论。论坛促进了基于主题的领域、小型项目和销售活动等，这些仅有参与讨论的个人获得。这种工作有助于提高效率，避免因为搜索文档而浪费时间。
166 166  )))
167 -|(% style="width:92px" %)映射工作流|(% style="width:500px" %)团队和项目使用的以可见的格式展示和应用于工作的模型。工作包、时间表、人员和输出显示为有形且易于访问的元素。该工作可供组织中的其他人员查看。这种透明度可以促进团队之间更好的交流和协作，从而避免大型组织内部通常的挑战。问题和难题并不遵循组织的典型报告路线，因此需要通过检查团队之间或跨团队时可能忽略的差距、遗漏或潜在障碍来不断改进协作。
168 -|(% style="width:92px" %)以小团队和冲刺方式工作|(% style="width:500px" %)(((
165 +|(% style="width:118px" %)映射工作流|(% style="width:1103px" %)团队和项目使用的以可见的格式展示和应用于工作的模型。工作包、时间表、人员和输出显示为有形且易于访问的元素。该工作可供组织中的其他人员查看。这种透明度可以促进团队之间更好的交流和协作，从而避免大型组织内部通常的挑战。问题和难题并不遵循组织的典型报告路线，因此需要通过检查团队之间或跨团队时可能忽略的差距、遗漏或潜在障碍来不断改进协作。
166 +|(% style="width:118px" %)以小团队和冲刺方式工作|(% style="width:1103px" %)(((
169 169  这是Agile和DevOps中的关键元素，小型集成团队以端到端价值流的形式处理离散的工作包。
170 170  
171 171  工具和跨团队方法应该动态地反映这些团队的性质，通常在有限的时间内作为矩阵资源模型的一部分运行，或由于灵活的问题处理方式（如全功能团队）而运行。为了实现其目标，相关的团队可能仅需要简单的文档、批准流程和阶段。
172 172  )))
173 -|(% style="width:92px" %)使用简单的反馈机制|(% style="width:500px" %)沟通并不需要过于正式的或复杂的。实际上，如果沟通很容易理解，通常会有更大的机会引起人们的注意、理解和采取行动。客户和员工反馈的收集应是即时且直观的。
174 -|(% style="width:92px" %)协作和“社交媒体”功能|(% style="width:500px" %)某些社交媒体功能正被基于工作的工具采用。许多人已经习惯了“点赞”、“转发”或“分享”等功能，这些功能可以在工作环境中提供有用的数据。此外，表情符号也可用于表示反馈。
171 +|(% style="width:118px" %)使用简单的反馈机制|(% style="width:1103px" %)沟通并不需要过于正式的或复杂的。实际上，如果沟通很容易理解，通常会有更大的机会引起人们的注意、理解和采取行动。客户和员工反馈的收集应是即时且直观的。
172 +|(% style="width:118px" %)协作和“社交媒体”功能|(% style="width:1103px" %)某些社交媒体功能正被基于工作的工具采用。许多人已经习惯了“点赞”、“转发”或“分享”等功能，这些功能可以在工作环境中提供有用的数据。此外，表情符号也可用于表示反馈。
175 175  
176 176  === 3.3.2 工具和功能 ===
177 177  
深圳市艾拓先锋企业管理咨询有限公司