Đề tài “Tìm hiểu về quy trình phát triển phần mềm theo Agile” pptx

Rút ra ưu nhược điểm của agile và so sánh agile với các phương phápkhác đặc biệt là các phương pháptrước nó Dương Văn Hà Phần III: Các quy trình phát triểnphần mềm theo hướng Agile Cụ th

MỤC LỤC

LỜI MỞ ĐẦU 3

BẢNG PHÂN CÔNG CÔNG VIỆC 4

PHẦN I TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM VÀ QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 5

I Tìm hiểu chung về công nghệ phần mềm 5

1 Công nghệ phần mềm là gì ? 5

2 Lịch sử phát triển của công nghệ phần mềm 5

II Quy trình phát triển phần mềm truyền thống 6

1 Đặc điểm 6

2 Các bước trong mô hình truyền thống 7

3 Một số mô hình phát triển phần mềm truyền thống (phát triển theo kế hoạch) 8

a Mô hình thác nước (waterfall model) 8

b Mô hình làm bản mẫu (Prototyping model) 10

c Mô hình xoắn ốc (The spiral model) 11

d Mô hình đài phun nước (mô hình hướng đối tượng) 13

PHẦN II TÌM HIỂU QUY TRÌNH AGILE 14

I Sự ra đời của mô hình agile 14

1 Sự cần thiết của một mô hình phát triển phần mềm mới 14

2 Agile là gì? 15

II Tìm hiểu chung về agile 15

1 Tuyên ngôn agile 15

2.Nguyên tắc agile: 17

3 Đặc điểm của mô hình agile: 19

III Quy trình thực hiện 20

1 Lập kế hoạch 20

2 Phân tích 20

3 Thiết kế và lập trình 21

4 Test 21

5 Bàn giao sản phẩm 22

IV Những vấn đề cần xem xét để quyết định chọn phát triển theo hướng agile 22

1 Cần trả lời những câu hỏi sau 22

2 Điều kiện áp dụng quy trình agile 22

VI Ưu nhược điểm của phương pháp: 24

1 Ưu điểm: 24

2 Rủi ro và giải pháp 26

V.Công cụ quản lí dự án với agile: agilebench.com 27

1 Khái niệm 27

2 Nội dung 27

VI So sánh phát triển theo mô hình truyền thống và phát triển theo Agile 28

CHƯƠNG III.CÁC PHƯƠNG PHÁP THEO AGILE 30

I.Tìm hiểu chung 30

II Các quy trình phát triển theo hướng Agile 31

1 Quy trình Scrum 31

2 Phương pháp XP (Extreme Programming) 37

3 Phương pháp phát triển phần mềm thích nghi ASD 41

III Đánh giá và so sánh các phương pháp 44

1.Đặc điểm chính 44

2 Khả năng và phạm vi áp dụng 45

KẾT THÚC 46

TÀI LIỆU THAM KHẢO 47

DANH MỤC HÌNH ẢNH 48

LỜI MỞ ĐẦU

Đi cùng với xu thế phát triển mạnh mẽ của các ngành công nghệ khác

trên thế giới, công nghệ phần mềm cũng đang mở ra một cánh cửa cho các tiếpcận tiến bộ Khá nhiều công ty, tổ chức đã nhận thức được tầm quan trọng củangành công nghệ này và đã có những bước tiếp cận đáng ghi nhận Tuy nhiên,song song với những bước phát triển như vậy, nhiều mặt hạn chế

về chất lượng phần mềm vẫn đã và đang là mối quan tâm của nhiều người, nhiều

tổ chức

Là sinh viên của khoa công nghệ thông tin, chúng em sớm đã được tiếpcận với môn công nghệ phần mềm và tìm hiểu khá nhiều qui trình hỗ trợ vànâng cao chất lượng phần mềm Chúng em đã nhận thức được tầm quan trọngcủa các quy trình phát triển phần mềm Mỗi qui trình có những mặt vượt trộiriêng và nhìn chung mục đích chính của chúng cũng để nâng cao chất lượng sảnphẩm và hạn chế rủi ro cho phần mềm làm ra Tuy nhiên, trong những qui trình

ấy chúng em nhận thấy phát triển phần mềm theo Agile là khá tiềm năng Chính

vì vậy, chúng em đã chọn đề tài báo cáo là “Tìm hiểu về quy trình phát triểnphần mềm theo Agile”

Nhóm sinh viên thực hiện:

