Làm thế nào các kiến ​​trúc sư có thể làm việc với các nhóm Scrum tự tổ chức?

Một tổ chức với một số nhóm Scrum nhanh nhẹn cũng có một nhóm nhỏ những người được chỉ định làm "kiến trúc sư doanh nghiệp". Nhóm EA đóng vai trò là người kiểm soát và người gác cổng về chất lượng và tuân thủ các quyết định. Điều này dẫn đến sự chồng chéo giữa quyết định của đội và quyết định của EA.

Chẳng hạn, nhóm có thể muốn sử dụng thư viện X hoặc muốn sử dụng REST thay vì SOAP, nhưng EA không chấp thuận điều đó.

Bây giờ, điều này có thể dẫn đến sự thất vọng khi các quyết định của đội bị ghi đè. Mất đủ xa, nó có khả năng dẫn đến một tình huống mà người EA "lấy" toàn bộ sức mạnh và cuối cùng cả đội cảm thấy bị mất điều kiện và không nhanh nhẹn chút nào.

Các hướng dẫn Scrum có điều này để nói về nó:

Tự tổ chức: Không ai (thậm chí không phải là Scrum Master) nói với Nhóm phát triển cách biến Backlog của sản phẩm thành các phần tăng thêm của chức năng có thể tin cậy được.

Điều đó có hợp lý không? Đội EA có nên tan rã không? Các đội nên từ chối hay đơn giản là tuân thủ?

Một nhóm phát triển được tạo thành từ 3 người9 với các kỹ năng đa chức năng thực hiện công việc thực tế

Scrum Master nên mời "Kiến trúc sư doanh nghiệp" trở thành một phần của nhóm dự án. Sau đó, giao tiếp giữa kiến ​​trúc sư và lập trình viên sẽ là tuyệt vời.

Sự lựa chọn công nghệ được sử dụng là một phần trong các yêu cầu của phần mềm, có nghĩa là đó là một phần của yêu cầu tính năng mà bạn không sử dụng một số công nghệ nhất định, vì bất kỳ lý do gì.

Các kiến ​​trúc sư nói cho các hệ thống và cơ sở mã bởi vì các hệ thống và cơ sở mã không thể tự nói được. Có một kiến ​​trúc sư nói chung là vì lợi ích lâu dài nhất của một công ty, đặc biệt là một công ty dựa trên phần mềm được xây dựng nội bộ.

Các kiến ​​trúc sư không nói với các nhà phát triển cách biến backlog thành gia số (chạy nước rút), họ nói rằng công nghệ nào có thể và không thể được sử dụng. Bạn đang nhầm lẫn hai vấn đề khác nhau.

Giải pháp là không thay đổi gì cả. Nếu các nhóm của bạn đang nản lòng vì các kiến ​​trúc sư quá hạn chế hoặc quá hống hách, đó là vấn đề nhân sự không liên quan gì đến SCRUM và nên được các bên liên quan kinh doanh coi là vấn đề về sự hài lòng của nhân viên và, nếu có thể, điểm mấu chốt ("Chúng tôi mất x%nhiều thời gian hơn để phát triển các tính năng yvì kiến ​​trúc sư zsẽ không cho phép chúng tôi sử dụng Turbo Pascal.")

Điều này là cần thiết để duy trì sự cân bằng giữa việc cần một nhóm lớn để thực hiện dự án và nhu cầu giữ cho các nhóm nhanh nhẹn.

Nói chung, 'nhóm lãnh đạo nhóm' bao gồm một thành viên được bầu từ mỗi nhóm nhỏ hơn. Điều đó cung cấp một số tính chất tự tổ chức, cũng như cung cấp một số cách thức đại diện để các quyết định của nhóm cấp cao được nhóm nhanh nhẹn chấp nhận.

Đối với kịch bản cụ thể của bạn, một cái gì đó nên được thực hiện để ngăn chặn việc giải trừ nhóm nhanh nhẹn, nhưng có lẽ không phải là nổi loạn hoặc chấp nhận đơn giản. Nhóm cần nhận ra rằng bạn đang ở đó để tạo ra phần mềm tốt chứ không phải lý tưởng. Có một nhóm các nhóm khác nhau, mỗi nhóm sử dụng các công nghệ khác nhau để làm những việc tương tự trong cùng một dự án sẽ dẫn đến phần mềm tồi tệ hơn. Có một nhóm các nhóm khác nhau sử dụng các tiêu chuẩn mã hóa khác nhau trong cùng một dự án sẽ dẫn đến phần mềm tồi tệ hơn.

