Quy trình xây dựng hệ thống phần mềm E-learning: Đã có lời giải? (phần 2)

Như đã nói ở phần 1, Scrum là một khung làm việc (framework) nên được áp dụng vào quy trình xây dựng hệ thống phần mềm E-learning để quản lý và kiểm soát tiến độ một cách tối ưu nhất. Ở phần 2 này, tôi sẽ giới thiệu cho các bạn 4 buổi họp quan trọng cấu tạo nên Scrum và những gì bạn cần làm để công việc đạt hiệu quả cao.

1. Daily Standup Meeting

Về thời lượng, Daily Standup Meeting là một cuộc họp ngắn diễn ra hằng ngày, kéo dài tối đa 15 phút và thường được tổ chức ở cùng một địa điểm và thời gian. Standup Meeting thường diễn ra vào buổi sáng, phải rõ ràng, ngắn gọn và dễ hiểu để tất cả các thành viên trong dự án E-learning đều có thể nắm bắt được công việc. Trước mỗi buổi Daily Standup Meeting, các thành viên nên chuẩn bị để trả lời 3 câu hỏi sau:

• Bạn đã làm gì?
• Bạn sẽ làm gì hôm nay?
• Bạn đang gặp khó khăn gì?

Về thành phần tham gia, tất cả thành viên của team đều phải tham gia vào cuộc họp này, mỗi người phải cập nhật tiến độ công việc của bản thân, đầu việc họ dự định hoàn thành trong hôm nay và những khó khăn đang gặp phải.

Có thể thấy Daily Standup Meeting là vô cùng cần thiết, bởi cuộc họp này khiến cho mọi thành viên trong nhóm hình thành thói quen giao tiếp một cách đều đặn, đồng thời dễ dàng tìm ra những khó khăn mà mỗi người gặp phải. Từ đó, quy trình xây dựng hệ thống phần mềm E-learning phần nào cũng dễ quản lý và theo sát hơn.

2. Sprint planning

Sprint planning là gì?

Sprint planning thường diễn ra vào đầu các sprint để lập ra kế hoạch các đầu việc cần làm cho sprint sắp tới. Bạn có thể chia Sprint Planning thành 2 phần tương đương với 2 câu hỏi lớn “Sprint tới sẽ làm gì?” và “Làm như thế nào?”

Về thành phần tham gia, tương tự như Daily Standup Meeting, toàn bộ thành viên đội sản xuất và Sprint Master đều phải tham gia vào Sprint Planning, còn Product Owner chỉ cần tham gia những buổi họp để cùng team định hướng sẽ làm gì, còn phần làm thế nào thì đối tượng này không nhất thiết phải tham gia.

Về thời lượng, điều này phụ thuộc vào tính chất của mỗi sprint. Chẳng hạn với những sprint quan trọng kéo dài 2 tuần, Sprint planning sẽ dễ ra trong khoảng 4 tiếng.

Làm thế nào để Sprint planning đạt hiệu quả?

Có thể thấy Sprint được chia thành 2 phần:

“Sẽ làm gì?”
Cả team cần vạch ra mục tiêu của Sprint sắp tới, bạn có thể áp dụng chiến lược SMART. Để tìm ra được mục tiêu, trước hết Product Owner sẽ trình bày về Product Backlog (chứa những tính năng mong muốn của sản phẩm) và các task của sprint này. Team phát triển sản phẩm sẽ chọn ra những đầu mục cần hoàn thiện trong sprint dựa vào kinh nghiệm làm việc trong quá khứ để ước lượng.

“Làm như thế nào?”
Ở phần này, các thành viên sẽ cùng xây dựng Sprint Backlog - bảng công việc bao gồm danh sách các hạng mục được phát triển trong sprint và các công việc cần làm tương ứng với từng hạng mục. Để xây dựng được Sprint Backlog, cả team sẽ cùng lên danh sách công việc cụ thể sau khi phân tích các đầu mục của Product Backlog. Bản Sprint Backlog cần được duyệt bởi Product Owner trước khi được sử dụng để đi vào sản xuất.

Lưu ý: Bạn cần phân chia khối lượng công việc cụ thể phù hợp thời gian cần hoàn thành chứ không chỉ nên chia đều theo các đầu mục.

3. Sprint demo (hay Sprint review)

Về thời gian, Sprint demo được tổ chức ở cuối mỗi sprint nhằm mục đích review, nhìn lại những gì mà team đã làm được trong sprint vừa rồi. Sprint demo diễn ra như một buổi trò chuyện, không trình chiếu slide show như các buổi họp khác. Thời lượng của buổi trò chuyện này cũng tùy thuộc vào từng sprint, thông thường là 4 tiếng với các sprint kéo dài khoảng 1 tháng.

Về thành phần tham gia, cả 3 đối tượng trong Scrum bao gồm Product Owner, Scrum master và Developer team đều phải tham gia buổi họp này. Ngoài ra, Sprint Demo cũng có thể có sự tham gia từ phía khách hàng hay đại diện của các dự án khác.

Giống như cái tên của mình, Sprint demo được coi như một buổi thử nghiệm, kiểm tra các chức năng được hoàn thiện trong sprint vừa rồi của hệ thống phần mềm E-learning. Trong quá trình thử nghiệm, sản phẩm sẽ được đánh giá dựa trên các mục tiêu và các task được thiết lập từ Sprint planning.

Lưu ý: Những danh mục Product Backlog chưa kịp hoàn thành sẽ được bỏ qua và được đề xuất để đưa vào sprint kế tiếp.

4. Sprint retrospective

Về thời gian, Sprint retrospective diễn ra vào cuối mỗi sprint và sau Sprint Demo. Cuộc họp này thường kéo dài tối đa 3 tiếng nhằm mục đích nhìn lại toàn bộ sprint và tìm cách cải tiến công việc.

Về thành phần tham gia, Sprint retrospective chào đón sự có mặt của toàn bộ team, bao gồm cả Product Owner và Sprint Master. Ở Sprint retrospective, cả team sẽ cần trả lời 3 câu hỏi:

• Cái gì đã hoạt động tốt trong sprint vừa qua?
• Cái gì đã không hoạt động tốt trong sprint vừa qua?
• Cái gì có thể cải tiến trong sprint kế tiếp và nên cải tiến thế nào?

Kết thúc buổi họp, cả nhóm sẽ chốt ra được những điểm mạnh cần được duy trì, phát triển trong những sprint sau và những giải pháp khắc phục để không lặp lại vấn đề này trong sprint tới.

"Last but not least", dù diễn ra cuối cùng trong số 4 buổi họp cấu trúc nên một sprint trong Scrum nhưng Sprint retrospective đóng vai trò vô cùng quan trọng, giúp cả team có cái nhìn tổng thể trong mỗi giai đoạn đồng thời đem lại những đề xuất để tối đa hiệu quả công việc.

Để được tư vấn và hỗ trợ thêm trong quá trình xây dựng hệ thống phần mềm E-learning, hãy liên hệ ngay với OES - Công ty đào tạo trực tuyến hàng đầu tại Việt Nam!

Xem thêm: Quy trình xây dựng hệ thống phần mềm E-learning: Đã có lời giải (phần 1)