Là quyền sở hữu tập thể bắt buộc trong Scrum?

9

Là một điều tuyệt đối phải tuân theo phương pháp Scrum để thực hành quyền sở hữu mã tập thể , thay vì quyền sở hữu mã yếu ?

scrum code-ownership

— Dimitri C.
nguồn

Tôi phải nói rằng điều đó làm tôi phát điên khi những người khác trong nhóm giả danh của tôi thay đổi mã của tôi ra khỏi nhu cầu không yêu cầu bất kỳ thay đổi nào, chỉ cần hiểu đúng về kiến trúc hoặc API tôi đặt.

— Ando

3

Nếu không có quyền sở hữu tập thể, làm thế nào có thể có sự cam kết của nhóm ? Trong một bộ kỹ năng (giả sử, lập trình Java), bất kỳ ai cũng nên sẵn sàng nhận bất kỳ nhiệm vụ nào .

— merryprankster

13

Quyền sở hữu mã tập thể không phải là một phần không thể thiếu của Scrum .

Tuy nhiên, đây là một phần của Lập trình cực đoan . Lập trình cực đoan & Scrum làm việc rất tốt với nhau.

Yếu tố trung tâm trong Scrum là nhóm. Do đó, rất khuyến khích thực hành quyền sở hữu mã tập thể để chống lại bất kỳ loại chủ nghĩa cá nhân nào .

Scrum hoạt động tốt nhất trong các dự án lớn (> $ 1 triệu) với rất nhiều điều không chắc chắn và với các nhóm lớn (> = 5 dev trên cùng một cơ sở mã). Quyền sở hữu mã yếu có thể rất hiệu quả trong các nhóm nhỏ hơn và các dự án nhỏ hơn như Paul Graham mô tả .

— Christopher
nguồn

"> 1 triệu" cái gì? Nhân viên? Đặc trưng? Dòng mã trong tổng thể sản phẩm? Các dòng mã thuộc sở hữu của một nhóm scrum? Tại sao nó không hoạt động tốt nhất với kích thước mã khiêm tốn hơn (giả sử bạn có nghĩa là kích thước mã)?

— Bryan Oakley

1

1 triệu đô la. Bởi vì nhóm scrum tối ưu là 7 người và sử dụng scrum trong vòng chưa đầy vài tháng không thực sự là một dự án nên sử dụng scrum. 7 nhà phát triển * 6 tháng là một dự án 1 triệu đô la điển hình.

1

$ 1M có vẻ hết sức độc đoán (và ngày - hai năm kể từ bây giờ $ 1M sẽ không mua nhiều như ngày nay, và chắc chắn không nhiều như hai năm trước). Mặc dù, tôi đoán đó là một con số tốt như bất kỳ. Một ngân sách hàng triệu đô la sẽ không trả nhiều hơn một nhóm scrum, vì vậy tôi đoán bạn đang nói SCRUM không hoạt động nếu bạn không đủ khả năng cho ít nhất một nhóm scrum. Điều đó có ý nghĩa. Mặc dù vậy, điều đó không áp dụng cho một startup thực sự nơi mọi người đang làm việc với một ngân sách nhỏ. Tôi nghĩ rằng câu trả lời của bạn sẽ tốt hơn nếu bạn đưa ra ở giới hạn nhân tạo.

— Bryan Oakley

@BryanOakley: không chính xác, tôi đã viết scrum hoạt động tốt hơn khi bạn có số liệu tối ưu . Scrum có thể làm việc trong nhóm nhỏ hơn và với số lần lặp ít hơn, nhưng nó trở nên ít hữu ích hơn trong những trường hợp đó. Tôi thích hoàn toàn không sử dụng khuôn khổ nào trong trường hợp đó, hoặc một scrum "nhẹ", đó là những gì tôi làm trong một trong những công ty của mình, nơi chỉ có 3 nhà phát triển. Về những gì bạn có thể mua với 1 triệu đô la, tôi đã không thấy biến động đó nhiều kể từ 10 năm qua.

10

Về chủ đề sở hữu mã, tôi nghĩ rằng bài đăng này ở đây đặt nó tốt hơn tôi có thể viết:

Tôi không muốn phụ thuộc vào bất cứ điều gì mà không có chủ sở hữu. Tôi thấy lý do này có thể gây phẫn nộ như thế nào. Chuyển trọng tâm từ phần mềm sang wetware là một mánh khóe bẩn thỉu được yêu thích bởi các loại kẻ thua cuộc quản lý trung gian giả định bất lực về mặt kỹ thuật. Đây là nỗ lực của tôi trong việc phân biệt bản thân với ilk của họ: tôi không chỉ muốn phụ thuộc vào công cụ với chủ sở hữu mà còn yêu cầu chủ sở hữu hạnh phúc ở đó. Trái ngược với một giả định quản lý chung (một trong những điều hiếm khi giữ nhưng giữ cho các nhà quản lý lành mạnh), tôi không tin vào việc giao quyền cưỡng chế. Nếu chủ sở hữu không thích mô-đun, mong đợi một số công việc làm vườn khá tệ hại.

/ tín đồ sở hữu mã yếu.

— Denis de Bernardy
nguồn

4

Tôi không nghĩ quyền sở hữu mã tập thể là hoàn toàn cần thiết cho scrum, tuy nhiên, quyền sở hữu mã càng ít thì càng linh hoạt trong phân công nhiệm vụ. Điều này đặc biệt đúng khi có nhiều nhóm scrum. Quyền sở hữu mã ít hơn cũng loại bỏ các nút thắt có thể phát triển khi một chủ sở hữu mã làm việc quá sức.

Quyền sở hữu mã không mang lại sự liên tục cho sự phát triển và tùy thuộc vào bộ kỹ năng của các thành viên trong nhóm, có thể không thể loại bỏ hoàn toàn.

— Blake
nguồn