Kiến thức cơ bản cho người mới đi làm tại công ty phần mềm

Chương 1 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu Chương 1, hướng dẫn bạn cách học tập và kết nối với giảng viên trong suốt khóa. Trọng tâm là tham gia group Zalo hỗ trợ — nơi bạn đặt câu hỏi và xin thêm tài liệu khi cần. Điểm đáng nhớ: khóa học này khuyến khích bạn chủ động, đừng ngại hỏi khi chưa hiểu.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách tham gia group Zalo hỗ trợ bằng link hoặc QR code.
• Nắm được các "rule" cơ bản để học hiệu quả cùng giảng viên.
• Hiểu rằng bạn có thể yêu cầu thêm template, guide, checklist khi cần.

─── NỘI DUNG CHÍNH

▸ 1. Tham gia group hỗ trợ

Giảng viên tạo sẵn một group Zalo làm nơi hỗ trợ học viên. Bạn click vào đường link hoặc quét QR code, sau đó bấm tham gia nhóm là xong. Đây là kênh chính để bạn hỏi đáp trực tiếp trong quá trình học, nên hãy tham gia ngay từ đầu.

▸ 2. Vài quy tắc để học hiệu quả

Giảng viên đưa ra một số nguyên tắc đơn giản nhưng quan trọng:

1. Học tập nghiêm túc, đi qua từng bài một cách chỉn chu.
2. Đặt câu hỏi ngay khi có chỗ chưa hiểu, đừng để dồn lại.
3. Sử dụng template, guide, checklist mà giảng viên chia sẻ để áp dụng vào thực tế.

Ngoài ra, nếu trong lúc học bạn thấy thiếu hoặc cần thêm template nào, cứ hỏi — giảng viên sẽ giúp tạo thêm hoặc chia sẻ thêm template, checklist cho bạn.

Chương 1 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này cho bạn cái nhìn tổng quan về ngành gia công phần mềm (outsourcing): công ty kiếm tiền từ đâu, chi vào những gì, lợi nhuận ra sao, và tập khách hàng là ai. Từ bức tranh kinh doanh đó, giảng viên nói tiếp về định hướng nghề nghiệp và con đường thăng tiến cho người mới. Điểm mấu chốt: hiểu công ty vận hành thế nào sẽ giúp bạn chọn đúng hướng đi và biết mình cần bồi đắp năng lực gì. Giảng viên minh họa bằng một file Google Sheets để bạn dễ hình dung.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu nguồn thu, nguồn chi và cách tính lợi nhuận của công ty outsourcing.
• Phân biệt được ba loại hợp đồng phổ biến: OSDC, Fixed Price, Body Shopping.
• Hình dung được lộ trình thăng tiến theo hai hướng: kỹ thuật hoặc quản lý.

─── NỘI DUNG CHÍNH

▸ 1. Nguồn thu và ba loại hợp đồng

Outsourcing nghĩa là công ty nhận gia công một ý tưởng từ khách hàng, hoặc nhận lại đơn hàng từ một công ty IT khác (thường ở nước ngoài) rồi làm với giá thấp hơn để ăn chênh lệch. Có ba loại hợp đồng chính:

1. OSDC (Offshore Software Development Center): khách hàng trả tiền theo tháng, thường cho dự án maintain hoặc support sản phẩm đang chạy — nguồn thu ổn định.
2. Fixed Price: chốt cứng giá, thời gian và cost; lời ăn lỗ chịu, nên phải quản lý scope thật chặt và estimate cho chuẩn kẻo lỗ, đổi lại lợi nhuận cao hơn.
3. Body Shopping: cho thuê người sang làm ở công ty khách hàng, mình không quản lý công việc của họ.

▸ 2. Nguồn chi, lợi nhuận và tập khách hàng

Nguồn chi gồm lương, thuê văn phòng, máy móc, thiết bị, bảo hiểm xã hội... trong đó lương là khoản chi lớn nhất vì nhân công là yếu tố tối quan trọng của gia công phần mềm. Công thức đơn giản: lợi nhuận = thu − chi. Có hai tập khách hàng thường gặp: khách hàng có ý tưởng, và công ty IT khác nhận việc rồi tìm công ty Việt Nam gia công lại.

▸ 3. Định hướng nghề nghiệp: kỹ thuật hay ngoại ngữ

Với người mới, giảng viên chỉ ra hai lối phát triển: giỏi kỹ thuật (đi lên từ developer) hoặc giỏi ngoại ngữ. Ai kết hợp được cả hai sẽ hợp với vị trí BrSE (Bridge System Engineer — kỹ sư cầu nối), làm cầu nối giữa khách hàng và offshore team. Mẹo tăng lương: nhìn xem công ty đang thiếu gì (PHP, tiếng Nhật, tiếng Anh...) rồi bổ sung đúng thứ họ cần — giỏi thôi chưa đủ, phải khớp với kỳ vọng.

▸ 4. Các vị trí, level và lộ trình thăng tiến

Một số vị trí cơ bản: Senior Manager, Project Manager, Project Technical Leader, Configuration Controller, developer, tester, QA, QC và BA. Mỗi vị trí có nhiều level (thường 1 đến 6): level 1 ~ fresher (làm xong việc của mình), level 2 ~ junior (chỉ dẫn được team), level 3 ~ senior (xây bộ khung, lead team). Người mới thường nằm ở nhóm developer, tester hoặc QA. Từ đó chọn một trong hai hướng — kỹ thuật hoặc quản lý — rồi bám theo một lộ trình rõ ràng, đặt mốc thăng cấp (ví dụ 2 năm lên một level) và chuyên sâu vào lĩnh vực đã chọn. Đừng nghĩ đang làm tester thì không làm được BA: chuyển hướng là chuyện bình thường, miễn bạn chịu học.

Chương 1 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học điểm qua bộ thuật ngữ bạn sẽ gặp gần như mỗi ngày khi đi làm ở công ty outsourcing: từ cách quản lý dự án, ước lượng công sức, cho tới các loại tài liệu thiết kế và kiểm thử. Bạn không cần thuộc lòng tất cả, mà nên nắm được ý nghĩa của từng nhóm thuật ngữ để đọc tài liệu và trao đổi với đồng nghiệp không bị hụt hơi.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bốn yếu tố cốt lõi của một dự án và vòng lặp quản lý công việc PDCA.
• Đọc được các thuật ngữ về ước lượng, lịch trình và thiết kế mà không thấy xa lạ.
• Phân biệt được các mức test và các mô hình hợp đồng phổ biến trong outsourcing.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố dự án và vòng lặp PDCA

Mọi dự án phần mềm đều xoay quanh bốn yếu tố phải kiểm soát: scope (phạm vi công việc), time (thời gian), cost (chi phí) và quality (chất lượng). Đi kèm là vòng lặp làm việc plan – do – check – action (PDCA): lên kế hoạch, thực thi, kiểm tra, và khi phát hiện vấn đề thì phải có hành động khắc phục để quay lại đúng kế hoạch ban đầu.

▸ 2. Ước lượng, lịch trình và cấu trúc công việc

Nhóm này giúp bạn hiểu dự án được đo và chia nhỏ ra sao. Man-month (MM) là số người trên tháng — ví dụ 5 MM là 5 người làm trong một tháng. Master schedule là lịch trình tổng thể chia theo các phase (design, coding, test), còn detail schedule rã nhỏ từng task có ngày bắt đầu, kết thúc. WBS (Work Breakdown Structure) chính là việc rã nhỏ công việc đó. Ngoài ra có KLOC/LOC (ngàn dòng code), Function Point (FP) dùng để estimate, và effort efficiency so sánh billable, calendar và actual effort.

▸ 3. Tài liệu thiết kế và các mức kiểm thử

Tài liệu thiết kế đi từ mức ý tưởng (high level design), qua mức chức năng (function/basic design), tới mức chi tiết mà developer code được (detail/program design). Về kiểm thử có ba mức tăng dần: unit test (từng hàm), integration test (nhiều màn hình với nhau) và acceptance test – UAT (do chính người dùng thực hiện). Bạn cũng nên biết các mô hình hợp đồng: Fixed Price (lời ăn lỗ chịu), OSDC (thuê theo người theo tháng) và body shopping (bán người trực tiếp cho khách hàng quản lý).

Chương 2 · Bài 0

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu cho chương Bảo mật thông tin — một chủ đề tưởng khô khan nhưng lại là điều kiện tiên quyết khi bạn đi làm ở công ty phần mềm, nhất là môi trường outsourcing. Chương này chia thành hai phần: bảo mật thông tin trong công ty (bài 1) và bảo mật thông tin trong dự án (bài 2). Nội dung được trình bày trong một bộ slide đi kèm để bạn vừa xem video vừa đối chiếu.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được cấu trúc của cả chương và biết trước hai chủ đề sắp học.
• Biết cách mở tài liệu slide đi kèm để theo dõi song song với video.
• Sẵn sàng tâm thế xem bảo mật thông tin là trách nhiệm bắt buộc, không phải chuyện phụ.

─── NỘI DUNG CHÍNH

▸ 1. Chương bảo mật gồm những gì

Chương được tách làm hai bài. Bài 1 nói về bảo mật thông tin trong công ty — các nguyên tắc và sự cố ở phạm vi toàn công ty. Bài 2 nói về bảo mật thông tin trong dự án — những quy định cụ thể bạn phải tuân thủ khi đang tham gia một dự án. Cả hai cùng nằm trong một bộ slide xuyên suốt.

▸ 2. Cách mở tài liệu đi kèm

Giảng viên chuẩn bị sẵn một tài liệu hướng dẫn. Bạn có thể click vào link hoặc quét mã QR code trên slide để mở tài liệu này. Hãy mở nó ra trước khi sang các bài tiếp theo, vì các bài sau sẽ đi qua từng trang slide để giải thích chi tiết.

Chương 2 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đặt nền cho toàn bộ chương bảo mật: ba nguyên tắc cơ bản khi giữ tài sản thông tin, kèm những sự cố có thật đủ nghiêm trọng để khiến công ty mất khách, mất uy tín, thậm chí phá sản. Điểm mấu chốt đáng nhớ: hầu hết sự cố không đến từ công nghệ yếu, mà đến từ thiếu ý thức của từng nhân viên.

─── SAU BÀI HỌC, BẠN SẼ

• Thuộc ba nguyên tắc về mang và bảo vệ tài sản thông tin trong công ty.
• Nhận diện được các tình huống rò rỉ thông tin thường gặp để chủ động tránh.
• Biết quy trình xử lý một sự cố bảo mật và hình dung được hậu quả nếu vi phạm.

─── NỘI DUNG CHÍNH

▸ 1. Ba nguyên tắc cơ bản về tài sản thông tin

Có ba nguyên tắc phải nhớ. Thứ nhất, không mang tài sản thông tin ra khỏi khu vực làm việc — giấy tờ in ra liên quan dự án không được đem ra ngoài. Thứ hai, khi thật sự cần mang ra ngoài thì phải được cán bộ quản lý phê duyệt (PM, senior manager…). Thứ ba, khi mang ra ngoài phải có biện pháp bảo mật phù hợp — ví dụ laptop phải đặt mã BIOS, có username, password khi login.

▸ 2. Những sự cố bảo mật thường gặp

Giảng viên kể lại nhiều tình huống thực tế. Điển hình là rò rỉ dữ liệu từ FTP server: một dự án cũ quên tắt server, dự án khác biến nó thành proxy nối internet, và 100 GB dữ liệu khách hàng bị Google scan, phát tán khắp nơi. Các sự cố khác gồm: chạy script test nhưng gửi email vào môi trường thật; commit source của khách hàng lên GitHub cá nhân (điều tối kỵ); để nhân viên đã nghỉ vẫn nằm trong group mail nhận thông tin dự án; hay dùng font, account, phần mềm không có license.