Đỗ Thị Thanh TuyềnNguyễn Quang HoàngĐoàn Thị Kim DungTrần Văn Thành

Hà Thị Thu HươngDương Văn Hà

BẢNG PHÂN CÔNG CÔNG VIỆC

Tên nhóm Thành viên Nội dung công việc

Nguyễn Quang Hoàng

Phần I: Tổng quan về công nghệ phầnmềm và quy trình phát triển phầnmềm

Cụ thể: Tìm hiểu chung về công nghệ

phần mềm, quy trình phát triển phầnmềm Tìm hiểu và rút ra nhận xét ưuđiểm, nhược điểm của các mô hìnhphát triển phần mềm truyền thống(phát triển theo kế hoạch)

Trần Văn Thành

Phần II: Quy trình phát triển phầnmềm theo Agile

Cụ thể: Tìm hiểu chung về agile, sự

ra đời, nguyên lý làm việc, đặc điểm

và các bước phát triển phần mềm theoagile Rút ra ưu nhược điểm của agile

và so sánh agile với các phương phápkhác đặc biệt là các phương pháptrước nó

Dương Văn Hà

Phần III: Các quy trình phát triểnphần mềm theo hướng Agile

Cụ thể:Tìm hiểu 3 quy trình phát triển

phần mềm được áp dụng theo nguyên

lý của agile là Scrum, ASD và XP

Lưu ý: Các nhóm phải tìm hiểu tất cả các phần nhưng chú trọng nhiều hơn vào

các phần đã được giao

PHẦN I TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM VÀ QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

I Tìm hiểu chung về công nghệ phần mềm.

1 Công nghệ phần mềm là gì ?

- Phần mềm máy tính là gì? Phần mềm máy tính (Computer software) là

các sản phẩm do nhà phát triển phần mềm thiết kế và xây dựng nhằm phục vụmột mục đích nào đó

- Công nghệ phần mềm là gì? Công nghệ phần mềm (SoftwareEngineering) là các hoạt động bao gồm: phát triển, đưa vào hoạt động, bảo trì,

và loại bỏ phần mềm một cách có hệ thống

- Mục tiêu của công nghệ phần mềm là tạo ra những phần mềm tốt nhấtvới thời gian ngắn nhất, giảm đến tối thiểu những rủi ro có thể gây ra cho cáckhách hàng

- Ngành học công nghệ phần mềm bao trùm kiến thức, các công cụ, vàcác phương pháp cho việc định nghĩa yêu cầu phần mềm, cũng như việc thực

hiện các tác vụ thiết kế, xây dựng, kiểm thử (software testing), và bảo trì phần

mềm.Ngoài ra, công nghệ phần mềm còn sử dụng kiến thức của các lĩnh vựcnhư kỹ thuật máy tính, khoa học máy tính, quản lý, toán học, quản lý dự án,

quản lý chất lượng, công thái học phần mềm (software ergonomics), và kỹ nghệ

hệ thống (systems engineering)

2 Lịch sử phát triển của công nghệ phần mềm.

- Thập niên 1940: Chương trình máy tính được viết bằng tay

- Thập niên 1950: Các công cụ đầu tiên xuất hiện như phần mềm biêndịch Macro Assembler và phần mềm thông dịch đã được tạo ra Các trình dịchđược tối ưu hóa lần đầu tiên ra đời

- Thập niên 1960: Các công cụ thế hệ thứ hai như trình dịch tối ưu hóa vàkiểm tra mẫu được thực hiện Khái niệm công nghệ phần mềm được bàn thảorộng rãi

- Thập niên 1970: Các công cụ phần mềm như UNIX các vùng chứa mã,các lệnh make… được kết hợp với nhau

- Thập niên 1980: Các máy PC và máy trạm ra đời Cùng lúc đó có môhình dự toán khả năng Lượng phần mềm tiêu thụ mạnh

- Thập niên 1990: Phương pháp lập trình hướng đối tượng ra đời Các quátrình nhanh như lập trình cực hạn được chấp nhận rộng rãi Chính vì vậy, máytính và internet phát triển rộng rãi.

- Hiện nay: Các phần mềm biên dịch như là net, PHP, Java làm cho việcphát triển phần mềm dễ dàng hơn Quy trình phát triển phần mềm hỗ trợ cũng đadạng

II Quy trình phát triển phần mềm truyền thống.

1 Đặc điểm.

