rust语法丑陋
产品积压是一个重要工具：它列出了想法，需求和新见解。 但是它始终是正确的工具吗？ 这篇文章讨论了传统产品积压的优点及其局限性。 它提供有关何时使用积压以及何时更适合使用其他工具的建议。
善良
传统产品积压列出了创建产品所需的出色工作。 这包括构想和要求，体系结构重构工作和缺陷。 我发现它的最大优势在于它的简单性，这使它的使用极其灵活：团队可以使用该产品
以最适合其产品的方式积压订单。 例如，项目可以描述为用户故事或用例，并且可以应用不同的优先级排序技术。 这种灵活性使积压可用于从移动应用程序到大型机系统的各种产品。 第二个很大的好处是积压的支持冲刺和发布计划的能力。 这是通过从上到下对项目进行排序，并根据其优先级对项目进行详细说明来实现的。 顶部的细小，详细和优先事项是sprint计划会议的正确输入。 通过订购积压的提醒，可以预测何时可能交付这些物品（如果还使用了发布燃尽图）。
坏人
尽管简单性是它的最大优点，但我也发现它有一个缺点：捕获用户和客户需求的角色不适合列表，场景和情节提要也不适合。 用户界面设计以及操作质量（例如性能或互操作性）也是如此。 结果，这些文物被分别保存在例如Wiki或项目管理工具中，或者在我的经验中被忽略。 尽管后者可能会带来很大的问题，但前者也不是很好：将在一起的信息分开存储。 这使得保持各种人工制品同步变得更加困难，并且可能导致不一致和错误。
同样，当发布计划可行且可取时，使用包含列表的产品待办事项也是有意义的。 但是，对于全新产品和主要产品更新，积压的项目必须出现：一些项目最初会丢失，并且会通过利益相关者的反馈被发现，其他项目则过于粗略，或者可能会发生重大变化。 更糟糕的是，开发新产品的团队可能一开始就无法估算所有产品待办事项，因为团队成员可能必须找出如何最佳实施软件的方法。
丑陋的
我在工作中看到了很多丑陋的产品积压，包括变相的需求规范，细节太多，长长的愿望清单包含数百项，以及“甜点积压”，其中仅包含少量松散相关的故事。 尽管这不是产品积压的问题，但我认为它的简单性并不总是能为团队提供所需的支持，尤其是在开发新产品时。
结论
传统的线性产品待办事项在角色，用户交互，用户界面设计和操作质量已知且无需说明的情况下，效果最好。 增量产品更新通常是这种情况。 但是，对于新产品和重大更新，我发现传统的积压产品可能会受到限制，因此我更喜欢使用Product Canvas 。 （但是，对于增量产品更新或维护版本，画布很可能是过大的功能！）
参考： Pichler博客博客中的JCG合作伙伴 Roman Pichler的《好，坏和丑陋积压》 。
翻译自: https://www.javacodegeeks.com/2013/03/the-good-the-bad-and-the-ugly-backlog.html
rust语法丑陋
