PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT (AGILE DEVELOPMENT METHODS)
lượt xem 144
download
MÔN HỆ THỐNG THÔNG TIN QUẢN TRỊ: Ngày nay, công nghệ thông tin (IT) có vai trò rất lớn trong các hoạt động kinh tế, sản xuất kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp….Việc áp dụng các ứng dụng của công nghệ IT đã trở thành một phần không thể thiếu của đời sống cũng như trong các hoạt động của nền kinh tế nói chung và của các doanh nghiệp nói riêng. Đặc biệt là việc phát triển hệ thống thông tin kinh doanh là yếu tố quan trọng góp phần vào sự thành công của một doanh nghiệp. Hiện...
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT (AGILE DEVELOPMENT METHODS)
- MÔN HỆ THỐNG THÔNG TIN QUẢN TRỊ ĐỀ TÀI: PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT (AGILE DEVELOPMENT METHODS) Thành phố Hồ Chí Minh, ngày 17 tháng 12 năm 2009
- MỤC LỤC I. MỞ ĐẦU ........................................................................................... 2 1. Định nghĩa mô hình thác nước Waterfall ............................................2 2. Định nghĩa phương pháp phát triển linh hoạt Agile...........................3 II. PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT (Agile Development Method)................................................................................................3 1. Đặc điểm phương pháp phát triển linh hoạt Agile............................3 2. Tuyên ngôn và nguyên tắc của phương pháp phát triển linh hoạt Agile ..............................................................................................................5 2.1. Tuyên ngôn ...............................................................................5 2.2. Nguyên tắc ...............................................................................5 3. Điều kiện áp dụng phương pháp phát triển linh hoạt Agile ............6 III. SO SÁNH AGILE VÀ WATERFALL ...............................................6 IV. KẾT LUẬN .........................................................................................8 BẢNG PHÂN CÔNG CÔNG VIỆC ............................................................11 Tài liệu tham khảo .......................................................................................12 2
- I. MỞ ĐẦU Ngày nay, công nghệ thông tin (IT) có vai trò rất lớn trong các hoạt động kinh tế, sản xuất kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp….Việc áp dụng các ứng dụng của công nghệ IT đã trở thành một phần không thể thiếu của đời sống cũng như trong các hoạt động của nền kinh tế nói chung và của các doanh nghiệp nói riêng. Đặc biệt là việc phát triển hệ thống thông tin kinh doanh là yếu tố quan trọng góp phần vào sự thành công của một doanh nghiệp. Hiện nay có rất nhiều phương pháp phát triển hệ thống và một trong những phương pháp được đánh giá là chiếm lĩnh ưu thế trong những năm gần đây: phương pháp phát triển linh hoạt (Agile Development Methods). Phương pháp Agile ra đời vào những năm 90, được phát triển trên nền tảng khắc phục nhược điểm của một phương pháp cổ điển: Waterfall Method. 1. Định nghĩa mô hình thác nước Waterfall Mô hình Thác nước (Waterfall) ra đời vào những năm 70, là một mô hình cổ điển và được áp dụng trong qui trình phát triển phần mềm tại phần lớn các công ty. Mô hình Waterfall là một chuỗi qui trình phát triển như một luồng đều đặn từ trên xuống giống như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau. Ưu điểm của Waterfall là dễ quản lý. Tuy nhiên, nhược điểm của nó là quá cứng nhắc và thiếu thực tế, bởi việc thay đổi ở bất kì phần nào của quy trình cũng là không thể vì việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm. Đề khắc phục được nhược điểm này của Waterfall, phương pháp agile ra đời 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 3
- 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. 2. Định nghĩa phương pháp phát triển linh hoạt Agile. Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm (method), chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile. Mỗi phương pháp Agile bao gồm một tập hợp các quy tắc (pratice), chẳng hạn quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng. II. PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT (Agile development method) Để khắc phục những đặc điểm của phương pháp Waterfall, vào đầu những năm 90, một phương pháp phát triển phần mềm mới đã ra đời. Phương pháp này cho phép các phần mềm có khả năng biến đổi, sửa chữa ngay cả khi dự án đã bắt đầu. Đó là phương pháp phát triển phần mềm linh hoạt ( Agile Development Methods). 1. Đặc điểm phương pháp phát triển linh hoạt Agile Phương pháp phát triển linh hoạt cho phép các dự án được hoàn thành nhanh chóng mà vẫn đảm bảo được yêu cầu về chất lượng và dễ dàng trong việc sửa chữa, cập nhật khi những yêu cầu thay đổi vào bất cứ giai đoạn nào của dự án cho đến khi dự án kết thúc và sản phẩm được giao cho khách hàng. Phương pháp phát triển linh hoạt có những đặc điểm sau: Thứ nhất là nó được phát triển dựa trên quy trình phát triển lặp (interative development) – mỗi dự án sẽ được chia ra thành nhiều mảng nhỏ, dễ sử dụng và dễ sửa đổi khi yêu cầu của khách hàng thay đổi. Dự án sẽ được thực hiện từng theo từng mảng nhỏ này, giống như những dự án nhỏ, hết dự án này quy trình sẽ 4
- lại bắt đầu với dự án tiếp theo cho đến khi tất cả những yêu cầu của khách hàng được đáp ứng và dự án được bàn giao. Thứ hai là, với phương pháp phát triển linh hoạt, cứ mỗi hai hay bốn tuần, nhóm lập trình viên sẽ giao cho khách hàng một phần của dự án, khách hàng sẽ kiểm tra và được khuyến khích đưa ra những ý tưởng mới, những yêu cầu mới hoặc thay đổi những yêu cầu của dự án. Theo đó, nhóm lập trình viên có thể cập nhật và sửa đổi sản phẩm theo đúng yêu cầu của khách hàng thay vì chỉ căn cứ vào hợp đồng và làm việc. Cần lưu ý là không giống với phương pháp waterfall, việc sửa đổi này giúp cho ứng dụng tốt hơn, đẹp hơn và không phá hỏng nó, không buộc phải bắt đầu lại từ đầu. Thứ ba là, với phương pháp phát triển linh hoạt, từng phần nhỏ của dự án phần mềm sẽ được test ngay trong quá trình làm dự án và việc này do chính các lập trình viên làm thay vì phải có các nhóm kiểm tra (tester) độc lập. Bằng cách sử dụng công cụ “unit test” (kiểm tra từng phần), từng phần của dự án sẽ được kiểm tra ngay trong quá trình phát triển trước khi tích hợp vào phần mềm. Thứ tư là, phương pháp phát triển linh hoạt nhấn mạnh vào việc gặp mặt trao đổi hàng ngày giữa các thành viên trong nhóm dự án. Khác với phương pháp phát triển truyền thống, các thành viên của nhóm dự án được chia ra phát triển từng mảng riêng biệt, với phương pháp Agile, tại mỗi thời điểm, cả nhóm cùng tập trung phát triển một mảng của dự án. Vì vậy, phương pháp Agile yêu cầu các 5
- thành viên có sự tập trung về địa lí, cùng bàn bạc thảo luận hàng ngày để hoàn thành dự án đúng thời hạn. Thứ năm là, phương pháp phát triển Agile dựa vào việc phát triển trên từng nhóm nhỏ (10 thành viên trở xuống), các thành viên phải là những người có kĩ năng cao và hiểu biết về dự án, hơn nữa, các thành viên trong nhóm cần tin tưởng lẫn nhau, chia sẻ thông tin với nhau. Với nhóm ít thành viên, các thành viên cũng cần có nhiều kĩ năng hơn so với việc lập trình và kiểm thử truyền thống. Với những đặc điểm như trên, hiện nay phương pháp phát triển linh hoạt đang ngày càng được ứng dụng rộng rãi với những phần mềm trị giá hàng chục triệu, thậm chí hàng trăm triệu đô la Mỹ (USD). 2. Tuyên ngôn và nguyên tắc của phương pháp phát triển linh hoạt Agile 2.1 Tuyên ngôn Gồm 4 điểm: - Cá nhân và các tương tác quan trọng hơn quy trình và công cụ. - Tập trung làm cho phần mềm chạy được thay vì viết tài liệu. - Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng. - Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn. Tuyên ngôn 4 điểm của phương pháp Agile được cụ thể thành 12 nguyên tắc chính. 2.2 Nguyên tắc: - Ư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. 6
- - 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 đã hoạt độ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. Điều kiện áp dụng phương pháp phát triển linh hoạt Agile: Mặc dù phương pháp Agile là một phương pháp linh hoạt tiến bộ nhưng nó cũng có những ưu điểm cũng như nhược điểm riêng, vì vậy không thể áp dụng phương pháp Agile cho mọi trường hợp. Vì vậy, để một dự án có thể áp dụng phương pháp Agile thì cần có những đặc điểm sau: - Mức độ rủi ro thấp. - Thành viên nhóm có kinh nghiệm. - Yêu cầu thay đổi thường xuyên. - Kích thước nhóm nhỏ. - Các thành viên làm việc cùng một địa điểm. 7
- - Văn hóa công ty ưa thích sự không trật tự. III. SO SÁNH AGILE VÀ WATERFALL Như đã phân tích ở trên, Agile hoạt động dựa trên nguyên tắc lặp, tức là, mỗi dự án được chia thành nhiều module nhỏ, mỗi module đều thực hiện những chức năng giống nhau được lặp đi lặp lại: tập hợp yêu cầu, lập kế hoạch, phân tích, code, test…Cũng với một trình tự như vậy nhưng Waterfall lại hướng đến cách tiếp cận cấu trúc có định trước, nó không có sự linh hoạt trong việc phân chia các giai đoạn của dự án, mỗi khâu phải đảm bào hoàn thành chính xác 100% trước khi chuyển sang khâu tiếp theo. Đây có thể coi là sự khác nhau cơ bản dẫn đến những khác nhau tiếp theo của hai phương pháp Thứ nhất, về rủi ro của hai phương pháp. Theo phương thức hoạt động của Waterfall, kiểm tra là bước thực hiện một lần và duy nhất và cuối mỗi dự án, như vậy, nếu dự án có lỗi sai thì lỗi sai đó chỉ được phát hiện khi dự án đã sắp hoàn thành, rủi ro gặp phải là rất lớn, hơn nữa, chi phí tìm kiếm và sửa chữa là rất tốn kém bởi các khâu trong cả quá trình của dự án có mắt xích với nhau. Tuy nhiên, Agile đã khắc phục điều này. Với các module nhỏ hoạt động như nhau, Agile cho phép dự án được kiểm tra một cách thường xuyên bởi cứ cuối mỗi giai đoạn thử nghiệm đều có thể đưa ra kết quả. Như thế đảm bảo phát hiện và loại bỏ các lỗi sai trong vòng phát triển, kết quả sẽ được kiểm tra lại hai lần sau đợt sàng lọc lỗi đầu tiên, từ đó, giảm thiểu tối đa rủi ro cho mình cũng như khách hàng, tiết kiệm được thời gian cũng như chi phí dành cho dự án. Thực tế cho thấy, những dự án làm theo phương pháp Waterfall mất từ 6 tháng đến 1 năm, trong khi đó, Agile chỉ mất khoảng 1-2 tháng để hoàn thành dự án. Thứ hai, tính linh hoạt và sự phù hợp với thực tế của Waterfall gần như bị triệt tiêu đến thời điểm bàn giao dự án cho khách hàng, đặc biệt là đối với những ngành nghề mang tính chất nhạy cảm cao với thông tin thị trường, thường xuyên thay đổi như tài chính ngân hàng…nhưng Agile lại hoàn toàn ngược lại. Với Waterfall, khách hàng phải gần như phải đưa ra tất cả yêu cầu, thông tin ngay từ 8
- khi ký kết hợp đồng, một sự thay đổi cũng rất khó bởi nó ảnh hưởng đến cả một hệ thống. Từ đây, chúng ta thấy, có thể 6 tháng trước, với những thông tin đó sẽ đưa ra những phân tích chính xác về thị trường, nhưng 6 tháng sau, có nhiểu yếu tố thay đổi không thể lường trước, những thông tin đưa vào lúc đầu không còn phù hợp nữa. Nếu muốn, chúng ta chỉ có thể quay lại lập trình laị hệ thống từ đầu, như vậy sẽ rất mất thời gian và tốn kém. Trong khi đó, khách hàng của Agile lại có thể thay đổi yếu cầu của mình trước những biến động bất thường của thị trường, vì cứ cuối mỗi giai đoạn của Agile sẽ có một chương trình hợp lý được lập trình nhằm giải quyết và sửa chữa những ý tưởng mới. Thứ ba, do yêu cầu và mục tiêu của phương pháp mà yêu cầu về nguồn nhân lực của hai phương pháp này cũng khác nhau. Phương pháp Agile chú trọng đến việc giao tiếp khách hàng thường xuyên trong thời gian thực hiện hợp đồng nhằm đưa đến một sản phẩm tốt nhất, phù hợp nhất. Mỗi cá nhân hoạt động theo phương pháp Agile không chỉ là những người lập trình viên viết code hay những tester đơn thuần, họ phải biết tất cả các khâu để hoàn thành dự án đó: từ việc marketing, thỏa thuận với khách hàng, đến việc thiết kế, phân tích, bàn giao và đưa sản phẩm ra thị trường. Agile khuyến khích làm việc nhóm, hoạt động trong môi trường mở, giảm thiểu tối đa những truyền đạt mang tính chất giấy tờ. Đây có thể coi là một phong cách làm việc mới trong giai đoạn hiện nay. Agile đối lập hoàn toàn với Waterfall ở điểm này, khi mà các cá nhân của Waterfall chỉ quan tâm đến một khâu mà họ đảm nhiệm. Thứ tư, Agile phù hợp với những dự án nhỏ, có tính chất thay đổi thường xuyên, yêu cầu thời gian hoành thành nhanh chóng và rủi ro thấp như thiết kế Web. Waterfall lại phù hợp hơn với những dự án lớn, không có yêu cầu thay đổi nhiều. Thêm vào đó, đặc tính tự điều chỉnh của phương pháp agile chính là tận dụng tốt hơn những lập trình và chương trình hướng đến đối tượng phù hợp, nghĩa là phương pháp này sỡ hữu mô hình hoạt động đưa ra những kết quả kịp thời ngay cả khi phương pháp này không phù hợp hoàn toàn với những chỉ định 9
- của khách hàng. Trong khi đó, phương pháp waterfall chỉ đưa ra được một kết quả duy nhất và bất kỳ rắc rối hay trì hoãn nào đều khiến khách hàng thất vọng. Cùng với đó là việc phương pháp agile thậm chí còn cải thiện chất lượng phần mềm do chúng chú trọng vào việc thử nghiệm. Phương pháp agile khuyến khích các lập trình viên tự mình thử nghiệm, thường xuyên yêu cầu họ đưa ra các thử nghiệm trước khi đưa ra bất kỳ mã nào và phát triển những thói quen kiểm tra tự động cho các chương trình họ đưa ra. Cuối cùng, cần phải có rất nhiều hệ thống khác để tương tác với phương pháp waterfall. Đối với phương pháp Agile, điều này không cần thiết. Tuy nhiên, cả hai phương pháp đều cho phép thực hiện phân khu, cụ thể trong phương pháp waterfall việc phân khu được thực hiện vào mỗi giai đoạn. Đối với phương pháp agile, mỗi module đã được mã hóa đều có thể được phân bổ cho những nhóm lập trình khác nhau. Điều này cho phép nhiều phần trong dự án được hoàn thành cùng lúc thế nên việc phân khu được sử dụng hiệu quả hơn trong phương pháp Agile. IV. KẾT LUẬN Agile là một phương pháp hữu dụng, nhưng nếu các dự án không thành công hay không mang lại lợi nhuận do áp dụng phương pháp agile thì lý do là vì các dự án đó không áp dụng agile đúng cách, hoặc agile không thích hợp áp dụng cho những dự án này, do đó không nên áp dụng agile cho mọi dự án. Nếu mục tiêu của bạn là làm tăng hiệu quả hay tăng năng suất lao động, thúc đẩy các lập trình viên làm việc nhanh hơn thì agile không phù hợp vì các nguyên lý của agile không có tác dụng làm tăng hiệu quả của dự án. Trước khi áp dụng agile cho dự án, bạn phải trả lời được các câu hỏi như “Liệu agile có giúp bạn thành công hơn không? Liệu người sử dụng có tham gia vào dự án không? Liệu trong nhóm có những lập trình viên phần mềm giỏi nhất, dày dạn kinh nghiệm và có tính kỷ luật cao nhất không? Môi trường làm việc tập trung hay 10
- phân tán? Liệu nhóm lập trình có được đào tạo kỹ năng làm việc nhóm? Liệu nhóm lập trình có liên tục học hỏi những điều mới không? Để phương pháp Agile thật sự mang lại hiệu quả, chúng ta cần xem xét kĩ càng liệu các dự án có phù hợp với phương pháp Agile hay không, sau đây là 1 số đặc điểm của dự án phù hợp với phương pháp Agile: - Rủi ro thấp. - Các thành viên nhóm lập trình dày dạn kinh nghiệm. - Các yêu cầu luôn luôn thay đổi. - Nhóm lập trình là nhóm nhỏ. Các thành viên làm việc cùng nhau tại cùng một địa điểm. - Văn hóa công ty ưa thích sự “mất trật tự” (hướng đến sự hỗn loạn). Ngược lại, những điều kiện nêu dưới đây sẽ cản trở việc áp dụng agile - Nhóm lập trình là nhóm lớn (hơn 20 thành viên bao gồm kỹ thuật viên, kiểm nghiệm viên dự án ngoài luồng). - Văn hóa: làm việc theo những gì được yêu cầu. - Các thành viên không làm việc tại cùng một địa điểm. Tóm lại, phương pháp Agile là một phương pháp tốt được tìm ra, tuy nhiên khi vận dụng nó chúng ta cũng cần thận trọng xem xét tới những mặt mạnh và yếu điểm của Agile nhằm vận dụng thật sự chính xác, đem lại hiệu quả cao nhất cho quá trình hoạt động. 11
- TÀI LIỆU THAM KHẢO 1. J Shore và S Warden, The “Art of Agile Development” http://jamesshore.com/Agile-Book/ 2. Jonathan Lambert (21/09/007),“Agile VS Waterfall development models, a discussion for managers of Drupal-based projects” http://www.workhabit.com/labs/agile-vs-waterfall-development-models- discussion-managers-drupal-based-projects c. “WATERFALL vs. AGILE METHODOLOGY” http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile- methodology/ 4.Gina Lijoi, “Can We Combine Agile and Waterfall Development Strategies?” http://www.projectsmart.co.uk/can-we-combine-agile-and-waterfall- development-strategies.html 12
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Lập trình hướng đối tượng C++
351 p | 2906 | 1826
-
Giáo trình lập trình hướng đối tượng - Lê Thị Mỹ Hạnh ĐH Đà Nẵng
165 p | 1406 | 510
-
OPP C++ (phần 1)
30 p | 258 | 68
-
TÀI LIỆU LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG
165 p | 145 | 41
-
Extreme programming(XP)
8 p | 385 | 40
-
Bài giảng về môn Lập trình hướng đối tượng
396 p | 125 | 28
-
Bài giảng Nhập môn Công nghệ phần mềm: Chương 9 - Nguyễn Thị Minh Tuyền
53 p | 79 | 12
-
Một số vấn đề tính toán liên quan đến cơ sở dữ liệu và khai phá dữ liệu
25 p | 75 | 7
-
Bài giảng Công nghệ phần mềm: Chương 2 - Trường ĐH Công nghiệp TP. HCM
53 p | 17 | 7
-
Pro Entity Framework 4.0 - Apress_6
26 p | 86 | 5
-
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile)
10 p | 67 | 3
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn