Phương pháp phát triển phần mềm linh hoạt potx

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

Phương pháp phát triển phần mềm linh hoạt

Agile Software Development

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ư:

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

Một trong những ý tưởng nền tảng của XP là không có xử lý nào phù hợp với mọi dự án tuy nhiên vẫn có những hành vi có thể được cân đối lại cho phù hợp với những yêu cầu của các dự án cá nhân riêng lẻ

Trong thực tế không có một báo cáo kinh nghiệm nào về tất cả các thực thi của XP được thực hiện Mặc dù vậy vẫn có một bộ phận các thực thi của XP được Beck báo cáo (Grenning 2001, Schuh 2001) XP là một phương pháp được tài liệu hóa nhiều nhất trong lập trình linh hoạt và đang được tiếp tục nghiên cứu

và có nhiều bài báo và kinh nghiệm về các nhánh khác nhau trong XP

Như phát biểu của Beck (1999b), phương pháp XP không có nghĩa là tương thích mọi nơi, và những giới hạn của nó vẫn chưa được đồng nhất Điều đó đòi hỏi những kinh nghiệm và những nghiên cứu đã được thí nghiệm kiểm chứng về những triển vọng khác nhau Tuy nhiên trong số đó có vài thứ đã được đồng nhất

XP được dùng cho các nhóm phát triển nhỏ và vừa Beck (1999b) cho rằng một nhóm nên có từ 3 đến tối đa là 20 thành viên Môi trường vật lý cũng hết sức quan trọng trong XP Sự trao đổi và cộng tác giữa các thành viên phải được thường xuyên Văn hóa kinh doanh tác động đến một đơn vị phát triển là một vấn đề trọng tâm của XP Bất kỳ một sự chống đối các thực thi hoặc nguyên tắc của XP của bất kỳ thành viên, quản lý, khách hàng cũng có thể đủ làm thất bại

dự án Tất nhiên công nghệ có thể cũng không thể vượt qua những trở ngại để đem lại thành công cho XP

Những nghiên cứu vẫn đang được triển khai Có nhiều tài liệu đã được xuất bản nó về nhiều diện mạo khác nhau của XP, tuy nhiên chắc chắn là nó sẽ được nhìn nhận là một phương pháp thực tế hơn là một phương pháp hàn lâm, hầu hết các trang tâm điểm về kinh nghiệm sử dụng XP trong những phạm vi khác nhau,

và những kinh nghiệm tìm kiếm trên những thực thi của nó

2 Scrum

Thuật ngữ “Scrum” được trình bày lần đầu tiên trong bài báo của Takeuchi

và Nonaka (1986) về khả năng thích nghi, nhanh chóng, tính tự tổ chức trong việc phát triển phần mềm Thuật ngữ “Scrum” có nguồn gốc từ một chiến thuật trong môn bóng bầu dục ám chỉ việc đưa bóng vào cuộc

Scrum gần như được phát triển cho việc xử lý phát triển hệ thống Đó gần như dựa trên kinh nghiệm trong việc áp dụng những ý tưởng lý thuyết điều khiển

xử lý trong công nghiệp để phát triển hệ thống và đưa đến kết quả là việc giới

thiệu lại ý tưởng về tính mềm dẻo, tính thích nghi, và tính năng suất Nó không định nghĩa cho bất kỳ một công nghệ phát triển phần mềm nào trong pha thực thi Scrum tập trung vào việc làm thế nào để các thành viên trong nhóm tạo nên được một hệ thống mềm dẻo trong một môi trường luôn luôn thay đổi

Ý tưởng chính của Scrum là phát triển hệ thống bao gồm vài môi trường và công nghệ có thể thay đổi (ví dụ như: yêu cầu, thời gian, nguồn lực công nghệ…) phù hợp với sự thay đổi của hệ thống trong suốt quá trình xử lý Điều này khiến cho việc phát triển là không thể dự đoán trước được và rất phức tạp, đòi hỏi hệ thống phải hết sức mềm dẻo để đáp ứng được những thay đổi Và kết quả là sản phẩm sẽ rất hữu ích khi đến tay khách hàng

Scrum giúp đẩy mạnh những kỹ thuật thực thi sẵn có trong một tổ chức, nó bao gồm những hoạt động quản lý thường xuyên nhắm đến việc nhận ra bất kỳ thiếu hụt nào hoặc những trở ngại trong quá trình phát triển phần mềm

Thực thi Scrum bao gồm 3 pha là các pha: pre-game, development, game

post-Pha pre-game bao gồm hai pha con là : Lập kế hoạch và kiến trúc (hay thiết kế bậc cao hơn)

