Phương pháp phát triển phần mềm linh hoạt Agile Software Development Nhóm nghiên cứu: - Tri ệu Minh Tiến - Nguy ễn Viết Tùng - Ph ạm Đức Khánh (Chương trình Việt - Nhật * Đại học Bách Khoa Hà Nội) HEDSPI HUT Tài li ệu tham khảo: - Agile software development methods - Review and analysis Pekka Abrahamsson, Outi Salo & Jussi Ronkainen, 2002 - An Introduction to Agile Methods Steve Hayes (Khatovar Technology) Martin Andrews (Object Consulting) - Internet http://en.wikipedia.org/wiki/Agile_Software_Development … I. Tổng quan: 1. S ự cần thiết của một mô hình phát triển phần mềm mới Chúng ta đã vi ết phần mềm được 30 năm nhưng những gì chúng ta đã làm đ ược còn rất ít. Thành công của chúng ta được thúc đẩy bởi sự tưởng tượng, sáng t ạo của con người. Chúng ta càng viết ra nhiều phần mềm thì sự đòi hỏi, yêu cầu c ủa con người càng nhiều. Chính vì vậy, những nhà quản lý và phát triển phần mềm tiếp tục tìm kiếm phương thức phát triển phần mềm tốt hơn. So với 30 năm tr ước chúng ta đã có những chiếc máy tính rẻ hơn, nhanh hơn, nhiều ngôn ngữ lập trình m ạnh mẽ ra đời, số lượng nhiều hơn cần thiết những công cụ hỗ trợ, sự đào tạo tốt hơn và có những hiểu biết sâu hơn về lý thuyết phần mềm. Internet đã thay đ ổi cách con người giao tiếp với nhau, thúc đẩy sự trao đổi thông tin và thay đổi m ột cách triệt để sự kỳ vọng của con người về cách thức phần mềm làm việc. Chúng ta c ũng có số lượng đáng kể những phương pháp khác nhau giúp xác định con đường phát triển phần mềm tốt nhất và đó chính là khía cạnh của việc phát tri ển phần mềm mà chúng ta sẽ tập trung vào trong thời gian tới. a. Nh ững hạn chế của mô hình phát triển phần mềm truyền thống Đã có r ất nhiều mô hình phát triển phần mềm được tạo ra trong những năm qua. Có th ể kể đến như: - Pure waterfall - Code-and-Fix - Spiral - Modifed Waterfalls - Evolutionary Prototyping - Staged Delivery - Evolutionary Delivery - Design-to-Schedule - Design-to-Tools - Commercial Off-the-shelf Software Khi xây d ựng các phương pháp truyền thống người ta đã cố gắng trang bị cho chúng khả năng dự đoán trước. Với khả năng này ta có thể tạo ra một bản k ế hoạch tại thời điểm đầu của dự án và xác định được thời gian hoàn thành dự án d ựa theo bản kế hoạch này. Và vấn đề cố hữu trong quá trình thực hiện dự án v ẫn là “sự thay đổi yêu cầu của người dùng”. Thông thường khách hàng không thay đổi yêu cầu của họ bởi vì họ biết rằng chi phí để thay đổi rất đắt. Tuy nhiên ph ần mềm không phải là thứ hữu hình. Khách hàng không chỉ khó đ ể xác định một cách chính xác cái gì là cần thiết mà cũng khó để hiểu tại sao việc thay đổi lại khó khăn như vậy. Họ mong đợi một phần mềm phải có tính m ềm dẻo. Những phương pháp truyền thống đã đưa ra những thủ tục nhằm ngăn ch ặn sự thay đổi yêu cầu từ phía khách hàng. Điều này giúp duy trì bản k ế hoạch dự án đã xây dựng ban đầu nhưng lại không đảm bảo rằng kết quả cuối cùng là những gì mà khách hàng mong muốn. Khả năng dự đoán trước có th ể là điều ước ao nhưng ta chỉ có thể đạt được điều đó với giá phải trả là sự gi ảm sút chất lượng phần mềm không thỏa mãn được đòi hỏi của khách hàng. V ới những hạn chế như vậy của những phương pháp phát triển phần mềm truyền thống, ta thắc mắc rằng tại sao chúng lại được sử dụng và nếu chúng đã đ ược sử dụng trong quá khứ thì lại từ bỏ chúng bây giờ? Phải chăng một vài th ứ đã thay đổi. Trong suốt thập niên 80 những thay đổi cơ bản đã xảy ra và kết quả là hình thành nên “thế giới nhanh” – thế giới của sự toàn cầu hóa và “th ế giới chậm” của những ai tự tách mình ra khỏi quá trình toàn cầu hóa. Sự phát triển phần mềm diễn ra trong thế giới nhanh và sự thay đổi diễn ra đồng th ời ở công nghệ, tài chính, thông tin và đi kèm với chúng là sự dỡ bỏ những hàng rào chính tr ị được duy trì suốt thời kỳ chiến tranh lạnh. Mọi việc diễn ra nhanh h ơn. Những đối thủ xuất hiện, sự thành công hay thất bại chỉ là ranh giới mong manh. Vòng đời của sản phẩm ngắn hơn và người dùng thì hay thay đổi. Không có gì là ng ạc nhiên khi những phương pháp phù hợp với thập niên 70 l ại thất bại trong thập niên 80 và 90. b. S ự nổi lên của phương pháp linh hoạt Trong th ập kỉ 90 nhiều người đã nhận ra mọi thứ đã thay đổi bằng cách này hay cách khác. Nh ững người này đã quan tâm tới phương pháp phát triển phần m ềm linh hoạt hơn, phù hợp hơn với môi trường làm việc luôn luôn vận động. Mặc dù chi tiết những phương pháp này là khác nhau nhưng chúng đều có chung m ột số nguyên tắc và trong một phạm vi nào đó những phương pháp này th ường được nhóm lại với nhau dưới tên gọi “những phương pháp linh hoạt – agile methodologies”. 2. Ph ương pháp linh hoạt Ph ương pháp phát triển phần mềm linh hoạt được đưa ra vào giữa những năm 90 nh ư là một phần của sự nỗ lực chống lại những phương pháp “nặng nề” – điển hình bởi những quy định khắt khe. Ban đầu chúng được gọi là “phương pháp nhẹ”. Đ ến năm 2001, 17 thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt đã g ặp gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần mềm linh hoạt hơn, nhanh hơn và hướng con người hơn. Họ đã thông qua tên gọi chính thức “ph ương pháp linh hoạt”. Và cũng trong hội nghị này, Agile Manifesto – tuyên ngôn v ề phương pháp linh hoạt được đưa ra và được công nhận rộng rãi như là m ột định nghĩa chuẩn của phương pháp phát triển linh hoạt kèm theo những nguyên tắc cơ bản. Bản tuyên ngôn hướng tới những giá trị: - S ự độc lập và sự tương tác dựa trên các quy trình và công cụ : sự vận động linh ho ạt nhấn mạnh mối quan hệ và cộng đồng các nhà phát triển phần mềm và vai trò c ủa con người được phản ánh trong hợp đồng, trái với những quy trình đã được thể chế hóa và những công cụ phát triển. Trong thực tiễn nó tự thể hiện thông qua nh ững mối quan hệ chặt chẽ trong nhóm, việc tạo ra môi trường làm vi ệc gần gũi, và những thủ tục khác để nâng cao tinh thần của nhóm. - Vận hành phần mềm dựa trên tài liệu hướng dẫn toàn diện : các mục tiêu quan tr ọng của nhóm phát triển phần mềm là liên tiếp đưa ra những phần mềm đã được kiểm thử. Những phiên bản mới thường được đưa ra hàng tháng thậm chí ở m ột vài phương pháp là hằng giờ hoặc hàng ngày. Những nhà phát triển luôn cố g ắng giữ cho mã nguồn đơn giản, rõ ràng nhất có thể, bởi vậy gánh nặng về tài li ệu hướng dẫn được giảm bớt. - Sự cộng tác với khách hàng dựa trên thương thảo hợp đồng : mối quan hệ và s ự hợp tác giữa những nhà phát triển và khách hàng được định rõ thông qua nh ững bản hợp đồng chặt chẽ. Những dự án càng lớn thì càng cần một bản dự thảo hợp đồng chặt chẽ. Quá trình thương lượng nên được đánh giá như là ph ương tiện để đạt được và duy trì mối quan hệ. Nhìn từ quan điểm kinh doanh, ph ương pháp phát triển linh hoạt tập trung vào việc nhanh chóng đưa ra được nh ững sản phẩm có thể đáp ứng những yêu cầu cơ bản của khách hàng ngay sau khi dự án được tiến hành; do đó làm giảm nguy cơ vỡ hợp đồng. - Đáp ứng với thay đổi dựa trên một kế hoạch theo sau : nhóm phát triển gồm c ả những nhà phát triển phần mềm và đại diện khách hàng nên được cung cấp thông tin đầy đủ, họ có đủ thẩm quyền và đươc ủy thác để xem xét những sự điều ch ỉnh cần thiết trong suốt vòng đời của quy trình phát triển phần mềm. Như vậy nh ững người tham gia được chuẩn bị để đối mặt với những thay đổi và có thể đưa ra đ ược bản hợp đồng hỗ trợ và cho phép sự thay đổi. M ột số nguyên tắc đi kèm sau tuyên ngôn có thể kể đến như: - Ph ần mềm chạy ổn định được bàn giao thường xuyên (hàng tuần hoặc hàng tháng) - Nh ững thay đổi yêu cầu dù muộn luôn được hoan nghênh - S ự hợp tác gắn bó khăng khít giữa nhà kinh doanh và những nhà phát tri ển phần mềm - Đối thoại trực tiếp là hình thức giao tiếp tốt nhất - D ự án được tiến hành bởi những cá nhân nhiệt tình, tận tụy, đáng tin cậy - Luôn luôn chú tr ọng tới kỹ thuật và thiết kế - S ự đơn giản - Các nhóm tự tổ chức - S ự thích nghi với những những thay đổi 3. So sánh v ới các phương pháp khác Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiểu tính kỉ luật. Nh ững nhận xét như vậy gây ra sự hiểu lầm. Để hiểu vấn đề một cách đúng đắn, ta có thể hình dung rằng những phương pháp phát triển phần mềm hiện có nằm trên m ột trục đi từ “khả năng thích ứng” tới “khả năng dự đoán trước” thì phương pháp phát tri ển linh hoạt nằm về phía “khả năng thích ứng”. Nh ững phương pháp nằm về phía “khả năng thích ứng” có thể thích nghi nhanh chóng với những thay đổi của thực tế. Khi mà những yêu cầu của dự án thay đ ổi, nhóm thực hiện cần phải có những điều chỉnh thích hợp. Họ sẽ gặp khó khăn đ ể mô tả chính xác những gì sẽ xảy ra trong tương lai. Tương lai càng xa thì sự khó khăn đó càng lớn. Nhóm thực hiện có thể báo cáo chính xác công việc sẽ đ ược tiến hành trong tuần tới nhưng chỉ có thể báo cáo những tính năng nào sẽ đ ược xây dựng trong tháng tới. Và khi được hỏi về phiên bản phần mềm trong 6 tháng ti ếp theo thì họ chỉ có thể đưa ra được những tính năng chung nhất hoặc đưa ra kinh phí dự kiến. Trong khi đó nh ững phương pháp nằm về phía “khả năng dự báo trước” trong h ợp đồng với khách hàng, tập trung vào xây dựng một kế hoạch chi tiết cho tương lai. Nhóm thực hiện dự án có thể báo cáo chính xác những tính năng và công việc c ần thực hiện trong toàn bộ quy trình phát triển phần mềm. Bản kế hoạch được tối ưu hoá cho những mục tiêu đã đặt ra lúc đầu và sự thay đổi có thể khiến cho công vi ệc đã hoàn thành trở nên vô nghĩa. Nhóm phát triển dự án sẽ xây dựng một bảng kiểm soát những thay đổi để đảm bảo rằng chỉ những thay đổi có giá trị mới được xem xét đ ến. a. Phân bi ệt với mô hình thác nước Ph ương pháp phát triển linh hoạt có vài điểm chung nhỏ với mô hình thác n ước. Hiện nay mô hình thác nước vẫn được sử dụng phổ biến. Nó được lên kế ho ạch trước và được tiến hành lần lượt qua các bước nắm bắt yêu cầu, phân tích, thi ết kế, viết code và kiểm thử một cách nghiêm ngặt. Vấn đề của mô hình thác nước là sự phân chia cứng nhắc dự án thành các giai đoạn riêng biệt và do đó r ất khó khăn khi muốn thay đổi yêu cầu. Chi phí để thực hiện lại rất đắt. Đi ều đó có nghĩa là mô hình thác nước không thích hợp khi mà không thể xác đ ịnh chính xác, rõ ràng yêu cầu của khách hàng hoặc những yêu cầu có thể thay đổi trong quá trình tiến hành dự án. Phương pháp phát triển linh hoạt, trong h ợp đồng, sẽ nhanh chóng đưa ra sản phẩm hoạt động ổn định với những tính năng c ơ bản giúp khách hàng sớm được sử dụng sản phẩm phục vụ mục đích của họ. Sau đó nhóm phát triển tiếp tục nâng cấp sản phầm trong suốt thời gian ti ến hành dự án, hàng tuần hoặc tháng sẽ bổ sung những tính năng được được phát triển và kiểm thử toàn diện. Theo khía c ạnh này, những người chỉ trích phương pháp linh hoạt có thể qu ả quyết rằng những tính năng này không được xem xét trong quy mô toàn dự án. N ếu người tài trợ dự án lo ngại về thời gian hoàn thành toàn bộ dự án đã được định trước hay ngân sách đầu tư cho dự án thì phương pháp linh hoạt có th ể không thích hợp. Tuy nhiên lời chỉ trích này gặp phải sự phản đối của cộng đ ồng phát triển phần mềm linh hoạt. Họ cho rằng với SCUM (một phương pháp phát triển linh hoạt sẽ được tìm hiểu kĩ hơn ở phần sau), nhóm phát triển có th ể đấy nhanh tiến độ thực hiện và liên tục cải thiện kế hoạch chiến lược. Vài nhóm phát tri ển phần mềm linh hoạt sử dụng mô hình thác nước với quy mô nh ỏ trong các giai đoạn của dự án. b. Phân bi ệt với “Cowboy coding” Khi nh ững thành viên trong nhóm làm bất cứ điều gì họ cho là đúng, không tuân th ủ kỷ luật, nguyên tắc thì người ta gọi đó là “Cowboy coding”. Sự thường xuyên đánh giá lại các kế hoạch của phương pháp phát triển linh hoạt, s ự chú trọng vào giao tiếp mặt đối mặt trực tiếp và vấn đề tài liệu hướng dẫn đi kèm khá ít đôi khi khi ến cho người dùng lầm tưởng nó với “cowboy coding”. Tuy nhiên th ực tế là nhóm phát triển phần mềm linh hoạt luôn làm việc theo một quy trình đã được vạch rõ ( và thường rất kỷ luật và nghiêm ngặt). Gi ống như tất cả các phương pháp phát triển phần mềm, kỹ năng và kinh nghi ệm của người sử dụng quyết định để mức độ thành công hoặc thất bại của sản phẩm. Càng có nhiều hệ thống kiểm soát khắt khe được nhúng vào trong quy trình phát tri ển thì trách nhiệm của người sử dụng càng được nâng cao. II. Các ph ương pháp phát triển phần mềm linh hoạt Các ph ương pháp phát triển phần mềm linh hoạt hiện nay bao gồm: Extreme programming (XP), Scrum, Crystal family of methodologies, Feature Driven Development (FDD), The Rational Unified Process, Dynamic Systems Development Menthod (DSDM), Adaptive Software Development, Open Sourse Software Development, ngoài ra còn có các ph ương pháp khác. 1. Lập trình cực hạn - Extreme programming (XP) XP là m ột phương pháp xây dựng phần mềm mới, dựa trên lý thuyết phương pháp phát triển phần mềm linh hoạt được phát triển bởi Kent Beck, Ward Cunningham, and Ron Jeffries, nó nh ấn mạnh vào sự cộng tác, tạo ra phần mềm m ột cách nhanh chóng, và phát triển mở rộng một cách khéo léo trong quá trình th ực hành. Nó được cô đọng lại trong bốn giá trị: sự giao tiếp (communication), đơn giản hóa (simplicity), sự phản hồi (feedback), và thế mạnh (courage). N ếu bạn làm việc trong một môi trường mà ở đó các nhu cầu được chờ để thay đ ổi và các khách hàng sẽ được lợi từ việc bàn giao phần mềm sớm và thường xuyên thì chắc chắn nên xem xét XP . Các nhóm làm theo XP sẽ thường xuyên nh ận ra rằng họ đang bàn giao các sản phẩm phần mềm chất lượng cao v ới số lượng rất lớn và nhanh hơn trước đây rất nhiều. [http://vi.wikipedia.org/wiki/Lập_trình_cực_hạn] XP bao gồm một tập hợp các luật giá trị và thực hành giúp người lập trình mô t ả chi tiết các hành vi. Vòng đời của XP gồm có các pha: Khảo sát (Exploration), L ập kế hoạch (Planning), Các bước lặp để phát hành (Iteration to Release), Sản xuất (Productionizing), Bảo trì và kết thúc (Maintenance and Death). Theo mô tả của Beck’s (1999b) thì pha ban đầu là pha “Khám phá”. Trong pha này khách hàng vi ết ra các yêu cầu về sản phẩm vào các “story card”. Mỗi “story card” sẽ mô tả một đặc trưng sẽ được thêm vào trong chương trình. Trong khi đó nhóm phát tri ển sẽ giới thiệu những công cụ, công nghệ, những thực thi mà h ọ sẽ sử dụng trong dự án đó. Công nghệ sử dụng cần được kiểm tra và kiến trúc có th ể được phân tích bằng cách xây dựng một nguyên mẫu. Pha này có thể kéo dài vài tuần đến vài tháng tùy thuộc vào từng dự án và nhóm phát triển. Ở pha thứ hai đó là pha “Lập kế hoạch” là tập hợp các thứ tự ưu tiên cho nh ững yêu cầu và thống nhất nội dung cho phiên bản phần mềm đầu tiên. Người lập trình đầu tiên phải ước lượng khả năng đáp ứng các yêu cầu này và lập thời gian bi ểu cho việc thực hiện. Khoảng thời gian để đưa ra bản phát hành đầu tiên th ường không vượt quá 2 tháng. Pha “L ặp để phát hành” bao gồm một số bước lặp trong hệ thống để tạo ra bản phát hành đầu tiên. Thời hạn đã đặt ra trong bước lập kế hoạch có thể bị sụp đ ổ nếu như thời gian để thực thi các bước lặp từ một đến bốn tuần. Bước lặp đầu tiên t ạo ra một hệ thống bao gồm kiến trúc của cả một hệ thống. Điều đó đạt được bằng cách thực thi những yêu cầu có tác động mạnh mẽ đến việc xây dựng c ấu trúc của cả hệ thống. Khách hàng sẽ quyết định yêu cầu nào được chọn qua m ỗi bước lặp. Các hàm kiểm tra được tạo bởi khách hàng sẽ chạy khi mỗi bước l ặp kết thúc. Đến khi kết thúc bước lặp cuối cùng thì sản phẩm đã được hoàn thành. Pha “S ản xuất” sẽ có các kiểm tra thêm đối với hoạt động của hệ thống trước khi t ạo ra một hệ thống hoàn chỉnh giao cho khách hàng. Trong pha này, những thay đổi mới vẫn có thể được phát hiện và sự quyết đinh sẽ được đưa ra nếu chúng n ằm trong bản phát hành hiện tại. Trong suốt pha này, các bước lặp cần đ ược đẩy nhanh hơn giảm từ ba tuần xuống còn khoảng một tuần. Các ý kiến và yêu c ầu bổ xung sẽ được ghi nhận lại và thực hiện ở pha tiếp theo. Trong khi phiên bản đầu tiên đang được khách hàng sử dụng thì nhóm phát tri ển vẫn phải đồng thời vừa giữ cho hệ thống làm việc liên tục vừa duy trì nh ững bước lặp mới để tạo ra các phiên bản kế tiếp. Để làm được việc này, pha “Phân tích” đòi h ỏi những cố gắng để chăm sóc khách hàng. Vì vậy tốc độ có thể bị chậm lại sau khi sản phẩm đã hoàn thành. Trong pha này có thể yêu cầu kết h ợp một số người mới làm thay đổi cấu trúc của nhóm lập trình. Pha “Chết” bắt đầu khi khách hàng không còn yêu cầu nào nữa để thi hành. Lúc này khách hàng đã th ỏa mãn với những chức năng mà phần mềm đem lại. Đây là lúc thích hợp để viết tài liệu cần thiết về hệ thống, lúc hệ thống đã ổn đ ịnh, không có sự thay đổi trong kiến trúc, thiết kế hay lập trình. “Chết” cũng có th ể xảy ra nếu như hệ thống không đạt được kết quả mong đợi hoặc nó quá đắt đ ể phát triển tiếp. Đối với người lập trình phải viết chương trình và kiểm thử một cách càng đ ơn giản và càng rõ ràng càng tốt. Điều đầu tiên tạo nên thành công của phương pháp phát tri ển phần mềm XP là sự giao tiếp và hợp tác giữa các lập trình viên khác và các thành viên trong nhóm. Khách hàng vi ết ra yêu cầu và các hàm kiểm tra và quyết định khi nào các yêu c ầu được thỏa mãn. Khách hàng tập hợp các thực thi ưu tiên cho các yêu c ầu. Kiểm định viên sẽ giúp khách hàng viết hàm kiểm tra. Họ chạy hàm kiểm tra m ột cách thường xuyên, thông báo rộng rãi kết quả kiểm tra và duy trì công cụ ki ểm tra. Người theo dõi sẽ đưa ra các phản hồi trong XP. Họ xác định các ước lượng đ ược tạo bởi nhóm lập trình và đưa ra phản hồi trong việc làm thế nào nhóm lập trình có th ể tuần tự cải thiện các ước lượng trong tương lai một cách chính xác. Ng ười này cũng theo sát sự tiến triển của mỗi vòng lặp để ước lượng xem có hay không việc đạt tới kết quả trong phạm vi nguồn lực cho phép và thời gian ràng bu ộc hoặc có gi thay đổi cần thiết trong quá trình xử lý. Hu ấn luyện viên là người chịu trách nhiệm cho toàn bộ quá trình phát triển phần mềm. Việc hiểu rõ XP có vai trò quan trọng cho phép huấn luyện viên có th ể hướng dẫn cho những thành viên trong nhóm tuân theo. Chuyên gia là nh ững người có kiến thức chuyên biệt về vấn đề nào đó, họ có nhi ệm vụ hướng dẫn nhóm lập trình giải quyết các vấn đề chuyên biệt của họ. Người quản lý là người đưa ra những quyết định. Để làm được việc đó anh ta ph ải giao tiếp với nhóm lập trình để quyết định những tình huống tức thời, và để nh ận định những khó khăn hoặc thiếu hụt trong quá trình thực hiện. XP bao g ồm một tập các ý tưởng và thực thi dựa trên những phương pháp luận đã có (Beck 1999a). Chính sự quyết định đã tạo nên cấu trúc. Trong khi khách hàng đ ưa ra những quyết định mang tính thương mại thì những người lập trình l ựa chọn công nghệ, đó chính là ý tưởng của Alexander (1979). Loại hình phát triển nhanh XP có nguồn gốc từ những ý tưởng hình thành sau Scrum (Takeuchi and Nonaka 1986) và ngôn ng ữ mô hình của Cunningham (1986). Việc lập dự án sử dụng XP dựa trên những yêu cầu từ phía khách hàng được vẽ ra t ừ những tình huống sử dụng (Jacobsen 1994) và phương pháp phát triển phân ph ối sinh ra bởi Gilb (1988). Cũng như mô hình xoắn ốc, sự phản hồi ban đầu là mô hình thác n ước cả hai đều có ảnh hưởng lên phương pháp XP. Phép ẩn dụ của XP khởi đầu từ nghiên cứu của Lakoff, Johnson (1998) và Coyne (1995). Cu ối cùng thì môi trường làm việc vật lý đã được Coplien (1998), DeMarco và Lister (1999) tìm ra. Mục tiêu mà XP nhắm đến là việc phát triển phần mềm thành công cho dù có s ự mập mờ và yêu cầu liên tục bị thay đổi trong một nhóm lập trình. Những bước lặp ngắn với phiên bản phát hành nhỏ và tốc độ phản hồi nhanh, sự tham gia c ủa khách hàng, sự trao đổi và hợp tác, những bước lặp liên tục và kiểm đ ịnh, chung quyền sở hữu phần lập trình, những tài liệu hạn chế và phương pháp lập trình theo cặp là những đặc trưng chính của phương pháp XP. Th ực thi của XP được biểu diễn theo cấu trúc của Beck (1999ª). Đó là các b ước Lập kế hoạch  Bản phân phối nhỏ và ngắn  Phép ẩn dụ  Thiết kế đ ơn  Tái tạo  Lập trình theo cặp  Quyền sở hữu tập thể  Bước lặp liên tục  40 giờ mọt tuần  Khách hàng có mặt  Chuẩn lập trình  Không gian làm vi ệc mở  Quy tắc, luật lệ. Beck cho r ằng phương pháp XP sẽ dần dần được chấp nhận: “Nếu bạn muốn thử XP, cho những mục đích tốt đẹp thì đừng cố nuốt tất cả m ột lúc. Chọn ra vấn đề tồi tệ nhất trong xử lý hiện thời của bạn và cố xử lý nó v ới phương pháp XP.” [...]... hai phương pháp thư ng dùng là phương pháp so sánh chính th ng và phương pháp so sánh g n chính th ng (Song and Osterweil 1992) Phương pháp so sánh g n chính th ng c g ng kh c ph c nh ng h n ch ch quan c a kĩ thu t so sánh chính th ng, theo Sol (1983), phương pháp so sánh không chính th ng có th ti p c n theo 5 cách khác nhau : 1 Mô t m t phương pháp và đánh giá các phương pháp đ i l p v i phương pháp. .. vài phương pháp hay qua vi c so sánh m i phương pháp v i nhau 3 Xây d ng nh ng gi thi t v các yêu c u c a phương pháp và đưa ra m t khuôn m u t nh ng b ng ch ng th c t trong m t vài phương pháp 4 Đ nh nghĩa m t siêu ngôn ng như là m t công c giao ti p và như là m t khung chu n chung đ mô t nhi u phương pháp khác 5 Dùng phương pháp ti p c n ng u nhiên và th liên k t các đ c đi m c a m i phương pháp. .. sau s cho ta th y nh ng bư c phát tri n ph n m m đư c h tr b i các phương pháp linh ho t khác M i phương pháp l i đư c chia thành 3 ph n, ph n đ u bi u di n phương pháp có đưa ra nh ng h tr cho vi c qu n lí d án hay không., ph n ti p theo xác đ nh xem 1 ti n trình, cái mà đư c phương pháp khuyên dùng có đư c mô t b i phương pháp đó hay không, ph n cu i cùng ch ra là phương pháp có mô t các ho t đ ng... phát tri n hơn là phương pháp Tuy nhiên, có khá nhi u nh ng d án thành công theo phương pháp này, m t đ c đi m đ c bi t c a OSS chính là v n đ b n quy n trong th c hi n, c th đây là ph i đ m b o r ng mã ngư n ph i luôn m v i các nhóm và có th đ c, s a ch a, biên d ch mã ngu n Cu i cùng là RUP, RUP không đư c cho là m t phương pháp đ c bi t, nó khác v i nh ng phương pháp kia ch nó là 1 phương pháp phát. .. t có giá tr H các phương pháp Crystal ch là m t nguyên t c thi t k phương pháp đ có th đáp ng thay đ i theo quy mô và gi i h n c a d án Đây là khía c nh khá quan tr ng k t khi quy mô c a phương pháp tr thành m t trong nh ng đ tài chính mà c ng đ ng phát tri n linh ho t c n đ c p đ n DSDM khác v i các phương pháp khác vi c s d ng ch th DSDM cũng đ t ra m t s vai trò mà các phương pháp khác không nh... (nascent) Mô t sinh” Phương pháp m i đư c đưa ra m năm, chưa có nh ng nghiên c u c và chưa có báo cáo th c nghi m “Đang xây d ng” Phương pháp và nh ng cách ti p c (building up) đư c công b r ng rãi,báo cáo Phương pháp t vài AM th , n đã FDD ,Crystal th c ,Scrum, PP, ASD “ho t (active) nghi m đã đư c đưa ra,có c ng đ ng phát tri n năng đ ng,đã có nh ng nghiên c u v phương pháp đ ng” Phương pháp đã đư c áp... th nh ng v n đ ho c nh ng khía c nh chính c a phương pháp, còn nh ng đi m đ c bi t thì dùng đ mô t m t ho c vài khía c nh c a phương pháp mà khác v i nh ng phương pháp khác DSDM và Scrum l n lư t đư c gi i thi u vào nh ng năm đ u và gi a c a th p niên 90 Tuy nhiên, t khi đư c coi là 1 phương pháp thì Scrum v n đang trong quá trình xây d ng, các phương pháp khác đã đư c công b r ng rãi là FDD, Crystal,... d án, v n đ c t lõi trong vi c hi u phương pháp h tr th nào trong chi n lư c qu n lí Vi c kinh doanh các s n ph m ph n m m ch thu đư c l i nhu n khi chúng đư c s d ng, tương t nhhư v y, l i nhu n liên quan đ n các phương pháp phát tri n ph n m m linh ho t cũng ch đ t đư c khi nh ng phương pháp này đư c s d ng trong s n xu t s n ph m Vi c th c hi n theo 1 phương pháp m i nên đơn gi n khi mà t ch c không... còn các phương pháp không n m trong nh ng nhóm trên thì tr ng thái “l i tàn”, th m chí, ví d như khi s d ng kĩ thu t DSDM, như là ch th thì cũng b coi là l i th i…Tr ng thái c a các phương pháp phát tri n ph n m m linh ho t đư c tóm t t trong b ng sau: Song and Osterweil cho r ng cách ti p c n th 2 và th 4 thì g n gũi v i phương pháp khoa h c c đi n thư ng đư c dùng cho m c đích so sánh phương pháp ... suy nghĩ linh ho t cũng đư c áp d ng đ thi t k m u ASD thiên v khái ni m và văn hóa hơn là th c hành ph n m m Thi t k phương pháp theo nguyên t c Có th ch n phương pháp thích h p nhât d a vào quy mô và gi i h n c a d án Đây là m t nguyên lí b sung r t t t cho vi c mô hình hóa chuyên nghi p, tuy nhiên nó ch áp d ng đư c v i nh ng phương pháp khác Quá s m đ cho r ng ch có 2 trong s 4 phương pháp đư c . những phương pháp này th ường được nhóm lại với nhau dưới tên gọi “những phương pháp linh hoạt – agile methodologies”. 2. Ph ương pháp linh hoạt Ph ương pháp phát triển phần mềm linh hoạt. trong quy trình phát tri ển thì trách nhiệm của người sử dụng càng được nâng cao. II. Các ph ương pháp phát triển phần mềm linh hoạt Các ph ương pháp phát triển phần mềm linh hoạt hiện nay. ph ương pháp khác. 1. Lập trình cực hạn - Extreme programming (XP) XP là m ột phương pháp xây dựng phần mềm mới, dựa trên lý thuyết phương pháp phát triển phần mềm linh hoạt được phát triển