Bạn đã biết về nghĩa thật sự của các thuật ngữ trong Agile chưa? Nếu chưa, hãy cùng tìm hiểu tại bài viết này nhé!

Agile Framework là một thuật ngữ bao gồm nhiều phương pháp khác nhau, mỗi phương pháp là Agile Framework riêng! Hãy cùng tìm hiểu ý nghĩa thật sự của từng thuật ngữ trong Agile nhé!

Acceptance Criteria	Các đặc điểm để xác nhận rằng một câu chuyện đáp ứng được mong đợi của người dùng. Được diễn đạt bằng ngôn ngữ rõ ràng, đơn giản và cụ thể, có thể chuyển đổi thành tiêu chí kiểm thử.
Backlog	Một danh sách động các câu chuyện ưu tiên theo thứ tự. Backlog có thể được quản lý cho toàn bộ chương trình, từng sản phẩm và từng sprint. Chủ sở hữu Sản phẩm, phối hợp với các bên liên quan, sẽ thường xuyên làm việc với backlog để đảm bảo công việc được xác định rõ ràng, theo thứ tự ưu tiên và có ước lượng hợp lý. Công việc ưu tiên cao sẽ được xác định và hoàn thành các chi tiết quan trọng trước, trong khi công việc được lên kế hoạch cho các bản phát hành trong tương lai sẽ nằm ở vị trí thấp hơn trên backlog và có mức độ chi tiết thấp hơn.
Burndown Chart	Một chỉ số phổ biến trong Agile để thể hiện lượng công việc còn lại so với thời gian. Nó được sử dụng để đánh giá tiến độ của nhóm phát triển trong một sprint.
Continuous Deployment	Cố gắng triển khai mã mới càng nhanh càng tốt bằng cách tự động hóa quá trình tích hợp, kiểm thử và triển khai lên môi trường sản phẩm.
Continuous Integration	Hợp nhất các thay đổi phần mềm vào kho mã chung nhiều lần trong một ngày. Phương pháp này giúp giảm thời gian và rủi ro trong việc triển khai phần mềm mới.
Definition of Done	Một sự thống nhất về những gì cần làm để đáp ứng mong đợi của người dùng, thường được áp dụng cho một câu chuyện người dùng.
Development Team	Nhóm đa chức năng thường bao gồm nhân viên hợp đồng: các nhà phát triển phần mềm, bao gồm kỹ sư phần mềm và an ninh, chuyên gia dữ liệu, những người kiểm thử, đảm bảo chất lượng và quản lý cấu hình.
Epic	Một tập hợp công việc lớn cần hoàn thành trong quá trình phát triển; thường là quá lớn để hoàn thành trong một sprint; được chia nhỏ thành các tính năng và câu chuyện người dùng nhỏ hơn. Các công việc này có thể liên quan đến chức năng kinh doanh hoặc xác định các ràng buộc đặt lên sản phẩm hoặc hệ thống. Epic được sử dụng trong quá trình lập kế hoạch và ước lượng chi phí.
Extreme Programming (XP)	Một phương pháp phát triển phần mềm Agile với việc phát hành và kiểm tra thường xuyên trong các chu kỳ phát triển ngắn. Nó nhằm tạo ra phần mềm chất lượng cao hơn và giảm chi phí của những thay đổi.
Iteration	Một khung thời gian để phát triển và triển khai phần mềm. AiDA sử dụng thuật ngữ “release” và “sprint” như các vòng lặp. Mỗi chương trình sẽ xác định một độ dài vòng lặp chung.
Kanban	Một phương pháp để hình dung công việc của nhóm phát triển trong nhiều cột để đánh giá tiến độ và xác định các rào cản. Bảng Kanban có thể được thực hiện trên bảng trắng, bảng thông báo với các ghi chú Post-It hoặc các công cụ phần mềm để hỗ trợ sự cộng tác của nhóm.
Minimum Viable Product (MVP)	Phiên bản của một sản phẩm mới cho phép một nhóm thu thập được số lượng lớn học tập đã được xác nhận về khách hàng với sự cố gắng tối thiểu. (Nguồn: Eric Reis)
Pair programming	Khi hai lập trình viên phát triển và kiểm thử phần mềm thông qua một máy trạm duy nhất. Khi một người viết mã, người còn lại quan sát và họ thường xuyên thay đổi vai trò. Điều này cho phép học hỏi nhanh hơn, thúc đẩy sự cộng tác và lý tưởng là cải thiện chất lượng phần mềm.
Planning Poker	Một phương pháp cho nhóm phát triển để ước lượng kích thước hoặc số lượng công việc cần thiết cho mỗi câu chuyện. Mỗi thành viên trong nhóm đặt một lá bài cá nhân cho ước lượng của mình. Nhóm sẽ xem xét những khác biệt để đạt được một hiểu biết chung về công việc được lên kế hoạch.
Product Owner	Người đại diện cộng đồng người dùng có thẩm quyền, người quản lý backlog(s) và sắp xếp ưu tiên yêu cầu, truyền đạt các khái niệm vận hành cho nhóm phát triển và cung cấp phản hồi liên tục cho nhóm phát triển về sản phẩm của họ. Xem phân tích yêu cầu để biết thêm chi tiết về vai trò này. Chủ sở hữu Sản phẩm thường là một nhân viên chính phủ thuộc tổ chức người dùng sở hữu yêu cầu, nhưng một số chương trình có thể có một nhà thầu đảm nhiệm vai trò này và sau đó làm việc với người dùng chính phủ.
Release	Phiên bản (release) đại diện cho yếu tố cốt lõi của cấu trúc chương trình, hướng dẫn tần suất chương trình cung cấp khả năng cho người dùng cuối. Độ dài của mỗi phiên bản phụ thuộc vào các yếu tố vận hành, mua sắm và kỹ thuật, nên được thảo luận với các bên liên quan trên các tổ chức người dùng và mua sắm. Như một hướng dẫn chung, hầu hết các phiên bản nên kéo dài ít hơn sáu tháng (như được ủng hộ bởi US CIO, GAO và FITARA). Chu kỳ phát hành ngắn hơn có nhiều lợi ích, quan trọng nhất là chương trình triển khai khả năng hữu ích cho người dùng cuối nhanh hơn.
Scrum	Một Framework Agile phát triển hợp tác để quản lý dự án; bao gồm thiết kế lặp lại, phát triển và triển khai thường xuyên các chức năng. Bao gồm sự tương tác trực tiếp với người dùng cuối và các bên liên quan khác, và cho phép và tạo điều kiện cho các nhóm tự tổ chức. Thông thường, nó liên quan đến quy trình giao tiếp mật thiết bao gồm các cuộc họp tình hình ngắn hằng ngày.
Scrum Master	Người này thiết lập và hỗ trợ Scrum hàng ngày, Scrum của Scrum và các buổi lễ Agile khác trong suốt quá trình phát triển. Thông thường, đây là một thành viên của nhóm hợp đồng, tùy thuộc vào chi tiết của hợp đồng cá nhân.
Scrum of Scrums	Phương pháp để mở rộng phát triển Agile, trong đó nhiều nhóm Scrum làm việc cùng nhau để cung cấp một giải pháp.
Software Factory	Việc tích hợp một tập hợp các công cụ dựa trên đám mây với chi phí thấp, cho phép các nhà phát triển, người dùng và quản lý làm việc cùng nhau theo một nhịp độ hàng ngày. (Xem trang Nhà máy phần mềm)
Sprint	Một chu kỳ công việc ngắn (thường từ hai đến bốn tuần) tập trung vào hoàn thành một phần được xác định của các sản phẩm hoặc chức năng có thể sử dụng của dự án. Mỗi sprint bao gồm quá trình lập kế hoạch, thiết kế, phát triển, tích hợp, kiểm thử và trình diễn phần mềm hoạt động cho chủ sở hữu sản phẩm, người dùng và các bên liên quan khác.
Story Point	Đơn vị đo lường để xác định kích thước hoặc số lượng công việc mà một nhóm phát triển cần thực hiện để hoàn thành một câu chuyện. Điểm câu chuyện (story points) là độc đáo cho mỗi nhóm phát triển. Một điểm câu chuyện có giá trị 1 là đơn vị nhỏ nhất và các công việc khác được đánh giá so với kích thước đó.
Technical Debt	Công việc làm lại (rework) cần được thực hiện bởi nhóm phát triển khi một giải pháp dễ dàng, ngắn hạn đã được theo đuổi, nhưng cần thay đổi thêm để cải thiện tính chặt chẽ và phát triển tiếp theo.
Test-Driven Development (TDD)	Một phương pháp phát triển phần mềm trong đó yêu cầu được chuyển đổi thành kịch bản kiểm thử. Phần mềm sau đó được phát triển và cải tiến cho đến khi nó vượt qua các bài kiểm tra.
Users	Những người cuối cùng sử dụng giải pháp phần mềm. Người dùng truyền đạt các khái niệm vận hành và yêu cầu/các nhu cầu, tham gia vào các hoạt động kiểm thử liên tục và cung cấp phản hồi về khả năng đã được phát triển. Việc hiểu rõ rằng người dùng cuối cùng là ai là rất quan trọng đối với nhóm phát triển, để đảm bảo họ tập trung vào việc làm hài lòng người dùng. Một nguyên tắc cốt lõi của Agile là sự tham gia tích cực của người dùng trong suốt quá trình phát triển.
User Story	Đơn vị yêu cầu nhỏ nhất được viết dưới góc nhìn của người dùng về cách họ sẽ sử dụng phần mềm. Các câu chuyện người dùng sẽ được xác định và ưu tiên bởi Chủ sở hữu Sản phẩm thông qua các backlog. Các câu chuyện người dùng không thể hoàn thành trong một sprint duy nhất nên được chia thành các yếu tố nhỏ hơn. Mỗi câu chuyện người dùng nên có tiêu chí chấp nhận rõ ràng.
Velocity	Số điểm câu chuyện mà một nhóm phát triển hoàn thành trong một chu kỳ (phiên bản/sprint). Tốc độ (velocity) của một nhóm qua nhiều chu kỳ là một chỉ số quan trọng để theo dõi hiệu suất của nhóm và hỗ trợ việc lập kế hoạch và xếp lịch công việc trong tương lai.

Bộ môn CNTT
Trường Cao đẳng FPT Mạng cá cược bóng đá cơ sở Hà Nội