▸ 3. Cách xử lý sự cố

Khi có sự cố, luôn làm hai việc: xử lý ngay lập tức để chặn thiệt hại, rồi điều tra nguyên nhân gốc rễ để ngăn tái diễn. Công cụ giảng viên khuyên dùng là 5 Why — hỏi "tại sao" nhiều lần cho tới khi tìm ra gốc vấn đề. Với sự cố rò rỉ, việc đầu tiên là thông báo cho khách hàng (tinh thần Horenso của Nhật — chia sẻ chứ đừng giấu), liên hệ Google nhờ gỡ, rồi nhờ QA rà lại quy trình.

▸ 4. Lưu ý quan trọng: hậu quả và ý thức

Hậu quả rất nặng: rò rỉ thông tin, ảnh hưởng uy tín, mất niềm tin khách hàng, tốn tiền bạc và thời gian xử lý; cá nhân có thể bị sa thải, công ty có thể phá sản. Vì công nghệ không thể chặn 100% rủi ro, điều quyết định nhất vẫn là ý thức của mỗi người khi động vào dữ liệu và source của khách hàng.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nếu bài trước là nguyên tắc chung của công ty, bài này đi vào những quy định cụ thể bạn phải làm khi đang ở trong một dự án: dùng máy tính, dùng thiết bị ngoại vi, giữ tài liệu mật, quản lý tài sản khách hàng, dùng mạng, phân quyền và xử lý sự cố. Điểm mấu chốt: bảo mật trong dự án là chuỗi thói quen hằng ngày, và khi có sự cố thì tốc độ phản ứng quan trọng hơn việc tự mình xử lý.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cấu hình chuẩn bảo mật cho máy tính và cách dùng thiết bị ngoại vi đúng quy định.
• Nắm quy trình quản lý tài liệu mật và tài sản của khách hàng.
• Biết cách phân quyền theo dự án và các bước bắt buộc khi xảy ra sự cố.

─── NỘI DUNG CHÍNH

▸ 1. Sử dụng máy tính và thiết bị ngoại vi

Máy tính (đặc biệt laptop hay mang ra ngoài) phải cài theo cấu hình chuẩn của công ty: đặt mật khẩu BIOS, đặt mật khẩu ổ cứng, mật khẩu login hệ điều hành, cập nhật Windows và antivirus thường xuyên, mã hóa dữ liệu (ví dụ TrueCrypt), và chỉ dùng phần mềm có license — tránh crack. Với thiết bị ngoại vi như USB, CD, ổ cứng ngoài: mặc định không được dùng, khi cần thì phải đăng ký, xin phép, và không lưu thông tin mật vào các thiết bị này.

▸ 2. Tài liệu mật và tài sản khách hàng

Tài liệu mật khi không dùng nữa phải hủy đúng cách: bản mềm thì xóa bằng công cụ IT cấp, bản cứng thì cho vào máy cắt giấy; hủy xong phải lập biên bản và chụp lại bằng chứng (trước – đang – sau khi hủy). Tài sản khách hàng cấp (đĩa CD, thiết bị test…) được quản lý theo quy trình: giao nhận → dán nhãn → sử dụng → bảo quản → trả/hủy, có mã QR để theo dõi và biên bản giao nhận mỗi lần mượn trả. Thiết bị nhỏ như thẻ nhớ nên cho vào túi zip hoặc hộp có dán nhãn, và kiểm kê định kỳ.

▸ 3. Tài nguyên mạng và phân quyền

Với mạng: không tự ý đổi cấu hình (IP, DNS, WAN), không chia sẻ tài liệu dự án qua folder share nội bộ (chỉ dùng file server chung), không dùng proxy/UltraSurf vượt tường lửa, và chỉ dùng email domain của công ty thay vì Gmail/Yahoo. Quyền truy cập được quản lý theo CMP (Configuration Management Plan): khi một thành viên rời dự án phải deny toàn bộ quyền của họ ngay; khi đóng dự án phải được QA verify trước khi IT thu quyền.

▸ 4. Xử lý sự cố và phê duyệt yêu cầu

Khi có sự cố, phải báo cho quản lý trực tiếp (ISMS team) trong vòng 2 tiếng, không tự ý xử lý theo cách của mình. Ví dụ máy dính virus hay thấy tài liệu bị tự upload: rút mạng, tắt nguồn ngay, rồi chụp evidence và nhờ bộ phận an ninh thông tin. Sau khi khắc phục phải truy nguyên nhân gốc rễ bằng 5 Why. Với việc phê duyệt đặc quyền (dùng USB, VPN, gửi free email…), leader phải đánh giá rủi ro, chỉ duyệt khi thực sự cần, và mọi đặc quyền đều phải giới hạn về thời gian và phạm vi.

Chương 2 · Bài 3 (phần 1)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu cho chủ đề tham khảo và sử dụng open source trong công việc. Trong ngành outsourcing, sản phẩm chủ yếu là source code, và developer rất hay lên mạng tìm mã nguồn mở để tham khảo — nhưng làm không đúng cách lại tiềm ẩn rủi ro bản quyền. Bài này giới thiệu ngắn gọn để bạn biết mình sắp học gì và mở đúng tài liệu đi kèm.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao việc dùng open source cần được nhìn nhận nghiêm túc trong outsourcing.
• Biết trước phần tiếp theo sẽ đi sâu vào license và cách dùng open source hợp lý.
• Biết cách mở tài liệu slide đi kèm để theo dõi song song với video.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao cần lưu ý khi dùng open source

Sản phẩm của công ty outsourcing phần lớn là source code. Khi gặp vấn đề, developer thường lên mạng tìm một open source rồi tham khảo, nhưng cách làm tùy tiện đó chưa hợp lý và có thể kéo theo rủi ro về bản quyền. Đây chính là lý do có cả một bài riêng để hướng dẫn dùng open source sao cho an toàn.

▸ 2. Cách mở tài liệu đi kèm

Giảng viên chuẩn bị một slide chi tiết cho chủ đề này. Bạn quét mã QR code hoặc mở link trên bài để đến đúng tài liệu. Phần chi tiết — các loại license và điều kiện sử dụng — sẽ được trình bày trong video ngay sau đó.

Chương 2 · Bài 3 (phần 2)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đi vào phần cốt lõi: open source và license là gì, các loại license phổ biến, và cách dùng chúng sao cho không dính rủi ro bản quyền khi làm outsourcing. Điểm mấu chốt đáng nhớ nhất: mỗi license ràng buộc bạn khác nhau — có loại bắt buộc phải công khai mã nguồn của bạn, nên chọn sai license có thể khiến toàn bộ source của khách hàng bị lộ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu open source luôn đi kèm một license và ý nghĩa của các quyền trong đó.
• Phân biệt được GPL và MIT — hai đầu đối lập về mức ràng buộc.
• Biết điều kiện, rủi ro và cách dùng open source an toàn trong dự án outsourcing.

─── NỘI DUNG CHÍNH

▸ 1. Open source và license là gì

Open source là mã nguồn mở được phê duyệt bởi tổ chức OSI, và mỗi open source chuẩn luôn đi kèm một license — như một giấy phép ghi rõ bạn được làm gì, không được làm gì. Nhìn chung các license đều cho phép: sửa đổi và dùng cho mục đích thương mại lẫn cá nhân, nhưng bắt buộc phải kèm license và thông tin bản quyền gốc trong sản phẩm của bạn. Tác giả cũng không đảm bảo và không chịu trách nhiệm nếu source có bug.

▸ 2. Phân biệt GPL và MIT

Bốn license thông dụng là GPL, Apache, BSD, MIT. Khác biệt lớn nhất nằm ở việc có bắt buộc công khai mã nguồn của bạn hay không. GPL là loại ràng buộc cao nhất: nếu dùng, sản phẩm của bạn cũng phải mở mã nguồn ra — nếu bạn giữ kín thì khi có tranh chấp, người ta vẫn có quyền yêu cầu bạn open source. MIT ngược lại, dễ dùng nhất, không bắt buộc mở source — nên trong nhiều dự án giảng viên khuyên ưu tiên MIT. Khi tạo repository mới trên GitHub, bạn sẽ thấy chỗ chọn license này và nên đọc kỹ từng loại.

▸ 3. Điều kiện và rủi ro khi dùng trong outsourcing

Khi làm outsourcing, trước khi dùng open source bạn nên xin xác nhận của PM hoặc Team Lead, rồi xin ý kiến khách hàng, và bảo đảm license đúng với policy của dự án. Rủi ro nếu làm ẩu rất nặng: mã nguồn có thể bị buộc công khai, bị phát hiện vi phạm bản quyền, công ty bị kiện, dừng hợp đồng, bồi thường, còn nhân viên có thể bị sa thải. Khách tìm đến outsourcing thường muốn một sản phẩm riêng, nên chuyện lộ bản quyền là điều tối kỵ.

▸ 4. Mẹo quan trọng: dùng open source cho an toàn

Cách dùng an toàn là đọc hiểu rồi viết lại theo hiểu biết của mình, đừng copy nguyên cả khối. Nếu buộc phải dùng, nên dùng trọn một package thay vì cóp nhặt một đoạn — vừa tránh khập khiễng, vừa dễ cập nhật khi tác giả thay đổi. Và nguyên tắc bao trùm: hạn chế dùng open source nếu không thật cần thiết, luôn xin phép trước khi dùng.

Chương 2 · Bài 4 (phần 1)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu cho chủ đề bảo mật thông tin khi tạo dữ liệu testing. Khi kiểm thử phần mềm, bạn cần dữ liệu để test — nhưng nếu dùng nhầm dữ liệu thật của khách hàng thì rất dễ gây rò rỉ thông tin. Bài này giới thiệu ngắn để bạn biết mình sắp học "dữ liệu test đúng chuẩn là như thế nào" và mở đúng tài liệu đi kèm.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao tạo dữ liệu testing cũng là một vấn đề bảo mật cần lưu ý.
• Biết trước phần tiếp theo sẽ hướng dẫn cách tạo dữ liệu test chuẩn chỉnh.
• Biết cách mở tài liệu slide đi kèm để theo dõi song song với video.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao dữ liệu testing cần được bảo mật

Trong quá trình kiểm thử, việc tạo dữ liệu test tưởng đơn giản nhưng lại liên quan trực tiếp tới bảo mật: dùng dữ liệu thật của khách hàng để test có thể khiến thông tin nhạy cảm bị lộ. Vì vậy bạn cần biết thế nào là một bộ dữ liệu test đúng và chuẩn chỉnh — đó chính là nội dung sẽ được hướng dẫn chi tiết ở phần sau.

▸ 2. Cách mở tài liệu đi kèm

Giảng viên chuẩn bị một slide riêng cho chủ đề này. Bạn click vào link hoặc quét mã QR code trên bài để đến tài liệu hướng dẫn về bảo mật thông tin khi tạo dữ liệu testing, rồi theo dõi cùng video tiếp theo.

Chương 2 · Bài 4 (phần 2)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi làm ở công ty outsourcing / ODC, việc tạo dữ liệu testing không chỉ là "gõ vài dòng cho có". Bài học chỉ ra các điểm dễ sai về bảo mật thông tin: dùng nhầm account, không phân biệt môi trường, tự ý đụng vào production. Điểm mấu chốt: bạn phải luôn tự hỏi dữ liệu này thuộc môi trường nào, account này có được phép thao tác không trước khi làm.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được 4 môi trường dev, testing, staging, production và biết luồng đi của dữ liệu qua từng môi trường.
• Nắm các quy tắc bảo mật khi tạo test data: đúng account, dữ liệu có ý nghĩa, không lộ tên công ty trong evidence.
• Biết cách xử lý những tình huống thực tế qua các case study về database chung, tái hiện bug, go-live và chụp evidence.

