Extreme Programming (XP)

Extreme Programming (XP) Trong những năm gần đây, các công ty, tổ chức hoạt động trong lĩnh vực sản xuất phần mềm đang dần làm quen và sử dụng các phương pháp phát triển phần mềm mới nằm trong nhóm các phương pháp phát triền phần mềm linh hoạt (Agile). Một trong các phương pháp Agile kể trên phải nói đến Extreme Programming. Vậy Extreme Programming là gì? Nó được ra đời khi nào? Triết lý của nó là gì? Nó có ưu và nhược điểm ra sao? Tất cả những câu hỏi trên sẽ được giải đáp trong các phần tiếp theo của bài viết. Nhưng trước khi tiếp cận XP, hãy cũng lược sơ qua đôi nét về họ các phương pháp Agile và triết lý chung của dòng các phương pháp này. Họ phương pháp Agile. Agile không phải là một phương pháp mà là tên gọi chung cho một nhóm các phương pháp phát triển phần mềm được nghiên cứu và phát triển khoảng 20 năm trở lại đây. Các phương pháp Agile đều dựa trên các nguyên tác phát triển phân đoạn lặp và tăng trưởng (iterative and incremental). Theo đó các nhu cầu và giải pháp tiến hóa được thực hiện thông qua các nhóm tự quản. Agile sử dụng cách lập kế hoạch thích ứng, phát triển và chuyển giao phần mềm theo hướng tiến hóa, sử dụng các khung thời gian ngắn trong việc lập trình và chuyển giao sản phẩm để dễ dàng phản hồi lại những sự thay đổi của các yêu cầu trong quá trình phát triển. Một số phương pháp Agile có thể kể đến như Scrum, eXtreme Programming, Feature Driven Development (FDD), lean software development… Hệ các phương pháp phát triển phần mềm linh hoạt chính thức được biết đến với cái tên Agile là kết quả của một cuộc gặp gỡ giữa 17 nhà phát triển phần mềm tại Snowbird, Utar Resort. Tại đây, họ thảo luận về các phương pháp phát triển phần mềm gọn nhẹ, linh hoạt. Cuối cuộc gặp, họ cùng nhau thảo và công bố bản “Tuyên ngôn phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development”), và sau này được biết đến với cái tên ngắn gọn hơn “Tuyên ngôn Agile”. Bản tuyên ngôn tuy ngắn gọn nhưng rất quan trọng. Tuyên ngôn Agile là tập hợp tất cả các giá trị cốt lõi mà các nhà lý thuyết hay những người thực hành Agile cần tuân thủ, mặc dù các phương pháp Agile rất khác nhau. Tuyên ngôn Agile Tuyên ngôn Agile gồm 5 giá trị cốt lõi: Cá nhân và sự tương tác. Phần mềm hoạt động tốt. Cộng tác với khách hàng. Phản hồi lại với sự thay đổi. Ngoài 5 giá trị cốt lõi trên, kèm theo tuyên ngôn Agile, 12 nguyên lý kèm theo tuyên ngôn sẽ giúp cho các nhà thực hành Agile có những gợi ý để vận dụng Agile vào thực tiễn: Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. Phần mềm chạy tốt là thước đo chính của tiến độ. Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản. Các kiến ​​trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức. Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. eXtreme Programing (XP). XP là gì? XP là một phương pháp phát triển nằm trong họ các phương pháp Agile, chú trọng đến các kĩ thuật lập trình ứng dụng, giao tiếp giữa các thành viên và làm việc nhóm. Triết lý phát triển phần mềm của XP dựa trên các giá trị: Giao tiếp, phản hồi, đơn giản, sự dũng cảm và sự tôn trọng. Mục đích cuối cũng của XP là đáp ứng được các nhu cầu của khách hàng, tạo ra sản phẩm chất lượng với chi phí thấp nhất, ít lỗi nhất và tối đa lợi nhuận đầu tư. Để hiện thực hóa các giá trị trên nhằm đạt được mục đích đã đề ra, XP còn có các nguyên tắc và các kỹ thuật thực hành kèm theo khác. (Đang viết, cái này ở trong quyển Extreme Programming Explained: Embrace Change, Second Edition) Nguyên tắc trong XP Humanity: Yêu tố con người là yếu tố đầu tiên được đề cập đến trong XP. Con người lập trình nên phần mềm. Tuy nhiên, trong hầu hết các phương pháp phát triển phần mềm trước đây, các yếu tố liên quan đến những nhu cầu chính đáng của con người vẫn chưa được quan tâm đến. Một khi nhu cầu của con người được đảm bảo sẽ kích thích khả năng sáng tạo và hiệu quả làm việc. XP đề xuất cách làm việc 40 giờ một tuần để đảm bảo rằng nhân viên có được sức khỏe tốt nhất khi tiến hành công việc. Economics: Phải chắc chắn rằng tất cả mọi thứ ta đang làm đều mang giá trị thương mại, đạt được mục tiêu thương mại và phục vụ lợi ích thương mại. Ví dụ cần giải quyết các yêu cầu có độ ưu tiên thương mại cao để tối ưu hóa giá trị của một dự án. Bên cạnh đó, XP sử dụng cách thiết kế phát triển phần mềm thành từng phần nhỏ (increment) giúp làm giảm việc phát triển các phần không mong muốn do sự thay đổi yêu cầu từ khách hàng. Một phương thức nhằm tăng giá trị thương mại trong XP khác là hoàn toàn có để phát triển một increment từ những increment khác có liên quan trước đó. Điều này làm cho các increment có giá trị cao hơn so với việc chúng chỉ có thể sử dụng cho nhưng yêu cầu ban đầu. Mutual Benefit Lợi ích đôi bên là nguyên tắc quan trọng nhất và cũng là khó thực hiện nhất. XP đòi hỏi mỗi hoạt động nên tạo lợi ích cho các hoạt động có liên quan. Điển hình là việc “Giao tiếp với tương lai”, hay nói cách khác là làm thế nào để giải quyết được việc một nhóm nào đó trong tương lai có thể bảo trì và chỉnh sửa cách dễ dàng các đoạn mã chương trình của ta hiện tại. Cách truyền thống là tạo những bộ tài liệu hỗ trợ mô tả chương trình. Và tất nhiên, quá trình này sẽ làm chậm tốc độ hoàn thành công việc của nhóm, không tạo ra lợi ích cho hiện tại. Đối với XP, vấn đề trên được giải quyết bằng những cách thức mang lợi ích đôi bên sau: Tạo những bản test tự động nhằm giúp phần thiết kế và lập trình phần mềm tốt hơn. Đồng thời để lại các bản test này cho những lập trình viên sau này. Giảm thiểu tối đa các phần mã khó hiểu nhằm làm cho các đoạn mã trong chương trình trong sáng, đơn giản và dễ hiểu. Chọn cách đặt tên biến hợp lý, dễ hiểu nhằm tăng tốc độ phát triển phần mềm của bản thân đồng thời tạo các đoạn mã rõ ràng cho các nhà lập trình mới. Seft-Similarity: Improvement: Theo XP, không có định nghĩa cho sự hoàn hảo trong phát triển phần mềm: không có một quy trình hoàn hảo, không có một sản phẩm hoàn hảo, chỉ có sự cải tiến liên tục từng ngày để đạt được mức gần hoàn hảo mà thôi. Do vậy, việc sử dụng một mô hình phát triển chia thành nhiều increment đã hiện thực hóa cách nhìn của XP. XP không chờ đợi để tạo ra một bản thiết kế hoàn hảo cho toàn bộ dự án trước khi đi vào xây dựng mà xây dựng các bản thiết kế trong từng giai đoạn phát triển. Qua thời gian, các bản thiết kế trên sẽ được chỉnh sửa, thay đổi theo thực tế để đạt đến sự hoàn hảo cần thiết. Diversity: Reflection: Một nhóm tốt không chỉ là nhóm chỉ biết làm công việc của họ, mà còn phải biết nghĩ họ đang làm như thế nào và tại sao họ lại làm như vậy. Họ phải biết phân tích sự thành công và thất bại của nhóm. Các thành viên không giấu giếm khuyết điểm của mình nhưng dựa vào những khuyết điểm đó để hoàn thiện hơn. Việc đưa ra các phản hồi đến người khác và nhận phản hồi từ họ là điều không thể thiếu trong một nhóm XP. Không chỉ phản hồi trong các cuộc gặp mặt chính thức: mỗi ngày, mỗi lần xuất sản phẩm hay lúc lập trình cặp, việc phản hồi có thể thực hiện ở bất kì lúc nào kể cả trong bữa ăn. XP cổ vũ sự học hỏi từ các phản hồi. Flow: Opportunity: Hay xem mọi vấn đề phát sinh là một cơ hội: cơ hội học tập, cơ hội phát triển bản thân chứ không phải là thứ mà ta cần làm mọi thứ để có thể sinh tồn. Redundancy: Failure: Nếu như bạn có 3 phương pháp khác nhau và bạn không biết cách nào tốt nhất. Đừng phí phạm quá nhiều thời gian vào việc bàn luận, tranh cãi. Hãy thực hiện cả 3 và có thể bạn sẽ tìm ra câu trả lời. Nếu cả 3 đều thất bại thì điều đó cũng không là cái gì lớn lao cả. Bạn đã học được nhiều thứ từ những lần thất bại ấy. Quality: Đừng nên hy sinh chất lượng để đạt được hiệu suất làm việc cao. Một dự án không tiến triển nhanh hơn nếu chấp nhận việc sản xuất với chất lượng thấp, cũng không chậm hơn nếu đặt mục tiêu phát triển với chất lượng cao hơn. Không những thế, phát triển dự án với chất lượng cao, xử lý mã nguồn sạch sẽ còn làm tăng hiệu năng và hiệu quả công việc. Những đoạn mã sạch, hợp lý giúp tối ưu quá trình bảo trì và kiểm thử. Baby Steps: XP sử dụng phương thức phát triển phần mềm với nhiều bước ngắn và tích hợp, kiểm tra liên tục. Nguyên lý này giúp hạn chế tối đa những rủi ro có thể do những sự thay đổi trong yêu cầu của khách hàng gây nên. Accepted Responsible: Các kĩ thuật thực hành cơ bản: Sit together: ngồi làm việc cùng nhau. Whole Team: Infomative Workspace: Enegized Work: Pair Programming: Stories: Weekly Cycle: Quanterly Cycle: Slack: Ten-Minute Build: Continuous Integration: Test-First Programming: Incremental Design: So sánh XP với Water Fall và Scrum Khi so sánh giữa những phương pháp phát triển phần mềm hay khi so sánh những thứ với nhau, thì việc so sánh cho dù có dựa trên nhứng kiến thức nhưng chắc chắn phụ thuộc vào các tiêu chí và quan điểm của người so sánh vì vậy việc so sánh này chúng tôi không nhằm mục đích chỉ ra phương pháp nào tốt hơn mà mục đích chỉ ra những điểm khác biệt cơ bản giữa chúng và khi nào sử dụng phương pháp nào thì tốt nhất. Và để có cái nhìn về những phương pháp chúng tôi sẽ so sánh với XP thì đầu tiên chúng tôi xin giới thiệu sơ về Water Fall và Scrum. Water Fall là gì? Water Fall là một quy trình phát triển phần mềm truyền thống theo hướng một chiều, từ trên xuống dưới. (như trong sơ đồ). Quy trình Water Fall gồm có 5 giai đoạn. Requirements là giai đoạn xác định những yêu cầu của phần mềm. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu đặc tả yêu cầu phần mềm hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án. Design hay System Analysis &Design: là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó.Hiện thực và kiểm thử từng thành phần (Implementation): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.Kiểm thử (Verification): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.Cài đặt và bảo trì (Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). Scrum là gì? Scrum là phương pháp phát triển phần mềm được phát triển 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 đó có 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 [1] Scrum được biết đến như là 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. 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à bàn giao sản phẩm. Và sau đây chúng tôi sẽ đi vào so sánh XP với Water Fall và Scrum Các đặc điểm chính: Trong phần này, chúng tôi so sánh đặc điểm chính của 3 phương pháp. Đó là những đặc điểm lấy ra từ nội dung của phương pháp, không liên quan đến việc áp dụng những phương pháp này như thế nào, đó là: vai trò của khách hàng, thời gian phát hành, tài liệu trong quá trình phát triển, khả năng đáp ứng thay đổi và sự hướng dẫn của phương pháp. Trong 3 phương pháp XP, Water Fall, Scrum, vai trò của khác hàng đều rất quan trọng. Đều là người đưa ra yêu cầu và định hướng cho dự án. Nhưng ở Water Fall, khách hàng chỉ tham gia vào bước lấy yêu cầu phần mềm. Còn ở 2 phương pháp còn lại, khách hàng đều tham gia vào toàn bộ dự án, trở thành một phần của đội phát triển phần mềm. Về thời gian phát hành, ở Water Fall không đề cập tới thời gian cụ thể sẽ phát hành sản phẩm, nhưng nhìn chung thời gian phát triển phần mềm khá dài, khách hàng cần phải có sự kiên nhẫn và nếu trong quá trình phát triển phần mềm của Water Fall nếu xãy ra lỗi thì sẽ phải tốn rất nhiều thời gian để khắc phục. Trong khi đó Scrum đưa ra sản phẩm sau mỗi vòng lặp Sprint, thời gian là 30 ngày. Đối với XP, mỗi vòng lặp kéo dài 1 đến 2 tuần, như vậy XP đưa ra sản phẩm sau từ 1 đến 2 tuần. Về tài liệu trong quá trình phát triển phần mềm.Với Water Fall, tài liệu là thứ không thể thiếu. Bởi vì nó là kết quả cũng như tài nguyên cần thiết để giai đoạn tiếp theo sau của dự án có thể vận hành được. Điều này trái ngược với tư tưởng lập trình nhanh của XP và Scrum trong họ Lightweight methodology, cả 2 phương pháp này đã hoàn toàn loại bỏ sự xuất hiện của tài liệu “doccument” trong quy trình phát triển phần mềm. Thay vì viết tài liệu, cả 2 tập trung phát triển phần mềm, chú trọng xây dựng các kiểm thử và các chức năng hoạt động tốt là thước đo chính cho phát triển dự án. Về khả năng đáp ứng thay đổi. Chúng ta đều biết rằng yêu cầu của khách hàng có thể thay đổi bất cứ lúc nào và càng đáp ứng được điều đó thì càng tốt. Nhưng với Water Fall, phương pháp này được xây dựng và theo phương châm là yêu cầu đã được phía khách hàng suy nghĩ kỹ lưỡng từ trước nên phương pháp này khó khăn trong việc đáp ứng sự thay đổi yêu cầu từ phía khác hàng. Ngược lại, 2 phương pháp còn lại đều cho rằng việc thay đổi yêu cầu từ phía khách hàng là tất yếu. XP có một nguyên tắc là “Embracing Change” [2] nghĩa là cần phải đối mặt, chấp nhận sự thay đổi cho thấy XP đáp ứng tốt sự thay đổi. Ở Scrum, để đảm bảo tính ổn định, những sự thay đổi được ghi nhận, nhưng không được xử lí ngay. Tham khảo: Schwaber K. (1996), SCRUM Development Process. Beck.K (2000) Extreme Programming Explained.