Vì vậy, bạn sẽ cần một số cách để đi đến sự đồng thuận về cách dự án sẽ hoạt động. Nhóm lãnh đạo nhóm được sử dụng ở những nơi khác một cách hiệu quả. Bạn có thể cần phải làm một cái gì đó khác đi, hoặc xem xét lý do tại sao nhóm của bạn không làm điều đó một cách hiệu quả.

Câu hỏi là: lý do tại sao nhóm Kiến trúc sư này tồn tại? Lý do duy nhất tôi có thể nghĩ đến là để thực thi khả năng tương tác giữa các đội khác nhau. Hoặc các nhóm đang làm việc trên các phần khác nhau của một sản phẩm và nhóm kiến ​​trúc sư này tồn tại để giữ cho mọi phần làm việc cùng nhau.

Tôi thực sự không nghĩ rằng chương trình này có thể hoạt động tốt trong môi trường nhanh, vì những lý do chính xác mà bạn nói. Các đội khác nhau nên được khép kín và do đó nên là đầu vào và đầu ra của họ. Vì vậy, việc hạn chế đầu ra của họ chỉ nên là một phần của yêu cầu đối với đầu vào. Nhưng những hạn chế đó phải hợp lý. Một cái gì đó như "Không được sử dụng thư viện X" không phải là một yêu cầu tốt, nhưng nói rằng "Phải giới hạn số lượng thư viện bên thứ 3 đã sử dụng ở mức tối thiểu" hoặc "Thêm thư viện mới, không nên sử dụng trong các nhóm khác." nên ổn

Sau đó, tôi sẽ giải tán đội ngũ kiến ​​trúc sư trên tất cả các đội và sử dụng chuyên môn của họ trong các câu hỏi về kiến ​​trúc. Khi trở thành một phần của nhóm, họ sẽ có thể nhìn rõ hơn các vấn đề mà nhóm đang gặp phải và có thể có ý tưởng tốt hơn hoặc có ý kiến ​​giáo dục hơn về việc thay đổi các phần cốt lõi của kiến ​​trúc. Nó cũng nên được khuyến khích để các kiến ​​trúc sư giữa các đội giao tiếp để đảm bảo kiến ​​trúc vẫn nhất quán giữa các đội.

Nhóm trên tại Scaled Agile Framework nói rất rõ điều này. Hầu hết chúng ta đều giao dịch ở cấp độ Đội, nhưng khi nhân rộng chúng ta cần nhận ra rằng cũng có vai trò ở cấp Chương trình và Danh mục đầu tư. Các quyết định kiến ​​trúc cần phải được đưa ra trên toàn tổ chức, và điều đó sẽ ăn sâu vào những gì đang xảy ra ở các cấp thấp hơn của tổ chức. Không có gì sai khi có quyết định kiến ​​trúc!

Liên quan đến vấn đề này, cuốn sách gần đây của Dean Leffingwell về Yêu cầu phần mềm Agile là một cuốn sách hay về chủ đề này, tôi đã tự mình đọc nó.

Chúng tôi cũng có nhiều nhóm, nhanh nhẹn (một số làm Kanban, một số Scrum) và kiến ​​trúc sư. Các kiến ​​trúc sư chịu trách nhiệm về cơ sở hạ tầng bao gồm tất cả các sản phẩm của chúng tôi (thư viện trợ giúp, xác thực, xây dựng cơ sở hạ tầng), v.v. Họ đưa ra các quyết định kỹ thuật, nhưng cũng thực hiện mọi thứ, chủ yếu là các thành phần cơ sở hạ tầng.

Điều này hoạt động tốt, và thường không có xung đột. Tôi tin rằng một điểm quan trọng là:

Các kiến ​​trúc sư không có thẩm quyền chính thức đối với các đội và không thể ghi đè lên họ. Thông thường, các kiến ​​trúc sư đưa ra quyết định áp dụng cho tất cả các sản phẩm và các nhóm đưa ra quyết định cho sản phẩm của họ. Nếu có xung đột, thì kiến ​​trúc sư & nhóm chỉ cần đạt được thỏa thuận, hoặc leo thang lên quản lý (mặc dù điều đó hiếm khi xảy ra).

Tôi nghĩ rằng nó thực sự quan trọng để làm cho các kiến ​​trúc sư và nhà phát triển đồng nghiệp. Cả hai đều hướng tới một mục tiêu chung, chỉ trong các lĩnh vực khác nhau. Nếu không ai có thể "ghi đè" người khác, hợp tác sẽ tốt hơn.

