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

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, post-

game.

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.

- Giai đoạn Dự thảo (Elaboration): Đây là giai đoạn xây dựng nền

tảng kiến trúc phần mềm. Quy trình, cơ sở hạ tầng, và môi trường phát triển

được mô tả chi tiết. Sau giai đoạn này, hầu hết các tình huống sử dụng và tất cả

cả nhân tố ảnh hưởng được xác định và mô tả. Vào cuối giai đoạn, những phân

tích được thực hiện để đánh giá khả năng xuất hiện rủi ro, sự ổn định của kiến

trúc và chi phí xây dựng so với những gì bước đầu đã xác định.

- Giai đoạn Xây dựng (Construction): tất cả những thành phần còn lại

và tính năng của ứng dụng được phát triển, tích hợp vào sản phẩm và kiểm thử.

Kết quả của giai đoạn xây dựng được tạo ra nhanh nhất có thể trong khi vẫn đảm

bảo chất lượng sản phẩm. Một hoặc vài phiên bản được hoàn thành trong giai

đoạn này trước khi chuyển sang giai đoạn Chuyển giao.

- Giai đoạn chuyển giao (Transition Phase): là giai đoạn khi mà sản

phẩm phần mềm đủ điều kiện để đưa tới cộng đồng người dùng. Dựa trên những

phản hồi của người dùng, những phiên bản tiếp theo sẽ được vá lỗi hoặc gỡ bỏ đi

những tính năng không cần thiết. Giai đoạn chuyển giao bao gồm kiểm thử beta,

phân phối thí điểm, đào tạo người dùng, duy trì hệ thống, đưa sản phẩm ra thị

trường, phân phối và thành lập đội kinh doanh.

6. Dynamic Systems Development Method (DSDM)

Kể từ khi ra đời năm 1994, DSDM dần dần trở thành framework số 1 cho

việc phát triển ứng dụng nhanh (RAD) ở UK. DSDM là frame work miễn phí và

không bị ràng buộc bởi luật bản quyền dành cho sự phát triển RAD, được duy trì

bởi DSDM Consortium. Những nhà phát triển duy trì rằng ngoài việc phục vụ

như là một trong các phương pháp thông thường đã được chấp nhận DSDM cũng

cung cấp một framework kiểm soát cho RAD, được bổ sung bởi sự hướng dẫn

cách kiểm soát hiệu quả.

Ý tưởng cơ bản đằng sau DSDM là thay vì cố định số lượng chức năng trong

một sản phẩm và sau đó điểu chỉnh thời gian và chi phí để hoàn thành, nó sẽ cố

định thời gian và chi phí hoàn thành và sau đó điều chỉn số lượng chức năng sao

cho phù hợp.

DSDM bao gồm 5 giai đoạn: feasibility study, business study, functional

model iteration, design and build iteration và implementation. Hai giai đoạn đầu

được thực hiện liên tiếp nhau và hoàn thành cùng thời điểm. 3 giai đoạn cuối,

mỗi khi công việc phát triển hiện thời được hoàn thành, sẽ được lặp lại với quy

mô lớn hơn.

- Feasibility study là giai đoạn mà sự thích hợp của DSDM đối với dự

án được đánh giá. Thông qua kiểu dự án và nhiều yếu tố khác quyết định được

đưa ra, sử dụng DSDM hay là không. Thêm vào đó, giai đoạn này còn đề cập

đến tính khả thi về kĩ thuật trong suốt dự án, những rủi ro trong đó và đưa ra bản

báo cáo tính khả thi và bản phác thảo kế hoạch phát triển.

- Business study là giai đoạn những đặc điểm cơ bản của nhiệm vụ cần thực

hiện và công nghệ được phân tích. Phương pháp tiếp cận được đề nghị để tổ

chức các hội thảo, nơi mà các chuyên gia của khách hàng tập trung đầy đủ để

có thể xem xét, đánh giá tất cả các mặt có liên quan của hệ thống và có thể

quyết định những gì được ưu tiên phát triển. Những quy trình nhiệm vụ chịu

ảnh hưởng và những lớp người dùng được mô tả trong Business Area

Definition. Việc xác định những lớp người dùng chịu ảnh hưởng đã thu hút

được khách hàng. Sự mô tả ở mức cao hơn của những quy trình được trình bày

trong Business Area Definition với dạng thích hợp như mô hình thực thể liên

kết,…

- Functional model iteration là giai đoạn lặp và gia tăng đầu tiên. Trong mỗi

bước lặp, nội dung và phương pháp tiến cận được lên kế hoạch, đi qua bước

lặp đó và kết quả được phân tích cho các bước lặp tiếp theo. Khi cả việc phân

tích và viết mã hoàn thành, bản dùng thử được xây dựng và những kinh

nghiệm thu được từ chúng được sử dụng để nâng cấp mô hình phân tích. Bản

dùng thử không bị loại bỏ hoàn toàn mà dần dần đi theo hướng nâng cao chất

lượng, như vậy chúng có thể được đưa vào trong hệ thống cuối cùng. Mô hình

chức năng đươc tạo ra như là một đầu ra, gồm mã bản dùng thử và mô hình

phân tích. Kiểm thử cũng là một phần cơ bản của giai đoạn này.

- Design and build iteration là giai đoạn mà hệ thống được tập trung xây dựng.

Đầu ra là một hệ thống đã được kiểm thử đáp ứng tối thiểu yêu cầu khách

hàng. Thiết kế và tính năng bản dùng thử được đánh giá bởi người dùng và

những phát triển sau này sẽ dựa trên những đánh giá đó.

- Implementation là giai đoạn hệ thống được chuyển tử môi trường phát triển

sang môi trường sản xuất thực tế. Công việc đào tạo, huấn luyện người dùng

được tiến hành và hệ thống được vận hành bởi họ. Nếu như khi triển khai thu

hút được số lượng lớn người dùng thì giai đoạn bổ sung cũng có thể được lặp

lại. Bên cạnh hệ thống, đầu ra của giai đoạn bổ sung cũng gồm tài liệu hướng

dẫn người dùng và bản báo cáo đánh giá dự án. Dựa trên kết quả đánh giá dự

án, kế hoạch về những phát triển sau này được xây dựng. DSDM vạch rõ bốn

