Extreme Programing

Extreme Programming (XP): Một Phuơng Cách Mới Trong Phát Triển Phần Mềm

(bài của bác GiangĐỗ)

I. Phần Giới Thiệu:

Có lẽ cái tên Extreme Programming, hay gọi tắt là XP có thể đã được nghe đến, hoặc đang ứng dụng trong các dự án phát triển phần mềm tại Việt Nam. Tuy nhiên, cách đây không lâu trong các cuộc phỏng vấn kỹ thuật một số dự tuyển viên lập trình, và kỹ sư phần mềm ở vùng Bắc Mỹ , những người đã có một số năm kinh nghiệm, tôi nhận thấy cái tên XP có nguời chưa bao giờ nghe đến, có nguời nghe tới nhưng chưa bao giờ ứng dụng trong các dự án của mình. Càng ngày kiến thức tổng quát về phương pháp phát triển phần mềm (Software Methodologies) nói chung, và XP nói riêng đã trở thành một đòi hỏi cần thiết trong việc quyết định tuyển cử nhân sự cho các dự án. Biết được XP là gì, và ứng dụng được XP không những có thể giúp các bạn trong công việc phát triển phần mềm hàng ngày mà còn đem đến cho bạn cơ hội thành công trong các cuộc phỏng vấn. Các bạn đồng nghiệp ở Việt Nam, nếu chưa nghe đến XP, có lẽ sẽ tự hỏi “Vậy XP là gì? Tại sao phải cần XP trong các dự án phát triển phần mềm? Và điều quan trọng phải ứng dụng XP như thế nào để có thể phát triển thành công một dự án?”. Mục đích của bài viết này nhằm trả lời cho các câu hỏi đó.

II. Extreme Programming:

Extreme Programming (XP) ra đời vào khoảng tháng 3 năm 1996 khi nhóm 3 kỹ sư phần mềm: Kent Beck, Ward Cunningham, và Ron Jeffries nắm trọng trách phát triển dự án Chrysler Comprehensive Compensation System (thường được biết đến qua cái tên dự án C3). Kent Beck lúc đó là trưởng nhóm kỹ thuật (Project Leader) và ông ta đã bắt đầu trau chuốt phương pháp XP trở thành một phương pháp tinh tế trong việc phát triển phần mềm. Có nếm những thất bại phủ phàng trong việc phát triển phần mềm, người ta mới có thể hiểu được tại sao nhóm kỹ sư này lại tạo thêm một phương thức phát triển mới cho phần mềm. Có khi nào bạn cùng các đồng nghiệp trải qua những ngày dài làm việc mệt mỏi trong hàng tháng trời để đến phút cuối khi công việc gần xong thì người sử dụng (end user) đổi ý và sửa lại các yêu cầu. Nhiều lúc sự thay đổi của các điều kiện, và yêu cầu xảy ra quá mức kiểm soát (thường được gọi là Scope Creep hay Requirement Creep) đã dẫn đến tổn thất về tài chính và nhân lực, và rồi dẫn đến sự thất bại của dự án. Có những dự án ngay cả chính người sử dụng cũng không biết mình cần những yêu cầu và đòi hỏi nào. Đây là những trường hợp vô cùng nguy hiểm vì bạn biết chắc rằng sự thay đổi trong yêu cầu cùa người sử dụng sẽ xảy ra, và có thể xảy ra thường xuyên nữa. Khi đó làm sao bạn có thể đối đầu được với những thay đổi này và tránh được những tổn phí. Các mô hình phát triển theo Chu Kỳ Phát Triển Phần Mềm (SDLC) như WaterFall, RAD, JAD điều đòi hỏi các yêu cầu bắt buộc của người sử dụng phải rõ ràng và không được thay đổi để tránh các tổn phí sau này. Ngoài ra các yêu cầu này phải được tiếp thu trong giai đoạn đầu trong chu kỳ phát triển. Đây là một điều mà ngày càng trở nên khó thực hiện và trở nên không thực tế. Mục tiêu cùa XP là làm sao giảm bớt các phí tổn gây ra bởi sự thay đổi trong yêu cầu của người sử dụng. Qua đó XP đã trở thành một phương pháp mềm dẻo có thể hòa hợp giữa con người và sản phẩm.

III. Tại Sao Cần XP:

XP mang đến những đến những giá trị cần thiết trong việc phát triển phần mềm. Có tất cả 5 giá trị chính:

Thông Tin (Communication)

