Decision-less Agility
Failure Pattern của Decision Avoidance, Context Erosion, và Measurement Gap
Summary
Decision-less Agility là Failure Pattern trong đó,
trong phát triển Agile,
"không quyết định" được hợp lý hóa như sự linh hoạt,
và một khoảng trống trong việc ra quyết định trở nên cố định một cách cấu trúc.
Pattern này mô tả quá trình mà khả năng ra quyết định bị mất
trong cả software và tổ chức
như kết quả của các động lực chồng chéo như decision avoidance, absence of measurement, và lack of context.
Điều được đề cập ở đây không phải là lỗi trong các phương pháp hoặc công cụ cụ thể,
mà là cơ chế mà các lựa chọn với thiện chí hội tụ về một cấu trúc lặp lại của thất bại.
Context
Pattern này xuất hiện trong các môi trường mà phát triển Agile đã trưởng thành như một tùy chọn
và đồng thời, tuổi thọ software đã trở nên dài hạn.
Trong các tình huống mà sự không chắc chắn cao và tất cả requirements và specifications không thể được xác định trước,
Agile được chọn,
nhưng có những trường hợp mà nó tiến hành mà không phân biệt giữa
"không quyết định tương lai" và "điều tối thiểu phải được quyết định bây giờ."
Trong các môi trường như phát triển hợp đồng hoặc phát triển thuê ngoài kiểu phòng thí nghiệm mà nhiều stakeholders tồn tại,
responsibility ra quyết định bị phân tán,
và các vấn đề không thể quyết định ngay chỗ có xu hướng bị hoãn lại một cách cấu trúc.
Trong những năm gần đây, phát triển hỗ trợ AI đã trở nên phổ biến,
và khả năng tiến hành công việc trong khi hoàn thành các giả định mơ hồ và các vấn đề chưa quyết định
càng tăng tốc động lực này.
Khi phát triển tiếp tục trong các tình huống như vậy, triển khai tiến hành dưới dạng bù đắp cho các giả định chưa quyết định,
và "Source of Truth" cho specifications dần dần được nhúng vào code.
Trong software đã được vận hành trong thời gian dài, thay thế PO và luân chuyển team xảy ra,
chỉ để lại tài liệu từng phần và code hiện tại.
Kết quả là, một trạng thái mà không ai có thể giải thích rõ ràng "tại sao nó như vậy" hoặc "nó có thể được thay đổi đến đâu" trở nên bình thường hóa.
Trong các môi trường thiếu context như vậy, phát triển hỗ trợ AI được giới thiệu một phần.
AI thực hiện hoàn thành hợp lý từ thông tin được cung cấp,
nhưng khi các giả định và ràng buộc không rõ ràng, nó đưa ra đánh giá dựa trên các giả định ngầm định, giống như con người.
Do đó, khi kết hợp với phát triển Agile mà việc ra quyết định vẫn mơ hồ, Pattern này có xu hướng biểu hiện.
Forces
Các động lực chính tạo ra Pattern này như sau:
-
Sự không chắc chắn cao và tương lai không thể quyết định
Specifications và hành vi trong tương lai không thể xác định, và lựa chọn "điều chỉnh sau" dễ dàng được hợp lý hóa. -
Rủi ro nắm giữ responsibility quyết định
Các quyết định đi kèm với trách nhiệm giải trình cho các thay đổi và thất bại trong tương lai, và trong các môi trường nhiều stakeholders chúng dễ dàng bị hoãn lại. -
Áp lực để di chuyển nhanh
"Sự thật của tiến trình" được coi trọng như sự an toàn hơn xây dựng sự đồng thuận, và triển khai tiến hành dễ dàng trong khi các vấn đề vẫn chưa quyết định. -
Chi phí viết tài liệu
Chi phí căn chỉnh sự hiểu biết và cập nhật không xuất hiện trong kết quả ngắn hạn, và triển khai trước tiên dễ dàng được hợp lý hóa hơn ghi lại các quyết định. -
Cám dỗ rằng AI ngay lập tức tạo ra "câu trả lời hợp lý"
Công việc tiến hành ngay cả khi các giả định và ràng buộc mơ hồ, làm cho các vấn đề chưa quyết định ít có khả năng nổi lên. -
Absence of measurement và thiếu vật liệu quyết định
Tác động không thể được so sánh, và hoãn lại được coi là một giải pháp tối ưu ngầm định một cách lặp lại, tích lũy một khoảng trống trong việc ra quyết định.
Failure Mode
-
"Source of Truth" cho specifications phân tán vào các đoạn code
Triển khai tiến hành trong khi mang các giả định chưa xác định, vì vậy các quyết định được nhúng cục bộ dưới dạng functions và configuration values.
Ý định và boundaries không hợp nhất ở một nơi, và cơ sở của hành vi trở nên không thể tái tạo do sự phân tán code. -
Các khoảng trống trong các quyết định tích lũy và trở nên cố định như các giả định ngầm định
Hành vi được sử dụng tạm thời tiếp tục và trở thành một tiêu chuẩn ngầm định, và không ai có thể chỉ định phạm vi có thể thay đổi.
Các thay đổi mang sự không chắc chắn của "có thể hỏng," và kết quả là, hoãn lại được tái tạo. -
AI completion tăng cường các giả định và các mâu thuẫn trở nên tiềm ẩn
Công việc tiến hành ngay cả mà không có các giả định rõ ràng, vì vậy các giả định cục bộ được xác nhận trực tiếp trong triển khai.
Ngay cả khi các giả định khác nhau cùng tồn tại, chúng hoạt động trong ngắn hạn, làm cho thiếu tính nhất quán khó phát hiện. -
Absence of measurement ngắt kết nối đường dẫn feedback
Độ lớn của tác động và hiệu quả không thể quan sát, và việc ra quyết định để cải tiến hoặc sửa chữa không thành lập.
Các thảo luận nghiêng về các xung đột ý kiến, và việc ra quyết định trở nên cố định như một thói quen hoãn lại. -
Tài liệu trở nên sau thực tế, và Source of Truth trở nên vắng mặt
Các mô tả được cập nhật một phần sau thực tế và không thể chỉ ra nơi cơ sở mới nhất nằm.
Người mới vào dựa vào reverse-engineering code, và chi phí và rủi ro thay đổi tăng lên. -
Boundaries trở nên không ổn định và các phụ thuộc giữa các modules trở nên không thể dự đoán
Các specifications không xác định thấm vào interfaces, và cả callers và providers trôi về tối ưu hóa cục bộ lẫn nhau.
Tính nhất quán như một tổng thể trở nên khó duy trì, và phạm vi tác động của các thay đổi có xu hướng mở rộng.
Consequences
- Maintenance cost tăng tích lũy
(Part I: What Breaks — Responsibility / Boundary) - Một trạng thái mà "không ai hiểu toàn bộ" trở nên cố định
(Part I: What Breaks — Responsibility / Boundary) - Hỗ trợ AI chỉ có thể được sử dụng theo cách hạn chế
Nó phụ thuộc vào một số nhân sự có thể bổ sung các giả định và ràng buộc bản thân,
và không hoạt động như hỗ trợ quyết định cho tổ chức trong tổng thể.
(Part II: Why It Breaks — Context Erosion) - Agile mất lòng tin
Khoảng cách giữa kỳ vọng của "phải linh hoạt" và thực tế không thể giải thích,
và bản thân quá trình trở nên được đặt câu hỏi.
(Part II: Why It Breaks — Decision Avoidance) - Organizational learning dừng lại
Learning loop không thành lập do absence of measurement,
và cải tiến không được chuyển đổi thành kiến thức có thể tái tạo.
(Part II: Why It Breaks — Broken Learning Loop)
Countermeasures
Sau đây không phải là danh sách các giải pháp,
mà là các counter-patterns để thay đổi động lực với can thiệp tối thiểu chống lại Failure Mode.
-
Thiết lập một decision gate tối thiểu
Phân biệt giữa immutable, tentative, và undecided để ngăn hoãn lại tích lũy thành "implicit specifications." -
Giới thiệu một chỉ số quan sát đơn lẻ
Ưu tiên khả năng so sánh hơn độ chính xác, tạo ra một trạng thái mà các quyết định kết nối với các deltas thay vì ý kiến. -
Cố định boundaries (contracts) cho một khoảng thời gian ngắn và bảo đảm các bậc tự do nội bộ
Cục bộ hóa tác động bên ngoài và duy trì giả định rằng lặp lại có thể "tiến hành an toàn." -
Thống nhất Source of Truth đến một điểm
Bảo vệ tính nhất quán của điểm tham chiếu thay vì tính đầy đủ, ngăn vị trí hiện tại của specifications bị mất. -
Để lại intent quyết định với các nhãn tối thiểu
Để lại immutable/tentative/deadline ở các vị trí liền kề, tạo ra một lịch sử quyết định có thể xác minh sau. -
Cố định assumption templates khi sử dụng AI
Trình bày các giả định, ràng buộc, và immutables trước, và chấp nhận/từ chối output được tạo ra bởi boundaries và indicators. -
Bình thường hóa việc xóa các mục hoãn lại
Chọn giữa "quyết định/loại bỏ/gửi về phía trước," và không làm cho hoãn lại thành một trạng thái ổn định.
Resulting Context
Sự không chắc chắn tiếp tục tồn tại,
nhưng các giả định cho các quyết định được làm rõ, và hoãn lại trở nên ít có khả năng tích lũy.
Với một chỉ số đơn lẻ, hiệu quả trở nên có thể so sánh,
và các thay đổi được thảo luận như các deltas thay vì ý kiến.
Khi boundaries và điểm tham chiếu ổn định,
các thay đổi được coi như các đánh giá có thể xác minh
thay vì "suy đoán có thể hỏng."
Output được tạo bởi AI cũng vậy
có thể được chấp nhận/từ chối dựa trên các giả định, boundaries, và indicators.
Đây không loại bỏ sự không chắc chắn, nhưng sắp xếp nó thành một dạng mà các quyết định có thể được thực hiện.
See also
-
Responsibility Diffusion
Một cấu trúc dẫn xuất trong đó động lực tránh các quyết định làm cho bản thân chủ thể ra quyết định trở nên mơ hồ. -
Specification-by-Absence
Một derived pattern trong đó, kết quả của việc tiến hành mà không quyết định, các vấn đề không xác định trở nên cố định như các de facto specifications.
Appendix: Conceptual References
- Responsibility & Decision
Background về các động lực trong đó decision responsibility và decision authority trở nên mơ hồ một cách cấu trúc. - Pattern Language
Foundation của định dạng mô tả trong đó Forces hội tụ vào cấu trúc. - Feedback, Measurement & Learning
Background về ngắt kết nối learning loop do absence of measurement. - Information Hiding & Boundaries
Background của failure structure trong đó các vấn đề chưa quyết định rò rỉ vào code và boundaries.
Appendix: References
- James O. Coplien, Organizational Patterns of Agile Software Development, 2004.
- W. Edwards Deming, Out of the Crisis, 1982.
- Stafford Beer, Cybernetics and Management, 1959.
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.