ADR团队协作问题

可以考虑特定的人员、特定的角色、特定的团队或特定的部门等方面;也要考虑是否存在可以委托创建 ADR 的人员、角色、团队或部门,即由他们提出请求,而由其他人来撰写。

示例回答:我们组织中任何阅读过架构决策记录 README 页面的人都可以提出 ADR,也就是说,该人员可以开始撰写并与团队分享。

可以考虑诸如你所在组织的团队工作方式、软件系统结构、跨团队协调、长期可维护性、外部接口、你希望让谁受益等方面。

示例回答:当我们希望未来的开发人员理解我们所做事情背后的“为什么”时,我们就想创建 ADR。

可以考虑诸如以下情形:决策与架构无关;决策很小,例如风险极低、自成一体或仅涉及单个开发人员;决策已在别处(例如标准、政策或文档)得到充分涵盖;或者决策是临时性的,例如变通方案、概念验证或实验。

示例回答:当决策在范围、时间、风险和成本上都很有限,或已在别处涵盖时,我们会跳过 ADR。

可以考虑创建流程、调研流程、决策流程、实施流程和退役流程等方面。考虑如何随时间跟踪 ADR 的生命周期,例如如何将 ADR 从一个状态推进到下一个状态,以及如何向利益相关者传达这一点。

示例回答:我们希望 ADR 有五个生命周期阶段:启动 → 调研 → 评估 → 实施 → 维护 → 退役。

可以考虑诸如 ADR 的验收标准等方面,也就是说,你如何知道它已经足够好,可以从一个生命周期步骤进入下一个?问题是否被清楚地阐述?是否已考虑各种备选方案?权衡取舍是否得到充分理解并记录?所有相关背景是否齐备?所有相关利益相关者是否都已参与?所有反馈是否都已吸收?

示例回答:当积极参与的团队 1)已完成调研,2)已完成评估,3)已向利益相关者发布 ADR 提案并征求意见,时限为一周,4)所有利益相关者的意见都已吸收和处理之后,我们希望由利益相关者对 ADR 进行投票。

可以考虑提议者、调研者、评估者、评审者、批准者、维护者等角色。考虑诸如与利益相关者沟通、确保满足期望、在网站或内网上分享、定期复查工作(尤其是在发生相关变化时)等职责。

示例回答:我们希望每个 ADR 始终有一名主要联系人、一名次要联系人和一个负责团队;他们负责沟通、发布、维护、至少每年一次的定期复查,以及在需要时最终使其退役。

可以考虑诸如你所在组织的工作方式、任何特殊的合规需求(例如法律方面或人力资源方面),以及你希望如何处理共识、冲突与升级。在 ADR 方面,是否有某些领域、人员或团队比其他人影响力更大,例如能够批准、投票或否决它?

示例回答:ADR 的治理按以下优先顺序:首席执行官(CEO)、首席技术官(CTO)、首席法务官(CLO)、实施 ADR 的团队、团队中最了解该 ADR 的专家。除非 ADR 中另有说明,其他人没有治理权。

可以考虑诸如你所在组织的工作方式,包括快速行动与慢速行动、决策共识与决策冲突、风险偏好与安全偏好、公开讨论与私下讨论等。

示例回答:我们采用的领导力原则是:崇尚行动、有异议但服从决定(disagree-and-commit)、对于易于撤销且易于隔离的决策,70% 的估计就足够好,以及采取公开的工作方式,但我们组织的保密协议所述的机密信息除外。