Các thành viên trong nhóm xây dựng dự án, và qui trình kỹ thuật cần có sự trao đổi ý kiến, chia xẻ kinh nghiệm, và phản ánh không những qua các bản thảo mà còn qua giao tiếp, và đối thoại hàng ngày.

Đơn Giàn (Simplicity)

Người trong giới lập trình thường có câu “Simplicity is the number one Design rule” (Đơn giản là điều kiện đầu tiên trong thiết kế phần mềm), hoặc đôi khi nhắc đến cái gọi là luật KISS hay “Keep It Simple, Stupid” (Làm cho nó đơn giản đi, đồ ngu). XP nhấn mạnh đặc điểm này qua đề nghị các giải pháp khi khởi đầu nên đơn giản sau đó có thể có thể được trau giồi lại cho tốt đẹp hơn. Giải pháp càng đơn giản thì càng có thể chia sẻ với mọi người ở mọi trình độ.

Phản Hồi (Feedback)

Sự phản hồi rất quan trọng và cần thiết trong XP. Thành công trong việc hiểu được ý kiến, và phản ánh của người sử dụng chương trình là điều kiện tất yếu cho sự thành công của dự án. Ngoài ra sự phản hồi của hệ thống đang xây dựng, và sự đóng góp ý kiến của mọi người trong nhóm cũng rất cần thiết.

Can Đảm (Courage)

Tại sao lại nói đến can đảm trong phát triển phần mềm. Can đảm của XP là có thể luôn luôn thiết kế và viết mã lệnh cho ngày hôm nay mà không phải là ngày mai. Cùng một lúc đó cũng có can đảm nếu đến lúc phải bỏ đi những mã lệnh rắc rối và viết lại cho tốt đẹp hơn.

Tôn Trọng (Respect)

Đây là một giá trị mới nhất của XP. Chúng ta nên luôn luôn tôn trọng những thành quả của nguời trong nhóm. Sự tôn trọng đó có thể là không để công việc cùa mình làm trì trệ công việc của người khác. Khi thảo trình chung trong cùng một chuơng trình thì lúc nào cũng phải bảo đảm phần cú pháp không đuợc có lỗi khi trả chuơng trình về cơ sở dữ liệu của version control (Visual Source Safe, StarTeam, etc).

IV. Áp Dụng XP:

Việc áp dụng lý thuyết hay thực hành xưa nay vẫn thường coi là khó. XP, giống như các phương pháp phát triển phần mềm khác, đều có những ngoại lệ và giới hạn.

Trước hết XP không phải là phương pháp có thể sử dụng trong các dự án ở mọi cỡ. Theo kinh nghiệm và quan sát hiện thời, XP mang đến nhiều lợi ích cho các dự án có qui mô nhỏ hoặc trung bình. Những dự án mà đội ngũ kỹ sư nằm trong khoảng từ 2 tới 12 người. Tuy nhiên có một vài dự án mà thành phần tham gia lên tới 30 người được nghe biết là đã thành công khi ứng dụng XP. Kinh nghiệm của chính tôi trong các dự án có từ 5 hoặc 8 người thì XP thực sự chiếm nhiều ưu thế trong sự thành công của dự án hơn so với các mô hình, hoặc phương pháp khác. Vậy tại sao lại có sự giới hạn này trong XP? Trước hết hãy coi thử cách áp dụng XP:

Các điều luật, và cách thực hành XP được gói trọn trong 4 giai đoạn: Planning (Quy hoạch), Designing (Thiết Kế), Coding (Lập Trình), và Testing (Kiểm Định).

Planning (Quy Hoạch)

Phần sau đây là các bước nên thực hiện trong giai đoạn quy hoạch:

User Stories: (Nhu cầu của nguời sử dụng)

Thông thường trưỏng nhóm kỹ thuật tổ chức một buổi họp giữa người sử dụng và nhóm kỹ sư để thâu thập các nhu cầu mà dự án phải mang đến cho người sử dụng. Trong cuộc họp này bạn nên mang theo các index card khoảng 6 cm X 8 cm. Những tấm card nhỏ này sẽ được người sử dụng dùng để viết xuống những nhu cầu mà họ muốn cho chương trình. Chẳng hạn:

“Tôi muốn một chương trình có cửa sổ cho mọi người phải login trước khi có thể sử dụng phần mềm kế toán cho tổ hợp gia công giày dép châu âu. Nếu như sau 3 lần truy nhập mà vẫn chưa thể vào được chương trình thì login ID phải bị khoá và người sử dụng phải liên hệ admin để giải khoá hoặc xin mật mã mới.”

