Ph ươ ng pháp phát tri ển ph ần m ềm linh ho ạt · Tuy nhiên ph ần m ềm không ph...
Transcript of Ph ươ ng pháp phát tri ển ph ần m ềm linh ho ạt · Tuy nhiên ph ần m ềm không ph...
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 .