PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT AGILE

30 Theo mô tả của Beck’s 1999b, hình…, dự án phần mềm phát triển bằng phương pháp XP có những pha cơ bản sau:...33 i.Khảo sát Exploration phase...33 XP không dành riêng một khoảng thời

MỞ ĐẦU 3

CHƯƠNG I CƠ SỞ LÍ LUẬN CỦA ĐỀ TÀI 6

7

8

10

11

13

CHƯƠNG II PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT AGILE 16

CHƯƠNG III: LẬP TRÌNH CỰC HẠN – XP 30

Theo mô tả của Beck’s (1999b), hình…, dự án phần mềm phát triển bằng phương pháp XP có những pha cơ bản sau: 33

i.Khảo sát (Exploration phase) 33

XP không dành riêng một khoảng thời gian cố định ban đầu cho việc thu thập yêu cầu Đại diện khách hàng sẽ ngồi làm việc chung với đội dự án, người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ các yêu cầu của sản phẩm Người đại diện khách hàng sẽ viết ra các yêu cầu về sản phẩm vào “user stories” Mỗi “user stories” sẽ mô tả một đặc trưng của 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 công việc mà họ sẽ sử dụng trong dự án đó Đối với những yê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ách hàng cùng đội dự án sử dụng các công cụ để 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 33

ii.Lập kế hoạch 33

34

CHƯƠNG IV SỬ DỤNG PHƯƠNG PHÁP XP ĐỂ XÂY DỰNG PHẦN MỀM TẠO MÁY RÚT TIỀN TỰ ĐỘNG ATM 41

43

44

45

47

48

49

KẾT LUẬN VÀ KIẾN NGHỊ 51 TÀI LIỆU THAM KHẢO 53 PHỤ LỤC 54

MỞ ĐẦU

1 Tính cấp thiết của vấn đề nghiên cứu

Lịch sử phần mềm phát triển từ khoảng cuối thập niên 40 của thế kỷ trước, nhờ công nghệ thông tin con người tạo ra những phần mềm từ dạng bé nhất bằng cách đục lỗ, cho đến những phần mềm xử lý tính toán phức tạp với kích thước hàng triệu dòng code, tạo ra nhiều ứng dụng trong mọi mặt của đời sống kinh tế -

xã hội Cùng với sự phát triển như vũ bão của Công nghệ thông tin nói chung và ngành công nghệ phần mềm nói riêng, việc phát triển phần mềm ngành ngày nay được hỗ trợ bởi nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm nhanh chóng và hiệu quả hơn Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn

về thời gian và chi phí, cho dù các quy trình sản xuất phần mềm ngày càng chặt chẽ và khoa học cũng khó có thể đáp ứng yêu cầu ngày càng cao từ phía người sử dụng Chính vì thế, đặt ra một câu hỏi lớn: Có phương pháp phát triển phần mềm nào giải quyết được những hạn chế trên hay không?

Từ trước đến nay đã có nhiều phương pháp phát triển phần mềm được sử dụng Tuy nhiên, với các phương pháp truyền thống đòi hỏi trong quá trình tạo ra sản phẩm các yêu cầu ít thay đổi hoặc nếu chấp nhận thay đổi thường phải thiết kế lại toàn bộ cấu trúc phần mềm sao cho phù hợp Sự phát triển không ngừng của nền kinh tế - xã hội làm cho các phương pháp phát triển phần mềm truyền thống không thể đáp ứng được yêu cầu tạo ra phần mềm như khách hàng mong muốn Vì vậy nó không phù hợp và không còn được sử dụng rộng rãi

Để khắc phục những hạn chế này, hiện nay các nhà phát triển phần mềm đã tìm đến phương pháp phát triển phần mềm mới, cho phép các phần mềm có khả năng biến đổi, sửa chữa ngay cả khi dự án đã bắt đầu Đó là phương pháp phát triển phần mềm linh hoạt Agile

