Gần đây, tôi đã có một cuộc thảo luận về “các nhóm tính năng”, tại sao chất lượng của họ kém và tại sao họ lại là một ví dụ khác về những ý tưởng tồi do SAFe thúc đẩy, tạo ra một bãi mìn để mọi người điều hướng trong khi cố gắng tìm những ý tưởng hay mà SAFe đã sao chép vào khuôn khổ của họ. Theo Scaled Agile Framework, một nhóm tính năng tập trung vào việc cung cấp một tính năng hoàn chỉnh từ đầu đến cuối theo quan điểm của người dùng. Ngược lại, một “nhóm thành phần” tập trung vào việc cung cấp các khả năng kinh doanh cụ thể; chẳng hạn như một nhóm tập trung vào tính thuế hoặc quản lý hàng tồn kho.

Thoạt nhìn, điều này có vẻ ổn từ góc độ tối ưu hóa việc sử dụng tài nguyên. Chúng tôi có thể chỉ định các nhóm cho luồng tính năng trên hồ sơ tồn đọng và khiến mọi người luôn bận rộn. Tuy nhiên, điều này bỏ qua tác động của các vấn đề giao tiếp giữa các nhóm, cách giải quyết các xung đột hợp nhất, tải trọng nhận thức để hiểu mọi thứ về hệ thống, v.v. Sơ đồ của họ ở trên giảm thiểu sự phức tạp của bất kỳ ứng dụng nào có nhiều nhóm đóng góp đến toàn bộ ngăn xếp hoặc tác động và độ phức tạp của ba, bốn nhóm trở lên đang cố gắng phối hợp công việc trong các silo trên toàn bộ ứng dụng.

Cá nhân tôi đã từng làm việc theo cách đó trong quá khứ và đã phải giúp điều phối việc tích hợp mã. Mẫu này cũng bỏ qua mọi thứ chúng ta đã biết trong hơn 50 năm về tác động của giao tiếp đối với kiến ​​trúc ứng dụng và tác động tích cực của việc “bạn xây dựng nó, bạn chạy nó” đối với chất lượng và sự ổn định. Điều này đưa chúng ta đến một điều khác mà mô hình này bỏ qua, tối đa hóa việc sử dụng không phải là mục tiêu. Mang lại giá trị là mục tiêu. Cung cấp giá trị có nghĩa là chúng ta có thể cung cấp, nhận phản hồi nhanh chóng và điều chỉnh. Điều đó cũng có nghĩa là chúng tôi phản ứng nhanh chóng và khắc phục thất bại. Hai khả năng đó được kết hợp chặt chẽ và yêu cầu thiết kế tổ chức tốt hơn.

Có người hỏi tôi: “Để giúp hạ thấp vùng kháng cự cho những người dựa vào điều này, giải pháp thay thế nào tốt hơn?”

Giải pháp thay thế là nêu rõ các mục tiêu kinh doanh và sau đó thiết kế tổ chức đi theo con đường ít gặp trở ngại nhất để đạt được những kết quả đó. Bắt đầu ở cuối và làm việc lạc hậu.

Mục tiêu: Cải thiện Thời gian trung bình để sửa chữa (MTTR) của chúng tôi

Mối quan tâm thiết kế chính của xe đua Công thức 1 là giảm thiểu thời gian dừng pit. Họ cũng thực hành tinh thần đồng đội cần thiết để tận dụng các yếu tố thiết kế đó một cách hiệu quả nhất. Kết quả là thời gian dừng pit trung bình dưới 3 giây ở F1. Chúng tôi có một thách thức tương tự trong phần mềm. Để phần mềm trở nên hữu ích, mọi người cần dựa vào nó, vì vậy khi xảy ra sự cố, chúng tôi cần có khả năng khôi phục nhanh chóng. Để giữ MTTR ở mức thấp, chúng tôi cần hệ thống dễ sửa chữa. Chúng tôi cần các công cụ, kiến ​​thức, hành vi và kiến ​​trúc ứng dụng cho phép thực hiện điều đó. Chúng tôi cũng cần cơ cấu tổ chức cho phép những điều đó. Sau khi thiết kế khả năng phản hồi nhanh chóng, chúng tôi có thể tận dụng khả năng đó để đưa ra những thay đổi mới và phản hồi nhanh chóng phản hồi về các tính năng mới.