- Các phương pháp truyền thống là các phương pháp thiên về kế hoạch,quá trình phát triển phần mềm phải tuân theo một quy trình nghiêm ngặt Trongquá trình phát triển phần mềm, rất nhiều tài liệu được tạo ra, được xét duyệt và

đó là một yếu tố quan trọng trong quản lí rủi ro

- Với các phương pháp này, toàn bộ quá trình phát triển thường được lên

kế hoạch chi tiết và các tài liệu trước cũng như trong quá trình phát triển đượcchuẩn bị đầy đủ Quá trình phát triển được thực hiện theo quy trình được địnhtrước, và việc tuân thủ quy trình sẽ làm tăng chất lượng phần mềm và giảm rủiro

- Theo các phương pháp này thì quá trình sản xuất phần mềm giống nhưsản xuất các mặt hàng công nghiệp khác Những người phát triển thực hiện côngviệc một cách nghiêm ngặt theo các chuẩn và quy trình, không yêu cầu sáng tạonhiều Những người quản lí chỉ cần tăng năng lực sản xuất và đạt được các mụctiêu như:

- Giảm thiểu lỗi và công việc diễn ra trơn tru

- Cố gắng giữ ổn định: về tổ chức, sản lượng…

- Chuẩn hóa mọi thao tác và buộc mọi người tuân theo một cách nghiêmngặt.

- Không cho phép sự sai sót

2 Các bước trong mô hình truyền thống

 Phân tích yêu cầu:

Phân tích có nghĩa là phải xem xét xem ta đang phải đối mặt với vấn đề gì?Trước khi đi vào thiết kế ta phải phân tích vấn đề một cách rõ ràng Từ đó mớibiết ta thực sự hiểu về sản phẩm mà khách hàng yêu cầu hay chưa? Điều nàyliên quan đến khách hàng, người dùng cuối

 Thiết kế:

Trong pha thiết kế chúng ta hành động để giải quyết vấn đề hay nói cáchkhác chúng ta đưa ra những quyết định dựa trên kinh nghiệm, ước lượng haytrực giác Ta thiết kế và xem nó sẽ được triển khai như thế nào Thiết kế hệthống thường phân ra thành 1 hệ thống con logic (tiến trình) và hệ thống con vật

lý (máy tính, mạng) quyết định cách thức máy móc làm việc với nhau từ đó lựachọn công nghệ

 Đặc tả:

Pha đặc tả thường bị bỏ qua Thuật ngữ đặc tả được dùng theo nhiều cáchkhác nhau Ví dụ như đầu ra của pha yêu cầu là một đặc tả về hệ thống ta cần

làm, thuật ngữ đặc tả dùng để mô tả hành vi mong đợi của một thành phần trongchương trình Đặc tả có thể dùng trong trường hợp sau:

- Là cơ sở để kiểm tra thiết kế phần mềm trong thực thi hệ thống

- Văn bản là các thành phần phần mềm có thể cài đặt bởi bên thứ ba

- Để mô tả cách thức code hay sử dụng lại code trong các ứng dụng khác

có sự quay lui hay nhảy vượt giai đoạn Cụ thể, quá trình sẽ được thực hiện tuần

tự qua các giai đoạn: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử,liên kết và bảo trì Tức là mô hình này sẽ xem quá trình xây dựng một sản phẩm

phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thìchuyển đến giai đoạn sau Sau khi phân tích yêu cầu thì đặc tả yêu cầu, đưa chokhách hàng xem xét Nếu khách hàng chấp nhận thì sẽ tiến hành tuần tự một loạtcác giai đoạn như trên Chỉ đưa sản phẩm cho khách hàng khi đã hoàn thiện.

 Mô tả mô hình:

Hình 1: Mô hình thác nước

 Ưu điểm:

- Tài liệu đầy đủ lên dễ bảo trì

- Dễ phân công công việc, phân bố chi phí, giám sát công việc.

- Kiến trúc hàng đợi ổn định

 Nhược điểm:

- Đôi khi tài liệu đặc tả mang tính chất kĩ thuật lên làm khách hàng khó màhiểu hết được và do đó dễ dẫn đến hiểu sai yêu cầu khách hàng

- Mối quan hệ giữa các giai đoạn không được thể hiện

- Hệ thống phải được kết thúc ở từng giai đoạn do vậy khó mà thực hiện theothay đổi của khách hàng yêu cầu

Phân tích

yêu cầu

Thiết kế

Cài đặt và thử nghiệm đơn thểThử nghiệm tổng thể Bảo trì và phát triển