khả năng có thể xảy ra. Nếu hệ thống đáp ứng được toàn bộ các yêu cầu thì

việc phát triển thêm là không cần thiết. Nhưng nếu vẫn còn có những yêu cầu

hệ thống chưa đáp ứng được thì quy trình phát triển có thể phải tiến hành lại từ

bắt đầu tới kết thúc. Nếu như một vài chức năng bị bỏ qua thì quy trình phát

triển có thể tiến hành lại từ functional model iteration. Cuối cùng, nếu một số

vấn đề kĩ thuật không được tập trung do eo hẹp về thời gian, chúng có thể được

hoàn thành khi tiến hành lại vòng lặp, bắt đầu từ giai đoạn thiết kế và xây

dựng.

7. Phát triển phần mềm thích nghi

Phát triển phần mềm tương thích (Adaptive Software Development-ASD)

được phát triển bởi James A.Highsmith III. Hiện nay có khá nhiều các nguyên

tắc của ASD khác với những tài liệu nghiên cứu của Highsmith trước kia về

phương pháp phát triển lặp. Một trong những tiền thân được biết đến nhiều nhất

của ASD là “RADical Software Development” (phát triển phần mềm căn bản),

mô hình được phát triển bởi sự cộng tác của Highsmith và S. Bayer và được giới

thiệu trong “Bayer and Highsmith” 1994.

Trọng tâm chính của ASD là vào những vấn đề trong việc phát triển các hệ

thống lớn và phức tạp. Phương pháp này đã kích thích mạnh mẽ việc phát triển

lặp với việc chế thử liên tục. Về cơ bản ,ASD là “giữ cho cân bằng ở ranh giới

của sự hỗn loạn”,do đó,mục đích của ASD là cung cấp một khuôn mẫu vói

những hướng dẫn đầy đủ để tránh cho dự án lâm vào tình trạng hỗn loạn,khó

kiểm soát mặc dù đôi khi nó cũng làm hạn chế những sáng tạo hay những đột

phá.

Một dự án ASD được thiết kế theo 3 chu kì,được biểu diễn bởi hình sau :

Các bước này được đặt tên theo cách để nhấn mạnh vào vai trò của việc thay

đổi trong tiến trình.

Ở đây, “Speculation”xem xét , nghiên cứu) được dùng thay cho “Planning”

(lên kế hoạch) bởi vì 1 kế hoạch thì nhìn chung là chỉ được nhìn nhận như là 1

cái gì đó không chắc chắn lắm,do đó mà những sự sai lệch sẽ dẫn đến thất bại.

Tương tự như vậy, “Collaborate”(cộng tác) được sử dụng để nhấn mạnh vào tầm

quan trọng của làm việc theo nhóm như là ý nghĩa của việc phát triển những hệ

thống có sự thay đổi cao.”Learn”(học tập) lại nhấn mạnh vào sự cần thiết của

kiến thức và sửa lỗi, và trong thực tế là những yêu cầu có thể thay đổi liên tục

trong suốt quá trình phát triển. Hình sau đây sẽ miêu tả chi tiết hơn về chu kì

phát triển thích nghi:

Bước khởi tạo dự án định ra những nền tảng của dự án và được bắt đầu bằng

cách định ra những nhiệm vụ của dự án.Những nhiệm vụ này cơ bản là lập ra

một khung thô cho sản phẩm cuối,và tất cả các việc phát triển sẽ được chỉ đạo để

các nhiệm vụ được hoàn thành.Một trong những cái quan trọng nhất trong việc

định ra các nhiệm vụ cho dự án là phác thảo ra những thông tin nào cần thiết cho

dự án.Các mặt quan trọng của nhiệm vụ được định ra theo 3 phần: tầm nhìn của

dự án,dữ liệu dự án,1 sản phẩm đầu ra chi tiết. Ý nghĩa của những tài liệu này

được được giải thích chi tiết trong Highsmith 2000. Bước khởi tạo dự án sửa lại

bảng lịch trình kế hoạch tổng thể cũng như lich trình và các mục tiêu cho mỗi

chu kì phát triển. Chu kì điển hình kéo dài từ 4 cho đến 8 tuần. ASD rõ ràng là

hướng thành phần hơn là hướng nhiệm vụ. Trong thực hành,điều này có ý nghĩa

là trọng tâm được đặt vào kết quả và chất lượng hơn là nhiệm vụ hay tiến trình

được sử dụng trong quá trình tạo ra kết quả ấy. Tiền đề cho những chu kì phát

triển xa hơn là kết quả của việc lặp đi lặp lại việc kiểm tra chất lượng mà trọng

tâm là tập trung vào phát triển các chức năng của phần mềm trong suốt chu kì.

Một yếu tố quan trọng nữa trong việc đưa ra các đánh giá,kiểm tra là sự có mặt

của khách hàng ,ví dụ như là 1 nhóm các chuyên gia. Tuy nhiên từ khi các đánh

giá,kiểm tra chất lượng trở nên hiếm dần (chúng chỉ được thực hiện vào cuối của

mỗi chu kì) thì sự có mặt của khách hàng trong ASD cũng chỉ được làm trong

các phiên phát triển ứng dụng kết nối (joint application development (JAD)).

Một phiên JAD là vô cùng quan trọng cho công việc, đây là nơi mà khách hàng

và nhà phát triển gặp nhau và thảo luận về những yêu cầu về các tính năng của

sản phẩm, và để nâng cao việc truyền thông với nhau. ASD không đề xuất ra

những lịch trình cho việc tổ chức các phiên JAD nhưng chúng thường được làm

đặc biệt vào những bước đầu của dự án.Bước cuối cùng của dự án ASD là những

câu hỏi \giải đáp cuối cùng và phát hành (Final Q/A and Release ). ASD không

đưa ra cách thực hiện bước này thế nào nhưng nó nhấn mạnh vào tầm quan trọng

của việc nắm được những gì đã học. Các hoạt động kế tiếp của dự án được xem

như rất quan trọng trong các dự án có tốc độ nhanh và có nhiều thay đổi, nơi mà

các quá trình phát triển linh hoạt diễn ra. Tóm lại, tính thích nghi của phát triển