─── NỘI DUNG CHÍNH

▸ 1. Bốn môi trường và luồng dữ liệu

Một hệ thống thường có bốn môi trường: dev (development team dùng), testing (tester trong team), staging (gần giống production, thường dành cho khách hàng) và production (môi trường vận hành thật). Luồng đi tuần tự dev → test → staging → customer. Khuyến cáo quan trọng: development team chỉ nên deploy lên dev và test; staging nên nhờ khách hàng làm, còn production thì tuyệt đối không được đụng vào vì đó là dữ liệu thật của người dùng, rất nguy hiểm.

▸ 2. Các điểm lưu ý khi tạo test data

• Account: nếu bạn không có tên trong hợp đồng, phải cân nhắc account đang dùng có được phép thao tác không — đây là issue rất phổ biến của outsourcing.
• Dữ liệu phải có nghĩa: tránh ghi A, B, C hay chữ vô nghĩa; nếu để demo cho khách thì phải tạo chuẩn chỉnh.
• Evidence (ảnh chụp quá trình test): tuyệt đối không để lộ tên, logo công ty mình; tên khách hàng thì tùy yêu cầu.
• Lấy dữ liệu từ production để tái hiện bug: bắt buộc xin phép khách hàng, không tự lấy.
• Việc test lặp đi lặp lại (xóa rồi insert) nên viết script data thay vì làm tay cho đỡ mất thời gian.
• Phân quyền database rõ ràng: developer, tester chỉ nên có quyền read; và lưu lại UUID của từng thiết bị test để kiểm soát, tránh lộ thông tin.

▸ 3. Bốn case study thực tế

Bài đưa ra bốn tình huống để bạn tự suy nghĩ: (1) test chung database với khách hàng — phải phân rõ account ai được test gì, daily backup, báo khách khi test ảnh hưởng dữ liệu; (2) thiếu resource dựng staging — điều tra bug production qua file log và compare source; (3) khách hàng nhờ go-live — nên gửi guideline và không nhận trách nhiệm với production phức tạp (ví dụ kiến trúc AWS); (4) khách yêu cầu chụp evidence toàn bộ — nên chụp ở môi trường testing, chụp ở round 2 sau khi đã test xong, dùng tool như Snagit cho nhanh.

Chương 3 · Bài 1 (phần 1)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu chương 3 về báo cáo trong dự án. Bài giới thiệu ngắn gọn HORENSO — một quy tắc làm việc quan trọng của người Nhật, được ghép từ ba từ. Điểm cần nhớ: HORENSO không phải kỹ thuật cao siêu, mà là thói quen giao tiếp cơ bản mà bất kỳ nhân viên nào đi làm cũng cần có.

─── SAU BÀI HỌC, BẠN SẼ

• Biết HORENSO là viết tắt của ba từ tiếng Nhật và ý nghĩa từng từ.
• Hiểu vì sao đây được coi là kiến thức nền tảng khi làm việc tại công ty phần mềm, đặc biệt với khách Nhật.
• Sẵn sàng đi sâu vào từng thành phần của HORENSO ở bài tiếp theo.

─── NỘI DUNG CHÍNH

▸ 1. HORENSO là gì?

HORENSO là quy tắc làm việc quan trọng của người Nhật, ghép từ ba chữ:

• Houkoku — báo cáo
• Renraku — liên lạc
• Soudan — thảo luận (bàn bạc)

▸ 2. Tài liệu tham khảo và hướng đi tiếp theo

Trong slide có kèm một tài liệu tham khảo và một QR code — bạn có thể quét QR để mở link tài liệu. Ở video sau, giảng viên sẽ đi sâu giải thích chi tiết từng thành phần của HORENSO dựa trên slide và tài liệu tham khảo này.

Chương 3 · Bài 1 (phần 2)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài đi sâu vào ba thành phần của HORENSO — Houkoku (báo cáo), Renraku (liên lạc), Soudan (thảo luận) — cùng những nguyên tắc thực chiến khi làm việc với khách hàng, nhất là khách Nhật. Điểm mấu chốt: HORENSO là dòng chảy thông tin hai chiều, giúp mọi người cùng nắm tình hình để công việc trôi chảy. Báo cáo phải trung thực nhưng khéo léo, tin xấu báo càng sớm càng tốt, và luôn diễn đạt theo 5W2H.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu và vận dụng được ba nguyên tắc Houkoku, Renraku, Soudan trong công việc hằng ngày.
• Biết khi nào cần báo cáo, khi nào liên lạc, khi nào phải thảo luận — và trình bày mọi thứ theo 5W2H.
• Tránh được các lỗi tối kỵ như báo cáo mơ hồ, nói "tôi không biết", giấu tin xấu, hay thảo luận sai người.

─── NỘI DUNG CHÍNH

▸ 1. Houkoku — Báo cáo

Báo cáo là báo lại kết quả công việc được giao. Bốn nguyên tắc cốt lõi:

• Trung thực — nhưng phải suy nghĩ cách báo, không phải có gì báo nấy khiến người nghe lo lắng vô cớ; đây là việc một PM giỏi biết cân chỉnh.
• Tin càng xấu báo càng sớm — thấy nguy cơ trễ release thì phải cho khách nhận thức từ sớm, đừng để sát deadline mới nói "không kịp".
• Báo cáo trước khi được hỏi — nếu khách phải hỏi status, tức là báo cáo của bạn chưa đủ tốt.
• Trình bày theo 5W2H — báo cáo cái gì, cho ai, tại sao, khi nào, ở đâu, làm thế nào, tốn bao nhiêu.

Khi nào cần báo cáo: báo cáo giữa kỳ cho việc dài hạn, báo cáo định kỳ (weekly meeting), báo cáo khi hoàn thành, và báo cáo ngay khi có risk (rủi ro) hoặc issue (vấn đề đã xảy ra). Các công đoạn làm báo cáo: xác định mục đích → đối tượng → thời điểm → phương tiện → nội dung, rồi ghi kết quả, xác nhận lại, đánh giá ảnh hưởng, tìm nguyên nhân, ra hướng xử lý.

▸ 2. Renraku — Liên lạc

Liên lạc là chủ động chia sẻ thông tin cần thiết cho đúng người liên quan. Những lưu ý quan trọng:

• Nội dung cần độ chính xác cao hoặc dễ gây hiểu lầm (ví dụ đổi lịch release) phải liên lạc bằng văn bản / mail, có meeting và memo confirm — không chỉ nhắn một câu chat rồi trôi mất.
• Khi khách gửi thông tin ảnh hưởng nhiều người, chủ động forward cho các bên liên quan thay vì giữ riêng.
• Khi nghe khách nói dài, hãy tóm tắt lại và xác nhận ("Tôi hiểu như vậy đúng không?") để chắc chắn không hiểu sai.

▸ 3. Soudan — Thảo luận (bàn bạc)

Khi gặp vấn đề vượt khả năng, đừng ngồi tự giải quyết một mình. Thảo luận không chỉ để được giúp ngay, mà còn để mọi người có nhận thức về vấn đề và hỗ trợ gián tiếp. Nguyên tắc:

• Có điểm giới hạn thời gian: task 5 ngày thì khoảng 1,5 ngày, task vài tiếng thì 1/4–1/5 quãng đường mà không tiến triển là phải đi thảo luận — có dự án quy định chỉ 2 tiếng.
• Chọn đúng người: phải là người có kinh nghiệm và quyền quyết định, không phải người cũng mới như mình. Câu "em quyết định được không?" là để tìm ra người quyết, đừng khó chịu.
• Sau khi thảo luận xong, phải báo cáo lại kết quả cho người đã bàn với mình — vừa để họ biết lời khuyên có hiệu quả không, vừa là sự tôn trọng.

▸ 4. Quy tắc tối thiểu — những lỗi tối kỵ

Đây là phần đáng nhớ nhất. Không được trễ hẹn với khách (hẹn 11h thì 10h45 nên có mặt) — trễ là thất lễ lớn. Lỗi đơn giản không được mắc (comment sai ngôn ngữ, lỗi layout) vì khách sẽ nghi ngờ những lỗi nghiêm trọng hơn. Không báo cáo mơ hồ kiểu "hơi hơi trễ" — phải có số liệu. Và đừng bao giờ nói "tôi không biết, tôi không làm được" — hãy nói "vấn đề này tôi chưa có kinh nghiệm, cần khoảng 2 ngày điều tra, tôi báo lại sau".

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nhiều bạn mới vào công ty phần mềm chỉ cắm đầu làm task — coding, testing — mà không biết dự án mình đang làm là gì. Bài học chỉ ra vì sao bạn cần hiểu thông tin cơ bản của dự án và hợp đồng: chính những thông tin đó giúp bạn phán đoán và thực hiện công việc chính xác, trơn tru hơn. Điểm mấu chốt: giả định (assumption), ràng buộc (constraint) và version môi trường là những thứ bạn phải chủ động hỏi và confirm trước khi làm.

─── SAU BÀI HỌC, BẠN SẼ

• Biết một dự án thường có những thông tin gì: tên, ràng buộc, chức năng, giả định, loại hợp đồng, kích cỡ (MM).
• Hiểu qua một dự án demo gồm các sheet Cover, Record of Change, Project Information, WBS và cách đọc chúng.
• Nhận ra sự khác nhau giữa các loại dự án (mới / maintain, web / mobile, lớn / nhỏ, khách trong nước / nước ngoài) để điều chỉnh cách làm.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao cần biết thông tin dự án

Chỉ biết làm task thì view của bạn chưa đủ. Muốn action đúng, bạn cần hiểu thông tin về dự án, hợp đồng và loại dự án. Thường một raw developer / tester không tự truy cập được các file này, nhưng PM nên share cho bạn để bạn biết dự án là gì, làm như thế nào.

▸ 2. Đọc một dự án demo

Giảng viên mở một dự án demo (một bản báo giá mẫu — mỗi công ty mỗi khác) gồm các sheet: Cover, Record of Change, Project Information (loại dự án, khách hàng, tên, kích cỡ bao nhiêu MM, môi trường), giai đoạn phát triển, giả định, ràng buộc, điều kiện chấp nhận sản phẩm, và WBS (liên quan tới ngày, cost từng hạng mục). Đây chính là bức tranh tổng thể của một dự án.

▸ 3. Lưu ý quan trọng: giả định và version môi trường

Đây là phần dễ gây "toang" nhất. Phải đọc kỹ giả định để biết việc nào của mình, việc nào của khách hàng — không đọc thì làm sẽ không chính xác. Đặc biệt về môi trường: tài liệu chỉ ghi "SQL" mà không ghi version, bạn phải đi hỏi PM và confirm rõ ràng trước khi cài. Dân developer hay cài bản mới nhất, nhưng hệ thống lớn của khách thường chạy trên platform cũ — cài lệch version với server là hỏng cả công sức.

▸ 4. Phân biệt loại và kích cỡ dự án

Cách triển khai phụ thuộc vào loại dự án. Dự án maintain chú trọng test rất nhiều (mỗi lần thêm CR hay fix bug phải test toàn bộ tránh regression bug); dự án mới thì cách làm khác. Dự án lớn thì nhiều người mỗi người một việc, dự án nhỏ thì một người kiêm nhiều vị trí. Thêm nữa, văn hóa khách hàng người Việt và người nước ngoài cũng khác — tất cả những yếu tố nhỏ này cộng lại đều là thứ bạn cần biết, đừng nói "tôi không cần".

