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% 的估計就足夠好,以及採取公開的工作方式,但我們組織的保密通訊協定所述的機密資訊除外。