由于这些调查与涉众要求的新特性没有明确的关联性，开发人员在极力压缩后续调查的投入，同时，由于缺乏经验又浪费了不少时间，这些从定义上看更符合“阻碍因素”，而不是“故事”这使他们成为团队进步的障碍我们想要明确地跟踪准确性的状态，就像我们跟踪故事的状态一样因此，我们决定尝试使用障碍板来观察这些障碍经再三考虑，可以通过调整现有的故事板，加入障碍以进行跟踪，就像约迪卡尔·帕克特在《敏捷中的障碍板?》中所提出的建议老实说，我们当时并没有考虑这种方法我们没有考虑使用这种合并后的板，而考虑的是使用一个单独的板来解决一开始要在平台中跟踪精确性状态的问题在向流程中添加障碍板之前，很有必要先向开发人员、业务分析师和产品负责人进行相关的培训不仅需要通过培训来解释这个概念，这还有助于证明为什么应该引入这个概念，并激发大家讨论是否使用以及如何使用这项技术上面提供的那些资源不仅对我来说很重要，对其他小队成员和利益相关者来说也很重要有效性测量这个小组同意使用障碍板来跟踪这些状态不明确的调查之后，我们设定了实验的界限由于关键利益相关者对准确性的高度关注，我们对障碍的定义仅限定于这些调查由于团队仍然在并行地处理故事，我们还定义了迭代中用于解决这些障碍的能力占比我们的做法是为每个迭代分配一定的比重随着时间的推移，我们会根据自己的节奏进行调整，但它通常不会超过我们所承诺的速度的 40%我们通过跟踪每周增加的障碍数量和解决的障碍数量来衡量效率这些数据很容易就能从 Jira 中提取出来，因为该工具会跟踪每个条目的创建和解决日期我假设，随着时间的推移，提出的障碍的数量将会减少，团队将有能力解决提出的所有障碍实际结果如下图所示，我们可以清楚地看到，随着时间的推移，我们增加的障碍的确变少了，部分原因是我们一开始在这块板上添加已知的障碍时，出现了较大的峰值我很高兴地看到，近一个月来没有出现新的障碍但是开发人员并没有在最初的高峰期解决所有的问题但之后，他们确实解决了提出的其他问题然而，由于最近这段时间没有继续调查问题，对解决率的计算产生了极大的影响从 Jira 中提取的数据也可以用于计算解决时间我们在实验期间收集了一些关键统计数据，如下表所示请注意，小障碍可以在不到几个小时的周期内解决，如表中的最短解决时间但是，如果不是大家共同努力，它们会被一直放在那里待很长一段时间，如表中的其他统计数据度量结果解决的障碍数量18个平均解决时间34天平均解决时间12天最短解决时间2小时最大解决时间102天未解决的障碍数量19个另一个有待评估的指标是总体燃尽由于障碍板的目标是可视化并消除那些阻碍故事发展的障碍，大家希望我们能够完成更多的故事点正如下图示例所示，可以看出我们已经距离完成迭代中的所有故事更近了从较长的那条垂直线可以清楚地看出，故事进行到完成状态所花的时间较长我认为，这很可能是由于我们采用了开发与障碍并行处理的工作形式调查和故事开发之间的切换可能会中断开发人员在这两种工作类型上的流程此外，尽管我们分配了一定的工作能力来帮助我们完成所承诺的故事，通过查看如上已创建和已解决的图表，但是我认为我们也许应该给障碍解决分配更高比重的工作能力从偏定性的角度来看，这块板已被证明是成功的了产品负责人和业务分析师都评论说，调查的情况更加透明了通过将调查明确地分配给自己，并将障碍切换到正处于什么状态，开发人员很容易就可以向所有涉众传达正在解决给定障碍的信息，就像那些开发任务一样此外，如果需要澄清，可以将同一条目分配给业务分析师或产品所有者，以获得更进一步的详细信息我们发现的另一个额外好处是，阻碍因素很容易就能转换为需要开发的故事如果障碍具有相同的根本原因，也可以将这些障碍关联起来这是由于我们决定障碍板也使用与 Scrum 故事板一样的工具如果同一个 Jira 条目中同时有障碍和故事这两类，我们可以将条目类型从障碍变为故事，这样就可以轻松将其置入到产品待办事项列表中此外，由于调查的细节和开发人员的发现都记录在 ticket 上，所有的信息都附在故事上，所以有助于验收标准的编写，甚至计划的制定和任务的识别工作开发人员也能从中受益，因为他们能够更好地和其他任务一起管理这些调查随着时间的推移，他们在旧系统的代码库上投入的时间越来越多，他们越来越了解旧系统是如何工作的这帮助他们产生了一种肌肉式的记忆，使他们之后能够识别相同问题的复发，因此节约在解决这些阻碍因素上花费的时间反思我们在使用第一块障碍板时取得了相当不错的开头然而，随着时间的推移，我们发现一直保持相同的方法会遇到很多的挑战实际上，该团队在实验开始三个半月后就停止使用这块板了经过对此进行反思，我决定考虑在某些方面改变一下我们当时使用的这块板，以帮助它更好地与我们的实践长久地整合在一起，并能更好地培训其他那些希望追随我们脚步的人首先，虽然我们可以从之前的燃尽图中看到，完成的故事与承诺的故事的比例正在趋向于 100%，但我们并没有在实验的时间框架内做到这一点原因大概率是因为我们一开始没有做好故事与障碍的平衡就像团队使用他们之前的迭代速率一样，或者在他们制定迭代计划中使用的平均速率一样，我们也应该尝试更好地跟踪在障碍上花费的时间来调整这个比例其次，在这个实验中，我们将障碍的定义局限为这些数据验证问题，实践证明这影响了这块板的使用寿命随着时间的推移，任何团队都在成长和发展，是什么导致他们放慢了发展速度？如果你不定期回顾导致你慢下来的原因，可能就不会把这些新的阻碍因素当成是障碍当第一个小组不再需要针对新旧工具进行调查时，他们便不再使用这块板了，因为他们对障碍的定义只局限于此就像团队可能用到的那些“准备就绪”或“已经完成”的定义一样，他们也应该定期重新审视他们对障碍的定义，以确保也能在这块障碍板上跟踪到那些新的事项当我们试图推广应用到同一领域的其他团队时，一些其他团队提出想用一块板承载更多的内容一位 IT 经理表示，希望有一块板来管理所有公司在我们的用例中，认为将障碍与故事分离开来是跟踪系统的准确状态的最好方法我一开始收到这些反馈时，并不愿意尝试将障碍和故事合并在一起我认为，就我们的经验来看，指望用这一块宝贵的板来包打天下有些贪心不同的受众希望状态有不同的视图，无论是精确的开发步骤，还是更高层次的“它已经准备就绪了吗”对于只想要一个视图的观众来说，障碍和故事没有理由不能和谐共存Judicael Paquet 之前在他的《敏捷中的障碍板?》中就已经讨论过了虽然他的观点是针对于看板的，但我认为这个想法也适用于 Scrum 实践从最初的实验之后，我已经转到了一个新的团队，他们发现在同一块板上跟踪主要障碍有助于让大家更能够关注到问题的存在因此，我现在坚信，在某些情况下，由一块板来管理所有的问题可能是正确的解决方案我提出的另一个建议包括有障碍板的用法或团队规范的通用障碍策略大家对团队规范有很多不同的叫法，我听说过的就有工作协议和团队章程之类的我猜还有其他的名字但如果你仍然觉得这个术语很陌生，那么它就是指团队达成共识的一组公共原则无论你们是在同一间办公室一起工作，还是分散在世界各地，都应该概括一下你们希望如何在一起工作，这是很有必要的声明你打算使用障碍板，以及你对不断发展着的障碍的定义是一个好的开始我在这里概括了许多反思的内容，如果把这些加进去可能也会很受欢迎结语我从未遇到过一个在开发新软件时从未遇到过任何问题的团队障碍板是一种机制，它使团队可以在前进过程中可视化所面临问题它们可以用来促进问题的开放交流，让大家能够坦诚、坦然地提出这些问题，并帮助团队一起协作消除障碍要注意，重点是不应该把推广所有团队全面执行作为目标强制使用工具和技术，会降低采用敏捷方法本应为我们带来的灵活性和团队自主权如果障碍板真能带来好处，那么就用不要把它们当作解决所有问题的灵丹妙药就像敏捷实践中使用的任何技术一样，它应该与团队的学习和成长一起有机地发展作者简介Carly Richmond 是摩根士丹利(Morgan Stanley)的首席软件工程师和 Scrum master她主要致力于构建金融系统，也在敏捷、UI、UX 和通用技术方面贡献了许多自己的想法她还喜欢烹饪、摄影，而且，她是一个大茶缸原文链接：Overcoming Software Impediments Using Obstacle Boards译者简介：冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》延伸阅读：Elasticsearch中的相似度评分介绍-InfoQ关注我并转发此篇文章，即可获得学习资料~若想了解更多，也可移步InfoQ官网，获取InfoQ最新资讯～
（图片来源网络，侵删）
0 评论