- Chỉ tiếp xúc với khách hàng ở pha đầu tiên nên phần mềm không đáp ứngnhu cầu khách hàng Hơn nữa làm tuần tự đến giai đoạn cuối hoàn thiện mới bàngiao sản phẩm cho khách hàng thì dễ tạo ra sản phẩm không phải cái khách hàngcần.

- Chi phí phát triển dự án lớn mà khả năng rủi ro cao

b Mô hình làm bản mẫu (Prototyping model)

 Ý tưởng:

Dựa vào những yêu cầu của khách hàng người phát triển phần mềm sẽxây dựng một mẫu thử ban đầu đưa cho người sử dụng xem xét, sau đó tinhchỉnh qua nhiều mẫu thử cho đến khi thỏa mãn yêu cầu người sử dụng thì dừnglại

Có 2 phương pháp với mô hình này:

- Phát triển thăm dò: Thực hiện với những yêu cầu rõ ràng và sau đó bổsung thêm những yêu cầu mới của khách hàng và dừng khi tất cả các yêu cầucủa khách hàng được thỏa mãn

- Loại bỏ mẫu thử: Thường sử dụng trong trường hợp yêu cầu không rõràng và ít thông tin Các mẫu thử sẽ được xây dựng và chuyển giao cho kháchhàng Từ đó ta sẽ biết được yêu cầu nào là cần thiết với người dùng Như vậyphương pháp này sẽ giúp sáng tỏ yêu cầu người dùng

Sử dụng phần mềm

Hệ thống thích hợp Chuyển

giao phần

Đ S

Hình 2: Mô hình làm bản mẫu

 Ưu điểm:

Thu được nhiều phiên bản hệ thống lên luôn đáp ứng nhu cầu khách hàng

 Nhược điểm:

- Thiếu tầm nhìn của cả quy trình

- Hệ thống thường có cấu trúc nghèo nàn

- Yêu cầu các kĩ năng đặc biệt (ví dụ: ngôn ngữ để tạo mẫu thử nhanhchóng)

- Chỉ nên áp dụng với hệ thống nhỏ hoặc vừa

c Mô hình xoắn ốc (The spiral model)

 Ý tưởng:

Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu vàđồng thời thêm một thành phần mới – phân tích rủi ro

Đầu tiên, nhóm phát triển sẽ thu thập nhu cầu khách hàng (những yêu cầu này

có thể đầy đủ hoặc còn mơ hồ) Sau đó, thực hiện một số phân tích để tăng hiểubiết về vấn đề được đặt ra ở pha xác định yêu cầu.Tiếp theo, phác thảo ra một hệthống phù hợp nhất với yêu cầu ban đầu Mặc dù những bước trước là chưahoàn chỉnh nhưng vẫn tiến hành viết code Khi đã hoàn thành code ban đầu tađưa cho khách hàng xem xét

Bằng cách đó thông qua mỗi chu trình chúng ta sẽ tăng thêm sự hiểu biết

về vấn đề nào đó và về các giải pháp đã được đề xuất Qua nhiều lần xoắn ốc,chúng ta có thể mổ xẻ yêu cầu và phân tích thiết kế một cách chính xác hơn đểđáp ứng với các yêu cầu nhiều hơn

Sau khi hệ thống hoàn thành, có lẽ qua 3 hoặc 4 lần xoắn ốc chúng ta cóthể thực hiện kiểm tra hệ thống một cách nghiêm ngặt

 Mô hình

Hình 3: Mô hình xoắn ốc

- Phân tích rủi ro làm tăng độ tin cậy dự án

- Cho phép thay đổi yêu cầu cho mỗi vòng xoắn

- Một rủi ro nào đó chưa được giải quyết, dự án sẽ chấm dứt

- Kiểm soát rủi ro ở từng giai đoạn phát triển

- Đánh giá chi phí chính xác hơn các phương pháp khác

 Nhược điểm:

- Phức tạp và không thích hợp với các dự án nhỏ, ít rủi ro

- Cần có kĩ năng tốt về phân tích rủi ro

Các bản mẫu tiếp theo

Tiếp tục phát triển hệ thống?

Phân tích rủi ro trên

cơ sở các yêu cầu ban đầu Phân tích rủi ro trên

cơ sở các phản ứng của khách hàng

- Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn.

- Đòi hỏi năng lực quản lí

d Mô hình đài phun nước (mô hình hướng đối tượng).

Ứng