Tuy nhiên, phương pháp này chưa thật sự được biết đến rộng rãi trên toàn thế giới Một số nhà lập trình chưa hiểu hết hoặc hiểu sai vì thế chưa vận dụng được phương pháp này trong việc tạo ra các phần mềm.

Trước thực tế trên đã thôi thúc tôi chọn đề tài: "Tìm hiểu phương pháp

phát triển phần mềm linh hoạt Agile” nhằm giúp mọi người nói chung và các

nhà lập trình nói riêng hiểu đúng và vận dụng tốt phương pháp này để tạo ra các phần mềm một cách nhanh chóng và hiệu quả

2 Mục đích nghiên cứu

Trên cơ sở tìm hiểu phương pháp phát triển phần mềm linh hoạt Agile, từ đó đưa ra các giải pháp giúp các nhà lập trình biết cách vận dụng nó để tạo ra các phần mềm có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ đầu Hay nói cách khác tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai

3 Khách thể và đối tượng nghiên cứu

3.1 Đố ượ i t ng nghiên c u ứ

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

3.2 Khách th nghiên c u ể ứ

Công nghệ phần mềm

4 Nhiệm vụ nghiên cứu

4.1 Nghiên cứu các vấn đề lý luận làm cơ sở cho đề tài

4.2 Tìm hiểu phương pháp phát triển phần mềm linh hoạt Agile

4.3 Đề xuất giải pháp để đưa phương pháp phát triển phần mềm linh hoạt Agile thực sự được áp dụng rộng rãi trong việc tạo ra các phần mềm

5 Giả thuyết khoa học

Sự hiểu biết cũng như cách vận dụng phương pháp phát triển phần mềm linh hoạt Agile trong việc tạo ra các sản phẩm phần mềm hiện nay còn nhiều hạn chế

Chính vì vậy, nếu hiểu đúng và áp dụng tốt thì phương pháp này chính là chìa khóa thành công giúp các nhà lập trình hoàn thành nhiệm vụ một cách nhanh chóng và hiệu quả nhất.

6 Các phương pháp nghiên cứu

6.1 Phương pháp nghiên cứu tài liệu

6.2 Phương pháp điều tra

6.3 Phương pháp quan sát

6.4 Phương pháp phỏng vấn

6.5 Phương pháp thống kê toán học

CHƯƠNG I CƠ SỞ LÍ LUẬN CỦA ĐỀ TÀI 1.1 Vài nét về lịch sử vấn đề nghiên cứu.

1.1.1 n Ở ướ c ngoài.

Agile không bắt nguồn từ phần mềm – nó bắt đầu sản xuất vào những năm

1950 (đọc lên trên WE Deming) Agile là lý do mà người Nhật làm cho những chiếc xe chất lượng cao giá cả phải chăng Agile là làm thế nào các công ty Nhật Bản lớn như Honda và Toyota có thể nhanh chóng quy mô xuống và đối phó với khủng hoảng tín dụng hiện hành[1]

Phương pháp phát triển phần mềm linh hoạt được đưa ra vào đầu 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 - Agile”[2]

1.1.2 Vi t Nam Ở ệ

Trước năm 2011, Agile ở Việt Nam chưa được quan tâm nhiều Các công ty khó tìm kiếm các chuyên gia am hiểu Agile để phát triển các sản phẩm của riêng

họ, hoặc đáp ứng yêu cầu của khách hàng về mặt phương pháp luận

Tính đến thời điểm hiện tại, Agile mới chỉ xuất hiện trong một cộng đồng hẹp dân CNTT tại Việt Nam và hiện vẫn còn là một “ẩn số” với đại đa số giới CNTT trong nước Một số công ty phần mềm sử dụng phương pháp này như công

ty Swiss IT bridge, Công ty TNHH Phần mềm FPT (FPT Software), …

1.2 Lịch sử các phương pháp phát triển phần mềm.

1.2.1 Mô hình thác n ướ c (Waterfall)