Release Planning: (Quy hoạch chuyển giao)

Người sử dụng sẽ viết các yêu cầu trên những tấm card nhỏ. Sau đó trên mỗi tấm card đánh một số thứ tự để ưu tiên cho các yêu cầu này. Các số thứ tự có thể từ 1 đến 5 hoặc hơn nữa với số 1 là ưu tiên hàng đầu cần làm trước và 5 là cái có thể làm sau. Xin nhớ đừng để người sử dụng viết dài quá. Là người trưởng nhóm trách nhiệm quan trọng của bạn trong các buổi họp với người sử dụng đó là quản lý thời gian của buổi họp, đạt được mục tiêu của buổi họp, và tránh những bàn luận ngoài đề. Yêu cầu ngắn gọn, nhưng đầy đủ là một trong những mục tiêu của cuộc họp này. Nên nhớ đây vẫn trong phạm vi quy hoạch do đó tránh đừng quá chi tiết và kỹ thuật quá ở giai đoạn này. Phần kế tiếp các thành viên kỹ thuật của dự án sẽ tham vấn những tấm card yêu cầu này và cho biết sự ước lượng của mình cho sự hoàn tất các yêu cầu của người sử dụng. Thông thường họ có thể đánh giá các yêu cầu bằng những con số chẳng hạn từ 10 đến 50 trên những tấm card. Số 10 có thể là yêu cầu này dễ làm có thể chỉ mất 1 hay 2 ngày. Số 50 là khó nhất có thể mất 1 tuần hoặc hơn nữa. Tránh những ước lượng trên 3 tuần. Nếu như có tấm card nào có sự ước lượng trên 3 tuần thì bạn nên chia nó ra thành 2 card. Nên nhớ việc đánh số không bắt buộc nhưng dùng cách này để giúp người sử dụng có khái niệm chút ít về cái giá mà họ phải trả cho những nhu cầu của họ. Trong cuộc họp này người sử dụng và các thành viên kỹ thuật sẽ thương lượng trên các tấm card về lịch trình, thời điểm hoàn thành, cái gì cần làm trước, làm sau và bao giờ. Cuộc họp sẽ chấm dứt khi 2 bên đạt được một thỏa thuận thực tế cho các yêu cầu. Nhớ đừng kéo dài cuộc họp hơn 1, 2 tiếng. Các thành viên sẽ còn có dịp gặp trực tiếp người sử dụng để kiểm chứng hoặc xin giải đáp những vấn đề liên quan đến nhu cầu. Đây là lúc mà giá trị thông tin (communication) thể hiện. Mặt khác người sử dụng có thể sẽ đổi ý về nhu cầu có khi ngay lúc họ rời phòng họp hoặc lúc lập trình viên đang thảo chương trình. Do đó họ sẽ gặp sẽ gặp trực tiếp thành viên chịu trách nhiệm về nhu cầu trên tấm card. Quá trình này có thể sẽ lập lại nhiều lần cho đến khi nhu cầu đạt điểm chính xác và rõ ràng. Đây là ưu thế của XP. Khả năng tiếp nhận những thay đổi trong nhu cầu cùng lúc có thể giảm bớt các chi phí liên hệ đến sự sửa chửa của những nhu cầu này.

Thiết Kế (Designing)