trong tương lai

LTHĐ T

TKHĐ T

Hình 4:Mô hình đài phun nước

PHẦN II TÌM HIỂU QUY TRÌNH AGILE

I Sự ra đời của mô hình agile

1 Sự cần thiết của một mô hình phát triển phần mềm mới

Ngày nay, các phần mềm mà con người ra càng phức tạp Các thuật toánngày càng phức tạp khó xây dựng và quản lí Chính vì vậy, những nhà quản líphần mềm đã không ngừng học hỏi và tìm kiếm để tạo ra phương thức phát triểnphần mềm tốt hơn So với trước đây, con người đã không ngừng tạo ra nhữngchiế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 phải có những công cụ hỗ trợ và có những hiểu biếtsâu sắc hơn về lý thuyết phần mềm Máy tính đã làm thay đổi cả thế giới, thúcđẩy sự trao đổi thông tin và thay đổi một cách triệt để kỳ vọng của con người vềcách thức mà phần mềm làm việc

Chúng ta có rất nhiều phương pháp giúp xác định con đường phát triểnphần mềm ví dụ như một số quy trình:

dự án Nhưng vấn đề quan trọng nhất vẫn là “sự thay đổi yêu cầu người dùng”.Bởi vì một phần mềm tốt là phần mềm mà đem lại cho khách hàng sự hài lòng.Tuy vậy những phương pháp truyền thống đang hạn chế sự thay đổi yêu cầu từkhách hàng Điều này giúp duy trì kế hoạch dự án ban đầu nhưng không đem lại

sự thỏa mãn hoàn toàn cho khách hàng

Chính sự hạn chế từ những phương pháp truyền thống mà cần có mộtphương pháp hay quy trình phát triển phần mềm mới ra đời Và quy trình pháttriển phần mềm linh hoạt agile đã phần nào đáp ứng được yêu cầu ấy.

2 Agile là gì?

- Phương pháp phát triển phần mềm Agile (Agile development Method) rađời từ đầu những năm 90, với ý tưởng khắc phục những nhược điểm của môhình truyền thống cụ thể là mô hình thác nước Agile là tên gọi chung để chỉ cácphương pháp phát triển nhanh “Agile” có nghĩa là nhanh nhẹn, khéo léo tronghành động

-Agile software development (phương thức phát triển phần mềm linhhoạt) với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóatheo thời gian mà không cần phải làm lại từ đầu Phương thức này tập chung vàotính đơn giản: tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu củakhách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai

- Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triểnphần mềm trong những khung thời gian ngắn và sự cộng tác chặt chẽ với kháchhàng Mỗi bước lặp (iteration) giống như phát triển một phần mềm hoàn chỉnhcũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test, viết tài liệu Điểmnổi bật là khả năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu

- Điểm quan trọng làm lên sự khác biệt của Agile so với các mô hìnhtruyền thống đó là: các mô hình truyền thống là mô hình theo kế hoạch, còn môhình agile thì không nhất thiết phải tuân theo kế hoạch, nó có thể có những bướcđột phá để tạo ra một phần mềm hiệu quả nhất

II Tìm hiểu chung về agile

1 Tuyên ngôn agile

Tuyên ngôn Agile được viết như sau: “Chúng tôi tìm kiếm những phươngpháp tốt hơn để phát triển và giúp người khác phát triển phần mềm Qua hoạtđộng đó, chúng tôi sẽ trân trọng: cá nhân và sự tương tác hơn là quy trình và

công cụ; phần mềm hoạt động được hơn là việc thu thập tư liệu phát triển; hợptác với khách hàng hơn là thương thuyết về hợp đồng; phản ứng theo sự thay đổihơn là theo sát kế hoạch Nghĩa là, mặc dù có những giá trị cố hữu ở ‘cánh hữu’(truyền thống), nhưng chúng tôi trân trọng các giá trị ‘cánh tả’ (của đổi mới)nhiều hơn”.

- Cá nhân và tương tác hơn là quy trình và công cụ: Câu đầu tiên này cho

ta thấy không phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp chính lànằm bên trong của công việc Và đề tìm được giải pháp, thì không chỉ dựa vàocác lý thuyết mà phải trực tiếp làm công việc phát triển phần mềm Tất nhiênquy trình và công cụ cũng là điều quan trọng Sẽ không thể có một phần mềm tốtnếu như quy trình và công cụ không tốt Nhưng điều mà bản tuyên ngôn nhấnmạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũphát triển phần mềm Ý nghĩa quan trọng nhất của Agile là mọi người cùng làmviệc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn là tập trung theo sátmột quy trình hay công cụ nào đó