Lập kế hoạch bao gồm định nghĩa về hệ thống sắp được phát triển Một bản liệt kê các công việc chưa làm được được tạo chứ đựng những yêu cầu của khách hàng trong thời điểm hiện tại Các yêu cầu này có thể bắt nguồn từ khách hàng, người buôn bán, người phân phối tiếp thị, người cung cấp hay từ chính người phát triển phần mềm Các yêu cầu được ưu tiên và các khó khăn khi thực thi phải được ước lượng trước Sản phẩm chưa hoàn chỉnh phải được cập nhật những cái mới, những yếu tố cụ thể hơn, để tạo ra được những đánh giá chính xác Việc lập

kế hoạch cũng bao gồm việc lập đội phát triển, chọn các công cụ và những tài nguyên khác, đánh giá rủi ro, kiểm soát vấn đề, đào tạo và phê chuẩn Ở mỗi bước lặp các sản phẩm cập nhật cần được đội phát triển đánh giá xem dự án tiến triển được đến đâu để lập kế hoạch cho các bước lặp tiếp theo

Pha kiến trúc bao gồm các kiến trúc đã được lập kế hoạch sẵn trong mỗi sản phẩm ở mỗi bước lặp Trong trường hợp nâng cao một hệ thồng có sẵn, những

sự thay đổi cần thiết cho bước thực thi Backlog và xác định rõ những vấn đề mà bạn có thể gặp phải Một cuộc họp để nhìn lại thiết kế của một hệ thống được tổ chức để thông qua đề xuất cho việc thực thi và những quyết định sẽ được đưa ra trong buổi họp này Thêm vào đó, kế hoạch mở đầu cho một phiên bản phát hành cũng được chuẩn bị

3 Crystal family of methodologies

Đây là phương pháp bao gồm một lượng các phương thức khác nhau cho việc chọn lựa một phương pháp tối ưu nhất cho một dự án cụ thể Bên cạnh những phương thức, cách tiếp cận Crystal bao gồm những nguyên tắc đan xen các phương thức phù hợp với những thay đổi liên tục của các dự án khác nhau Mỗi thành viên trong gia đình Crystal được đánh dấu bằng những màu sắc khác nhau tùy thuộc vào “sức nặng” của nó Sức nặng càng lớn thì màu càng đậm Đối với những dự án lớn yêu cầu nhiều sự hợp tác và nhiều phương pháp

“mạnh mẽ” hơn những dự án nhỏ Càng được phê bình nhiều thì sản phẩm làm

ra càng hoàn thiện Lược đồ dưới đây sẽ cho biết khả năng tiềm tàng của thất bại khi hệ thống bị lỗi Trong đó Sự thoải mái (C), tiền tự do làm theo ý mình (D) , tiền cần thiết (E), vòng đời (L)

Có những quy tắc, đặc điểm và giá trị thông thường được đặt ra cho những phương thức trong gia đình Crystal Đầu tiên dự án phải sử dụng chu kỳ phát triển phần mềm tăng dần, và đạt mức tăng lớn nhất trong vòng mỗi 4 tháng, tốt nhất là trong vòng từ 1 đến 3 tháng Điều cực kỳ quan trọng là sự hợp tác và giao tiếp giữa các thành viên trong nhóm Phương pháp Crystal không giới hạn số lượng phương pháp thực thi, số lượng công cụ, số lượng các sản phẩm, và đặc biệt cho phép các thực thi của các phương thức khác nhiuw Scrum hay XP Hơn nữa, cách tiếp cận này còn cho phép giảm bớt các sản phẩm trung gian và thể hiện cụ thể trong phạm vi một quy ước cho các dự án riêng lẻ và phát triển chúng như là các dự án mở

Hiện nay có 3 phương thức chính trong Crystal đó là: Crystal Clear, Crystal Orange, Crystal Orange Web

Tất cả các phương thức trong gia đình Crystal đều dựa trên những chuẩn hợp đồng đã ký, sản phẩm, chi phí, công cụ, và các quy tắc chuẩn để thực thi trong suốt quá trình sản xuất Crystal Clear và Crystal Orange là hai trong số các thành viên của gia đình Crystal đã được xây dựng và sử dụng (Cockburn 1998, Cockburn 2002a) Crystal Orange (Cockburn 1998) cũng biểu diễn các hoạt động trong một quá trình

Crystal Clear được thiết kế cho những dự án rất nhỏ được phát triển bởi khoảng 6 thành viên Tuy nhiên với cá phần mở rộng của nó có thể phù hợp với một dự án có từ 8-10 thành viên Một đội sử dụng phương thức Crystal nên làm việc cùng nhau trong một phòng để tiện việc trao đổi, bàn bạc