trong ASD được mô tả qua bảng sau:

Đặc

điểm

Mô tả

Hướng nhiệm

vụ

Các hoạt động trong mỗi chu kì phát triển phải phù hợp với

nhiệm vụ tổng thể của dự án .Nhiệm vụ có thể được sửa đổi trong khi

việc phát triển được tiến hành

Dựa vào thành

phần

Các hoạt động phát triển không nên hướng tác vụ,nhưng cũng

nên tập trung vào phát triển phần mềm làm việc như xây dựng hệ

thống theo những phần nhỏ cùng lúc

Lặp lại Một mô hình thác nước chỉ làm việc trong những môi trường đã

được hiểu rõ và được định nghĩa chi tiết.Hầu hết các việc phát triển

đều thay đổi thất thường vì thế thay vì làm đúng trong lần đầu ,các

nỗ lực phát triển nên tập trung vào việc làm lại

Time-Boxed Sự mập mờ trong những dự án phần mềm phức tạp có thể được

giảm bớt bằng cách thay đổi thời hạn.Việc quản lí time-boxed dự án

tập trung vào những người tham gia vào dự án để xử lí sớm những

quyết định khó khăn không tránh khỏi trong dự án

Thích ứng được

với các thay đổi

Thay đổi là thường xuyên trong phát triển phần mềm, việc có thể

thích ứng với nó thì quan trọng hơn là kiểm soát nó.Để xây dựng một

hệ thống thích ứng được với thay đổi,những nhà phát triển phải luôn

đánh giá được sự thay đổi của các thành phần trong quá trình xây

dựng chúng

Hướng rủi ro Việc mở rộng phạm vi những yếu tố rủi ro cao nên được bắt đầu

sơm nếu có thể

8. Phát triển phần mềm mã nguồn mở

Sự kết hợp của những phát minh về he thing bảng thông báo và những thói

quen cũ cũ của những người phát triển phần mềm để chia sẻ mã nguồn miễn phí

với nhau đã thúc đẩy sự mở rộng của Internet trên phạm vi toàn cầu vào những

năm 90. Tiến trình phát triển này đã khơi nguồn cho ý tưởng về 1 mô hình phát

triển phần mềm mới – OSS - cách phát triển ứng dụng khá mới lạ.

OSS cho rằng mã nguồn nên miễn phí và có thể sửa chữa hoặc bổ sung mà

không cần trả tiền. Feller và Fitzgerald (2000) đã trình bày một số động lực và

phương hướng cho phát triển OSS như sau:

- Tính kĩ thuật; cần thiết phải có những mã mạnh, vòng đời phát triển

nhanh hơn, đạt những tiêu chuẩn chất lượng cao hơn, đáng tin cậy và ổn định và

hơn hết là tính mở.

- Tính thương mại; sự hợp tác cần cho cả việc san sẻ lợi nhuận cũng

như rủi ro.

- Về chính trị, xã hội; thỏa mãn những sở thích cá nhân, mong muốn

về công việc có ý nghĩ và hướng tới cộng đồng.

Phần lớn mọi người đều biết rằng dự án phát triển OSS lấy trọng tâm là

những công cụ phát triển hoặc những môi trường được các chuyên gia sử dụng

để phát triển chúng thêm, vì vậy cùng lúc, họ đóng vai trò là người sử dụng và

nhà phát triển. OSS không phải là một bản thing kê các thực nghiệm phát triển

phần mềm đã được định nghĩa hay đã được ra đời mà nó được mô tả chính xác

hơn trong thuật ngữ về những quyền hạn khác trong việc phân phối phần mềm.

Sáng kiến về mã nguồn mở sẽ công nhận và cấp bản quyền cho những phần

mềm đáp ứng các yêu cầu của OSS.

Mặc dù có những khác biệt trong những mặt như tính thương mại, về cách tổ

chức nhóm so với các phương pháp linh hoạt khác nhưng trong 1 số tình huống,

các suy nghĩ và thực hiện lại có những điểm giống nhau, ví dụ như tiến trình

phát triển OSS bắt đầu với những việc cho ra đời sớm và thường xuyên các bản

thử nghiệm và nó thiếu rất nhiều các cơ chế truyền thống, cái mà được sử dụng

cho hợp tác phát triển phần mềm với những kế hoạch, thiết kế cấp độ, lập lịch và

những tiến trình đã định. Thông thường, một dự án OSS bao gồm các bước sau:

- Tìm hiểu vấn đề

- Tìm những người tình nguyện

- Định ra cách giải quyết

- Phát triển và kiểm thử mã nguồn

- Thay đổi mã nguồn

- Các tài liệu hướng dẫn mã nguồn

- Tổ chức phát hành

Mặc dù có thể mô tả phương pháp phát triển phần mềm OSS theo những

bước trên nhưng sự quan tâm lại nằm ở chỗ quản lí những bước trên như thế nào,

sau đây là một vài đặc điểm mô tả phương pháp phát triển OSS :

- hệ thống được xây dựng bởi số lượng lớn những người tình nguyện

- Công việc không được phân định rõ ràng mà mọi người tự chọn công việc

mà mình thích

- Có những thiết kế cấp độ hệ thống không rõ ràng

- Không có kế hoạch, lịch trình

- Hệ thống phát triển theo những bước tiến nhỏ

- Chương trình được kiểm thử thường xuyên

Theo Feller và Fitzgerald (2000), tiến trình phát triển OSS được tổ chức là

một cách phát triển và những cố gắng gỡ lỗi trong phạm vi rộng 1 cách song

song, nó bao gồm sự hợp tác và những cống hiến của những người phát

triển.Tuy nhiên, cũng có những dấu hiệu chỉ ra rằng ý tưởng phát triển miễn phí

này đang dần thay đổi vì tiến trình phát triển OSS không có bất kì một quy tắc

hay thói quen được chuẩn hóa nào thế nhưng tiến trình này vẫn liên quan đến

thói quen và những điều cấm kị đã được học hoặc rút ra từ thực nghiệm.

III. So sánh các phương pháp phát triển phần mềm linh hoạt

1. Giới thiệu

Việc so sánh khách quan các phương pháp với nhau thường rất khó, và những

