Là sở hữu tính năng là một thực hành tốt?

Gần đây trong công ty của tôi, có một đề xuất rằng một nhà phát triển nên tập trung (và chỉ một) trong một tính năng. Điều đó có nghĩa là một cái gì đó giống như đặt nhà phát triển sang một bên trong thói quen nhóm bình thường, giải phóng nó một số trách nhiệm khác (các cuộc họp và như vậy) và người này sẽ là "duy nhất" chịu trách nhiệm về tính năng, công nghệ khôn ngoan.

Để ghi lại, chúng tôi sử dụng SCRUM trong SAFe và chúng tôi có các nhà phát triển toàn thời gian cho mỗi nhóm, chia sẻ QA và chủ sở hữu sản phẩm giữa hai nhóm của chúng tôi (Android và iOS).

Mặc dù tôi đồng ý rằng điều này sẽ tăng năng suất trong một thời gian ngắn, tôi có cảm giác (và tôi nghĩ rằng tôi đã học được ở trường đại học) rằng đây là một thực tiễn tồi vì nhiều lý do:

Xem lại mã mất giá trị.
Chia sẻ kiến thức tối thiểu.
Rủi ro gia tăng.
Mất tính linh hoạt của đội.

Tôi đúng hay không phải là một thực hành xấu?

agile team code-ownership

— mdelolmo
nguồn

Phản ứng ngay lập tức của tôi là điều này có thể hoạt động nếu được thực hiện trong chừng mực, nhưng bạn đã đúng về các vấn đề nếu nó đi quá xa. Mặt khác, kinh nghiệm của tôi là mọi tính năng đều đã có chủ sở hữu trên thực tế: Người cuối cùng dành nhiều thời gian để làm việc với nó.

— Ixrec 11/07/2015

" Một nhà phát triển nên tập trung (và chỉ một) " - Nếu bạn muốn SPOF, bạn nên làm theo cách đó. Gần đây tôi đã đưa ra một lý thuyết thực nghiệm cho thấy người bạn cần nhất trong một tình huống nhất định (" wtf?!? Tại sao anh ta viết nó theo cách đó? ") Chính xác là một điều thực sự không thể truy cập được.

— JensG

@JensG: meh, tôi có một lý thuyết thực nghiệm rằng người tôi thường xuyên cần nhất ("wtf? Tại sao anh ấy lại viết như vậy?") Là một nhân tố xe buýt để "ghi nhớ những điều đáng lẽ phải được viết ra tại thời điểm "là 0. Nó đáng chú ý hơn khi tôi bị chặn bởi một người khác, bởi vì tôi băn khoăn về nó thay vì kiểm tra lại mã hiện có từ đầu về giá trị của chính nó ;-)

— Steve Jessop

@SteveJessop: Chắc chắn, cố gắng tái cấu trúc cách suy nghĩ của những người khác bằng cách kiểm tra một loạt mã KLOC của họ trong khi khách hàng hét lên với bạn rằng anh ta cần một giải pháp ngay bây giờ ( hoặc nếu không! ) Tôi không đủ để thấy bất cứ điều gì buồn cười khi lãng phí thời gian của mình mà thay vào đó tôi có thể chi tiêu hiệu quả hơn.

— JensG

@JensG: may mắn thay, khách hàng của tôi được xã hội hóa tốt hơn bạn. Do đó, tôi không phải chịu quá nhiều áp lực khi tham gia vào kiểu suy nghĩ ma thuật dẫn đến kết luận rằng điều quan trọng đối với tôi thực sự khiến mọi người khó tiếp cận với tôi. Như vậy, tôi nghĩ rằng có một yếu tố đùa trong những gì bạn nói, vì vậy, tôi đủ để thấy một tình huống buồn cười trong đó bạn bù đắp cho mã không thể hiểu được bằng cách cố gắng giữ cho nhiều người xung quanh nhớ cách nó hoạt động. Đặc biệt là vì các wtfs như vậy thường là lỗi ngu ngốc của riêng tôi chứ không phải của các đồng nghiệp của tôi.

— Steve Jessop

Câu trả lời:

Trong 20 năm kinh nghiệm của tôi, tốt hơn là có quyền sở hữu mã xoay vòng trách nhiệm giữa các nhà thiết kế hoặc ít nhất là có một cặp chủ sở hữu. Quyền sở hữu một tính năng có các vấn đề sau, một số vấn đề bạn đã đề cập:

