Thực hành Scrum Framework với ứng dụng GitLab

Bài viết này minh họa cách thực hành Scrum Framework với ứng dụng GitLab, nhờ đó, người làm phần mềm sẽ không cần thiết phải sử dụng thêm quá nhiều công cụ để gây thêm rắc rối trong công việc của mình. GitLab hoàn toàn miễn phí và nếu trả thêm một ít phí, bạn sẽ có nhiều tính năng tuyệt vời như Point Estimate, Epic, Burndown Chart và Product Roadmap.

Scrum là gì? Framework được giới lập phát triển phần mềm ưa chuộc vì tính thực hành rõ ràng đồng thời đảm bảo các trụ cột thẩm tra, minh bạch, thích nghi. Sprint Backlog là một xương sống quan trọn trong một chu trình Scrum, nơi toàn bộ Development Team đeo bám công việc nhằm tạo ra sản phẩm chất lượng khi kết thúc Sprint.

Bạn có thể tìm hiểu theêm các khái niệm của Scrum ở đây:

GitLab là một nền tảng DevOps hoàn thiện, ứng dụng trong việc lên kế hoạch dự án và quản lý mã nguồn và CI/CD. Những công cụ như GitLab trở thành phần không thể thiếu trong giới phát triển phần mềm.

Định nghĩa Sprint bằng Milestone của GitLab

Định nghĩa Sprint bằng Milestone của GitLab
Định nghĩa Sprint bằng Milestone của GitLab

Tuy trong GitLab không có định nghĩa Sprint, nhưng bạn hoàn toàn có thể ứng dụng Milestone trong việc định nghĩa Sprint.

Một Milestone sẽ được định nghĩa thành 1 Sprint nếu tuân thủ các nguyên tắc sau:

  • Ngày bắt đầu và kết thúc Milestone cũng chính là ngày bắt đầu và kết thúc của 1 Sprint. Đây phải là các ngày cố định của tuần. Bất chấp trong Sprint có bao nhiêu ngày nghỉ. Ví dụ nếu bạn quy định Sprint 1 tuần với ngày bắt đầu là thứ 2 và kết thúc là thứ 6, vậy bạn sẽ tạo một loạt Milestone nối tiếp có ngày bắt đầu và kết thúc vào thứ 2 và thứ 6. Ngay cả thứ 6 rơi vào ngày nghỉ 01/05 thì đây vẫn coi là ngày kết thúc Sprint. Bám sát điều này giúp bạn tạo ra nhịp. Giữ vững nhịp Sprint đều đặn giống như bước chạy đều của vận động viên Marathon, sẽ giữ sức đi quãng đường rất xa.
  • Tên Milestone cũng chính là tên Sprint, hãy chọn 1 cái tên đáng nhớ và phản ánh mục tiêu của mỗi Sprint.
  • Description của Milestone sẽ giải thích chi tiết hơn các mục tiêu mà bạn định nhắm tới trong Sprint.

Tổ chức Board để monitor công việc trong Sprint

Tổ chức Board để monitor công việc trong Sprint
Tổ chức Board để monitor công việc trong Sprint

Trong GitLab có sẵn phần Board để bạn có thể monitor công việc trong Sprint. Đối tượng được quản lý trên Board là các Issue, tương đương với User Story trong Scrum.

Vào Issue > Board, đã có sẵn 2 cột là Open và Closed. Các Issue mới hình thành sẽ được đưa vào Open, các Issue đã hoàn thành và được Product Owner nghiệm thu thì sẽ được Closed.

Có thể add stage trung gian giữa Open và Closed để phản ánh quy trình phát triển của team. Cá nhân tôi ưa chuộng các cột trung gian sau:

  • To do: khi các Issue được làm rõ ràng để phát triển, team sẽ kéo từ cột Open sang cột To do, các Issue chưa làm rõ sẽ được giữ ở Open để làm rõ ràng dần.
  • Doing: khi Developer làm đến Issue nào sẽ kéo từ To do sang Doing
  • Delivery Ready: Khi Developer làm xong, sẽ kéo Issue từ cột Doing sang Delivery Ready.
  • Delivery Done: Developer chuyên deloy sẽ thực hiện triển khai Issue này lên môi trường Live, khi thực hiện xong sẽ kéo sang Delivery Done.

Xác định ưu tiên trong Sprint bằng Label của GitLab

Để đánh giá mức độ ưu tiên của các Issue, Label trong GitLab được sử dụng. Bạn có thể tự đặt tên các Label của mình như Must Have, Should Have, Could Have.

Chu trình Scrum trên GitLab

Lập kế hoạch Sprint (Sprint Planning)

Lập kế hoạch Sprint (Sprint Planning)
Lập kế hoạch Sprint (Sprint Planning)

Để chuẩn bị cho buổi lập kế hoạch, Product Owner cần chuẩn bị trước các Issue cần làm trên cột Open, gắn nhãn ưu tiên và sắp xếp theo mức độ ưu tiên.

Trong buổi lập kế hoạch Sprint,  Development Team  theo thứ tự thấy Issue nào rõ ràng, khả thi sẽ kéo sang cột To Do. Nếu chưa rõ cần trao đổi thêm với Product Owner để làm rõ ràng hơn trước khi quyết định đưa vào To Do.

Development Team quyết định đưa vào Sprint bằng cách gắn Milestone tương ứng cho Issue.

Development Team tiến hành Estimate từng Issue trong cột To Do bằng cách comment vào mỗi Issue bằng lệnh /estimate.

Trong Sprint

Sprint trên GitLab
Sprint trên GitLab

Trong Sprint, team tương tác trên Board của mình bằng cách lọc Lấy các Issue cần làm bằng cách dùng Milestone Filter.

Deloper nào thực hiện việc gì sẽ Assign vào Issue đó, và tự kéo sang các cột tương ứng như Doing.

Chú ý Monitor, quan sát quá trình hoạt động của team, nếu đến gần hết Sprint mà cột To do vẫn còn đọng rất nhiều Issue thì khả năng trễ hẹn rất cao.

Sơ kết Sprint (Sprint Review)

Sơ kết Sprint (Sprint Review)
Sơ kết Sprint (Sprint Review)

Trong buổi sơ kết Sprint, Product Owner sẽ nghiệm thu (Acceptance) các Issue đang nằm trên cột Delivery Done. Nếu thực sự hoàn thành đúng yêu cầu, nó sẽ được kéo sang cột Closed.

Mọi Issue chưa hoàn thành cần bỏ hoặc chuyển về Milestone khác tức Sprint khác để làm.



Hãy đăng ký nhận tin để là người đầu tiên đọc bài viết mới nhất từ chúng tôi nhé

Posted 
Apr 29, 2020
 in 
Agile & Culture
 category

Bài viết khác từ

Agile & Culture

category

View All