Crystal Orange được thiết kế cho một dự án cỡ vừa, có từ 10 đến 40 thành viên và với thời gian thực hiện dự án là 1 đến 2 năm Dĩ nhiên một dự án có 50 thành viên vẫn có thể sử dụng phương thức này nhưng với điều kiện phải thêm vào cho nó phương thức kiểm chứng Một dự án sử dụng Crystal Orange có thể được chia nhỏ cho nhiều nhóm phát triển với cross-functional sử dụng chiến lược Holistic Deliversity Tuy nhiên phương thức này không dành cho bản phát triển môi trường Crystal Orange nhấn mạnh tầm quan trọng của time-to-market

Sự hoán đổi giữa phân phối rộng rãi và sự thay đổi nhanh trong yêu cầu và thiết

kế kết quả trong một số giới hạn các phiên bản cho phép giảm bớt giá thành để bảo trì chúng nhưng vẫn giữ cho chức năng giao tiếp giữa các đội phát triển được hiệu quả

Policy standards:

Đây là những thực thi cần được áp dụng trong suốt quá trình phát triển phần mềm Cả Crystal Clear và Crystal Orange đều đưa ra các tiêu chuẩn chính sách sau:

1 Mở rộng các bản phân phối một cách đều đặn

2 Quy trình theo dõi những thành phần quan trọng được đưa vào các phiên bản, chú ý vào những quyết định hơn là viết tài liệu

3 Hướng sự chú ý của người dùng

4 Nghiên cứu chức năng tự động hóa kiểm chứng

5 Coi như có 2 người sử dụng đang quan sát bạn làm việc

6 Hội thảo về sản phẩm và những điều chỉnh phương thức thực thi ở đầu vào ở giữa mỗi bước lặp

Chỉ có sự khác biệt duy nhất trong chính sách của 2 phương thức này là Crystal Clear cho rằng nên tăng phiên bản khoảng 2 đến 3 tháng một lần, trong khi Crystal Orange lại cho rằng nên mở rộng tối đa là 4 tháng

Những chính sách này đặc trưng của phương thức Crystal, tuy nhiên chúng có thể bị thay thế bằng những phương thức tương đương như XP và Scrum

Work products:

Cockburn cho rằng các sản phẩm của Crystal Clear và Crystal Orange thường

có những quy mô khác nhau Tuy nhiên cũng có những sản phẩm tương tự nhau như: phiên bản liên tục, mô hình đối tượng thông thường, sổ tay người dùng, các trường hợp kiểm thử, mã di trú

Thêm vào đó Crystal Clear bao gồm những chú thích để mổ tả các đặc điểm, trái lại ở Crystal Orange lại đòi hỏi các tài liệu đặc tả yêu cầu

Local matters:

Đó là những thủ tục của Crystal mới được ứng dụng, tuy nhiên nó hoàn toàn tách biệt với bản thân dự án, những thủ tục này có phạm vi khác nhau giữa hai phương thức Crystal Clear và Crystal Orange Cả hai phương thức trên đều cho rằng mẫu cho một sản phẩm tốt là mã nguồn, kiểm tra truy hồi, và sử dụng giao diện chuẩn có thể cài đặt và bảo trì bởi chính đội phát triển

Tools:

Công cụ mà Crystal Clear yêu cầu là công cụ biên dịch, công cụ tạo các phiên bản, công cụ cấu hình và quản lý và các trang in Công cụ tối thiểu mà Crystal Orange yêu cầu là công cụ tạo các phiên bản, lập trình, kiểm thử, giao tiếp, theo dõi dự án, đồ họa và biện pháp trình diễn

Standards:

Crystal Orange đề xuất việc lựa chọn những ký hiệu chuẩn, thiết kế thỏa thuận, định dạng chuẩn và chất lượng chuẩn (Cockburn 1998) sẽ được sử dụng trong dự án

Activities:

Các hoạt động được thể hiện qua sơ đồ sau:

4 Feature Driven Development

Feature Driven Development (FDD) là phương pháp tiếp cận linh hoạt dành cho phát triển hệ thống FDD không bao phủ toàn bộ quy trình phát triển phần mềm mà nó tập trung vào giai đoạn thiết kế và xây dựng Tuy nhiên nó được thiết kế để làm việc với những hoạt động khác của một dự án phát triển phần mềm và không yêu cầu bất cứ một mô hình quy trình riêng nào Nó tập trung vào chất lượng sản phẩm xuyên suốt quy trình

FDD bao gồm 5 quy trình liên tục và cung cấp những phương thức, kỹ thuật

và những hướng dẫn mà nhà đầu tư cần đến để chuyển giao hệ thống Phần lặp của quy trình FDD hỗ trợ phát triển linh hoạt với sự thích nghi nhanh chóng với những thay đổi muộn trong yêu cầu của khách hàng