kết quả thu được thông thường đều dựa trên các kinh nghiệm chủ quan của những

người đi trước hay là những hiểu biết trực giác của người làm (Song and Osterweil

1991). Có 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 đó.

2 Rút ra những đặc điểm quan trọng từ một 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 thành 1 vấn đề cụ thể

Ở đây chúng ta có sử dụng hai thuật ngữ là “những điểm chính “ (key points)

và “những điểm đặc biệt” (Special features). Những điểm chính mô tả cụ 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, PP, ASD. Thế nhưng cũng ít người biết được là họ đang dùng phương

pháp nào nên có thể nói các phương pháp trên cũng đang trong quá trình xây

dựng.

AM mới được đưa ra cách đây 1 vài năm nên nó ở trạng thái là “ mới sinh”.

XP,RUP,OSS và DSDM là những phương pháp hay những cách tiếp cận đã được

giới thiệu cẩn thận và có thể sẵn sàng sử dụng , hơn nữa,mỗi phương pháp này lại

có những nghiên cứu riêng và cộng đồng người dùng riêng, vì vậy mà chúng đang

ở trạng thái “hoạt độ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 .

2 . Những đặc điểm chung

Trạng thái Mô tả Phương pháp

“mới sinh”

(nascent)

Phương pháp mới được đưa ra một vài

năm, chưa có những nghiên cứu cụ thể ,

và chưa có báo cáo thực nghiệm

AM

“Đang xây dựng”

(building up)

Phương pháp và những cách tiếp cận đã

được công bố rộng rãi,báo cáo thực

FDD ,Crystal

,Scrum, PP, ASD

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

“hoạt động”

(active)

Phương pháp đã được áp dụng ở nhiều nơi

, có báo cáo thực nghiệm, có những

nghiên cứu và có cộng đồng người dùng

đang hoạt động

XP

,RUP,OSS,DSDM

Các đặc điểm chính và các đặc điểm quan trọng của các phương pháp được

tóm tắt trong bẳng sau :

Tên

phương

pháp

Đặc điểm chính Đặc điểm quan trọng Hạn chế

ASD Tương thích với văn

hóa,hợp tác trong công

việc, các thành phần

hướng nhiệm vụ dựa

trên sự phát triển lặp

lại.

Được tổ chức như một

hệ thống tương thích.

Tạo ra một trật tự

nghiêm ngặt nằm

ngoài mạng lưới các cá

nhân liên kết với nhau

ASD thiên về khái

niệm và văn hóa hơn

là thực hành phần

mềm

AM Áp dụng các nguyên tắc

linh hoạt để mô hình hóa

: sự đa dạng, linh hoạt

trong văn hóa,cách tổ

chức công việc để hỗ trợ

việc truyền thông đơn

giản hơn

Cách suy nghĩ linh

hoạt cũng được áp

dụng để thiết kế mẫu

Đâ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

Crystal Là tập hợp của các

phương pháp, mỗi cái có

cùng một giá trị ban đầu

và nguyên tắc cơ bản về

kĩ thuật, vai trò, công cụ

và tiêu chuẩn thì có thể

khác nhau

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

Quá sớm để cho rằng

chỉ có 2 trong số 4

phương pháp được

khuyến cáo đang được

dùng

DSDM ứng dụng việc điều Là phương pháp phát Trong khi mà phương

khiển vào RAD, sử dụng

timeboxing, các nhóm

DSDM có quyền hay

các tập đoàn tài chính để

chỉ đạo việc phát triển

phương pháp

triển phần mềm linh

hoạt thực sự đầu

tiên,sử dụng việc chế

thử, một vài vai trò của

người dùng như: đại

sứ, nhà tiên tri hay cố

vấn

pháp này áp dụng thì

chỉ có những tập đoàn

tài chính thành viên

mới có quyền truy

nhập vào các giao dịch

giấy tờ với thực tế sử

dụng phương pháp .

XP Phát triển hướng người

dùng, các nhóm nhỏ,

xây dựng thường xuyên

Liên tục thiết kế lại hệ

thống để nâng cao hiệu

suất và đáp ứng các

thay đổi

Trong khi những phần

việc cá nhân có vẻ phù

hợp trong nhiều tình

huống thì cái nhìn

tổng quan và việc

quản lí lại ít được

quan tâm.

FDD Là quá trình gồm 5

bước, phát triển dựa trên

thành phần hướng đối

tượng, bước lặp lại rất

ngắn (từ vài tiếng cho

đên 2 tuần)

Sự đơn giản trong

phương pháp, thiết kế

và thực hiện hệ thống

bằng cách mô hình hóa

đối tượng và đặc điểm

Trọng tâm của FDD

nhằm vào thiết kế và

thực hiện, cần thêm

những cách thức hỗ

trợ khác

OSS Dựa trên sự tự nguyện,

phát triển phân

tán,những khó khăn

thường là về trách

nhiệm với đòi hỏi, yêu

cầu hơn là trách nhiệm

thương mại

Mã nguồn luôn sẵn

sàng miễn phí cho mọi

người

Bản thân OSS không

phải là 1 phương pháp,

có thể chuyển các

nguyên tắc OSS sang

phát triển phần mềm

thương mại

PP Nhấn mạnh vào tính

thực dụng, lí thuyết lập

trình không it quan

trọng, tự động hóa ở cấp

độ cao trong các khâu

của lập trình

Các thủ thuật, gợi ý cụ

thể có tính kinh

nghiệm…tiếp cận thực

tế đến phát triển phần

mềm

Trọng tâm của PP là

các phần việc cá nhân,

tuy nhiên nó không

phải là phương pháp

mà ở đó hệ thống có

thể phát triển

RUP Hoàn thành mô hình

phát triển SW bao gồm

hỗ trợ công cụ, phân

công vai trò hướng đến

hoạt động

Là mô hình kinh

doanh, hỗ trợ công cụ

RUP không hạn chế

phạm vi sử dụng,

nhưng một mô tả làm

thế nào để đáp ứng

thay đổi mà cụ thể là

thay đổi nhu cầu thì lại

bị bỏ qua.

Scrum Độc lập, nhỏ, các nhóm

phát triển có thể tự sắp

xếp,quay vòng trong 30

ngày