Mô hình thác nước ra đời vào những năm 1970, là một mô hình cổ điển và được áp dụng trong quy trình phát triển phần mềm tại phần lớn các công ty Mô hình này là một chuỗi quy trình phát triển như một luồng đều đặn từ trên xuống hoạt động như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì

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

Các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành Sản phẩm đầu ra của giai đoạn trước sẽ trở thành đầu vào của giai đoạn sau

Ưu điểm:

Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng Mô hình này

cơ bản dựa trên tài liệu Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo trình tự rõ ràng Dễ quản lý

Nhược điểm:

Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự

án

Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử

Quá cứng nhắc và thiếu thực tế, bởi việc thay đổi ở bất kỳ phần nào của quy trình cũng là không thể vì việc làm lại các giai đoạn ban đầu thường mất rất nhiều công sức và phá vỡ cấu trúc phần mềm, chi phí để sửa chữa có thể rất cao

Mô hình làm bản mẫu thực hiện các bước như sau:

B1: Xác định các yêu cầu của người sử dụng

Chuyên viên phân tích thiết kế hệ thống làm việc với người sử dụng để nắm được thông tin cơ bản cần cho việc tạo ra bản mẫu.

B2: Phát triển bản mẫu đầu tiên

Người thiết kế tạo nhanh một bản mẫu bằng cách sử dụng một công cụ phát triển phần mềm thích hợp

B3: Sử dụng bản mẫu làm việc với người sử dụng

Bản mẫu được sử dụng để trình diễn hay cho người sử dụng thử nghiệm Người sử dụng biết được bản mẫu đáp ứng yêu cầu của họ như thế nào và đưa ra

đề nghị để bổ sung và cải tiến

B4: Hoàn thiện và tăng cường bản mẫu

Người thiết kế phải thay đổi bản mẫu để đáp ứng đòi hỏi của người sử dụng

và làm mịn hơn bản mẫu một cách phù hợp trên cơ sở sử dụng các thông tin khác.Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu được "vi chỉnh" thoả mãn nhu cầu của khách hàng trong khi đồng thời lại làm cho người phát triển hiểu được kĩ hơn cần phải thực hiện nhu cầu nào

Hệ thống có rủi ro cao: Yêu cầu chưa chắc chắn, giao diện chưa rõ

Khách hàng, nhất là người sử dụng cuối không thể xác định rõ ràng yêu cầu

1.2.3 Mô hình xo n c ắ ố

Mô hình xoắn ốc (spiral model) được Berry Boehm đưa ra năm 1988 Nó dựa trên ý tưởng là tối thiểu hóa rủi ro, bằng viêc phân tích yếu tố rủi ro ở mỗi bước lặp và sử dụng phương pháp làm bản mẫu Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi

ro, rồi tạo bản mẫu, hoàn thiện và phát triển hệ thống, duyệt lại, và cứ thế tiếp tục Nội dung gồm 4 hoạt động chính:

Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc

Phân tích rủi ro: phân tích các phương án, xác định và giải quyết rủi ro

Kỹ nghệ: phát triển sản phẩm “mức tiếp theo”

Đánh giá của khách hàng: khẳng định kết quả của kỹ nghệ

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

Với mỗi lần lặp vòng xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn thiện dần Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiến hành tiếp hay dừng” Nếu rủi ro quá lớn, thì có thể đình chỉ dự án hay thay đổi yêu cầu đặt ra cho thích hợp

Ưu điểm:

Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi

“spiral” để tăng mức độ tin cậy của dự án

Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”

Nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng

Thích hợp để phát triển các hệ thống quy mô lớn

Nhược điểm:

Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro

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

Quy mô dự án phải đủ lớn để trả chi phí cho chuyên gia phân tích rủi ro

Điều kiện áp dụng:

Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợquyết định

Đội ngũ thực hiện dự án có khả năng phân tích rủi ro

1.2.4 Mô hình ch V ữ

Hình 4: Mô hình chữ V

