系统用例永远都是1个与最小可交付有没有冲突
jeri 2024-4-24 12:04
潘老师，每个迭代周期需要关注的系统用例永远都是1个，这个与产品最小可用或最小可交付有没有冲突，还是说这是两回事，与是否能交付无关。
还有这个：需要根据愿景来判断应该先实现哪个用例，然后观察改进的结果。
实现了这个用例，可能无法交付，即有最小交付集合，如并多多，通过愿景找到最需要改进的点，但仍需要有退货，商品上架等用例，产品才能交付。
UMLChina潘加宇
首先，这里面最要命的，就是我们做需求的时候，不能先设想一个答案，然后再根据答案去“探索需求”，那就使得所做的工作没有意义了。
这种犯错有时候是比较隐秘的，例如，看到某个业务流程时，我们会下意识地觉得目标系统应该涉及流程中的每一步。
例如问题中的“如并多多……但仍需要有退货，商品上架等用例，产品才能交付”，下意识我们会这样想，觉得这些内容目标系统都应该涉及。
但这中间有一个付款的步骤，目前它的服务经常是由另外的系统提供的，我们并没有觉得不妥，反而下意识地跳过去了。
同理，目标系统也可以跳过其他步骤，例如只做一个“购买”的用例，业务流程的其他步骤仍然通过原有的人脑系统或电脑系统完成。
不排除这样一种可能性，有厂商精研“购买”方面的学问，只做这一点，但这一点是做得全世界最好的。
同样，这里也要提防先入为主，认为精研某个环节一定要先精研“购买”。实际上，也可以直接精研“退货”。
排除了“先预想答案再去套问题”的错误后，剩下的实事求是就可以了。
如果目标系统只提供“购买”（也可以换成 “退货”）用例，业务流程的其他步骤仍然通过原有的人脑系统或电脑系统完成，这样可以满足老大的愿景，那就是1个。
如果老大觉得目标系统和其他系统协作不流畅（很常见），带来了各种麻烦，可能需要把业务流程的其他步骤也通过目标系统完才能解决，那就有其他的用例。
如果以上描述的业务流程步骤都改进了，老大有更多的愿景，那就有更多。
或者，开发团队认为这个老大已经不能榨出油水，要放弃这个老大，思考方法也没有变化。
关于“最小可行产品”，我发过一个视频评点：
