Những loại dự án nào được SCRUM coi là phù hợp?

Tôi đã sử dụng SCRUM trong ba dự án khác nhau trong bốn năm qua. Một trong những lợi thế của SCRUM dường như là tính linh hoạt và khả năng thích ứng của nó, ví dụ như thay đổi yêu cầu của khách hàng. Một lợi thế khác là quản lý có thể dễ dàng theo dõi tiến độ của một dự án.

Tính linh hoạt của SCRUM có thể là một lợi thế, ví dụ như khi triển khai một ứng dụng web, trong đó các yêu cầu thay đổi rất nhanh và khách hàng thực sự hiểu những gì họ muốn sau khi họ nhìn thấy một nguyên mẫu.

Mặt khác, có các loại dự án phần mềm khác (ví dụ như trong ngành hàng không vũ trụ) trong đó các yêu cầu khá cố định: bạn nhận được một tài liệu đặc tả yêu cầu và bạn phải quay lại sáu tháng sau với phần mềm làm việc và tài liệu hoàn chỉnh. Đối với các loại dự án này, tôi nghi ngờ rằng tính linh hoạt được cung cấp bởi SCRUM là cần thiết (theo nghĩa là bạn không cần xây dựng các nguyên mẫu và đưa chúng cho khách hàng để nhận phản hồi về các yêu cầu): bạn cần một cách tiếp cận có cấu trúc và có hệ thống , có lẽ được lặp đi lặp lại nhiều lần cho mỗi dự án với rất ít chỗ cho sự bất ngờ.

Vì vậy, SCRUM được xem xét bởi những người đề xuất một phương pháp phát triển phần mềm có mục đích chung hay nó được coi là đặc biệt phù hợp cho một số loại dự án hoặc lĩnh vực ứng dụng nhất định?

Ví dụ, gần đây tôi đã xem trang web của một công ty sản xuất phần mềm cho ngành hàng không vũ trụ và nhận thấy rằng họ đang sử dụng mô hình V. Một người đề xuất SCRUM sẽ nói rằng SCRUM không phù hợp với loại dự án này hay đúng hơn là đề nghị công ty này nên thử chuyển sang SCRUM?

Lưu ý rằng tôi không hỏi ý kiến ​​của độc giả của diễn đàn này, nhưng tôi muốn biết ý kiến ​​được thiết lập giữa những người đề xuất SCRUM là gì: SCRUM được coi là mục đích chung hay chỉ phù hợp cho một số loại dự án nhất định? Trong các trường hợp sau, cho các loại dự án?

SCRUM là một phương pháp mục đích chung có thể hoạt động tốt cho hầu hết các dự án và quy mô nhóm, nhưng ít hữu ích hơn cho các nhóm lớn thực hiện các dự án rất lớn. Số lượng người tham gia vào một số dự án khiến cho bất kỳ phương pháp nhanh nhẹn nào cũng trở nên khó gần như không thể bởi vì một cấu trúc cứng nhắc hơn được yêu cầu để giữ trật tự. Ngành hàng không vũ trụ là một ví dụ điển hình về ngành công nghiệp có xu hướng có các dự án lớn, nơi các phương pháp nhanh nhẹn không phải lúc nào cũng khả thi.

Bất kỳ loại dự án! Nó hoạt động tốt cho cả các dự án lớn và nhỏ.

Mọi người đã sử dụng nó để lập kế hoạch cho đám cưới, chuyển nhà, vv Vì vậy, thậm chí không chỉ các dự án phần mềm.

Tôi là một người tin tưởng vững chắc rằng có nhiều hoạt động kinh doanh có thể được hưởng lợi từ cách tiếp cận giống như Scrum.

Xin lưu ý rằng Scrum không phải là một phương pháp, mà là một khung.

Scrum sẽ hoạt động tốt nhất trong một nhóm đa chức năng từ 5 đến 9 nhà phát triển làm việc trong một dự án có quy mô vừa và lớn (từ 4 tháng đến nhiều năm). Nếu dự án của bạn lớn hơn, bạn có thể mở rộng quy mô với Scrum of Scrums .

Tôi sẽ không thảo luận về điều đa chức năng ở đây, nhưng đây là những gì Hướng dẫn Scrum chính thức nói cho quy mô nhóm:

Kích thước nhóm phát triển tối ưu đủ nhỏ để duy trì sự nhanh nhẹn và đủ lớn để hoàn thành công việc quan trọng. Ít hơn ba thành viên Nhóm phát triển làm giảm sự tương tác và dẫn đến tăng năng suất nhỏ hơn. Các nhóm phát triển nhỏ hơn có thể gặp phải các hạn chế về kỹ năng trong Sprint, khiến Nhóm phát triển không thể cung cấp Phần tăng có thể tin cậy được. Có hơn chín thành viên đòi hỏi quá nhiều sự phối hợp. Các nhóm phát triển lớn tạo ra quá nhiều phức tạp cho một quy trình thực nghiệm để quản lý. Vai trò của Chủ sở hữu sản phẩm và Scrum Master không được bao gồm trong số này trừ khi họ cũng đang thực hiện công việc của Sprint Backlog

Một lần chạy nước rút là khoảng một tháng.

Nước rút được giới hạn trong một tháng theo lịch. Khi đường chân trời của Sprint quá dài, định nghĩa về những gì đang được xây dựng có thể thay đổi, độ phức tạp có thể tăng lên và rủi ro có thể tăng lên. Nước rút cho phép dự đoán bằng cách đảm bảo kiểm tra và điều chỉnh tiến trình hướng tới mục tiêu ít nhất mỗi tháng theo lịch. Nước rút cũng hạn chế rủi ro trong một tháng theo lịch.

Tôi nghĩ việc sử dụng một khung dựa trên quy trình lặp với các dự án nhỏ hơn 4 tháng là vô nghĩa. 4 tháng = 4 lần chạy nước rút. Bạn cũng phải xem xét rằng bạn có được vận tốc chính xác hơn sau 3 lần chạy nước rút.

Điều đó nói rằng, cá nhân tôi sử dụng một phiên bản giới hạn của Scrum cho các dự án nhỏ hơn. Nhưng bạn thực sự không thể gọi nó là Scrum. Trong trường hợp cụ thể đó, bạn đang sử dụng một số nguyên tắc cốt lõi của Scrum trong việc triển khai khung công tác của riêng bạn.

để bắt đầu, hãy nghĩ về SCRUM chỉ là một bộ hướng dẫn để thực hiện các thực hành nhanh. Đừng bao giờ nghĩ về nó như một "cuốn sách thần thánh" về cách thực hiện các dự án. Đối với nhiều dự án đòi hỏi một luồng công việc ổn định, chẳng hạn, Kanbam thích hợp hơn.

Các dự án Agile có xu hướng rơi xuống nơi bạn đang thực hiện các dự án yêu cầu ngày kết thúc cố định hoặc chi phí cố định. Mặc dù bạn vẫn có thể thực hiện các dự án này bằng phương pháp Agile, nhưng cần lập kế hoạch trước mọi thứ để xác định xem bạn có khả năng bắn trúng mục tiêu không phải là cách nhanh nhẹn thông thường - nhanh nhẹn, bạn có xu hướng tiếp tục làm việc cho đến khi hết công việc để làm hoặc hết thời gian để thực hiện. Đối với hầu hết các dự án, điều này vẫn ổn vì các yêu cầu thay đổi trong suốt dự án.