Mô hình chữ V giống hệt mô hình thác nước, pha sau được thực hiện khi pha trước thực hiện xong Điều mấu chốt là phần coding nằm ở dưới đáy chữ V và đi ngược lại lên trên Điểm đặc biệt là kết hợp giữa kiểm thử và các pha trước nó Có thể coi đây là mô hình mở rộng của mô hình thác nước.

Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và kiểm thử Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng

Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển

Ưu điểm:

Mô hình này khuyến khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực

1.2.5 Mô hình hi n đ i 4GT ệ ạ

Mô hình 4GT đối với công nghệ phần mềm tập trung vào khả năng xác định phần mềm bằng việc dùng các khuôn mẫu ngôn ngữ đặc biệt hay kí pháp đồ họa vốn mô tả cho vấn đề cần được giải quyết dưới dạng khách hàng có thể hiểu được

Hình 5: Mô hình 4GT

Mô hình 4GT bắt đầu từ bước thu thập yêu cầu Một cách lý tưởng, khách hàng sẽ mô tả các yêu cầu và các yêu cầu đó sẽ được dịch trực tiếp thành một bản mẫu vận hành được Nhưng điều này không thực hiện được Khách hàng có thể không chắc chắn mình cần gì, có thể có sự mơ hồ trong việc xác định các sự kiện

đã biết, có thể không có khả năng hay không sẵn lòng xác định thông tin theo cách thức mà công cụ 4GT có thể giải quyết được Bởi lí do này, đối thoại khách hàng/ người phát triển được mô tả cho các mô hình tiến trình khác vẫn còn là phần bản chất của cách tiếp cận 4GT

Ngày nay môi trường 4GT đã được mở rộng để đề cập tới hầu hết các loại ứng dụng phần mềm Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt bằng công cụ 4GT hay một mô hình bao gồm một mạng các biểu tượng đồ hoạ

Để biến đổi một cài đặt 4GT thành một sản phẩm, người phát triển phải tiến hành việc kiểm thử toàn diện, xây dựng các tài liệu có ý nghĩa và thực hiện mọi hoạt động tích hợp giải pháp khác vốn cần tới trong các mô hình kĩ nghệ phần mềm khác Bên cạnh đó, phần mềm được phát triển theo 4GT phải được xây dựng theo cách làm cho việc bảo trì có thể được tiến hành một cách chóng vánh

Ưu điểm:

Làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu suất của người xây dựng phần mềm

Nhược điểm:

Có những công cụ 4GT hiện tại khó dùng hơn các ngôn ngữ lập trình

Chương trình gốc do các công cụ 4GT tạo ra là "không hiệu quả," và tính bảo trì cho các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT vẫn còn là vấn đề mở

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

Được ra đời vào đầu những năm 90 Là phương pháp phát triển phần mềm chú trọng vào sự tiến hóa, phát triển của nó theo thời gian (xây dựng bồi đắp thêm,

mở rộng thêm) với sự kế thừa tối đa, hiệu chỉnh lại cho phù hợp và tránh phải bắt đầu làm một thành phần nào đó lại từ đầu

Agile là một triết lý cho việc phát triển phần mềm Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm Các triết lý của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm, chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là phương pháp Agile

1.3 Kết luận lịch sử các phương pháp phát triển phần mềm

Lịch sử phần mềm đã trải qua nhiều phương pháp phát triển, mỗi phương pháp đều có ưu và nhược điểm nhất định tuy nhiên phương pháp sau bao giờ cũng

kế thừa nhiều nhất những ưu điểm và cố gắng khắc phục những hạn chế của phương pháp trước Trong khi đưa ra yêu cầu, có thể khách hàng không thể lường

trước được mọi tình huống mà nó sẽ tự phát sinh trong quá trình tạo ra sản phẩm Với các phương pháp truyền thống, tiêu biểu là mô hình thác nước lại ngăn chặn

