10. Phát triển lặp và Tạo nguyên mẫu
Mục lục
🔁 Phát triển Lặp (Iterative Development) – Trái tim của Agile
🎯 1. Đặt vấn đề: Tại sao “phát triển lặp” lại quan trọng trong Agile?
Trong phát triển phần mềm truyền thống (Waterfall), nhóm phát triển thường đi theo tuyến tính: phân tích → thiết kế → lập trình → kiểm thử → bàn giao. Nếu phát hiện sai sót ở bước sau, quay lại bước trước là cực kỳ tốn kém.
Ngược lại, Agile xem mỗi vòng lặp là một cơ hội để học hỏi, điều chỉnh và tiến gần hơn tới giải pháp cuối cùng.
📌 Phát triển lặp không chỉ là cách làm, mà là một tư duy linh hoạt để thích nghi với thay đổi.
🔄 2. Phát triển lặp là gì?
Là phương pháp chia quá trình phát triển thành các vòng lặp nhỏ (iterations), mỗi vòng tập trung vào một phần nhỏ của giải pháp:
| Bước trong mỗi vòng lặp | Mô tả |
|---|---|
| Xác định | Chọn phần công việc cần làm (theo ưu tiên) |
| Lập kế hoạch | Phân bổ thời gian, nhân lực, tiêu chí hoàn thành |
| Phát triển | Thiết kế, lập trình, tạo nguyên mẫu, kiểm thử |
| Xem xét | Nhận phản hồi từ người dùng, PO, đội ngũ |
| Lặp lại nếu cần | Cải tiến, sửa lỗi, hoặc chuyển sang phần tiếp theo |
📅 3. Đặc điểm của vòng lặp Agile
- Thường có độ dài cố định (Timebox) từ vài ngày đến vài tuần
- Kết thúc mỗi vòng lặp là một phiên bản hoàn chỉnh nhỏ của sản phẩm (có thể demo, test, thậm chí triển khai thử)
- Gắn liền với khái niệm Inspect & Adapt: kiểm tra và thích nghi liên tục
💬 “Xây dựng phần mềm như điêu khắc đá – bạn không tạo ra kiệt tác ngay từ nhát đục đầu tiên, mà tạo nên nó từ hàng trăm lần chạm khắc.”
🧩 4. Ưu điểm của phát triển lặp
| Lợi ích | Giải thích |
|---|---|
| 🧠 Phát hiện sai sớm | Nếu sai, biết ngay trong vài ngày, không phải vài tháng |
| 🗣 Tăng cường tương tác | Người dùng có thể phản hồi sớm và thường xuyên |
| 🎯 Tập trung vào giá trị | Mỗi vòng lặp chọn việc quan trọng nhất để làm |
| 🧰 Cải tiến liên tục | Mỗi lần lặp là một cơ hội học hỏi |
| 🔄 Dễ thích nghi | Khi yêu cầu thay đổi, có thể điều chỉnh kế hoạch các vòng tiếp theo |
🏗️ 5. Phân biệt phát triển lặp và phát triển tuyến tính (thác nước)
| Tiêu chí | Phát triển Lặp (Agile) | Phát triển Tuyến tính (Waterfall) |
|---|---|---|
| Cách tiếp cận | Chia nhỏ thành vòng lặp | Một chiều, từng giai đoạn |
| Phản hồi người dùng | Mỗi vòng lặp đều có | Thường chỉ ở cuối |
| Độ linh hoạt | Cao – dễ thay đổi | Thấp – thay đổi rất khó |
| Tạo giá trị | Liên tục | Cuối dự án mới thấy kết quả |
| Khả năng sửa sai | Cao | Rất tốn kém nếu sai |
🧠 6. Khi nào nên dùng phát triển lặp?
- Khi yêu cầu chưa rõ hoặc dễ thay đổi
- Khi muốn phát hành sớm một phần chức năng
- Khi đội nhóm chấp nhận học từ sai lầm và cải tiến liên tục
📌 Các mô hình Agile như Scrum, DSDM, XP… đều đặt phát triển lặp là trung tâm.
✅ Tổng kết phần: Phát triển lặp
- Phát triển lặp là xương sống của Agile – giúp giảm rủi ro, nâng cao chất lượng và tập trung vào giá trị thực
- Mỗi vòng lặp là một vòng đời mini – có kế hoạch, thực thi, kiểm tra, cải tiến
- Thành công trong Agile không đến từ lần làm đầu tiên đúng – mà từ hàng loạt lần làm dần đúng hơn
💬 “Càng lặp sớm, sai càng ít.”
🧪 Tạo Nguyên Mẫu (Prototyping) – Cây cầu nối giữa ý tưởng và thực tế
🎯 1. Tại sao phải tạo nguyên mẫu trong Agile?
Trong quá trình phát triển phần mềm, nhiều yêu cầu không được hiểu rõ chỉ bằng lời nói hay tài liệu. Người dùng thường không thể tưởng tượng sản phẩm trông như thế nào cho đến khi… họ được nhìn thấy.
Đó là lúc Prototyping – kỹ thuật tạo mẫu thử ban đầu – phát huy sức mạnh.
📌 Tạo nguyên mẫu không phải là làm phần mềm thật – mà là tạo ra phiên bản đủ để nhìn thấy, tương tác và phản hồi.
🧱 2. Nguyên mẫu là gì?
- Là một phần chưa hoàn chỉnh của hệ thống, được tạo ra nhanh chóng
- Mục tiêu: hiểu rõ hơn yêu cầu, kiểm tra ý tưởng, khám phá giải pháp
- Có thể mang tính tạm thời (disposable) hoặc phát triển tiếp thành sản phẩm thật (evolutionary)
🧪 3. Các loại nguyên mẫu phổ biến
| Loại nguyên mẫu | Đặc điểm | Khi nào dùng |
|---|---|---|
| Trên giấy (paper prototype) | Vẽ tay giao diện, quy trình | Giai đoạn ý tưởng, brainstorming |
| Giao diện màn hình (screen-based) | Giao diện tĩnh hoặc có tương tác nhẹ | Kiểm tra bố cục, điều hướng |
| Nguyên mẫu kỹ thuật (technical / capability prototype) | Viết mã nhỏ kiểm thử công nghệ | Kiểm chứng framework, API, xử lý dữ liệu |
| Video thử nghiệm | Quay thao tác demo giải pháp | Trình bày ý tưởng cho khách hàng |
| Đóng vai (role-play) | Mô phỏng quy trình bằng hành động người thật | Mô hình dịch vụ, kịch bản nghiệp vụ |
🧠 Không phải nguyên mẫu nào cũng cần viết code!
🛠 4. Tạo nguyên mẫu như thế nào trong Agile?
Bước 1 – Xác định mục đích
- Bạn cần kiểm chứng điều gì?
- Giao diện có thân thiện không?
- Quy trình có hợp lý không?
- Công nghệ có khả thi không?
Bước 2 – Chọn loại nguyên mẫu phù hợp
- Nếu chưa rõ giao diện → dùng paper hoặc screen
- Nếu muốn thử kỹ thuật → làm spike hoặc prototype kỹ thuật
- Nếu có nhiều bên liên quan → workshop + đóng vai
Bước 3 – Tạo mẫu đơn giản nhất có thể
- Không cần hoàn chỉnh
- Tập trung vào phần nghi ngờ, cần xác minh
Bước 4 – Trình bày – Lắng nghe – Ghi nhận
- Không bảo vệ ý tưởng quá mức
- Tìm ra điểm sai để sửa – đó là lý do bạn tạo prototype
🔍 5. Phân loại nguyên mẫu theo mục tiêu
| Góc nhìn | Mục tiêu khi tạo mẫu |
|---|---|
| Chức năng (Functional) | Thử quy trình, hành vi hệ thống |
| Trải nghiệm người dùng (Usability) | Kiểm tra dễ dùng, điều hướng |
| Phi chức năng (Non-functional) | Kiểm tra thời gian phản hồi, bảo mật, giới hạn kỹ thuật |
📌 Một nguyên mẫu tốt sẽ giúp phát hiện lỗ hổng trước khi viết mã thật.
🧠 6. Nguyên mẫu kỹ thuật – Spike & Proof of Concept
- Spike: thử nhanh một đoạn mã để đánh giá khả thi
- Proof of Concept (POC): xây dựng mô hình nhỏ chứng minh công nghệ khả thi
Ví dụ:
Trước khi tích hợp ZaloPay, team làm spike gửi thử giao dịch từ backend tới sandbox API → từ đó quyết định dùng hay không.
💬 7. Đóng vai – Một hình thức nguyên mẫu mạnh mẽ
- Không cần code, không cần vẽ – chỉ cần kịch bản + con người
- Áp dụng tốt với các hệ thống có nhiều bước thủ công hoặc nhiều vai trò (ATM, bệnh viện, ngân hàng…)
Người dùng sẽ nói thật khi họ được “đóng vai” chính mình trong hệ thống.
✅ Tổng kết phần: Tạo nguyên mẫu
- Nguyên mẫu giúp hiểu đúng yêu cầu trước khi viết mã
- Có nhiều loại – không nhất thiết phải dùng công cụ phức tạp
- Trong Agile, tạo nguyên mẫu là cách rút ngắn khoảng cách giữa “ý tưởng” và “thử nghiệm”
- Prototyping + Feedback = sản phẩm tốt hơn, nhanh hơn, ít sai hơn
💬 “Thà sai sớm với nguyên mẫu – còn hơn sai trễ với phần mềm thật.”
🏗️ Chiến lược Phát triển Tiến hóa trong Agile – Từng bước đến giải pháp hoàn chỉnh
🎯 1. Phát triển tiến hóa là gì?
Là cách tiếp cận phần mềm không làm tất cả mọi thứ ngay lập tức, mà xây dựng từng phần nhỏ, lặp lại và cải tiến dần qua từng vòng lặp (iteration/timebox).
📌 Thay vì đợi hoàn chỉnh tất cả rồi mới ra mắt, bạn xây dựng phiên bản đầu tiên đủ tốt để dùng, sau đó phát triển thêm dựa trên phản hồi thực tế.
🧱 2. Ba chiến lược phát triển tiến hóa trong DSDM
🟦 1. Chiến lược Dọc (Vertical Strategy)
- Xây dựng trọn vẹn một chức năng từ đầu đến cuối
- Bao gồm giao diện, xử lý logic, lưu trữ dữ liệu, phản hồi
🧪 Ví dụ:
Trong app đặt lịch, làm hoàn chỉnh quy trình “Đặt lịch khám” trước: từ nhập thông tin → kiểm tra lịch trống → xác nhận.
🧠 Ưu điểm:
- Có thể trình diễn ngay một chức năng hoàn chỉnh
- Người dùng thấy kết quả sớm
- Thu thập phản hồi sâu về từng phần
🟨 2. Chiến lược Ngang (Horizontal Strategy)
- Tạo nguyên mẫu cho nhiều phần giao diện, nhưng chưa cần xử lý logic đầy đủ
- Ưu tiên khám phá trải nghiệm người dùng (UX), điều hướng, thiết kế
🧪 Ví dụ:
Làm xong giao diện “Đăng nhập”, “Đặt lịch”, “Trang cá nhân” nhưng chưa có backend xử lý.
🧠 Ưu điểm:
- Hiệu quả khi chưa rõ yêu cầu đầy đủ
- Giúp khách hàng hình dung toàn bộ hệ thống
🟩 3. Chiến lược Kết hợp (Combined Strategy)
- Kết hợp cả chiến lược dọc và ngang
- Bắt đầu bằng ngang → chọn 1 vài phần để phát triển theo chiều dọc
🧪 Ví dụ:
Đầu tiên, tạo các màn hình giao diện chính. Sau đó chọn “Đăng nhập” để phát triển đầy đủ (cả UI và xử lý).
🧠 Đây là chiến lược thực tế và phổ biến nhất, giúp:
- Có tầm nhìn tổng thể hệ thống (ngang)
- Có kết quả cụ thể để demo (dọc)
🧠 3. So sánh nhanh 3 chiến lược
| Tiêu chí | Dọc | Ngang | Kết hợp |
|---|---|---|---|
| Trải nghiệm người dùng | Trung bình | Cao | Cao |
| Tốc độ ra kết quả cụ thể | Cao | Thấp | Cao (tùy chọn) |
| Rủi ro kỹ thuật | Cao (nếu chọn sai phần đầu tiên) | Thấp | Trung bình |
| Phù hợp giai đoạn | Development | Khám phá | Cả hai |
🔍 4. Khi nào dùng chiến lược nào?
| Trường hợp | Nên dùng |
|---|---|
| Chưa rõ yêu cầu, muốn thử giao diện | Ngang |
| Muốn sớm có sản phẩm demo được | Dọc |
| Dự án lớn, có thời gian nhiều vòng lặp | Kết hợp |
📌 Agile không ép chọn 1 kiểu duy nhất – bạn có thể chuyển đổi giữa các chiến lược tùy từng giai đoạn.
✅ Tổng kết phần: Chiến lược Phát triển Tiến hóa
- Là cốt lõi trong cách làm Agile – xây dựng từng bước nhỏ nhưng chắc chắn
- Ba chiến lược:
- Dọc: làm hoàn chỉnh từng chức năng
- Ngang: khám phá toàn bộ hệ thống qua giao diện
- Kết hợp: chiến lược thực tiễn và linh hoạt nhất
- Mỗi chiến lược đều có ưu – nhược, và phù hợp với từng hoàn cảnh cụ thể
💬 “Agile không yêu cầu làm tất cả một lúc – mà giúp bạn làm đúng từng phần một cách thông minh.”
