Mức độ lớn quá lớn đối với XP/SCRUM?

Question

Trong các giai đoạn sớm nhất của việc lập kế hoạch phát triển một hệ thống mới, mô hình phát triển để theo dõi có vẻ là tối quan trọng. Tôi đã luôn luôn giữ niềm tin rằng một thác nước cổ điển (hoặc lai thác/lặp mẫu) là cách tiếp cận tốt nhất cho các dự án trung bình đến lớn. Dường như một khi một dự án có kích thước nhất định, các mô hình Agile/XP/Scrum không thể giải thích các yêu cầu phức tạp, một nhóm lớn, sự phức tạp giữa nhiều hệ thống con, nhu cầu tài liệu, thay đổi nhân sự, v.v. v.v.

Giới hạn của các phương pháp nhanh nhẹn như vậy về quy mô hệ thống, quy mô nhóm, LOC, v.v ...?

Answer 1

Tôi không nghĩ rằng có một ranh giới, sau khi tất cả các ý tưởng của scrum ra khỏi sản xuất xe hơi và đó là khá lớn về mặt người. Điều có dự án lớn là bạn cần bắt đầu với một nhóm nhỏ và phát triển nó theo thời gian. Giữ các nhóm riêng biệt tương tác thông qua Scrum of Scrums và nó sẽ mở rộng quy mô, nếu mọi người sẵn sàng cộng tác thì nó sẽ hoạt động. Nó giống như luôn luôn trong kinh doanh của chúng tôi: phân chia và chinh phục. Phá vỡ vấn đề khó khăn lớn thành các khối nhỏ hơn.

Answer 2

Trong nhóm, các kênh truyền thông tỷ lệ thuận với (N * N-1)/2 là giới hạn trên, vì vậy có thể được xem lỏng lẻo là O (N^2). Bản chất phi tập trung của các nhóm nhanh nhẹn có nghĩa là không có điểm trung tâm tham chiếu và thông tin liên lạc sẽ phát triển gần hơn với giới hạn trên hơn nếu có một điểm tham chiếu như vậy.

Trường hợp bạn có thông số bằng văn bản và cấu trúc chính thức hơn (xem Painless Functional Specification để thảo luận về tài liệu cụ thể), giao tiếp gần với mô hình trung tâm và đã nói gần hơn với các kênh O (N) nhân viên dự án). Hầu hết các bình luận rule-of-thumb tôi đã nhìn thấy đặt điểm ngọt cho các đội Agile 6 hoặc ít hơn và giới hạn trên ở khoảng 10, mặc dù mileage của bạn có thể khác nhau.

Trong bài viết PFS Joel (có, rằng Joel) thảo luận về vai trò của Programme Manager, có vai trò là phát triển và sở hữu đặc điểm kỹ thuật. Loạt thông số chức năng không đau sẽ đi sâu vào vấn đề này một cách chi tiết và cũng khá dễ tiếp cận với quản lý phi kỹ thuật - tôi đã giới thiệu khá nhiều người cho bài viết này.

Answer 3

Hình ảnh Scrum/XP dưới dạng một loạt các thác nhỏ. Ban đầu, bạn muốn thực hiện một nỗ lực trả trước để có được một backlog tốt, được xác định rõ. Không nhất thiết là toàn bộ hệ thống, tôi cho rằng một khi bạn nhận được một hoặc hai lần chạy nước rút trị giá các sản phẩm tồn đọng của sản phẩm, đã đến lúc bắt đầu chạy nước rút. Đồng thời với chạy nước rút, bạn nên tạo thêm PBI (và tái tạo chúng một cách thích hợp).

Ý tưởng là bạn có thể nhận giá trị kinh doanh được phân phối trước khi hệ thống được định nghĩa đầy đủ.

Answer 4

Scrum có thể được chia tỷ lệ bằng cách sử dụng "Scrum of Scrums".

Từ liên minh Scrum đến advice này tiến hành các cuộc họp Scrum Scrums:

Các scrum họp scrums là một kỹ thuật quan trọng trong việc mở rộng quy mô Scrum để nhóm dự án lớn. Các cuộc họp này cho phép các nhóm thảo luận về công việc của họ, tập trung đặc biệt vào các lĩnh vực chồng chéo và hội nhập.