sự thay đổi này vì nó phá vỡ cấu trúc phần mềm đã được tạo ra Trong khi đó phương pháp phát triển phần mềm phương pháp Agile khuyến khích sự thay đổi từ phía khách hàng, mặt khác trong một thời gian ngắn lại đưa ra được sản phẩm cho người sử dụng Vì vậy, với xu thế phát triển hiện nay, phương pháp Agile là một lực chọn đúng đắn cho các nhà phát triển phần mềm

CHƯƠNG II PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH

HOẠT AGILE 2.1 Tổng quan về phương pháp Agile.

Trong Agile, việc giao tiếp giữa các thành phần tham gia dự án được coi trong hơn là việc viết tài liệu dự án… Nhất là giao tiếp giữa đội phát triển dự án với khách hàng

Vào tháng 12 năm 2001, 17 nhà phát triển phần mềm[3] đã gặp gỡ nhau ở Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn nhẹ và linh hoạt Họ đã cùng nhau công bố "Tuyên ngôn phát triển phần mềm linh hoạt" ("Manifesto for Agile Software Development" - gọi tắt là "Tuyên ngôn Agile") để định nghĩa cách hiểu về phương pháp phát triển phần mềm linh hoạt[4]

a) Tuyên ngôn 4 điểm của Agile:

“Chúng tôi đang khám phá những phương pháp tốt hơn để phát triển phần mềm bằng cách tự tay phát triển và giúp những người khác làm việc đó Qua công việc này chúng tôi thống nhất đánh giá cao và nhấn mạnh các điểm sau:

• Vai trò các cá nhân và sự tương tác hơn là qui trình và công cụ

[Coi trọng vai trò cá nhân và sự tương tác hơn là qui trình và công cụ] …phía sau các mệnh đề khác cũng viết lại theo kiểu này cho cô…Coi trọng … Hơn là…

• Phần mềm hoạt động được hơn là các tài liệu đầy đủ

[Coi trọng khả năng hoạt động của phần mềm hơn là…]

• Cộng tác của khách hàng hơn là việc thương lượng hợp đồng

• Đáp ứng các thay đổi hơn là tuân thủ kế hoạch

[Coi trọng việc đáp ứng các thay đổi yêu cầu hơn là…]

Điều này có nghĩa là, mặc dù những điểm nằm ở vế phải có giá trị, nhưng chúng tôi đánh giá cao vế bên trái hơn.”

Thứ nhất: Trong phương pháp Agile các thành viên tham gia dự án chia sẻ

thông tin chứ không chú trọng một quy trình hay công cụ nào đó

Thứ hai: Mục tiêu chính là hoàn tất phần mềm, không quá chú ý đến việc

thu thập thông tin tổng thể; nghĩa là ít nhấn mạnh việc thu thập tư liệu và tập trung nhiều hơn cho việc hoàn tất công việc

Thứ ba: Agile tập trung vào việc khuyến khích khách hàng cùng tham gia

vào dự án tránh việc viết hợp đồng xong khách hàng không tham gia đóng góp cho

dự án

Thứ tư: Nhóm phát triển luôn sẵn lòng đón nhận thay đổi; không quá rập

khuôn 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.[5]

b) Các nguyên lý phía sau tuyên ngôn Agile: [6]

- Ư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 giao sả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ào giai đ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ì càng ngắn càng tốt

- 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ùng nhau 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ưởng họ

- 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 đã hoạt động là thước đo chính cho tiến độ dự án

- Lập trình viên, người dùng, nhà quản lí…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

- Những yêu cầu và thiết kế tốt nhất được xuất phát 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ải tiến hiệu quả công việc

2.1.2 T m quan tr ng c a ph ầ ọ ủ ươ ng pháp Agile.

Một dự án phần mềm thành công là khi phần mềm giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng Tuy nhiên trên thực tế

có nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng

Ngoài các yếu tố trên, một dự án phần mềm chỉ được coi là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà nhóm mang lại cho công ty Các phương pháp Agile giúp cho dự án phần mềm đạt được ba thành công này