Chương 3 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Báo cáo là việc gần như ai đi làm cũng phải làm mỗi ngày. Bài học tập trung vào nguyên tắc và nội dung của một báo cáo tốt thay vì đưa một mẫu cứng nhắc — vì template thì mỗi công ty mỗi khác, bạn nên đi hỏi template của nơi mình làm. Điểm mấu chốt: một báo cáo đúng phải trả lời được hiện trạng, issue, tương lai, và phải có cả định lượng lẫn định tính.

─── SAU BÀI HỌC, BẠN SẼ

• Biết ba phần bắt buộc của một báo cáo: hiện trạng, vấn đề (issue) và hướng giải quyết, việc tiếp theo.
• Phân biệt và kết hợp được định lượng (số liệu) với định tính (nhận định, cảm nhận) trong báo cáo.
• Tránh được lỗi báo cáo cụt ngủn kiểu "hôm nay em làm task ABC" mà không có thông tin gì.

─── NỘI DUNG CHÍNH

▸ 1. Báo cáo cho ai, để làm gì

Trước khi viết, phải nhớ mình báo cáo cho đối tượng nào và báo cáo để làm gì. Khách hàng quan tâm tiến độ và issue của dự án; sếp hay PM lại quan tâm những thứ khác. Bạn phải điều chỉnh nội dung cho phù hợp với người nhận. (Bài này bổ trợ cho bài HORENSO trước đó.)

▸ 2. Ba phần trong nội dung báo cáo

Một báo cáo nên có ba ý chính:

1. Hiện trạng — công việc đang làm tới đâu (ví dụ "task ABC đang 50%"), có vấn đề gì không.
2. Issue và hướng giải quyết — nếu có vấn đề thì nêu hướng xử lý và deadline; chưa có thì ghi rõ "chưa có hướng giải quyết".
3. Tương lai — sau khi xong việc này bạn sẽ làm gì tiếp; nếu hết việc thì ghi rõ, để người quản lý biết mà sắp xếp.

▸ 3. Định lượng và định tính, và lỗi thường gặp

Báo cáo phải có định lượng — con số cụ thể (đọc 50/100 trang = 50%, viết 80 test case trong 4 tiếng, làm 5/10 tiếng = 50%) chứ không nói chung chung. Đồng thời có định tính — nhận định, cảm nhận của bạn (ví dụ "đang đúng tiến độ nhưng có issue phát sinh, tôi e sắp tới sẽ trễ"). Sau đó phải nhìn nhận vấn đề từ báo cáo, phán đoán và xử lý, và thể hiện ra được cho người khác hiểu chứ không giữ trong đầu. Lỗi phổ biến của người mới là báo cáo cụt ngủn "em đang làm task này", "study nghiệp vụ" mà không có phần trăm, không có issue — đó là cái sai cần bỏ. Trong công ty, người mới bị bắt gửi daily report mỗi ngày chính là để rèn kỹ năng này.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài giới thiệu một công cụ báo cáo rất thực dụng: meeting minutes (văn bản cuộc họp). Khi đi làm, không ai đúc kết sẵn cho bạn như thời đi học — mọi người thường nói "thao thao bất tuyệt", nên nếu không có kỹ năng ghi chép thì coi như thua. Điểm mấu chốt: mọi cuộc họp đều cần được ghi lại thành meeting minutes rồi log lên hệ thống quản lý và gửi cho các bên liên quan.

─── SAU BÀI HỌC, BẠN SẼ

• Biết một meeting minutes cần có gì: thời gian họp, thành phần tham gia, nội dung/agenda, kết luận và việc cần làm tiếp.
• Biết cách xử lý sau cuộc họp: tạo ticket trên Redmine/Jira với deadline, gửi minutes qua mail cho các bên.
• Áp dụng được cho cả daily meeting nội bộ lẫn weekly meeting với khách hàng (kèm dịch ngoại ngữ khi cần).

─── NỘI DUNG CHÍNH

▸ 1. Meeting minutes gồm những gì

Về cơ bản, một văn bản cuộc họp cần ghi rõ: cuộc họp diễn ra từ bao giờ tới bao giờ, những ai tham gia, và nội dung cuộc họp — gồm các hạng mục, đề mục đã thảo luận, kết luận là gì, và sau kết luận cần làm gì tiếp theo. Template mẫu trong bài khá đầy đủ, có các sheet như general, schedule, milestone, weekly, postmortem, export — nhưng bạn chỉ cần nhớ ba ý cốt lõi: nội dung cơ bản, người tham gia, agenda và kết luận.

▸ 2. Xử lý sau cuộc họp

Ví dụ với daily meeting: sau khi họp xong 15–20 phút, bạn ghi lại minutes (developer A làm task gì xong ngày nào, developer B làm gì xong khi nào) và chat lên group. Những công việc chưa có trên hệ thống quản lý thì tạo ticket trên Redmine, Jira... kèm deadline cụ thể. Với weekly meeting cùng khách hàng, làm tương tự nhưng phải dịch ra ngôn ngữ chính (tiếng Nhật với khách Nhật, tiếng Anh với khách nước ngoài), log record lên hệ thống và inform cho khách biết bạn đã log việc gì, phát sinh vấn đề gì.

▸ 3. Bước cuối: gửi văn bản sau cuộc họp

Sau khi hoàn thành meeting minutes (thông tin sơ bộ, người tham gia, nội dung — ai làm, khi nào xong, deadline), việc cuối cùng là cầm nguyên văn bản đó gửi qua mail cho khách hàng hoặc cho nhóm đã tham gia. Đó chính là "văn bản sau cuộc họp" — khép lại một vòng báo cáo trọn vẹn.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương 4 về các mô hình làm việc, bài giải thích Waterfall — mô hình thác nước, một trong những mô hình phổ biến nhất. Điểm mấu chốt: Waterfall làm tuần tự từng giai đoạn, output của giai đoạn trước là input của giai đoạn sau, và gần như không quay ngược lên. Hiểu ưu — nhược điểm của nó giúp bạn biết khi nào nên (và không nên) dùng.

─── SAU BÀI HỌC, BẠN SẼ

• Hình dung được luồng các giai đoạn của Waterfall: yêu cầu → thiết kế → coding → testing → deploy → maintain.
• Nắm ưu điểm (estimate cost chính xác) và nhược điểm (deliver chậm, sửa lỗi phức tạp) của mô hình.
• Biết rằng không có mô hình "tốt tuyệt đối" — phải chọn theo điều kiện và nhu cầu của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Waterfall vận hành thế nào

Waterfall là mô hình "thác nước" — dòng chảy đổ xuống và ít khi đổ ngược lên. Bạn nhận yêu cầu, làm tài liệu thiết kế, rồi mới coding, sau đó testing, rồi deploy lên môi trường thật và maintain. Nguyên tắc cốt lõi: phải làm xong hết một giai đoạn mới được sang giai đoạn sau, và output của giai đoạn trước là input của giai đoạn sau. Ví dụ dự án 5 màn hình thì phải thiết kế xong cả 5 mới được coding, coding xong cả 5 mới được test.

▸ 2. Ưu điểm và nhược điểm

Ưu điểm: cho góc nhìn tổng thể và đặc biệt là estimation rất chính xác — cost, chi phí được fix và thấy trước được hết. Đây là giá trị gần nhất mà Waterfall mang lại.

Nhược điểm: thời gian delivery sản phẩm rất lâu. Với dự án cỡ lớn (cả trăm, hai trăm màn hình), riêng khâu thiết kế đã mất mấy tháng mới tới coding, nên sản phẩm ra rất chậm. Khách hàng lại thường không hiểu tài liệu thiết kế — họ cần nhìn thấy sản phẩm thật chạy được. Ngoài ra khi có bug, việc truy vấn đề khá "mù": phải quay ngược về sửa tài liệu thiết kế rồi đi lại từ đầu, khá phức tạp.

▸ 3. Khi nào nên dùng Waterfall

Waterfall là mô hình cũ, và chính vì những nhược điểm trên mà người ta chuyển sang các mô hình khác sau này. Nhưng đừng nghĩ nó "không xài được" — trong một số dự án có điều kiện tiên quyết cần sự cố định về cost và phạm vi, Waterfall vẫn là lựa chọn bắt buộc và hợp lý. Mỗi mô hình đều có ưu, nhược điểm; bạn phải hiểu nó rồi cân nhắc điều kiện và nhu cầu của mình để chọn mô hình phù hợp.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

V-Model là một mô hình mở rộng của Waterfall, nhưng cụ thể hơn ở phần testing. Điểm mấu chốt cần nhớ: mỗi giai đoạn phát triển (từ requirement đến coding) đều ghép cặp với một loại test tương ứng, và mỗi loại test đó lại đi kèm một tài liệu thiết kế test riêng. Nhờ vậy quy trình có kỷ luật hơn, biết rõ hoàn thành file test nào thì chuyển sang việc nào.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu V-Model là bản mở rộng của Waterfall, chi tiết hoá phần testing thành nhiều loại test.
• Ghép được từng phase phát triển với loại test tương ứng và tài liệu test đi kèm.
• Nắm được ý nghĩa của việc chia nhỏ quá trình test thay vì chỉ ghi chung chung là "testing".

─── NỘI DUNG CHÍNH

▸ 1. V-Model — bản mở rộng của Waterfall

V-Model kế thừa toàn bộ tinh thần tuần tự của Waterfall, nhưng thay vì gói gọn công đoạn kiểm thử trong một chữ "testing", nó tách ra thành nhiều loại test khác nhau. Nhờ đó quy trình được định nghĩa chính xác hơn, có kỷ luật hơn: hoàn thành đến đâu, kiểm tra đến đó, biết rõ khi nào một file test được coi là xong để đi tiếp.

▸ 2. Mỗi phase ghép với một loại test và một tài liệu

Đây là ý cốt lõi của hình chữ V. Mỗi mức thiết kế ở nhánh đi xuống sẽ có một mức test tương ứng ở nhánh đi lên:

• Requirement Analysis ↔ Acceptance Test (kèm Acceptance Test Design).
• System Design ↔ System Test (kèm System Test Design).
• Kiến trúc / liên kết màn hình ↔ Integration Test (kèm Integration Test Design).
• Thiết kế chi tiết ↔ Coding rồi Unit Test (kèm Unit Test Design).

Phần giảng viên nhấn mạnh dùng nhiều nhất chính là góc dưới: dựa trên tài liệu thiết kế chi tiết để Coding, sau đó làm Unit Test, rồi lên Integration Test dựa trên tài liệu liên kết các màn hình. Mỗi loại test dẫn thẳng tới một file test, và mỗi file test gắn với một tài liệu thiết kế test tương ứng. Bài có kèm một đường link tham khảo để bạn xem sơ đồ V-Model rõ hơn.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Scrum — một framework chạy theo tư tưởng Agile — thay cho cách làm tuần tự của Waterfall/V-Model. Ý mấu chốt: thay vì làm hết cả trăm màn hình rồi mới giao, bạn bóc ra vài tính năng ưu tiên cao nhất, chạy trọn một vòng nhỏ (sprint) và giao cho khách hàng thấy ngay, rồi lặp lại để sản phẩm lớn dần. Toàn bộ các mô hình Agile đều phải tuân theo 4 tuyên ngôn và 12 nguyên tắc của Agile Manifesto.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Scrum là một framework hiện thực hoá tư tưởng Agile (giống Laravel là framework của PHP).
• Nắm được các thành phần cốt lõi: product backlog, Epic, user story, story point, sprint backlog.
• Biết vai trò từng người và các event chính: planning, daily meeting, Sprint Review, Retrospective.

─── NỘI DUNG CHÍNH

▸ 1. Agile và tư duy chia nhỏ để giao sớm

Agile chạy vòng lặp Plan → Design → Develop → Test → Deploy → Review → Launch. Thay vì làm một lần cả 100 màn hình, bạn chọn ra khoảng 5 màn hình ưu tiên cao nhất, giá trị nhất, cho vào một sprint, chạy xong là cho khách hàng thấy luôn. Scrum là framework cụ thể hoá cách làm này — nó define chi tiết các bước cần đi theo, giống quan hệ giữa ngôn ngữ lập trình (PHP) và framework (Laravel).

