持续交付/部署和流程控制

Question

从“流程控制”POV，在持续交付/部署环境中，要求源控制提交与敏捷PM（或票务工具）“工作项”相关联有多重要？这里的“工作项”意味着以下任何一个：用户故事，任务，缺陷，错误等。

最终目标是确保开发人员不会将新功能投放到生产中而不是从产品所有者那里获得。显然，代码审查是正确的流程控制故事的关键部分，但是进行代码审查会假定审阅者可以查看相关的工作说明（例如用户故事），以确保代码更改反映所请求的工作。

这就是问题所在。

上下文

我总是假设拥有一个工作单与工作票相关联的工作流程，例如Jira，但现在我正在与一个PM工具无法关联工作的公司合作带有源提交的-items或缺陷票据。

有了这个客户，我也看到了一个捕获22。首先，PMO的代表告诉我，不需要这样的票证到提交协会。其次，工程组织为外部咨询公司支付了审计和标记主要流程缺陷的费用。确定的第一个缺陷是管理层无法知道开发人员提交是否对授权工作有任何影响。

从我的POV，我认为项目管理办公室需要意识到他们是“尾巴摇摆不定”，他们需要采用工具更改或特殊集成来克服这个问题（更不用说敏捷哲学更成熟）。

然而，或许我只是过分关注票证提交关联的那个，也许还有另一种方法可以在没有特定机制的情况下实现有效的流程控制？

Answer 1

在处理受监管行业（例如医疗保健或管理机构）时，需要从范围到代码的完全可追溯性。我曾经不得不进行一次审核，以验证每行代码都与SRS中用于FDA批准的一行相关联，尽管通常它足以证明存在可跟踪性方法（例如，github中的一个分支，被命名为匹配JIRA中的任务/故事并启用代码集成）。

如果您不在受监管的行业中，则需要代码可追溯性不是必需的......但它仍然非常有用。优点包括但不限于：

• 对团队中的每个人完全透明，不论是否具有技术。这唤起的信心是惊人的，它减少了喋喋不休的数量。
• 报告以确定要求中的哪个主题导致最大量的代码流失，因为这会带来沉重的代价。
• 识别受PR影响的功能。当计划发布时，发布的某些方面无法实现或有错误，许多代码已经合并，并且团队需要隔离要发布的内容和不发布的内容，这非常有用。
• 通过删除意见来确认一个固执己见的事实：＆＃34;我确定我做到了......让我们仔细检查......是的！ （或者哎呀，让我们纠正它！）＆＃34;。这有助于阻止CYA行为，这会消耗士气并对效率产生负面影响。
• 使用现有主流工具集进行简单实施（JIRA，Trello，Asana，Freshdesk用于门票...... Github，Bitbucket用于回购和门票...... Zapier，IFTTT用于整合缺少内置集成的系统）

对于我曾经管理或建立的每个团队（作为开发经理，PMO，产品经理，顾问或创始人），我明确期望每一行代码都可以追溯到上面列出的原因。我主张使用git（Github或Bitbucket）中的每个主题分支模式来实现它，其中分支以JIRA任务/故事/错误为前缀（例如，XYZ-2443-fix-that-bug），以便JIRA＆＃ 39; s集成自动显示分支到问题的链接。

当然，这不是唯一的方法，但这是我目前的首选流程，旨在说明一个具体的例子。