Thực hiện mô hình

chuyển đổi từ “định

nghĩa và có thể lặp

lại” sang “tầm nhìn

phát triển sản phẩm

mới của Scrum”

Trong khi Scrum rất

chi tiết việc làm thế

nào để quản lí quay

vòng trong 30 ngày thì

việc lặp lại và kiểm

thử lại không chi tiết.

Bảng trên đã trình bày những điểm khác nhau cơ bản của những phương pháp

mà ta đang nghiên cứu. ASD là phương pháp trừu tượng nhất từ quan điểm phát

triển phần mềm .Mặc dù nghe khá hấp dẫn, nhưng mục tiêu chính – tạo ra một trật

tự nghiêm ngặt nằm ngoài mạng lưới các cá nhân liên kết, có thể sẽ khá khó khăn

để đạt được. Đây cũng là hạn chế chính của nó kể từ khi những kĩ sư gặp khó khăn

trong việc chuyển đổi những khái niệm mới sang những cái mà họ quen dùng .Mô

hình linh hoạt (Agile modeling- AM), XP và lập trình thực tế, tất cả đều đại diện

cho quan điểm hướng thực hành. Chúng bao gồm một số lượng các kinh nghiệm

thực hành hữu dụng được rút ra bởi các kĩ sư. Vì vậy, chúng rấ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ắc đến như người dùng

đóng vai trò như một đại sứ, một nhà tiên tri hay một cố vấn. Những vai trò này

của người dùng đại diện cho những quan điểm khác nhau của khách hàng. Mặt hạn

chế của DSDM chính là sự phụ thuộc vào các tập đoàn tài chính DSDM nhằm

ngăn chặn quyền tham gia các giao dịch giấy tờ. FDD không đặt mục tiêu cung

cấp một giải pháp all-in-one cho phát triển phần mềm mà trọng tâm của nó là cách

tiếp cận 5 bước đơn giản, cái mà dựa trên việc xác định, thiết kế, thực hiện các đặc

tính. FDD cũng tuyên bố rằng 1 số việc theo dự án này đã được làm , vì vậy mà nó

sẽ không bao gồm những giai đoạn đầu của dự án.Scrum là một cách tiếp cận quản

lí dự án dựa trên các nhóm phát triển độc lập tự quản, thực hiện các dự án phần

mềm theo mỗi chu kì 30 ngày, gọi là các chặng nước rút. Tương tự như ASD ,

OSS thì giống các nguyên tắc 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 triển đầy đủ

được hỗ trợ bởi đa dạng các công cụ thương mại, đây là điểm khác biệt nhất của

RUP so với các phương pháp khác. RUP cũng mở rộng phương pháp để bao gồm

cả các mô hình thực hiện mang tính chất thương mại giống như DSDM, do đó,

cũng có những sự hỗ trợ trong những bước đầu của dự án phát triển phần mềm.

3. Thực hiện theo phương pháp

Trong những phương pháp đã trình bày ở trên,việc thực hiện theo mới đề cập

đến quy trình, vai trò, trách nhiệm và thực hiện theo, rút ra kinh nghiệm, nhưng

ngoài ra, việc so sánh còn mở rộng sang cả các vấn đề về quản lí 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ó khả năng tài chính để làm chậm hay dừng việc sản xuất để tái tổ

chức hay tìm ra hướng đi mới trong công việc kinh doanh của họ. Việc làm theo

và rút ra kinh nghiệm để đánh giá mỗi phương pháp đã được trình bày ở những

phần trên. Một điều khá rõ ràng rằng có không nhiều những báo cáo kinh nghiệm

và càng ít hơn những báo cáo khoa học về vấn đề này. Nandhakumar và Avison

nhận thấy rằng những phương pháp phát triển phần mềm truyền thống đang được

sử dụng hiện nay như là một sự mơ hồ tất yếu để cho ta thấy thực trạng của việc

quản lí hoặc là để đưa ra một tình trạng tiêu biểu. Họ cũng khuyến cáo rằng

những phương pháp thay thế, cái mà mang đặc điểm đặc biệt của công việc trong

nhiều môi trường là rất cần thiết. Nhhững đặc điểm đặc biệt của công việc của

công việc mà họ đề cập đến ở đây là môi trường kinh doanh sôi động hay thay đổi

theo nền kinh tế. Trong những môi trường này, những thay đổi là rất cần thiết để

đạt được dự án hay thậm chí là đạt đến 1 mức rất cao. Nandhakumar và Avison

cũng cho rằng công việc thực hiện của những nhà phát triển chỉ bộc lộ rõ nét nhất

khi có những yếu tố tương ứng. Một lần nữa, lại có 1 vấn đề là tất cả các phương

pháp phát triển phần mềm linh hoạt đều được phân định rõ ràng, thực tế là tất cả

các quan điểm về phương pháp linh hoạt đều bộc lộ đặc trưng khi đặt điểm nhấn

vào những khía cạnh sau:

- Việc đem lại 1 vài lợi ích

- Tin cậy với con người

- Khuyến khích cộng tác

- Thúc đẩy những tiến bộ kĩ thuật

- Khả năng tạo ra những cái đơn giản nhất

- Có tính tương thích

Nandhakumar và Avison cũng cho rằng việc phát triển phần mềm hiện nay rất

khác so với quan điểm phương pháp luận phổ biến, bảng sau bổ sung thêm những

phát hiện của họ với cách tiếp cận linh hoạt,nó trình bày những điều xa hơn ,điều

mà phát triển phần mềm linh hoạt đang tiếp cận, kể cả nhiều cách thức phát triển

phần mềm hiện nay, do đó, nó giải thích phần nào tại sao, ví dụ như, lập trình gần

đây lại thu hút được nhiều sự chú ý đến vậy, hơn nữa nó cũng tiếp cận đến phát

triển phần mềm từ quan điểm của người phát triển

Quan điểm phương pháp

luận

Phát triển phần mềm

trong thực hành

Quan điểm biện hộ bởi

phương pháp linh hoạt

Các nhiệm vụ riêng rẽ Các kế hoạch cá nhân

liên hệ lẫn nhau

Các kế hoạch cá nhân

liên hệ lẫn nhau

Dự đoán được thời gian Không đoán trước

