Tài liệu ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình agile

MỤC LỤC DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT .................................................. 5 DANH MỤC CÁC BẢNG .............................................................................................. 6 DANH MỤC CÁC HÌNH VẼ ......................................................................................... 7 MỞ ĐẦU ......................................................................................................................... 8 CHƢƠNG I: CƠ SỞ LÝ THUYẾT .............................................................................. 11 CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM ............ 11 1.1 Tổng quan ƣớc lƣợng phần mềm ......................................................................... 11 1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm ..................................................... 12 1.3 Các phƣơng pháp ƣớc lƣợng ............................................................................... 14 1.4 Tổng quan mô hình Agile .................................................................................... 14 1.4.1 Mô hình phát triển phần mềm Agile ............................................................ 14 1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý ........................... 15 1.4.3 Các đặc trƣng của mô hình Agile ................................................................. 16 1.5 Giới thiệu Scrum ................................................................................................. 18 1.5.1 Giới thiệu ...................................................................................................... 18 1.5.2 Khung làm việc Scrum ................................................................................. 19 1.5.3 Nguyên lý hoạt động của scrum: .................................................................. 24 CHƢƠNG II. LOGIC MỜ VÀ ỨNG DỤNG ............................................................... 25 2.1 Cơ sở lý thuyết..................................................................................................... 25 2.1.1 Cơ sở lý thuyết về logic mờ.......................................................................... 25 2.1.2 Cơ sở toán học của logic mờ ........................................................................ 25 2.1.3. Khái niệm về tập mờ ................................................................................... 26 2.1.4. Các phép toán của tập mờ............................................................................ 28 2.2 Logic mờ .............................................................................................................. 31 2.2.1 Khái niệm ..................................................................................................... 31 2.2.2 Biến ngôn ngữ .............................................................................................. 32 2.2.3. Mệnh đề mờ ................................................................................................. 32 2.2.4 Các phép toán của logic mờ. ........................................................................ 36 2.2.5 Biến ngôn ngữ. ............................................................................................. 37 2.2.6 Các luật trong mô hình logic mờ .................................................................. 37 2.2.7 Qui trình hoạt động của Logic mờ ............................................................... 38 2.2.8 Một số ứng dụng ........................................................................................... 38 2 CHƢƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE .............................................. 40 3.1 Mô hình tổng quan ............................................................................................... 41 3.2 Bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile ................. 41 3.3 Áp dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm ............. 43 3.3.1 Xác định độ phức tạp (nỗ lực) ...................................................................... 44 3.3.2 Xác định vận tốc ........................................................................................... 50 3.3 Tóm tắt các bƣớc thực hiện: ................................................................................ 53 3.4 Ví dụ minh họa. ................................................................................................... 54 3.5 Chƣơng trình ứng dụng ....................................................................................... 56 KẾT LUẬN VÀ TRIỂN VỌNG ................................................................................... 58 1. Kết quả đạt đƣợc. ................................................................................................... 58 2. Hạn chế .................................................................................................................. 58 3. Hƣớng phát triển .................................................................................................... 58 TÀI LIỆU THAM KHẢO ............................................................................................. 59 3 TÓM TẮT LUẬN VĂN ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE Học viên: Lê Duy Tuấn Chuyên ngành: Khoa học máy tính Mã số: 8480101 Trƣờng: ĐH Bách Khoa – ĐH Đà Nẵng Khóa: K33 Tóm tắt: Mô hình phát triển phần mềm linh hoạt (Agile Software Development) gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm, mô hình này khắc phục đƣợc những hạn chế của các phƣơng pháp phát triển phần mềm truyền thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng trong thời gian ngắn nhất với hiệu quả cao nhất. Cũng nhƣ các mô hình phát triển phần mềm khác, trong mô hình phát triển phần mềm Agile khâu ƣớc lƣợng cũng đóng vai trò quyết định đến sự thành công hay thất bại của dự án phần mềm. Nghiên cứu này nhằm mục đích ứng dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile để giảm thiểu đƣợc thời gian, chi phí cho quá trình ƣớc lƣợng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án phần mềm. Từ khóa: Mô hình Agile, quy trình Scrum, ước lượng nỗ lực, công nghệ phần mềm, logic mờ. FUZZY LOGIC APPLICATION SOLVES THE ESTIMATION PROBLEM OF AGILE SOFTWARE DEVELOPMENT EFFORTS Abstract: Agile Software Development model has become very popular in software development industry, this model overcomes the limitations of traditional software development methods, contribute to creating software that can meet customer requirements in the shortest time with the highest efficiency. Like other software development models, in Agile software development model, the estimation also plays a decisive role in the success or failure of software projects. This study aims to apply fuzzy logic to the estimation of Agile software development efforts to minimize time and cost for the process of estimating software development efforts, thereby contributing improve efficiency for software projects. Keywords: Agile Software Development, Scrum, Software Effort Estimation, Software Engineering, Fuzzy Logic. 4 DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT STT Ký hiệu Diễn giải 1 SLOC Source Line Of Code: Dòng mã nguồn 2 FP Function Point: Điểm chức năng 3 OP Object Point: Điểm đối tƣợng 4 COCOMO Constructive Cost Model - Mô hình giá cấu thành 5 SP Story Point là đại lƣợng chỉ độ lớn tƣơng đối của các user story 6 FR Friction: Hệ số ma sát 7 DF Dynamic Force: Yếu tố dao động 8 ES User Story Effort 5 DANH MỤC CÁC BẢNG Số hiệu Tên bảng Trang 2.1 Mô tả hoạt động của máy sƣởi 38 3.1 Qui mô, kích thƣớc của Story 44 3.2 Độ phức tạp của User Story 46 3.3 Trọng số các User Story 47 3.4 Yếu tố thành phần nhóm 47 3.5 Giá trị độ phức tạp 49 3.6 Yếu tố ảnh hƣởng hệ số ma sát 50 3.7 Yếu tố ảnh hƣởng hệ số dao động 52 3.8 Minh họa các yếu tố ảnh hƣởng đến hệ số ma sát 54 3.9 Minh họa các yếu tố ảnh hƣởng đến hệ số dao động 55 6 DANH MỤC CÁC HÌNH VẼ Số hiệu hình vẽ Tên hình vẽ Trang 1.1 Đồ thị hình nón không chắc chắn 12 1.2 Quy trình hoạt động Scrum 24 2.1 Hàm phụ thuộc của tập kinh điển A 26 2.2 Hàm liên thuộc của tập mờ 27 2.3 Độ cao, miền xác định, miền tin cậy của tập mờ 27 2.4 Các dạng hàm liên thuộc của tập mờ 28 2.5 Hợp của hai tập mờ có cùng cơ sở theo qui tắc Max (a) và theo Lukasiewiez (b 29 2.6 Giao của hai tập mờ có cùng cơ sở theo qui tắc Min (a) và theo tích đại số (b) 30 2.7 Bù của tập mờ 31 2.8 Quy trình hoạt động của hệ Logic mờ 38 3.1 Mô hình đề xuất 41 3.2 Mô hình xử lý dữ liệu 43 3.3 Minh họa hàm phụ thuộc giữa SP, ILF với Com 46 3.4 Minh họa các giá trị Story Point trên Matlab 47 3.5 Minh họa các giá trị ILF trên Matlab 48 3.6 Minh họa các giá trị luật trên Matlab 48 3.7 Minh họa kết quả trên Matlab 49 3.8 Minh họa các giá trị Hệ số ma sát 51 3.9 Giao diện xác định độ phức tạp 56 3.10 Giao diện xác định vận tốc 56 3.11 Giao diện dự đoán kết quả 57 7 MỞ ĐẦU I. Lý do chọn đề tài Trong quản lý dự án phần mềm, khâu ƣớc ƣớc lƣợng đƣợc xem là vấn đề trực tiếp ảnh hƣởng đến sự thành công hay thất bại của một dự án phần mềm. Thực tế đã có rất nhiều dự án thất bại do trong khi thực hiện dự án quá trình ƣớc lƣợng không chính xác dẫn đến kế hoạch bị phá sản. Trong quá trình thực hiện dự án ta không thể tính toán, ƣớc lƣợng chính xác tuyệt đối đƣợc chi phí để phát triển phần mềm, tuy nhiên nếu các con số dự đoán nằm trong khoảng cho phép sẽ góp phần giảm rủi ro cho dự án phần mềm. Do đó, nếu ta có một phƣơng pháp ƣớc lƣợng phần mềm hiệu quả thì sẽ hạn chế đƣợc sự thất bại của một dự án phần mềm. Hiện nay mô hình phát triển phần mềm linh hoạt (Agile Software Development) gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm, mô hình này khắc phục đƣợc những hạn chế của các phƣơng pháp phát triển phần mềm truyền thống, góp phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng trong thời gian ngắn nhất với hiệu quả cao nhất. Tuy nhiên, cũng nhƣ các phƣơng pháp truyền thống khác, khâu ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile cũng đóng vai trò quyết định đến sự thành công của một dự án phần mềm. Dựa trên lý thuyết logic mờ và xét thấy có sự liên quan trong quá trình ƣớc lƣợng nỗ lực đến logic mờ. Do đó, tôi đề xuất chọn luận văn cao học: "Ứng dụng logic mờ giải bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile" II. Mục đích nghiên cứu Xây dựng đƣợc ứng dụng hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm có ứng dụng logic mờ áp dụng vào mô hình Agile để giảm thiểu đƣợc thời gian, chi phí cho quá trình ƣớc lƣợng nỗ lực phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án phần mềm. III. Mục tiêu và nhiệm vụ nghiên cứu 1. Mục tiêu: - Nắm vững lý thuyết về công nghệ phần mềm và kiến thức về ƣớc lƣợng nỗ lực phát triển phần mềm - Nắm vững mô hình phát triển phần mềm Agile - Nắm vững về lý thuyết logic mờ và áp dụng đƣợc logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm. 8 - Xây dựng đƣợc ứng dụng để hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm 2. Nhiệm vụ: - Nghiên cứu mô hình phát triển phần mềm linh hoạt ở thực tiễn. - Nghiên cứu lý thuyết logic mờ và tình hình ứng dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm ở hiện tại. - Tìm hiểu và cài đặt thuật toán có ứng dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm - Thực nghiệm và đánh giá giá kết quả theo yêu cầu mà đề tài đặt ra IV. Đối tƣợng và phạm vi nghiên cứu - Mô hình phát triển phần mềm Agile - Lý thuyết ƣớc lƣợng nỗ lực phát triển phần mềm - Lý thuyết Logic mờ và ứng dụng của logic mờ V. Phƣơng pháp nghiên cứu - Phƣơng pháp lý thuyết - Phƣơng pháp phân tích và tổng hợp - Phƣơng pháp thực nghiệm VI. Ý nghĩa khoa học và thực tiễn - Nghiên cứu và vận dụng đƣợc mô hình phát triển phần mềm Agile trong công việc quản lý dự án phần mềm - Nắm vững phƣơng pháp ƣớc lƣợng nỗ lực phát triển phần mềm - Nắm vững đƣợc lý thuyết về logic mờ và áp dụng đƣợc vào bài toán nỗ lực phát triển phần mềm - Xây dựng đƣợc ứng dụng hỗ trợ ƣớc lƣợng nỗ lực phát triển phần mềm để có thể áp dụng vào các dự án thực tế - Kết quả nghiên cứu có thể làm tài liệu tham khảo trong quá trình ƣớc lƣợng nỗ lực phát triển phần mềm cho các dự án phần mềm VII. Dự kiến kết quả đạt đƣợc - Biết đƣợc mô hình phát triển phần mềm Agile - Biết đƣợc kiến thức về logic mờ và ứng dụng kiến thức về logic mờ để áp dụng vào bài toán ƣớc lƣợng chi phí 9 - Xây dựng đƣợc ứng dụng để minh họa cho nội dung luận văn - Có kết quả thực nghiệm để đánh giá tính thực tế của đề tài VIII. CẤU TRÚC NỘI DUNG LUẬN VĂN CHƢƠNG I: CƠ SỞ LÝ THUYẾT CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM 1.1 Tổng quan ƣớc lƣợng phần mềm 1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm 1.3 Các phƣơng pháp ƣớc lƣợng 1.4 Tổng quan mô hình Agile 1.5 Giới thiệu Scrum CHƢƠNG II. LOGIC MỜ VÀ ỨNG DỤNG 2.1 Cơ sở lý thuyết 2.2 Logic mờ CHƢƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE 3.1 Mô hình tổng quan 3.2 Bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình Agile 3.3 Áp dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển phần mềm 3.4 Ví dụ minh họa 3.5 Chƣơng trình ứng dụng KẾT LUẬN VÀ TRIỂN VỌNG 1. Kết quả đạt đƣợc 2. Hạn chế 3. Hƣớng phát triển TÀI LIỆU THAM KHẢO 10 CHƢƠNG I: CƠ SỞ LÝ THUYẾT CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM 1.1 Tổng quan ƣớc lƣợng phần mềm Ƣớc lƣợng là công việc tính toán gần đúng một đại lƣợng nào đó dựa trên các tập dữ liệu liên quan đến đại lƣợng đó. Cũng giống nhƣ bất cứ một dự án nào khác, dự án phần mềm cũng cần phải ƣớc lƣợng các đại lƣợng trên với mục đích: - Dự toán chi phí hợp lý - Sự chính xác cao - Đảm bảo tiến độ - Kiểm soát dự án tốt hơn - Thể hiện đƣợc sự chuyên nghiệp Ƣớc lƣợng phần mềm từ lâu đã đƣợc xem là vấn đề cốt lõi có ảnh hƣởng trực tiếp đến sự thành bại của dự án. Ƣớc lƣợng là một trong những nền tảng cho việc lập lịch dự án một cách hiệu quả. Nhiều công ty phát triển phần mềm phải chịu thất bại hoặc bị mất lợi thế cạnh tranh do các ƣớc lƣợng xấu. Khi phát triển phần mềm cần phải đƣa ra một ƣớc lƣợng về giá cả, nhân lực và thời gian thực hiện dự án một cách hợp lý. Nếu ƣớc lƣợng thiếu cho một dự án, quản lý thiếu các nỗ lực đảm bảo chất lƣợng sẽ dẫn đến việc quá tải, vƣợt quá về khả năng và thời gian làm việc. Ngƣợc lại nếu ƣớc lƣợng dƣ cho một dự án sẽ dẫn đến việc phát sinh chi phí nhiều hơn so với mức cần thiết dẫn đến sự lãng phí đối với dự án. Trong suốt quá trình phát triển phần mềm, cho dù có sử dụng mô hình quản lý phần mềm nào đi nữa thì sau mỗi cột mốc phát triển phần mềm, các trƣởng dự án thƣờng phải hoạch định công việc cho cột mốc tiếp theo và tính toán lại những phần công việc đã thực hiện đƣợc ở cột mốc trƣớc. Điều đó dẫn đến việc ƣớc lƣợng đƣợc tiến hành xuyên suốt quá trình thực hiện dự án, trải qua từng bƣớc của quy trình phần mềm. Ở giai đoạn đầu, dự án còn ở dạng đơn giản, thiếu thông tin, việc ƣớc lƣợng trong giai đoạn này có độ chính xác không cao. Càng về những giai đoạn sau, các chi tiết của dự án đã đầy đủ, độ chính xác của ƣớc lƣợng sẽ tăng lên. Hình 1 cho thấy quá trình ƣớc lƣợng chính xác hơn sau mỗi giai đoạn của dự án phần mềm. 11 Hình 1.1: Đồ thị hình nón không chắc chắn [1] 1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm Các bƣớc chính trong ƣớc lƣợng dự án phần mềm là: - Ƣớc lƣợng kích thƣớc, phạm vi dự án: Đây là thông số ƣớc lƣợng rất đƣợc quan tâm là yếu tố về độ lớn phần mềm. Một ƣớc lƣợng chính xác về kích thƣớc phần mềm là cơ sở cho một ƣớc lƣợng có hiệu quả. Ta cần thu thập các thông tin về phạm vi của dự án bắt đầu với những mô tả với những yêu cầu của khách hàng. Tài liệu ƣớc lƣợng cần phải đƣợc làm mới lại sau mỗi lần có thêm thông tin phạm vi ƣớc lƣợng. Để ƣớc lƣợng kích thƣớc, phạm vi ta có thể dựa vào các dự án tƣơng tự trong quá khứ (nếu nhƣ ta đã từng làm). Chúng ta có thể ƣớc lƣợng cho dự án mới bằng cách dùng phép tính phần trăm của kích thƣớc với phần tƣơng tự của dự án trƣớc đó, sau đó sẽ tổng lại các kích cỡ đã đƣợc ƣớc lƣợng. Ngoài ra ta có thể dùng phƣơng pháp phân tích để ƣớc lƣợng kích thƣớc bằng cách đo độ lớn phần mềm bằng đơn vị dòng mã nguồn (SLOC – Source Line Of Code). Tuy nhiên trong khi phần mềm chƣa hoàn thành, thông số này phải phỏng đoán nên không tránh khỏi những sai sót. Để khắc phục tình trạng này ngƣời ta dùng đơn vị điểm chức năng (FP Function Point). Đơn vị này đƣợc tính toán dựa trên các yêu cầu về chức năng và phi chức năng của một dự án nên mang tính thực tế hơn. Hiện nay một đơn vị khác cũng đƣợc sử dụng là điểm đối tƣợng (OP – Object Point). Đây là đơn vị đƣợc tính toán dựa trên yêu cầu về số màn hình và báo biểu của phần mềm. Nó thƣờng đƣợc dùng để đo độ lớn phần mềm trong giai đoạn sơ khai của sự án, lúc những chi tiết dùng để tính điểm chức năng chƣa đƣợc làm rõ. 12 - Ƣớc lƣợng nỗ lực: Sau khi chúng ta đã có đƣợc một ƣớc lƣợng kích thƣớc, phạm vi của sản phẩm, chúng ta có thể tính toán đƣợc ƣớc lƣợng nỗ lực từ nó. Kích thƣớc của phần mềm là yếu tố quan trọng nhất trong việc xác định bao nhiêu nỗ lực là cần thiết để xây dựng nó. Tuy nhiên, kích thƣớc cuối cùng thì không đƣợc biết khi dự án vẫn còn đang đƣợc hình thành, và phần mềm chƣa thực sự tồn tại. Do đó, nếu kích thƣớc đƣợc sử dụng cho một mô hình ƣớc lƣợng nỗ lực, nó phải đƣợc ƣớc lƣợng ngay từ lúc đầu. Có 2 cách để tính toán nỗ lực là dùng dữ liệu lịch sử và sử dụng mô hình tính toán. Dùng dữ liệu lịch sử tức là dựa vào các dữ liệu nỗ lực và kích thƣớc của các dự án trƣớc đã sử dụng trong quá khứ để ƣớc lƣợng cho dự án hiện tại. Sau khi đã có đƣợc một nỗ lực tổng thể ta sẽ xác định các nỗ lực cho các hoạt động hoặc các giai đoạn bằng tỉ lệ phần trăm so với nỗ lực tổng thể. Trƣờng hợp ta không có dữ liệu của dự án trong quá khứ chúng ta có thể tiếp cận một số thuận toán đã hoàn thiện và đƣợc công nhận rộng rãi (ví dụ mô hình COCOMO, COCOMO II). Các mô hình này có đƣợc từ việc nghiên cứu một số lƣợng lớn các dự án đã đƣợc hoàn thành từ nhiều tổ chức khác nhau để xem xét các kích cỡ dự án so với tổng nỗ lực của dự án tổng. Vì dữ liệu đƣợc thu thập từ nhiều dự án của các tổ chức nên có thể độ chính xác so với dữ liệu so với tổ chức của mình nhƣng chúng có thể giúp chúng ta có đƣợc những ƣớc lƣợng nỗ lực gần đúng. - Ƣớc lƣợng tiến trình: Sau khi nỗ lực đã đƣợc biết hoặc đã đƣợc ấn định cố định ngay từ đầu, các thời gian biểu khác nhau có thể tính đƣợc tính, tùy thuộc vào số nhân sự đƣợc đƣa vào để thực hiện dự án. Ta sẽ ƣớc lƣợng số lƣợng ngƣời làm việc trên dự án, họ sẽ làm những gì, thời gian bắt đầu làm, thời gian kết thúc. Khi ta có đƣợc thông tin này ta sẽ phải tính toán để đƣa vào lịch trình theo thời gian. Ƣớc lƣợng lịch trình cho một dự án là một vấn đề phức tạp vì phần lớn dự án đều trễ tiến độ nguyên nhân là do mất sự kiểm soát tiến độ dự án. - Ƣớc lƣợng chi phí: Trong ngành sản xuất phần mềm yếu tố ƣớc lƣợng đƣợc quan tâm là chi phí phần mềm. Chi phí phần mềm bao gồm: Chí phí sản xuất: Chi phí để phát triển phần mềm dựa trên số công thực hiện dự án phần mềm. Chi phí môi trƣờng: Bao gồm những chi phí phát sinh trong quá trình phát triển dự án. Trong 2 loại chi phí này thì chi phí môi trƣờng phụ thuộc vào rất nhiều yếu tố nhƣ: giá cả, xu hƣớng thị trƣờng, mức độ lạm phát... nên việc ƣớc lƣợng là không khả thi. Trong đó chi phí sản xuất đƣợc tính toán trên công thực hiện dự án phần mềm nên việc ƣớc lƣợng có thể làm đƣợc. 13 1.3 Các phƣơng pháp ƣớc lƣợng Ƣớc lƣợng phần mềm là một quá trình phức tạp. Đầu vào của quá trình ƣớc lƣợng là các thông số, các thông số này ảnh hƣởng đến công việc thực hiện của dự án, có thể chia các thông số thành các loại sau: - Thông số về sản phẩm: những yếu tố của sản phẩm phần mềm ảnh hƣởng đến công thực hiện dự án: độ lớn, độ phức tạp, loại phần mềm. - Thông số về môi trƣờng: gồm những yếu tố môi trƣởng có ảnh hƣởng đến công thực hiện sự án nhƣ: quy trình thực hiện, công nghệ triển khai... - Thông số về đội ngũ phát triển: trình độ, khả năng chuyên môn, kinh nghiệm Các phƣơng pháp ƣớc lƣợng nỗ lực có thể đƣợc sử dụng: - Ƣớc lƣợng dựa vào chuyên gia: Phƣơng pháp này dựa vào các kinh nghiệm của những chuyên gia làm phần mềm, tuy nhiên phƣơng pháp này mang tính chủ quan, không phải kết quả lúc nào cũng tin cậy. - Ƣớc lƣợng dựa vào các dự án cũ: Phƣơng pháp này sử dụng những số liệu của các dự án phần mềm trƣớc đó, từ đó dự đoán ƣớc lƣợng cho dự án hiện tại - Ƣớc lƣợng bằng các mô hình thực nghiệm: Phƣơng pháp này sẽ sử dụng một mô hình thực nghiệm cụ thể để ƣớc lƣợng. Tuy nhiên phƣơng pháp này cần có các tham số về dự án 1.4 Tổng quan mô hình Agile Phƣơng pháp phát triển phần mềm linh hoạt đƣợc đƣa ra vào giữa những năm 90 nhƣ là một phần của sự nỗ lực chống lại những phƣơng pháp “nặng nề” – điển hình bởi những quy định khắt khe. Ban đầu chúng đƣợc gọi là “phƣơng pháp nhẹ”. Đến năm 2001, 17 thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt đã gặp gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần mềm linh hoạt hơn, nhanh hơn và hƣớng con ngƣời hơn. Họ đã thông qua tên gọi chính thức “phƣơng pháp linh hoạt” 1.4.1 Mô hình phát triển phần mềm Agile Agile là mô hình phát triển phần mềm linh hoạt, dựa trên phƣơng thức lặp (iterative) và tăng trƣởng (incremental). Nó sẽ gắn kết khách hàng vào quy trình phát triển của phần mềm, mọi ngƣời cố gắng cho ra sản phẩm càng nhanh càng tốt. Sau đó đƣa cho khách hàng dùng thử và phản hồi lại, đội ngũ phát triển sẽ tiếp tục phát triển các giai đoạn tiếp theo. Tùy vào dự án mà thời gian release ra sản phẩm dài hay ngắn (có thể 2 tuần, cũng có thể 1 tháng…) 14 Thuật ngữ "Agile" chính thức đƣợc sử dụng rộng rãi theo cách thống nhất kể từ khi “Tuyên ngôn Agile” đƣợc giới thiệu ra công chúng năm 2001. Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phƣơng pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. 1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý Tuyên ngôn phát triển phần mềm Agile [1] - Tuyên ngôn 1: Cá nhân và sự tƣơng tác hơn là quy trình và công cụ. Không phải lúc nào mọi việc đều có giải pháp mà giải pháp chính là nằm bên trong công việc. Đối với một số công việc để tìm giải pháp không chỉ tập trung vào lý thuyết mà phải trải qua thực tiễn. Ở đây bản tuyên ngôn nhấn mạnh vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong nhóm phát triển phần mềm. Nếu dự án có những thành viên có năng lực, luôn sẵn sàng chia sẻ kiến thức, hỗ trợ lẫn nhau trong công việc thì sẽ mang đến thành công. Nếu dự án của bạn có quy trình làm việc tốt, đƣợc hỗ trợ những công cụ tốt nhất nhƣng những thành viên không “cùng nhìn về một hƣớng” thì khả năng dự án thất bại là rất lớn. Ở Agile mọi ngƣời cùng làm việc trong nhóm, chia sẻ thông tin với nhau hơn là theo sát một quy trình hay công cụ nào đó. - Tuyên ngôn 2: Phần mềm chạy tốt hơn là tài liệu đầy đủ. Một phần mềm dù có tài liệu hƣớng dẫn tốt, chi tiết tới đâu nhƣng vận hành không hiệu quả thì xem nhƣ không đạt, vì vậy việc tạo ra sản phẩm phần mềm trong trọng hơn và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một cách chính xác. Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại. Tất cả các phƣơng pháp linh hoạt thể hiện ở Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định, Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là phần mềm chạy tốt, thƣờng đƣợc biết nhƣ "Định nghĩa của hoàn thành". Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vƣợt qua tất cả các kiểm thức và có thể vận hành bởi ngƣời dùng cuối. Ở mức thấp hơn, các nhóm phải vƣợt qua những kiểm thự đơn vị và kiểm thử hệ thống. - Tuyên ngôn 3: Cộng tác với khách hàng hơn là đàm phán hợp đồng: Việc ký kết hợp đồng là quan trọng nhƣng chƣa đủ. Một môi trƣờng hợp tác tốt sẽ giúp cho những ngƣời phát triển đƣa ra những giải pháp tốt nhất cho khách hàng, khách hàng và những ngƣời phát triển phải tƣơng tác với nhau để làm rõ các yêu cầu cũng nhƣ các vấn đề cần thiết. Bản tuyên ngôn khuyến khích khách hàng cũng tham một phần của dự án hơn chỉ là viết hợp đồng. 15 - Tuyên ngôn 4: Phản hồi với các thay đổi hơn là bám sát kế hoạch: Việc lập kế hoạch cho phát triển phần mềm là rất quan trọng. Một bản kế hoạch tốt sẽ giúp công việc đƣợc định hƣớng tốt hơn. Tuy nhiên trong thực tế có rất nhiều sự thay đổi và nếu nhƣ ta cứ bám sát và kế hoạch ban đầu mà không thay đổi theo thực tế thì sẽ dẫn đến sự thất bại. Vì vậy nhóm phát triển phần mềm phải luôn sẵn sàng đón nhận các sự thay đổi khi có yêu cầu. 12 nguyên lý sau tuyên ngôn Agile [1] - Ƣu tiên cao nhất là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị. - Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. - Thƣờng xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ƣu tiên cho các khoảng thời gian ngắn hơn. - Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án. - Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trƣờng và sự hỗ trợ cần thiết, và tin tƣởng họ để hoàn thành công việc. - Phƣơng pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. - Phần mềm chạy tốt là thƣớc đo chính của tiến độ. - Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và ngƣời dùng có thể duy trì một nhịp độ liên tục không giới hạn. - Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt. - Sự đơn giản – nghệ thuật tối đa hóa lƣợng công việc chƣa xong – là căn bản. - Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ đƣợc làm ra bởi các nhóm tự tổ chức. - Đội sản xuất sẽ thƣờng xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. 1.4.3 Các đặc trƣng của mô hình Agile Phát triển linh hoạt bản thân nó không phải là một phƣơng pháp. Nó là một thuật ngữ chung mô tả rất nhiều các phƣơng pháp linh hoạt. Tại thời điểm ký kết Tuyên ngôn Agile năm 2001, những phƣơng pháp này bao gồm: Scrum, XP, Crystal, FDD và DSDM. Mỗi phƣơng pháp phát triển linh hoạt có một cách tiếp cận hơi khác 16 nhau để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống nhƣ các ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hƣớng đối tƣợng theo những cách khác nhau. Phƣơng pháp linh hoạt có những đặc trƣng sau: - Tính lặp: Dự án sẽ đƣợc thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn này thƣờng có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết nhƣ lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm. Các phƣơng pháp agile thƣờng phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn. - Tính tăng trƣởng và tiến hóa: Cuối các phân đoạn, nhóm phát triển thƣờng cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thƣờng là đầy đủ, có khả năng chạy tốt, đƣợc kiểm thử cẩn thận và có thể sử dụng ngay. Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy đƣợc này sẽ đƣợc tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng đƣợc thỏa mãn. Sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt đƣợc trạng thái đủ để phát hành. - Tính thích nghi: Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng đƣợc điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hƣớng về mục tiêu v.v.) đều có thể đƣợc đáp ứng theo cách thích hợp. Theo đó, các quy trình agile thƣờng thích ứng rất tốt với các thay đổi. - Nhóm tự tổ chức và liên chức năng: Cấu trúc nhóm agile thƣờng là liên chức năng và tự tổ chức. Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control). - Quản lý tiến trình thực nghiệm: Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các giả định. Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lƣợc phát triển của mình. Theo thời gian, các chiến lƣợc này sẽ tiến gần đến trạng thái tối ƣu, nhờ đó nhóm có thể kiểm soát đƣợc tiến trình, và nâng cao năng suất lao động. - Giao tiếp trực diện: Mô hình Agile đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ. Về yêu cầu của khách hàng, agile khuyến khích 17 nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản. Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ sƣ (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai ngƣời này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu. Bản thân các nhóm agile thƣờng nhỏ để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Các nhóm phát triển thƣờng tạo ra các thói quen trao đổi trực diện một cách thƣờng xuyên. Một trong các cơ chế thƣờng thấy là các cuộc họp tập trung hằng ngày (daily meeting). Tại đây, tất cả các thành viên đƣợc yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc. Khi cơ chế này đƣợc thực hiện hiệu quả, nhóm luôn luôn nắm đƣợc tình hình công việc của mình, có các hành động thích hợp để vƣợt qua các trở lực để thực hiện thành công mục tiêu của dự án. - Phát triển dựa trên giá trị: Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thƣớc đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dƣ thừa không trực tiếp mang lại giá trị cho sản phẩm. Để vận hành đƣợc cơ chế “làm việc dựa trên giá trị”, nhóm agile thƣờng làm việc trực tiếp và thƣờng xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ƣu tiên cao hơn, mang lại giá trị hơn cho dự án. Nhờ đó các dự án agile thƣờng giúp khách hàng tối ƣu hóa đƣợc giá trị của dự án. Một cách gần nhƣ trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng. Các phƣơng pháp phát triển phần mềm linh hoạt hiện nay bao gồm: Extreme programming (XP), Scrum, Crystal family of methodologies, Feature Driven Development (FDD), The Rational Unified Process, Dynamic Systems Development Menthod (DSDM), Adaptive Software Development, Open Sourse Software Development, ngoài ra còn có các phƣơng pháp khác. 1.5 Giới thiệu Scrum 1.5.1 Giới thiệu Scrum là một phƣơng pháp Agile dùng cho phát triển sản phẩm. Scrum là một khung quản lý dự án đƣợc áp dụng rất rộng rãi, từ những dự án đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phức tạp với hàng trăm ngƣời tham gia, và kể cả những dự án đòi hỏi khung thời gian cố định. Trong Scrum, công việc đƣợc thực hiện bởi nhóm Scrum thông qua từng phân đoạn lặp liên tiếp nhau đƣợc gọi là Sprint. Để hiểu đƣợc Scrum thì cần hiểu nguyên lý của Scrum, các Vai trò, Tạo tác, Sự kiện và sự vận hành của một vòng đời Scrum. 18 Cốt lõi của qui trình Scrum đó là Sprint, một vòng thời gian của một tháng hoặc ít hơn, sự phát triển và tung ra sản phẩm có tiềm năng, hữu dụng đƣợc tạo ra. Những Sprints tối ƣu là sprint có thời hạn thông qua sự nỗ lực phát triển. Sprint mới sẽ bắt đầu ngày sau khi Sprint trƣớc kết thúc. Trong mỗi Sprint: - Không có sự thay đổi đƣợc thực hiện nhằm duy trì đƣợc kết quả của Sprint đó. - Chất lƣợng kết quả không đƣợc giảm và có thể làm rõ và thảo luận lại bởi chủ sản phẩm và đội phát triển. 1.5.2 Khung làm việc Scrum a. Ba giá trị cốt lõi: [6] a) Minh bạch (Transparency): Trong Scrum, minh bạch xem nhƣ là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin phải minh bạch và thông suốt. Từ đó mọi ngƣời với các vai trò khác nhau có đủ thông tin cần thiết để tiến hành các quyết định các giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn bảo đảm thông tin minh bạch cho các bên. b) Thanh tra (Inspection): Công tác thanh tra liên tục các hoạt động trong scrum bảo đảm cho việc phát triển các vấn đề cũng nhƣ giải pháp để thông tin đa dạng và hữu ích đến đƣợc với các bên tham gia dự án. Với việc truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và cải tiến liên tục trong Scrum. c) Thích nghi (Adaptation): Scrum là một trong những phƣơng pháp phát triển rất linh hoạt. Nhờ đó mang lại tinh thích nghi rất cao. Scrum có thể phản hồi lại các thay đổi một cách tích cực nhờ đó mang lại nhiều thành công lớn cho dự án. b. Ba vai trò: [6] Ba vai trò trong Scrum là: Product Owner, Nhóm Phát triển, và ScrumMaster. Tất cả hợp thành nhóm Scrum Product Owner: Là ngƣời chịu trách nhiệm về sự thành công của sản phẩm đang đƣợc phát triển. Product Owner có thể là ngƣời trực tiếp sở hữu sản phẩm hoặc có thể là đại diện cho các bên liên quan khác nhƣng luôn luôn là ngƣời chịu trách nhiệm và có tiếng nói cuối cùng về mọi quyết định liên quan đến sản phẩm. Công việc chủ yếu của Product Owner là tối ƣu hóa giá trị của sản phẩm thông qua việc quản lý thật tốt Product Backlog. ScrumMaster: Là ngƣời đảm bảo Nhóm Scrum hoạt động năng suất nhất thông qua việc áp dụng tốt Scrum. ScrumMaster không phải là ngƣời quản lý của các thành viên Nhóm Phát triển, cũng không phải là quản lý dự án, trƣởng nhóm, hay đại diện của nhóm. Thay vào đó, ScrumMaster phục vụ Nhóm Phát triển; là ngƣời giúp loại bỏ 19 các trở ngại, bảo vệ Nhóm Phát triển khỏi các tác động từ bên ngoài, và trợ giúp Nhóm Phát triển ứng dụng các kỹ thuật phát triển hiện đại. ScrumMaster cũng dạy, huấn luyện và hƣớng dẫn Product Owner Để đạt đƣợc điều này thì ScrumMaster có thể sử dụng một số kỹ thuật nhƣ dạy, huấn luyện để nhóm am hiểu về triết lý cũng nhƣ áp dụng tốt các kỹ thuật thực tế sử dụng trong Scrum. ScrumMaster cũng có nhiệm vụ loại bỏ tất cả các trở ngại mà nhóm gặp phải, bảo vệ nhóm trƣớc tất cả những nguyên nhân gây ảnh hƣởng tới công việc của nhóm. Nhóm Phát triển: Là tập hợp của từ 3 đến 9 thành viên chịu trách nhiệm trực tiếp tham gia sản xuất. Hai tính chất quan trọng nhất của Nhóm Phát triển đó là tự-tổ chức và liên-chức năng. Tự-tổ chức tức là các thành viên tự sắp xếp công việc, tự đƣa ra các quyết định để đạt đƣợc mục đích của nhóm mà không bị sự quản lý, điều khiển từ bất cứ ai bên ngoài nhóm, kể cả các lãnh đạo. Liên-chức năng có nghĩa là nhóm có đầy đủ tất cả các kỹ năng cần thiết để có thể độc lập hoàn thành tất cả các công việc mà không cần chờ đợi ai khác từ bên ngoài. Nhóm liên-chức năng tức là nhóm có đầy đủ các kỹ năng chứ không phải là mỗi thành viên đều phải có hết tất cả các kỹ năng. Ngoài ba vai trò kể trên, còn có các bên liên quan khác đóng góp vào sự thành công của sản phẩm, bao gồm các nhà quản lý, khách hàng và ngƣời dùng cuối. Một vài ngƣời liên quan chẳng hạn nhƣ những ngƣời quản lý chức năng (ví dụ, ngƣời quản lý kỹ thuật) có thể thấy vai trò của họ nếu còn giá trị thì cũng thay đổi khi áp dụng Scrum. Ví dụ: Họ hỗ trợ Nhóm Phát triển bằng cách tôn trọng các quy tắc và tinh thần của Scrum Họ giúp loại bỏ các trở ngại mà Nhóm Phát triển và Product Owner chỉ ra Họ sẵn sàng đóng góp chuyên môn và kinh nghiệm của mình c. Năm cuộc họp: [6] 1. Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint (xem thêm phần Sprint bên dƣới). Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ƣớc lƣợng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà đƣợc lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm. 20 2. Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng nhƣ chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint. 3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm. 4. Sprint Retrospective (Họp Cải tiến Sprint): Dƣới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng nhƣ bản thân sản phẩm. Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết. 5. Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint. Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ƣớc lƣợng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà đƣợc lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm d. Ba công cụ: [6] - Product Backlog: Khi một nhóm dự định chuyển sang Scrum thì trƣớc khi có thể bắt đầu Sprint đầu tiên họ cần có một Product Backlog, đây là danh sách các hạng mục cần phát triển của sản phẩm. Danh sách này đƣợc sắp xếp theo độ ƣu tiên do Product Owner quyết định. Product Owner là ngƣời chịu trách nhiệm quản lý Product Backlog, kể cả nội dung, đánh giá độ ƣu tiên cho đến việc cập nhật Product Owner cần phải đƣa ra các quyết định đánh giá ƣu tiên xuyên suốt toàn bộ phạm vi, đại diện cho quyền lợi của các bên liên quan (bao gồm cả Nhóm Phát triển). Các hạng mục trong Product Backlog có thể là các tính năng mong muốn của sản phẩm, hoặc các cải tiến kỹ thuật lớn, hoặc các lỗi kỹ thuật đã đƣợc phát hiện… Product Backlog tồn tại (và tiến hóa) trong suốt vòng đời của sản phẩm; nó cũng là lộ trình của sản phẩm. Một Product Backlog tốt cần đạt đƣợc tiêu chí DEEP Detailed Appropriately (Chi tiết hợp lý): Các hạng mục có độ ƣu tiên cao cần đƣợc làm mịn và chi tiết hơn so với hạng mục có ƣu tiên thấp hơn vì chúng sẽ đƣợc lựa chọn để thực hiện trƣớc. 21