Chuẩn hóa giao hàng

Phục hồi nhanh chóng sau thất bại đòi hỏi một cách đáng tin cậy để cung cấp các thay đổi trong trường hợp khẩn cấp một cách an toàn và nhanh chóng. Việc tự động hóa quy trình đó từ đầu đến cuối đảm bảo chúng tôi không đưa ra phương sai do sai sót khi thực hiện các bước thủ công trong điều kiện căng thẳng. Chúng tôi cũng cần đảm bảo rằng quy trình khắc phục sự cố khẩn cấp của chúng tôi luôn sẵn sàng. Thời gian tồi tệ nhất để phát hiện ra rằng nó không phải là trong trường hợp khẩn cấp. Chúng tôi làm điều đó bằng cách chỉ sử dụng quy trình khẩn cấp của mình để cung cấp tất cả các thay đổi. Điều đó không chỉ giúp chúng tôi liên tục cải thiện khả năng phản hồi nhanh chóng mà còn loại bỏ một nguồn phương sai khác tạo ra lỗi để có một quy trình làm việc duy nhất cho tất cả các thay đổi. Nó cũng liên tục giảm chi phí thay đổi khi chúng tôi tiếp tục tối ưu hóa quy trình hỗ trợ vận hành.

Thiết kế cho hoạt động

Đường ống phân phối của chúng tôi là tính năng bằng không. Mối quan tâm tiếp theo là khả năng quan sát. Điều đó nên được thực hiện ngay từ lần giao hàng đầu tiên, không phải là điều mà chúng tôi lo lắng vào một ngày nào đó sau khi chúng tôi “xong việc”. Ứng dụng sẽ cảnh báo cho chúng tôi khi xảy ra hoặc sắp xảy ra lỗi. Hy vọng rằng chúng tôi cũng đã thiết kế cho các tác động bên ngoài có thể xảy ra và có thể làm suy giảm các tính năng một cách nhẹ nhàng khi các phần phụ thuộc không thành công (tôi không bao giờ tin tưởng bất kỳ phần phụ thuộc phần cứng hoặc phần mềm nào). Sẽ dễ dàng xác định vị trí và những gì cần sửa vì mã rất dễ hiểu. Thiết kế mô-đun và kiến ​​trúc rõ ràng giữ cho độ phức tạp ở mức thấp và giúp hệ thống dễ dàng sửa chữa hơn. Chúng tôi cũng cần một nhóm hỗ trợ ứng dụng hiểu nó.

Xây dựng một tổ chức hỗ trợ

Chúng tôi cần các đội có thể nhanh chóng xác định cái gì và ở đâu bị hỏng để giảm thiểu thời gian cần thiết để khám phá trong một sự cố. Để một nhóm có thể nhanh chóng xác định nơi nào đó bị hỏng, yêu cầu phải hiểu vấn đề mà ứng dụng đang giải quyết, cách ứng dụng giải quyết vấn đề đó cũng như kiến ​​trúc và văn hóa của mã. Đối với các ứng dụng nhỏ, điều này không quá khó. Một nhóm duy nhất có thể hỗ trợ ứng dụng và làm quen với nó. Đối với các ứng dụng lớn hơn, chúng tôi tận dụng Thiết kế hướng miền chiến lược.

Chúng tôi cố tình sắp xếp các nhóm hỗ trợ phù hợp với các khả năng kinh doanh cụ thể để họ có thể trở thành chuyên gia về miền và chuyên gia về mã triển khai các miền mà họ hỗ trợ. Hãy ghi nhớ Định luật Conway , chúng tôi đảm bảo rằng cùng một nhóm hỗ trợ các thành phần có liên quan chặt chẽ với nhau và các thành phần chúng tôi muốn giữ liên kết chặt chẽ với nhau, chúng tôi đưa vào các nhóm khác nhau. Điều này làm giảm tải nhận thức và cho phép nhóm giải quyết các vấn đề sản xuất một cách nhanh chóng trong khi vẫn duy trì kiến ​​trúc mong muốn.

