Dẫn nhập
Các mô hình phát triển sản phẩm ngày này đa phần là mô hình iterate, nghĩa là mô hình có vòng lặp. Cho nên khi mình dạy lớp về product, có 2 câu mà mình hay nghe nhiều nhất “Waterfall là gì? Trước giờ em chỉ nghe về Scrum”, “Waterfall có thực sự đã chết?”. Nhìn chung, có thể bạn đã từng nghe qua hai từ khoá “Waterfall”, “Agile”. Có bao giờ bạn tò mò tự hỏi, Waterfall có thật là thác nước và Agile có phải chỉ là “nhanh nhẹn”? Và waterfall có thực sự biến mất hay không? Blog hôm nay mình sẽ dành để giải thích lại về những từ khoá về mô hình phát triển sản phẩm / phần mềm / dự án này và cùng nhìn lại khi nào thì waterfall vẫn có dất diễn bên cạnh sự lên ngôi của Agile.
Đây là bài viết của giảng viên Dương Lê, giảng viên lớp UX Nhập môn và Product Design tại TELOS Academy. Bài viết gốc nằm trên blog của chị ấy ở link này, hãy bấm vào để kết nối và học hỏi thêm từ giảng viên.
Nếu nói Waterfall và Agile là mô hình phát triển sản phẩm thì cũng không thực sự chính xác. Nói đúng hơn, đó là những mô hình để quản lý dự án. Tuy nhiên, việc phát triển sản phẩm thường được xem là một dự án – có thể dài hạn hoặc ngắn hạn. Cho nên chúng ta sẽ thấy khi nói về phát triển sản phẩm, mọi người hay hỏi “em làm theo Scrum hay Kanban?”. Điều đó dẫn tới ngoài phát triển các digital product, bất cứ việc xây dựng / phát triển một thứ gì đó nếu đã thành dự án đều có thể áp dụng các mô hình quản lý này. Ví dụ, công ty bạn cần xây dựng website, việc xây dựng website đó có thể xem như một dự án nhỏ vì có ngày bắt đầu, kết thúc, mục tiêu cần đạt. Vậy thì bạn hoàn toàn có thể áp dụng Waterfall hay Agile để quản lý kể cả mình chỉ làm một website công ty.
Waterfall (mô hình thác nước) là gì?
Trước tiên chúng ta nói về Waterfall. Tên gọi này được lấy từ tính chất của mô hình, nó giống như một cái thác nước nhiều tầng ấy. Khi bạn nhìn thấy các thác nước nhiều tầng như bên dưới, bạn sẽ thấy nước chảy từng tầng một xuống đến hồ bên dưới.
Quy trình Waterfall cũng vậy: dự án sẽ đi qua từng bước theo trật tự cố định và mỗi giai đoạn phải hoàn thành trước khi sang giai đoạn tiếp theo. Đây là một qui trình Waterfall điển hình:
Một khi nước (hay công việc) đã chảy qua một tầng, thì rất khó để chảy ngược lên trên. Nói cách khác, khi bạn đã “đi qua” một giai đoạn, việc quay lại chỉnh sửa gần như tốn kém và phức tạp. Ví dụ: nếu bạn đã thiết kế xong giao diện và đội dev đã code xong rồi, mà lúc đó khách hàng mới bảo “Ơ tôi muốn đổi màu chủ đạo từ xanh sang đỏ”, thì… ôi thôi, cả team sẽ rất khổ, vì phải quay lại từ bước thiết kế và chỉnh sửa toàn bộ code.
Ở một mức phức tạp hơn, có thể bạn sẽ muốn nghía qua các hạng mục công việc của một dự án Website Design & Develope từ A-Z
Agile là gì?
Mô hình waterfall dần dần trở nên không còn phù hợp trong việc phát triển digital product bởi vì tính thử nghiệm liên tục, sự thay đổi của thị trường, người dùng và yêu cầu phải học nhanh từ data để cải tiến sản phẩm. Để khắc phục nhược điểm mất thời gian, công sức khi có thay đổi của Waterfall, chúng ta có Agile. Agile là phương pháp quản lý dự án lặp đi lặp lại, tập trung vào việc chia nhỏ sản phẩm thành các vòng phát triển ngắn (iteration/sprint). Mỗi vòng thường kéo dài 1–4 tuần, bao gồm:
Ví dụ, chúng ta được giao làm một chiếc bánh kem. Với Agile, team sẽ chia nhỏ bánh ra làm từng iteration (vòng lặp): bắt đầu với làm cốt bánh, cho mọi người thử. Xong đến lớp kem, lại cho feedback. Cuối cùng mới đến trang trí hoa lá hẹ. Nhờ vậy, nếu khách đổi ý giữa chừng, bạn chỉ việc điều chỉnh lớp sau, không cần bỏ cả cái bánh.
Các mô hình phổ biến trong Agile có thể kể đến:
1. Scrum
Scrum là “món ăn đặc sản” của Agile, được dùng nhiều nhất. Hình dung Scrum như một đội bóng đá: mỗi sprint (thường 2 tuần) giống như một trận đấu. Team tập trung vào một “goal” cụ thể, có huấn luyện viên (Scrum Master), có đội trưởng (Product Owner) và cầu thủ (Development Team).
Mỗi ngày đều có “daily stand-up” – giống như cả đội họp nhanh 15 phút trước khi ra sân, xem hôm qua làm gì, hôm nay sẽ làm gì, có vướng mắc không. Nhờ vậy, Scrum giúp team gọn gàng, kỷ luật và liên tục tiến tới mục tiêu.
Một vòng đời Sprint thường có các buổi họp như sau:
2. Kanban
Nếu Scrum là bóng đá, thì Kanban giống như… quán phở. Bạn có bảng Kanban với cột “To Do – In Progress – Done”, mỗi công việc là một “tô phở” đặt trên bàn. Khi khách vào gọi món, bếp trưởng không làm một lúc 10 tô mà sẽ kéo từng tô từ “chưa làm” sang “đang nấu”, rồi cuối cùng là “ra lò”.
Điểm hay của Kanban là giúp team nhìn rõ luồng công việc, tránh ôm đồm quá nhiều, và tập trung hoàn thành việc trước mắt.
3. Extreme Programming (XP)
XP nghe hơi “hầm hố”, nhưng thực ra rất gần gũi: nó tập trung tối đa vào chất lượng code và phản hồi nhanh từ khách hàng. Ví dụ: lập trình đôi (pair programming) – hai dev cùng ngồi một máy, một người code, một người review ngay lập tức. Hay viết test trước khi code (test-driven development), để đảm bảo sản phẩm chạy mượt từ đầu.
Bạn có thể hình dung XP giống như một tiệm bánh cao cấp: mỗi công đoạn (trộn bột, nướng, trang trí) đều có kiểm soát chặt chẽ, thử nếm liên tục để đảm bảo chiếc bánh ra lò “xịn” đúng chuẩn.
4. Lean Software Development
Lean thì giống… phong cách “nấu ăn tiết kiệm”: tránh lãng phí, cái gì không cần thì bỏ, tập trung vào giá trị khách hàng. Ví dụ: thay vì thêm cả tá chức năng “cho sang”, Lean sẽ hỏi: khách thực sự cần gì để giải quyết vấn đề ngay?
Với Lean, sản phẩm được tinh gọn, tránh thừa mứa, đồng thời giảm chi phí và tăng tốc độ ra thị trường.
Nói ngắn gọn:
- Scrum → như đội bóng, chia trận (sprint).
- Kanban → như quán phở, nhìn dòng công việc.
- XP → như tiệm bánh cao cấp, kiểm soát chất lượng liên tục.
- Lean → như đầu bếp tiết kiệm, chỉ nấu cái khách cần.
Scaled Agile & mô hình Spotify
Khi công ty phát triển, không chỉ có 1–2 team nhỏ làm việc Agile, mà có rất nhiều team (Scrum, Kanban, XP…) cùng hoạt động song song, phối hợp với nhau để xây dựng sản phẩm lớn. Đây là lúc cần tới Scaled Agile — tức cách mở rộng Agile để ứng dụng ở quy mô lớn. Một trong những mô hình được biết đến nhiều khi nói về Agile at scale là Spotify Model (Mô hình Spotify).
Spotify Model không phải là “framework cứng nhắc” mà là tầm nhìn tổ chức xoay quanh văn hoá, cấu trúc và mạng lưới (network) sao cho các team có thể hoạt động linh hoạt, tự chủ. Ý tưởng là: tổ chức không phải ép mọi team phải làm Scrum, mà để mỗi team (Squad) chọn cách làm phù hợp (Scrum, Kanban, Scrumban…) nhưng vẫn có cấu trúc để giữ sự kết nối, chia sẻ kiến thức và giữ định hướng chung.
Cre: crisp.se
Để hình dung, mình dùng 1 ví dụ giả định: công ty muốn phát triển một ứng dụng “quản lý sức khoẻ”.
- Squad: tương tự như 1 Scrum team; team nhỏ, tự chức năng (frontend, backend, design, test…) — chịu trách nhiệm phát triển một mảnh chức năng (ví dụ module “theo dõi nhịp tim”). Mỗi Squad có Product Owner, Agile Coach nếu cần.
- Tribe: khi có nhiều Squad làm liên quan trong cùng lĩnh vực (ví dụ các module về sức khoẻ: nhịp tim, huyết áp, giấc ngủ…), thì các Squad này nằm trong 1 Tribe để phối hợp, share kiến thức, thống nhất hướng đi chung. Tribe thường từ 40–150 người để vẫn giữ được sự gắn kết.
- Chapter: đây là nơi tập hợp các người có kỹ năng chuyên môn giống nhau trong cùng Tribe — ví dụ các developer frontend, backend, QA trong Tribe sẽ thuộc các Chapter tương ứng. Chapter giúp chuẩn hóa, chia sẻ best practices, đảm bảo chất lượng kỹ thuật.
- Guild: cộng đồng sở thích / chủ đề, có thể vượt Tribe — ví dụ có Guild về “Machine Learning”, hay “UI/UX”, nơi mọi ai quan tâm đến ML hoặc UX từ nhiều Tribe có thể tham gia để học hỏi, chia sẻ. Không bắt buộc, không có cấu trúc quản lý cứng.
Atlassian - Trio / Alliance: khi công ty mở rộng hơn, xuất hiện nhu cầu liên kết giữa các Tribe — Trio là nhóm (Product Lead, Design Lead, Tribe Lead) làm việc chung để đảm bảo ba góc — business, design, kỹ thuật — được đồng bộ. Alliance là liên minh nhiều Tribe để phối hợp dự án lớn hơn phạm vi 1 Tribe.
Định nghĩa là vậy, tuy nhiên câu hỏi thường nghe về Waterfall và Agile nhất của mình là: Waterfall giờ ai còn dùng đúng không? Dự án tốt là phải chạy theo Agile đúng không? Thực tế lại không giống như lý thuyết, trong một dự án có khi là sự pha trộn giữa Waterfall và Agile, hoặc có phát sinh cách quản lý mới dựa trên hai mô hình này để phù hợp với dự án. Đúng rồi, thực tế hiếm khi “thuần” 100% một mô hình. Nhiều công ty vẫn dùng Waterfall cho những phần có tính chất rõ ràng, ít thay đổi (ví dụ: hạ tầng, tuân thủ pháp lý), trong khi áp dụng Agile cho những phần cần thử nghiệm nhanh (như tính năng mới, trải nghiệm người dùng). Người ta hay gọi đây là Hybrid model – kiểu “nửa thác nước, nửa linh hoạt”. Giống như bạn xây một tòa nhà: phần móng, kết cấu bê tông thì phải chắc chắn, có bản vẽ chi tiết ngay từ đầu (Waterfall). Nhưng khi tới phần nội thất, trang trí, sơn màu thì có thể thay đổi liên tục dựa trên gu của khách (Agile). Quan trọng không phải là “Agile hay Waterfall đúng hơn”, mà là chọn cách làm phù hợp với bối cảnh, sản phẩm và đội ngũ. Agile đem lại sự linh hoạt, nhưng đôi khi Waterfall lại cho sự chắc chắn cần thiết. Một dự án thông minh là dự án biết pha trộn và điều chỉnh cách quản lý để tối ưu cả tiến độ lẫn chất lượng.
Lấy ví dụ vì sao Waterfall không chết. Mình từng làm trong một dự án trong ngành bảo hiểm và tham gia vào một dự án xây dựng platform để bán sản phẩm bảo hiểm trực tuyến. Dự án của mình khi đó nếu nhìn nhận lại thì chính là sự đan xen giữa Waterfall truyền thống và Agile. Ví dụ, vì liên quan đến sản phẩm bảo hiểm nên yêu cầu phải đảm bảo về legal và compliance rất chặt chẽ. Design và tất cả tài liệu liên phải được chốt và gửi duyệt full bộ trước khi bắt đầu develop. Đến khi develop và test, để đảm bảo tiến độ thì dự án có áp dụng quản lý theo Agile để có thể test cuốn chiếu.
Agile trở nên phổ biến và chiếm tỉ trọng lớn nhờ vào sự linh hoạt phù hợp với tốc độ phát triển và thay đổi nhanh của thị trường, nhu cầu người dùng và cũng đồng thời giải quyết bài toán của vòng lặp thử-sai-làm lại. Nhưng Waterfall trong một số trường hợp đòi hỏi đảm bảo sự kiểm định và tuân thủ nghiêm ngặt thì vẫn là một sự lựa chọn. Hơn hết, bất kì mô hình quản lý nào cũng cần điều chỉnh cho phù hợp với dự án và team chứ không chỉ dừng lại ở việc máy móc áp dụng.
Waterfall và Agile, hay cho dù bất kì mô hình quản lý nào, điều quan trọng để 1 sản phẩm sống được: làm điều khách hàng muốn.
Đọc bài viết thấy hay hông? đăng ký học một lớp để gặp cô Dương Lê ngay tại:
