Lịch sử Scrum
Kể từ khi Winston Royce công bố báo cáo "Quản lý sự phát triển của các hệ thống phần mềm lớn" vào năm 1970, nhiều người đã cố gắng tìm ra một phương pháp luận có thể loại bỏ những nhược điểm của mô hình phát triển Thác nước. Một giải pháp thay thế cho “thác nước” là phương pháp Scrum, phương pháp này sẽ được thảo luận ngay bây giờ.
Scrum được đặt tên vào năm 1986 từ công trình của Takeuchi và Nonaki Các quy tắc mới để phát triển sản phẩm mới. Tài liệu này lập luận rằng cách hiệu quả nhất để đạt được mục tiêu là cung cấp cho các nhà phát triển một kế hoạch hành động rõ ràng.
Năm 1995, một hướng dẫn khác, "Phát triển phần mềm với Scrum," của Sutherland và Schweiber, xuất hiện. Ấn phẩm này kể từ đó đã được cập nhật nhiều lần. Bây giờ nó được coi là hướng dẫn chính cho sự phát triển của phương pháp này. Phiên bản hiện tại của Hướng dẫn Scrum chứa thông tin được cập nhật vào năm 2020.
Các điều khoản chính của Hướng dẫn Scrum gợi ý rằng mẫu quản lý dự án nên dựa trên thực tế là các nhà phát triển cung cấp sản phẩm hoàn chỉnh trong khung thời gian đã thỏa thuận - chạy nước rút. Để triển khai Scrum thành công, nên sử dụng cấu trúc bao gồm một số yếu tố: vai trò, sự kiện, quy tắc và tạo tác.
Vai trò trong Scrum
Có ba vai trò trong Scrum, tất cả đều tạo thành một nhóm Scrum:
Khách hàng của sản phẩm phần mềm là người quan trọng nhất trong dự án, bởi vì chỉ có anh ta mới hiểu đầy đủ giá trị của nó đối với doanh nghiệp. Khách hàng giải thích nhu cầu của người dùng sản phẩm trong tương lai cho các nhà phát triển, nhưng anh ta không chịu trách nhiệm về phần kỹ thuật của quy trình phát triển. Khách hàng cũng xác định mức độ ưu tiên khi tạo các yếu tố hoặc chức năng nhất định trong sản phẩm.
Các nhà phát triển được giao nhiệm vụ thực hiện các nhiệm vụ kỹ thuật, chức năng chéo phụ thuộc vào phạm vi ứng dụng. Các nhà phát triển đang bận tạo các công việc tồn đọng của sprint, viết mã, điều chỉnh dự án cho phù hợp với mục tiêu chạy nước rút và các nhiệm vụ khác.
Scrum Master là người hỗ trợ nhóm Scrum. Nó cung cấp hỗ trợ cho khách hàng và các nhà phát triển. Nói một cách đơn giản, Scrum Master đang bận giao tiếp giữa những người không tham gia vào dự án và những người viết mã. Đôi khi các nhóm lập trình viên khác nhau trong cùng một công ty lớn giao tiếp và phối hợp tại các cuộc họp chung của các chuyên gia đánh giá của các nhóm này.
Sự kiện trong Scrum
Có 5 loại sự kiện scrum:
Sprint là phần quan trọng nhất của Scrum. Nó bao gồm lập kế hoạch chạy nước rút, đứng lên hàng ngày (đấu tranh hàng ngày), xem xét và hồi tưởng lại quá trình chạy nước rút.
Kế hoạch nước rút. Tất cả các thành viên của nhóm Scrum đều tham gia xây dựng kế hoạch cho Sprint trong tương lai. Tại đây, ý tưởng sản phẩm được trình bày và mỗi thành viên trong nhóm có thể bày tỏ ý kiến của mình, suy nghĩ của mình về điều này. Sau đó, tại cuộc họp, các ưu tiên được xác định và thời hạn được công bố.
Scrum Hằng ngày là một sự kiện scrum ngắn hàng ngày, kéo dài không quá 15 phút. Thông thường, nó được thực hiện để lập kế hoạch cho công việc của bộ mã hóa cho ngày hôm nay hoặc ngày mai. Tại Scrum Hằng ngày, bạn có thể thảo luận về các vấn đề hiện tại. Tất cả các nhà phát triển tham gia vào dự án được yêu cầu tham gia vào một hội thảo như vậy. Sự hiện diện của Scrum Master được cho phép, nhưng không bắt buộc.
Đánh giá Sprint (Demo) - Hiển thị kết quả được tạo trong Sprint. Thông thường sự kiện này diễn ra ở giai đoạn cuối cùng. Tất cả những người quan tâm tham gia vào nó.
Sprint Retrospective - thảo luận về kết quả của Sprint. Các thành viên trong nhóm chia sẻ ý kiến của họ về cách họ đối phó với các nhiệm vụ được giao và cách cải thiện kết quả công việc trong tương lai.
Ngoài ra, việc sàng lọc tồn đọng đôi khi được thực hiện - Backlog Refinement. Nó thảo luận về các mục tồn đọng, chuẩn bị cho lần chạy nước rút tiếp theo và ưu tiên các nhiệm vụ hiện tại.
hiện vật
Tạo tác Scrum là công việc xảy ra khi kết thúc một dự án hoặc chạy nước rút. Có ba thành phần tạo tác - sản phẩm tồn đọng, tồn đọng chạy nước rút và phần gia tăng. Mỗi người trong số họ là cần thiết để cung cấp phần mềm kịp thời cho người dùng. Ngoài ra còn có các hiện vật phụ trợ (ghi các biểu đồ và hơn thế nữa).
Các thành phần có trong các tạo tác chạy nước rút:
Product backlog - giao diện và các tính năng phụ trợ.
Sprint backlog là một danh sách các nhiệm vụ cần được thực hiện trong một lần lặp. Chúng được thống nhất trước khi bắt đầu chạy nước rút.
Gia số - Tổng số hạng mục tồn đọng của phần mềm được tạo trong lần chạy nước rút và giá trị của các gia số đã được thực hiện trước đó. Phần tăng mới đã hoàn thành phải được hiển thị trước khi kết thúc chạy nước rút. Điều này có nghĩa là bạn có một phiên bản làm việc đáp ứng các yêu cầu của nhóm scrum.
Hạng mục tồn đọng của sản phẩm - nó phải được hoàn thành trong vòng lặp chạy nước rút. Theo quy định, phần tử được chia thành nhiều nhiệm vụ nhỏ.
Mục tiêu chạy nước rút là các nhiệm vụ cần được hoàn thành (tạo một hạng mục tồn đọng hoặc nhiệm vụ khác).
Sprint burndown là công việc còn lại trước khi kết thúc Sprint. Biểu đồ ghi giảm là tăng dần hoặc giảm dần. Tất cả phụ thuộc vào những khó khăn mà các thành viên trong nhóm gặp phải khi làm việc. Nó không phải là một chỉ số về sự tiến bộ, mà chỉ là một cách để giải quyết vấn đề và một động lực.
Phát hành sản phẩm/Biểu đồ tiêu hủy sản phẩm là một biểu đồ do Scrum Master vẽ trước khi kết thúc Sprint tiếp theo. Trục hoành là số lần chạy nước rút, trục tung là khối lượng công việc còn lại.
Quy tắc khung Scrum
Các vai trò, sự kiện và tạo tác là cơ sở của Scrum, nhưng ngoài điều này còn có các quy tắc khác. Tất cả đều nâng cao hiệu quả của quá trình làm việc. Dưới đây là danh sách các quy tắc đó:
- Nhóm scrum bao gồm khách hàng phần mềm, chủ scrum và nhà phát triển.
- Tất cả các lần chạy nước rút phải có cùng độ dài.
- Sau khi hoàn thành một lần chạy nước rút, ngay lập tức bắt đầu làm việc trên một lần chạy nước rút mới.
- Sprint luôn bắt đầu với một kế hoạch.
- Các thành viên trong nhóm có một cuộc thảo luận buổi sáng khi bắt đầu ngày làm việc của họ.
- Mỗi lần chạy nước rút được xem xét trong mỗi lần chạy nước rút. Điều này cải thiện giao tiếp giữa nhóm và các bên liên quan.
- Không nên thay đổi công việc tồn đọng của nước rút trong thời gian chạy nước rút.
Hạn chế trong Scrum
Cùng với những ưu điểm rõ ràng, Scrum cũng có những nhược điểm:
- Scrum thường dẫn đến giảm khối lượng công việc thực hiện do thiếu deadline chung.
- Với sự tham gia thấp hoặc không sẵn sàng hợp tác giữa những người tham gia dự án, có rất nhiều khả năng dẫn đến thất bại trong kết quả.
- Cấu trúc Scrum khó sử dụng trong các nhóm lớn, nhưng vẫn có thể thực hiện được. Có các khung mở rộng cho việc này: LeSS, SAFe, Nexus và các khung khác.
- Việc một hay nhiều thành viên rời nhóm giữa chừng không ảnh hưởng nhiều đến dự án.