Mở đầu — vì sao bài này quan trọng
Khi nhắc đến Scrum, nhiều người Việt Nam vẫn quen miệng gọi "lập trình viên", "coder", hay "team kỹ thuật". Nhưng trong Scrum Guide 2020, có một accountability (trách nhiệm giải trình) được đặt tên rất chính xác và cũng dễ gây hiểu lầm nhất: Developers. Đây là nhóm đông nhất trong Scrum Team, là những người trực tiếp biến ý tưởng thành sản phẩm chạy được — và cũng là phần mà đề thi PSM I "gài bẫy" nhiều nhất.
Tại sao bài này quan trọng cho kỳ thi và cho công việc thực tế? Vì rất nhiều thí sinh người Việt mất điểm oan ở những câu hỏi kiểu: "Ai quyết định bao nhiêu việc đưa vào Sprint?", "Ai có quyền thay đổi Sprint Backlog giữa Sprint?", "Tester có phải là Developer không?". Nếu bạn vẫn nghĩ Developer chỉ là "người viết code", bạn sẽ trả lời sai hàng loạt. Scrum định nghĩa Developer rộng và sâu hơn nhiều so với nghĩa thông thường trong tiếng Việt.
Bài này tập trung chỉ vào accountability của Developers — không lan sang Product Owner (Bài 9) hay Scrum Master (Bài 10). Sau khi học xong, bạn sẽ trả lời "theo sách" mọi câu hỏi về quyền hạn, trách nhiệm và đặc tính của Developers.
Khái niệm cốt lõi
Định nghĩa "by the book"
Scrum Guide 2020 định nghĩa rất gọn:
> Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. > > (Developers là những người trong Scrum Team cam kết tạo ra bất kỳ khía cạnh nào của một Increment khả dụng trong mỗi Sprint.)
Hãy đọc kỹ ba điểm mấu chốt trong câu này, vì đề thi xoáy đúng vào đây:
- "any aspect" — bất kỳ khía cạnh nào. Không chỉ là viết code. Một Increment khả dụng cần phân tích, thiết kế, lập trình, kiểm thử, viết tài liệu, tích hợp, triển khai... Người làm bất kỳ phần nào trong số đó, để góp phần tạo ra Increment, đều là Developer.
- "usable Increment" — Increment khả dụng. Mục tiêu không phải là "làm xong task của mình" mà là cùng nhau tạo ra một phần sản phẩm dùng được.
- "each Sprint" — mỗi Sprint. Đây là cam kết lặp đi lặp lại, không phải làm một lần rồi thôi.
Developers chịu trách nhiệm gì (accountabilities)
Scrum Guide liệt kê các trách nhiệm cụ thể của Developers. Hãy ghi nhớ chính xác bốn điều sau:
- Creating a plan for the Sprint, the Sprint Backlog — Tạo ra kế hoạch cho Sprint, tức là Sprint Backlog. Developers là người làm chủ Sprint Backlog.
- Instilling quality by adhering to a Definition of Done — Đảm bảo chất lượng bằng cách tuân thủ Definition of Done (DoD). Chất lượng là trách nhiệm của Developers, không phải của QA riêng lẻ hay của một ai khác.
- Adapting their plan each day toward the Sprint Goal — Điều chỉnh kế hoạch của họ mỗi ngày hướng tới Sprint Goal. Đây chính là tinh thần của Daily Scrum.
- Holding each other accountable as professionals — Chịu trách nhiệm với nhau như những người chuyên nghiệp. Đây là tinh thần tự quản (self-management).
Quyền hạn quan trọng của Developers
Bên cạnh trách nhiệm, Developers có những quyền hạn mà đề PSM I thường kiểm tra:
- Developers — và chỉ Developers — quyết định bao nhiêu công việc đưa vào Sprint. Product Owner sắp xếp thứ tự ưu tiên Product Backlog và làm rõ giá trị, nhưng số lượng việc lấy vào Sprint là do Developers tự định đoạt, dựa trên năng lực của họ. Không ai được "ép" Developers nhận thêm việc.
- Developers là người duy nhất được sửa Sprint Backlog trong Sprint. Sprint Backlog thuộc về Developers. Họ cập nhật nó liên tục khi học được điều mới. Product Owner và Scrum Master không tự ý chỉnh Sprint Backlog.
- Developers quyết định cách thực hiện công việc (the "how"). Product Owner quyết định "cái gì" (what) và thứ tự, còn Developers tự tổ chức cách họ biến công việc thành Increment.
Đặc tính của Developers
Hai đặc tính then chốt mà bạn cần phân biệt với các bài khác:
- Self-managing (tự quản): Developers tự quyết ai làm gì, khi nào, như thế nào. Không có "team lead" trong Scrum ra lệnh phân công. Sẽ học sâu ở Bài 28.
- Cross-functional (đa kỹ năng): Cả nhóm Developers gộp lại phải có đủ mọi kỹ năng cần thiết để tạo ra Increment mà không phụ thuộc vào người ngoài team. Sẽ học sâu ở Bài 29.
Số lượng Developers
Scrum Team thường có 10 người hoặc ít hơn, gồm 1 Product Owner, 1 Scrum Master và phần còn lại là Developers. Scrum Guide không quy định con số tối thiểu cứng cho riêng Developers, nhưng nguyên tắc là: đủ nhỏ để linh hoạt, đủ lớn để hoàn thành công việc có ý nghĩa trong một Sprint. Nếu team quá lớn, hãy chia thành nhiều Scrum Team cùng làm trên một sản phẩm (Bài 38).
Tình huống thực tế
Ví dụ 1 — Tiki: "Tester không phải Developer" và cái giá phải trả
Một nhóm sản phẩm tại một sàn thương mại điện tử lớn ở Việt Nam (tạm gọi mô hình giống Tiki) có 5 lập trình viên và 2 nhân viên QA. Ban đầu, người quản lý cho rằng "Developers" chỉ gồm 5 lập trình viên, còn 2 QA là "bộ phận kiểm thử riêng", chỉ vào cuộc ở cuối Sprint.
Kết quả: trong Sprint Planning, 5 lập trình viên ước lượng và nhận 13 user story. Nhưng đến ngày thứ 8 của Sprint 2 tuần, QA mới bắt đầu test, phát hiện hàng loạt lỗi, và Increment không kịp đạt Definition of Done. Sprint Review chỉ demo được 6 story "tạm chạy được".
Vấn đề ở đây là họ đã hiểu sai khái niệm Developer. Theo Scrum, cả 7 người — 5 lập trình viên và 2 QA — đều là Developers, vì cả hai vai trò đều góp phần tạo ra Increment khả dụng. Khi tổ chức lại, 2 QA tham gia ngay từ Sprint Planning, cùng ước lượng, kiểm thử song song với việc code ngay trong tuần đầu. Số story lấy vào giảm xuống còn 9 nhưng tất cả đều đạt DoD.
Bài học: Đừng để cái tên "Developer" đánh lừa. QA, BA, designer tham gia tạo Increment đều là Developers. Việc tách "team test" ra ngoài Sprint phá vỡ tính cross-functional và làm chất lượng trượt dốc.
Ví dụ 2 — Một startup fintech ở TP.HCM: ai mới được quyết định khối lượng việc?
Tại một startup fintech khoảng 30 người ở Quận 1, TP.HCM, có một Product Owner rất nhiệt huyết. Trước mỗi Sprint, anh ấy lập sẵn danh sách "Sprint này phải xong 20 story" rồi thông báo cho nhóm 6 Developers. Áp lực khiến team thường xuyên overtime, chất lượng đi xuống, và 2 Developer xin nghỉ trong vòng 3 tháng.
Scrum Master mới về đã chỉ ra một vi phạm cơ bản: Product Owner không có quyền quyết định bao nhiêu việc đưa vào Sprint. Theo Scrum Guide, "the Developers... select" — chính Developers chọn số lượng từ Product Backlog đã được sắp xếp ưu tiên. Product Owner có thể trình bày mục tiêu, làm rõ giá trị, thương lượng phạm vi, nhưng con số cuối cùng do Developers tự định đoạt dựa trên năng lực thật.
Sau khi điều chỉnh, Product Owner chỉ đưa ra Product Goal và thứ tự ưu tiên; Developers tự đề xuất nhận 11–13 story mỗi Sprint dựa trên forecast của họ (xem thêm Bài 31 về forecasting). Tốc độ thực tế ổn định hơn, overtime giảm hẳn.
Bài học: Quyền quyết định khối lượng việc trong Sprint thuộc về Developers, không phải Product Owner hay quản lý. Đây là một câu kinh điển trong đề PSM I.
Ví dụ 3 — Đội game ở Singapore: tự quản khi gặp việc phát sinh giữa Sprint
Một studio game tại Singapore có nhóm 7 Developers đang chạy Sprint 2 tuần với Sprint Goal là "ra mắt chế độ chơi PvP thử nghiệm". Đến giữa Sprint, họ phát hiện một tác vụ kỹ thuật bị ước lượng thiếu, cần thêm việc tích hợp máy chủ mà ban đầu chưa lường tới.
Trong nhiều tổ chức cũ, Developers sẽ chờ "sếp" hoặc Scrum Master ra quyết định. Nhưng đúng tinh thần Scrum, Developers tự cập nhật Sprint Backlog: họ thêm các đầu việc mới cần thiết, bỏ bớt một story phụ ít quan trọng để bảo toàn Sprint Goal, và trao đổi với Product Owner về phạm vi. Họ không cần xin phép ai để sửa Sprint Backlog — đó là artifact của họ.
Quan trọng: họ vẫn giữ nguyên Sprint Goal (Bài 22). Việc thương lượng phạm vi với Product Owner là hợp lệ, nhưng Sprint Goal là cam kết thì cả nhóm bám sát.
Bài học: Developers tự quản nghĩa là họ chủ động điều chỉnh kế hoạch hằng ngày hướng tới Sprint Goal, và họ — chứ không phải ai khác — là người sở hữu và sửa Sprint Backlog trong Sprint.
Hướng dẫn từng bước
Nếu bạn đang giúp một nhóm vận hành đúng accountability của Developers, hãy làm theo các bước sau:
- Xác định ai là Developers. Liệt kê tất cả những người tham gia tạo Increment: lập trình viên, QA, designer, BA, DevOps... Tất cả họ đều là Developers. Loại bỏ tư duy "team test riêng".
- Đảm bảo tính cross-functional. Kiểm tra: nhóm Developers gộp lại có đủ kỹ năng để đi từ ý tưởng đến Increment khả dụng không? Nếu thiếu kỹ năng nào (ví dụ không ai biết viết test tự động), hãy bồi đắp kỹ năng đó trong nhóm.
- Trao quyền quyết định khối lượng việc cho Developers. Trong Sprint Planning, để Developers tự chọn bao nhiêu Product Backlog Item đưa vào, dựa trên năng lực và forecast của chính họ. Product Owner không áp số.
- Giao quyền sở hữu Sprint Backlog. Chỉ Developers cập nhật Sprint Backlog trong suốt Sprint. Họ điều chỉnh mỗi ngày hướng tới Sprint Goal.
- Gắn chất lượng vào Definition of Done. Developers cam kết mọi việc "Done" đều đạt DoD. Chất lượng là trách nhiệm tập thể của Developers (liên hệ Bài 19, 20, 37).
- Nuôi dưỡng tự quản và trách nhiệm với nhau. Không phân công từ trên xuống; Developers tự tổ chức và "hold each other accountable" như những người chuyên nghiệp.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ Developer chỉ là lập trình viên. Đây là lỗi phổ biến nhất với người Việt vì dịch từ "developer" thường ra "lập trình viên". Mẹo: trong Scrum, hãy đọc "Developer" = "người tạo ra Increment", bao gồm mọi vai trò kỹ thuật và phi kỹ thuật góp phần làm sản phẩm.
Lỗi 2 — Tin rằng Product Owner hoặc manager quyết định khối lượng việc trong Sprint. Sai. Developers chọn. Nhớ động từ "the Developers select/forecast".
Lỗi 3 — Cho rằng có "team lead" phân công việc cho Developers. Scrum không có cấp bậc trong team, không có sub-teams. Developers tự quản.
Lỗi 4 — Nghĩ QA / Scrum Master / một người riêng chịu trách nhiệm chất lượng. Không. Chất lượng gắn với DoD và là trách nhiệm của toàn bộ Developers.
Lỗi 5 — Nghĩ Sprint Backlog do Scrum Master hay Product Owner quản lý. Sprint Backlog thuộc về Developers; chỉ họ được sửa trong Sprint.
Mẹo ghi nhớ nhanh: Gắn Developers với 4 từ khóa — Plan (Sprint Backlog), Quality (DoD), Adapt daily (Sprint Goal), Accountable to each other (self-managing). Khi gặp câu hỏi, đối chiếu 4 từ này.
Mẹo phân vai: Product Owner = "WHAT & WHY" (cái gì, vì sao, thứ tự ưu tiên). Developers = "HOW & HOW MUCH" (làm thế nào và lấy bao nhiêu vào Sprint). Scrum Master = "giúp mọi người làm đúng Scrum".
Bài tập thực hành
- Phân loại vai trò: Trong một Scrum Team gồm 1 PO, 1 SM, 3 lập trình viên, 1 QA, 1 UX designer — có bao nhiêu Developers? (Đáp án gợi ý: 5 — gồm 3 lập trình viên, 1 QA và 1 designer.)
- Tình huống quyết định: Manager nói với team: "Sprint tới phải hoàn thành đúng 18 story, không bàn cãi." Theo Scrum, điều này vi phạm nguyên tắc nào? Ai mới có quyền quyết định con số đó?
- Tự kiểm tra DoD: Hãy viết ra: nếu một story đã code xong nhưng chưa qua kiểm thử và chưa đạt Definition of Done, nó có được tính là "Done" trong Sprint Review không? Ai chịu trách nhiệm về điều này?
- Phản tư thực tế: Ở nhóm bạn (hoặc nhóm bạn từng làm), ai đang quyết định khối lượng việc mỗi Sprint, và ai sửa Sprint Backlog? So sánh với cách Scrum quy định và chỉ ra một điểm cần thay đổi.
- Câu hỏi kiểu thi: "Giữa Sprint, Developers phát hiện cần thêm việc để đạt Sprint Goal. Họ nên làm gì?" Viết câu trả lời "by the book" trong một câu. (Gợi ý: tự cập nhật Sprint Backlog, điều chỉnh kế hoạch hướng tới Sprint Goal, trao đổi với Product Owner về phạm vi nếu cần.)
Tóm tắt
- Developers là những người trong Scrum Team cam kết tạo ra bất kỳ khía cạnh nào của một Increment khả dụng trong mỗi Sprint — không chỉ lập trình viên, mà gồm cả QA, designer, BA và mọi vai trò góp phần tạo sản phẩm.
- Bốn trách nhiệm cốt lõi: tạo Sprint Backlog, đảm bảo chất lượng qua DoD, điều chỉnh kế hoạch hằng ngày hướng tới Sprint Goal, và chịu trách nhiệm với nhau như những người chuyên nghiệp.
- Quyền then chốt: Developers quyết định bao nhiêu việc vào Sprint và là người duy nhất sửa Sprint Backlog trong Sprint; họ quyết định "how".
- Đặc tính: self-managing và cross-functional, không sub-teams, không hierarchy.
- Câu "gài bẫy" của PSM I luôn xoay quanh: ai quyết khối lượng việc (Developers), ai chịu trách nhiệm chất lượng (Developers), ai sửa Sprint Backlog (Developers). Trả lời "theo sách" và bạn sẽ ăn trọn điểm những câu này.