4. Ba công cụ

a) Product backlog

Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).

b) Sprint backlog

Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

c) Burndown Chart

Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart). Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó

Nguyên lý hoạt động của scrum

Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.

Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống. Các tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra.

Cách thức cài đặt để sử dụng scrum

Bước 1: Thu nhập các đặc điểm của sản phẩm (backlog) trong đơn đặt hàng. Đây là bước quan trọng nhất. Lập nên các đội làm việc, có thể tách thành các đội nếu cần thiết và thảo luận với nhau về nghiệp vụ cần làm. Sau đó bổ nhiệm một người vào vị trí Product owner, người này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp ưu tiên đúng thứ tự các nhiệm vụ. Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ưu tiên.

Bước 2: Ước lượng đầy các yêu cầu về sản phẩm đầu ra. Có ước lượng ở mức độ cao, chia sản phẩm thành số lượng các danh mục backlog. Tuy nhiên số lượng sẽ không chính xác được, về sau chúng sẽ được bổ sung. Tiếp đến là ước lượng chi tiết từng backlog, ước lượng số lượng các đội làm việc.

Bước 3: Lên kế hoạch phát triển các vòng lặp sprint. Sử dụng các cuộc trao đổi kế hoạch phát triển sprint với tất cả các thành viên. Xác định khoảng thời gian sẽ phát triển một sprint (thường là 30 ngày), mục tiêu của sprint là gì, sẽ đạt được gì, phân tích các yêu cầu của sprint một cách rõ ràng.

Bước 4: Lên kế hoạch phát triển các nhiệm vụ của sprint. Tất cả mọi người sẽ xác định ngân sách của sprint đó, chia các đặc điểm thành các tác vụ nhỏ hơn, ước lượng số thời gian sẽ làm từng task (giờ), hoàn tất các yêu cầu và nhận dạng task quan trọng.

Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người. Thường sử dụng bảng trắng để vẽ nên những vấn đề cần thiết cho tất cả mọi người cùng đánh giá.

Bước 6: Các thành viên bắt tay xây dựng từng sprint. Lập trình, kiểm thử và điều chỉnh thời gian để có hiệu quả tốt nhất. Đôi khi có thể hủy bỏ một sprint và quay lại với việc lập kế hoạch khác.

Bước 7: Mọi người báo cáo kết quả để tiếp tục làm việc. Các báo cáo tập trung vào các vấn đề: đạt được những gì so với lần trao đổi trước; sẽ hoàn thành những gì trong lần trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc v.v.

Bước 8: Tổng hợp kết quả trên biểu đồ. Đây là bức tranh tổng quát về những việc đã làm được, những việc chưa làm được, thời gian ước lượng còn lại và có thể điều chỉnh lại.

Bước 9: Xem xét để hoàn tất. Khi các thành viên nói công việc đã hoàn thành có nghĩa là mọi thay đổi sẽ bị từ chối, đẩy lại cho vòng lặp sau.

Bước 10: Đánh giá, phản ánh và lặp lại. Có các cuộc họp đánh giá lại sprint của các thành viên. Sẽ trình bày những gì đạt được, phản hồi của khách hàng, xét thời hạn của sprint. Nhìn lại biểu đồ ở bước 8 để xác định lại toàn bộ hệ thống và tiếp nhận những đóng góp, bổ sung để đưa tiếp vào các vòng lặp sprint tiếp theo.

Định nghĩa Done

Khi một hạng mục Product Backlog hoặc một Gói tăng trưởng cho là “Done”, mọi người phải hiểu rõ “Done” như thế nghĩa là thế nào.

Mặc dù việc xác định rõ định nghĩa này hoàn toàn phụ thuộc vào từng Nhóm Scrum, nhưng mọi thành viên phải chia sẻ chung một cách hiểu về việc hoàn thành một công việc, để đảm bảo tính minh bạch và thông suốt. Đây chính là “Định nghĩa Hoàn thành” (Definition of Done) cho Nhóm Scrum; nó được dùng để đánh giá khi nào công việc thực sự hoàn thành trên mỗi gói tăng trưởng của sản phẩm.

Định nghĩa giống nhau sẽ chỉ dẫn cho Nhóm Phát triển nắm được số lượng hạng mục Product Backlog có thể được lựa chọn cho một Sprint. Mục đích của mỗi Sprint là để chuyển giao Gói tăng trưởng của các chức năng có tiềm năng chuyển giao được tuân thủ “Định nghĩa Done của Nhóm Scrum."

Mỗi Sprint, Nhóm Phát triển chuyển giao một Gói tăng trưởng. Phần tăng trưởng này phải là khả dụng, để Product Owner có thể lựa chọn và phát hành ngay lập tức. Mỗi gói tăng trưởng được cộng dồn vào các gói tăng trưởng trước đó và được kiểm thử toàn bộ để đảm bảo chúng làm việc tốt với nhau. Khi Nhóm Scrum ngày càng trưởng thành thì “Định nghĩa Hoàn thành” càng được mở rộng với các chỉ tiêu khắt khe hơn để đạt chất lượng cao hơn.

Ứng dụng thực tế

Scrum đã được sử dụng cho:

• Phần mềm Thương mại

• Các dự án mà giá đã được chốt

• Các ứng dụng Tài chính

• Các ứng dụng tuân thủ chuẩn ISO 9001

• Các hệ thống Nhúng

• Các hệ thống hoạt động 24x7 với yêu cầu 99.999% thời gian hoạt động.

• Phát triển Video game

• Phần mềm Điều khiển-Vệ tinh

• Phần mềm cho thiết bị cầm tay

• Điện thoại di động

• Các ứng dụng chuyển mạng

• Các ứng dụng ISV

• Các chiến dịch Marketing

So sánh scrum và các quy trình phần mềm truyền thống

-Ưu điểm:

Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế.

Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt theo môi trường sử dụng thực tế. Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu.

Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao.

Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá lại ở những vòng lặp phát triển.

Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất nhanh. Và khi đi sai hướng, có thể hủy ngay sprint đó để quay lại với bản kế hoạch.

-Nhược điểm

Quy mô đội ngũ: Trung bình giới hạn từ 7 đến 10 người, quy mô đội ngũ có thể là một trở ngại nếu nó vượt quá số lượng đề xuất này. Việc tổ chức các cuộc họp sẽ không khả thi và nền tảng của phương pháp này trở nền suy yếu.

Số lượng yêu cầu nhiều: Số yêu cầu có thể đến từ nhiều kênh của dự án và đôi khi có thể khó quản lý vì các khía cạnh khác nhau của chúng. Ở mức độ nhận giao hàng, những mâu thuẫn này có thể làm chậm quá trình xác nhận

Chất lượng phát triển: Số lượng đội ngũ càng tăng, chất lượng càng khó kiểm soát. Điều này hoàn toàn đúng khi dự án được triển khai tại nhiều chi nhánh. Các rủi ro đặc biệt liên quan đến chất lượng code và số lượng khiếm khuyết được xác định tại thời điểm tích hợp.

**Link references: **

https://viblo.asia/p/tong-quan-ve-scrum-phan-1-3P0lPqEm5ox https://hocvienagile.com/agipedia/tong-quan-ve-scrum https://ngotuongdan.wordpress.com/2017/02/03/mo-hinh-scrum-post-lai/ https://vi.wikipedia.org/wiki/Scrum_(mô_hình_phát_triển_phần_mềm) https://www.saga.vn/so-sanh-2-phuong-phap-quan-ly-du-an-agile-vs-waterfall~42810