được kết thúc

Đoán được kết quả của

bước tiếp theo

Hoạt động

Có thể lặp lại Phụ thuộc vào hoàn

cảnh

Thường phụ thuộc vào

hoàn cảnh

Tin cậy Phụ thuộc vào điều

kiện, hoàn cảnh

Đáng tin cậy

Những tác động qua lại có

thể thấy rõ được

Có sắn tính tương tác Các tương tác cụ thể

làm tăng khả năng

tương tác tự nhiên

Quy trình

thực hiện

Các nhiệm vụ đơn nối tiếp Nhiều nhiệm vụ kết

hợp với nhau

Các nhiệm vụ đơn

thường bị ràng buộc

theo các điều kiện

Tận tụy với dự án SW Thích ứng với nhiều

việc như dự án,không

phải dự án, cá nhân

Người phát triển đánh

giá được cố gắng cần

thiêt trong công việc

Không có tính phân hóa Phân biệt cá nhân Phân biệt cá nhân

Nỗ lực của

người phát

triển

Tinh thần sẵn sàng cao Tận dụng triệt để Tận dụng triệt để

Thường xuyên Tận dụng cơ hội, ứng

phó nhanh và gián

đoạn

Chỉ chấp nhận việc

kiểm soát hiện tai, tôn

trọng công việc của

người khác

Điều khiển

công việc

Kiểm soát những bước

tiến quan trọng,những kế

hoạch và việc quản lí

Hội thảo cá nhân và

thương lượng với

nhau

Hội thảo cá nhân và

thương lượng với nhau

Mặc dù cách tiếp cận linh hoạt phần nào tương đồng với việc phát triển phần

mềm hiện tại nhưng chúng không phải phù hợp hoàn toàn theo các bước trong chu

trình phát triển phần mềm. Biểu đồ 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 và sản phẩm công

việc cái mà sau đó có thể được dùng trong nhiều hoàn cảnh khác nhau hay không.

Màu nâu biểu thị phương pháp này được áp dụng trong suốt vòng đời của bước

còn màu trắng biểu thị phương pháp này không cung cấp những thông tin chi tiết

về 1 trong 3 lĩnh vực được đánh giá là quản lí dự án, tiến trình, thực hiện\ hoạt

động\ sản phẩm công việc.

Biểu đồ trên cho thấy phương pháp linh hoạt tập trung vào các khía cạnh khác

nhau của vòng đời phát triển phần mềm. Hơn nữa, một số lại tập trung vào thực

hành (như lập trình cực hạn (Extreme Programming), lập trình thực tế, mô hình

linh hoạt) trong khi số khác lại tập trung vào quản lí dự án phần mềm (Scrum).

Chưa hết, lại có những cách tiếp cận lại được sử dụng trong toàn bộ quá trình phát

triển (DSDM,RUP ) trong khi hầu hết chúng chỉ phù hợp trong những bước cụ thể

(FDD). Do đó, có sự khác nhau rõ ràng đa dạng các phương pháp phát triển phần

mềm linh hoạt. Trong khi DSDM và RUP không cần bổ sung thêm các cách tiếp

cận để hỗ trợ phát triển phần mềm, thì những phương pháp kia phải cần. Tuy

nhiên, DSDM lại chỉ phù hợp cho những thành viên của các tập đoàn tài chính

DSDM còn RUP thì sau này là môi trường phát triển mang tính thương mại. Cân

nhắc làm theo phương pháp nào, quy mô của nhóm phát triển như thế nào hiện nay

trở thành một trong những vấn đề quyết định chính. XP, Scrum, AM và PP tập

trung vào các nhóm nhỏ, thường là dưới 10 kĩ sư phần mềm. Crystal, FDD , RUP,

OSS, ASD và DSDM lại yêu cầu khả năng phát triển lên đến 100 người phát

triển. Tuy vậy, những đề xuất linh hoạt thừa nhận rằng khi mà quy mô nhóm phát

triển càng tăng lên thì số lượng tài liệu cũng tăng, do đó,làm cho dự án ít linh hoạt

đi. Khi nhóm phát triển tăng lên đến 20 kĩ sư phần mềm, thì vấn đề nổi cộm ở đây

là giải quyết khó khăn trong truyền thông hiệu quả. Mỗi phương pháp lại bao gồm

một số lượng các gợi ý làm thế nào để tổ chức các kênh truyền thông với những

nhóm kĩ sư nhỏ. Phương pháp tiếp cận linh hoạt xuát hiện đặc biệt phù hợp với

những tình huống mà những yêu cầu tiếp theo không được biết. Điều này cho

thấy, nếu các yêu cầu tiếp theo như những yêu cầu về hiệu suất, về những xử lí

phụ khác, hay những yêu cầu về tính năng … mà được biết hay đã được định rõ thì

các cách tiếp cận linh hoạt sẽ không có nhiều ý nghĩa với việc phát triển dự án.

Highsmith (2002) đã có những nỗ lực trong việc tìm ra giai đoạn thị truờng phù

hợp nhất với phương pháp linh hoạt. Ông cho rằng các cách tiếp cận linh hoạt đặc

biệt phù hợp với giai đoạn “ngõ hẻm (bowling alley) “ và “Bão táp (tornado)”

(xem phần những đặc điểm của các giai đoạn thị trường khác nhau của Moore

1995). Một ví dụ cho điều này là, trong giai đoạn ngõ hẻm, Highsmith cho rằng,

trong giao tiếp khách hàng với sự đáp ứng thay đổi ở cấp độ cao và cường độ lớn

thì nên phát triển bằng phương pháp tiếp cận linh hoạt hướng hợp tác. Highsmith

cũng gợi ý là kết hợp các phương pháp lại với nhau thành 1 cơ cấu, tổ chức cũng

khá quan trọng và những tổ chức có năng lực cao và hợp tác tốt thì sẽ phù hợp cho

phương pháp tiếp cận linh hoạt hơn là những tổ chức mà chỉ phụ thuộc vào việc

quản lí ,tuy nhiên cũng chưa có sự hỗ trợ về kinh nghiệm nào cho những điều này.

Những cái được và những khó khăn của việc chọn làm theo một phương pháp nào

