Starting an Agile Project from Scratch: A Complete, Real-World Preparation Guide (Part 1)
Everything you need to start an Agile project right: frameworks, templates, pitfalls to avoid, and real-world case studies
Vào một ngày đẹp trời, bạn nhận được yêu cầu từ khách hàng mới
“Phía chúng tôi cần xây dựng một nền tảng bán hàng online. Hiện tại, chúng tôi chưa có tài liệu chi tiết, nhưng đại khái là cần hiển thị product, cho khách hàng đặt hàng và thanh toán một cách dễ dàng. Phần sau sẽ có thêm quản lý đơn, report, CRM,… À và đặc biệt chúng tôi cần hệ thống này ASAP trong vòng 2 tháng.”
Vậy là bạn có một project mới, timeline đã được dự kiến, nguồn lực đã được gán, nhưng thứ duy nhất bạn có trên tay là một mô tả sơ bộ thông qua một cuộc họp chỉ vỏn vẹn 30 phút hoặc thậm chí bạn họp xong và nhận nội dung trên qua email. Không có wireframe, không có workflow, không có business requirement hay design.
Thực tế thì trong rất nhiều công ty công nghệ, cả outsource lẫn product, đây là một điều hoàn toàn bình thường. Ở các giai đoạn khởi đầu, mọi thứ dường như là con số 0, việc cần một yêu cầu cụ thể là rất khó. Agile được lựa chọn chính vì tính linh hoạt, phản ứng nhanh và thích nghi tốt với sự mô hồ ban đầu như thế này.
Giải pháp không phải là chờ đợi tài liệu đầy đủ, mà là xây dựng một Agile Project Foundation đủ linh hoạt nhưng có hệ thống. Bài viết này sẽ hướng dẫn bạn từng bước một.
Phase 1: Pre-Project Preparation
1.1. Agile Project Charter
Một điều mà mình rút ra sau khi triển khai khá nhiều project đó là “không có định hướng chung”. Team nhảy vào design, vào backlog mà chưa trả lời được câu hỏi “Tại sao chúng ta làm project này?”.
Khác với Waterfall, Agile không yêu cầu bạn phải chuẩn bị một Project Charter dài 20 trang, mà chỉ cần một phiên bản ngắn gọn, linh hoạt nhưng mang tính định hướng rõ ràng cho team.
Thành phần cốt lõi bạn cần xây dựng với team của bạn gồm:
Project Vision & Mission - Product này tồn tại để làm gì? Giải quyết vấn đề gì cho ai? Ví dụ như website đơn giản, tối ưu tải nghiệm mobile-first.
Success Criteria - Khi nào chúng ta gọi là thành công, định nghĩa cụ thể ví dụ như MVP ra mắt trong 6 tuần, xử lý được ít nhất 30 sản phẩm và 2 phương thức thanh toán (COD + Momo).
Stakeholder & Roles - Ai là người quyết định, ai sẽ review, ai sẽ là người ảnh hưởng đến project.
Scope ban đầu + Limitations - Không ai ôm tất cả mọi thứ. MVP là gì? Cái gì sẽ làm trước, cái gì sẽ làm sau?
Assumptions & Risks - Giả định ban đầu? Rủi ro ở mức high-level nào cần đề phòng? Ví dụ như chúng ta có thể đánh giá behavior của customer như sử dụng chủ yếu từ mobile, tỷ lệ COD > thanh toán online. Risk có thể không tối ưu tốc độ và ảnh hưởng tới SEO & trải nghiệm mua sắm.
Timeline & Budget - Có deadline không? Release theo sprint hay một lần?
Thực tế, theo kinh nghiệm cá nhân của mình tất cả những điều trên không nên để một mình PM hay PO viết, mà hãy tổ chức 1 buổi workshop nhỏ với toàn bộ core team để cùng nhau định hình và thống nhất về chapter. Việc này giúp cả team hiểu rõ định hướng chung và mục tiêu của toàn bộ dự án.
1.2. User Story Workshop - Thu thập yêu cầu
Với bản thân mình, triển khai các project, ít bao giờ mình sẽ ngồi viết BRD chi tiết, dĩ nhiên nếu phía client họ có yêu cầu thì cũng nên có BRD, thay vào đó mình sẽ hướng tới User Story Workshop, nó sẽ giúp chúng ta đi thẳng vào trực tiếp vấn đề và các yêu cầu cụ thể từ khách hàng.
Hiểu đơn giản đây sẽ là buổi họp để trao đổi và breakdown từ những thứ high-level xuống thành các story chi tiết.
Người tham gia: Product Owner, Dev Team, UX, SME
Công cụ: Sticky notes, Miro, Figma hoặc whiteboard
Bắt đầu từ Persona → Role → Goal → User Stories
Thời gian: Khoảng 2-4 tiếng, nên chia theo các module như Checkout, Product, CMS.
Tư duy ở đây thay vì hướng về feature-centric thì hãy thay đổi thành user-centric, điều đó sẽ giúp các bạn đáp ứng chính xác yêu cầu người dùng.
Ví dụ thay vì hỏi “Bạn muốn tính năng gì?” thì hãy hỏi “Khi mua sản phẩm A bạn thường gặp khó khăn gì khi đặt hàng online?”, từ đó sẽ đưa ra được tính năng phù hợp.
Một ví dụ về case study, sau khi workshop nhóm đã xác định được 30+ user stories, được chia thành 3 nhóm Epic chính:
Mua hàng - duyệt sản phẩm, tìm kiếm, thêm vào giỏ, thanh toán
Quản lý đơn hàng - lưu thông tin đơn, trạng thái, email xác nhận
Quản lý nội dung - cập nhật sản phẩm, hình ảnh, giá cả.
Lưu ý các user story cần rõ ràng và có Acceptance Criteria và quan trọng nhất là Backlog ban đầu đủ để khởi động sprint đầu tiên, và trong quá trình triển khai thì vẫn có thể cập nhật hoặc xoá đi các yêu cầu.
1.3. Tổng kết cho Phase 1
Đừng nhảy vào ngay backlog mà không có vision chung. Mục tiêu của Phase 1 chính là tạo ra initial product backlog.
Output của Phase 1 sẽ là backlog dạng draft: từ persona → story → grouping → các ưu tiên hiện tai.
Giao tiếp thường xuyên với client hoặc PO trong workshop - vì đây sẽ giúp họ bắt đầu nhìn thấy product của chính họ.
Chuẩn bị sprint 0 để chuyển draft backlog thành backlog có thể triển khai được (Phase 2).
Phase 2: Sprint 0 - Thiết lập nền móng dự án
Sprint 0 sẽ là bước xây dựng móng (giống xây dựng) cho toàn bộ dự án Agile. Đây không phải là Sprint để phát triển các feature, mà là Sprint chuẩn bị, nơi bạn và team sẽ xác lập các yếu tố nền tảng: kỹ thuật, quy trình, vai trò, backlog và công cụ. Nếu bạn làm tốt Sprint 0, bạn sẽ tránh được 80% rủi ro và sự hỗn loạn trong Sprint 1 trở đi.
2.1. Mục tiêu chính của Sprint 0
Xác định tầm nhìn và scope dự án: thống nhất chúng ta đang giải quyết vấn đề gì, và đâu là giới hạn để tránh scope creep.
Thiết lập môi trường và công cụ phát triển: không ai viết được dòng code đầu tiên mà chưa có repo, CI/CD, staging server,…
Thiết kế kiến trúc kỹ thuật ban đầu: quyết định tech stack, hướng tổ chức backend/ frontend, khả năng mở rộng, tích hợp hệ thống, các 3rd party,…
Tạo product backlog sơ khởi: cần 1-2 Sprint đầu tiên đủ chín để đội dev có thể chủ động làm được
Định nghĩa Definition of Done (DoD) và Working Agreement: thống nhất output cụ thể và cách team sẽ làm việc với nhau.
Lập kế hoạch release đầu tiên (MVP plan): giúp khách hàng hiểu rõ thời điểm họ có thể sử dụng thử sản phẩm đầu tiên.
2.2. Một số điều cần quan tâm ở Sprint 0
Dưới đây là chia sẻ về kinh nghiệm thực tế của cá nhân mình trong giai đoạn sprint 0 này.
Product Vision: không nên chỉ là website bán hàng → cần ước lượng hoá được expectations như xử lý được 50 product, load < 1.5s, checkout không quá 3 bước.
Backlog sơ khởi không cần đầy đủ 100%, chỉ cần khoảng 8-12 story ready cho 1-2 sprint đầu.
Technical Architecture cần có ít nhất:
Sơ đồ kiến trúc hệ thống (Miro, draw.io)
Stack công nghệ
API endpoints (nếu có tích hợp với các system khác bên ngoài)
Team Charter càng cụ thể càng tốt, ví dụ:
Khi nào dùng Slack, khi nào call?
Ai được quyền merge code? Code review kéo dài bao lâu?
Giờ làm việc chung của team là khi nào?
Release Plan nên được vẽ thành timeline và hiển thị theo dạng value per sprint:
Sprint 1 → có thể hiển thị được product
Sprint 2 → thêm giỏ hàng + xem giỏ hàng
Sprint 3 → thanh toán + gửi email xác nhận
2.3. Tổng kết Checkpoint cho Phase 2
Cuối cùng thì vẫn nên có một checklist để theo dõi toàn bộ các công việc phase 2:
Xác định được đầy đủ toàn bộ Epics, có ít nhất 10 stories được xác định rõ ràng theo Epics.
Đã có môi trường dev/ staging/ test hoạt động.
CI/CD pipeline đã sẵn sàng.
Đội ngũ hiểu rõ vai trò, giờ họp, công cụ.
Release plan cho 2-3 sprint đầu đã xác định.
Product Owner và cả teeam đều hiểu rõ Definition of Done.
Sprint 0 là giai đoạn khá quan trọng để giảm sai sót, tăng hiệu quả cho các sprint sau. Đừng cắt giảm sprint 0 chỉ để làm nhanh, vì bạn sẽ trả bằng lỗi của product, hiểu lầm expectation và technical debt không đáng có.
Phase 3: Agile Project Kick-off
Sau khi đã xây dựng nền tảng trong Sprint 0, bạn cần tổ chức buổi Agile Project Kickoff - đây không chỉ đơn thuần là buổi chào hỏi mà là bước setup nhận thức chung về tầm nhìn, quy trình và tinh thần làm việc trong suốt quá trình phát triển.
Thực tế, bạn thấy mình nhắc tới mission và vision rất nhiều ở Phase 1 và Phase 2, điều này cho thấy tầm quan trọng của việc hiểu tại sao chúng ta làm project này, tất cả cần có chung về hướng đi và mục tiêu project.
Kick-off là cuộc họp cũng khá đơn giản nhưng cần đầy đủ các nội dung sau:
Giới thiệu team & vai trò → Ai làm gì, ai là PO, SM, Dev, QA?
Trình bày mục tiêu, phạm vi, KPI → Vision, success criteria, những gì cần làm trước - làm sau. Nhắc lại scope đã chốt trong Sprint 0 và MVP Plan
Giới thiệu quy trình Scrum → Sprint Planning, Daily Standup, Review, Retrospective → xác định sẽ tổ chức thời gian nào, họp với ai, ai host
Working Agreement → định nghĩa working-time, phản hồi email, flow xử lý lỗi, code review
Define Risk → những gì có thể gây chậm tiến độ: thiếu API, chưa rõ quy trình duyệt thiết kế
Next steps → bắt đầu sprint nào? có cần bổ sung task không? công cụ đã config chưa?
Nhìn chung đây sẽ là buổi chính thức, kiểu trình bày lại toàn bộ các phần đã chuẩn bị trong Project Charter và Sprint 0. Mục tiêu mình thường hướng đến đối với kick-off đó là giúp mọi người hiểu rõ vai trò, tránh chồng chéo và trách nhiệm mơ hồi, dev team nắm rõ luồng phát triển đầu tiên → triển khai Sprint 1 nhanh chóng. PO cảm thấy được đồng hành cùng team, không có cảm giác đợi báo cáo từ team.
Kick-off không chỉ là trình bày - mà tạo ra sự đồng thuận về tư duy và cách làm việc, giúp team tiết kiệm rất nhiều thời gian cho các sprint sau. Dù là team mới, dự án mới hay chỉ là giai đoạn mở rộng một tính năng quan trọng thì cũng nên tổ chức Kick-off meeting nhé.
Kết Luận
Agile không phải là một “phép màu” giúp bạn tạo ra phần mềm nhanh, gọn, lẹ khi mọi thứ đều mơ hồ. Agile chỉ thật sự phát huy sức mạnh khi bạn khởi động đúng - với một team hiểu vai trò của mình, một tầm nhìn chung rõ ràng, và một bộ khung chuẩn bị đầy đủ linh hoạt nhưng có hệ thống.
Key Takeways cho bài viết này:
Phase 1 giúp bạn trả lời câu hỏi “Chúng ta làm dự án này để làm gì?” và chuyển đổi các yêu cầu mơ hồ thành draft backlog có thể hành động được
Phase 2 - Sprint 0 là thời điểm để bạn xây móng - cả về kỹ thuật, tổ chức và quy trình - trước khi viết dòng code đầu tiên.
Phase 3 - Agile Kickoff đảm bảo rằng mọi người trong team cùng nhìn về một hướng, cùng hiểu luật chơi và sẵn sàng bước vào Sprint đầu tiên với tốc độ ổn định.
Bài viết tạm thời sẽ dừng tại đây, phần 2 mình sẽ nói về 3 phase còn lại bao gồm:
Phase 4: Vận hành Sprint đầu tiên & Thiết lập Scrum Process
Phase 5: Quản lý giao tiếp liên tục, quản lý thay đổi, quản lý rủi ro và kiểm soát kỳ vọng
Phase 6: Release MVP & Cải tiến sau từng Sprint
Kèm theo đó là các công cụ quản lý sprint, mẫu template mình sưu tầm và bài học rút ra sau các dự án thực tế.
Nếu bạn quan tâm hãy subscribe để nhận email thông báo khi có Part 2 nhé. Và nếu bạn thấy phần nào cần mở rộng sâu hơn (ví dụ: mô hình Dual-Track Agile, hay quản lý backlog khi client liên tục thay đổi yêu cầu), hãy để lại bình luận – mình sẽ chia sẻ thêm từ thực tế nhé.
Hướng dẫn quá chi tiết & có tâm luôn í, chị đọc thấy rất bổ ích vì em phải mất rất nhiều công để tổng hợp đc vậy