Ở phần trước, chúng ta đã tìm hiểu về các nguyên lý Agile.

Trái ngược với Agile, Scrum không phải là những nguyên lý chung chung mà là một bộ khung (framework), với các công cụ (artifact), vai trò (role) và qui trình rõ ràng dựa trên các nguyên lý của Agile.

Hầu hết các bài viết về Scrum hiện nay đều tập trung vào việc giải thích các khái niệm của Scrum. Để bạn đọc dễ hiểu hơn, mình sẽ lấy ví dụ cụ thể về một dự án phần mềm: Công ty A. nọ muốn tạo ra một hệ thống bán sách mang tên Taka.vn, cạnh tranh trực tiếp với Tiki.vn.

Trước tiên, chúng ta hãy cùng tìm hiểu một số khái niệm, vai trò trong qui trình Scrum.

Một số khái niệm quan trọng của Scrum

• User Story: Đây là tóm tắt một chức năng của sản phẩm đứng từ góc nhìn của người dùng. User story thường được viết trong một hai câu ngắn gọn, đơn giản, ví dụ như:
  • Là khách hàng mua sách, tôi có thể xem toàn bộ sách có trong cửa hàng
  • Là quản lý, tôi có thể thay đổi số lượng sách trong kho
• Story Point: Là một đơn vị được dùng để đánh giá công sức phải bỏ ra để thực hiện một user story. Story point càng nhiều thì user story đó càng lớn và tốn nhiều thời gian thực hiện.
• Product Backlog: Đây là danh sách những việc mà team cần phải làm để có thể hoàn thành sản phẩm. Mỗi việc này có thể là việc technical (tạo database, tích hợp API) hoặc là user stories.
• Sprint (Iteration): Có thể hiểu là một chu kì làm việc kéo dài từ 2 đến 4 tuần. Trong một sprint, team thực hiện các quá trình như thiết kế, code, test để tạo ra sản phẩm vào cuối sprint.
• Sprint Backlog: Ở đầu mỗi sprint, cả team sẽ có một cuộc họp để lựa chọn những user story quan trọng mà team phải hoàn thành trong sprint này. Những user story này sẽ được bỏ vào Sprint Backlog. Ví dụ ở sprint đầu, team cần một bản demo để người mua sách sử dụng, họ sẽ chọn những user story liên quan đến người mua để thêm vào backlog.
• Definition of Done (Định nghĩa hoàn thành): Trước khi bắt đầu, cả nhóm phải thống nhất thế nào là “hoàn thành” một công việc. Hoàn thành có thể là user stories đó đã được code và test xong, hoặc module đó đã demo cho khách hàng và được khách hàng duyệt. Định nghĩa này tùy thuộc vào mỗi team.

Một số vị trí (role) trong Scrum

• Scrum Master: Đây là người đảm bảo mọi người hiểu và thực hiện đúng qui trình Scrum. Họ cũng có trách nhiệm huấn luyện các thành viên trong nhóm về qui trình, tổ chức các cuộc họp.
• Product Owner: Là người quản lý Product Backlog. Với Taka.vn, product owner là người quyết định những chức năng nào nên được thêm vào, những chức năng nào nên bị bỏ đi, giải thích từng chức năng cho các thành viên trong nhóm làm việc.
• Development Team: Dựa theo các user story trong product backlog, team tạo ra sản phẩm. Trong team không chia ra các vị trí như team leader, tester,… mà tất cả đều là developer ngang hàng nhau. Cả team sẽ tự phân chia công việc, tự dự đoán thời gian hoàn thành (trong thực tế làm việc, mình thấy các nhóm Scrum vẫn có vị trí leader, hỗ trợ các thành viên chọn công việc và ước đoán).

Chuyện họp hành

Trong qui trình Scrum, thành viên thường phải tham gia các cuộc họp sau:

• Sprint Planning Meeting: Cuộc họp này được bắt đầu mỗi Sprint, kéo dài khoảng 4 tiếng. Cuộc họp giúp xác định mục tiêu cần đạt được trong Sprint và những công việc (user story) cần làm. Trong cuộc họp này, cả nhóm cũng ước đoán story point cho mỗi user story.
• Daily Meeting: Xuyên suốt Sprint, mỗi ngày cả team sẽ bỏ ra khoảng 15 phút để tổ chức một cuộc họp ngắn. Việc họp này giúp các thành viên nắm được tình hình dự án. Trong cuộc họp, mỗi thành viên trả lời 3 câu hỏi:
  • Hôm qua tôi đã làm được gì?
  • Hôm nay tôi sẽ làm gì?
  • Tôi đang gặp trở ngại, vướng mắc gì?
• Sprint Review Meeting: Cuộc họp này diễn ra sau khi kết thúc Sprint. Cả nhóm sẽ xem xét lại những việc đã hoàn thành, chưa hoàn thành, sau đó demo những phần đã hoàn thành cho Product Owner. Product Backlog sẽ được cập nhật lại.
• Retrospective Meeting: Trong buổi họp này, cả nhóm cùng ngồi nhìn lại và đánh giá những điểm được và chưa được trong Sprint vừa qua, đồng thời đề xuất các biện pháp cải tiến.

Một Sprint làm việc của team Scrum

Giả sử mình là một thành viên trong Development Team của Taka.vn. Một Sprint làm việc của mình sẽ trông như sau:

• Đầu tháng 2, bắt đầu Sprint. Mình tham dự Sprint Planning Meeting. Trong cuộc họp này, anh Product Owner xác nhận mục tiêu là “cho phép người mua xem và bình chọn sách trong hệ thống”. Những user story được chọn cho Sprint Backlog là:
  • Là một người mua, tôi muốn xem toàn bộ sách trong hệ thống (3 points)
  • Là một người mua, tôi muốn tìm sách theo tên tác giả (5 points)
  • Là một người mua, tôi muốn bình chọn cho sách (8 points)
  • Là một người mua, tôi muốn xem những sách được bình chọn cao nhất (8 points)
  • ….
• Sau buổi họp, mình và các bạn trong nhóm chọn những user stories sẽ làm. Mỗi sáng, mình tham dự họp Daily Meeting từ 10h tới 10h15. Mình trả lời các câu hỏi (không dài dòng, nếu cần bàn luận chuyên môn hãy tổ chức cuộc họp khác):
  • Hôm qua mình đã dựng xong giao diện cho chức năng bình chọn
  • Hôm nay mình sẽ thiết kế database và bắt đầu viết code cho chức năng này
  • Khó khăn: Database trên máy mình không truy cập được, có thể tốn thời gian sửa
• Giữa tháng 2, kết thúc Sprint, mình tham dự Sprint Review Meeting. Cả team demo chức năng đã làm xong (chọn sách, bình luận). Sau khi xem demo, Product Owner đưa ra nhận xét, cập nhận lại requirement, thêm yêu cầu mới.
• Sau đó, cả nhóm tham gia Retrospective Meeting. Team đã làm tốt việc giao tiếp với nhau, làm đúng yêu cầu khách hàng, đúng hẹn. Tuy vậy, do chưa có chuẩn chung nên mọi người code và thiết kế một kiểu. Cả nhóm đề xuất biện pháp “tạo ra coding và design convention để mọi người tuân theo” nhằm cải tiến qui trình.

Lưu ý: Hầu hết các công ty không tuân theo qui trình Scrum “chuẩn” hoàn toàn mà sẽ biến đổi nó để phù hợp với văn hóa và qui trình của công ty. Thứ quan trọng nhất là hiệu quả công việc, sản phẩm làm ra chứ không phải là “theo đúng qui trình”.

Ngoài ra, đừng quá lo lắng khi bạn chưa thể hình dung được cách qui trình Scrum hoạt động. Chỉ cần đi làm khoảng 1,2 tuần và tham gia vào một dự án, bạn sẽ hiểu ngay thôi.

 

30s quảng cáo

Đây là một bài viết được trích dẫn từ cuốn sách “Code dạo kí sự – Lập trình viên đâu phải chỉ biết code” do mình viết. Quyển sách bao gồm những kĩ năng từ mềm đến cứng mà mỗi developer phải có, đảm bảo sẽ rất có ích cho các bạn sinh viên hoặc lập trình viên đã đi làm. Các bạn xem thông tin và đặt mua sách tại đây nhé: Sách Code Dạo Ký Sự