đó rất khó để đánh giá và cũng có một số rất ít những nhà nghiên cứu nghiên cứu

về vấn đề này. Tuy vậy, chúng ta vẫn phải thấy rằng, nếu có một sự chuyển đổi mô

hình giữa cách phát triển phần mềm truyền thống và phát triển phần mềm linh hoạt

thì nó sẽ rất rộng và việc hỗ trợ để chọn theo một kiểu hoặc theo kĩ thuật nào sẽ bị

bỏ qua, và khi đó, có thể các tổ chức và những nhà phát triển sẽ không tiếp tục áp

dụng phương pháp linh hoạt trong công việc hằng ngày nữa. Việc chuyển đổi mô

hình này không đặt trọng tâm vào những gì vẫn làm theo truyền thống như lập kế

hoạch, chuẩn bị cho các bước tiếp theo, cho tài liệu, thỏa thuận hợp đồng cùng với

những quy trình và công cụ. Các tổ chức và cá nhân hầu như không thể thay đổi

180 độ trong việc thực hiện việc phát triển phần mềm của họ. Hầu hết các phương

pháp được nghiên cứu đều nâng cao vai trò, quyền hạn của khách hàng và nhóm

phát triển để có được những đánh giá quý báu cho quá trình phát triển. Vì vậy,

việc làm theo phương pháp linh hoạt cũng yêu cầu sự thay đổi trong văn hóa, đặc

biệt là trong giai đoạn đầu và giữa của việc phát triển. Rất nhiều cơ chế quản lí

truyền thống như báo cáo định kì phải được chuyển đổi theo hướng sản xuất các

mã làm việc. Một mặt, điều này đòi hỏi thay đổi cách thức tổ chức, mặt khác nó

cũng đặt nhiều niềm tin vào năng lực, khả năng của của nhóm phát triển. Thêm

vào đó, cũng có cả rủi ro trong việc thay đổi phương pháp phát triển. Tất cả các

cách tiếp cận linh hoạt đều đưa ra việc phát triển các đặc tính phần mềm trong

những chu trình nhỏ từ 2 đến 6 tuần, do đó, rủi ro ít nhất, ví dụ như việc sai lịch

trình sẽ thấy trước được trong vài tuần. Những đề xuất về phương pháp linh hoạt

được biết đến như của Highsmith hay Schwaber, tin rằng việc triển khai theo 1

phương pháp sẽ đạt được những kết quả tốt hơn nếu nó có 1 sự hậu thuẫn vững

chắc, do vậy cần có những sự quan tâm và hỗ trợ chiến lược. Mặc dù cũng có 1 vài

luận chứng nhỏ khá hữu ích cho vấn đề này, nhưng những nghiên cứu mang tính

kinh nghiêm vẫn cần thiết để quyết định xem bao giờ,như thế nào và trong tình

huống nào thì các phương pháp linh hoạt có thể được áp dụng tốt nhất. Thực hiện

theo công nghệ mới không hẳn là công nghệ phát triển phần mềm linh hoạt ấy

khác xa so với các công nghệ phần mềm khác hay nó sẽ phủ nhận các thành tựu

nghiên cứu, ví dụ như Agarwal và Prasal chỉ ra rằng sự tin tưởng vào công nghệ

mới và việc triển khai theo công nghệ ấy có quan hệ khá mật thiết với nhau,

Abrahamsson cũng đã đưa ra một luận điểm tương tự như vậy. Một yếu tố quan

trọng khác ảnh hưởng đến việc triển khai công nghệ mới là cách nắm bắt có tổ

chức, có kiến thức kĩ thuật, có sự huấn luyện kinh nghiệm và nhận biết những việc

không an toàn. Những phát hiện trên nên được áp dụng trong việc phát triển việc

thực hiện theo mô hình nhằm mục đích cung cấp những hướng dẫn trong quá trình

tiếp cận các phương pháp phát triển phần mềm linh hoạt.

IV. Những phê bình dành cho phương pháp phát triển linh hoạt:

Những tranh cãi về Lập trình cực hạn (Extreme Programming-XP) như Lập trình

ôm ( pair programming) và Thiết kế liên lục vẫn luôn thu hút được nhiều phê bình

gay gắt từ những người như Mc Breen hay Boehm và Turner. Tuy vậy, cũng có

nhiều nhà thực hành linh hoạt lại tin rằng những phê bình ấy là hiểu lầm về phát

triển linh hoạt.

Cụ thể, theo những phê bình của Matt Stephens và Doug Rosenberg trong

Extreme Programming Refactored. Những phê bình này gồm :

- Việc phát triển linh hoạt được dùng như một công cụ để moi tiền khách

hàng do thiếu những định nghĩa về sản phẩm thỏa thuận

- Thiếu những cấu trúc và những tài liệu hướng dẫn cần thiết

- Chỉ làm việc với những nhà lập trình cao cấp

- Hội tụ đủ các thiết kế phần mềm

- Đòi hỏi những hội thảo với chi phí lớn gây lãng phí cho khách hàng

- Đòi hỏi quá nhiều những thay đổi trong văn hóa để thích nghi

- Có thể dẫn đến những thỏa thuận hợp đồng phức tạp hơn

- Có thể không hiệu quả nếu những yêu cầu cho một mẫu code thay đổi

trong quá trình trao đổi qua lại, một chương trình như vậy có thể cần được làm đi

làm lại nhiều lần, trong khi đó, nếu còn 1 kế hoạch nữa theo sau thì 1 mẫu code có

thể phải viết lại một lần nữa.

- Không thể đánh giá được giá trị của công sức bỏ ra vì ngay từ khi bắt đầu

dự án , không ai biết được toàn bộ yêu cầu dự án.

- Có thể làm tăng khả năng nguy cơ kéo dài thời hạn vì thiếu những tài liệu

về yêu cầu chi tiết.

Những phê bình đánh giá về thết kế phần mềm và việc thiếu những tài liệu

hướng dẫn đã được chỉ ra trong phương pháp lập mẫu linh hoạt (Agile Modeling

method), cái mà có thể được dễ dàng thiết kế trong các tiến trình linh hoạt.

Phát triển phần mềm linh hoạt bị phê bình vì nó không mang lại những lợi ích