Phát triển ứng dụng

Để ứng dụng luôn hữu ích, ứng dụng phải dễ dàng phát triển khi chúng tôi tìm hiểu thêm và nhu cầu của người dùng thay đổi. Chúng tôi cũng cần phát triển một nhóm có thể nhanh chóng phát triển hệ thống mà không làm suy giảm tính ổn định của chúng tôi. Chúng tôi không muốn các nhóm ngẫu nhiên đóng góp các tính năng mới cho ứng dụng, nếu không nó sẽ làm giảm chất lượng kiến ​​trúc và làm tăng nợ công nghệ. Điều này đã được chứng minh trong nhiều thập kỷ. Định luật Conway luôn có hiệu lực. Để một nhóm có thể nhanh chóng phát triển ứng dụng mà không làm suy giảm hoạt động, họ cần phải trở thành chuyên gia về miền và chuyên gia về mã triển khai các miền mà họ đang nâng cấp. Lưu ý rằng đó là yêu cầu tương tự để cho phép nhóm hỗ trợ khắc phục sự cố một cách nhanh chóng.

Tại sao hai đội?

Đó là một câu hỏi hay. Tại sao chúng tôi muốn một nhóm thêm các tính năng mới vào ứng dụng và một nhóm khác sửa lỗi? Chúng tôi không. Điều đó gây ra các vấn đề về giao tiếp, che giấu phản hồi chất lượng có giá trị từ nhóm phát triển và chắc chắn làm tăng nợ công nghệ, khiến ứng dụng khó thay đổi hơn. Ngoài ra, hãy xem xét sự khác biệt giữa “lỗi” và “tính năng mới”. Lý do duy nhất để thêm một tính năng mới là ứng dụng không hoạt động hoặc hoạt động khi cần thiết. Đó chính xác là định nghĩa tương tự như một khiếm khuyết. Sự khác biệt giữa một khiếm khuyết và một tính năng chỉ là mức độ ưu tiên. Nếu hai nhóm đang “sửa chữa” ứng dụng một cách độc lập, thì chúng ta có hai nguồn thông tin xác thực về các vấn đề về chất lượng và giao tiếp làm giảm chất lượng phản hồi. Đây là vấn đề tương tự mà chúng tôi gặp phải với các nhóm tính năng.

Nhóm có cái nhìn tốt nhất về tính ổn định của hệ thống và có nhiều kinh nghiệm vận hành hệ thống nhất cũng là những người đủ điều kiện nhất để thêm các tính năng mới. Họ hiểu rõ hệ thống nhất, hiểu không gian vấn đề và quan tâm nhất đến kết quả đạt được vì họ nghe về các vấn đề trước tiên. Vì vậy, lựa chọn rõ ràng là loại bỏ nhóm phát triển và trao cho nhóm hỗ trợ khả năng kinh doanh quyền sở hữu để nâng cấp nó.

Điều gì về độ tin cậy kỹ sư trang web?

Chúng ta không nên có hỗ trợ xử lý nhóm SRE sao?

SRE không hỗ trợ ứng dụng riêng. SRE làm việc với các nhóm sản phẩm để giám sát và cung cấp phản hồi để nhóm có thể làm cho ứng dụng của họ đáng tin cậy hơn. Họ là những người đầu tiên biết khi có vấn đề, nhưng họ không sở hữu giải pháp. Nếu ứng dụng của nhóm trở nên không ổn định đến mức đòi hỏi quá nhiều sự chú ý từ nhóm SRE, ứng dụng đó sẽ được trả lại cho nhóm để ổn định. Họ không phải là nạn nhân.

Nhưng tôi không có quyền truy cập vào sản xuất!