Tôi không thấy bất kỳ xung đột ở đây. Theo những gì tôi hiểu, tất cả các EA (như một sự hào hoa mà tôi nghĩ đó là) có nghĩa là làm QA. Mọi người nên nhận thức được điều đó.

Bạn nên xem xét, rằng trong bất kỳ phương pháp phát triển nào (đáng được coi là một), việc thu thập các yêu cầu là một bước quan trọng, cho dù đó là lặp đi lặp lại hay trả trước.

Một số trong những yêu cầu này được thiết lập bởi chính sách của công ty. Và những điều này đặt ra các quy tắc cơ bản:

• Nhóm sẽ phải tuân theo chúng như bất kỳ yêu cầu nào khác. Thách thức chính sách sau đó chỉ đơn giản là nằm ngoài phạm vi của dự án và nên được xử lý riêng.
• Công việc của EA là thực thi các yêu cầu này và không áp đặt sự ưa thích cá nhân của họ. Họ không thích X thì đó là ý kiến ​​cá nhân của họ. Không hơn không kém. Đối xử với nó như bất kỳ ý kiến ​​khác. Tuy nhiên, nếu EA có thể cho thấy rằng việc sử dụng X vi phạm một yêu cầu hiện có, thì họ cũng có quyền cấm sử dụng X và nếu họ biết một giải pháp thay thế khả thi và nhóm không có, thì đó là quyền của họ để thực thi.

Nhưng dù bằng cách nào, một yêu cầu hoặc được đáp ứng hoặc không. Nếu quyết tâm đó khó thực hiện, thì yêu cầu còn thiếu và bạn cần nhắc lại để trở nên thực sự có thể kiểm chứng (theo nghĩa rộng hơn). Bạn nên xử lý như bất kỳ yêu cầu nhắc lại.

Kiến trúc sư của bạn không nên ghi đè các quyết định được đưa ra bởi các nhóm nhanh nhẹn của bạn. Kiến trúc sư của bạn nên bao gồm những điều này trong các yêu cầu / câu chuyện được chuyển đến các đội. Họ nên giữ cho các nhóm được cập nhật khi bối cảnh của dự án thay đổi & các yêu cầu về khả năng tương tác mới được đưa ra.

Kiến trúc sư đưa ra các đơn đặt hàng và kiểm tra các quyết định kỹ thuật là một lỗ hổng văn hóa. Họ coi mình là "ông chủ" thay vì chỉ đơn giản là duy trì mục tiêu / tầm nhìn chung & giữ các nhóm riêng biệt trên cùng một trang. Phương pháp nhanh nhẹn dựa trên giao tiếp và liên lạc. Khi các kiến ​​trúc sư của bạn không tham gia cho đến khi quyết định được đưa ra, họ sẽ thất bại nhanh nhẹn.

Martin, tôi nghĩ rằng bạn có thể có một quan niệm sai lầm về cách một nhóm tự tổ chức hoạt động trong môi trường của nó.

Bạn đã trích dẫn Hướng dẫn Scrum: "Không ai (kể cả Scrum Master) nói với Nhóm phát triển cách biến Backlog sản phẩm thành phần tăng thêm của chức năng có thể tin cậy được."

Đây không phải là giấy phép để nhóm Scrum làm bất cứ điều gì họ muốn (miễn là nó cung cấp) mà không liên quan đến nhu cầu công nghệ và kinh doanh của công ty nói chung và nhu cầu của các nhóm khác.

Chắc chắn các bên liên quan có thể lạm dụng ảnh hưởng của họ. Đó là một trong những thách thức của sự hợp tác và chắc chắn nó không giới hạn ở EA. Nhưng sự hợp tác không kết thúc ở ranh giới của đội.

Waterfall hoặc Scrum (điều này có vẻ như trộn lẫn hai, mà vâng, sẽ không hoạt động), nghe có vẻ như là một lớp quản lý khá vô nghĩa đối với tôi ở nơi đầu tiên. Người gác cổng về các quyết định công nghệ nên là người dẫn đầu, người quản lý phát triển tổng thể có nhiệm vụ là giữ cho sở thích của nhà phát triển biến ứng dụng của bạn thành một lựa chọn công nghệ và bất kỳ ai có ngân sách đều phải chi trả cho dự luật tiềm năng.

Không có gì tiếp tục làm tôi ngớ ngẩn như những người không phải là nhà phát triển thực sự có quyết định công nghệ mà không hỏi ý kiến ​​những người thực sự phải chịu hậu quả của những quyết định đó.