▸ 2. Backlog, story point và vai trò trong team

Từ ý tưởng sản phẩm, dự án tạo ra product backlog chứa các Epic và user story; mỗi story được gắn story point thể hiện độ lớn, độ nặng, độ giá trị. Bạn đánh trọng số để biết tính năng nào cần thiết nhất, rồi bóc khoảng 5 tính năng ưu tiên cao vào sprint backlog cho Development team làm. Trong nhóm Scrum có:

• Product Owner — chịu trách nhiệm về sản phẩm.
• Scrum Master — đảm bảo dự án chạy đúng quy trình, chỉ hỗ trợ chứ không có quyền cao như PM.
• Development team — thường 6–7 người, kỹ năng bằng nhau hoặc hỗ trợ được cho nhau, giữ nhóm nhỏ để chạy nhanh trong sprint ngắn.

▸ 3. Các event trong một sprint

Sau planning, cả team join vào chạy sprint theo đúng vòng design → develop → test → review → deploy. Mỗi ngày có Daily Meeting: mọi người đứng lên trả lời 3 câu — hôm nay đã làm được gì, sắp tới làm gì, có issue gì không. Kết thúc sprint có Sprint Review để review sản phẩm cùng khách hàng và stakeholder. Sau đó là Retrospective — nhìn lại toàn bộ vấn đề để cải thiện, đây chính là nơi rút ra Lesson learned.

▸ 4. Definition of Done và tăng trưởng dần

Trong khi chạy Scrum, team phải thống nhất Definition of Done — định nghĩa thế nào là "xong". Mỗi khi một item được coi là xong, sản phẩm lớn thêm một chút: tuần một xong màn hình một, tuần hai xong màn hình hai... cứ thế tăng dần (improvement) qua từng lần review. Cốt lõi của tất cả nằm ở 4 tuyên ngôn và 12 nguyên tắc của Agile — bài để sẵn link để bạn đọc từ trang gốc Agile Manifesto.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Thực tế hiếm khi một dự án chạy được thuần một mô hình. Bài học chỉ ra các yếu tố buộc ta phải pha trộn Waterfall và Scrum (cách làm hybrid): lấy ưu điểm của từng mô hình và tuỳ tính chất dự án mà kết hợp. Điểm mấu chốt là mindset: trong thực tế người ta dùng hybrid rất nhiều, không có công thức cứng nào áp cho mọi dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao áp cứng một mô hình (Waterfall hoặc Scrum) nhiều khi lại dở.
• Nhận ra các yếu tố ảnh hưởng: budget, năng lực team, scope thay đổi, kỳ vọng khách hàng.
• Hình dung được cách chạy hybrid: estimate kiểu Waterfall rồi chia nhỏ chạy Scrum.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao khó áp cứng một mô hình

Nếu muốn fix cứng một phương pháp, bạn thường không đủ điều kiện để làm đúng như nó đòi hỏi:

• Scrum khó chốt trước tổng chi phí vì nó "Welcome to Change" — thay đổi liên tục; đồng thời đòi hỏi team giỏi, cross functional (làm được việc của nhau, hỗ trợ nhau).
• Waterfall lại buộc phải biết trước budget, estimate và fix cứng rất nhiều, nên không hợp khi thay đổi nhiều.
• Thực tế nhiều công ty giá bán thấp, tuyển nhiều fresher/junior skill chưa đủ, dẫn tới cảnh một người giỏi "gánh" team còn lại vào hỗ trợ.
• Khách hàng luôn hỏi bao giờ xong, budget có đáp ứng không; scope liên tục thay đổi, chạy user test lại phát sinh bug, có khách hàng không hiểu hết mô hình.

▸ 2. Cách chạy hybrid trong thực tế

Vì các lý do trên, nhiều công ty làm hybrid — pha trộn hai mô hình. Ví dụ khi khách gửi yêu cầu, ở khâu estimation vẫn dùng Waterfall: estimate một phát cho cả dự án để khách thấy được độ lớn (ví dụ ~100 MM). Sau đó vào giai đoạn triển khai thì chia nhỏ theo Scrum: làm requirement đi trước, rồi chạy từng cục từng cục, triển khai daily meeting, giao cho khách hàng từng phần. Giảng viên không đi sâu từng bước vì với người mới vào công ty gia công thì khá khó — điều cần nhớ ở đây là mindset rằng hybrid thực sự tồn tại và được dùng phổ biến. Việc chọn mô hình nào phụ thuộc rất nhiều yếu tố, mỗi công ty/dự án một khác; bạn hãy chịu khó để ý và hỏi thẳng người quản lý dự án đang chạy mô hình nào, ở thời điểm nào, rồi tự điều chỉnh cho phù hợp.

Chương 4 · Bài 5 (phần 1)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần mở đầu chủ đề teamwork (làm việc nhóm) trong dự án. Giảng viên giới thiệu những điều bạn sẽ nắm được xuyên suốt bài: khái niệm làm việc nhóm, giai đoạn hình thành nhóm, cách tổ chức nhóm, và 7 kỹ năng cơ bản để làm việc nhóm hiệu quả. Điểm mấu chốt: làm việc nhóm tốt giúp bạn tạo uy tín, nâng cao trình độ bản thân và tăng hiệu suất công việc.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được bức tranh tổng thể của chủ đề teamwork sẽ học trong các phần tiếp theo.
• Hiểu vì sao kỹ năng làm việc nhóm gắn liền với uy tín và hiệu suất của bạn.
• Biết cần xác định đúng vị trí, vai trò của mình trong nhóm.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao teamwork quan trọng

Trong slide này bạn sẽ hiểu được khái niệm làm việc nhóm, giai đoạn hình thành nhóm, cách tổ chức nhóm, và xác định đúng vị trí, vai trò của mình trong nhóm. Nắm vững và vận dụng tốt kỹ năng này, bạn sẽ tạo được uy tín, nâng cao trình độ bản thân, đồng thời nâng cao hiệu suất công việc — đây là lý do teamwork được đặt thành một chủ đề riêng.

▸ 2. Những gì sẽ học tiếp

Bài có kèm một tài liệu tham khảo và QR code để bạn mở link tài liệu chi tiết. Nội dung cụ thể — đặc biệt là 7 kỹ năng cơ bản để làm việc nhóm hiệu quả — sẽ được trình bày kỹ trong phần tiếp theo (phần 2) của bài. Phần này chỉ đặt nền và giới thiệu, nên bạn hãy xem tiếp video sau để đi vào chi tiết.

Chương 4 · Bài 5 (phần 2)

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần đi sâu vào kỹ năng làm việc nhóm. Bài làm rõ nhóm (teamwork) khác đám đông ở chỗ nào, 4 giai đoạn hình thành nhóm, 7 nhóm người (cũng chính là 7 kiểu kỹ năng) trong một tổ chức nhóm, và quan trọng nhất là 7 nguyên tắc bắt buộc khi làm việc nhóm. Điểm mấu chốt: mỗi người là một mảnh ghép, phải chung sức ghép lại thì bức tranh dự án mới hoàn thành.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được nhóm (có mục tiêu, tổ chức, phân công) với đám đông, và nắm 4 giai đoạn hình thành nhóm.
• Nhận diện 7 nhóm người trong tổ chức nhóm để biết mình và đồng đội thuộc kiểu nào.
• Vận dụng được 7 nguyên tắc làm việc nhóm vào công việc hằng ngày.

─── NỘI DUNG CHÍNH

▸ 1. Khái niệm nhóm và 4 giai đoạn hình thành

Teamwork là tập hợp từ hai người trở lên, cùng tồn tại để hoàn thành một mục tiêu nhất định — khác với đám đông (tụ tập không mục tiêu). Nhóm có tổ chức, ổn định và phân công rõ ràng; chia thành nhóm không chính thức (tập hợp ngẫu nhiên để xử lý vụ việc đặc biệt rồi tách ra, như đội đặc nhiệm) và nhóm chính thức (ổn định, có tổ chức). Một nhóm thường trải qua 4 giai đoạn: hình thành (còn rụt rè, đi tìm vị trí của mình) → xung đột (tranh cãi, thiếu kiên nhẫn) → bình thường hoá (hiểu nhau, giảm xung đột, tăng hợp tác) → hoạt động trôi chảy (tin tưởng, phối hợp linh hoạt).

▸ 2. 7 nhóm người trong tổ chức nhóm

Hiểu 7 nhóm người cũng là hiểu 7 kiểu kỹ năng, để biết mình và đồng đội thuộc nhóm nào:

• Người lãnh đạo — tìm thành viên mới, phán đoán năng lực, tạo bầu không khí hưng phấn, lạc quan.
• Người góp ý — giám sát, phân tích, không bao giờ thỏa mãn với phương án kém hiệu quả.
• Người bổ sung — thiết kế thời gian biểu, lường trước rủi ro, hỗ trợ nhóm chạy trơn.
• Người giao dịch — hướng ngoại, tạo mối quan hệ với các nhóm/bên ngoài.
• Người điều phối — lôi kéo mọi người làm chung, nắm ưu tiên (thường là PM); phân biệt manager (thiên quản lý, điều phối) với leader (thiên tầm nhìn, cuốn hút), nhiều khi phải đảm cả hai role.
• Người tham gia ý kiến — góc nhìn lạc quan, cân bằng với người bi quan để nhìn vấn đề đủ hai chiều.
• Người giám sát — như role QA, giữ và theo đuổi tiêu chuẩn cao theo quy trình.

▸ 3. 7 nguyên tắc làm việc nhóm (phần quan trọng nhất)

Đây là các nguyên tắc bắt buộc phải có:

1. Lắng nghe — ưu tiên hàng đầu; nói nhiều quá không hay.
2. Chất vấn — biết đặt câu hỏi, đưa ra thảo luận; im lặng dễ bị hiểu là không hiểu.
3. Thuyết phục — bảo vệ ý tưởng bằng dẫn chứng, ưu/nhược điểm rõ ràng.
4. Tôn trọng — trên tinh thần win-win, không hạ người khác để nâng mình.
5. Trợ giúp — chủ động giúp khi ai gặp vấn đề, và dám giơ tay khi mình có issue.
6. Chia sẻ — chia sẻ cái hay của mình để cả nhóm cùng tiến bộ.
7. Chung sức — mỗi người là một mảnh ghép; ghép lại đủ thì dự án mới hoàn thành.

Đây là những kỹ năng rất cần thiết; ai còn thiếu thì nên chủ động học và luyện tập, vì thiếu chúng sẽ rất khó đi làm.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Coding convention (quy ước code) là tập hợp các nguyên tắc chung khi lập trình — cách đặt tên biến, tên hàm, file, class — nhằm giúp source code dễ đọc, dễ bảo trì và dễ sửa hơn. Điểm mấu chốt: nhiều bạn mới ra trường code ra được sản phẩm nhưng không biết quy ước, trong khi các công ty outsource/chuyên về lập trình lại rất chú trọng điều này, vì làm việc nhóm mà không có rule chung thì phát sinh vấn đề ngay.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu coding convention là gì và vì sao nó quan trọng khi làm việc nhóm.
• Biết những khía cạnh convention thường quy định: đặt tên biến, thụt lề, khoảng trắng.
• Biết cách áp dụng convention trong dự án: theo ngôn ngữ, theo công ty và confirm với khách hàng.

─── NỘI DUNG CHÍNH

▸ 1. Coding convention là gì và vì sao cần

