我有一个包含三个组件的项目：服务器，Android和Web。
然后我得到了可能会影响这些组件子集的用户故事（故事），例如，具有向Android发送命令的按钮将在每个组件处执行任务。然后当所有这些都完成后就结束了。
另一方面，我确实需要一个Release来跟踪包含的内容以及发布的时间。
我不确定如何继续使用此结构，因为我尝试的所有方法都会产生一些摩擦并产生问题（以及许多手动操作）。
当前我正在做
缺点：
推荐的方法是什么？
我在公司的所有项目中都没有看到有关此用例的清晰文档或建议。
答案 0 :(得分：0)
关键是要从用户的角度出发。
将任务视为可能涉及许多存储库和影响代码的潜在更改，从而影响用户。代码更改（一旦发布）使故事成为现实。如果不更改代码，则没有任何东西可以提供给用户。
一个版本可以包含许多任务和存储库。
一个例子是100次提交（对于Android，Server和Web）。如果这100次提交位于一个存储库中，那么您只需要在GitHub中发出一个pull请求，并在您的管道中发布一个CI / CD版本。无需使其更加复杂。此外，您的组件应基于用户将经历的内容，通常会要求查看，使用等。例如用户个人资料，主页等。应限制按内部体系结构或组织结构分开组件。您不向用户提供Android或服务器，而老板则需要查看用户角度。 （即使他不想）
如果您在100个存储库中有100个项目，则会变得有点困难。 Jira的产品组合可能会帮助您将所有这些项目整合到一个版本中。
从用户角度讲一次故事，将要实现的故事归为一个版本。不要让自己的文书工作超出必要。
最后，它很敏捷……与瀑布不同，没人知道日期，而我们却不知道。它在发生时发生。