用敏捷实践平衡旧案例

Question

我的团队刚刚开始将敏捷实践(我们选择了kanban)集成到我们的开发团队、测试团队和设计团队中，但是我们有很多错误案例和特性用例没有写在旧系统遗留下来的用户故事中，我们正在试图找到一种很好的方法来处理这些bug，但仍然让需要保持低调的开发人员保持注意力集中。现在，我们已经为bug修复指定了一个较新的开发工具，因此其他的开发人员可以在新特性上工作，但我们正在寻找构建团队的正确方法。我们有7名开发人员，2名测试人员和2名设计师。

谢谢您的帮助:)

Answer 1

将bug项目像其他所有东西一样放在看板上(当然，按优先顺序排列)，然后让团队决定谁应该实现队列中的下一个项目。

我相信团队最好知道如何处理这个问题，而不是让其他人在特定的团队成员之间分配项目。至少这会给他们一个自我组织的机会。这一切都很敏捷。

Answer 2

像往常一样完成旧的bug案例和特性请求，并且随着新的bug案例和特性请求的出现，慢慢开始实现kanban系统。

或

让一些开发人员或其他人在办公室里为旧的bug创建用户故事，然后再进行。

Answer 3

您可能缺少的是一个清晰的优先级待办事项和适当的WIP限制(工作进度限制)。

首先，假设您开始使用3种状态(Open/ backlog，In product，Done)，团队需要有一种方法来根据产品负责人确定的优先级从待办事项中提取项目。不管这些是否是预敏捷时期的剩菜，都无所谓。每件事都要优先考虑其他事情，对吗？因此，组装您的待办事项，使团队有可能从积压的顶部进行选择。不管项目是粗略的bug描述还是完全吹毛求疵的故事，重要的是您对产品所有者的想法有某种可视化的表示，即团队可以使用它。过渡到一个更正式的方式来定义这些愿望在途中(直到你结束时只有适当的错误和故事在最后)。Bug是软件开发中的一个事实，所以在确定优先级时，只需把它们当作故事来处理。

第二，告诉团队提供他们希望同时进行的最大数量的项目，并让团队将其定义为最初的WIP限制。这个值可以随着时间的推移而调整，这取决于它对你的工作方式。

似乎您也认为您最了解团队应该如何组织他们的工作(为一个新开发人员分配bug，让其他开发人员集中精力)。我以前见过这种行为，通常这是一种行为失调的迹象。团队应该知道如何解决看板上的项目，只要他们作为一个团队行事和思考。通过这种方式，它们可以最大限度地提高吞吐量，并最大限度地利用每个人的能力。来自外部的干扰(微观管理和类似的)会伤害团队。这就是说，故事总是有两个方面的，因为团队必须成长，可能需要适当的指导才能实现敏捷实践有效工作的某种质量。如果他们有分裂工作的问题，这是可以作为回顾/反馈循环的一部分来解决的，这些循环对于改善工作的分布是必不可少的。

请记住，看板是基于让团队拉，而不是推动项目到团队。最后，如果一个大团队方法失败了，那么您和您的团队总是可以考虑将团队分成几个较小的团队，每个团队都有自己的看板流程和工作流程，并根据特定团队的需要进行定制(例如，修复错误的团队、特性团队、测试团队)。最后，您和您的开发团队必须管理流程，而不是反过来。