Code convention tạm dịch là quy ước code — tập các nguyên tắc chung về cách đặt tên biến, hàm, file, class... để source code dễ đọc và dễ bảo trì. Bài này học để hiểu, không dạy cách code cụ thể. Rất nhiều bạn sinh viên/mới ra trường làm được sản phẩm nhưng khi hỏi convention là gì thì không trả lời được. Điều nguy hiểm nằm ở chỗ làm việc nhóm: nhiều người cùng code mà không có rule chung thì lập tức có vấn đề, nên các công ty chuyên nghiệp rất coi trọng việc này.

▸ 2. Convention quy định những gì

Một số điểm điển hình mà convention đề cập:

• Cách đặt tên biến — ví dụ dùng snake_case hay camelCase.
• Thụt lề và khoảng trắng — trình bày code cho nhất quán.
• Quy tắc đặt tên và quy ước về số lượng, cấu trúc khác tuỳ ngôn ngữ.

Lưu ý: mỗi ngôn ngữ lập trình có coding convention khác nhau, và mỗi dự án/công ty còn có thể đặt convention riêng.

▸ 3. Áp dụng convention trong dự án

Khi tham gia dự án, bạn cần: (1) hiểu rõ các quy tắc mà công ty/dự án đặt ra và tuân theo; (2) confirm với khách hàng — hỏi và xác nhận xem họ đồng ý với bộ convention này không. Nếu khách hàng chưa có quy tắc nào, hãy đề nghị dùng bộ chuẩn của ngôn ngữ lập trình đó rồi gửi cho khách hàng chốt. Bài có kèm link một tài liệu tham khảo bằng tiếng Việt; nội dung không khó, bạn có thể tự search thêm trên mạng hoặc xem ngay tại trang chủ của từng ngôn ngữ.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Checklist là danh sách các item cần kiểm tra, dùng chủ yếu cho việc self review — tự mình rà lại phần việc trước khi coi là xong. Điểm mấu chốt: khi team lead hoặc PM hỏi "làm sao em biết code của em tốt?", câu trả lời "em thấy nó chạy được" là chưa đủ. Checklist cho bạn một căn cứ rõ ràng để tự đánh giá và đảm bảo chất lượng trước khi giao.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu checklist là gì và vai trò self review trong quá trình coding.
• Biết một checklist coding thường gồm những trường thông tin và tiêu chí nào.
• Biết cách áp dụng hoặc đề xuất tạo checklist khi dự án chưa có.

─── NỘI DUNG CHÍNH

▸ 1. Checklist và self review

Checklist rất quen thuộc trong đời sống: bảng tích trong nhà vệ sinh (đã lau dọn chưa), bảng kiểm tra ở công trường, phiếu kiểm khi sửa xe... — đều là danh sách item cần kiểm tra. Trong coding, checklist dùng nhiều cho self review: tự nhìn lại phần việc của mình và tích vào từng mục. Nó giải quyết đúng câu hỏi khó: dựa trên cái gì để đảm bảo code của bạn ổn? Thay vì chỉ nói "code chạy được là được", bạn có một bộ tiêu chí để soi lại một cách có căn cứ.

▸ 2. Nội dung một checklist coding

Giảng viên mở một sample checklist (bằng tiếng Việt nên dễ đọc) gồm các trường như:

• Mã dự án, người tạo, ngày apply (ngày thực hiện).
• Người review (người xem lại) và ngày review.
• Mã màn hình, phiên bản tài liệu.
• Danh sách các câu hỏi kiểm tra ở dạng checklist để bạn xác nhận và tích vào.

Người ta thường đặt tiêu chí dưới dạng câu hỏi vì như vậy dễ hình dung hơn. Làm xong phần màn hình hay phần việc của mình thì bạn đánh (tích) vào các mục tương ứng.

▸ 3. Khi dự án chưa có checklist

Sample chỉ để minh hoạ ý nghĩa, không cứng nhắc — bạn có thể sửa lại các tiêu chí cho phù hợp với dự án. Nếu dự án của bạn chưa có checklist, hãy chủ động suggest team leader / technical leader / PM tạo ra một bộ checklist cho việc coding. Khi đã apply hết checklist tức là bạn có cơ sở để khẳng định phần việc của mình đã hoàn thành đạt chất lượng.

Chương 5 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Rất nhiều bạn mới ra trường vào công ty phần mềm bị "khớp" ngay ở khâu dùng Git: không rõ làm việc nhóm ra sao, đặt tên nhánh thế nào, commit ghi gì cho đúng. Bài học giới thiệu một bộ Git convention cơ bản mà giảng viên đang áp dụng trong nhóm của mình: mô hình Git Flow với các nhánh chuẩn, quy ước đặt tên và quy ước commit message. Điểm mấu chốt: đây là quy ước làm việc chung, không phải hướng dẫn từng câu lệnh Git — lệnh Git bạn tự tra thêm trên mạng vì đã có rất nhiều người viết.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vai trò các nhánh trong Git Flow: Master, Develop, Feature, Release, Hotfix.
• Biết quy ước tiền tố commit message: Feat, Fix, Docs, Style, Refactor, Test.
• Nắm cách đặt tên nhánh Feature/Release và ý nghĩa các môi trường Dev/Test/Staging/Production.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc nhánh theo Git Flow

Dự án thường phân cấp khoảng ba tầng nhánh. Master là nhánh chính (bản chạy thật), Develop là nhánh phát triển được tách ra từ Master. Tầng dưới có Feature (mỗi tính năng/màn hình một nhánh) và Hotfix. Luồng đi cần nhớ:

• Develop tách ra từ Master.
• Feature và Release đều tách ra từ Develop.
• Feature làm xong thì merge về Develop.
• Release xong thì merge về cả Develop và Master.
• Có sự cố trên bản thật thì tạo Hotfix từ Master, xong merge về cả Develop và Master.

Việc phân quyền cũng đi kèm: quyền trên Master/Develop thường thuộc PM, Technical, Team Lead; Dev làm việc trên nhánh Feature của mình.

▸ 2. Quy ước commit và đặt tên nhánh

Mỗi commit nên bắt đầu bằng một tiền tố thể hiện loại thay đổi: Feat (tính năng mới), Fix (sửa lỗi), Docs (tài liệu), Style, Refactor, Test. Nhánh Feature đặt tên kèm mã màn hình hoặc mã tính năng để nhìn là biết đang làm gì. Nhánh Release đặt tên theo quy ước gồm chữ Release + ngày/tháng/năm, giờ + môi trường release (ví dụ Test, Staging, Production).

▸ 3. Dùng convention này thế nào cho đúng

Đây là bộ quy ước để tham khảo, không phải luật cứng. Nếu nhóm bạn chưa có quy định nào, hãy lấy bộ này làm nền để commit và đặt tên cho nhất quán. Nếu nhóm đã có convention riêng, hãy tuân theo quy định của nhóm. Phần câu lệnh Git cụ thể (lấy source, tạo nhánh, pull/push) bạn tự tìm hiểu thêm — tài liệu trên mạng rất sẵn.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chia sẻ một quy trình coding hợp lý theo kinh nghiệm của giảng viên: nên code cái gì trước, cái gì sau, ai làm phần dùng chung, và làm sao để nhiều người cùng code mà không giẫm chân nhau. Trọng tâm là thứ tự và cách tổ chức công việc chứ không phải chi tiết framework hay ngôn ngữ cụ thể — vì phần đó phụ thuộc hoàn toàn vào tính chất từng dự án. Điểm mấu chốt đáng nhớ nhất: tích hợp liên tục (continuous integration) để tránh "ráp lại một phát là chết".

─── SAU BÀI HỌC, BẠN SẼ

• Biết luồng coding hợp lý: plan → dựng framework/library chung → code functional → đóng file.
• Hiểu vì sao phần common/database nên giao cho một người phụ trách để tránh conflict.
• Nắm nguyên tắc tích hợp liên tục thay vì để dồn đến cuối mới ghép.

─── NỘI DUNG CHÍNH

▸ 1. Bắt đầu bằng plan và phần dùng chung

Mở đầu là plan: lên kế hoạch bao nhiêu người tham gia, chiến lược code ra sao. Sau đó đừng lao vào code màn hình ngay — hãy dựng framework và các library/common trước. Những phần common là phần được tái sử dụng đi tái sử dụng lại, nhiều người cùng dùng, nên bắt buộc phải có sớm: coding library, model, validation, những gì chung nhất.

▸ 2. Quy định người phụ trách phần chung

Những phần liên quan tới database hoặc common nên thống nhất một người phụ trách, đừng để quá nhiều người cùng sửa. Nhiều người cùng xử lý một chỗ dùng chung sẽ dẫn tới conflict, chồng chéo nhau và mất khả năng support. Khi đang code functional mà thấy cần bổ sung phần common, hãy báo lên người phụ trách common/database; họ sửa phần chung trước, rồi bạn mới implement phần riêng của mình.

▸ 3. Mẹo quan trọng: tích hợp liên tục

Đây là từ khóa giảng viên nhấn mạnh. Nếu mỗi người tự chia nhỏ ra code riêng, code xong từng màn hình rồi để đến cuối mới ghép, thì lúc tích hợp rất dễ "chết" vì logic không khớp nhau. Thay vào đó: code xong function A thì tích hợp ngay, xong function B tích hợp, xong function C tích hợp — continuous integration. Đơn vị tích hợp là tính năng hay màn hình là tùy cách bạn phân loại, nhưng nguyên tắc chung là ghép sớm và ghép thường xuyên.

▸ 4. Tài liệu và kết thúc

Sau khi code, lý tưởng là tạo tài liệu hướng dẫn. Trên thực tế nhiều nơi bỏ qua bước này và chỉ comment source cho rõ ràng để dễ đọc lại. Cuối cùng, khi mọi thứ ổn thì đóng và kết thúc file code. Đây là quy trình theo kinh nghiệm — bạn có cách hay hơn thì cứ chia sẻ thêm.

Chương 6 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học làm rõ unit test là gì trong bối cảnh ngành outsourcing, và vì sao nó lại là khâu chiếm phần lớn công việc test. Có hai cách hiểu về unit test: test bằng code (viết code để test từng hàm, ví dụ JUnit) và test bằng file test case ở mức đơn vị màn hình. Điểm mấu chốt: trong outsourcing, unit test thường chính là file test case cho từng màn hình — kiểm tra để màn hình đó chạy được và chạy hết chức năng.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt hai nghĩa của unit test: test code (JUnit) và file test case mức màn hình.
• Hiểu vì sao ngành outsourcing hay dừng ở unit test mà ít làm integration test.
• Đọc được hai mẫu template test case: dạng list và dạng matrix.

─── NỘI DUNG CHÍNH

▸ 1. Unit test là gì

Unit test là việc kiểm tra ở mức đơn vị màn hình — trong hệ thống nhiều màn hình, mình kiểm tra từng màn hình nhỏ một. Ở mức code, viết code để test từng unit (hàm) nhỏ gọi là JUnit, đó cũng là unit test. Nhưng trong outsourcing mà giảng viên giới thiệu, unit test thường chính là file test case ở mức đơn vị màn hình. Theo lý thuyết developer nên tự test, nhưng thực tế developer thường code xong là hết giờ, nên khâu này hay do tester đảm nhận (tùy dự án).

▸ 2. Vì sao outsourcing chủ yếu làm unit test

Khi một công ty nhận hệ thống lớn, họ cắt nhỏ ra giao cho nhiều bên: ví dụ 100 màn hình chia thành từng cụm 20 màn hình cho các công ty khác nhau. Mục đích là tránh lộ ý tưởng tổng thể và tránh ai đó ráp lại được toàn bộ source. Hệ quả: bên nhận chỉ có phạm vi vài chục màn hình rời, nên unit test được nhưng integration test thì không (vì phần tích hợp với màn hình khác không nằm trong tay họ). Vì vậy unit test là khâu phải làm rất nhiều trong outsourcing.

