| 关注 @wpschaub
加拿大温哥华
自 80 年代中期以来，我一直致力于软件工程的简洁性和可维护性。作为一名软件工程师，我分析、设计、开发、测试和支持软件解决方案。我热衷于持续创新，并分享来自微软和 ALM | DevOps Rangers 的数字化转型经验，以 DevOps 文化来调整人员、流程和产品，从而持续为我们的最终用户交付价值。您可以在以下网址关注我：www.linkedin.com/in/wpschaub、https://willys-cave.ghost.io、https://twitter.com/wpschaub 和 https://www.agents-of-chaos.org。
撰写的评论
感谢您的出色反馈。正如我在示例中提到的，您通常依赖于故障处理策略的组合，例如重试和断路器来微调系统。关于 instrumentation 的观点很好，它为宝贵的反馈循环提供支持，以帮助进行主动监控和根本原因分析。
说得好 - 许多“害怕失败”的根本原因在于固定的截止日期和期望，尤其是在一个正在经历自下而上的敏捷转型的组织中。我目睹过许多 sprint 计划会议，这些会议以产品负责人展示包含里程碑和每个里程碑预期功能列表的路线图开始。当产品负责人影响团队如何以及何时交付功能时，自主权界限经常被突破 - 结果，团队专注于里程碑，而不是质量和持续改进。
正如其他文章中讨论的那样，大多数转型旅程的挑战都基于人员、组织文化以及期望的不一致。