Điều đáng nói là những người cần phản hồi nhất từ ​​sản xuất không phải lúc nào cũng có quyền truy cập. Tôi cảm thấy kinh hãi khi xây dựng thứ gì đó mà không có khả năng nhận phản hồi về tính ổn định, chức năng, v.v. Tôi đã phải làm điều đó trước đây. Nó luôn luôn kết thúc trong nước mắt. Nếu bạn không có quyền truy cập vào sản xuất, bạn cần tìm cách giảm thiểu rủi ro đó. Làm bất cứ điều gì bạn có thể để nhận phản hồi về "chúng ta có đang xây dựng đúng không?" và "nó có đang được xây dựng đúng cách không?" Chúng ta có thể có được một môi trường phù hợp với sản xuất không? Có cách nào để nhận phản hồi từ người dùng dự định không? Mọi dòng mã bị thay đổi nhưng không được xác thực trong môi trường giống như sản xuất đều là rủi ro và lỗi tiềm ẩn. Để mắt đến nó.

Tối ưu hóa cho những điều sai trái

Nhiều tổ chức được thiết kế xung quanh Trải nghiệm quản lý (ManEx) hoặc mong muốn tối đa hóa việc sử dụng hoặc đầu ra, nhưng không có mục tiêu nào trong số đó giải quyết vấn đề của người dùng một cách hiệu quả.

Một tổ chức trước đây mà tôi làm việc đã quyết định “cải thiện năng suất của nhà phát triển” bằng cách loại bỏ “sự phân tâm” về hỗ trợ sản xuất khỏi các nhóm phát triển. Trong quy trình ban đầu, trung tâm cuộc gọi sẽ gọi cho nhóm nhà phát triển sau khi chạy bất kỳ playbook nào họ cung cấp cho nhóm hỗ trợ không hoạt động. Trong quy trình “cải tiến” mới, bộ phận hỗ trợ là một tổ chức hoàn toàn khác theo cấu trúc báo cáo khác chịu trách nhiệm hỗ trợ Cấp 1 và 2 với các nhóm phát triển là Cấp 3. Điều này làm giảm trải nghiệm người dùng.

Tác động ngay lập tức là thay vì nhóm phát triển được gọi trong vòng 15 phút sau khi xảy ra sự cố, chúng tôi được gọi sau 90 phút kể từ khi xảy ra sự cố. Sau đó, chúng tôi phải bắt kịp bối cảnh của vấn đề trước khi có thể giúp giải quyết vấn đề vào lúc nửa đêm. Điều này kéo dài thời gian ngừng hoạt động và có nghĩa là chúng tôi thường phải đối phó với những người dùng thù địch. Chúng tôi cũng mất khả năng đào tạo các thành viên mới trong nhóm hỗ trợ bằng cách sử dụng các vấn đề có tác động thấp hơn vì chúng tôi không còn nhìn thấy các vấn đề nhỏ hơn. Thay vào đó, tổ chức hỗ trợ sẽ viết một tập lệnh để vá hệ thống hoặc thậm chí triển khai một bản sửa lỗi cho mã. Điều này che giấu các vấn đề cấp thấp từ các nhóm phát triển. Việc thiếu phản hồi chất lượng này có nghĩa là các lỗi nhỏ phát triển thành các lỗi lớn khi quá trình phát triển tiếp tục trong khi không nhận ra các vấn đề cấp thấp mà mã mới đang được xây dựng. Chúng tôi đã giải quyết vấn đề này bằng cách tổ chức lại thành các nhóm sản phẩm từ các nhóm tính năng, chuyển sang quy trình làm việc trên đĩa CD và thực hiện các thay đổi nhanh hơn mức mà tổ chức hỗ trợ có thể tiếp thu. Điều này có nghĩa là hỗ trợ được mặc định trở lại với chúng tôi, chúng tôi nhận được phản hồi chất lượng tốt hơn nhiều và có thể ứng phó với các sự cố cũng như phát triển hệ thống nhanh hơn nhiều.

Phản hồi từ SAFe

