Đề tài Tìm hiểu về quy trình phát triển phần mềm theo Agile

MỤC LỤC LỜI MỞ ĐẦU Đi cùng với xu thế phát triển mạnh mẽ của các ngành công nghệ khác trên thế giới, công nghệ phần mềm cũng đang mở ra một cánh cửa cho các tiếp cận tiến bộ. Khá nhiều công ty, tổ chức đã nhận thức được tầm quan trọng của ngành công nghệ này và đã có những bước tiếp cận đáng ghi nhận. Tuy nhiên, song song với những bước phát triển như vậy, nhiều mặt hạn chếvề chất lượng phần mềm vẫn đã và đang là mối quan tâm của nhiều người, nhiều tổ chức.  Là sinh viên của khoa công nghệ thông tin, chúng em sớm đã được tiếp cận với môn công nghệ phần mềm và tìm hiểu khá nhiều qui trình hỗ trợ và nâng cao chất lượng phần mềm. Chúng em đã nhận thức được tầm quan trọng của các quy trình phát triển phần mềm. Mỗi qui trình có những mặt vượt trội riêng và nhìn chung mục đích chính của chúng cũng để nâng cao chất lượng sản phẩm và hạn chế rủi ro cho phần mềm làm ra. Tuy nhiên, trong những qui trình ấy chúng em nhận thấy phát triển phần mềm theo Agile là khá tiềm năng. Chính vì vậy, chúng em đã chọn đề tài báo cáo là “Tìm hiểu về quy trình phát triển phần mềm theo Agile”. Nhóm sinh viên thực hiện: Đỗ Thị Thanh Tuyền Nguyễn Quang Hoàng Đoàn Thị Kim Dung Trần Văn Thành Hà Thị Thu Hương Dương Văn Hà BẢNG PHÂN CÔNG CÔNG VIỆC Tên nhóm Thành viên Nội dung công việc Nhóm 1 Đỗ Thị Thanh Tuyền Nguyễn Quang Hoàng Phần I: Tổng quan về công nghệ phần mềm và quy trình phát triển phần mềm. Cụ thể: Tìm hiểu chung về công nghệ phần mềm, quy trình phát triển phần mềm. Tìm hiểu và rút ra nhận xét ưu điểm, nhược điểm của các mô hình phát triển phần mềm truyền thống (phát triển theo kế hoạch). Nhóm 2 Đoàn Thị Kim Dung Trần Văn Thành Phần II: Quy trình phát triển phần mềm theo Agile. Cụ thể: Tìm hiểu chung về agile, sự ra đời, nguyên lý làm việc, đặc điểm và các bước phát triển phần mềm theo agile. Rút ra ưu nhược điểm của agile và so sánh agile với các phương pháp khác đặc biệt là các phương pháp trước nó Nhóm 3 Hà Thị Thu Hương Dương Văn Hà Phần III: Các quy trình phát triển phần mềm theo hướng Agile Cụ thể:Tìm hiểu 3 quy trình phát triển phần mềm được áp dụng theo nguyên lý của agile là Scrum, ASD và XP. Lưu ý: Các nhóm phải tìm hiểu tất cả các phần nhưng chú trọng nhiều hơn vào các phần đã được giao. PHẦN I. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM VÀ QUY TRÌNH PHÁT TRIỂN PHẦN MỀM I. Tìm hiểu chung về công nghệ phần mềm. 1. Công nghệ phần mềm là gì ? - Phần mềm máy tính là gì? Phần mềm máy tính (Computer software) là các sản phẩm do nhà phát triển phần mềm thiết kế và xây dựng nhằm phục vụ một mục đích nào đó. - Công nghệ phần mềm là gì? Công nghệ phần mềm (Software Engineering) là các hoạt động bao gồm: phát triển, đưa vào hoạt động, bảo trì, và loại bỏ phần mềm một cách có hệ thống. - Mục tiêu của công nghệ phần mềm là tạo ra những phần mềm tốt nhất với thời gian ngắn nhất, giảm đến tối thiểu những rủi ro có thể gây ra cho các khách hàng. - Ngành học công nghệ phần mềm bao trùm kiến thức, các công cụ, và các phương pháp cho việc định nghĩa yêu cầu phần mềm, cũng như việc thực hiện các tác vụ thiết kế, xây dựng, kiểm thử (software testing), và bảo trì phần mềm. Ngoài ra, công nghệ phần mềm còn sử dụng kiến thức của các lĩnh vực như kỹ thuật máy tính, khoa học máy tính, quản lý, toán học, quản lý dự án, quản lý chất lượng, công thái học phần mềm (software ergonomics), và kỹ nghệ hệ thống (systems engineering). 2. Lịch sử phát triển của công nghệ phần mềm. - Thập niên 1940: Chương trình máy tính được viết bằng tay. - Thập niên 1950: Các công cụ đầu tiên xuất hiện như phần mềm biên dịch Macro Assembler và phần mềm thông dịch đã được tạo ra. Các trình dịch được tối ưu hóa lần đầu tiên ra đời. - Thập niên 1960: Các công cụ thế hệ thứ hai như trình dịch tối ưu hóa và kiểm tra mẫu được thực hiện. Khái niệm công nghệ phần mềm được bàn thảo rộng rãi. - Thập niên 1970: Các công cụ phần mềm như UNIX các vùng chứa mã, các lệnh make… được kết hợp với nhau. - Thập niên 1980: Các máy PC và máy trạm ra đời. Cùng lúc đó có mô hình dự toán khả năng. Lượng phần mềm tiêu thụ mạnh. - Thập niên 1990: Phương pháp lập trình hướng đối tượng ra đời. Các quá trình nhanh như lập trình cực hạn được chấp nhận rộng rãi. Chính vì vậy, máy tính và internet phát triển rộng rãi. - Hiện nay: Các phần mềm biên dịch như là .net, PHP, Java làm cho việc phát triển phần mềm dễ dàng hơn. Quy trình phát triển phần mềm hỗ trợ cũng đa dạng. II. Quy trình phát triển phần mềm truyền thống. 1. Đặc điểm. - Các phương pháp truyền thống là các phương pháp thiên về kế hoạch, quá trình phát triển phần mềm phải tuân theo một quy trình nghiêm ngặt. Trong quá trình phát triển phần mềm, rất nhiều tài liệu được tạo ra, được xét duyệt và đó là một yếu tố quan trọng trong quản lí rủi ro. - Với các phương pháp này, toàn bộ quá trình phát triển thường được lên kế hoạch chi tiết và các tài liệu trước cũng như trong quá trình phát triển được chuẩn bị đầy đủ. Quá trình phát triển được thực hiện theo quy trình được định trước, và việc tuân thủ quy trình sẽ làm tăng chất lượng phần mềm và giảm rủi ro. - Theo các phương pháp này thì quá trình sản xuất phần mềm giống như sản xuất các mặt hàng công nghiệp khác. Những người phát triển thực hiện công việc một cách nghiêm ngặt theo các chuẩn và quy trình, không yêu cầu sáng tạo nhiều. Những người quản lí chỉ cần tăng năng lực sản xuất và đạt được các mục tiêu như: - Giảm thiểu lỗi và công việc diễn ra trơn tru. - Cố gắng giữ ổn định: về tổ chức, sản lượng… - Chuẩn hóa mọi thao tác và buộc mọi người tuân theo một cách nghiêm ngặt. - Không cho phép sự sai sót. 2. Các bước trong mô hình truyền thống Xác định yêu cầu: Đây là bước đầu tiên của quy trình phát triển phần mềm. Nó gồm 2 khía cạnh: - Mô hình hóa nghiệp vụ: Liên quan đến việc hiểu các nghiệp vụ chung của phần mềm trong văn cảnh cụ thể của nó. - Mô hình hóa yêu cầu hệ thống: Xác định được yêu cầu thực sự của khách hàng, xem khách hàng cần gì để biết được ta sẽ phải làm gì, không cần làm gì và xác định càng chi tiết càng rõ ràng càng tốt. Phân tích yêu cầu: Phân tích có nghĩa là phải xem xét xem ta đang phải đối mặt với vấn đề gì? Trước khi đi vào thiết kế ta phải phân tích vấn đề một cách rõ ràng. Từ đó mới biết ta thực sự hiểu về sản phẩm mà khách hàng yêu cầu hay chưa? Điều này liên quan đến khách hàng, người dùng cuối. Thiết kế: Trong pha thiết kế chúng ta hành động để giải quyết vấn đề hay nói cách khác chúng ta đưa ra những quyết định dựa trên kinh nghiệm, ước lượng hay trực giác. Ta thiết kế và xem nó sẽ được triển khai như thế nào. Thiết kế hệ thống thường phân ra thành 1 hệ thống con logic (tiến trình) và hệ thống con vật lý (máy tính, mạng) quyết định cách thức máy móc làm việc với nhau từ đó lựa chọn công nghệ. Đặc tả: Pha đặc tả thường bị bỏ qua. Thuật ngữ đặc tả được dùng theo nhiều cách khác nhau. Ví dụ như đầu ra của pha yêu cầu là một đặc tả về hệ thống ta cần làm, thuật ngữ đặc tả dùng để mô tả hành vi mong đợi của một thành phần trong chương trình. Đặc tả có thể dùng trong trường hợp sau: - Là cơ sở để kiểm tra thiết kế phần mềm trong thực thi hệ thống. - Văn bản là các thành phần phần mềm có thể cài đặt bởi bên thứ ba. - Để mô tả cách thức code hay sử dụng lại code trong các ứng dụng khác. Cài đặt: Giai đoạn này chúng ta sẽ viết các đoạn code nhỏ cho các chương trình con. Công việc chính là viết phần thân các phương thức trong lớp thiết kế. Kiểm thử: Sau khi phần mềm đã hoàn thành thì cần kiểm tra lại xem nó có đáp ứng nhu cầu khách hàng hay chưa. Cách tốt nhất mà người ta hay làm là thực hiện các test nhỏ trong suốt quá trình phát triển phần mềm hệ thống để đảm bảo chất lượng. Triển khai: Giai đoạn này quan tâm đến phần cứng và phần mềm tại nơi người dùng cuối. Bảo trì: Sau khi hệ thống được triển khai có thể có nhiều lỗi hệ thống hay cũng có thể khách hàng yêu cầu sửa đổi nâng cấp…Vì, vậy cần có quá trình bảo trì hệ thống. 3. Một số mô hình phát triển phần mềm truyền thống (phát triển theo kế hoạch) a. Mô hình thác nước (waterfall model) Ý tưởng: Mô hình thác nước hay còn gọi là mô hình tuyến tính hay mô hình kinh điển (classic model). Trong mô hình này, quy trình phát triển trông giống như một dòng chảy, với các giai đoạn được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt giai đoạn. Cụ thể, quá trình sẽ được thực hiện tuần tự qua các giai đoạn: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì. Tức là mô hình này sẽ xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau. Sau khi phân tích yêu cầu thì đặc tả yêu cầu, đưa cho khách hàng xem xét. Nếu khách hàng chấp nhận thì sẽ tiến hành tuần tự một loạt các giai đoạn như trên. Chỉ đưa sản phẩm cho khách hàng khi đã hoàn thiện. Mô tả mô hình: Phân tích yêu cầu Thiết kế Cài đặt và thử nghiệm đơn thể Thử nghiệm tổng thể Bảo trì và phát triển Hình 1: Mô hình thác nước Ưu điểm: - Tài liệu đầy đủ lên dễ bảo trì - Dễ phân công công việc, phân bố chi phí, giám sát công việc. - Kiến trúc hàng đợi ổn định. Nhược điểm: - Đôi khi tài liệu đặc tả mang tính chất kĩ thuật lên làm khách hàng khó mà hiểu hết được và do đó dễ dẫn đến hiểu sai yêu cầu khách hàng. - Mối quan hệ giữa các giai đoạn không được thể hiện. - Hệ thống phải được kết thúc ở từng giai đoạn do vậy khó mà thực hiện theo thay đổi của khách hàng yêu cầu. - Chỉ tiếp xúc với khách hàng ở pha đầu tiên nên phần mềm không đáp ứng nhu cầu khách hàng. Hơn nữa làm tuần tự đến giai đoạn cuối hoàn thiện mới bàn giao sản phẩm cho khách hàng thì dễ tạo ra sản phẩm không phải cái khách hàng cần. - Chi phí phát triển dự án lớn mà khả năng rủi ro cao. b. Mô hình làm bản mẫu (Prototyping model) Ý tưởng: Dựa vào những yêu cầu của khách hàng người phát triển phần mềm sẽ xây dựng một mẫu thử ban đầu đưa cho người sử dụng xem xét, sau đó tinh chỉnh qua nhiều mẫu thử cho đến khi thỏa mãn yêu cầu người sử dụng thì dừng lại. Có 2 phương pháp với mô hình này: - Phát triển thăm dò: Thực hiện với những yêu cầu rõ ràng và sau đó bổ sung thêm những yêu cầu mới của khách hàng và dừng khi tất cả các yêu cầu của khách hàng được thỏa mãn. - Loại bỏ mẫu thử: Thường sử dụng trong trường hợp yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao cho khách hàng. Từ đó ta sẽ biết được yêu cầu nào là cần thiết với người dùng. Như vậy phương pháp này sẽ giúp sáng tỏ yêu cầu người dùng. Mô hình: Phác thảo nét chính Xây dựng phần mềm Sử dụng phần mềm Hệ thống thích hợp Chuyển giao phần mềm Đ S Hình 2: Mô hình làm bản mẫu Ưu điểm: Thu được nhiều phiên bản hệ thống lên luôn đáp ứng nhu cầu khách hàng. Nhược điểm: - Thiếu tầm nhìn của cả quy trình - Hệ thống thường có cấu trúc nghèo nàn. - Yêu cầu các kĩ năng đặc biệt (ví dụ: ngôn ngữ để tạo mẫu thử nhanh chóng). - Chỉ nên áp dụng với hệ thống nhỏ hoặc vừa. c. Mô hình xoắn ốc (The spiral model) Ý tưởng: Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới – phân tích rủi ro. Đầu tiên, nhóm phát triển sẽ thu thập nhu cầu khách hàng (những yêu cầu này có thể đầy đủ hoặc còn mơ hồ). Sau đó, thực hiện một số phân tích để tăng hiểu biết về vấn đề được đặt ra ở pha xác định yêu cầu.Tiếp theo, phác thảo ra một hệ thống phù hợp nhất với yêu cầu ban đầu. Mặc dù những bước trước là chưa hoàn chỉnh nhưng vẫn tiến hành viết code. Khi đã hoàn thành code ban đầu ta đưa cho khách hàng xem xét. Bằng cách đó thông qua mỗi chu trình chúng ta sẽ tăng thêm sự hiểu biết về vấn đề nào đó và về các giải pháp đã được đề xuất. Qua nhiều lần xoắn ốc, chúng ta có thể mổ xẻ yêu cầu và phân tích thiết kế một cách chính xác hơn để đáp ứng với các yêu cầu nhiều hơn. Sau khi hệ thống hoàn thành, có lẽ qua 3 hoặc 4 lần xoắn ốc chúng ta có thể thực hiện kiểm tra hệ thống một cách nghiêm ngặt. Mô hình Kế hoạch Phân tích rủi ro Khách hàng đánh giá Xây dựng sản phẩm Lập kế hoạch và thu tập yêu cầu ban đầu Kế hoạch dựa trên các đánh giá của khách hàng Đánh giá sản phẩm Hướng hoàn thiện của hệ thống Bản mẫu đầu tiên Các bản mẫu tiếp theo Tiếp tục phát triển hệ thống? Phân tích rủi ro trên cơ sở các yêu cầu ban đầu Phân tích rủi ro trên cơ sở các phản ứng của khách hàng Hình 3: Mô hình xoắn ốc Ưu điểm: - Phân tích rủi ro làm tăng độ tin cậy dự án. - Cho phép thay đổi yêu cầu cho mỗi vòng xoắn. - Một rủi ro nào đó chưa được giải quyết, dự án sẽ chấm dứt. - Kiểm soát rủi ro ở từng giai đoạn phát triển - Đánh giá chi phí chính xác hơn các phương pháp khác Nhược điểm: - Phức tạp và không thích hợp với các dự án nhỏ, ít rủi ro. - Cần có kĩ năng tốt về phân tích rủi ro. - Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn. - Đòi hỏi năng lực quản lí. d. Mô hình đài phun nước (mô hình hướng đối tượng). Ý tưởng: Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem như là một hệ thống các thực thể tác động qua lại để đạt được một mục đích nào đó. Mô hình này tương ứng với mô hình thác nước trong cách tiếp cận hướng thủ tục ở trên. Ở đây, ta thấy trong có những phần lặp và giao nhau giữa các bước phân tích, thiết kế và cài đặt. Ưu điểm Hỗ trợ việc lặp lại bên trong các giai đoạn song song, song song hóa giai đoạn. Nhược điểm: hiếu kỉ luật thực hiện công việc lung tung bừa bãi. Mô hình Các đối tượng trong không gian lời giải Các đối tượng trong chương trình Bảo trì Ứng dụng Phát triển trong tương lai LTHĐT TKHĐT PTHĐT Lập trình hướng đối tượng Thiết kế hướng đối tượng Phân tích hướng đối tượng Các đối tượng trong không gian bài toán Hình 4:Mô hình đài phun nước PHẦN II. TÌM HIỂU QUY TRÌNH AGILE I. Sự ra đời của mô hình agile 1. Sự cần thiết của một mô hình phát triển phần mềm mới Ngày nay, các phần mềm mà con người ra càng phức tạp. Các thuật toán ngày càng phức tạp khó xây dựng và quản lí. Chính vì vậy, những nhà quản lí phần mềm đã không ngừng học hỏi và tìm kiếm để tạo ra phương thức phát triển phần mềm tốt hơn. So với trước đây, con người đã không ngừng tạo ra những chiếc máy tính rẻ hơn nhanh hơn, nhiều ngôn ngữ lập trình mạnh mẽ ra đời, số lượng nhiều hơn cần thiết phải có những công cụ hỗ trợ và có những hiểu biết sâu sắc hơn về lý thuyết phần mềm. Máy tính đã làm thay đổi cả thế giới, thúc đẩy sự trao đổi thông tin và thay đổi một cách triệt để kỳ vọng của con người về cách thức mà phần mềm làm việc. Chúng ta có rất nhiều phương pháp giúp xác định con đường phát triển phần mềm ví dụ như một số quy trình: - Mô hình thác nước. - Mô hình xoắn ốc. - Mô hình hướng đối tượng. - Mô hình làm bản mẫu. Các phương pháp truyền thống kể trên cố gắng trang bị một khả năng dự đoán trước cho quy trình phát triển phần mềm. Vì vậy, chúng có thể tạo ra một bản kế hoạch từ thời điểm đầu dự án và xác định được thời gian hoàn thành của dự án. Nhưng vấn đề quan trọng nhất vẫn là “sự thay đổi yêu cầu người dùng”. Bởi vì một phần mềm tốt là phần mềm mà đem lại cho khách hàng sự hài lòng. Tuy vậy những phương pháp truyền thống đang hạn chế sự thay đổi yêu cầu từ khách hàng. Điều này giúp duy trì kế hoạch dự án ban đầu nhưng không đem lại sự thỏa mãn hoàn toàn cho khách hàng. Chính sự hạn chế từ những phương pháp truyền thống mà cần có một phương pháp hay quy trình phát triển phần mềm mới ra đời. Và quy trình phát triển phần mềm linh hoạt agile đã phần nào đáp ứng được yêu cầu ấy. 2. Agile là gì? - Phương pháp phát triển phần mềm Agile (Agile development Method) ra đời từ đầu những năm 90, với ý tưởng khắc phục những nhược điểm của mô hình truyền thống cụ thể là mô hình thác nước. Agile là tên gọi chung để chỉ các phương pháp phát triển nhanh. “Agile” có nghĩa là nhanh nhẹn, khéo léo trong hành động -Agile software development (phương thức phát triển phần mềm linh hoạt) với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ đầu. Phương thức này tập chung vào tính đơn giản: tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai. - Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mềm trong những khung thời gian ngắn và sự cộng tác chặt chẽ với khách hàng. Mỗi bước lặp (iteration) giống như phát triển một phần mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test, viết tài liệu. Điểm nổi bật là khả năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu. - Điểm quan trọng làm lên sự khác biệt của Agile so với các mô hình truyền thống đó là: các mô hình truyền thống là mô hình theo kế hoạch, còn mô hình agile thì không nhất thiết phải tuân theo kế hoạch, nó có thể có những bước đột phá để tạo ra một phần mềm hiệu quả nhất. II. Tìm hiểu chung về agile 1. Tuyên ngôn agile Tuyên ngôn Agile được viết như sau: “Chúng tôi tìm kiếm những phương pháp tốt hơn để phát triển và giúp người khác phát triển phần mềm. Qua hoạt động đó, chúng tôi sẽ trân trọng: cá nhân và sự tương tác hơn là quy trình và công cụ; phần mềm hoạt động được hơn là việc thu thập tư liệu phát triển; hợp tác với khách hàng hơn là thương thuyết về hợp đồng; phản ứng theo sự thay đổi hơn là theo sát kế hoạch. Nghĩa là, mặc dù có những giá trị cố hữu ở ‘cánh hữu’ (truyền thống), nhưng chúng tôi trân trọng các giá trị ‘cánh tả’ (của đổi mới) nhiều hơn”. - Cá nhân và tương tác hơn là quy trình và công cụ: Câu đầu tiên này cho ta thấy không phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp chính là nằm bên trong của công việc. Và đề tìm được giải pháp, thì không chỉ dựa vào các lý thuyết mà phải trực tiếp làm công việc phát triển phần mềm. Tất nhiên quy trình và công cụ cũng là điều quan trọng. Sẽ không thể có một phần mềm tốt nếu như quy trình và công cụ không tốt. Nhưng điều mà bản tuyên ngôn nhấn mạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũ phát triển phần mềm. Ý nghĩa quan trọng nhất của Agile là mọi người cùng làm việc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn là tập trung theo sát một quy trình hay công cụ nào đó. - Phần mềm hoạt động được hơn là việc thu thập tư liệu để phát triển: Điều này không có nghĩa là chúng ta không phải thu thập lại tư liệu để phát triển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều hơn cho việc hoàn tất công việc. Bởi vì đối với một dự án muốn thành công thì phải thu thập tài liệu đầy đủ. Nhưng bản thân tài liệu cũng không thể giúp được gì nếu không có một sản phẩm phần mềm thực sự. Vì thế, việc tạo ra sản phẩm phần mềm quan 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. - Hợp tác với khách hàng hơn là thương thuyết hợp đồng: Việc ký kết hợp đồng là quan trọng nhưng không đủ. 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 giải pháp tốt nhất cho khách hàng. Các hợp đồng định nghĩa những điều khoản ràng buộc mà trong đó cả hai bên đối tác phải tuân theo, những người phát triển cần hợp tác với khách hàng để có thể hiểu rõ yêu cầu cũng như những gì cần phải đưa ra. Agile tập trung vào việc khuyến khích khách hàng cùng tham gia vào dự án hơn là chỉ viết hợp đồng để rồi khách hàng sẽ chẳng làm gì với nhóm dự án phần mềm. - Phản ứng theo thay đổi hơn là theo sát kế hoạch: Việc lập kế hoạch cho phát triển phần mềm là không thể thiếu. Kế hoạch giúp công việc định hướng tốt hơn. Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nhất nhất tuân theo kế hoạch sẽ dễ dẫn đến thất bại. Do đó cần đáp ứng với thay đổi để có sự điều chỉnh sao cho phù hợp. Chính vì vậy, nhóm phát triển luôn sẵn lòng đón nhận thay đổi hơn là chỉ làm theo kế hoạch dự án (có trước) vì thay đổi luôn diễn ra và cả kế hoạch dự án cũng sẽ thay đổi khi yêu cầu thay đổi. 2.Nguyên tắc agile: Nguyên tắc Miêu tả Khách hàng tham gia Khách hàng nên tham gia chặt chẽ trong suốt quá trình phát triển. Vai trò của họ là cung cấp và quy định mức độ ưu tiên các yêu cầu mới về hệ thống, và đánh giá hệ thống tại các lần lặp (iterations of the system