Cụ thể:

a) Thành công ở mức công ty.

Agile tạo ra giá trị cho công ty trong khi làm giảm chi phí Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển Nhờ đó,

những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty.

Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với đội dự án Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể Các phiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào

Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm Chất lượng mã nguồn được cải tiến liên tục Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên

b) Thành công về mặt kĩ thuật.

Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới của phần mềm được “ra lò” Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năng trước khi chuyển sang chức năng tiếp theo Bởi vậy, tiến độ công việc được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay đổi từ phía khách hàng

Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các thiết kế và các đọan mã tốt Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử” (test-driven development) trợ giúp lập trình viên viết các chương trình thực hiện đúng chức năng mong muốn

c) Thành công về mặt cá nhân

Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản thân Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng cao, chẳng hạn trong việc ước lượng và lập kế hoạch Quyền tự chủ của đội dự án cũng được tăng cường Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm được các công việc lặp lại một cách nhàm chán Nhà

quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng.

Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều kiển được hướng đi của dự án và các ý kiến được lắng nghe

Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty

2.1.3 Cách áp d ng ph ụ ươ ng pháp Agile.

Khi phát triển phần mềm, tùy vào đặc trưng của từng dự án có thể lựa chọn các phương pháp, quy trình cho phù hợp Cũng giống các phương pháp đã biết, Agile không phù hợp với mọi loại hình dự án, đặc biệt là các dự án nhằm mục tiêu tăng năng suất lao động của các thành viên Theo tài liệu….Agile có thể phù hợp với các dự án có đặc điểm sau đây:

Không phải dự án nào cũng nên áp dụng Agile Nếu mục tiêu của bạn là tăng năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile có thể không phù hợp bởi các quy tắc của nó không nhằm tăng năng suất của đội dự án Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: liệu Agile có giúp bạn thành công hơn 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

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

• Yêu cầu thay đổi thường xuyên

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

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

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 (hơn 20 thành viên bao gồm lập trình viên, tester,

…)

• 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 công ty làm việc theo mệnh lệnh

2.2 Quy trình thực hiện trong phương pháp Agile

2.2.1 L p k ho ch (planning) ậ ế ạ

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ác phầ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 tiến triển của dự án

Mỗi phần tăng trưở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.2.2 Phân tích yêu c u (requirements analysis) ầ

Agile không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu Đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án Người đại diện này không nhất thiết phải là khách hàng thậ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ững yê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ách hà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 Có một số dự án lại thuê người thiết kế giao diện riêng

2.2.3 Thi t k và l p trình (design) ế ế ậ

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 động này được thực hiện nhờ phương pháp phát triển dựa trên kiểm thử (test-driven development hay TDD) TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và kiểm thử Các lập trình viên phải làm việc theo cặp, một trong hai 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 mã nguồn (code) vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng Mã nguồn được coi là sở hữu tập thể Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do

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ăng chất lượng công việc

- Đều cho phép thực hiện phân khu, cụ thể trong phương pháp truyền thống việc phân khu được thực hiện vào mỗi giai đoạn Đối với phương pháp Agile, mỗi module đã được mã hóa đều có thể được phân bổ cho những nhóm lập trình khác nhau Điều này cho phép nhiều phần trong dự án được hoàn thành cùng lúc thế nên việc phân khu được sử dụng hiệu quả hơn trong phương pháp Agile.

2.3.2 Khác nhau.

Tiêu chí Phương pháp phát triển truyền

thống

Phương pháp phát triển Agile

- Nhấn mạnh kết quả mà không phải

là những hoạt động tạo ra kết quả đó

- Không nhấn mạnh việc gặp mặt trao

đổi hàng ngày

- Nhấn mạnh việc làm hàng ngày

- Nhấn mạnh việc gặp mặt trao đổi hàng ngày

Tiêu chí

thành

công.

