Extreme programming(XP)

Chia sẻ: Cuong Vo | Ngày: | Loại File: DOCX | Số trang:8

Thêm vào BST

Báo xấu

388
lượt xem 40
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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).

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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. I. 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: 1. Ư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ị. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. Phần mềm chạy tốt là thước đo chính của tiến độ.
8. 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. 9. 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. 10. 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. 11. 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. 12. Độ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. II. eXtreme Programing (XP). 1. 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) 2. Nguyên tắc trong XP - Humanity: Yêu tố con người là yêu tố đâu tiên được đề câp đên trong XP. Con người lâp trinh nên ́ ̀ ̣ ́ ̣ ̀ phân mêm. Tuy nhiên, trong hâu hêt cac phương phap phat triên phân mêm trước đây, cac ̀ ̀ ̀ ́ ́ ́ ́ ̉ ̀ ̀ ́ yêu tố liên quan đên những nhu câu chinh đang cua con người vân chưa được quan tâm ́ ́ ̀ ́ ́ ̉ ̃ đên. Môt khi nhu câu cua con người được đam bao sẽ kich thich khả năng sang tao và hiêu ́ ̣ ̀ ̉ ̉ ̉ ́ ́ ́ ̣ ̣ quả lam viêc. XP đề xuât cach lam viêc 40 giờ môt tuân để đam bao răng nhân viên có ̀ ̣ ́ ́ ̀ ̣ ̣ ̀ ̉ ̉ ̀ được sức khoe tôt nhât khi tiên hanh công viêc. ̉ ́ ́ ́ ̀ ̣ - Economics: Phai chăc chăn răng tât cả moi thứ ta đang lam đêu mang giá trị thương mai, đat đ ược ̉ ́ ́ ̀ ́ ̣ ̀ ̀ ̣ ̣ muc tiêu thương mai và phuc vụ lợi ich thương mai. Ví dụ cân giai quyêt cac yêu câu có ̣ ̣ ̣ ́ ̣ ̀ ̉ ́ ́ ̀ độ ưu tiên thương mai cao để tôi ưu hoa giá trị cua môt dự an. ̣ ́ ́ ̉ ̣ ́ Bên canh đo, XP sử dung cach thiêt kế phat triên phân mêm thanh từng phân nhỏ ̣ ́ ̣ ́ ́ ́ ̉ ̀ ̀ ̀ ̀ (increment) giup lam giam viêc phat triên cac phân không mong muôn do sự thay đôi yêu ́ ̀ ̉ ̣ ́ ̉ ́ ̀ ́ ̉ câu từ khach hang. ̀ ́ ̀ Môt phương thức nhăm tăng giá trị thương mai trong XP khac là hoan toan có để phat ̣ ̀ ̣ ́ ̀ ̀ ́ triên môt increment từ những increment khac có liên quan trước đo. Điêu nay lam cho cac ̉ ̣ ́ ́ ̀ ̀ ̀ ́ increment có giá trị cao hơn so với viêc chung chỉ có thể sử dung cho nhưng yêu câu ban ̣ ́ ̣ ̀ đâu. ̀ - Mutual Benefit
Lợi ich đôi bên là nguyên tăc quan trong nhât và cung là khó thực hiên nhât. XP đoi hoi ́ ́ ̣ ́ ̃ ̣ ́ ̀ ̉ môi hoat đông nên tao lợi ich cho cac hoat đông có liên quan. Điên hinh là viêc “Giao tiêp ̃ ̣ ̣ ̣ ́ ́ ̣ ̣ ̉ ̀ ̣ ́ với tương lai”, hay noi cach khac là lam thế nao để giai quyêt được viêc môt nhom nao đó ́ ́ ́ ̀ ̀ ̉ ́ ̣ ̣ ́ ̀ trong tương lai có thể bao trì và chinh sửa cach dễ dang cac đoan mã chương trinh cua ta ̉ ̉ ́ ̀ ́ ̣ ̀ ̉ hiên tai. Cach truyên thông là tao những bộ tai liêu hỗ trợ mô tả chương trinh. Và tât ̣ ̣ ́ ̀ ́ ̣ ̀ ̣ ̀ ́ nhiên, quá trinh nay sẽ lam châm tôc độ hoan thanh công viêc cua nhom, không tao ra lợi ̀ ̀ ̀ ̣ ́ ̀ ̀ ̣ ̉ ́ ̣ ́ ich cho hiên tai. ̣ ̣ Đôi với XP, vân đề trên được giai quyêt băng những cach thức mang lợi ich đôi bên sau: ́ ́ ̉ ́ ̀ ́ ́ Tao những ban test tự đông nhăm giup phân thiêt kế và lâp trinh phân mêm tôt hơn. Đông ̣ ̉ ̣ ̀ ́ ̀ ́ ̣ ̀ ̀ ̀ ́ ̀ thời để lai cac ban test nay cho những lâp trinh viên sau nay. ̣ ́ ̉ ̀ ̣ ̀ ̀ Giam thiêu tôi đa cac phân mã khó hiêu nhăm lam cho cac đoan mã trong chương trinh ̉ ̉ ́ ́ ̀ ̉ ̀ ̀ ́ ̣ ̀ trong sang, đơn gian và dễ hiêu. ́ ̉ ̉ Chon cach đăt tên biên hợp ly, dễ hiêu nhăm tăng tôc độ phat triên phân mêm cua ban thân ̣ ́ ̣ ́ ́ ̉ ̀ ́ ́ ̉ ̀ ̀ ̉ ̉ đông thời tao cac đoan mã rõ rang cho cac nhà lâp trinh mới. ̀ ̣ ́ ̣ ̀ ́ ̣ ̀ - Seft-Similarity: - Improvement: Theo XP, không có đinh nghia cho sự hoan hao trong phat triên phân mêm: không có môt ̣ ̃ ̀ ̉ ́ ̉ ̀ ̀ ̣ quy trinh hoan hao, không có môt san phâm hoan hao, chỉ có sự cai tiên liên tuc từng ngay ̀ ̀ ̉ ̣ ̉ ̉ ̀ ̉ ̉ ́ ̣ ̀ để đat được mức gân hoan hao mà thôi. Do vây, viêc sử dung môt mô hinh phat triên chia ̣ ̀ ̀ ̉ ̣ ̣ ̣ ̣ ̀ ́ ̉ thanh nhiêu increment đã hiên thực hoa cach nhin cua XP. XP không chờ đợi để tao ra môt ̀ ̀ ̣ ́ ́ ̀ ̉ ̣ ̣ ban thiêt kế hoan hao cho toan bộ dự an trước khi đi vao xây dựng mà xây dựng cac ban ̉ ́ ̀ ̉ ̀ ́ ̀ ́ ̉ thiêt kế trong từng giai đoan phat triên. Qua thời gian, cac ban thiêt kế trên sẽ được chinh ́ ̣ ́ ̉ ́ ̉ ́ ̉ sửa, thay đôi theo thực tế để đat đên sự hoan hao cân thiêt. ̉ ̣ ́ ̀ ̉ ̀ ́ - Diversity: - Reflection: Môt nhom tôt không chỉ là nhom chỉ biêt lam công viêc cua ho, mà con phai biêt nghĩ họ ̣ ́ ́ ́ ́ ̀ ̣ ̉ ̣ ̀ ̉ ́ đang lam như thế nao và tai sao họ lai lam như vây. Họ phai biêt phân tich sự thanh công ̀ ̀ ̣ ̣ ̀ ̣ ̉ ́ ́ ̀ và thât bai cua nhom. Cac thanh viên không giâu giêm khuyêt điêm cua minh nhưng dựa ́ ̣ ̉ ́ ́ ̀ ́ ́ ́ ̉ ̉ ̀ vao những khuyêt điêm đó để hoan thiên hơn. ̀ ́ ̉ ̀ ̣ Viêc đưa ra cac phan hôi đên người khac và nhân phan hôi từ họ là điêu không thể thiêu ̣ ́ ̉ ̀ ́ ́ ̣ ̉ ̀ ̀ ́ trong môt nhom XP. Không chỉ phan hôi trong cac cuôc găp măt chinh thức: môi ngay, ̣ ́ ̉ ̀ ́ ̣ ̣ ̣ ́ ̃ ̀ môi lân xuât san phâm hay luc lâp trinh căp, viêc phan hôi có thể thực hiên ở bât kì luc nao ̃ ̀ ́ ̉ ̉ ́ ̣ ̀ ̣ ̣ ̉ ̀ ̣ ́ ́ ̀ kể cả trong bữa ăn. XP cổ vũ sự hoc hoi từ cac phan hôi. ̣ ̉ ́ ̉ ̀ - Flow: - Opportunity: Hay xem moi vân đề phat sinh là môt cơ hôi: cơ hôi hoc tâp, cơ hôi phat triên ban thân ̣ ́ ́ ̣ ̣ ̣ ̣ ̣ ̣ ́ ̉ ̉ chứ không phai là thứ mà ta cân lam moi thứ để có thể sinh tôn. ̉ ̀ ̀ ̣ ̀ - Redundancy: - Failure: Nêu như ban có 3 phương phap khac nhau và ban không biêt cach nao tôt nhât. Đừng phí ́ ̣ ́ ́ ̣ ́ ́ ̀ ́ ́ pham quá nhiêu thời gian vao viêc ban luân, tranh cai. Hay thực hiên cả 3 và có thể ban sẽ ̣ ̀ ̀ ̣ ̀ ̣ ̃ ̃ ̣ ̣
tim ra câu trả lời. Nêu cả 3 đêu thât bai thì điêu đó cung không là cai gì lớn lao ca. Ban đã ̀ ́ ̀ ́ ̣ ̀ ̃ ́ ̉ ̣ hoc được nhiêu thứ từ những lân thât bai ây. ̣ ̀ ̀ ́ ̣ ́ - Quality: Đừng nên hy sinh chât lượng để đat được hiêu suât lam viêc cao. Môt dự an không tiên ́ ̣ ̣ ́ ̀ ̣ ̣ ́ ́ triên nhanh hơn nêu châp nhân viêc san xuât với chât lượng thâp, cung không châm hơn ̉ ́ ́ ̣ ̣ ̉ ́ ́ ́ ̃ ̣ nêu đăt muc tiêu phat triên với chât lượng cao hơn. Không những thê, phat triên dự an với ́ ̣ ̣ ́ ̉ ́ ́ ́ ̉ ́ chât lượng cao, xử lý mã nguôn sach sẽ con lam tăng hiêu năng và hiêu quả công viêc. ́ ̀ ̣ ̀ ̀ ̣ ̣ ̣ Những đoan mã sach, hợp lý giup tôi ưu quá trinh bao trì và kiêm thử. ̣ ̣ ́ ́ ̀ ̉ ̉ - Baby Steps: XP sử dung phương thức phat triên phân mêm với nhiêu bước ngăn và tich hợp, kiêm tra ̣ ́ ̉ ̀ ̀ ̀ ́ ́ ̉ liên tuc. Nguyên lý nay giup han chế tôi đa những rui ro có thể do những sự thay đôi trong ̣ ̀ ́ ̣ ́ ̉ ̉ ̀ ̉ ́ yêu câu cua khach hang gây nên. ̀ - Accepted Responsible: 3. Các kĩ thuật thực hành cơ bản: - ̀ ̀ ̣ ̀ Sit together: ngôi lam viêc cung 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: III. 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. 1. 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). 2. 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.