như đã nêu với người lập trình ở mức độ trung bình.

V. Kết luận

Các nghiên cứu đã chỉ ra rằng, phương pháp luận phát triển phần mềm hướng dự

án theo cách truyền thống không được sử dụng trong thực tiễn và nó cũng quá máy

móc. Kết quả là, các nhà phát triển phần mềm trong công nghiệp đã tỏ ra hoài nghi

về những giải pháp mới cái mà rất khó khăn để tìm ra và do vậy vẫn chưa được sử

dụng. Các phương pháp phát triển phần mềm linh hoạt chính thức được bắt đầu với

sự công bố bản tuyên ngôn về vấn đề linh hoạt, và chúng cũng tạo được những cố

gắng trong việc mang đến mô hình chuyển đổi trong lĩnh vực kĩ nghệ phần mềm.

Các phương pháp linh hoạt yêu cầu hướng trọng tâm đến con người, đến sự tương

tác, đến làm việc phần mềm, đến sự cộng tác với khách hàng và sụ thay đổi hơn là

các quy trình, công cụ, các hợp đồng hay kế hoạch. Có một số hệ phương pháp luận

mới ra đời yêu cầu sự tương thích với các nguyên tắc linh hoạt cũng đang được giới

thiệu tuy nhiên vẫn chưa có được những quan điểm mang tính hệ thống nào về

phương pháp linh hoạt.

Tài liệu này viết ra với 3 mục đích :

Đầu tiên là tổng hợp những tư tài liệu hiện thời về những gì thức sự có ý nghĩa là

“linh hoạt” bằng cách đặt câu hỏi “Cái gì đã biến 1 phương pháp phát triển thành 1

phương pháp linh hoạt?”, và kết luận rằng việc phát triển phần mềm phải đạt được

những yêu cầu sau:

- Phát triển nhanh (các phần mềm nhỏ được hoàn thành nhanh chóng với những

chu kì nhanh)

- Có tính hợp tác (khách hàng và nhà phát triển hợp tác với nhau với 1 cách thân

thiện gần gũi)

- Đơn giản (bản thân phương pháp phải dễ dàng được áp dụng, sửa, và có các tài

liệu hỗ trợ tôt)

- Có tính thích ứng (có khả năng thích ứng với những thay đổi)

Thứ hai, dựa trên cơ sở định nghĩa này, mỗi phương pháp lại được mô tả bằng

những thuật ngữ về quy trình, vai trò, nhiệm vụ, thực hành, triển khai , rút kinh

nghiệm cùng với những nghiên cứu hiện tại.

Thứ ba, cho phép lựa chọn các tiêu chí để so sánh các phương pháp và đưa ra

những điểm giống và khác nhau của các phương pháp, từ đó thấy rằng tuy rằng các

phương pháp có những điểm chung nhưng vẫn có vài phương pháp nổi bật hơn các

phương pháp kia, ví dụ như chúng hỗ trợ các bước khác nhau trong phát triển phần

mềm ở nhiều cấp độ. Những điểm khác nhau này cũng được thấy trong những thực

tế khi mà những phương pháp này được áp dụng.

Ví dụ như ASD thì hầu như tập trung vào các nguyên tắc hưuớng dẫn phát triển

phần mềm trong khi XP lại đặt trọng tâm vào việc thực hành phát triển.

Những cơ sở luận chứng nhỏ cũng đã gợi ra rằng các phương pháp linh hoạt khá

hệu quả và phù hợp trong nhiều môi trường và trong nhiều tình huống, tuy vậy, hiện

tại, có rất ít những nghiên cứu xác đáng mang tính kinh nghiệm hỗ trợ cho luận

điểm này, những luận chứng hiện nay chỉ bao gồm phần lớn là những thành công

của các chuyên gia thực hành. Mặc dù những luận chứng ấy cũng cung cấp những

thông tin khá giá trị về những ứng dụng mang tính thực nghiệm, tuy vậy vẫn cần có

thêm những nghiên cứu mang tính kinh nghiệm để đánh giá được hiệu quả và khả

năng của việc sử dụng những phương pháp phát triển phần mềm linh hoạt. Hơn

nữa, việc cho ra đời thường xuyên các phương pháp linh hoạt thì lại hầu như làm

tình hình rắc rối hơn, mỗi phương pháp lại sử dụng những thuật ngữ, những công

nghệ riêng mà không chú trọng đến việc thống nhất trong cách trình bày quan điểm.

Cái đang vô cùng cấp thiết hiện nay (hơn cả những mô hình mới) chính là sự thực

hiện theo hay chọn lựa những phương pháp để sử dụng cho những người thực hành.

Mục tiêu của việc này là cho phép các chuyên gia phần mềm, các dự án,các tổ chức

có thể chọn và áp dụng được đúng phương pháp và đúng thời điểm. Chúng ta cũng

mong rằng những nghiên cứu mang tính kinh nghiệm hoặc những kinh nghiệm sẽ

tạo cho chúng ta môi trường tiềm năng cho xu hướng phát triển này.

Tóm lại, suy nghĩ linh hoạt là xem con người là trọng tâm của phát triển phần

mềm. Chiến lược lấy con người làm trọng tâm này đã được xem như là một trong

những ưu thế sống còn bởi vì không giống như công nghệ, giá cả, hay phát triển sản

phẩm mới, chiến lược con người khá khó để triển khai (Pfeffer 1998; Miller and Lee

2001). Tuy nhiên đây không phải là việc mới mẻ, vào năm 1990, trong một đề tài

của những nhà lập trình Mỹ (Ed Yourdon’s Software Journal, Vol. 3, No. 7-8) các

nhà biên tập đã bình luận về vấn đề đặc biệt này như sau “Mọi người đều biết cách

tốt nhất để phát triển phần mềm về số lượng cũng như chất lượng chính là đặt con

người làm trọng tâm”. Do vậy, ý tưởng về các phương pháp linh hoạt không phải là

quá mới mẻ, mặc dù vậy,chúng ta vẫn luôn tin rằng những phương pháp phát triển

phần mềm linh hoạt sẽ đem lại cho chúng ta một giải pháp nào đó trong việc tiếp

cận các vấn đề của kĩ nghệ phần mềm .