- Phần mềm hoạt động được hơn là việc thu thập tư liệu để phát triển:Điều này không có nghĩa là chúng ta không phải thu thập lại tư liệu để pháttriển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều hơn cho việc hoàntất công việc Bởi vì đối với một dự án muốn thành công thì phải thu thập tàiliệu đầy đủ Nhưng bản thân tài liệu cũng không thể giúp được gì nếu không cómột sản phẩm phần mềm thực sự Vì thế, việc tạo ra sản phẩm phần mềm quantrọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm mộtcách chính xác

- Hợp tác với khách hàng hơn là thương thuyết hợp đồng: Việc ký kết hợpđồng là quan trọng nhưng không đủ Một môi trường hợp tác tốt sẽ giúp chonhững người phát triển đưa ra giải pháp tốt nhất cho khách hàng Các hợp đồngđịnh nghĩa những điều khoản ràng buộc mà trong đó cả hai bên đối tác phải tuântheo, những người phát triển cần hợp tác với khách hàng để có thể hiểu rõ yêu

cầu cũng như những gì cần phải đưa ra Agile tập trung vào việc khuyến khíchkhách hàng cùng tham gia vào dự án hơn là chỉ viết hợp đồng để rồi khách hàng

sẽ chẳng làm gì với nhóm dự án phần mềm

- Phản ứng theo thay đổi hơn là theo sát kế hoạch: Việc lập kế hoạch chophát triển phần mềm là không thể thiếu Kế hoạch giúp công việc định hướng tốthơn Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nhất nhất tuân theo kế hoạch

sẽ dễ dẫn đến thất bại Do đó cần đáp ứng với thay đổi để có sự điều chỉnh saocho phù hợp Chính vì vậy, nhóm phát triển luôn sẵn lòng đón nhận thay đổi hơn

là chỉ làm theo kế hoạch dự án (có trước) vì thay đổi luôn diễn ra và cả kếhoạch dự án cũng sẽ thay đổi khi yêu cầu thay đổi

ưu tiên các yêu cầu mới về hệ thống,

và đánh giá hệ thống tại các lần lặp(iterations of the system)

Chuyển giao tăng dần

Phần mềm được phát triển một cáchtăng dần từng đợt (increment), trong đókhách hàng chỉ ra các yêu cầu cầnđược đưa vào mỗi đợt

Con người thay vì quy trình

Kĩ năng phát triển của đội cần được ghinhận và khai thác Các thành viên củađội cần được tự do phát triển cách làmviệc của riêng mình mà không cần đếncác quy trình quy phạm định trước.Chấp nhận thay đổi

Hiểu rằng hệ thống sẽ thay đổi nênthiết kế hệ thống sao cho nó có thể

chấp nhận được thay đổi đó.

Gìn giữ tính giản dị dễ hiểu

Chú trọng vào tính giản dị dễ hiểu củaphần mềm đang được phát triển cũngnhư của quy trình phát triển Chủ động

nỗ lực loại bỏ sự phức tạp ra khỏi hệthống bất cứ khi nào có thể

Cụ thể quy trình phát triển phần mềm theo hướng Agile có 12 nguyên tắc nhưsau:

- Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giaosản phẩm sớm và liên tục

- Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vàogiai đoạn cuối

- Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng Chu kì ngắn tốthơn chu kì dài

- Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùngnhau hàng ngày

- Tổ chức dự án xoay quanh những cá nhân tích cực Hỗ trợ và tin tưởnghọ

- Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp

- Các chức năng đã họat động là thước đo chính cho tiến độ dự án

- Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quảnlí…phải có khả năng tham gia dự án một cách liên tục

- Liên tục cải tiến chất lượng thiết kế và mã nguồn

- Tính đơn giản giữ vai trò cốt yếu Làm càng ít càng tốt

- Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc

tự chủ

- Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cảitiến hiệu quả công việc.

3 Đặc điểm của mô hình agile:

- Phát triển dựa trên quy trình phát triển lặp (interative development) Mỗi

dự án được chia thành nhiều mảng nhỏ dễ sử dụng và thay đổi khi khách hàngyêu cầu thay đổi Dự án này sẽ thực hiện từng phần nhỏ này như những dự ánnhỏ cho đến khi tất cả các yêu cầu của khách hàng được đáp ứng và dự án đượcbàn giao