nó có xu hướng thiết kế hố bồ câu và hạn chế cơ hội phát triển của chúng
nó đặt tất cả trứng vào một giỏ để nếu ai đó bị xe buýt đâm hoặc bỏ cuộc, có thể có lỗ hổng kiến thức
một người có thể không thấy vấn đề trong mã và không có đánh giá mã chủ sở hữu ngang hàng sẽ kém hiệu quả hơn nhiều
Thật khó để duy trì tính nhất quán và dễ đọc của mã nếu mọi người đang làm việc với mã bằng cách sử dụng phong cách của riêng họ - trong khi điều này có thể được thực hiện theo hướng dẫn về phong cách, sự tinh tế có thể leo lên đặc biệt là khi sử dụng quy ước về cấu hình nơi mọi người đang dựa vào hành vi mặc định
các nhà phát triển có thể có xu hướng bảo vệ và bảo vệ mã của họ nếu họ sở hữu nó có thể ức chế sự phát triển của mã - nếu một số người sở hữu nó, xu hướng này bị giảm

— Jason K
nguồn

Chắc chắn rồi. Quan trọng phải đề cập đến yếu tố xe buýt là vấn đề rõ ràng nhất với quyền sở hữu chỉ có một người.

— JensG

Tuy nhiên, yếu tố xe buýt cần được giao dịch với chi phí và YAGNI, và liệu xe buýt có thực sự làm tê liệt tổ chức của bạn hay chỉ gây ra nhiều rắc rối. Nếu đó là sự lựa chọn giữa việc thua cuộc, giả sử, 3 giờ một tuần mãi mãi đảm bảo rằng hai người được giáo dục về một mã cụ thể thay vì chỉ một hoặc mất, giả sử, 60 giờ như một lần để ai đó tự đưa mình lên để tăng tốc trong trường hợp một trong những nhà phát triển của bạn bị tấn công, thì trong nhiều trường hợp, bạn đã chọn chi phí một lần. Nhưng vì những lý do đã nêu, silo kiến thức có những nhược điểm khác quan trọng hơn (mặc dù ít rõ ràng hơn).

— Steve Jessop

Quyền sở hữu tính năng là không thể tránh khỏi, và được thực hiện tốt có thể là một điều tốt. Nó giúp xây dựng quyền làm chủ và cho phép tự chủ - hai trong số những trụ cột thường được công nhận . Nó cho thấy rõ ai là người có trách nhiệm đối với mã đó và hỗ trợ trong việc ủy quyền, giao tiếp và nếu không thì sẽ hoàn thành công việc.

Nhưng bạn không nói về điều đó. Bạn đang nói về việc tạo một nhóm mới gồm một người - cắt người này khỏi phần còn lại của mã. Điều đó không tuyệt vời. Nó giới hạn sự nghiệp của họ. Nó thêm rủi ro cho dự án / công ty. Nó gây hại cho comradarie.

Vì vậy, một số điều độ có thể là để loại bỏ điều này khỏi một ý tưởng tồi.

— Telastyn
nguồn

Tôi không đồng ý rằng quyền sở hữu mã bởi một người là không thể tránh khỏi, nhưng nó sẽ thuộc sở hữu của một số ít người. Tôi đã thấy các tổ chức đã làm một công việc tồi tệ là có mã chia sẻ nhưng làm như vậy. Các thiết lập hiệu quả nhất mà tôi thấy là khi 2 đến 3 người biết các đoạn mã và hợp tác. Điều này làm giảm căng thẳng và sự cô lập giữa các lập trình viên bởi vì họ không tự mình nắm bắt được khi mọi thứ thất bại và các tính năng trễ có thể được chú ý nhiều hơn để đáp ứng thời hạn mà không cần đến sự huấn luyện nhanh chóng của những người khác trong tổ chức.

— Jason K.

@jason - chắc chắn, nên có một vài người trong nhóm thoải mái và có khả năng làm việc với một đoạn mã. Nhưng một người sẽ kết thúc chuyên gia vấn đề chỉ đơn giản là làm việc trên nó nhiều nhất.

— Telastyn

đồng ý rằng điều đó thường xảy ra, là kịch bản có khả năng nhất và chuyên môn về chủ đề là một điều tốt - chỉ có sự bất đồng là điều không thể tránh khỏi đơn giản vì tôi đã thấy thành công tốt hơn với một số người là các doanh nghiệp vừa và nhỏ trong một khu vực bằng cách có sự chồng chéo đáng kể

— Jason K .