Thiết kế là giai đoạn rất quan trọng. Là trưởng nhóm kỹ thuật những quyết định về thiết kế và phương pháp lập trình của bạn ảnh hưởng rất lớn trong quá trình phát triển dự án. Các tiêu chuẩn đặt tên cho các biến số (naming conventions), lớp (class), và vật hướng (Design Patterns), cũng như phương thức vẽ đồ hình thiết kế (UML) rất có lợi cho quá trình phát triển dự án. Khi tất cả các thành viên kỹ thuật đều có chung một kiến thức về các phép ẩn dụ trong cách đặt tên biến số và phương thức thiết kế vật hướng, việc lập trình không những tốn ít thì giờ mà còn tránh được những sai lầm phức tạp. Ngoài ra khi thiết kế nên thật đơn giản khi khởi đầu. Tại sao? thiết kế càng đơn giản thì lập trình càng dễ. Lập trình dễ thì chương trình càng xong nhanh. Mặt khác nếu như người sử dụng thay đổi nhu cầu việc thay thế giải pháp thiết kế đơn giản cũng sẽ không quá tốn kém. Tuy nhiên giai đoạn thiết kế cũng bao gồm phần cải tiến (refactoring). Cải tiến đây là tiếp tục làm cho sản phẩm tốt đẹp và có năng suất hơn khi ra thị trường. Trong lập trình tiếp tục cải tiến các mã lệnh, vật hướng dễ sử dụng, và được tái sử dụng giữa các chương trình sẽ mang lại nhiều lợi ích không những cho dự án đang thực hiện mà có thể cho các dự án khác sau này. Một khái niệm thú vị trong phần thiết kế mà tôi biết đến đó là giải pháp spike (spike solution). Khi chúng tôi đối đầu với một vấn đề khó khăn kỹ thuật và các khái niệm kỹ thuật đưa ra không chắc là đúng, giải pháp spike sẽ dùng 1 hoặc 2 thành viên nghiên cứu khái niệm bằng cách thảo ra chương trình thực nghiệm trong 1 khoảng thời gian ngắn để chứng minh cho khái niệm của giải pháp. Cách này giảm bớt được yếu tố mạo hiểm trong việc dùng các giải pháp không đúng đưa đến sự thất bại của dự án.

Lập Trình (Coding)

Nên lập trình theo một tiêu chuẩn thực hành tốt nhất (best practices). Kiểu cách lập trình (programming style, coding standards), và các mẫu lập trình cần được bàn luận và chia sẻ giữa các thành viên kỹ thuật trong nhóm. Khi bắt đầu lập trình cho dự án, nên thảo các chương trình kiểm định trước khi chính thức thảo chương trình cho các nhu cầu. Đây là một điều rất khó cho một số lập trình viên đã quen với các phương pháp phát triển khác vì việc kiểm định khi nào cũng xảy ra sau khi việc thảo chương được hoàn thành. Ở khâu này chương trình NUnit hiện được sử dụng khá phổ biến trong việc lập trình chuơng trình kiểm định (unit test). Là trưởng nhóm kỹ thuật, nhiệm vụ của bạn là phải bảo đảm các tiêu chuẩn, phương thức lập trình được tuân thủ nghiêm túc. Cái tên XP là từ Extreme Programming. Tĩnh từ Extreme trong cái tên XP mang ý nghĩa phải tuyệt đối tuân thủ, và nổ lực đạt các tiêu chuẩn, và phương thức đặt ra. Khái niệm kế tiếp trong khâu lập trình là sự thảo trình cặp đôi (pair programming) và quyền sở hữu chung (collective ownership) của chương trình. Cứ 2 thành viên làm thành một nhóm và lập trình chung cho 1 chương trình. Khi 2 người làm chung cho 1 chương trình cho 1 nhu cầu. Chương trình đó sẽ có ít nhất 2 người biết đến. Nếu như 1 trong 2 người vắng mặt vì 1 lý do nào đó, dự án vẫn có thể tiếp tục vì người kia sẽ nối tiếp công việc 1 cách dễ dàng. Luôn luôn làm cho các mã lệnh, hoặc chương trình mới viết được xử lý một cách hòa hợp với các mã lệnh, hoặc chương trình có trước đó (continuous integration). Quan trọng hơn nữa luôn luôn cất giữ cẩn thận các thành quả cuả dự án bằng cách bỏ chúng vào các kho mã lưu giữ mã lệnh (code repository, Visual SourceSafe, StarTeam).

Kiểm Định (Testing)

Tất cả các mã lệnh phải có thể kiểm định đuợc. Không nên viết một hàm, hoặc các mã lệnh khi bạn không biết cách kiểm định chúng. Đó là lý do tại sao XP đòi hỏi viết các chương trình kiểm định trước khi viết chương trình cho các nhu cầu (Test Driven Development).

Khi một lỗi được khám phá, một chương trình kiểm định mới phải được viết ra khi chữa lỗi đó.

Khi các khâu kiểm định unit test, system test, performance test, integration test được hoàn thành, một khâu kiểm định dành cho người sử dụng cần phải được tiến hành (user acceptance test). Khi khâu kiểm định này kết thúc tốt đẹp đã đến lúc bạn chuẩn bị chuyển giao sản phẩm phần mềm của bạn cho người sử dụng.

Reference:

Extreme Programming Explained: Embrace Change (2^nd Edition), Kent Beck And Cynthia Andres