Sản phẩm giao đúng hạn, trong ngân

sách cho phép và làm đúng yêu cầu

của khách hàng

Sản phẩm thỏa mãn 3 tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty

Xử lý khi

có yêu

cầu mới

Phần lớn phải viết lại code Chỉnh sửa lại code, mở rộng tính

năng mà không phải code lại từ đầu

Về rủi ro Kiểm thử được thực hiện 1 lần vào

cuối mỗi dự án Nếu dự án phát sinh

lỗi, hoặc có sự thay đổi về yêu cầu

của người sử dụng thì chi phí để sửa

lỗi và đáp ứng yêu cầu mới rất lớn

Kiểm thử được thực hiện một cách thường xuyên vì cuối mỗi giai đoạn thử nghiệm đều có thể đưa ra kết quả Giảm thiểu tối đa rủi ro, tiết kiệm được thời gian cũng như chi phí sửa lỗi

- Lập trình Cực hạn (eXtreme Programming - XP): Phương pháp này đặt

nặng về yếu tố thích nghi - tương thích, và thường hữu ích đối với các dự án chưa xác định được mong muốn của sản phẩm cuối cùng

- Scrum (Phương pháp phát triển trong Hỗn độn): Phương pháp này

nhấn mạnh sự lặp lại của việc kiểm các chức năng sản phẩm và phát triển tịnh tiến

vì các yêu cầu của sản phẩm luôn thay đổi

2.4.1 C th các ph ụ ể ươ ng pháp phát tri n Agile ể

2.4.1.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, được Kent Beck mô tả bằng các tài liệu có liên quan do Martin Flower và Ron Jeffries đề xướng[7], phương pháp này 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 trong quá trình thực hiện Nó được cô đọng trong bốn nguyên tắc: sự trao đổi (communication), đơn giản hóa (simplicity), sự phản hồi (feedback), và sự dũng cảm (courage)[8]

Đối với các dự án khách hàng thường xuyên thay đổi các yêu cầu và mong muốn sớm nhận được sản phẩm từ ngời phát triển thì XP có vẻ phù hợp

Nếu bạn làm việc với những dự án khách hàng thường xuyên thay đổi yêu cầu và mong muốn sớm nhận được sản phẩm thì nên xem xét XP Phương pháp

XP khuyến khích các nhóm làm việc với nhau; bàn giao các phiên bản phần mềm chất lượng cao hơn các phiên bản phương pháp truyền thống

XP bao gồm một tập hợp các quy tắc và công việc giúp người lập trình mô tả chi tiết các hoạt động 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)[9]

2.4.1.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[10]

Kent Schwaber lần đầu tiên mô tả về phương pháp Scrum vào năm 1996, là một quá trình chấp nhận và phát triển các yêu cầu chưa được xác định trước[11].Nguyên tắc của phương pháp Scrum là phát triển một phần mềm bằng việc gia tăng dần các yêu cầu phát triển Với việc bàn giao thường xuyên (thông thường

4 tuần) khách hàng sẽ nhận được phần mềm với nhiều tính năng và hoạt động tốt hơn Phương pháp Scrum dựa trên việc phát triển các yêu cầu với tốc độ không đổi trong khoảng từ 2 đến 4 tuần

a) Các thành viên trong Scrum [12]

- Product owner: Chủ sở hữu sản phẩm là người chịu trách nhiệm cho dự

án, quản lý, kiểm soát và thống kê các yêu cầu chưa được thực hiện của cầu sản phẩm Product owner được lựa chọn bởi các ScrumMaster, Customer và managent

- ScrumMaster: Người lãnh đạo nhóm là người hỗ trợ đắc lực cho dự án,

làm việc chặt chẽ với người chủ sở hữu sản phẩm Kiểm tra công việc của các thành viên đảm bảo đội hoạt động và có năng suất hiệu quả với Scrum

- ScrumTeam: Quy mô từ 4 đến 10 người, đội sản xuất tập trung các thành

viên có kinh nghiệm và có vai trò cần thiết trong một dự án Có quyền quyết định những hoạt động cần thiết để đạt được mục tiêu Sprint

- Customer: Tham gia vào các nhiệm vụ liên quan đến công việc chưa được

thực hiện để sản phẩm phát triển và nâng cao hơn

- Management: Quyết định kết quả cuối cùng Tham gia vào việc thiết lập

các yêu cầu

b) Các hình th c h p bàn trong Scrum ứ ọ [13]

- Sprint Planning (Lập kế hoach cho Sprint):

Đội sản xuất sẽ gặp gỡ với chủ sở hữu sản phẩm, người quản lí, khách hàng

để lên kế hoạch làm việc cho một Sprint Các công việc như là: chọn lựa các yêu cầu cần phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các công việc Scrum sử dụng phương thức lập kế hoạch từng phần và tăng dần theo thời gian Theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại

- Daily Scrum (Buổi họp hằng ngày):

Mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay

và kiểm tra các tình huống có thể cản trở công việc trong ngày hôm nay

- Sprint Review (Buổi họp đánh giá):

Cuối Sprint, đội sản xuất cùng với Product Owner sẽ rà soát lại các công việc

đã hoàn thành trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm

- Sprint Retrospective (Buổi họp cải tiến):

Dưới sự chỉ đạo của Scrum Master, Đội sản xuất sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như sản phẩm

c) Cách th c cài đ t đ s d ng Scrum ứ ặ ể ử ụ [14]

Bước 1: Thu nhập các đặc điểm của sản phẩm (product backlog) trong đơn

đặt hàng Đây là bước quan trọng nhất Lập nên các đội làm việc, có thể tách thành các đội nếu cần thiết và thảo luận với nhau về nghiệp vụ cần làm Sau đó bổ nhiệm

một người vào vị trí Product owner, người này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp ưu tiên đúng thứ tự các nhiệm vụ Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ưu tiên.

Bước 2: Ước lượng các yêu cầu về sản phẩm đầu ra Có ước lượng ở mức

độ cao, chia sản phẩm thành số lượng các danh mục backlog Tuy nhiên số lượng

sẽ không chính xác được, về sau chúng sẽ được bổ sung Tiếp đến là ước lượng chi tiết từng backlog, ước lượng số lượng các đội làm việc

Bước 3: Lên kế hoạch phát triển các vòng lặp sprint Sử dụng các cuộc trao

đổi kế hoạch phát triển sprint với tất cả các thành viên Xác định khoảng thời gian

sẽ phát triển một sprint (thường là 30 ngày), mục tiêu của sprint là gì, sẽ đạt được

gì, phân tích các yêu cầu của sprint một cách rõ ràng

Bước 4: Lên kế hoạch phát triển các nhiệm vụ của sprint Tất cả mọi người

sẽ xác định ngân sách của sprint đó, chia các đặc điểm thành các tác vụ nhỏ hơn, ước lượng số thời gian sẽ làm từng task (giờ), hoàn tất các yêu cầu và nhận dạng task quan trọng

Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người Thường

sử dụng bảng trắng để vẽ nên những vấn đề cần thiết cho tất cả mọi người cùng đánh giá

Bước 6: Các thành viên bắt tay xây dựng từng sprint Lập trình, kiểm thử và

điều chỉnh thời gian để có hiệu quả tốt nhất Đôi khi có thể hủy bỏ một sprint và quay lại với việc lập kế hoạch khác

Bước 7: Mọi người báo cáo kết quả để tiếp tục làm việc Các báo cáo tập

trung vào các vấn đề: đạt được những gì so với lần trao đổi trước; sẽ hoàn thành những gì trong lần trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc

Bước 8: Tổng hợp kết quả trên biểu đồ Đây là bức tranh tổng quát về những

việc đã làm được, những việc chưa làm được, thời gian ước lượng còn lại và có thể điều chỉnh lại