Sách Agile and Iterative Development cũng discuss vấn đề này.

Answer 5

Vảy nhanh nhẹn. Nó không phải là một khoa học tên lửa. Trên thực tế, tất cả là về mô đun.Phát triển phần mềm là một CAS (Hệ thống thích ứng phức tạp) và, như hầu như bất kỳ CAS nào, nó có các mô-đun để quy tắc sự phức tạp tốt hơn. Scrum of Scrums là một trong những cách tiếp cận mô-đun có thể cho quy mô phát triển quy mô. Các bộ phận chức năng (Nhà phát triển, QA, vv) là một phương pháp mô-đun khác. Trường hợp xấu nhất là khi bạn không có mô-đun nào cả trong một dự án lớn.

Tùy thuộc vào tính chất của dự án, nhóm có thể quyết định mô-đun nào sẽ hoạt động cho dự án. Mẫu chung là tạo thành một số nhóm hoạt động trên một số mô-đun gắn kết thấp thấp. Mỗi đội nên khá tự trị, nhưng sự tương tác với các đội khác sẽ tốt.

Ví dụ tương tự từ CAS là cơ thể người. Chúng tôi có các cơ quan như tim và gan. Chúng là các mô-đun riêng biệt (các nhóm tế bào :) tương tác thông qua hệ thần kinh/máu/v.v.

Answer 6

Hãy xem this blog post bởi Bernie Thompson.

Nó phác thảo rất nhiều vấn đề và sự cân bằng mà anh gặp phải khi mở rộng quy mô Scrum/XP tại Microsoft và có một số giải pháp rất chu đáo và thú vị.

Có các bài đăng khác trên cùng một blog cũng giải quyết các vấn đề về quy mô quan tâm đến bạn - IMO nó là một mỏ vàng của những ý tưởng về "nhanh nhẹn cho người lớn".

Answer 7

Scrum scaling hoặc bất kỳ cách tiếp cận nhanh nào phụ thuộc vào môi trường của bạn.

Nếu bạn có nhiều dự án với nhiều nhóm, việc chia tỷ lệ chỉ đơn giản là chia sẻ các phương pháp hay nhất giữa các nhóm. Ngay sau khi bạn bắt đầu yêu cầu tích hợp giữa các hệ thống/dự án, hãy cảnh giác. Tích hợp chặt chẽ giữa các đội là thích hợp hơn tại thời điểm đó.

Nếu bạn có một dự án lớn (tôi đã có một đội ngũ 45 người tại một thời điểm), có các cách tiếp cận khác nhau để mở rộng quy mô. Chúng tôi đã chọn để giữ một đội với nhiều điểm nổi bật - nhà phát triển đứng riêng biệt với BA/QA standup. Người quản lý lặp lại tham dự cả hai và ít nhất một từ mỗi bên đã tham dự khác. Chúng tôi đã có một bức tường thẻ, nhưng nó bao gồm các công cụ trước khi lặp (các câu chuyện trong quá trình phân tích, lỗi sản xuất để theo đuổi) và các công cụ sau khi lặp (công việc phát hành/triển khai).

Tôi cũng là một phần của một dự án rất lớn với nhiều đội scrum (~ 20 đội - một số phân phối - từ 10-20 thành viên mỗi nhóm). Mỗi người đều có các standups riêng biệt, và có một scrum-of-scrums và thậm chí là một scrum-of-scrum-of-scrums. Tôi nghĩ chúng tôi đã nhầm lẫn bằng cách phân đoạn các đội theo khu vực chức năng thay vì quy trình công việc. Phân đoạn của chúng tôi đã tạo ra các bản quyền sở hữu mã với các vấn đề quản lý tích hợp hợp lý giữa các nhóm.

Tóm lại, nó không chỉ là về kích thước để mở rộng quy mô ... mà còn về nội dung của dự án. Vui lòng chia sẻ thêm chi tiết cụ thể về môi trường của bạn để nghe các cách tiếp cận cụ thể hơn để giải quyết quy mô trong môi trường của bạn.