▸ 3. Hai mẫu template test case

Khóa học kèm hai template. Template dạng list: mỗi test case một dòng, gồm mục đích, điều kiện tiên quyết, các bước thực hiện, kết quả mong đợi, rồi đánh trạng thái (Not yet / Not good / Cancel, hoặc Approve / đang review), có bug thì ghi bug lại. Cách đọc theo chiều trên xuống dưới.

Template dạng matrix (ma trận): các quan điểm giao nhau theo hàng và cột, đánh dấu Maru (dấu tròn) tại ô kiểm tra. Ví dụ input ký tự alphabet vào text box điểm thì kết quả xác nhận là không chấp nhận input. Cách đọc theo chiều trái sang phải, ghi kết quả test, ngày test, người test, ghi chú. Chọn dạng nào là tùy dự án; các kỹ thuật test chuyên sâu bạn tham khảo thêm ở phần riêng.

Chương 6 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trước khi viết test case, dân test chuyên nghiệp làm thêm một bước đi trước nữa: xác định point of view — các quan điểm test, tức những góc nhìn cần kiểm tra. Bài học mở đầu chương testing bằng cách giải thích vì sao phải liệt kê point of view trước, và minh họa bằng một sơ đồ XMind liệt kê hàng loạt quan điểm test cho giao diện. Điểm mấu chốt: có point of view rõ ràng thì viết test case không lan man, đúng tiêu chí team đề ra.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu point of view là gì và vì sao nó đi trước khâu viết test case.
• Biết các nhóm quan điểm cần kiểm tra: giao diện/control, dialog, validation, list view.
• Biết dùng mind map (XMind) hoặc Excel/Google Sheet để liệt kê quan điểm test.

─── NỘI DUNG CHÍNH

▸ 1. Point of view đến trước test case

Khâu testing có rất nhiều loại (unit test, integration test, system test, user acceptance test) và nhiều kỹ thuật (black box, white box, grey box, monkey test, stress test...). Với bất kỳ loại nào, việc đầu tiên là viết test case. Nhưng trước khi viết nội dung test, hãy xác định quan điểm test — mình sẽ nhìn hệ thống dưới những góc độ nào. Mỗi quan điểm được đánh mã (ví dụ POV 101, 102...) rồi cả team họp thống nhất: cái nào nằm trong point of view thì viết test case, cái nào không thì bỏ, nhờ vậy test đúng trọng tâm.

▸ 2. Các quan điểm kiểm tra giao diện

Với POV 101 – giao diện người dùng (GUI): verify app chạy trên nền tảng nào (Windows XP/7/10/11) và màu sắc tương ứng; kiểm tra mọi loại control (menu, submenu, icon, button, combo box, checkbox, text box, radio) về hình dạng, màu sắc, vị trí, kích cỡ, trạng thái, tiêu đề, mặc định collapse hay expand. POV 102 – dialog/confirm: kiểm tra vị trí, title, button, mặc định focus hay selected, thứ tự sắp xếp. Ngoài ra còn kiểm tra giá trị mặc định, default focus, alignment, và thao tác chuột/phím tắt/phím đặc biệt.

▸ 3. Quan điểm validation và list view

Nhóm validation là khó và phải test nhiều nhất: nhập giá trị bình thường, giá trị biên (một byte, hai byte), empty, trim, min length / max length / max value, input theo byte, copy-paste bằng Ctrl+C/Ctrl+V trên numeric box / text box / list view. Với form thì kiểm tra size, position, resize, double click, thanh cuộn. Với list view kiểm tra hành vi: default sort column, focus, data mapping có đúng không. Với integration test, quan điểm là test các function kết hợp, hành vi form chính, tình huống hệ thống sập, thay đổi processing/data phía hệ thống.

▸ 4. Công cụ liệt kê point of view

Vì danh sách quan điểm rất dài, hãy trực quan hóa bằng mind map (XMind) — bung ra hết các nhánh — hoặc dùng Excel/Google Sheet. List từng quan điểm ra, thống nhất với team, rồi mới bước sang viết test case.

Chương 6 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn thực hành tạo một unit test case cơ bản (UTC) từ một tài liệu chức năng cho sẵn. Giảng viên đưa link bài tập (tài liệu mô tả các màn hình) và link bài giải (file test case mẫu), rồi làm mẫu cách điền. Điểm mấu chốt: khi viết UTC, bạn dựa lại vào point of view ở bài trước để biết cần kiểm tra những gì, và luôn hỏi team lead mẫu chuẩn trước khi bắt tay viết.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách chuyển một tài liệu chức năng thành các test case ở mức màn hình.
• Biết điền test case theo template dạng ngang: step, điều kiện, phần xác nhận.
• Hiểu vì sao phải thống nhất mẫu và câu chữ với team trước khi viết.

─── NỘI DUNG CHÍNH

▸ 1. Đọc tài liệu chức năng đầu vào

Bài tập là một tài liệu mô tả các chức năng cơ bản của người dùng, gồm màn hình login, màn hình list, màn hình chỉnh sửa, và một bước xóa hiện hộp Yes/No. Lưu ý: tài liệu này ở mức function design (user requirements) — chỉ mô tả sơ. Ở mức detail design thực tế sẽ chi tiết hơn nhiều: validate bao nhiêu field, max length / min length bao nhiêu, loại input là gì. Bạn viết test case dựa trên mức tài liệu mình đang có.

▸ 2. Cách viết test case theo template

Với mỗi màn hình (theo mã màn hình), bạn copy layout qua template rồi kiểm tra từng mục một. Với template dạng ngang: cột step ghi từng bước (bước 1 làm gì, bước 2, bước 3, bước 4...), đến bước cần xác nhận thì chuyển sang phần xác nhận, và trong đó liệt kê đủ số điểm cần xác nhận (ví dụ 4 điểm thì ghi 4). Nội dung kiểm tra (giao diện, hiển thị mặc định...) lấy lại từ point of view đã lập ở bài trước — mở point of view ra và viết theo từng quan điểm. Làm xong màn hình 1 thì sang màn hình 2, viết tương tự.

▸ 3. Tổ chức file và vai trò team lead

Có hai cách tổ chức: viết tất cả trong một file, hoặc tách ra nhiều file / nhiều sheet — tùy nhu cầu dự án sao cho hợp lý. Trước khi viết, hãy hỏi người hướng dẫn / team lead hai điều: nên dùng template nào, và viết theo mẫu ra sao — nếu có mẫu thì đọc trước. Điều này đặc biệt quan trọng khi làm cho thị trường nước ngoài: câu chữ phải thống nhất thì khi dịch test case sang ngoại ngữ mới nhanh, nếu mỗi người viết một kiểu thì phải đọc hiểu lại rồi mới dịch được, rất mệt. Tóm lại: cách viết đơn giản, nhưng hãy bám point of view và nghe theo mẫu của team.

Chương 6 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi viết và chạy test case, bạn cần ghi lại kết quả — đó chính là Unit Test Report (UTR). Bài học giới thiệu file test report và một bug template đầy đủ để ghi nhận, phân loại và theo dõi bug. Điểm mấu chốt: mục tiêu của UTR là record và kiểm soát được toàn bộ trạng thái bug, biết rõ mỗi lỗi nghiêm trọng đến đâu, ưu tiên fix ra sao, ai fix, nguyên nhân từ đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu test report là gì và phân biệt với việc log bug.
• Điền được các trường của một bug hoàn chỉnh, biết vòng đời trạng thái bug.
• Phân biệt Severity (độ nghiêm trọng) và Priority (độ ưu tiên fix).

─── NỘI DUNG CHÍNH

▸ 1. Test report và hệ thống log bug

Khi bật màn hình lên test, kiểm tra và đánh kết quả vào file test case, thì file có kết quả đó gọi là test report — kết quả thực hiện test. Các bug tìm được nên được record lại. Lý tưởng là dùng một hệ thống quản lý lỗi DMS (Defect Management System) để log bug lên. Nếu không có hệ thống, bạn hoàn toàn có thể tự tạo file theo bug template để log — miễn kiểm soát được trạng thái bug là ổn.

▸ 2. Các trường của một bug hoàn chỉnh

Bug template gồm: loại Tracker và mã ID; Subject (mô tả lỗi); các bước tái hiện, kết quả đang bị lỗi và kết quả mong đợi. Cột Status đi qua vòng đời: bug mới → đang fix → đã fix → phản hồi → xếp/đóng bug, hoặc hủy (cancel) / pending. Thêm các trường: Assignee (ai fix), tác giả test, nguyên nhân gây lỗi, hành động khắc phục; nguyên nhân lỗi (bất cẩn, không hiểu requirement, thiếu training, other); defect type (coding standard, hard code, logic code, layout, other); QC activity (unit test, integration test, acceptance test, code review, document review) và role người test. Cuối cùng ghi ngày dự định fix, ngày fix thực tế và thời gian mất bao lâu. Trên hệ thống thì bug ID tự gen; làm bằng file thì bạn phải tự viết công thức.

▸ 3. Severity và Priority — đừng nhầm lẫn

Đây là hai trường dễ nhầm. Severity là độ nghiêm trọng của bug: Critical (ảnh hưởng lớn), Major, Minor, Trivial. Priority là độ ưu tiên fix. Hai cái không phải lúc nào cũng đi cùng nhau: lỗi Layout chẳng hạn không làm chết chương trình nên Severity chỉ Minor, nhưng vì nó là "bộ mặt" với khách hàng nên Priority lại cao. Nắm được cách phân loại này giúp bạn báo bug đúng mức độ và fix đúng thứ tự. Nếu muốn xem một quy trình log bug đầy đủ, giảng viên có để link tham khảo trên website trong slide.

Chương 7 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

CI/CD là cách để mỗi lần developer commit code, hệ thống tự động build, test và đưa lên môi trường thật — thay vì làm thủ công từng bước. Bài học giải thích ngắn gọn hai khái niệm CI (Continuous Integration) và CD (Continuous Delivery), để bạn hiểu vì sao chúng giúp tăng chất lượng source code và tiết kiệm rất nhiều thời gian, chi phí cho dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được CI và CD, và biết mỗi giai đoạn tự động hoá những gì.
• Hình dung được luồng đi của source code từ lúc commit đến khi release ra môi trường thật.
• Biết một vài công cụ CI/CD phổ biến để tự tìm hiểu và thử cấu hình.

─── NỘI DUNG CHÍNH

▸ 1. CI — Continuous Integration

CI lo phần tích hợp — build — test ngay khi có code mới. Khi developer commit một version source code lên, hệ thống tự động: phân tích code, chạy unit test (test từng hàm), rồi chạy functional test (test theo chức năng của màn hình/tính năng). Kết quả là một báo cáo cho development team biết code hiện tại đạt hay không đạt chất lượng, để sửa lại. Toàn bộ quá trình này là tự động.

Ý nghĩa lớn nhất: nếu developer code xong mà không có test nào, cũng không ai review, đó là điểm yếu rất nguy hiểm. CI chính là "lưới an toàn" tự động bắt lỗi sớm.

▸ 2. CD — Continuous Delivery

CD lo phần deploy — vận hành (operate) — đo lường (measure). Sau khi code qua được vòng build + unit test, hệ thống tự động deploy lên môi trường test, chạy tiếp User Acceptance Test (test case của khách hàng). Vòng lặp feedback cứ lặp cho tới khi mọi thứ ổn; user chỉ cần test lần cuối và approve một phát là release ra môi trường thật.

▸ 3. Vì sao đáng đầu tư (và một lưu ý thật lòng)

