Thiết Kế Website

Thiết kế website tại BizMaC, chúng tôi cam kếtmang đến cho Quý khách sự an tâm tuyệt đốivà hài lòng cao nhất

Thiết Kế Website
Tên Miền & SSL

Đăng ký tên miền ngay từ bây giờ để bảo vệ thương hiệu của bạn. Tên miền kích hoạt ngay an toàn và bảo mật

Tên Miền & SSL
Hosting

Cloud Hosting chất lượng cao.
Nơi lý tưởng cho website của bạn, nhanh, ổn định, nhiều sự lựa chọn

Hosting
Email

Hệ thống Email Server chuyên nghiệp, dung lượng lớn, tốc độ cao giúp doanh nghiệp an tâm giao dịch với khách hàng

Email
VPS Cloud

VPS Cloud với quyền truy cập root, bộ lưu trữ SSD/NVMe, Plesk License và có thể mở rộng với mọi phiên bản

VPS Cloud
Servers

Máy chủ riêng (Dedicated Servers), thanh toán theo tháng.
Data Center Tier 3 - Viettel, VDC
Network 1Gbps - Bandwith Unlimited

Servers

Thực Hành Scrum Với GitLab

12/08/20211,462
Làm thế nào để ứng dụng Scrum với Gitlab?

Scrum là gì? Framework được giới lập phát triển phần mềm ưa chuộng 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.

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

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

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à Close để 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 deploy 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

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)

Để 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 Sprinta

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.

Developer 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)

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.

Bài viết khác
We’re here 24 / 7