Hiểu thác nước, Agile, Scrum Guide 2020, Kanban Guide 2025 và DevOps; luyện giới hạn WIP, phân biệt phản hồi sản phẩm với cải tiến quy trình qua lab.
Nhóm sửa một công cụ tiếp nhận ticket có ba việc cùng lúc: lỗi chặn đăng nhập, yêu cầu thêm bộ lọc và cập nhật tài liệu. Nếu mọi người đều bắt đầu thêm việc mới, bản sửa quan trọng có thể nằm chờ review. Chọn một mô hình phát triển có ích khi nó giúp nhóm thấy công việc, phản hồi và trách nhiệm, không chỉ đổi tên cuộc họp.
Bài 055.1, Mô hình phát triển phần mềm, tham chiếu Open Source Essentials 050-100 trang in 197–215, biên soạn độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu vòng đời phần mềm, công cụ cộng tác và vai trò người dùng ở mức nhập môn. Lab dùng thẻ giấy hoặc bảng cục bộ với dữ liệu DEMO, không thay quy trình của một dự án thật.
Sau bài học, bạn có thể giải thích cách tiếp cận thác nước, Agile, Scrum, Kanban và DevOps; phân biệt mục tiêu sản phẩm với số việc bận rộn; và mô tả một điểm nghẽn bằng trạng thái cụ thể. Bài tập chưa phải triển khai đầy đủ bất kỳ framework nào.
Một yêu cầu như “tìm ticket nhanh hơn” chưa cho biết người dùng muốn tìm theo trường nào, dữ liệu nào được phép xem hoặc kết quả thế nào là đúng. Phân tích yêu cầu chuyển nhu cầu thành điều có thể thảo luận, thiết kế và kiểm chứng. Người dùng, Help Desk và kỹ thuật cần trao đổi trước khi chốt cách làm.
Quản lý dự án phối hợp phạm vi, lịch, nguồn lực và rủi ro. Phân tích kinh doanh xem mục tiêu và giá trị; kiến trúc xem cấu trúc, ràng buộc; phát triển tạo thay đổi; kiểm thử cung cấp bằng chứng về hành vi. Cách phân công tùy tổ chức, không phải mọi nhóm đều có một người riêng cho từng chức danh.
Không mặc định kiến trúc sư luôn là người duy nhất quyết định, tester là người duy nhất chịu trách nhiệm chất lượng hoặc người quản lý bảo đảm mọi dự đoán sẽ đúng. Điều cần thấy là ai quyết định việc nào, đầu vào gì và làm sao phản hồi khi giả định thay đổi.
ALM, quản lý vòng đời ứng dụng, nối con người, quy trình và công cụ từ ý tưởng tới ngừng sử dụng. VCS giữ lịch sử source; bảng việc theo dõi trạng thái; tài liệu quyết định giải thích lý do. Mua một công cụ ALM chưa tự tạo sự thống nhất giữa các phần này.
Mô hình thác nước thường được trình bày theo các giai đoạn yêu cầu, phân tích, thiết kế, phát triển, kiểm thử và vận hành. Đầu ra một giai đoạn tạo cơ sở cho bước sau. Cách tổ chức này giúp mô tả các điểm xem xét và tài liệu cần bàn giao, nhất là khi phạm vi tương đối rõ.
Nhược điểm của cách triển khai quá cứng là phản hồi thực tế tới muộn. Một hiểu sai ở yêu cầu có thể kéo theo thiết kế và mã cần làm lại. Tuy nhiên, không nên kết luận mọi dự án chia giai đoạn đều cấm phản hồi sớm, không kiểm thử trong phát triển hoặc chắc chắn dự đoán đúng ngân sách.
Trong tình huống ticket, có thể làm rõ quyền truy cập bằng mẫu giao diện trước khi phát triển toàn bộ chức năng. Kế hoạch cần ghi cách xử lý thay đổi và rủi ro; một sơ đồ tuyến tính chưa giải quyết các câu hỏi đó. Đội Help Desk nên đưa bằng chứng về tình huống người dùng vào đúng thời điểm.
Tuyên ngôn Agile nhấn mạnh tương tác, phần mềm hoạt động, hợp tác với khách hàng và phản hồi thay đổi. Nó vẫn thừa nhận giá trị của quy trình, tài liệu, hợp đồng và kế hoạch. Không diễn giải Agile thành bỏ tài liệu, nhận mọi yêu cầu ngay hoặc làm việc không cần mục tiêu.
Các phần nhỏ có thể giúp nhóm kiểm tra giả định sớm. Ví dụ, chỉ thử bộ lọc trạng thái trước khi thêm nhiều trường tìm kiếm. Phản hồi cho biết cách hiểu nhu cầu có đúng không; nó chưa bảo đảm thiết kế đã an toàn, nhanh hoặc đủ khả năng vận hành.
Scrum và Kanban cung cấp những cách tổ chức cụ thể khác nhau. Một nhóm có bảng thẻ chưa chắc đang dùng Kanban đầy đủ; một nhóm họp mỗi sáng cũng chưa chắc đang dùng Scrum. Cần xem các nguyên tắc, trách nhiệm và cách kiểm tra kết quả thực tế.
Scrum Guide 2020 mô tả ba trách nhiệm trong Scrum Team: Product Owner, Scrum Master và Developers. Product Owner chịu trách nhiệm tối đa hóa giá trị và quản lý Product Backlog; không mặc định đây là người tài trợ hoặc cấp trên giao từng việc kỹ thuật.
Scrum Master giúp thiết lập Scrum và nâng hiệu quả của nhóm. Vai trò này không bắt buộc chủ trì mọi sự kiện hoặc nhận báo cáo cá nhân trong Daily Scrum. Developers tự quản công việc cần làm để tạo Increment sử dụng được; chất lượng là phần việc của cả nhóm, không chờ bàn giao cho một nhóm kiểm thử ở cuối.
Sprint có độ dài cố định một tháng hoặc ngắn hơn. Sprint Planning làm rõ mục tiêu, phần việc lựa chọn và cách tiếp cận. Daily Scrum là sự kiện 15 phút cho Developers kiểm tra tiến độ tới Sprint Goal và điều chỉnh kế hoạch. Nó không bắt buộc diễn ra đầu ngày hoặc theo một bộ ba câu hỏi cố định.
Sprint Review kiểm tra kết quả cùng các bên liên quan và thích nghi hướng đi; Sprint Retrospective xem cách cải thiện chất lượng và hiệu quả làm việc. Review không chỉ là màn trình diễn để xin duyệt, còn retrospective không nên biến thành cuộc truy trách nhiệm cá nhân.
Product Backlog gắn với Product Goal; Sprint Backlog gồm Sprint Goal, các mục đã chọn và kế hoạch thực hiện; Increment phải đáp ứng Definition of Done. Hoàn thành nhiều thẻ chưa đủ nếu sản phẩm chưa dùng được theo định nghĩa chất lượng. Increment cũng không cần đợi Sprint Review mới được cung cấp.
The Kanban Guide tháng 5/2025 tập trung định nghĩa, quản lý và cải thiện luồng. Nhóm cần hiểu điểm bắt đầu, kết thúc, trạng thái, chính sách và cách kiểm soát WIP, tức công việc đã bắt đầu nhưng chưa xong. Không có yêu cầu mọi bảng phải dùng đúng ba tên cột hoặc có chức danh quản lý Kanban riêng.
Giới hạn WIP tạo lý do để hoàn tất hoặc tháo gỡ việc đang làm trước khi kéo thêm. Nếu review đang nghẽn, tăng số thẻ lập trình có thể chỉ tăng hàng chờ. Một thẻ bị chặn vẫn thuộc công việc đang tiến hành nếu đã qua điểm bắt đầu và chưa tới điểm kết thúc đã định nghĩa.
Các chỉ số luồng có thể giúp nhìn thời gian hoàn tất, số việc xong và tuổi việc đang mở. Chúng cần định nghĩa thống nhất và bối cảnh, không dùng để xếp hạng cá nhân bằng số thẻ. Kanban cũng không đồng nghĩa không có thời hạn; nhóm vẫn có thể quản lý kỳ vọng về thời gian và ưu tiên.
DevOps nhấn mạnh hợp tác và phản hồi giữa những người tạo, cung cấp và vận hành phần mềm. Tự động hóa build, kiểm thử, triển khai và giám sát có thể hỗ trợ điều này. Chỉ thêm một công cụ CI hoặc đổi tên một bộ phận chưa giải quyết được trách nhiệm và bàn giao.
DORA phân biệt continuous delivery với continuous deployment. Delivery hướng tới khả năng cung cấp thay đổi theo nhu cầu; deployment tự động đưa thay đổi đạt điều kiện tới production. Không bắt buộc mọi nhóm tự động phát hành mọi commit để thực hành delivery.
Phản hồi vận hành cần quay lại công việc phát triển: lỗi người dùng, khả năng quan sát, phục hồi và giới hạn tài nguyên. Các kiểm tra tự động vẫn cần phạm vi đúng, quyền truy cập phù hợp và đường xử lý khi thất bại. Không hứa DevOps tự bảo đảm tốc độ hoặc độ tin cậy cho mọi dự án.
Tạo bốn trạng thái: Chờ, Đang làm, Review, Xong. Trong bài này, điểm bắt đầu là lúc vào Đang làm; điểm kết thúc là khi đáp ứng tiêu chí kiểm tra và vào Xong. Đặt giới hạn tổng WIP là hai thẻ cho Đang làm cộng Review. Đây là chính sách giả định cho lab.
Tạo thẻ A sửa lỗi đăng nhập, B thêm bộ lọc, C cập nhật hướng dẫn và D thêm thông báo. Mỗi thẻ có mô tả kết quả và cách kiểm chứng. Không ghi thông tin khách hàng thật vào bảng công khai hoặc mời thành viên dự án thật để thực hiện bài.
Đặt A ở Review, B ở Đang làm, C và D ở Chờ. Tổng WIP là hai nên chưa kéo C. Nhóm cần xem việc review A đang thiếu người, bằng chứng hay quyền truy cập. Chỉ chuyển A sang một cột “bị chặn” để né giới hạn sẽ che vấn đề thay vì giảm việc tồn.
Kết quả mong đợi là giải thích được vì sao làm thêm chưa giúp A tới Xong. Ghi một hành động gỡ chặn có người phụ trách. Bài tập không khẳng định WIP bằng hai phù hợp cho đội thật; giới hạn cần được đánh giá theo bối cảnh và luồng thực tế.
Giả định A đã được review nhưng chưa kiểm tra đăng nhập với tài khoản thiếu quyền. Theo tiêu chí của lab, A chưa Xong. Bổ sung kiểm tra cần thiết trước khi chuyển trạng thái; không ghi “đã chạy” nếu mới chỉ viết yêu cầu kiểm tra trên giấy.
Sau khi giả định bằng chứng đầy đủ, chuyển A tới Xong. WIP còn một nên có thể xem xét kéo C theo ưu tiên. Nếu nhu cầu thay đổi, ghi lý do đổi thứ tự; việc kéo thẻ cần gắn mục tiêu, không chỉ nhằm làm bảng trông đầy.
Viết một nhận xét về sản phẩm và một nhận xét về cách làm. “Thông báo đăng nhập chưa rõ” là phản hồi hành vi sản phẩm; “review chờ vì chưa có người thay thế” là vấn đề quy trình. Hai nhận xét cần hành động khác nhau.
Nếu đặt bài tập trong Scrum, nhóm còn cần Sprint Goal, các trách nhiệm, sự kiện và Definition of Done phù hợp. Không gọi bốn thao tác chuyển thẻ là một Sprint hoàn chỉnh. Giữ đúng giới hạn giúp người mới hiểu từng khái niệm mà không học thuộc nhãn.
Agile có bỏ kế hoạch không? Không. Daily Scrum có phải báo cáo cho quản lý không? Mục đích của nó là Developers kiểm tra và điều chỉnh tiến độ tới Sprint Goal. Có bảng việc đã đủ Kanban chưa? Cần thêm định nghĩa luồng, kiểm soát và cải thiện công việc.
Khi một thẻ bị chặn, trước hết làm rõ nó đang chờ gì và còn thuộc WIP không theo chính sách đã công bố. Khi chọn mô hình, hãy chỉ ra nhu cầu và vấn đề cần giải quyết. Không có một tên framework bảo đảm dự án thành công chỉ nhờ được áp dụng trên giấy.
Khung mục tiêu: LPI Open Source Essentials 055.1. Agile Manifesto, Scrum Guide 2020, Kanban Guide 2025 và DORA được dẫn tại các phần tương ứng. Các ví dụ bảng và thẻ trong bài do tác giả biên soạn.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.