Tưởng tượng: developer chỉ cần commit một lần, mọi thứ còn lại tự động chạy hết. Đó là lý do CI/CD giúp tăng chất lượng source code và tiết kiệm thời gian, chi phí. Một số công cụ đáng tham khảo: Jenkins, GitLab CI. Lưu ý thật lòng của giảng viên: cấu hình CI/CD không dễ, nhưng cũng không quá khó — chịu khó nghiên cứu là làm được, và rất đáng để thử cho dự án của bạn.

Chương 7 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Quality Report là báo cáo chất lượng của một dự án phần mềm, dựa trên các chỉ số (quality metric) đo được trong quá trình làm việc. Bài học giải thích cách một dự án dùng bộ chỉ số chuẩn — gọi là norm — để biết source code, test case và bug của mình có nằm trong vùng chất lượng cho phép hay không. Điểm mấu chốt cần nhớ: mỗi công ty có chuẩn riêng, và một chỉ số quá cao hay quá thấp so với norm đều là dấu hiệu bất thường, cần tìm nguyên nhân.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Quality Report dùng để làm gì và vì sao không phải công ty nào cũng dùng chung một chuẩn.
• Đọc được các thuật ngữ metric cơ bản: norm, KLOC (một ngàn Line Of Code), bug rate, Effort Efficiency, Timeliness.
• Biết cách so một chỉ số thực tế với norm để phán đoán một màn hình/chức năng đạt hay không đạt chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Norm và vùng chất lượng cho phép

Norm là bộ chỉ số cơ bản để đo chất lượng. Mỗi chỉ số có một mức trung bình, một cận trên và một cận dưới; nằm giữa hai cận là đạt. Ví dụ với bug review code: 1000 line of code bắt được khoảng 15 bug là bình thường; bắt nhiều hơn cận trên nghĩa là chất lượng sản phẩm kém, còn bắt ít hơn cận dưới lại là dấu hiệu người review làm không hiệu quả. Tương tự cho số test case, bug UT, bug IT, bug UAT — cái gì vượt chuẩn đều đáng nghi.

▸ 2. Các chỉ số hay gặp

Bài giới thiệu nhiều thuật ngữ của ngành outsourcing: dự án OSDC (thanh toán theo tháng) so với Fixed Price (chốt tiền một lần); Billable là effort khách hàng trả, so với người thực tế load vào dự án để tính Effort Efficiency; Timeliness đo việc deliver có đúng hạn không. Bạn không cần thuộc lòng mọi công thức — quan trọng là hiểu mỗi chỉ số phản ánh một khía cạnh chất lượng.

▸ 3. Cách áp dụng để đánh giá từng màn hình

Với mỗi màn hình, bạn lấy số line of code, số test case, số bug thực tế, tính ra tỉ lệ, rồi so với norm. Ví dụ màn hình Login có mật độ 8.1 bug, nằm trong vùng cho phép nên vẫn đạt. Nếu một chức năng không đạt, phải kiểm tra lại xem lỗi nằm ở đâu: test case quá ít, chất lượng test có vấn đề, hay chính source code có vấn đề. Đó là cách dùng Quality Report để đánh giá chất lượng dự án một cách khách quan.

Chương 8 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi bắt đầu đi xin việc, thứ đầu tiên bạn cần là một hồ sơ thể hiện được kinh nghiệm của mình. Ngoài file CV, giảng viên giới thiệu LinkedIn như một nền tảng rất hiệu quả: bạn tạo một tài khoản, đưa toàn bộ thông tin lên đó để nhà tuyển dụng chủ động tìm thấy và kết nối với bạn. Điểm mấu chốt: một profile đầy đủ và chỉn chu sẽ tự thu hút HR, người tuyển dụng và đồng nghiệp cùng ngành connect tới bạn, mở rộng cơ hội việc làm mà không cần bạn đi mời từng người.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao một profile LinkedIn tốt lại giá trị ngang, thậm chí hơn, một file CV tĩnh.
• Biết cần đưa những thông tin nào lên profile để thể hiện sự chuyên nghiệp.
• Biết cách tự học hoàn thiện LinkedIn qua các video hướng dẫn sẵn có.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao nên có LinkedIn

Giảng viên chia sẻ từ góc nhìn người trực tiếp tuyển dụng: mỗi ngày nhìn rất nhiều hồ sơ. Một profile LinkedIn cho phép bạn "gói" tất cả kinh nghiệm lên một nơi để người khác nhìn vào là hiểu ngay bạn có năng lực gì — thuận tiện hơn nhiều so với chỉ gửi một file CV. Khi profile của bạn đẹp và đầy đủ, người tuyển dụng thích hơn và sẽ chủ động tìm đến.

▸ 2. Những gì nên đưa lên profile

Hãy điền đầy đủ các mục quan trọng:

• Kinh nghiệm làm việc: từng làm gì, ở đâu.
• Học vấn: học trường nào.
• License / bằng cấp: đưa hết các chứng chỉ bạn có vào để tăng độ tin cậy.
• Skill: liệt kê rõ những kỹ năng và môi trường bạn từng làm.
• Kết nối: tham gia các nhóm, company, following phù hợp với ngành.

Mỗi mục chỉ cần click để thêm, không có gì khó.

▸ 3. Kết nối và tự học hoàn thiện

Sau khi profile hoàn chỉnh, hãy connect với những người bạn quen biết; từ đó bạn lại biết thêm nhiều mối quan hệ khác trên thị trường tuyển dụng. Nguyên tắc của giảng viên là không làm lại những gì đã có sẵn: chỉ cần lên YouTube gõ "hướng dẫn tạo LinkedIn chuyên nghiệp" là ra rất nhiều video chi tiết. Về bản chất các hướng dẫn đều giống nhau — tạo tài khoản, rồi cứ theo gợi ý "add thêm..." mà bấm và điền cho đủ là bạn có một hồ sơ hoàn chỉnh.

Chương 8 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn bạn tạo một CV chuyên nghiệp bằng Canva hoặc Google Sheets, rồi chia sẻ để nhà tuyển dụng dễ tiếp cận. Điểm mấu chốt không nằm ở mẫu đẹp, mà ở chỗ CV phải liền mạch về thời gian và được chỉnh riêng cho từng vị trí ứng tuyển — đây là hai lỗi khiến ứng viên bị đánh giá thấp nhất.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được một CV hoàn chỉnh từ template Canva hoặc mẫu Google Sheets.
• Biết một CV cần có những mục nào và cách trình bày kỹ năng cho thuyết phục.
• Tránh được hai lỗi phổ biến: khoảng trống thời gian (gap year) và CV "gì cũng biết".

─── NỘI DUNG CHÍNH

▸ 1. Tạo CV bằng Canva

Vào Canva, tạo thiết kế mới, gõ "Resume" hoặc "CV" để ra kho template. Chọn một mẫu bạn thấy phù hợp về màu sắc, phông chữ, rồi chỉ việc replace ảnh và thông tin của mình vào. Một CV cơ bản nên có: ảnh, thông tin cá nhân (tên, vị trí muốn ứng tuyển, điện thoại, email, địa chỉ), phần giới thiệu bản thân, và phần kinh nghiệm (học ở đâu, làm việc ở đâu, skill). Với skill, bạn có thể chấm thang điểm hoặc dùng thanh mức độ — miễn sao thể hiện rõ khả năng.

▸ 2. Tạo CV bằng Google Sheets

Nếu thông tin của bạn nhiều và muốn trình bày chi tiết, có thể dùng mẫu Google Sheets (giảng viên có template sẵn gồm tiếng Việt, Anh, Nhật). Mẫu này liệt kê bằng cấp, kỹ năng chuyên môn, các project đã làm, vị trí, team size... rất nhanh để điền. Cách nào cũng được — chọn cái hợp với lượng thông tin của bạn.

▸ 3. Lưu ý quan trọng: liền mạch và đúng vị trí

Đây là phần đáng nhớ nhất. Liền mạch thời gian: các mốc học và làm phải nối tiếp nhau, đừng để khoảng trống khó giải thích — nhà tuyển dụng dễ đánh giá là "không ổn định". Chỉnh CV theo vị trí: nếu bạn biết PHP, Java, C# nhưng đang ứng tuyển vị trí PHP, hãy làm nổi bật PHP thay vì liệt kê dàn trải "cái gì cũng nhận". Với người nhiều kinh nghiệm, có thể thêm mục refer (người tham chiếu) để tăng độ tin cậy.

▸ 4. Chia sẻ CV

Sau khi CV chỉn chu, chia sẻ online cho thầy cô hoặc các mối quan hệ, ghi rõ mong muốn của bạn để họ dễ kết nối và sắp xếp phỏng vấn. Muốn tìm việc tốt, hãy chịu khó đầu tư cho khâu này.

Chương 8 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi có CV và được hẹn phỏng vấn, bạn cần chuẩn bị chứ không nên "vào tới đâu trả lời tới đó". Bài học chia sẻ những bước chuẩn bị trước buổi phỏng vấn và cách ứng xử khi trả lời, từ góc nhìn của người trực tiếp tuyển dụng. Điểm mấu chốt: với người mới (fresher), nhà tuyển dụng không kỳ vọng bạn dùng được ngay — họ ưu tiên thái độ, tính kỷ luật và sự phù hợp hơn là kỹ năng, vì kỹ năng sẽ được đào tạo lại.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cần tìm hiểu gì về công ty và vị trí trước khi đi phỏng vấn, và chuẩn bị câu hỏi để hỏi lại.
• Biết cách deal lương hợp lý, bám theo mức công ty đưa ra thay vì đòi "trên trời dưới biển".
• Biết cách trả lời khiêm tốn, chân thật, tập trung vào điều liên quan tới vị trí ứng tuyển.

─── NỘI DUNG CHÍNH

▸ 1. Tìm hiểu trước và chuẩn bị câu hỏi

Trước buổi phỏng vấn, hãy tìm hiểu kỹ công ty và job direction của vị trí xem có phù hợp với mình không. Ghi sẵn ra giấy vài câu hỏi để hỏi lại người interviewer. Khi bạn chủ động hỏi thêm, người ta rất thích vì đó là dấu hiệu bạn thật sự quan tâm — khác hẳn kiểu rải CV tùm lum rồi vào ngồi thụ động, không tương tác.

▸ 2. Deal lương cho hợp lý

Đây là bước ai cũng nghĩ tới. Hãy deal dựa trên mức công ty công bố: nếu tin tuyển ghi 10 triệu, bạn có thể nhích lên 11–12 triệu; đòi 15 triệu là bất khả thi. Xem thêm mức lương tham khảo của thị trường để đưa con số nằm trong hạn mức hợp lý, đừng nghe đâu đó rồi hiểu lệch.

▸ 3. Cách trả lời khi phỏng vấn

Buổi phỏng vấn thường xoay quanh 3 phạm trù: kỹ thuật, tính cách/con người, và benefit/policy của công ty — bạn cũng nên hỏi kèm cả ba. Khi giới thiệu bản thân, kể quá trình học và làm sao cho tương thích vị trí, bỏ bớt kỹ năng không liên quan, rồi chốt bằng một câu thể hiện định hướng ngắn hạn và dài hạn. Về kỹ thuật, cái gì biết thì nói biết, không lấp lửng; chưa làm thì nói cách bạn sẽ xử lý — nhà tuyển dụng muốn nghe cách bạn tư duy giải quyết vấn đề.

▸ 4. Lưu ý quan trọng: giữ thái độ đúng mực

Giọng điệu khi trả lời nên khiêm tốn, nhẹ nhàng, chân thật — đừng hấp tấp. Giảng viên kể có ứng viên bị hỏi lại đã buông câu "anh lên mạng search đi": dân IT tra mạng là bình thường, nhưng trong buổi phỏng vấn thì đó là câu tuyệt đối nên tránh. Thái độ đúng mực nhiều khi quyết định kết quả hơn cả kỹ năng.