Trong bài viết này, mình sẽ giới thiệu tiếp đến các bạn Scrum trong Agile. Scrum cơ bản là bộ khung làm việc (framework) hay có thể hiểu nôm na là cách thức làm việc để trở nên “linh hoạt” trong phát triển phần mềm. Tới đây thì mình mặc định các bạn đã hiểu sơ qua về Agile cũng như “Tuyên ngôn Agile” và “12 nguyên tắc trong Agile”. Lí do là vì việc hiểu rõ những giá trị cốt lõi trong Agile giúp các bạn hiểu về Scrum tốt hơn.
Hình. Tóm tắt Scrum
Đó là tóm tắt về Scrum. Giờ chúng ta sẽ đi vào chi tiết thêm một tí về Scrum.
Vai trò trong Scrum
Trong Scrum có 3 vai trò: Chủ sản phẩm (Product Owner), Nhóm phát triển, và Scrum Master. Trong Scrum bạn sẽ không có vai trò Quản lý dự án (Project manager) hay Trưởng nhóm kỹ thuật (Technical lead)
- Chủ sản phẩm: Là người chịu trách nhiệm cao nhất đối với sản phẩm và nhóm phát triển. Chủ sản phẩm có trách nhiệm làm việc với chủ đầu tư để hiểu yêu cầu về sản phẩm, quản lý những yêu cầu đó, tạo ra những “câu chuyện người dùng” đối với sản phẩm và truyền đạt những thông tin đó đến đội phát triển. Cơ bản là nếu nhóm gặp những vấn đề hay thắc mắc gì liên quan đến sản phẩm, hãy tìm gặp Chủ sản phẩm.
- Nhóm phát triển: Là một tập hợp những kỹ sư “liên chức năng”- nghĩa là công việc của họ không cố định ở lập trình, kiểm thử, phân tích hay thiết kế. Tùy theo yêu cầu công việc mà họ sẽ đảm nhận những vai trò tương ứng. Nhóm phát triển được quyền chủ động tổ chức công việc, ước lượng khối lượng công việc và cam kết hoàn thành công việc đã cam kết. Trong Sprint, nhóm phát triển có tiếng nói lớn nhất và những bộ phận khác có nhiệm vụ hỗ trợ những điều kiện tốt nhất để nhóm làm việc hiệu quả
- Scrum Master: Nhiệm vụ của Scrum Master là giúp mọi người trong nhóm hiểu được Scrum, làm theo Scrum đồng thời hỗ trợ nhóm phát triển để họ có thể toàn tâm toàn ý làm việc. Vừa giống ông chủ vừa giống osin, kiểu vậy. Nếu có ai đó thắc mắc về quy trình trong Scrum, ý nghĩa của Scrum hay những vấn đề liên quan đến Scrum khác, hãy tìm gặp Scrum Master.
Hình. Vai trò trong Scrum
Các sự kiện trong Scrum:
- Sprint: Như đã giới thiệu ở trên, Sprint là những chu kỳ nhỏ để phát triển sản phẩm. Trong Sprint, nhóm sẽ tập trung phát triển những chức năng cụ thể nào đó và hoàn hiện nó vào cuối mỗi Sprint. Mỗi Sprint sẽ có thời gian cố định được thống nhất, thường là 2 tuần và thường không hơn 4 tuần.
- Họp kế hoạch Sprint (Sprint Planning Meeting): Diễn ra vào đầu mỗi Sprint bao gồm Chủ sản phẩm, Scrum Master và Nhóm phát triển. Chủ sản phẩm sẽ trình bày mục tiêu của Sprint (Sprint goal) và những đầu mục công việc có độ ưu tiên cao trong danh sách các đầu mục công việc (được gọi là Product Backlog) sau đó đội phát triển sẽ thảo luận (đặt câu hỏi, ước lượng độ lớn, định ra những công việc cần phải làm v.v). Những đầu mục công việc mà nhóm thống nhất sẽ làm trong Sprint sẽ được chuyển qua một danh sách công việc khác gọi là Sprint Backlog. Cơ bản, sau buổi họp kế hoạch Sprint, ta sẽ biết được Mục tiêu của Sprint và những việc đầu mục cần làm trong Sprint.
- Họp Scrum hằng ngày (Daily Scrum Meeting): Sau họp kế hoạch Sprint, nhóm sẽ bắt tay vào công việc phát triển và nhóm sẽ có cuộc họp ngắn vào mỗi đầu ngày. Buổi họp này thường diễn ra ngắn khoảng 15 phút và cố định về thời gian, địa điểm họp. Trong cuộc họp này, từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi sau:
- Hôm qua đã làm gì?
- Hôm nay sẽ làm gì?
- Có khó khăn trở ngại gì không?
Scrum Master là người chịu trách nhiệm giải quyết hoặc tìm giải pháp cho những khó khăn, trở ngại mà nhóm gặp phải và đảm bảo là nó được giải quyết sớm nhất có thể để nhóm có thể hoàn thành công việc.
- Họp sơ kết Sprint (Sprint Review Meeting): Vào cuối mỗi Sprint, nhóm sẽ trình bày những phần mình đã làm được trong Sprint hay còn gọi là demo trên sản phẩm thật. Thành phần tham dự là tất cả những ai quan tâm đến sản phẩm. Cuộc họp sẽ giúp đánh giá xem nhóm có đạt được mục tiêu đề ra ở buổi họp kế hoạch Sprint hay không.
- Họp cải tiến Sprint (Sprint Retrospective Meeting): Buổi họp này thường diễn ra ngay sau buổi họp sơ kết Sprint và mất tầm khoảng 1-2 giờ thảo luận. Trong buổi họp nhóm sẽ đánh giá những việc mình đã làm và cách để làm cho nó tốt hơn. Về cơ bản, buổi họp sẽ xoay quanh trả lời những câu hỏi:
- Những việc nào chúng ta nên bắt đầu làm
- Những việc nào chúng ta không nên làm tiếp
- Những việc nào chúng ta nên duy trình làm tiếp
Sau khi có được danh sách những việc “cần bắt đầu làm”, “không nên làm tiếp”, “nên duy trì làm tiếp”, nhóm sẽ thống nhất chọn ra vài thứ mà nhóm sẽ tập trung để cải tiến trong Sprint kế tiếp. Kết quả thực thi những cải tiến này sẽ được thảo luận trong buổi họp cải tiến của Sprint sau.
Đồ nghề trong Scrum:
- Product Backlog: Là một danh sách các đầu mục cần phải làm để phát triển sản phẩm bao gồm đủ loại như chức năng của sản phẩm, lỗi cần sửa, nghiên cứu công nghệ hay những việc công việc liên quan khác. Những đầu mục này thường được mô tả dưới dạng “câu chuyện người dùng” (user story). Vd như “Là người dùng, tôi muốn xem lại danh sách các sản phẩm đã chọn trong giỏ hàng để tôi có thể biết được tôi đã chọn những gì”.
- Sprint Backlog: Là một danh sách các đầu mục mà nhóm cam kết hoàn thành trong Sprint sau buổi họp sơ kết Sprint. Trong thời gian diễn ra Sprint, nhóm phát triển sẽ chỉ tập trung vào danh sách này và cập nhật tiến độ hoàn thành của chúng.
- Biểu đồ Burndown (Burndown chart): Được dùng để đo tiến độ của Sprint hay của dự án. Không giống như biểu đồ Gantt chart (biểu đồ Gantt cho thấy ai làm việc gì và mất bao nhiêu thời gian để hoàn thành) thì biểu đồ Burndown sẽ cho thấy nhóm còn bao nhiêu thời gian để hoàn thành công việc đã được định ra lúc đầu. Biểu đồ Burndown đi xuống là một dấu hiệu tốt cho tiến độ hoàn thành công việc.
Hình. Burndown chart
- Bảng công việc: Được dùng để hiển thị những “câu chuyện người dùng” trong Sprint, những công việc nào cần làm cho “câu chuyện” đó, trạng thái của chúng cũng như những ghi chú cần thiết khác. Bạn nên lưu ý “Bảng công việc” theo đúng nghĩa của nó là công việc được biểu diễn trên một tấm bảng trắng. Nhóm sẽ dùng những sticky note nhiều màu sắc để ghi thông tin và dán lên trên tấm bảng đó. Việc đó sẽ giúp nhóm cập nhật thông tin một cách trực quan và nhanh hơn. Tuy nhiên, có một số dự án do đội phát triển không cùng một nơi thì có thể dùng công cụ để thể hiện “Bảng công việc” nhưng bản chất thì không thay đổi.
Hình. Bảng công việc
Mình vừa chia sẻ với các bạn tổng quan về Scrum. Nếu bạn cảm thấy Scrum khó và phức tạp thì có thể do cách trình bày của mình chưa tốt và gây khó hiểu. Về cơ bản, Scrum được thiết kế để có thể thực hành, nhỏ gọn và linh hoạt. Các công cụ trong Scrum rất trực quan sinh động và dể sử dụng. Các cuộc họp trong Scrum thường ngắn, có mục đích cụ thể và đi vào trọng tâm nên tính hiệu quả cũng cao hơn. Các vai trò trong Scrum ít nên sẽ dể dàng để trao đổi thông tin và giúp tránh được tình trạng “thắt cổ chai” trong công việc. Một điều cũng nên lưu ý rằng Scrum chỉ là một trong nhiều phương pháp để thực hành Agile. Ngoài Scrum, chúng ta còn có nhiều phương pháp khác để trở nên “linh hoạt” như XP (Extreme Programming), Lean, Kanban, v.v mà mình cũng chưa có cơ hội tìm hiểu sâu và trải nghiệm. Tuy nhiên, Scrum được ứng dụng phổ biến nhất hiện nay trong Agile, do đó nếu bạn có cơ hội trải nghiệm Scrum thì bạn cũng đã “Xì-trum” lắm rồi :-).
Bài viết có tham khảo nội dung từ:
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20VI.pdf#zoom=100