持续交付/部署和过程控制
从“过程控制”POV来看，在连续交付/部署上下文中，要求源代码管理提交与敏捷PM (或票务工具)“工作项”相关联有多重要？在这里，“工作项”是指任何一个:用户故事，任务，缺陷，错误等等。
最终目标是确保开发人员不会在产品所有者的产品中添加新的特性。显然，代码评审是正确的过程控制故事的一个关键部分，但是进行代码评审可以假定审阅者可以查看相关的工作语句(例如，用户故事)，以确保代码更改反映所请求的工作。
这就是问题所在。
上下文
我一直假设工作流与提交相关联，比如Jira，但现在我正在与一个公司合作，它的PM工具无法将工作项或缺陷-票据与源提交关联起来。
有了这个客户，我也看到了-22。首先，PMO的代表告诉我，这样的票据提交协会是不需要的.其次，工程组织出资聘请外部顾问来审计和标识主要的流程缺陷。发现的第一个缺陷是管理层无法知道开发人员提交是否与授权的工作有任何关系。
从我的POV中，我认为PMO需要认识到他们是“摇尾巴的狗”，他们需要接受工具更改或特殊集成来克服这个问题(更不用说敏捷哲学的更成熟了)。
然而，也许--我就是一个过分关注票据提交关联的，也许没有这种特定机制，还有另一种方法来实现有效的流程控制？
回答 1
Stack Overflow用户
发布于 2016-10-11 02:26:18
在处理受监管行业，如医疗保健或管理机构时，从范围到代码的完全可追溯性是一项要求。我曾经执行过一次审核，以验证每一行代码是否与SRS中的一行相关，以供FDA批准，尽管通常证明存在存在一种可追溯性方法(例如，github中的一个分支被命名为与JIRA中的任务/故事相匹配，并且启用了代码集成)。
如果你不是一个受监管的行业，需求到代码的可追溯性并不是一个要求.但这仍然是非常有用的。这些好处包括而且不限于：
- 对团队中的每一个人都是完全透明的，不管是不是技术人员。这唤起的信心的数量是惊人的，它减少了聊天的数量。
- 报告，以确定需求中的哪个主题导致了最大的代码混乱，因为这会造成很大的成本。
- 识别受公关影响的特征。当计划发布时，这是非常有用的，发行版的某些方面是不可实现的或错误的，许多代码已经被合并，并且团队需要分离发布的内容和不发布的内容。
- 通过删除以下观点来确认一个固执己见的事实：“我确信我做到了.让我们再检查一遍.是的！(或者哎呀，让我们纠正它吧！”这有助于阻止青年团行为，这将消耗士气，并对效率产生负面影响。
- 现有主流工具集(JIRA，Trello，Asana，Freshdesk )的简单实现.Github，回购和罚单的比特桶..。Zapier，IFTTT用于集成缺乏内置集成的系统)
对于我曾经管理或建立过的每个团队(作为开发经理、PMO、产品经理、顾问或创始人)，我都明确地期望每一行代码都可以跟踪到基于上述原因的需求。我主张在git中使用每个主题的分支模式来实现这一点(Github或Bitbucket)，其中分支以JIRA任务/故事/bug为前缀(例如。XYZ-2443-FIX-bug)，以便JIRA的集成自动显示到问题分支的链接。
当然，这不是唯一的办法，但这是我现在喜欢的过程，目的是说明一个具体的例子。
https://stackoverflow.com/questions/39966461
复制相似问题
腾讯云开发者
