Knowledge
Cách đội làm việc, viết ra để không phải giải thích lại mỗi lần có người mới. Tài liệu ở đây là thoả thuận chung, không phải gợi ý. Đọc tuần tự từ đầu tới cuối thì thành một khoá huấn luyện; đọc lẻ thì dùng như sổ tra cứu.
Nền tảng
Bộ khung chung: sản phẩm gồm những gì, ai chịu trách nhiệm phần nào, làm việc theo nhịp nào, quyết định ra sao.
Hệ điều hành dự án
Bản đồ tổng thể — toàn bộ sổ tay này ghép lại thành một vòng lặp khép kín. Đọc bài này trước, các bài còn lại là chi tiết của từng mắt xích.
Tư duy Shift Left
Đẩy mọi hoạt động phát hiện lỗi về càng sớm càng tốt. Lỗi tìm ra lúc viết yêu cầu rẻ gấp hàng trăm lần lỗi tìm ra khi người dùng đã cài app.
Chưa đo được thì chưa kiểm soát được
Nguyên tắc thứ ba của sổ tay, kèm bản đồ đi với nó: mỗi thứ sổ tay tuyên bố kiểm soát được thì chứng minh bằng con số nào, và con số đó nằm ở bài nào.
Phạm vi sản phẩm và ranh giới giữa các module
Alliance App gồm ba module Chat, Task và Bán hàng. Bài này xác định mỗi module sở hữu dữ liệu gì, không được đụng vào cái gì, và nói chuyện với nhau qua đường nào.
Vai trò và trách nhiệm
Mỗi thứ trong dự án có đúng một người chịu trách nhiệm. Bài này nói rõ ai quyết gì, ai làm gì, và khi nào phải hỏi ai.
Nhịp làm việc
Lịch cố định của đội theo ngày, tuần, hai tuần và quý. Mỗi buổi có mục đích riêng, có đầu ra riêng, và không được biến thành buổi báo cáo tiến độ.
Cách ra quyết định và ghi lại quyết định
Quyết định kỹ thuật quan trọng phải được ghi kèm lý do và các phương án đã loại. Không ghi thì sáu tháng sau cả đội sẽ tranh luận lại từ đầu.
Tổ chức công việc
Một việc đi từ ý tưởng tới tay người dùng qua những chặng nào, và mỗi chặng phải có đủ thứ gì mới được đi tiếp.
Từ ý tưởng đến release
Đường đi đầy đủ của một việc, qua sáu chặng. Mỗi chặng có điều kiện vào và điều kiện ra rõ ràng, không có chặng nào được nhảy cóc.
Vòng đời một hạng mục công việc
Đường đi của một ý tưởng từ lúc được nêu tới lúc tới tay người dùng, và ai chịu trách nhiệm ở từng chặng.
Viết yêu cầu và acceptance criteria
Một hạng mục chỉ được giao cho dev khi đã nêu rõ vấn đề, acceptance criteria kiểm chứng được, và phần nằm ngoài phạm vi. Thiếu ba thứ đó thì dev sẽ ngồi đoán.
Ưu tiên công việc
Cách xếp thứ tự khi việc nhiều hơn người. Có công thức để so sánh, có luật cứng cho vài loại việc, và có nguyên tắc thêm vào thì phải lấy ra.
Ước lượng và cam kết
Ước lượng là dự đoán, cam kết là lời hứa. Trộn hai thứ này là nguồn gốc của phần lớn xung đột giữa đội phát triển và phần còn lại của công ty.
Yêu cầu với lập trình viên
Phần bắt buộc. Đây là những điều một dev phải làm, không phải gợi ý để cân nhắc.
Những điều bắt buộc với lập trình viên
Danh sách ngắn những việc một dev phải làm trong mọi hạng mục, không có ngoại lệ. Đây là điều kiện để code được nhận, không phải gợi ý để cân nhắc.
Chuẩn viết code
Quy ước code của Alliance App. Phần nào máy kiểm tra được thì máy chặn, phần nào máy không thấy thì review chặn. Cả hai đều bắt buộc.
Quản lý branch và commit
Quy ước branch, commit, rebase và merge. Mục tiêu là branch main luôn release được, và lịch sử commit đọc được như một bản tường thuật.
Chuẩn pull request
PR nhỏ, mô tả đủ, review nhanh. Đây là chặng người-nhìn-người cuối cùng trước khi code vào branch main, nên nó có luật riêng cho cả người mở lẫn người review.
Chuẩn test của dev
Dev chịu trách nhiệm chính về chất lượng phần mình viết. Bài này nói rõ phải viết test gì, viết thế nào, và tự kiểm tra tay những gì trước khi mở PR.
Chuẩn riêng cho Chat, Task và Bán hàng
Ba module của Alliance App có ba loại rủi ro khác nhau, nên có ba bộ luật khác nhau. Đây là phần bắt buộc khi làm việc trong từng module.
Chuẩn UI trên mobile
Phân biệt chuẩn với pattern, đặt ngưỡng đo được cho touch target, contrast, font scale và scroll, rồi gắn chúng vào acceptance criteria, PR và DoD.
Kiểm soát chất lượng
Các quality gate giữ cho lỗi không đi tiếp được, đặt càng gần chỗ sinh ra lỗi càng tốt: hoàn thành, review, test, CI.
Definition of Done
Điều kiện một hạng mục phải thoả trước khi được gọi là xong — khác nhau theo loại hạng mục và theo module, có người ký tên, và ở quy mô 500.000 người dùng thì "xong" nghĩa là đã quan sát được trên dữ liệu thật chứ không phải đã merge.
Chuẩn review code
Review để bắt lỗi và lan truyền hiểu biết, không phải để phô diễn hay bắt bẻ phong cách.
Chiến lược test cho ứng dụng di động
Phân tầng test sao cho bắt được lỗi sớm với chi phí thấp, thay vì dồn hết vào manual test trước ngày release.
Quality gate tự động
Danh sách đầy đủ các cổng chặn tự động, đặt ở đâu, chặn cái gì, chạy trong bao lâu. Đây là xương sống kỹ thuật của shift left.
Ranh giới kiến trúc
Quy tắc về tầng, phụ thuộc và ranh giới giữa ba module. Kiến trúc ở đây không phải sơ đồ đẹp, mà là những luật máy kiểm tra được để code không rối dần theo thời gian.
Smoke test và cách liệt kê case
Smoke test trả lời đúng một câu: bản build này có đáng để test tiếp không. Bài này cho bộ tiêu chí chọn case, công thức liệt kê từ chính kiến trúc app, và danh sách đề xuất cho ba module.
Automation test cho mobile và API
Hai câu hỏi: tự động hoá việc nào trước, và bộ test tự động phải đạt con số nào mới coi là xong. API trước mobile, mười luồng E2E là trần, chập chờn dưới 1%.
PM cần gì để quyết định automation test
Ba artifact hay được liệt kê chỉ trả lời nửa câu hỏi. Nửa còn lại — số lần kiểm lại, trọng số nghiệp vụ, dữ liệu test — chỉ chủ sản phẩm có, và đó mới là nửa quyết định được.
Quy mô và hiệu năng
Alliance App hướng tới 500.000 người dùng trên hàng trăm loại thiết bị. Nhóm này gồm mốc quy mô, ma trận thiết bị, test đặc thù mobile, performance budget và test tải.
Chất lượng ở quy mô 500.000 người dùng
Alliance App hướng tới 500.000 người dùng. Ở quy mô đó, một lỗi hiếm vẫn là hàng trăm người, và một bản release xấu lan nhanh hơn khả năng phản ứng thủ công. Bài này nói cách QC phải đổi theo.
Device matrix và OS support policy
Danh sách device và OS version được hỗ trợ, chia theo tier. Không có device matrix thì câu "đã test trên Android" không mang thông tin gì.
Kiểm thử đặc thù mobile
Bốn nhóm kịch bản chỉ mobile mới có — app lifecycle, network chaos, runtime permission và upgrade/migration. Đây là nơi sinh ra phần lớn bug lọt ra production.
Test app lifecycle thế nào
Bài kiểm thử đặc thù mobile nói phải test những trạng thái lifecycle nào. Bài này nói ép app vào từng trạng thái bằng lệnh gì, vì sao Don't keep activities cho kết quả xanh giả, và quy trình kiểm một flow rủi ro cao.
Chạy network chaos test thế nào
Bài kiểm thử đặc thù mobile nói phải test những điều kiện mạng nào. Bài này nói dựng chúng bằng công cụ gì, cái nào đẩy được vào CI, và quy trình chứng minh idempotency thật sự hoạt động.
Test runtime permission thế nào
Bài kiểm thử đặc thù mobile nói mỗi quyền phải test đủ sáu trạng thái. Bài này nói đưa quyền về từng trạng thái bằng lệnh gì, vì sao Android không phân biệt được "chưa hỏi" với "deny vĩnh viễn", và phần nào máy chặn được.
Test upgrade và data migration thế nào
Bài kiểm thử đặc thù mobile nói phải test update đè từ mọi version còn hỗ trợ. Bài này nói dựng dữ liệu version cũ bằng cách nào, cài đè ra sao cho không mất dữ liệu, và cách ép hỏng giữa lúc migration mà không phải đua với hệ điều hành.
Performance budget
Thay câu "app phải nhanh" bằng con số đo được trên device thật, và cảnh báo khi build mới chậm hơn build cũ dù vẫn còn trong ngưỡng.
Test tải và quy mô
Ngân sách hiệu năng đo một người dùng; test tải đo cả hệ thống ở giờ cao điểm. Bài này là loại thứ hai — bốn kiểu test tải, mục tiêu phải chịu được, và bộ dữ liệu cỡ production.
Vì sao cần kiểm kê thiết bị test
Bản yêu cầu gửi cả đội — điền máy test mình đang giữ vào danh sách thiết bị. Kèm lý do, mười hai trường cần điền, và những gì tuyệt đối không ghi vào.
Phát hành
Đưa thay đổi ra người dùng một cách có kiểm soát, và rút lui được khi hỏng.
Quy trình release và rollback
Các bước cắt bản, kiểm tra trước khi đẩy, mở rộng theo tỷ lệ và phương án xử lý khi bản mới có vấn đề.
Release từng phần và feature flag
Cách đưa thay đổi ra người dùng theo tỷ lệ tăng dần, tách việc merge code khỏi việc bật tính năng, và rút lui trong vài giây thay vì vài ngày.
Backward compatibility giữa app và backend
User không update app ngay. Mọi thay đổi backend phải sống chung với các app version cũ còn ngoài thị trường, hoặc phải có cách buộc update.
Đưa app lên cửa hàng
Quy trình và danh sách kiểm tra khi nộp bản lên App Store và Google Play. Chặng này có độ trễ do bên thứ ba, nên mọi thứ sai ở đây đều đắt.
Vận hành
Biết app đang sống thế nào ngoài đời thật, và xử lý khi nó gãy.
Production monitoring
Release không phải điểm kết thúc của kiểm soát chất lượng, nó là chặng tiếp theo. Cần hai dashboard — kỹ thuật và nghiệp vụ. Thiếu cái thứ hai thì có loại hỏng không ai thấy.
Quy tắc cảnh báo
Dashboard là thứ ta chủ động mở ra xem; cảnh báo là thứ tự đánh thức ta. Bài này là loại thứ hai: ngưỡng nào thì kêu, kêu với ai, và làm sao để cảnh báo không bị bỏ qua.
Bug severity, on-call và root cause analysis
Severity quyết định ai bị gọi lúc mấy giờ. Và mỗi incident phải kết thúc bằng một thay đổi cơ chế, không phải bằng câu "lần sau cẩn thận hơn".
Yêu cầu báo cáo và điều kiện kỹ thuật đi kèm
Bản yêu cầu gửi đội — sáu nhịp báo cáo quản lý dự án cần, và với mỗi nhịp là thứ phải dựng trước mới có số. Không dựng thì báo cáo chỉ còn cách điền tay, mà số điền tay thì sai lặng lẽ.
Người dùng và số liệu
Căn cứ để quyết định làm gì tiếp theo, thay cho phỏng đoán.
Quality metrics
Khoảng mười hai con số là đủ để biết hệ chất lượng đang tốt lên hay xấu đi. Nhiều hơn thì không ai đọc, ít hơn thì có chỗ mù.
Đo lường sản phẩm
Chọn ít chỉ số nhưng đúng, gắn mỗi chỉ số với một quyết định, và biết chỉ số nào dễ bị lừa. Không đo được thì không kiểm soát được.
Analytics event là một phần của yêu cầu
Tính năng không có analytics event là tính năng không biết có ai dùng không. Danh sách event phải nằm trong acceptance criteria, không phải gắn thêm sau khi code xong.
Lắng nghe người dùng
Số liệu cho biết chuyện gì đang xảy ra, người dùng cho biết vì sao. Cần cả hai. Đây cũng là chặng shift left sớm nhất — rẻ hơn mọi loại test.
Thử nghiệm có kiểm chứng
Cách biết một thay đổi có thật sự tốt hơn không, thay vì tin là nó tốt hơn. Ở quy mô lớn, đây là cách rẻ nhất để không đổ công vào thứ không ai cần.
Quản trị rủi ro
Nhìn trước thứ có thể làm hỏng dự án, và giữ cho đội không kiệt sức.
Quản lý rủi ro và nợ kỹ thuật
Cách nhìn thấy rủi ro trước khi nó thành sự cố, và cách trả nợ kỹ thuật đều đặn thay vì dồn tới lúc không chịu nổi.
Security baseline và privacy
Lấy OWASP MASVS làm khung tham chiếu, kiểm kê third-party SDK, và coi khai báo dữ liệu trên store là điều kiện chặn release.
Bảo mật và quyền riêng tư
Alliance App giữ tin nhắn, công việc nội bộ và giao dịch tiền của 500.000 người. Bài này là những luật cứng về dữ liệu, quyền và bí mật — kiểm tra từ chặng thiết kế, không phải chặng cuối.
Sức khoẻ đội ngũ
Đội kiệt sức là rủi ro dự án lớn nhất và ít được theo dõi nhất. Nó không có cảnh báo tự động, nhưng có dấu hiệu sớm — và có luật cứng để không đi tới đó.
Biểu mẫu
Mẫu có sẵn để chép ra dùng ngay, khỏi nghĩ lại cấu trúc mỗi lần.
Mẫu bug report
Chép mẫu này khi tạo một phiếu lỗi. Thiếu mục nào thì người sửa phải hỏi lại, và mỗi lần hỏi lại mất nửa ngày.
Mẫu checklist trước release
Danh sách chép ra dùng cho mỗi bản release. Mỗi nhóm có một người ký tên, không phải tick cho có.
Mẫu họp cải tiến
Buổi nhìn lại cuối sprint. Có cấu trúc cố định, có luật để người ta dám nói thật, và bắt buộc kết thúc bằng đúng ba hành động có tên người và hạn.
Mẫu báo cáo tuần
Một trang, gửi chiều thứ Sáu, viết trong 15 phút. Mục đích là để người ngoài đội biết tình hình thật mà không phải họp, và để rủi ro được nói ra sớm.

