Mở đầu — vì sao bài này quan trọng
Ở bốn bài trước, bạn đã hiểu BA là gì, rèn kỹ năng nền tảng, học cách moi requirements và viết tài liệu đầu tiên. Nhưng có một khoảng cách rất lớn giữa "biết lý thuyết BA" và "làm được việc BA trong một team thật". Khoảng cách đó chính là: bạn phải làm việc trong một quy trình (thường là Agile), dùng những công cụ (tools) mà cả team đang dùng, và có một cách thực hành hằng ngày để không bị "khớp" khi vào việc thật.
Đây là điều mà rất nhiều sinh viên mới ra trường bỏ qua. Họ đọc sách BA, biết viết user story, nhưng khi vào công ty thấy mọi người nói "sprint planning", "grooming", "ticket đang ở cột In Progress trên Jira" thì hoàn toàn ngơ ngác. Nhà tuyển dụng cũng biết điều này, nên trong phỏng vấn họ hay hỏi: "Em đã dùng Jira/Confluence chưa? Em hiểu Scrum hoạt động thế nào?". Nếu bạn trả lời trôi chảy, bạn đã hơn 70% ứng viên fresher khác.
Tin tốt là: nếu bạn từng là sinh viên làm đồ án nhóm, làm bài tập lớn, chạy deadline theo tuần — bạn đã có sẵn nhiều "phản xạ Agile" mà không hề biết. Bài này sẽ giúp bạn kết nối những kỹ năng sẵn có đó với công cụ và quy trình chuẩn của ngành, để bạn bước vào job đầu tiên với sự tự tin thật sự, chứ không phải sự tự tin giả tạo từ việc học thuộc.
Khái niệm cốt lõi
Agile và Scrum — hiểu bản chất, đừng học vẹt
Agile không phải là một công cụ hay một quy trình cứng. Agile là một cách tư duy: thay vì làm cả dự án khổng lồ trong 12 tháng rồi mới giao (kiểu Waterfall), team chia nhỏ công việc thành từng phần, làm nhanh, giao sớm, lấy phản hồi rồi điều chỉnh liên tục. Triết lý gốc nằm trong Agile Manifesto năm 2001, nhưng bạn chỉ cần nhớ tinh thần: ưu tiên phản hồi thực tế hơn kế hoạch cứng nhắc.
Scrum là cách phổ biến nhất để triển khai Agile, và là thứ bạn gần như chắc chắn sẽ gặp trong công ty Việt Nam. Scrum vận hành theo các chu kỳ ngắn gọi là sprint (thường 2 tuần). Trong mỗi sprint có các "nghi thức" (ceremonies) mà BA phải tham gia:
- Sprint Planning: đầu sprint, cả team ngồi lại chọn xem sprint này sẽ làm những gì. BA phải bảo đảm các user story đã đủ rõ để dev bắt tay vào code.
- Daily Standup: họp nhanh 15 phút mỗi sáng, mỗi người nói: hôm qua làm gì, hôm nay làm gì, có gì bị vướng (blocker). BA thường report tiến độ làm rõ requirements và gỡ vướng cho dev.
- Sprint Review: cuối sprint, team demo sản phẩm cho stakeholder xem. BA hay là người dẫn dắt phần demo hoặc giải thích tính năng.
- Retrospective (Retro): team nhìn lại sprint vừa rồi, cái gì tốt, cái gì cần cải thiện.
Backlog và cách công việc "chảy"
Toàn bộ danh sách việc cần làm của sản phẩm gọi là Product Backlog. Mỗi món việc trong đó thường là một user story hoặc một task. Đầu mỗi sprint, một phần backlog được kéo vào Sprint Backlog để làm. Công việc "chảy" qua các trạng thái: To Do → In Progress → In Review → Done. Hiểu được dòng chảy này giúp bạn biết chính xác vị trí của mình mỗi ngày: một cái story tôi viết đang nằm ở đâu, ai đang cầm nó, nó có bị kẹt không.
Bộ công cụ BA thực sự dùng hằng ngày
Bạn không cần biết hết mọi tool, nhưng bốn nhóm sau là bắt buộc phải quen mặt:
- Jira — công cụ quản lý công việc phổ biến nhất. Đây là nơi các user story, task, bug được tạo, gán người, theo dõi trạng thái. BA thường là người tạo và viết chi tiết các ticket.
- Confluence — "wiki" của team, nơi lưu tài liệu: BRD, đặc tả, biên bản họp, quyết định thiết kế. BA viết và cập nhật tài liệu ở đây.
- Công cụ vẽ diagram — như draw.io (miễn phí), Lucidchart, hoặc Figma. Dùng để vẽ flowchart, quy trình nghiệp vụ, sơ đồ luồng màn hình. Một BA giỏi diễn đạt bằng hình vẽ nhiều hơn bằng chữ.
- Bộ Office/Google Workspace — Excel/Google Sheets để làm ma trận requirement, quản lý danh sách; PowerPoint/Slides để trình bày.
Lợi thế "ẩn" của sinh viên mới ra trường
Quay lại điều tôi nói ở đầu: bạn có sẵn nhiều thứ. Làm đồ án nhóm chính là chạy một mini-sprint. Chia task cho từng thành viên chính là chia backlog. Họp nhóm mỗi tuần để cập nhật tiến độ chính là standup. Bạn quen với Google Docs, Google Sheets, quen dùng Trello để chia việc nhóm — đó chính là nền tảng để bạn học Jira/Confluence nhanh hơn người khác. Việc của bạn bây giờ là gọi tên lại những trải nghiệm đó bằng ngôn ngữ chuyên nghiệp.
Tình huống thực tế
Tình huống 1: Minh và cú sốc "sprint" đầu tiên tại một fintech ở TP.HCM
Minh, tốt nghiệp ngành Hệ thống thông tin, vào làm BA fresher tại một công ty fintech khoảng 60 người ở Quận 1. Tuần đầu tiên, Minh được thêm vào một dự án ví điện tử đang chạy Scrum sprint 2 tuần. Trong buổi Sprint Planning đầu tiên, PO nói: "Story VÍ-142, nạp tiền qua VNPay, ước lượng 5 point, ai nhận làm phần requirement?". Minh giơ tay nhưng không hiểu "5 point" nghĩa là gì, cũng không biết story đã "đủ rõ để dev làm" hay chưa.
Kết quả: story bị kéo qua giữa sprint mới phát hiện thiếu mô tả xử lý khi giao dịch thất bại. Dev phải chờ, sprint suýt trễ. Bài học Minh rút ra — và cũng là bài học cho bạn: trước Sprint Planning, BA phải làm refinement (làm mịn story) để mỗi story có đủ mô tả, acceptance criteria và các trường hợp lỗi. Sau lần đó, Minh tự lập một checklist "story đã sẵn sàng chưa" và dán ngay cạnh màn hình. Điều đáng nói: chỉ sau 3 sprint, Minh thành thạo nhịp Scrum, vì bản chất nó giống hệt cách cậu chạy đồ án tốt nghiệp — chỉ khác là chuyên nghiệp hơn.
Bài học rút ra: Agile không khó, nhưng bạn phải chủ động làm rõ story trước khi sprint bắt đầu, đừng đợi dev hỏi mới cuống.
Tình huống 2: Lan và Jira board rối như tơ vò tại một công ty e-commerce
Lan mới vào một công ty thương mại điện tử ở Hà Nội, được giao quản lý các ticket trên Jira cho tính năng "mã giảm giá". Ban đầu Lan tạo ticket kiểu tùy hứng: có ticket ghi mỗi dòng "Làm phần voucher", không mô tả, không gán ai, không đặt trạng thái. Sau một tuần, cả team không biết cái nào đang làm, cái nào xong, dev hỏi liên tục "story này ý em là gì?".
Scrum Master ngồi lại hướng dẫn Lan ba nguyên tắc: mỗi ticket phải có (1) tiêu đề rõ theo dạng "Là [người dùng], tôi muốn... để...", (2) phần mô tả chi tiết cộng acceptance criteria, (3) được gán đúng người và đúng trạng thái. Lan áp dụng, đồng thời dùng Confluence để viết tài liệu chi tiết rồi link từ Jira sang — Jira giữ ngắn gọn, Confluence chứa chi tiết. Chỉ hai tuần sau, board của Lan gọn gàng đến mức PM khen trong buổi Review.
Bài học rút ra: Tool chỉ mạnh khi bạn dùng có kỷ luật. Jira để theo dõi trạng thái, Confluence để chứa nội dung chi tiết. Đừng nhồi mọi thứ vào một chỗ.
Tình huống 3: Nhóm sinh viên biến đồ án thành "portfolio Agile"
Một nhóm bốn sinh viên năm cuối ở Đà Nẵng làm đồ án xây app đặt lịch phòng gym. Thay vì làm kiểu "code cho xong nộp thầy", một bạn trong nhóm — vốn muốn theo BA — đề xuất chạy dự án theo Scrum. Họ lập một board miễn phí trên Trello với các cột To Do / Doing / Done, chia đồ án thành 3 sprint mỗi sprint 2 tuần, mỗi sáng thứ Hai họp standup 15 phút qua Google Meet. Bạn BA viết user story cho từng tính năng, vẽ flow bằng draw.io, ghi biên bản họp trên Google Docs.
Khi đi phỏng vấn, thay vì nói "em có làm đồ án", bạn ấy kể: "Em điều phối một team 4 người theo Scrum, chạy 3 sprint, viết 18 user story, quản lý board và facilitate standup". Nhà tuyển dụng gật gù ngay. Bạn ấy được nhận vào vị trí BA fresher mà không cần kinh nghiệm đi làm thật.
Bài học rút ra: Bạn không cần một công việc thật để thực hành Agile và tool. Bạn cần một dự án — và cách kể lại nó bằng ngôn ngữ chuyên nghiệp.
Hướng dẫn từng bước
Đây là lộ trình để bạn tự trang bị năng lực "tools + Agile + thực hành" trong khoảng 3–4 tuần tự học:
- Nắm chắc vòng đời một sprint. Vẽ ra giấy chu kỳ 2 tuần với đủ 4 ceremonies (Planning → Daily → Review → Retro). Với mỗi ceremony, ghi rõ "BA làm gì ở đây". Học đến mức bạn kể lại được như kể chuyện.
- Tạo tài khoản Jira miễn phí. Atlassian cho phép dùng miễn phí tới 10 người. Tự lập một project mẫu, tạo vài user story, kéo qua các cột trạng thái, thử gán người, thử ước lượng story point. Chỉ cần một buổi chiều bạn sẽ hết sợ Jira.
- Làm quen Confluence (hoặc Notion nếu muốn). Viết thử một trang tài liệu: mô tả một tính năng đơn giản như "đăng nhập bằng số điện thoại", có phần mục tiêu, quy trình, acceptance criteria. Tập link từ Jira sang Confluence.
- Vẽ một flow trên draw.io. Chọn một quy trình đời thường bạn hiểu — ví dụ "đặt món trên GrabFood" — và vẽ luồng từ lúc mở app đến lúc nhận đồ ăn, có cả nhánh xử lý khi hết món. Đây là kỹ năng ăn điểm mạnh nhất khi phỏng vấn.
- Chạy một mini-project Agile thật. Rủ 2–3 người bạn, hoặc tự mình đóng nhiều vai, chọn một ý tưởng app nhỏ và chạy đúng một sprint 2 tuần: có backlog, có standup, có review. Ghi lại mọi thứ.
- Đóng gói thành câu chuyện. Viết lại trải nghiệm trên thành 2–3 dòng theo dạng "Tôi đã làm X, dùng công cụ Y, tạo ra kết quả Z". Đây là nguyên liệu vàng cho CV và phỏng vấn.
Lỗi thường gặp & mẹo
Lỗi 1: Học thuộc thuật ngữ mà không hiểu bản chất. Nhiều bạn đọc vanh vách "Scrum có 4 ceremonies" nhưng khi hỏi "vì sao cần Retro?" thì tắc. Nhà tuyển dụng phân biệt được người hiểu và người học vẹt ngay lập tức. Mẹo: với mỗi khái niệm, tự hỏi "nó giải quyết vấn đề gì?".
Lỗi 2: Nghĩ rằng phải thành thạo mọi tool. Bạn không cần biết 20 công cụ. Fresher chỉ cần vững Jira + Confluence + một công cụ vẽ + Excel/Sheets. Mẹo: ghi trong CV đúng những gì bạn thật sự dùng được, đừng liệt kê bừa rồi bị hỏi tủ.
Lỗi 3: Dùng Jira như một cái danh sách việc thô. Ticket không mô tả, không acceptance criteria khiến dev không làm được và làm bạn mất uy tín. Mẹo: áp dụng nguyên tắc "một ticket phải tự nó đủ rõ để người lạ đọc là hiểu".
Lỗi 4: Nhầm Agile là "làm bừa, không có kế hoạch". Agile linh hoạt nhưng vẫn rất kỷ luật. Mẹo: nhớ rằng linh hoạt là về phản hồi và điều chỉnh, không phải về sự lộn xộn.
Mẹo vàng cho sinh viên: hãy "Agile hóa" chính việc học của bạn. Chia mục tiêu học BA thành các sprint 2 tuần, mỗi cuối tuần tự Retro xem mình học được gì, cần chỉnh gì. Bạn vừa học nội dung, vừa sống trong tư duy Agile.
Bài tập thực hành
- Vẽ vòng đời sprint (30 phút): Vẽ tay chu kỳ một sprint 2 tuần đầy đủ 4 ceremonies, chú thích vai trò của BA ở từng bước.
- Dựng board Jira mẫu (1 buổi): Tạo tài khoản Jira miễn phí, lập project "App đặt lịch phòng gym", tạo tối thiểu 6 user story và kéo chúng qua các trạng thái To Do / In Progress / Done.
- Viết một trang Confluence/Notion: Chọn tính năng "đăng nhập bằng OTP", viết tài liệu gồm mục tiêu, luồng xử lý, acceptance criteria, và các trường hợp lỗi.
- Vẽ một business flow trên draw.io: Chọn quy trình "đặt món GrabFood" hoặc "chuyển khoản ngân hàng", vẽ đầy đủ nhánh chính và nhánh lỗi.
- Chuyển đồ án cũ thành câu chuyện Agile: Lấy một đồ án nhóm bạn từng làm, viết lại 3 câu mô tả nó theo ngôn ngữ Scrum/tool để dùng cho CV.
Tóm tắt
Bài này giúp bạn nối liền lý thuyết BA với thực tế làm việc qua ba trụ cột: Agile/Scrum (cách team vận hành theo sprint và các ceremonies), Tools (Jira để theo dõi công việc, Confluence để chứa tài liệu, công cụ vẽ để diễn đạt bằng hình, Excel/Sheets để quản lý), và thực hành (biến đồ án, mini-project thành sân tập thật). Điểm mấu chốt: bạn — một sinh viên mới ra trường — đã có sẵn nhiều "phản xạ Agile" từ việc làm đồ án nhóm; việc cần làm là gọi tên chúng bằng ngôn ngữ chuyên nghiệp và luyện tool đến mức tự tin. Qua ba tình huống của Minh, Lan và nhóm sinh viên Đà Nẵng, bạn thấy rõ: hiểu bản chất quan trọng hơn học vẹt, dùng tool có kỷ luật quan trọng hơn biết nhiều tool, và một dự án tự chạy có thể thay thế kinh nghiệm đi làm khi bạn kể nó đúng cách. Hãy bắt tay vào các bài tập ngay hôm nay — đó là bước biến bạn từ "người biết về BA" thành "người làm được BA".