- Cứ mỗi khi bàn giao các phần nhỏ được hoàn thành cho khách hàng,khách hàng có thể đưa ra các thay đổi hoặc yêu cầu mới cho dự án Theo đónhóm phát triển phần mềm sẽ cập nhập và sửa lại sản phẩm cho đúng yêu cầukhách hàng mà không cần làm lại từ đầu

- Từng phần nhỏ của dự án sẽ được test ngay trong quá trình làm dự ánbằng các Unit test tương ứng bởi chính các lập trình viên hay các tester độc lập.Quá trình test được thực hiện trong quá trình phát triển trước khi tích hợp phầnmềm

- Yêu cầu về việc gặp mặt trao đổi thông tin thường xuyên, cùng bàn bạc

và thống nhất để hoàn thành dự án đúng thời hạn vì trong phương pháp Agile,tại mỗi thời điểm thì cả nhóm phải cùng tập trung phát triển một mảng của dựán

- Vì các quá trình của Agile đều được thực hiện với nhân lực hoàn toàn làcác lập trình viên nhiều hơn và có kinh nghiệm trong lập trình và kiểm thử

III Quy trình thực hiện

Hình 5: Mô hình Agile tổng quát

1 Lập kế hoạch.

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên.Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành cácphần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng vàvạch ra lịch trình phát triển cho từng phần tăng trưởng Kế hoạch tổng thể

sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án Mỗi phần tăngtrưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp.Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc

2 Phân tích.

Agile không dành riêng một khoảng thời gian cố định ban đầu choviệc phân tích yêu cầu Trái lại, đại diện của khách hàng sẽ ngồi làm việcchung với đội dự án Người đại diện này không nhất thiết phải là khách hàngthật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm Khi cần thông tin,các lập trình viên chỉ việc đến trao đổi trực tiếp với người này Đối với nhữngyêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những

ví dụ chi tiết gọi là “customer test” Đối với các giao diện đồ họa, đại diện kháchhàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình Một

số dự án thuê người thiết kế giao diện riêng

3 Thiết kế và lập trình

Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục Hoạt độngnày được thực hiện nhờ phương pháp phát triển dựa trên test (test-drivendevelopment hay TDD) TDD gắn kết chặt chẽ các công việc thiết kế,lập trình và test Các lập trình viên phải làm việc theo cặp, một tronghai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kếcủa chương trình Các lập trình viên tích hợp code vài giờ một lần và đảm bảorằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay chokhách hàng Mã nguồn được coi là sở hữu tập thể Mọi người được yêu cầusửa lỗi bất kể lỗi đó do ai gây ra

4 Test.

Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chấtlượng sản phẩm Các lập trình viên thực hiện unit test và integration test Đạidiện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng cáccustomer test Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyênnhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn Tất cả cácregression test đều được thực hiện tự động (bởi code mới được tích hợpvào hệthống một cách liên tục) và được chạy bởi các lập trình viên khi

họ tích hợp code mới vào hệ thống Lập trình theo cặp góp phần làm tăngchất lượng công việc.

5 Bàn giao sản phẩm.

Phần mềm sẽ được trình chiếu hàng tuần và đưa cho khách hàngxem xét,góp ý Nếu không có thay đổi thì tiến hành thực hiện và cuốicùng khi sản phẩm hoàn thành thì bàn giao cho khách hàng

IV Những vấn đề cần xem xét để quyết định chọn phát triển theo hướng agile.

1 Cần trả lời những câu hỏi sau

- Hệ được phát triển thuộc loại nào?

- Hệ có khả năng bị kiểm duyệt từ bên ngoài?

- Vòng đời của hệ?

- Hệ được phát triển lớn hay nhỏ?

- Đội phát triển được tổ chức thế nào?

- Khả năng của người thiết kế và lập trình viên đến đâu?

- Có sẵn những công nghệ nào để hỗ trợ phát triển?

- Có cần phải đặc tả và thiết kế chi tiết trước khi cài đặt hay không?

- Chiến thuật bàn giao có tăng dần khả thi không?

- Có vấn đề văn hóa hay tổ chức nào có thể ảnh hưởng đến phát triển haykhông?

2 Điều kiện áp dụng quy trình agile.

Agile là một phương pháp tốt, tuy nhiên không phải trường hợp nào cũng