- Phát triển một mô hình toàn thể (Develop an Overall Model)

Khi việc phát triển một mô hình toàn thể bắt đầu, các chuyên gia trong lĩnh vực này họ đã nhận thức được phạm vi, khung cảnh và yêu cầu của hệ thống để xây dựng Các yêu cầu được tài liệu hóa như việc sử dụng các trường hợp hoặc các chức năng đặc biết sẽ có thể xuất hiện ở bước này Tuy nhiên FDD không địa chỉ rõ ràng vấn đề lấy lại và quản lý các yêu cầu Các chuyên gia cũng được gọi là “walkthrough” trong mỗi đội và là người kiến trúc sư chính có hiểu biết cao về hệ thống

Mô hình này có thể được chia nhỏ ra thành các nhóm và mỗi nhóm sẽ có các

“walkthrough” phụ trách Sau “walkthrough” các thành viên trong nhóm phát triển sẽ chia làm các nhóm nhỏ để trao đổi và thảo luận nhằm xây dựng một hệ thống tốt nhất

- Xây dựng một danh sách các tính năng (Build a Features List)

Những chuyên gia, mô hình đối tượng, và những tài liệu về những yêu cầu đã

có để tạo ra nền tảng tốt cho việc xây dựng một liệt kê các tính năng thông minh cho hệ thống đang được phát triển Trong bản liệt kê, người phát triển hệ thống

sẽ trình bày mỗi chức năng giá trị riêng biệt được xây dựng trong hệ thống Chức năng sẽ được trình bày trong các nhóm bao gồm các chức năng trọng yếu đã được cài đặt Thêm vào đó, các tính năng quan trọng này lại được chia ra cho các đặc điểm khác thiết lập Sự biểu diễn lại này khác nhau đối với các phạm vi khác nhau Liệt kê này sẽ được kiểm tra lịa bởi người dùng hoặc các nhà đầu tư cho một hệ thống hiệu quả và trọn vẹn

- Lập kế hoạch nhờ vào tính năng (Plan by Features):

Bao gồm việc tạo ra các kế hoạch cao cấp hơn, mỗi đặc điểm sẽ được sắp xếp theo thứ tự quyền ưu tiên và phụ thuộc và được ấn định cho người đứng đầu nhóm lập trình Ngoài ra, các lớp được đồng nhất trong một quy trình “mô hình phát triển toàn thể” sẽ được phân công cho các lập trình viên khác

- Thiết kế theo tính năng và xây dựng theo tính năng (Design by Feature and Build by Feature):

-

Một nhóm nhỏ các tính năng được lựa chọn từ tập hợp các tính năng Những nhóm tính năng này được các đội phát triển Quy trình thiết kế bằng tính năng

và xây dựng bằng tính năng là những thủ tục có thể được lặp lại trong suốt quá trình những tính năng đã lựa chọn được sản xuất Một bước lặp cần từ vài ngày cho tới tối đa 2 tuần để thực hiện Sau khi thực hiện thành công một bước lặp, những tính năng đã hoàn thành được đưa vào trong chương trình chính trong khi vòng lặp thiết kế và xây dựng bắt đầu với một nhóm các tính năng mới từ tập các tính năng

5 The Rational Unified Process

Ration Unified Process (viết tắt làRUP) được phát triển bởi Philippe Kruchten, Ivar Jacobsen và những thành viên khác tại Ration Corporation để bổ sung cho UML (Unified Modelling Language)

RUP là một phương thức tiếp cận những hệ thống hướng đối tượng, và được

sử dụng để nắm bắt các yêu cầu mẫu và xây dựng nền tảng hệ thống RUP nghiêng về hướng phát triển hướng đối tượng Nó không bác bỏ hoàn toàn những phương thức khác, mặc dù UML đặc biệt thích hợp với phát triển OO Vòng đời của một dự án RUP được chia làm 4 giai đoạn : Khởi đầu (Inception), Dự thảo (Elaboration), Xây dựng (Construction) và Chuyển giao (Transition)

Những giai đoạn lại được chia thành những vòng lặp nhỏ (interation) Khoảng thời gian của một vòng lặp có thể từ 2 tuần tới 6 tháng

- Giai đoạn Khởi đầu (Inception): Xem xét yêu cầu khách hàng và

đưa ra các tiêu chí của dự án Nhóm phát triển đưa ra những kiến trúc xây dựng khác nhau, bản kế hoạch và chi phí ước tính cho toàn bộ dự án Ngoài ra những ước tính cho giai đoạn Dự thảo tiếp theo cũng được xây dựng