Khi tôi đăng đề xuất SAFe cho các nhóm tính năng làm ví dụ về một trong nhiều phản mẫu do SAFe thúc đẩy, một “Nhà tư vấn thực hành SAFe được chứng nhận” đã phản hồi.

Tôi cho rằng mô hình nhà máy sản xuất tính năng ít nhất cũng tồi tệ với các nhóm (thành phần) dịch vụ kinh doanh dựa trên DDD chỉ cung cấp các đầu ra dịch vụ cụ thể và bị ngắt kết nối khỏi kết quả kinh doanh từ đầu đến cuối, vì những điều này chỉ có thể đạt được khi tích hợp E2E thành công của từng dịch vụ có liên quan và không [thành phần] đơn lẻ nào chịu trách nhiệm về tầm nhìn/kết quả lớn hơn đó.

Họ có thể lập luận rằng, nhưng họ không cung cấp bằng chứng. Điều đó có vẻ hợp lý đối với họ vì họ cũng nhận xét về việc đảm bảo mọi người có đủ việc làm. Đó không phải là mục tiêu của chúng tôi. Hoạt động ổn định và phát triển nhanh chóng là mục tiêu của chúng tôi.

Tôi đã làm việc trong nhiều năm bằng cách sử dụng cả hai mẫu. Trong mọi hệ thống lớn mà tôi đã làm việc được tổ chức dựa trên các khả năng, mọi nhóm đều biết cách thành phần của họ phù hợp với tổng thể lớn hơn nhờ cả các cuộc thảo luận về lộ trình cấp cao liên tục và sơ đồ miền cho thấy sự tương tác giữa các thành phần. Các nhóm đã nói chuyện với nhau để điều phối các thay đổi hợp đồng theo cách cho phép phân phối không đồng bộ và đảm bảo khả năng tương tác. Các nhóm hiểu cách xử lý dữ liệu để ngăn chặn đột biến không phù hợp. Không có khả năng chồng chéo tạo ra nhiều nguồn sự thật cho luồng hoặc thông tin. Việc phối hợp rất dễ dàng vì các nhóm chỉ cần phối hợp với các nhóm mà họ chia sẻ giao diện chứ không phải toàn bộ hệ thống. Chất lượng cao vì mỗi đội sở hữu khả năng của mình từ khi sinh ra cho đến khi chết. Đây chính xác là cách Amazon và NetFlix hoạt động. Không sử dụng SAFe. Cả hai đều linh hoạt ở quy mô vì họ quản lý quy mô bằng kỹ thuật chứ không phải quy trình.

Thiết kế cho kết quả

“Bạn xây dựng nó; bạn chạy nó” với các nhóm thành phần được thiết kế có chủ ý sẽ mang lại chất lượng cao hơn Phát triển theo hướng Jenga với các nhóm tính năng. Tuy nhiên, điều quan trọng là mọi người hiểu điều đó có nghĩa là gì. Điều đó không có nghĩa là nhóm sở hữu tất cả các vấn đề về cơ sở hạ tầng và phân phối; đó là những gì các nền tảng tự phục vụ tốt dành cho. Các công cụ như Zarf có thể giúp giảm bớt nỗ lực và khối lượng nhận thức trong việc giữ cho môi trường lành mạnh bằng cách tạo cấu hình hệ thống không thay đổi và có thể lặp lại.

Làm việc ngược lại từ các hoạt động đặt trọng tâm của chúng tôi vào nơi nó thuộc về, cung cấp giá trị ổn định. Những người gần gũi nhất với những người sử dụng sản phẩm là những người có trình độ tốt nhất để biết cách cải thiện sản phẩm. Chúng tôi xây dựng các nhóm sở hữu một hoặc nhiều khả năng của sản phẩm, sở hữu cách họ cung cấp những khả năng đó và sở hữu hậu quả của các quyết định của họ để họ có thể nhanh chóng phát triển và sửa chữa những gì họ sở hữu. Chúng tôi thiết kế các nhóm để sở hữu giá trị chứ không phải đầu ra và đảm bảo họ có đường dẫn liên lạc rõ ràng để nhận phản hồi chất lượng.