áp dụng được phương pháp này Trước khi quyết định áp dụng Agile cho dự áncủa mình, bạn phải trả lời được câu hỏi: đối với dự án này, điều kiện củacông ty như thế này thì liệu phương pháp Agile có giúp bạn thành công hơnkhi áp dụng các phương pháp khác hay không? Các dự án có đặc điểm sau đây

có thể phù hợp với Agile:

 Mức độ rủi ro thấp

Mức độ rủi ro của dự án có thể được hiểu là khả năng thực hiện vàmức độ thành công của dự án Dự án nào có tính khả thi thấp, tức làmức độ rủi ro cao thì không nên áp dụng mô hình này Bởi vì dự án theoagile sẽ tốn rất nhiều chi phí Ví dụ như khách hàng thường xuyên thay đổi yêucầu thì bên làm dự án sẽ phải thực hiện lại cho phù hợp yêu cầu Như vậy, nếunhư rủi ro cuối cùng dự án vẫn không thể hoàn thành thì rất tốn thời gian, côngsức và tiền bạc.

 Thành viên nhóm có kinh nghiệm

Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn, do đóphương pháp này đòi hỏi có những cá nhân tài năng, những người sẵnlòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm quanhiều công đoạn trong vòng đời truyền thống của sản phẩm.Phương pháp Agile cần có các cá nhân đa năng, có động lực, biết nghiêncứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết

để hiểu thấu các vấn đề của khách hàng Họ cũng phải là những người làmviệc nhóm có tính kỷ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đờisản phẩm đúng hạn thời gian cho phép Đặc biệt, họ phải có kĩ năng hoạt độngtheo nhóm tốt để thường xuyên trao đổi hợp tác với các thành viên trong nhóm

 Nhu cầu thay đổi thường xuyên

Khi thực hiện phương pháp này, các thành viên trong nhóm sẽ tiếpxúc thường xuyên với khách hàng, trao đổi thường xuyên để cùng hoàn thiện

dự án Nếu bên khách hàng có thay đổi yêu cầu, cả hai bên sẽ cùng ngồi vớinhau bàn bạc lại để tìm ra giải pháp tối ưu nhất Do vậy, đối với các dự án cótính ổn định cao, ít thay đổi thì áp dụng phương pháp này là không cần thiết

 Kích thước nhóm nhỏ, các thành viên làm việc cùng một địa điểm

Xuất phát từ yêu cầu trao đổi thông tin thường xuyên giữa cácthành viên trong nhóm, nên phương pháp Agile đòi hỏi nhóm không cần quánhiều thành viên, nếu quá nhiều thành viên sẽ làm cho sự quản lý nhóm,trao đổi giữa các thành viên trong nhóm trở nên không hiệu quả Mặt

khác, yêu cầu quan trọng nữa là các thành viên phải cùng làm việc tạicùng một địa điểm, khi đó sự trao đổi thông tin mới có hiệu quả hơn.

 Văn hóa công ty ưa thích sự “không trật tự”

Bởi vì có như thế các thành viên mới mạnh dạn đưa ra những chính kiếncủa mình trong quá trình làm việc nhóm Nhằm phát huy tính sáng tạo cao nhấtcủa các thành viên

Trái lại, những điều kiện sau đây là vật cản cho việc áp dụng Agile:

 Kích thước nhóm lớn

 Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource)

 Văn hóa làm việc theo mệnh lệnh

VI Ưu nhược điểm của phương pháp:

1 Ưu điểm:

- Agile là sự lựa chọn rất tốt cho các dự án nhỏ bởi dự án nhỏ thường cónhững yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên.Với phương pháp này bạn phải chia yêu cầu ra thành những nhiệm vụ nhỏ mà cóthể dễ dàng quản lý

- Với agile khách hàng có thể được xem trước dự án trong quá trình pháttriển vì Agile phát triển phần mềm theo hướng tăng dần và có thể đưa cho kháchhàng xem từng nhiệm vụ đã thực hiện Bằng việc đó sẽ không bị chậm và kháchhàng sẽ có sản phẩm sơ lược thay vì đợi đến khi dự án hoàn thành Chính vì vậy,nếu qua mỗi giai đoạn, mỗi nhiệm vụ của phát triển dự án mà có sai sót hay yêucầu thay đổi từ khách hàng chúng ta có thể dễ dàng sửa đổi

- Agile chia dự án ra thành những thành phần nhỏ và giao cho mỗi người.Hàng ngày mọi người đều phải ngồi họp với nhau trong một thời gian ngắn để