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

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). Chuyển giao tăng dần Phần mềm được phát triển một cách tăng dần từng đợt (increment), trong đó khách hàng chỉ ra các yêu cầu cần được đưa vào mỗi đợt. Con người thay vì quy trình Kĩ năng phát triển của đội cần được ghi nhận và khai thác. Các thành viên của đội cần được tự do phát triển cách làm việc của riêng mình mà không cần đến các quy trình quy phạm định trước. Chấp nhận thay đổi Hiểu rằng hệ thống sẽ thay đổi nên thiết kế hệ thống sao cho nó có thể chấp nhận được thay đổi đó. Gìn giữ tính giản dị dễ hiểu Chú trọng vào tính giản dị dễ hiểu của phần mềm đang được phát triển cũng như của quy trình phát triển. Chủ động nỗ lực loại bỏ sự phức tạp ra khỏi hệ thống bất cứ khi nào có thể. Cụ thể quy trình phát triển phần mềm theo hướng Agile có 12 nguyên tắc như sau: - Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và liên tục. - Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối. - Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt hơn chu kì dài. - Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hàng ngày. - Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ. - Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp. - Các chức năng đã họat động là thước đo chính cho tiến độ dự án. - Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án một cách liên tục. - Liên tục cải tiến chất lượng thiết kế và mã nguồn. - Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt. - Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ. - Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc. 3. Đặc điểm của mô hình agile: - Phát triển dựa trên quy trình phát triển lặp (interative development). Mỗi dự án được chia thành nhiều mảng nhỏ dễ sử dụng và thay đổi khi khách hàng yêu cầu thay đổi. Dự án này sẽ thực hiện từng phần nhỏ này như những dự án nhỏ cho đến khi tất cả các yêu cầu của khách hàng được đáp ứng và dự án được bàn giao. - Cứ mỗi khi bàn giao các phần nhỏ được hoàn thành cho khách hàng, khách hàng có thể đưa ra các thay đổi hoặc yêu cầu mới cho dự án. Theo đó nhóm phát triển phần mềm sẽ cập nhập và sửa lại sản phẩm cho đúng yêu cầu khách hàng mà không cần làm lại từ đầu. - Từng phần nhỏ của dự án sẽ được test ngay trong quá trình làm dự án bằng các Unit test tương ứng bởi chính các lập trình viên hay các tester độc lập. Quá trình test được thực hiện trong quá trình phát triển trước khi tích hợp phần mềm. - Yêu cầu về việc gặp mặt trao đổi thông tin thường xuyên, cùng bàn bạc và thống nhất để hoàn thành dự án đúng thời hạn vì trong phương pháp Agile, tại mỗi thời điểm thì cả nhóm phải cùng tập trung phát triển một mảng của dự án. - Vì các quá trình của Agile đều được thực hiện với nhân lực hoàn toàn là các lập trình viên nhiều hơn và có kinh nghiệm trong lập trình và kiểm thử. III. Quy trình thực hiện Hình 5: Mô hình Agile tổng quát 1. Lập kế hoạch. Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên. Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án. Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp. Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc. 2. Phân tích. Agile không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu. Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này. Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết kế giao diện riêng. 3. Thiết kế và lập trình Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình. Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng. Mã nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra. 4. Test. Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất lượng sản phẩm. Các lập trình viên thực hiện unit test và integration test. Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test. Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn. Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệthống một cách liên tục) và được chạy bởi các lập trình viên khi họ tích hợp code mới vào hệ thống. Lập trình theo cặp góp phần làm tăng chất lượng công việc. 5 . Bàn giao sản phẩm. Phần mềm sẽ được trình chiếu hàng tuần và đưa cho khách hàng xem xét,góp ý. Nếu không có thay đổi thì tiến hành thực hiện và cuối cùng khi sản phẩm hoàn thành thì bàn giao cho khách hàng. IV. Những vấn đề cần xem xét để quyết định chọn phát triển theo hướng agile. 1. Cần trả lời những câu hỏi sau - Hệ được phát triển thuộc loại nào? - Hệ có khả năng bị kiểm duyệt từ bên ngoài? - Vòng đời của hệ? - Hệ được phát triển lớn hay nhỏ? - Đội phát triển được tổ chức thế nào? - Khả năng của người thiết kế và lập trình viên đến đâu? - Có sẵn những công nghệ nào để hỗ trợ phát triển? - Có cần phải đặc tả và thiết kế chi tiết trước khi cài đặt hay không? - Chiến thuật bàn giao có tăng dần khả thi không? - Có vấn đề văn hóa hay tổ chức nào có thể ảnh hưởng đến phát triển hay không? 2. Điều kiện áp dụng quy trình agile. Agile là một phương pháp tốt, tuy nhiên không phải trường hợp nào cũng áp dụng được phương pháp này. Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: đối với dự án này, điều kiện của công ty như thế này thì liệu phương pháp Agile có giúp bạn thành công hơn khi áp dụng các phương pháp khác hay không? Các dự án có đặc điểm sau đây có thể phù hợp với Agile: Mức độ rủi ro thấp Mức độ rủi ro của dự án có thể được hiểu là khả năng thực hiện và mức độ thành công của dự án. Dự án nào có tính khả thi thấp, tức là mức độ rủi ro cao thì không nên áp dụng mô hình này. Bởi vì dự án theo agile sẽ tốn rất nhiều chi phí. Ví dụ như khách hàng thường xuyên thay đổi yêu cầu thì bên làm dự án sẽ phải thực hiện lại cho phù hợp yêu cầu. Như vậy, nếu như rủi ro cuối cùng dự án vẫn không thể hoàn thành thì rất tốn thời gian, công sức và tiền bạc. Thành viên nhóm có kinh nghiệm Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn, do đó phương pháp này đòi hỏi có những cá nhân tài năng, những người sẵn lòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm qua nhiều công đoạn trong vòng đời truyền thống của sản phẩm. Phương pháp Agile cần có các cá nhân đa năng, có động lực, biết nghiên cứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết để hiểu thấu các vấn đề của khách hàng. Họ cũng phải là những người làm việc nhóm có tính kỷ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đời sản phẩm đúng hạn thời gian cho phép. Đặc biệt, họ phải có kĩ năng hoạt động theo nhóm tốt để thường xuyên trao đổi hợp tác với các thành viên trong nhóm. Nhu cầu thay đổi thường xuyên Khi thực hiện phương pháp này, các thành viên trong nhóm sẽ tiếp xúc thường xuyên với khách hàng, trao đổi thường xuyên để cùng hoàn thiện dự án. Nếu bên khách hàng có thay đổi yêu cầu, cả hai bên sẽ cùng ngồi với nhau bàn bạc lại để tìm ra giải pháp tối ưu nhất. Do vậy, đối với các dự án có tính ổn định cao, ít thay đổi thì áp dụng phương pháp này là không cần thiết. Kích thước nhóm nhỏ, các thành viên làm việc cùng một địa điểm Xuất phát từ yêu cầu trao đổi thông tin thường xuyên giữa các thành viên trong nhóm, nên phương pháp Agile đòi hỏi nhóm không cần quá nhiều thành viên, nếu quá nhiều thành viên sẽ làm cho sự quản lý nhóm, trao đổi giữa các thành viên trong nhóm trở nên không hiệu quả. Mặt khác, yêu cầu quan trọng nữa là các thành viên phải cùng làm việc tại cùng một địa điểm, khi đó sự trao đổi thông tin mới có hiệu quả hơn. Văn hóa công ty ưa thích sự “không trật tự” Bởi vì có như thế các thành viên mới mạnh dạn đưa ra những chính kiến của mình trong quá trình làm việc nhóm. Nhằm phát huy tính sáng tạo cao nhất của các thành viên. Trái lại, những điều kiện sau đây là vật cản cho việc áp dụng Agile: Kích thước nhóm lớn. Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource). Văn hóa làm việc theo mệnh lệnh. VI. Ưu nhược điểm của phương pháp: 1. Ưu điểm: - Agile là sự lựa chọn rất tốt cho các dự án nhỏ bởi dự án nhỏ thường có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên. Với phương pháp này bạn phải chia yêu cầu ra thành những nhiệm vụ nhỏ mà có thể dễ dàng quản lý. - Với agile khách hàng có thể được xem trước dự án trong quá trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần và có thể đưa cho khách hàng xem từng nhiệm vụ đã thực hiện .Bằng việc đó sẽ không bị chậm và khách hàng sẽ có sản phẩm sơ lược thay vì đợi đến khi dự án hoàn thành. Chính vì vậy, nếu qua mỗi giai đoạn, mỗi nhiệm vụ của phát triển dự án mà có sai sót hay yêu cầu thay đổi từ khách hàng chúng ta có thể dễ dàng sửa đổi. - Agile chia dự án ra thành những thành phần nhỏ và giao cho mỗi người. Hàng ngày mọi người đều phải ngồi họp với nhau trong một thời gian ngắn để thảo luận tiến độ và các vấn đề nảy sinh lên mọi vấn đề đều có thể được giải quyết nhanh chóng. - Tỷ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác. Hình 6: So sánh agile với các phương pháp khác. Và tỷ lệ thành công của agile thì gấp 3 lần so với Waterfall: Theo báo cáo “CHAO Manifesto” năm 2011 của Standish Group, các dự án agile có tỷ lệ thành công gấp 3 lần so với những dự án không dùng agile. Báo cáo đó cho thấy rằng, “Quy trình linh hoạt là phương thuốc phổ dụng dành cho các dự án phát triển phần mềm thất bại. Các ứng dụng phần mềm được phát triển bởi các quy trình linh hoạt có tỷ lệ thành công gấp 3 lần so với phương pháp waterfall truyền thống và có tỷ lệ phần trăm thấp hơn nhiều về thời gian và chi phí phát sinh.” Standish Group đánh giá dự án thành công dựa trên thời gian, ngân sách, và tất cả các tính năng được lên kế hoạch. Họ không báo cáo về việc có bao nhiêu dự án trong cơ sở dữ liệu của mình nhưng họ cho biết kết quả này được thực hiện trên các dự án từ năm 2002 đến 2010. Biểu đồ sau sẽ cho thấy các số liệu cụ thể trong báo cáo của họ. Hình 7: So sánh agile với waterfall 2. Rủi ro và giải pháp. Quy mô đội ngũ Trung bình giới hạn từ 7 đến 10 người, quy mô đội ngũ có thể là một trở ngại nếu nó vượt quá số lượng đề xuất này. Việc tổ chức các cuộc họp sẽ không khả thi và nền tảng của phương pháp này trở nền suy yếu. Số lượng yêu cầu nhiều  Số yêu cầu có thể đến từ nhiều kênh của dự án và đôi khi có thể khó quản lý vì các khía cạnh khác nhau của chúng. Ở mức độ nhận giao hàng, những mâu thuẫn này có thể làm chậm quá trình xác nhận. Để khắc phục vấn đề này, bắt buộc phải sử dụng công cụ duy nhất quản lý các yêu cầu, một công cụ chuẩn cho mọi dự án cả Pentalog. Chất lượng phát triển Số lượng đội ngũ càng tăng, chất lượng càng khó kiểm soát. Điều này hoàn toàn đúng khi dự án được triển khai tại nhiều chi nhánh. Các rủi ro đặc biệt liên quan đến chất lượng code và số lượng khiếm khuyết được xác định tại thời điểm tích hợp. Vì thế, điều quan trong là cần phải có một chính sách chất lượng nghiêm ngặt và kế hoạch chất lượng dự án xác định chính xác các quy tắc dự án. Việc kiểm tra code thường xuyên và việc thiết lập các chỉ tiêu đánh giá năng lực của các lập trình viên cho phép giảm thiểu rủi ro này. V.Công cụ quản lí dự án với agile: agilebench.com 1. Khái niệm Agile Bench là một công cụ quản lý dự án, được thiết kế để hỗ trợ quá trình phát triển phần mềm: theo phương pháp agile. Nó giúp bạn lên kế hoạch, dự đoán và theo dõi quá trình phát triển phần mềm từ bước ý tưởng cho tới khi hoàn thành, đồng thời cho phép bạn chia sẻ thông tin với các thành viên khác trong nhóm. 2. Nội dung 2.1.Tạo project và đặt iteration size (thời gian kéo dài một iteration). 2.2. Ước lượng và tạo một vài iterations, mặc định agilebench đã tạo sẵn 3 iterations. 2.3. Viết các story cần thực hiện trong từng iteration, nếu một story chưa biết nên đặt vào iteration nào thì có thể đặt tạm nó ở backlog (kho). 2.4. Đánh giá độ khó, gán điểm (point) cho mỗi story. 2.5. Gán trách nhiệm làm mỗi story cho một/một vài thành viên trong nhóm. 2.6. Khởi chạy một iteration. 2.7. Thực hiện các stories của iteration hiện hành (coding, testing,…) 2.8. Kết thúc iteration, chuyển giao thành quả của iteration cho khách hàng dùng thử, đánh giá. 2.9. Bắt đầu iteration mới nếu dự án chưa hoàn thành. VI. So sánh phát triển theo mô hình truyền thống và phát triển theo Agile Phát triển theo kế hoạch Phát triển theo agile Phát triển theo kế hoạch đã dự định trước: Hạn chế sự thay đổi từ khách hàng. Bởi nếu thay đổi thì sẽ tốn nhiều chi phí, thời gian và sức lực. Phát triển không nhất thiết phải theo kế hoạch mà có thể thay đổi nếu hợp lí. Khuyến khích khách hàng thay đổi để tạo ra phần mềm tốt hơn. Quan trọng nhất vẫn là chất lượng phần mềm. Ít cho khách hàng xem trước sản phẩm. Thường khách hàng chỉ được xem phần đặc tả yêu cầu, nếu khách hàng đồng ý thì tiến hành các giai đoạn khác. Thông thường khách hàng chỉ được tiếp xúc với sản phẩm khi đã hoàn thiện. Chính vì vậy, lúc đó nếu không phù hợp với yêu cầu khách hàng sẽ rất khó thay đổi. Thường xuyên cho khách hàng xem trước sản phẩm. Bên thực hiện dự án sẽ trao đổi bàn giao với khách hàng 1 tuần 1 lần để dễ dàng đáp ứng với thay đổi. Khi khách hàng có yêu cầu thay đổi cả hai bên sẽ cùng bàn bạc. Các giai đoạn phát triển tách biệt: Sản phẩm của mỗi giai đoạn được lập kế hoạch từ trước. Các hoạt động phát triển được thực hiện xen kẽ Các thành viên trong nhóm thực hiện dự án làm việc độc lập, ít trao đổi với nhau. Các thành viên trong nhóm thường xuyên trao đổi thông tin và giúp đỡ lẫn nhau.Thậm chí, khi lập trình còn có lập trình theo đôi, một người phác thảo ý tưởng, còn một người sẽ viết code. Không nhất thiết chỉ dành cho mô hình thác nước, mô hình phát triển tăng dần cũng sử dụng được. Nghĩa là có thể tận dụng mô hình này cho mô hình khác Sản phẩm cần thực hiện được quyết định bởi thương thuyết trong quá trình phát triển Hình 8: So sánh agile và các phương pháp truyền thống. Phương pháp phát triển phần mềm theo hướng Agile đôi khi bị đánh giá là thiếu tính kỉ luật so với các phương pháp truyền thống. Nhưng nhận xét như vậy là không chính xác và thể hiện sự thiếu hiểu biết tường tận vê mô hình. Để hiểu về vấn đề một cách đúng đắn, ta có thể hình dung rằng những phương pháp phát triển phần mềm hiện có nằm trên một trục đi từ “ khả năng thích ứng” tới “khả năng dự đoán trước” thì phương pháp linh hoạt hướng đến khả năng thích . CHƯƠNG III.CÁC PHƯƠNG PHÁP THEO AGILE I.Tìm hiểu chung Agile không phải là một phương pháp. Mà nó là những lý thuyết về quy trình phát triển phần mềm. Hiện nay có nhiều các phương pháp phát triển nhanh theo hướng Agile được đề xuất và áp dụng. Mỗi phương pháp có một hướng tiếp cận khác nhau, đưa ra các quy trình, các hướng dẫn thực hiện riêng. Nhưng chung nhất, các phương pháp này đều có những tính chất đã được tuyên bố trong bản tuyên ngôn của các phương pháp phát triển nhan như: tính tương tác cao, coi trọng vai trò khách hàng, khả năng đáp ứng thay đổi nhanh. Hình 9: Một số phương pháp agile Chương III, Chúng ta sẽ tìm hiểu một phương pháp được mô phỏng theo Agile được đánh giá cao và được sử dụng rộng rãi đó là Scrum, XP và ASD. Trong đó Scrum và ASD thiên về lĩnh vực quản lý. Scrum đưa ra một quy trình chặt chẽ, trong đó nêu rõ vai trò của những thành viên tham gia dự án cũng như những hoạt động phải tiến hành trong quá trình thực hiện dự án. ASD thì lại đưa ra một khung quản lý chung hơn, trong đó có nhiều tùy chọn cho phép người quản lý áp dụng linh hoạt. Trong khi đó, cách tiếp cận của XP thì thiên về các kỹ thuật áp dụng trong lập trình. Nhiều hướng dẫn thực hiện trong lĩnh vực lập trình được XP đề cập một cách chi tiết. Hình 10: So sánh các phương pháp phát triển phần mềm II. Các quy trình phát triển theo hướng Agile 1. Quy trình Scrum a. Giới thiệu Scrum là một phương pháp luận được viết bởi Ken Schwaber và Mike Beedle. Thuật ngữ Scrum được đưa ra dựa trên một bài viết của Takeuchi và Nonaka (1986) mà trong đó giới thiệu một quy trình phát triển phần mềm nhanh có khả năng thích nghi. Phương pháp phát triển phần mềm Scrum được biết đến như một phương pháp quản lý nâng cao, áp dụng cho các hệ thống hiện có. Do đó, có thể áp dụng Scrum với các phương pháp phát triển phần mềm khác. Ý tưởng chính của Scrum là cho rằng việc phát triển một hệ thống cần phải quản lý một loạt các đại lượng như yêu cầu, thời gian, tài nguyên hay công nghệ dùng để phát triển, mà những đại lượng này hoàn toàn có thể thay đổi trong quá trình phát triển. Từ đó cho thấy quá trình phát triển dự án mang tính không ổn định, phức tạp và khó đoán trước. Do đó, cần phải có một quy trình phát triển có tính linh hoạt cao để có thể áp ứng được những thay đổi này, và sản phẩm đầu ra phải có tính ứng dụng cao đáp ứng nhu cầu khách hàng. b. Nguyên tắc Phát triển phần mềm theo cách gia tăng dần thông qua việc thực hiện một danh sách công khai các yêu cầu hay sửa chữa cần thực hiện (backlog). Việc bàn giao với khách hàng diễn ra thường xuyên (4 tuần/1 lần). Mỗi lần khách hàng sẽ nhận một phần mềm với tính năng nhiều hơn và hoạt động tốt hơn. - Họp hàng ngày: mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay và kiểm tra các tình huống có thể cản trở công việc trong ngày hôm nay. - Họp lên kế hoạch: toàn đội sẽ tập trung để quyết định các tính năng cần thực hiện của Sprint sau và cập nhật danh sách chung. - Họp kiểm tra lại công việc: trong cuộc họp này, mỗi người sẽ trình bày công việc đã làm trong thời gian thực hiện một sprint. Việc chứng minh các tính năng mới hay trình bày kiến trúc sẽ được tổ chức. Đây là một cuộc họp không chính thức kéo dài khoảng 2 giờ với sự tham gia của toàn đội. - Họp tổng kết: mỗi khi kết thúc một sprint, toàn đội sẽ họp về những tính năng hoạt động tốt và những tính năng chưa tốt. Trong cuộc họp khoảng 15 đến 30 phút này, môi người tham gia sẽ bỏ phiếu để xác định nhưng cải tiến cần có trong giai đoạn tiếp theo. c. Đặc điểm Scrum là phương pháp tiêu biểu trong các phương pháp nhanh với tính linh động cao, thời gian đáp ứng thay đổi nhanh và cộng tác chặt chẽ giữa các thành viên cũng như khách hàng. Nó có một số các đặc trưng như sau: - Linh động trong việc đưa kết quả- nội dung đưa ra phụ thuộc vào môi trường. - Linh động trong lập lịch- việc đưa ra có thể sớm hơn hoặc muộn hơn kế hoạch. - Đội ngũ phát triển phần mềm nhỏ- đội nhỏ được chia thành các nhóm nhỏ, một dự án phần mềm có thể có nhiều nhóm nhỏ cùng nhau phát triển. - Thảo luận thường xuyên- quá trình thực hiện của từng nhóm thường xuyên được xem xét thảo luận. - Tính cộng tác- Trong quá trình thực hiện dự án, việc cộng tác giữa các thành viên với nhau và với đối tác được coi trọng. d. Quy trình Scrum là một phương pháp hướng quy trình. Quy trình Scrum chia thành 3 giai đoạn: Giai đoạn bắt đầu và lập kế hoạch, giai đoạn phát triển, và giai đoạn kết thúc và đưa ra sản phẩm. Hình 11: Quy trình Scrum Giai đoạn bắt đầu và lập kế hoạch: - Trước khi dự án bắt đầu, tất cả các yêu cầu hệ thống được liệt kê và tập hợp dưới dạng các phiếu công việc (Blacklog). Các yêu cầu có thể từ khách hàng, bộ phận bán hàng hay người phát triển phần mềm. Tập hợp các phiếu công việc của toàn bộ dự án được gọi là Product Blacklog. Product Blacklog cho ta cái nhìn tổng thể về các chức năng của sản phẩm cuối cùng. Người tạo ra Product Blacklog được gọi là Product Owner (người sở hữu) thông thường là khách hàng hoặc người quản lý trong công ty. - Tiếp theo, các yêu cầu này được xác định độ ưu tiên và nhân lực tương ứng. Danh sách này sẽ luôn được cập nhập để công việc xác định độ ưu tiên, nhân lực và tài nguyên cho chính xác. - Trong giai đoạn này cũng phải đưa ra được nhóm dự án, công cụ, tài nguyên cần thiết, đánh giá rủi ro và tiến hành đào tạo lại nếu cần thiết. Ngoài ra, thiết kế tổng thể cũng được định nghĩa trong giai đoạn này. - Trước khi tiến hành phát triển, người sở hữu chọn những công việc cần tiến hành trong vòng lặp đầu tiên của giai đoạn phát triển. Các công việc này được tập hợp dưới dạng danh sách gọi là Sprint Backlog. Trong khi đó, nhóm phát triển chuẩn bị những gì cần thiết và ước lượng thời gian sao cho công việc có thể hoàn thành trong 30 ngày là khoảng thời gian một vòng lặp được quy định bởi Scrum. - Công việc cuối cùng của xác định mục tiêu là phải hoàn thành vòng lặp, gọi là Sprint Goal. Việc xác định mục tiêu này để giúp đội phát triển thấy được lý do công việc mình phải làm. Giai đoạn phát triển: - Toàn bộ giai đoạn phát triển được phân thành các vòng lặp, mỗi vòng lặp kéo dài 30 ngày gọi là Sprint. Mỗi vòng lặp, các thành viên dự án sẽ chọn công việc từ Sprint Backlog, làm việc sao cho đạt được mục tiêu đề ra trong Sprint Goal. Trong vòng lặp các công việc lại được chia thành các khoảng thời gian nhỏ hơn: + Phát triển: Tiến hành phân tích, thiết kế, cài đặt, kiểm thử và viết tài liệu cho những chức năng được lựa chọn. + Đóng gói: Tạo bộ cài đặt của sản phẩm đến thời điểm hiện thời. + Xem lại: Tất cả các thành viên trong nhóm họp với nhau để cùng đưa ra cách giải quyết những vấn đề gặp phải. + Điều chỉnh: Tổng hợp các thông tin thu từ cuộc họp và tiến hành điều chỉnh. - Trong giai đoạn này các thành viên phải gặp nhau trong cuộc họp hằng ngày kéo dài khoảng 15 phút. Điều này giúp nắm bắt hiện trạng và tăng cường sự liên hệ, trao đổi giữa các thành viên trong nhóm. Trong cuộc họp các thành viên phải giải quyết các vấn đề như: + Những gì làm được từ cuộc họp trước. + Dự định làm gì cho lần họp tiếp theo. + Vướng mắc gặp phải? - Để giảm tác động thay đổi, Scrum đưa ra nguyên tắc là mọi thay đổi trong Sprint được ghi nhận nhưng không được áp dụng ngay. Điều này có vẻ như không phù hợp với tiêu chí của phương pháp phát triển nhanh Agile nhưng là cần thiết vì mọi thứ thay đổi liên tục, nếu thay đổi lập tức sẽ dẫn đến tình trạng lộn xộn. - Cuối mỗi vòng lặp, các kết quả được thể hiện cho người sở hữu, người quản lý và những ai quan tâm. Dựa vào đó, người sở hữu phải chuẩn bị để đưa ra những tính năng cần thiết phải cài đặt trong vòng lặp kế tiếp. Nếu toàn bộ chức năng hoàn thành thì chuyển sang giai đoạn cuối là đưa ra sản phẩm. Giai đoạn kết thúc và đưa ra sản phẩm: Khi sản phẩm đã sẵn sàng được phát hành người quản lý sẽ tuyên bố đóng dự án và tiến hành đưa ra sản phẩm. Trong giai đoạn này, một số công việc khác cần phải được chuẩn bị tiến hành như tập hợp tài liệu sử dụng, đào tạo người dùng, phát triển kinh doanh. e. Các tác nhân tham gia: - Product owner: Trong phần lớn các dự án, người quản lý sản phẩm (product owner) là người chịu trách nhiệm đội ngũ dự án khách hàng. Đây chính là người sẽ xác định và ưu tiên các danh sách tính năng của sản phẩm và lựa chọn thời gian, nội dung của mỗi sprint trên cơ sở các giá trị (trách nhiệm) mà đội ngũ trao đổi với họ. - ScrumMaster: là người hỗ trợ đắc lực cho dự án, ScrumMaster là người kiểm tra công việc mà mỗi người có thể làm hết khả năng thông qua việc loại bỏ các hạn chế và tránh cho toàn đội những vấn đề cản trở từ bên ngoài. ScrumMaster cũng giám sát đặc biệt việc tuần thủ các giai đoạn khác nhau của phương pháp Scrum. - Đội ngũ: thông thường với quy mô từ 4 đến 10 người, đội ngũ tập trung các kỹ sư có vai trò cần thiết trong một dự án, đó là kỹ sư kiến trúc, thiết kế, lập trình, kiểm thử… Đội ngũ tự tổ chức công việc và không thể thay đổi trong toàn bộ thời gian của một sprint. Hình 12: Mối quan hệ trong Scrum f. Nhận xét Ưu điểm: - Thông thường, với các phương pháp truyền thống, toàn bộ yêu cầu thường được xác định trước trong giai đoạn khảo sát, và các phương pháp đó sẽ cố gắng hạn chế sự thay đổi của đặc tả. Chính điều này làm giảm khả năng đáp ứng thay đổi của các phương pháp đó, tăng rủi ro cũng đồng nghĩa với việc giảm khả năng thành công của dự án nhất là với các dự án kéo dài. Ngược lại, Scrum lại được thiết kế khá linh động. Nó cho phép thay đổi yêu cầu tại bất cứ thời điểm nào để có thể đưa ra sản phẩm phù hợp nhất cho khách hàng. - Việc chia thành nhóm nhỏ để phát triển cũng giúp các thành viên có thể dễ dàng trao đổi thông tin với nhau. - Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm. - Giảm thời gian dành cho quản lý, tăng thời gian dành cho việc phát triển - Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu. ... Nhược điểm: - Vai trò của PO rất quan trọng (Là tiếng nói của khách hàng trong việc đánh giá sản phẩm. Người hiểu rõ cái mà khách hàng cần. Thông thường PO là khách hàng hoặc một Business Analysis). PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung . - Khi phát triển dự án theo Scrum thì dự án sẽ không có detail design. Do vậy mỗi thành viên của dự án cũng sẽ là một người thiết kế hệ thống. Do vậy nếu phối hợp không tốt thì có thể dẫn đến việc sản phẩm rất khó "sửa chữa" . 2. Phương pháp XP (Extreme Programming). a. Giới thiệu: XP là một trong những phương pháp phát triển nhanh tiêu biểu nhất. Phương pháp này được đề xuất và áp dụng từ khi các phương pháp phát triển theo Agile còn chưa được phổ biến rộng rãi. Xp đã khắc phục những vấn đề gặp phải trong cách tiếp cận truyền thống có chu kì dài không đáp ứng được yêu cầu khách hàng. Dựa trên những kinh nghiệm thực tế sẵn xó, cộng với những thành công trong quá trình thử nghiệm, XP đã được tổng quát lên thành lý thuyết với một loạt các nguyên lý và bài học thực tiễn. b. Đặc điểm - Phản hồi nhanh: Nhanh chóng nhận phản hồi, xử lý và áp dụng sẽ làm tăng tính thích nghi với thay đổi và sửa lỗi nhanh hơn. Xử lý phản hồi càng chậm thì việc sửa lỗi hoặc đáp ứng thay đổi càng tốn kém và chứa nhiều rủi ro. - Giải pháp đơn giản: Coi mọi vấn đề như thể có thể giải quyết nó 1 cách đơn giản nhất. Trên thực tế, hầu hết các vấn đề đều có thể giải quyết 1 cách đơn giản. Đôi khi, người ta hay phức tạp hóa vấn đề mà không nghĩ rằng nó có thể giải quyết bằng cách đơn giản hơn. - Thay đổi dần dần: Cố gắng giữ cho mọi thứ thay đổi từ từ, tránh sự thay đổi lớn tại một thời điểm . Một thay đổi lớn có thể được thực hiện qua nhiều thay đổi nhỏ. - Đối mặt với sự thay đổi: Chấp nhận sự thay đổi là một trong những ưu điểm của Xp so với các phương pháp khác. Các yêu cầu sẽ được xem xét và thay đổi để thỏa mãn nhu cầu khách hàng nhằm tạo ra phần mềm tốt nhất - Chất lượng công việc: Mội thành viên được tạo điều kiện để phát huy khả năng của mình một cách tốt nhất. Nhấn mạnh làm việc theo nhóm (teamwork). Nhà quản lý, khách hàng,lập trình viên tất cả phải kết hợp với nhau để tạo ra một phần mềm chất lượng c. Quy trình phát triển phần mềm XP Hình 13: Quy trình Xp Giai đoạn khảo sát: - Trước khi phát triển dự án, nhóm phát triển cần đánh giá các yếu tố như nhân lực, công nghệ, thời gian để đảm bảo thực hiện dự án. Về phía khách hàng, họ sẽ viết ra những yêu cầu mà họ muốn có trong phiên bản đầu tiên. Mỗi yêu cầu tương ứng một chức năng trong chương trình. - Các thành viên trong dự án cũng làm quen các công cụ và công nghệ mà họ sẽ làm trong dự án. Lập kế hoạch Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên. Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong các phần sau của dự án đang thực hiện. Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp. Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc. Phân tích: XP không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu. Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này. Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết kế giao diện riêng. Thiết kế và lập trình Trong một dự án XP, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình.Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng. Mã nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra. Test Tất cả các thành viên trong dự án XP đều có trách nhiệm đảm bảo chất lượng sản phẩm. Các lập trình viên thực hiện unit test và integration test. Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test. Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn.Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệ thống một cách liên tục) và được chạy bởi các lập trình viên khi họ làm công việc là tích hợp code mới vào hệ thống dự án đang thực hiện.Lập trình theo cặp góp phần làm tăng chất lượng công việc.Bàn giao sản phẩm Hệ thống được trình diễn nội bộ hàng tuần và được bàn giao cho khách hàng theo kế hoạch đã định trước hoặc theo nhu cầu của khách hàng. e. Nhận xét XP đưa ra một cách chi tiết về hướng dẫn thực hiện, được mô tả rõ ràng từ cách thực hiện cho đến những lợi ích thu được từ các hoạt động này. Việc thực hiện theo hướng dẫn này có thể giải quyết được khá nhiều những vấn đề thường gặp phải trong các dự án hiện nay và tăng thêm khả năng thành công của dự án. Tuy nhiên có một số yêu cầu tư quy trình XP mà việc thực hiện không phải là dễ. Ví dụ như việc yêu cầu có một khách hàng thường trực, làm việc cùng đội phát triển phụ thuộc nhiều vào khách hàng. Thường thì khách hàng có rất nhiều việc phải làm hiện thời và không phải ai cũng có tinh thần hợp tác tốt. Hay việc lập trình theo cặp là khá xa lạ với chúng ta hiện nay. Không dễ gì để người ngồi bên cạnh một người khác với đúng chức năng được đưa ra trong CP Nhưng trên hết, XP đã đưa ra một phương pháp hay khả năng khả thi. Thực tế cho thấy XP đã thành công, vì thế việc áp dụng XP trong phát triển phần mềm sẽ có lợi rất nhiều. 3. Phương pháp phát triển phần mềm thích nghi ASD a.Giới thiệu Phương pháp phát triển phần mềm thích nghi ASD ( Adaptive Software Development) được phát triển bởi James A.H, Highsmith là một trong những phương pháp được phát triển dựa trên ý tưởng của các phương pháp phát triển nhanh. Phương pháp ASD tập trung vào việc giải quyết các vấn đề trong hệ thống phức tạp, nhiều thay đổi. Tư tưởng của ASD cho rằng việc thích nghi trong những môi trường luôn thay đổi là rất quan trọng. Từ đó, ASD đưa ra quy trình mang tính lặp lại, quá trình “học” được tiến hành qua mỗi vòng lặp để tăng cường khả năng thích nghi. b.Quy trình Hình14: Quy trình ASD Một dự án theo ASD được tiến hành qua các vòng lặp, các vòng lặp gồm 3 giai đoạn: suy đoán, cộng tác và học. + Suy đoán (Speculate) được thay cho lập kế hoạch (Plan) vì kế hoạch thường dựa trên những gì rõ ràng, chắc chắn, trong khi mọi thứ của dự án đều có thể thay đổi. + Cộng tác (Collaborate): Nhấn mạnh vai trò cộng tác giữa các thành viên. + Học (Learn): Nhấn manh việc rút ra kiến thức, bài học để tránh những lỗi đã gặp phải. Khởi động dự án và lập kế hoạch ASD cho rằng kiến thức con người có hạn, những giả thiết có thể không thể đạt được hiệu quả ngay lập tức chính vì vậy việc thay đổi kế hoạch là một điều rất tự nhiên. - Công việc đầu tiên trong giai đoạn này là định nghĩa nhiệm vụ dự án. Nhiệm vụ này đưa ra một khung cơ bản cho sản phẩm cuối cùng, giúp định hướng quá trình phát triển sản phẩm. Phạm vi dự án cũng được ước lượng đồng thời đội ngũ dự án cũng được định hình cơ bản. - Công việc tiếp thep cần thực hiện là xác định thời gian thực hiện cho dự án. Dựa vào khoảng thời gian này, khung thời gian cho mỗi vòng lặp được định nghĩa. Các vòng lặp cũng sẽ được lập kế hoạch, độ dài vòng lặp phụ thuộc kích cỡ dự án và mức độ khả thi, nhưng thường khoảng từ 2 đến 8 tuần. Việc lập kế hoạch này bao gồm cả việc gán các khung thời gian cho mỗi vòng lặp. - Tiếp theo là viêc lên lịch trình thực hiện trong các vòng lặp. Mỗi vòng lặp sẽ được gắn một “ chủ đề” chính là vấn đề chính cần quan tâm trong vòng lặp. - Cuối cùng, các tính năng được gán cho vòng lặp. Khách hàng là người quyết định dựa trên mức độ ưu tiên các tính năng. Người phát triển giúp khách hàng ước lượng thời gian, rủi ro… Giai đoạn phát triển các tính năng Trong giai đoạn này, các tính năng của sản phẩm sẽ được phát triển. Giống như Scrum , ASD không đưa ra các hướng dẫn chi tiết trong việc làm thế nào để phát triển mà chỉ đơn thuần đưa ra một khung cho việc quản lý. Đánh giá lại chất lượng công việc Trong giai đoạn này những tính năng được phát triển trong giai đoạn trước được trình bày với khách hàng. Ngoài ra, các thành viên trong nhóm cũng bàn bạc về những vấn đề kỹ thuật gặp phải, từ đó rút ra bài học để tránh gặp phải cũng như biết cách xử lý trong các trường hợp tương tự. ASD không có quan điểm là luôn phải đúng, vẫn có thể mắc lỗi nhưng quan trọng nhất là ta học được gì từ những lỗi đó. Để đánh giá chất lượng công việc thì phải kiểm tra xem các tính năng đã làm có hoạt động không, và nó hoạt động thế nào, công việc của nhóm có vướng mắc gí không. Cuối cùng cần đánh giá hiện trạng dự án, những gì đã làm được và chưa làm được và kế hoạch cho những công việc tiếp theo. c. Nhận xét ASD là phương pháp tập trung vào kết quả và chất lượng công việc hơn là chỉ ra những quy trình. Quá trình thực hiện dự án thông qua một loạt các vòng lặp, trong đó việc lập kế hoạch cũng là một phần của vòng lặp. Điều này có nghĩa là các chức năng cần phát triển sẽ liên tục được điều chỉnh dựa vào các thông tin thu được thông qua các vòng lặp. Mặc dù ASD không đưa ra nhiều hướng dẫn thực hiện, mà chỉ đưa ra khung quản lý gọn nhẹ, nhưng chứa đựng nhiều ý tưởng quan trọng trong việc thích nghi với những thay đổi thường xuyên. Điều này cho phép những người quản lý có thể tùy biến áp dụng phương pháp này. Cũng như Scrum, ASD không định nghĩa cụ thể cách thức thực hiện các cài đặt các chức năng, do đó có thể áp dụng kết hợp với một phương pháp phát triển khác như XP. III. Đánh giá và so sánh các phương pháp 1.Đặc điểm chính - Trong cả ba phương pháp: Scrum, XP và ASD vai trò khách hàng được đánh giá cao. Khách hàng đóng vai trò định hướng dự án. Khách hàng lựa chọn những chức năng thực hiện trong mỗi giai đoạn cũng như xác định độ ưu tiên của các chức năng đó. Đặc biệt, trong XP khách hàng còn tham gia vào đội dự án với tư cách thành viên thường trực. - Về chiến lược phát hành, cả ba phương pháp đều đưa ra kết quả trong một thời gian ngắn. Scrum thì trình bày kết quả sau mỗi Sprint 30 ngày, ASD là khoảng 2 đến 8 tuần, XP thì nhanh chóng đưa ra phiên bản nhỏ để sử dụng, sau đó liên tục phát hành các phiên bản mới. - Về khả năng đáp ứng thay đổi: Tất cả các phương pháp đều cho rằng việc thay đổi yêu cầu là tất yếu, khó tránh khỏi và việc đáp ứng thay đổi là giảm rủi ro và tăng thành coog cho dự án. XP luôn chú trọng vào đáp ứng thay đổi với nguyên tắc “Embracing change” nghĩa là cần phải đối mặt. Để đảm bảo tính ổn định, Scrum cũng ghi nhận thay đổi nhưng sẽ xem xét chứ không xử lý ngay.Còn với ASD, việc đáp ứng thay đổi và tiếp nhận ý kiến khách hàng còn được coi là một quá trình học hỏi. - Hướng dẫn thực tiễn mà các phương pháp cung cấp: ASD không đưa nhiều hướng dẫn cụ thể mà chỉ đưa một khung chung tổng thể để áp dụng. Scrum thì đưa nhiều hướng dẫn khắt khe trong quản lý như họp hằng ngày, khoảng thời gian phát triển, nhưng lại không đưa ra nhiều kỹ thuật lập trình. XP thì đưa ra những hướng dẫn trong lập trình khá chi tiết nhưng lại ít đề cập vấn đề quản lý. 2. Khả năng và phạm vi áp dụng - ASD đưa ra một mô hình khá chung mang tính định hướng nên việc áp dụng ASD khá linh động, tính tùy biến cao. Tuy nhiên, phương pháp không đưa ra nhiều hướng dẫn cụ thể nên đòi hỏi người quản lý phải có kĩ năng tốt. - Scrum đưa ra tiêu chuẩn, hướng dẫn chi tiết nhưng không có những hướng dẫn cụ thể về mặt lập trình. Chính vì vậy, nên áp dụng nó với một phương pháp phát triển phần mềm khác. - XP luôn đưa ra nhiều ý tưởng hay và hiệu quả như cùng làm việc với khách hàng hay lập trình theo cặp. XP không cứng nhắc việc áp dụng mà mang tính chất chỉ đạo nên việc áp dụng dễ dàng. Ta có thể áp dụng XP với phương pháp Scrum. KẾT THÚC Trên đây là bài tập lớn nhóm em môn công nghệ phần mềm với đề tài: “ Tìm hiểu quy trình Agile”. Do kiến thức còn hạn chế lên bài tập lớn của nhóm chúng em còn nhiều hạn chế kính mong thầy cô và các bạn góp ý để chúng em hoàn thiện hơn. Nhân đây em cũng xin gửi lời cảm ơn chân thành đến thầy Lê Hoàn, cùng toàn thể giáo viên trong khoa công nghệ thông tin đã giúp đỡ chúng em rất nhiều trong quá trình học tập cùng như trong quá trình thực hiện đề tài này. Em xin chân thành cảm ơn! Nhóm sinh viên thực hiện: Dương Văn Hà Đoàn Thị Kim Dung Hà Thị Thu Hương Đỗ Thị Thanh Tuyền Trần Văn Thành Nguyễn Quang Hoàng TÀI LIỆU THAM KHẢO 1. Giáo trình “ Kỹ nghệ phần mềm” (software engeneering) – Giảng viên Nguyễn Văn Vy- Bộ môn Công nghệ phần mềm- Khoa CNTT- DHCN- Email:vynv@coltech.vnu.vn. 2. Giáo trình “ Công nghệ phần mềm”- Giảng viên Lê Văn Tường Lân- Trường đại học khoa học công nghệ thông tin. 3. Tài liệu trên www.agiledevelopment.org. DANH MỤC HÌNH VẼ,BẢNG VẼ Hình 1 : Mô hình thác nước 9 Hình 2 : Mô hình làm bản mẫu 10 Hình 3 : Mô hình xoắn ốc 12 Hình 4 : Mô hình đài phun nước 13 Hình 5 : Mô hình Agile tổng quát 20 Hình 6 : So sánh Agile với các phương pháp khác 25 Hình 7 : So sánh Agile với Waterfall 26 Hình 8 : So sánh Agile với các phương pháp truyền thống 29 Hình 9 : Một số phương pháp Agile 30 Hình 10 : Các quy trình phát triển theo hướng Agile 31 Hình 11 : Quy trình Scrum 33 Hình 12: Mối quan hệ Scrum 36 Hình 13 : Quy trình XP 39 Hình 14 : Quy trình ASD 42