技术类事项，例如“将服务器从v1升级到v2”、“提高启动性能”或“重构登录模块以减少代码复杂度”，是否应该放入产品待办列表中？如果是，非技术产品负责人如何优先考虑它们与其他更具功能性的待办事项？
是否应该为技术类事项建立单独的待办列表？我们是否需要一个联合PO角色，由两个人来优先考虑产品待办列表上的功能和技术类事项？
3个回答
11
通常在“原汁原味”的SCRUM中，您提到的技术任务不会作为单独的故事进行。对我来说，非技术PO不应该把故事看作“升级服务器”之类的。这不是一个业务故事，对最终用户不可见，因此很难确定优先级。优先级应根据工作的商业价值进行分配。“升级”并没有什么意义。“允许更多同时连接”、“减少停机时间”甚至“提高团队速度”可能为非技术人员提供更有价值的见解。如果找不到非技术描述，请问自己升级的必要性是什么：）
“重构”故事更加复杂。你有没有想过为什么它是一个故事？重构可以作为故事中的一个任务完成，但很少成为一个故事本身。因此，如果您想使登录功能更好或提供更多功能，那就是一个故事，但是在引擎盖下修补不算一个故事。请注意，没有商业目的的重构很容易导致所谓的“镀金”。
我建议将“升级”故事作为“改进性能”和“重构”为相关业务故事的任务进行。
P.S. 您可能会在Mike Cohn的优秀书籍“用户故事应用：敏捷软件开发”中找到这个主题的良好讨论（主要在第三部分）。
“重构”故事更加复杂。你有没有想过为什么它是一个故事？重构可以作为故事中的一个任务完成，但很少成为一个故事本身。因此，如果您想使登录功能更好或提供更多功能，那就是一个故事，但是在引擎盖下修补不算一个故事。请注意，没有商业目的的重构很容易导致所谓的“镀金”。
我建议将“升级”故事作为“改进性能”和“重构”为相关业务故事的任务进行。
P.S. 您可能会在Mike Cohn的优秀书籍“用户故事应用：敏捷软件开发”中找到这个主题的良好讨论（主要在第三部分）。
- Ilya Kochetov
1
1有些任务无法归类到你所提到的两个组别中。有些任务是预先需要完成的任务，例如：使代码生成准备就绪，培训团队成员，建立日志基础设施，使基本开发基础设施准备就绪，将项目分为3个不同的项目以更好地控制它...如何应对这些任务？ - Mahmoud Moravej
2
我赞同从商业利益的角度看待任何技术故事，并在主要产品待办事项中跟踪它。
我认为有一些内部故事与团队的速度/能力有关，有时更方便地通过分配一些开发人员的能力来管理，特别是当产品负责人不感兴趣优先考虑或管理这些故事时。例如，将10％的能力分配给测试自动化待办事项（传统回归），CI服务器设置等。
是的，当然可以用商业术语表达所有内容，但其中一些应被视为“我们需要完成工作的方式”，在产品负责人和团队之间存在信任，团队将最好地利用分配给此类任务的能力。
- Yuval
1
你能给我一个例子吗？例如，我该如何用商业术语解释“使代码生成工具为当前项目做好准备”？ - Mahmoud Moravej
0
我已经成功地采用了双重待办事项方法：
产品待办事项由产品负责人拥有。它包含故事级别的条目（功能），由团队进行估算，然后由产品负责人进行优先排序。这个估算过程将故事分成更小的任务。
团队待办事项由开发团队拥有。它包含相对较小的任务级别项目（可以在一个迭代周期内完成）。它们可以与故事相关联，例如作为障碍：要完成故事，必须首先完成以下技术任务。它们也可以是独立的，以便不需要任何故事本身，但它们可以偿还一些技术债务，以实现未来更高的速度。
（在一些大型的、多项目的程序中，我还有程序待办事项，其中包含史诗级别的条目，由程序管理团队拥有和优先排序，进一步分解为产品待办事项中的故事。）
- laalto
4
5依我之见，采用双重待办事项方法并不是一个好的做法。团队应该试着用商业术语来表达技术故事，展示它们提供的商业价值，解释它们如何影响团队速度。这样产品负责人就可以像处理其他故事一样对它们进行优先级排序。 - Pascal Thivent
我认为拥有多个待办事项列表会使项目或迭代管理变成一场噩梦。我认为这是一种反模式。 - Mahmoud Moravej
1不止一个积压会导致产品负责人和开发团队之间产生冲突。如果双方之间有信任，那么这不是问题。如果没有信任，那么你会面临更大的问题。 - Chris
每个设置/团队都是不同的；实际上没有规则。列出改进清单可以帮助开发人员将想法付诸实践。这些项目可以在计划期间“融入”用户故事的估算中。较大的项目可以重新构思为用户故事，但其价值必须明确映射，重要的是“以便”这一点；以便页面加载更快+链接到页面加载/销售影响研究。 - Luke Puplett
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接