Nếu hai nhóm Scrum sử dụng cùng một thành phần phần mềm, ai chịu trách nhiệm cung cấp một tầm nhìn kiến trúc rõ ràng về thành phần đó và duy trì / phát triển tầm nhìn này khi cơ sở mã phát triển? Trong Scrum, bạn phải có quyền sở hữu mã tập thể, vậy làm thế nào để đảm bảo rằng sự phát triển được thực hiện bởi Nhóm A không can thiệp vào sự phát triển được thực hiện bởi Đội B?
Câu trả lời:
Tôi không phải là chuyên gia về Scrum, nhưng "quyền sở hữu mã tập thể" của AFAIK có nghĩa là mỗi nhóm và mỗi sản phẩm (và tôi nghĩ rằng câu hỏi của bạn không dành riêng cho Scrum, nó có thể được áp dụng cho bất kỳ quy trình phát triển "mã chia sẻ" nào).
Nếu bạn có hai đội A, B, hai sản phẩm A, B và một thành phần C được chia sẻ, có những kịch bản có thể khác nhau. Có thể thành phần được chia sẻ chủ yếu thuộc về sản phẩm A (và chỉ được tái sử dụng, nhưng không được phát triển, bởi nhóm cho sản phẩm B). Trong tình huống này, đội A chịu trách nhiệm rõ ràng về tầm nhìn kiến trúc. Hoặc ngược lại: nó rõ ràng thuộc về sản phẩm B - vì vậy trách nhiệm là ở đó. Nếu nhóm A chịu trách nhiệm, nhóm B có thể sử dụng một nhánh của thành phần để cho phép sửa lỗi khẩn cấp (cũng cần có cách để tái hòa nhập chúng vào dòng chính của C), nhưng B nên tránh thực hiện bất kỳ sự phát triển lớn hơn nào của thành phần.
Tuy nhiên, nếu cả hai sản phẩm A và B có nhiều "yêu cầu lái xe" cho C, bạn nên quản lý C như một sản phẩm hoàn toàn riêng biệt, với phiên bản riêng, quản lý phát hành, quản lý thay đổi, kiểm tra đơn vị, v.v. và một nhóm riêng biệt có trách nhiệm cho thành phần đó. Đội đó có thể chỉ là một "đội ảo", bao gồm các nhà phát triển riêng biệt từ đội A, B hoặc cả hai. Nhóm này có "quyền sở hữu mã chung" cho C và chịu trách nhiệm về "tầm nhìn kiến trúc". Chỉ cần nghĩ về C onging một thành phần được cung cấp bởi một nhà cung cấp bên thứ ba.
Không có khái niệm "tầm nhìn kiến trúc rõ ràng" trong Scrum hay nhanh nhẹn!
Tôi từ lâu đã là một kiến trúc sư, và rõ ràng với tôi rằng để có một tầm nhìn kiến trúc, người ta cần có một cái nhìn rõ ràng về các yêu cầu trong tương lai. Vì trong hầu hết các trường hợp, các yêu cầu không rõ ràng, nên không có tầm nhìn cố định.
Điều cần thiết là có một kiến trúc đủ thích ứng với các yêu cầu thay đổi. Nói cách khác, mọi thứ thay đổi và kiến trúc thay đổi - tôi không ủng hộ một kiến trúc "mềm" có thể được cấu hình lại. Tôi đang nói về việc chấp nhận rằng kiến trúc mà người ta có ngày nay sẽ bị lỗi thời và sẽ cần phải thay đổi, vì vậy không ai nên "kết hôn" với nó.
Quyền sở hữu mã tập thể có nghĩa là mọi người nên - về lý thuyết - có thể thay đổi bất cứ điều gì. Điều này phải được hiểu là "đối nghịch với silo". Nói cách khác, có thể có rào cản kỹ năng, điều này là bình thường và được mong đợi - không phải ai cũng là một DBA có kinh nghiệm có thể điều chỉnh các truy vấn SQL, để đưa ra một ví dụ - nhưng từ đó, nó không tuân theo chỉ DBA mới có thể tay tối ưu hóa truy vấn. Sẽ có một "chuyên gia miền tính năng" có thể giúp người khác thành thạo, nhưng các nhiệm vụ vẫn phải thuộc về mọi người.
Ví dụ: nếu tôi là chuyên gia tên miền về tính năng "A", thì tôi vẫn mong đợi bất kỳ ai khác làm việc với tính năng "A", nhưng tôi có thể được tư vấn khi cần thay đổi lớn hoặc mọi người cần trợ giúp. Tính năng "A" chắc chắn sẽ không phải là tính năng của tôi . Nó sẽ là một tính năng mà tôi biết rõ. Tôi sẽ thích thú khi biết nhiều tính năng hơn và sở thích của người khác để biết tính năng này.
Trong tổng hợp: kiến trúc được các nhà phát triển thiết kế và thiết kế lại nhiều lần khi các yêu cầu xuất hiện và thay đổi. Mọi người dự kiến sẽ thực hiện bất kỳ thay đổi cần thiết theo kỹ năng của họ và biết khi nào cần yêu cầu giúp đỡ. Không có tầm nhìn dài hạn về kiến trúc bởi vì chúng tôi tin tưởng mọi người và chúng tôi không tin tưởng vào các yêu cầu .
Ví dụ: spotify sử dụng vai trò có tên "Chủ sở hữu hệ thống" để giải quyết vấn đề, trực tiếp từ tài liệu:
Về mặt kỹ thuật, bất cứ ai cũng được phép chỉnh sửa bất kỳ hệ thống nào. Vì các đội là các nhóm tính năng hiệu quả, thông thường họ cần cập nhật nhiều hệ thống để đưa một tính năng mới vào sản xuất. Rủi ro với mô hình này là kiến trúc của một hệ thống bị rối tung nếu không ai tập trung vào tính toàn vẹn của hệ thống nói chung.
Để giảm thiểu rủi ro này, chúng tôi có một vai trò gọi là Chủ hệ thống trực tuyến. Tất cả các hệ thống đều có chủ sở hữu hệ thống hoặc một cặp chủ sở hữu hệ thống (chúng tôi khuyến khích ghép nối). Đối với các hệ thống quan trọng hoạt động, Chủ sở hữu hệ thống là một cặp Dev-Ops - nghĩa là, một người có quan điểm nhà phát triển và một người có quan điểm hoạt động.
Chủ sở hữu hệ thống là người đi đến người của bất kỳ vấn đề kỹ thuật hoặc kiến trúc nào liên quan đến hệ thống đó. Anh ấy là một điều phối viên và hướng dẫn những người viết mã trong hệ thống đó để đảm bảo rằng họ không vấp ngã nhau. Ông tập trung vào những thứ như chất lượng, tài liệu, nợ kỹ thuật, tính ổn định, khả năng mở rộng và quy trình phát hành.
Chủ hệ thống không phải là kiến trúc sư cổ chai hoặc tháp ngà. Cá nhân anh ta không phải đưa ra tất cả các quyết định, hoặc viết tất cả mã, hoặc thực hiện tất cả các bản phát hành. Anh ta thường là thành viên của đội hoặc trưởng nhóm, người có các trách nhiệm hàng ngày khác ngoài quyền sở hữu hệ thống. Tuy nhiên, thỉnh thoảng anh sẽ lấy một chủ sở hữu hệ thống của ngày, và làm công việc dọn phòng trên hệ thống đó. Thông thường chúng tôi cố gắng giữ quyền sở hữu hệ thống này dưới một phần mười thời gian của một người, nhưng tất nhiên nó thay đổi rất nhiều giữa các hệ thống.
Tôi thực sự thích ý tưởng này, có các lợi ích hoặc quyền sở hữu mã tập thể ở cấp công ty (không chỉ ở cấp độ nhóm) mà với các chủ sở hữu hệ thống này đang cố gắng đảm bảo tính toàn vẹn của kiến trúc.
Liên kết đến tài liệu đầy đủ: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , đây là một tài liệu ngắn nhưng rất, rất thú vị dựa trên kinh nghiệm thực tế về quy mô nhanh.
Đó là một vấn đề khó giải quyết, và chắc chắn nó không được giải quyết bởi Scrum, đây là một phương pháp quản lý dự án, không phải là một phương pháp phát triển.
Giải pháp hiệu quả nhất mà tôi tìm thấy là quản lý gói tốt (nuget / gem / etc) và phiên bản. Không bao giờ thực hiện thay đổi đối với đội khác cho đến khi họ sẵn sàng tiêu thụ nó. Hãy để họ tiếp tục sử dụng bản dựng cũ, trong khi bạn chuyển sang bản dựng mới.
Hãy chắc chắn rằng bạn có một chiến lược tạo phiên bản để làm cho nó rõ ràng những thay đổi nào đang vi phạm và đó là các tiện ích mở rộng.
Ngoài ra, khi bạn thực hiện thay đổi, hãy đẩy đánh giá mã tới ai đó TRÊN MACHI ĐỘI. Hãy để họ xem xét khả năng ảnh hưởng đến họ như thế nào, rất lâu trước khi họ buộc phải tiêu thụ nó để họ có thể thực hiện các thay đổi của mình trên đầu trang.
Và, khi mọi thứ trở nên thực sự lộn xộn; khi một nhóm cần thực hiện thay đổi và không thể dễ dàng thay đổi một thay đổi khác (điều này NÊN là một trường hợp thực sự hiếm gặp), phân nhánh mã, biến nó thành một gói hoàn toàn khác, nhưng ưu tiên lấy lại mã chung ngay khi có thời gian cho phép.
Câu trả lời không phải lúc nào cũng rõ ràng như có thể là để các đội quyết định cách họ sẽ chia sẻ bất kỳ thành phần nào.
Ví dụ, nhóm của tôi gần đây đã bắt đầu phát triển một dòng sản phẩm mới có chung nhiều mã với hai nhóm khác, những người đã phát triển các sản phẩm tương tự trong một thời gian dài. Sản phẩm của chúng tôi khác nhau theo một số cách, vì vậy đôi khi chúng tôi phải tìm ra cách để thêm các điểm tùy chỉnh vào mã chung.
Chúng tôi đã có một số xung đột về mã đó và đã thử một vài cách khác nhau để xử lý quyền sở hữu chung. Sau đó, với một tính năng mới lớn sắp ra mắt, chúng tôi quyết định chúng tôi cần phải tập hợp tất cả các đội lại với nhau trên cùng một trang, dẫn đến một nhóm nhỏ hơn gồm một vài thành viên từ mỗi nhóm đang tìm hiểu chi tiết.
Giải pháp mà các đội của chúng tôi đưa ra có thể không hoạt động trong một tình huống khác. Bạn có thể cần một cái gì đó đơn giản hơn, hoặc một cái gì đó trang trọng hơn nhiều. Vấn đề là, bạn có quyền sở hữu tập thể và tìm ra những gì phù hợp với bạn.
Tôi sẽ tự do giả định:
Nếu các giả định trên là chính xác thì đôi khi chỉ có lúc hai đội sẽ can thiệp lẫn nhau. Họ có thể giải quyết nó bằng các cách sau: