Hiểu cơ bản về Scrum trong 5 phút (1/2)

Cho đến nay, tôi đã giới thiệu phương pháp Scrum - phương pháp quản lý chủ yếu được sử dụng trong thời kỳ Agile. Lần này, tôi sẽ tóm tắt những ý cơ bản thật ngắn gọn.

Về cơ bản, Scrum là gì?

Nói ngắn gọn, Scrum là một khung thời gian (Frame work) để thúc đẩy các công việc bằng nhóm làm việc.

Ban đầu, nó là một cơ chế để làm cho các dự án phát triển phần mềm thành công, nhưng sau đó thì các yếu tố kỹ thuật đã được loại bỏ, chỉ còn giữ lại những yếu tố thích hợp có thể áp dụng chung cho nhiều đội nhóm. Vì vậy đặc điểm của Scurm là có thể áp dụng tốt cho cả những dự án ngoài phát triển phần mềm.

Backlog: Là danh sách hàng đợi, kế hoạch làm việc, kế hoạch thay đổi Canvas của team.

Trong Scrum, có 2 loại Backlog được định nghĩa:

• Product Backlog: mô tả những giá trị mà sản phẩm sẽ mang lại cho khách hàng và user.

• Sprint Backlog: hiển thị kế hoạch công việc hiện tại.

Product Backlog

Product Backlog là những danh sách những tính năng hay yếu tố cải tiến kỹ thuật đã được đánh độ ưu tiên. Tất cả mọi người liên quan đều có thể theo dõi được danh sách đó và nắm được tình trạng sản phẩm hiện tại.

User story là hình thức được sử dụng nhiều, tuy nhiên hình thức sử dụng không quá quan trọng, mục tiêu là đảm bảo được tất cả những người liên quan có thể nhớ được nội dung bất kỳ lúc nào.

• Vì ai?

• Vì cái gì?

• Sẽ thực hiện cái đó chứ?

Việc thống nhất được những điều trên sẽ giúp cho việc gợi nhớ lại nội dung công việc ở bất cứ lúc nào. Do đó, nếu có thay đổi spec thì việc lí giải "Tại sao cần thay đổi?" sẽ trở nên dễ dàng hơn, việc nắm được và truyền đạt lại mức độ ảnh hưởng tới toàn bộ tiến độ của sản phẩm cũng sẽ trở nên trơn tru hơn.

Khi có thay đổi gấp về spec mà chúng ta cứ tốn nhiều thời gian để thảo luận và thuyết phục xoay quanh chủ đề "Vốn dĩ trước đây tính năng này là...." thì có thể đây chính là con đường trực tiếp dẫn tới cái chết của một dự án. Trước khi rơi vào khủng hoảng thì chúng ta nên chia sẻ tình hình một cách thường xuyên và minh bạch, từ đó thúc đẩy sự tin tưởng giữa các bên. Thay vì che dấu và mang một bộ mặt lạnh như tiền để đàm phán với khách hàng thì chúng ta nên phơi bày ra hết thực lực mà mình có để cả 2 bên đều nắm bắt được.

Sprint Backlog

Sprint Backlog là "List task của team" được lấy ra từ Product Backlog sao cho phù hợp với sprint làm việc (từ 1~4 tuần).

Nhóm sẽ xem xét xem có thể hoàn thành được lượng công việc đó hay không dựa trên các ước lượng. Các thành viên trong team thì đều có skill khác nhau, vậy nên điều quan trọng là cần phải xác nhận để có thể tự tin nói rằng "Có thể xong được".

Trong thời gian của sprint, để hoàn thành các công việc và tính năng được liệt kê trong Sprint Backlog thì cần phải có sự nỗ lực của cả nhóm. Không phải là công việc của tôi, công việc của bạn, mà là công việc của cả nhóm. Phải có tinh thần chịu trách nhiệm và hoàn thiện năng lực với tư cách cả nhóm chứ không phải riêng mỗi cá nhân nào cả.

Vì vậy, việc chia sẻ thông tin với tư cách cả nhóm là một việc không thể thiếu. Để đạt được điều đó thì buổi Daily scrum cần phải đạt hiệu quả. Daily scrum là buổi họp hàng ngày để cả nhóm xác nhận với nhau về tiến độ công việc.

Nội dung của Daily scrum là trả lời 3 câu hỏi dưới đây:

