• Thứ Ba, 16/12/2003 16:47 (GMT+7)

    XP thách thức ISO/CMM

        Phương pháp phát triển phần mềm linh hoạt thách thức các phương pháp phát phiển phần mềm qui ước.
        Có một “truyền thống” trong lĩnh vực phát triển phần mềm (PM): các dự án PM luôn trễ bất chấp kế hoạch “thực tế” đến mức nào, và thường không đáp ứng kỳ vọng của khách hàng bất chấp các yêu cầu được chi tiết đến mức nào. Những qui trình phát triển PM qui ước như ISO hay CMM không dễ áp dụng và cũng không phải luôn bảo đảm thành công cho mọi dự án phần mềm. Theo nghiên cứu của Standish Group, ba phần tư các dự án PM có một trong các kết quả sau: thất bại hoàn toàn, vượt quá ngân sách, vượt quá thời gian, hoặc không đạt yêu cầu.
        Phương pháp phát triển phần mềm linh hoạt (PPPTPMLH) - tiêu biểu là XP - có thể thay đổi “truyền thống” này.

    SỰ TIẾN HOÁ TRONG PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM

        “Viết và sửa lỗi” là nhóm từ đặc trưng của công việc phát triển PM. Một thời gian dài (và cho đến hiện nay vẫn còn),PM được xây dựng theo phong cách “nghệ sĩ”: Với ý tưởng trong đầu, nhà lập trình “sáng tác” ngay trên máy, rồi sau đó cho chạy chương trình và… “sai đâu sửa đó”! Không có thiết kế hệ thống cũng như qui trình phát triển. Cách thức này làm việc tốt với hệ thống nhỏ, nhưng khi hệ thống phát triển lên thì việc bổ sung tính năng mới và sửa lỗi sẽ rất phức tạp và khó khăn. Một vấn đề tiêu biểu của cách thức này là giai đoạn kiểm tra dài có thể phá hỏng tiến độ vì việc kiểm tra và sửa lỗi không thể định thời gian chính xác.

        Chúng ta cũng đã sống với một phương thức khác thời gian dài không kém: Phương pháp công nghệ. Phương pháp này đưa ra qui trình chi tiết và chặt chẽ nhằm làm cho việc phát triển PM có thể kiểm soát và dự đoán - lấy ý tưởng từ những ngành công nghệ khác như xây dựng hay cơ khí - vì vậy được gọi là phương pháp công nghệ. Tiêu biểu là các qui trình ISO và SEI-CMM (Capability Mature Model – qui trình phát triển PM của Học viện công nghệ phần mềm SEI, www.sei.cmu.edu) hay CMMI (CMM Integration).
        Các phương pháp công nghệ có những mặt tốt: các biểu đồ, tài liệu thiết kế, môi trường phát triển nhóm và một loạt công cụ. Tuy nhiên, các phương pháp này thường bị phê phán là quá nặng nề và tốn nhiều thời gian. Sự “nặng nề” không chỉ ở chỗ khối lượng giấy tờ tài liệu sử dụng mà còn ở chỗ công việc quản lý, kiểm tra chất lượng, và nhiều thủ tục cứng nhắc buộc các lập trình viên phải tuân theo.

        Rõ ràng, cần có sự cân bằng giữa hai thái cực, đó chính là lý do xuất hiện các phương pháp phát triển PM gọn nhẹ, linh hoạt đang nhận được ngày càng nhiều sự quan tâm. Các phương pháp này cung cấp qui trình vừa đủ, thoả hiệp giữa “không qui trình” với “qui trình quá cồng kềnh” nhằm phát triển PM nhanh hơn, hiệu quả hơn, linh hoạt hơn và ít tốn kém hơn. Các phương pháp phát triển PM mới này đứng chung dưới tiêu đề PPPTPMLH (Agile Software Development).

    PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT

        Khác biệt dễ nhận thấy của PPPTPMLH đó là lượng giấy tờ tài liệu ít hơn và có thể nói là tập trung vào việc lập trình hơn. Nhưng ẩn đằng sau đó là hai khác biệt nền tảng quan trọng: “thích ứng thay vì dự đoán” và “hướng đến con người thay vì qui trình”.














        Thích ứng thay vì dự đoán. Các phương pháp công nghệ thường cố gắng hoạch định phần lớn quá trình  phát triển PM thật chi tiết cho một thời gian dài, phương thức này tỏ ra tốt cho đến khi có sự thay đổi. Bản chất của các phương pháp này chống lại sự thay đổi. Công việc hoạch định gắn liền với dự đoán, đòi hỏi một số điều kiện như nhân lực và  yêu cầu hệ thống ổn định… Tuy nhiên, thường không phải dự án phần mềm nào cũng thoả mãn những điều kiện này. Môi trường kinh doanh hiện nay đầy biến động, các yêu cầu cũng biến động. Nhiều biến động trong môi trường kinh doanh và cả vấn đề nhân lực không thể dự đoán chính xác được.
        Ngược lại, PPPTPMLH chấp nhận sự thay đổi. Chúng được thiết kế nhằm thích ứng và phát triển theo sự thay đổi, thậm chí thay đổi ngay chính bản thân quy trình.
        Hướng đến con người thay vì qui trình. Một trong những mục tiêu của các phương pháp truyền thống là phát triển một qui trình tổng quát làm việc tốt cho mọi trường hợp, nhân sự tham gia là  thành phần có thể thay thế trong dây chuyền phát triển PM: phân tích, kiểm tra, lập trình, quản lý… Các cá nhân không quan trọng, chỉ có vai trò là quan trọng. Phương pháp này chịu ảnh hưởng của phương pháp dây chuyền sản xuất. Việc phát triển PM ngày càng thu hút những người trẻ, thông minh, năng động và đầy tài năng, thực tế cho thấy phương pháp trên hiện trở nên “chật chội” đối với họ.
        PPPTPMLH cho rằng không có qui trình nào đáp ứng hoàn toàn cho mọi trường hợp, mỗi nhóm phát triển PM có những điều kiện và kỹ năng riêng, mỗi dự án PM cũng có những yêu cầu riêng, qui trình chỉ đóng vai trò hỗ trợ. PPPTPMLH đề cao tính chủ động và sáng tạo của các cá nhân tham gia, và đặc biệt là việc trao đổi thông tin giữa các thành viên. Cách tiếp cận này yêu cầu có sự chia sẻ trách nhiệm mà trong đó công việc lập trình và quản lý có vị thế ngang nhau trong việc điều hành dự án.
        PPPTPMLH không khước từ sự tổ chức nhưng nó cố gắng cân bằng giữa sự tổ chức và sự linh hoạt, cân bằng giữa việc không có qui trình nào cả và qui trình quá chi li và cứng nhắc. Nó vẫn lập tài liệu thiết kế nhưng không để chết ngộp với hàng đống tài liệu, nó cũng hoạch định nhưng không mù quáng tuân thủ nghiêm ngặt theo kế hoạch.
        Có nhiều phương pháp phát triển PM đứng dưới tiêu đề PPPTPMLH như Adaptive (adaptivesd.com), Crystal (crystalmethodologies.org), DSDM (Dynamic Systems Development Method, dsdm.org), FDD (Feature Driven Development, featuredrivendevelopment.com), Scum (controlchaos.com) và XP (eXtreme Programming, extremeprogramming.org và xprogramming.com). Tuy có những cách tiếp cận khác nhau, nhưng các phương pháp này có một số điểm chung:
        •  Tính đến khách hàng trong qui trình phát triển.
        •  Có sự tham gia của cấp lãnh đạo ngoài bộ phận IT.
        •  Tập trung vào nhiệm vu.
        •  Xây dựng từng phiên bản nhỏ, thực hiện vừa đủ những tính năng cần thiết ở từng vòng lặp phát triển.
        •  Chu trình phát triển ngắn.
        •  Giữ cho yêu cầu tối thiểu.
        •  Giữ cho nhóm phát triển nhỏ.
        •  Liên tục kiểm tra.
        •  Chấp nhận và thích ứng nhanh với những thay đổi.
        •  Khuyến khích việc trao đổi giữa các thành viên.
        •  Cổ vũ tinh thần đồng đội.
        PPPTPMLH khuyến khích việc trao đổi thông tin thường xuyên giữa các thành viên của dự án, bao gồm cả khách hàng, xem đây là cách tốt nhất để cập nhật những thay đổi của kế hoạch, yêu cầu, thiết kế và mã nguồn.

    eXtreme Programming (XP)

        Trong các PPPTPMLH thì XP là phương pháp nhận được sự quan tâm nhiều nhất. Phương pháp này do Ken Besk, Ward Cunningham, Ron Jeffries và một số người khác phát triển, khởi nguồn từ dự án Chrysler Comprehensive Compensation, hay C3 (phần mềm tính lương thưởng của hãng xe hơi Chrysler, hiện vẫn đang được sử dụng).
        XP đưa ra 4 giá trị nền tảng: thông tin liên lạc, đơn giản, phản hồi và can đảm. Các lập trình viên XP trao đổi thông tin với khách hàng và các thành viên khác của dự án. Thiết kế được làm đơn giản và rõ ràng. Phản hồi từ việc kiểm tra liên tục. Đưa ra sản phẩm càng sớm càng tốt và thực hiện các thay đổi theo yêu cầu. Với nền tảng này, các lập trình viên XP có đủ can đảm đối phó với sự thay đổi yêu cầu và công nghệ.

        XP dùng từâ “extreme” (cực kỳ) vì nó đúc kết những kinh nghiệm thực tiễn phát triển PM tốt nhất (tuy có chữ “Programming” nhưng XP bao hàm phạm trù lớn hơn): lập trình đôi, xây dựng các kiểm tra trước, thường xuyên tái cấu trúc và xây dựng lại, liên tục tích hợp và kiểm tra… Một trong những đặc trưng của XP đó là nó nhấn mạnh đến việc kiểm tra, xem đây là nền tảng của việc phát triển, việc kiểm tra được xây dựng trước khi lập trình chức năng. Kiểm tra được tích hợp vào qui trình xây dựng và tích hợp liên tục để đạt được một nền tảng có tính ổn định cao cho việc phát triển trong tương lai. Trên nền tảng này, XP xây dựng một qui trình thiết kế tiến hóa dựa trên việc tái cấu trúc hệ thống cơ sở ở mỗi chu trình. Kết quả là một qui trình thiết kế chặt chẽ nhưng linh hoạt. Tuy nhiên không phải tất cả các qui tắc của XP đều luôn áp dụng được, tuỳ từng tình huống mà vận dụng có chọn lọc.

    LỜI KẾT
        Được sự ủng hộ của các chuyên gia và các nhà phát triển PM nổi tiếng, PPPTPMLH đang có được lực đẩy rất lớn và trở nên khá phổ biến trong vài năm trở lại đây.  Đặc biệt trong tình hình kinh tế suy thoái hiện nay, môi trường kinh doanh đầy biến động và cạnh tranh gay gắt tạo nên áp lực rất lớn đối với các dự án PM: yêu cầu tiến độ thực hiện nhanh hơn, chi phí thấp hơn và linh hoạt hơn…, các công ty cần có những phương pháp mới để cải tiến hiệu suất và đáp ứng nhanh với những thay đổi của thị trường.
        XP và các PPPTPMLH khác được thiết kế nhằm cung cấp PM mà khách hàng cần và vào đúng thời điểm cần thiết.
        Tuy vậy, PPPTPMLH không phải là giải pháp «vạn năng» có thể áp dụng cho mọi dự án phần mềm, cũng như các phương pháp phát triển PM qui ước không phải luôn thất bại với mọi dự án. Cần có những điều kiện nhất định để quyết định đi theo phương pháp nào.

    Tài liệu tham khảo
    •  The New Methodology, Martin Fowler
    •  Agile Software Development Manifesto
    •  Extreme Agile Programming, Computerworld Magazine

    Thanh Phong

     

    ID: A0307_90