Mở đầu — vì sao bài này quan trọng
Khi nói đến Scrum, nhiều người hình dung ngay tới Product Owner (PO) là người "ra quyết định", Scrum Master là người "điều phối", còn nhóm còn lại thì gọi chung chung là "đội kỹ thuật". Cách hiểu này không sai, nhưng nó vô tình hạ thấp vai trò của một trong ba thành phần quan trọng nhất của Scrum Team: Developers.
Hãy ghi nhớ điều này ngay từ đầu: trong Scrum, không có sản phẩm nào được tạo ra mà không đi qua đôi tay của Developers. PO có thể có tầm nhìn xuất sắc, Scrum Master có thể bảo vệ team tuyệt vời, nhưng nếu Developers không biến ý tưởng thành một Increment dùng được sau mỗi Sprint, thì toàn bộ framework chỉ là lý thuyết suông. Developers chính là nơi giá trị được "đúc" ra thành hình hài cụ thể.
Là một Product Owner tương lai, bạn cần hiểu sâu về Developers vì một lý do rất thực tế: bạn sẽ làm việc với họ mỗi ngày. Bạn ưu tiên backlog cho họ làm, bạn giải thích "why" để họ quyết định "how", bạn nghiệm thu Increment họ giao. Nếu bạn không hiểu cách Developers vận hành, bạn sẽ vô tình trở thành một PO chuyên giao việc theo kiểu ra lệnh, phá vỡ tính tự quản (self-managing) — yếu tố sống còn của một Scrum Team hiệu quả. Bài này sẽ giúp bạn nhìn Developers đúng như Scrum Guide định nghĩa, và quan trọng hơn, đúng như họ cần được đối xử để phát huy hết năng lực.
Khái niệm cốt lõi
Định nghĩa chính thức
Scrum Guide 2020 định nghĩa rất rõ ràng:
> "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 thành viên trong Scrum Team cam kết tạo ra bất kỳ khía cạnh nào của một Increment dùng được trong mỗi Sprint.)
Hãy mổ xẻ định nghĩa này, vì mỗi cụm từ đều có chủ đích:
- "the people" — Developers là số nhiều, là một tập thể, không phải một cá nhân anh hùng.
- "committed to" — họ cam kết, chứ không phải được giao việc thụ động.
- "any aspect" — bất kỳ khía cạnh nào: code, thiết kế, kiểm thử, phân tích, tài liệu kỹ thuật, vận hành... Đây là điểm cực kỳ quan trọng mà chúng ta sẽ làm rõ bên dưới.
- "usable Increment" — kết quả phải dùng được, không phải làm dở dang.
- "each Sprint" — nhịp độ đều đặn, lặp lại.
"Developer" không có nghĩa là "lập trình viên"
Đây là hiểu lầm phổ biến nhất ở Việt Nam. Trong tiếng Việt, "developer" thường được dịch là "lập trình viên", khiến nhiều người tưởng Developers trong Scrum chỉ gồm coder. Hoàn toàn sai.
Trong Scrum, "Developers" mang nghĩa rộng: bất kỳ ai đóng góp vào việc tạo ra Increment. Một tester chuyên QA là Developer. Một UX/UI designer là Developer. Một data analyst chuẩn bị dữ liệu cho tính năng là Developer. Một business analyst viết spec kỹ thuật là Developer. Thậm chí trong các dự án phần cứng hay marketing, "Developers" có thể là kỹ sư cơ khí hoặc chuyên viên nội dung. Cái tên "Developer" chỉ vai trò "người tạo ra (develop) Increment", chứ không gắn với một nghề cụ thể.
Các đặc trưng cốt lõi của Developers
1. Self-managing (Tự quản lý)
Scrum Team là một nhóm tự quản. Không ai — kể cả Scrum Master hay PO — được phép nói cho Developers biết phải biến Product Backlog thành Increment bằng cách nào. Developers tự quyết định: ai làm việc gì, dùng kỹ thuật nào, kiến trúc ra sao, thứ tự thực hiện trong Sprint thế nào. PO quyết định what và why; Developers quyết định how.
2. Cross-functional (Đa chức năng)
Một nhóm cross-functional là nhóm có đủ mọi kỹ năng cần thiết để tạo ra giá trị trong mỗi Sprint mà không phụ thuộc người ngoài. Họ không cần "chờ đội QA bên kia rảnh" hay "đợi anh DBA ở phòng khác duyệt". Tất cả kỹ năng cần thiết nằm bên trong nhóm.
3. Không có chức danh hay sub-team chính thức
Scrum Guide nhấn mạnh: trong Developers không có titles (không có "senior", "lead" theo nghĩa cấp bậc quyền lực) và không có sub-teams (không chia "team frontend", "team backend" như những tiểu đội tách biệt). Tất cả cùng chịu trách nhiệm chung về Increment. Tất nhiên trong thực tế mọi người vẫn có chuyên môn khác nhau, nhưng trách nhiệm thì không bị phân mảnh.
4. Trách nhiệm tập thể (Accountability as a whole)
Cả nhóm Developers cùng chịu trách nhiệm về kết quả, chứ không phải "phần này của Nam thì Nam chịu". Khi một Increment không đạt Definition of Done, đó là vấn đề của cả nhóm, không phải lỗi của riêng cá nhân nào.
Các trách nhiệm cụ thể của Developers
Theo Scrum Guide, Developers luôn chịu trách nhiệm về:
- Tạo ra một kế hoạch cho Sprint, tức Sprint Backlog.
- Đảm bảo chất lượng bằng cách tuân thủ Definition of Done (DoD).
- Điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal (thông qua Daily Scrum).
- Chịu trách nhiệm lẫn nhau như những chuyên gia (hold each other accountable).
Quy mô nhóm
Scrum Team lý tưởng có 10 người trở xuống, trong đó Developers thường dao động khoảng 3–9 người. Quá ít thì thiếu kỹ năng và khó tự chủ; quá nhiều thì giao tiếp phức tạp, điều phối tốn kém. Đây là con số được rút ra từ kinh nghiệm để giữ nhóm đủ nhỏ để linh hoạt nhưng đủ lớn để hoàn thành công việc đáng kể.
Tình huống thực tế
Tình huống 1 — Tiki và bài học "any aspect of a usable Increment"
Giả định một nhóm tại một công ty thương mại điện tử lớn ở Việt Nam (lấy bối cảnh kiểu Tiki) đang phát triển tính năng "Đặt lịch giao hàng theo khung giờ". Nhóm Developers gồm 6 người: 2 backend, 1 frontend, 1 mobile, 1 QA tester, và 1 UX designer.
Trong Sprint Planning, một backend lập luận: "Tính năng coi như xong khi API trả về đúng khung giờ. Phần test và đo lường để Sprint sau làm." Kết quả Sprint đầu: API chạy, nhưng giao diện chọn giờ trên app khó dùng, chưa có test tự động, và khi demo cho stakeholder thì lỗi múi giờ khiến khách ở miền khác chọn nhầm khung giờ.
Diễn giải: Nhóm đã hiểu sai "Increment". Một Increment phải usable — dùng được, đạt Definition of Done — chứ không phải "code chạy là xong". Việc QA, UX, và backend tách rời nhau, ai lo phần nấy, đã phá vỡ tinh thần "Developers cùng tạo ra mọi khía cạnh của Increment".
Bài học: Increment là sản phẩm của cả nhóm Developers, bao gồm test, UX, đo lường — không chỉ code API. Từ Sprint sau, nhóm thống nhất DoD gồm cả "đã test E2E, đã review UX, đã xử lý múi giờ". Là PO, bạn nên là người gây áp lực lành mạnh để DoD phản ánh đúng "dùng được", thay vì để team tự thỏa hiệp xuống mức tối thiểu.
Tình huống 2 — Startup Fintech ở Singapore và sự cố "sub-team"
Một startup fintech tại Singapore có nhóm 8 Developers. Vì lý do lịch sử, họ tự chia thành "đội Frontend" (3 người) và "đội Backend" (5 người), hai bên gần như chỉ giao tiếp qua tài liệu API. Trong một Sprint phát triển tính năng chuyển tiền liên ngân hàng, đội Backend hoàn thành sớm và... ngồi chờ. Đội Frontend thì quá tải, làm không kịp. Cuối Sprint, Increment không hoàn chỉnh vì frontend nghẽn, trong khi backend rảnh rỗi 3 ngày.
Diễn giải: Đây chính là cái bẫy "sub-teams" mà Scrum Guide cảnh báo. Khi Developers tự chia thành các tiểu đội cứng nhắc, công việc không chảy mượt; người rảnh không giúp được người bận vì "không phải việc của tôi". Velocity của cả nhóm bị giới hạn bởi đội tắc nghẽn nhất.
Bài học: Cross-functional không chỉ là "nhóm có đủ skill", mà còn là tinh thần "cả nhóm cùng chịu trách nhiệm cho một Increment". Sau sự cố, Scrum Master tổ chức cho 2 backend học cơ bản về frontend (pair programming), để khi backend rảnh có thể "swarm" — xúm vào hỗ trợ frontend. Sprint sau, nhóm hoàn thành đúng hạn. Trách nhiệm tập thể không phải khẩu hiệu — nó là cách tổ chức công việc thực tế.
Tình huống 3 — Ngân hàng số tại Việt Nam và việc PO can thiệp vào "how"
Tại một ngân hàng số ở TP.HCM, một PO mới (vốn xuất thân kỹ thuật) thường xuyên dự Daily Scrum và bắt đầu chỉ đạo chi tiết: "Việc này nên dùng Redis cache", "Phần kia giao cho bạn Linh làm sẽ nhanh hơn". Ban đầu mọi việc có vẻ trôi, nhưng sau vài Sprint, Developers trở nên thụ động, chỉ chờ PO phân công, không còn chủ động đề xuất giải pháp. Tinh thần sa sút, một developer giỏi xin nghỉ.
Diễn giải: PO đã vượt ranh giới. Anh ấy can thiệp vào how — vốn là lãnh địa tự quản của Developers. Khi sự tự quản bị tước đoạt, động lực nội tại (intrinsic motivation) biến mất, và nhóm dần mất khả năng tự giải quyết vấn đề.
Bài học: Ranh giới vàng — PO sở hữu "what" và "why", Developers sở hữu "how". Một PO giỏi cung cấp bối cảnh, mục tiêu, ưu tiên thật rõ ràng, rồi tin tưởng để Developers tự tìm cách thực hiện tốt nhất. Tin tưởng không phải là buông lỏng; đó là điều kiện để self-management hoạt động.
Hướng dẫn từng bước
Nếu bạn là PO và muốn cộng tác hiệu quả với Developers, hãy theo các bước sau:
Bước 1 — Trao "why" trước khi trao "what". Trước mỗi item trong backlog, hãy chắc chắn Developers hiểu giá trị và bối cảnh: tính năng này giải quyết vấn đề gì cho người dùng nào. Khi hiểu "why", Developers tự tìm ra "how" thông minh hơn nhiều so với khi chỉ nhận một bản đặc tả khô khan.
Bước 2 — Tôn trọng ranh giới tự quản. Đừng phân công ai làm gì, đừng áp đặt giải pháp kỹ thuật. Hãy để Developers tự kéo (pull) công việc và tự tổ chức. Vai trò của bạn là làm rõ ưu tiên, không phải điều hành cách làm.
Bước 3 — Cùng nhau định nghĩa "usable". Tham gia xây dựng Definition of Done cùng Developers. DoD phản ánh "thế nào là Increment dùng được" — đây là điểm giao thoa giữa kỳ vọng kinh doanh (của bạn) và năng lực kỹ thuật (của họ).
Bước 4 — Sẵn sàng giải đáp trong Sprint. Developers sẽ liên tục có câu hỏi khi triển khai. Hãy có mặt (available) để làm rõ yêu cầu nhanh, tránh để họ bị block chỉ vì chờ bạn trả lời một câu hỏi nhỏ.
Bước 5 — Tin tưởng nhưng minh bạch. Theo dõi tiến độ qua Daily Scrum và Sprint Backlog (với tư cách quan sát viên, không chỉ đạo), qua biểu đồ burndown, qua đối thoại — chứ không phải qua việc giám sát từng người.
Bước 6 — Tôn vinh trách nhiệm tập thể. Khi Increment thành công, khen cả nhóm. Khi có vấn đề, hỏi "chúng ta học được gì" thay vì "ai làm hỏng". Điều này nuôi dưỡng tinh thần một đội.
Lỗi thường gặp & mẹo
Lỗi 1: Hiểu Developers chỉ là coder. Hệ quả là tester, designer bị xem là "người ngoài", Increment thiếu chất lượng. Mẹo: Luôn coi mọi người đóng góp vào Increment đều là Developers, mời tất cả vào mọi sự kiện Scrum.
Lỗi 2: PO hoặc Scrum Master phân công công việc cho Developers. Phá vỡ self-management. Mẹo: Hãy hỏi "Nhóm thấy nên làm thế nào?" thay vì "Em làm việc này nhé".
Lỗi 3: Để hình thành sub-team cứng nhắc. Gây nghẽn cổ chai. Mẹo: Khuyến khích pair/mob programming, chia sẻ kỹ năng (T-shaped skills), và văn hóa "swarming" — xúm vào hoàn thành item ưu tiên nhất.
Lỗi 4: Nhồi quá nhiều người vào nhóm. Một nhóm 15 Developers giao tiếp cực kỳ tốn kém. Mẹo: Giữ Scrum Team từ 10 người trở xuống; nếu lớn hơn, hãy cân nhắc tách thành nhiều Scrum Team (chủ đề scaling sẽ học ở bài sau).
Lỗi 5: Hiểu nhầm "self-managing" là "không cần trách nhiệm". Tự quản không có nghĩa muốn làm gì thì làm. Mẹo: Tự quản đi kèm cam kết với Sprint Goal và DoD — tự do trong khuôn khổ trách nhiệm.
Lỗi 6: Bỏ qua chất lượng để chạy theo số lượng. Developers bị ép giao nhiều mà bỏ test, nợ kỹ thuật chồng chất. Mẹo: Bảo vệ DoD như một cam kết bất khả xâm phạm; Increment không đạt DoD thì coi như chưa "Done".
Bài tập thực hành
Bài 1 — Nhận diện Developers. Liệt kê tất cả những người trong dự án gần nhất của bạn từng đóng góp vào việc tạo ra sản phẩm dùng được (code, test, thiết kế, phân tích, tài liệu...). Đánh dấu ai trong số đó "chính thức" được coi là một phần của nhóm phát triển, và ai bị xem là "người ngoài". Bạn rút ra điều gì?
Bài 2 — Vẽ ranh giới what/why vs how. Lấy 3 item bất kỳ trong backlog của bạn. Với mỗi item, viết ra rõ phần "what" và "why" (thuộc PO) và phần "how" (thuộc Developers). Tự kiểm tra: bạn có đang vô tình lấn sang "how" không?
Bài 3 — Tự đánh giá tính cross-functional. Cho nhóm hiện tại của bạn, liệt kê mọi kỹ năng cần để giao một Increment hoàn chỉnh. Đánh dấu kỹ năng nào nhóm tự có, kỹ năng nào phải phụ thuộc bên ngoài. Đề xuất một hành động cụ thể để giảm sự phụ thuộc đó.
Bài 4 — Viết lại Definition of Done. Soạn một DoD ngắn (5–8 tiêu chí) thể hiện đúng nghĩa "usable Increment" cho sản phẩm của bạn, bao gồm cả yêu cầu về test và chất lượng, không chỉ "code chạy".
Tóm tắt
Developers là những thành viên trong Scrum Team cam kết tạo ra bất kỳ khía cạnh nào của một Increment dùng được trong mỗi Sprint. Hãy nhớ các điểm cốt lõi:
- "Developers" không có nghĩa "lập trình viên" — đó là tất cả những ai tạo ra Increment: coder, tester, designer, analyst...
- Developers là một nhóm self-managing (tự quyết "how") và cross-functional (đủ mọi kỹ năng cần thiết).
- Không có titles, không có sub-teams cứng nhắc; cả nhóm cùng chịu trách nhiệm về Increment.
- Trách nhiệm cụ thể: tạo Sprint Backlog, tuân thủ DoD, điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal, và chịu trách nhiệm lẫn nhau.
- Quy mô lý tưởng: Scrum Team từ 10 người trở xuống.
- Ranh giới vàng với PO: PO sở hữu "what" và "why", Developers sở hữu "how".