• Việc đã làm hôm qua?
• Việc sẽ làm hôm nay?
• Vấn đề đang gặp phải?

Khi chia sẻ với cả nhóm câu trả lời cho 3 câu hỏi trên, nên tránh việc đi sâu vào các vấn đề (gây mất thời gian), cố gắng hoàn thành buổi họp trong vòng 15'.

Task board

Task boar (còn gọi là bảng Kanban) là Backlog biểu diễn các tác vụ bằng bảng và các giấy note. Nó giúp chia sẻ tình hình mới nhất một cách nhanh chóng để bạn có thể nắm được tình hình một cách trực quan.

Các task sẽ được di chuyển vào các vùng tương ứng dưới đây:

• ToDo (Task sẽ làm)
• Inprogress (Task đang làm)
• Done (Task đã hoàn thành)

Cách sử dụng

1. Viết tất cả các task trong Sprint Backlog vào giấy note và dán vào phần 「ToDo」.
2. Tại buổi họp Daily scrum, từng thành viên di chuyển các tờ giấy note vào các mục 「Done」 và 「Inprogress」 tương ứng.

Bản thân Task board cũng được cải tiến và chỉnh sửa theo cách làm việc của nhóm và các vấn đề phát sinh trong quá trình làm việc.

Chi tiết về Backlog và Daily scrum các bạn có thể đọc thêm ở các bài viết bằng tiếng Nhật dưới đây:

• 第1回「ほう・れん・そう」を15分の朝会に置き換える
• 第2回“なる早”タスクに振り回されないための「バックログ」
• 第3回バックログで、動的に計画変更できる仕組みを作る
• 第4回プロジェクト予測の限界、改善法としてのスクラム

Role (vai trò): Từ chủ thể là Leader/Manager chuyển sang chủ thể là Team

Một nhóm lý tưởng là có từ 3~9 người

Thay vì đẩy hết trách nhiệm cho Leader và Manager thì cả nhóm sẽ tự quản lý với nhau và cùng chịu trách nhiệm.

Đó chính là cách một Scrum team vận hành.

Để nhóm có thể giao tiếp với nhau một cách trơn tru thì số lượng thành viên trong nhóm không được quá nhiều. Scrum khuyến khích một nhóm nên có từ 3~9 người. Nếu nhóm có 9 người thì khi Daily scrum, mỗi người sẽ nói khoảng 1' và sẽ có khoảng 9' để kết thúc daily scrum.

Product owner

Trong Scrum, nhóm sẽ làm việc độc lập, nhưng khi ra quyết định chung liên quan đến sản phẩm thường không mang lại nhiều hiệu quả. Khi đó, Product owner (PO) sẽ là người quyết định.

PO là người tạo ra các Product Backlog và là người chịu trách nhiệm cuối cùng cho việc sắp xếp độ ưu tiên các tác vụ. Trên thế giới có rất nhiều thứ bạn không thể biết nếu như không thử, vậy nên thay vì tổ chức 100 cuộc họp, chúng ta nên quyết định thứ tự ưu tiên theo cảm tính cũng được, sau đó làm thử và đưa ra phán đoán tiếp theo dựa trên kết quả đã thực hiện.

Scrum master

Scrum master là người cố vấn và xây dựng môi trường xung quanh cho nhóm làm việc. Là người có vai trò đảm bảo cho team luôn trong trạng thái tốt nhất, cũng có thể gọi là Bác sĩ của team.

Công việc của Scrum master là kiểm tra xem công việc của team có tiến triển tốt không, có vấn đề vướng mắc nào đang gặp phải không? Đôi khi, Scrum master phải tách các vấn đề ra khỏi team và tự giải quyết chúng để giữ sự tập trung cho team. Trong trường hợp PO làm việc không thực sự tốt thì Scrum master cũng đưa ra lời khuyên và cách khắc phục, điều chỉnh.

Chi tiết về Team, Product Owner, Scrum master các bạn có thể đọc thêm ở các bài viết bằng tiếng Nhật dưới đây:

• 第5回最適化した開発チームは3～10人で美しく回る
• 第6回指示しないリーダー像：プロダクトオーナーは舵取り役
• 第7回スクラムマスター：不都合な事実を見つけるチームの医

(còn nữa...)

Link bài gốc tại đây