Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm

T M TẮT

Ngày nay, khách hàng đang yêu cầu những phần mềm đòi hỏi cập nhật thường xuyên hay sửa lỗi

trong thời gian ngắn, những mô hình phát triển phần mềm cổ điển không phù hợp để đáp ứng

những nhu cầu này, vì thế Agile đang dần trở nên thịnh hành và phổ biến hơn, ở Việt Nam cũng

không ngoại lệ, mô hình Agile đang ngày một phát triển và các công ty phần mềm đang ngày

càng chú ý đến Agile. Bài báo này đề cập những phương pháp Agile được sử dụng nhiều nhất, ích

lợi của việc sử dụng Agile, lợi thế của Agile trước Waterfall và đánh giá lợi ích thực tế của việc áp

dụng Agile thông qua hai trường hợp Zonmob và Cisco

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 1

Trang 1

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 2

Trang 2

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 3

Trang 3

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 4

Trang 4

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 5

Trang 5

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 6

Trang 6

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm trang 7

Trang 7

pdf 7 trang xuanhieu 9000
Bạn đang xem tài liệu "Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm

Phân tích định tính việc áp dụng mô hình Agile vào quy trình phát triển phần mềm
944 
PHÂN TÍCH ĐỊNH TÍNH VIỆC ÁP DỤNG MÔ HÌNH AGILE 
VÀO QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 
Trần Nguyễn Quốc Khang 
Viện Đào tạo Quốc tế, Trường Đại học Công nghệ TP.Hồ Chí Minh 
GVHD: TS. Lê Thị Ngọc Thơ 
T M TẮT 
Ngày nay, khách hàng đang yêu cầu những phần mềm đòi hỏi cập nhật thường xuyên hay sửa lỗi 
trong thời gian ngắn, những mô hình phát triển phần mềm cổ điển không phù hợp để đáp ứng 
những nhu cầu này, vì thế Agile đang dần trở nên thịnh hành và phổ biến hơn, ở Việt Nam cũng 
không ngoại lệ, mô hình Agile đang ngày một phát triển và các công ty phần mềm đang ngày 
càng chú ý đến Agile. Bài báo này đề cập những phương pháp Agile được sử dụng nhiều nhất, ích 
lợi của việc sử dụng Agile, lợi thế của Agile trước Waterfall và đánh giá lợi ích thực tế của việc áp 
dụng Agile thông qua hai trường hợp Zonmob và Cisco. 
Từ khóa Agile, Scaling Agile, Quy trình phát triển phần mềm, Scrum, Scaled Agile Framework. 
1 GIỚI THIỆU MÔ HÌNH AGILE 
1.1 Tổng quan về m hình Agile 
Agile là một thuật ngữ chung cho một số phương pháp tiếp cận phát triển phần mềm theo cách lặp 
và tăng dần, với mỗi biến thể đó gọi là Agile framework hay Agile methodology. Lúc đầu, các Agile 
framework phổ biến bao gồm Scrum, Crystal, Phương thức phát triển hệ thống động và Phát triển 
dựa trên tính năng (Feature-Driven Development), sau này, Scrum, Kanban và các phương pháp 
hỗn hợp khác chiếm ưu thế. Trong đó, framework phổ biến và được ứng dụng nhiều nhất vẫn là 
Scrum. [1] 
Hình 1: Những phương pháp Agile được sử dụng[2] 
945 
Mặc dù mỗi loại phương pháp Agile có những tính chất độc đáo riêng, tất cả chúng đều kết hợp 
các yếu tố phát triển lặp và thu thập phản hồi liên tục khi tạo một ứng dụng. Bất kỳ dự án phát triển 
Agile nào cũng bao gồm lập kế hoạch liên tục, thử nghiệm liên tục, tích hợp liên tục và các hình 
thức phát triển liên tục khác của cả dự án và ứng dụng do Agile framework làm ra. 
Mỗi Agile framework có tính linh động cao. Các quy tắc và thông lệ được giữ ở mức tối thiểu và 
được thiết kế để có thể thích ứng với mọi loại hoàn cảnh. Thay vào đó, trọng tâm rơi vào việc trao 
quyền cho các nhà phát triển đủ loại để hợp tác và đưa ra quyết định cùng nhau như một nhóm 
một cách nhanh chóng và hiệu quả. Mấu chốt phương pháp phát triển Agile là tạo ra các ứng 
dụng theo từng bước nhỏ, kiểm tra từng mức tăng trưởng riêng lẻ trước khi hoàn thành. Quá trình 
này đảm bảo chất lượng được đưa vào trong sản phẩm, so với việc kiểm tra chất lượng sau này. [3] 
1.2 Agile mở rộng (Scaling Agile) 
Khi áp dụng Agile, khó khăn lớn nhất là áp dụng nó cho nhiều team khác nhau trong một tổ chức 
lớn. Scaling Agile là một tập hợp những phương pháp Agile mở rộng dùng cho những công ty và 
tập đoàn lớn, trong đó, Scaled Agile Framework (SAFe) là phương pháp Scaling Agile được sử dụng 
nhiều nhất (30%).[2] 
Hình 2: Những phương pháp Scaling Agile được sử dụng [2] 
1.3 Những t nh chất của Agile 
Tính mô đun: Tính mô đun cho phép Agile chia thành các thành phần và ưu tiên thực hiện các phần 
quan trọng.[4] 
Lặp lại: Agile tập trung vào các chu trình ngắn và lặp đi lặp lại nhằm cái tiến sản phẩm từng bước 
đến sự hoàn hảo. [4] 
Giới hạn thời gian: Mỗi chu kỳ của Agile có thể có giới hạn từ 1 đến 6 tuần. [4] 
Tiết kiệm: Với mỗi chu kỳ, chỉ đặt ra những mục tiêu tối thiểu nhằm vừa hoàn thành sản phẩm đúng 
hạn vừa giúp developer có thời gian nghỉ. [4] 
Thích nghi: Agile giúp dễ dàng phát hiện ra các nguy cơ trong mỗi vòng lặp nhằm giúp thay đổi để 
loại bỏ nguy cơ. [4] 
946 
Phi tập trung: Agile phân bổ việc ra quyết định cho các developer.[1] 
Hội tụ: Agile giúp loại bỏ toàn bộ các nguy cơ đáng quan tâm để đảm bảo sự thành công của sản 
phẩm trong một quá trình phát triển nhanh chóng. [4] 
Hướng tới con người: Agile quan trọng con người hơn công nghệ và quy trình, tất cả các nguyên lý 
của Agile nhằm giúp developer có tinh thần và năng suất cao nhất có thể (Ví dụ: con người giỏi làm 
từng việc cỡ nhỏ với nhịp độ nhất định hơn là làm một việc lớn dài hạn .[4 
Hợp tác: Khách hàng làm việc gần gũi với đội ngũ phát triển, đưa ra phản hồi với từng vòng lặp 
giúp developer quyết định cách tốt nhất để làm hài lòng khách hàng. [4] 
2 NHỮNG LỢI ÍCH THỰC TẾ CỦA AGILE SO VỚI WATERFALL 
 ảng 1: So sánh tỷ lệ thành công của Agile so với Waterfall dựa trên kích cỡ các dự án[5] 
Kích cỡ Phương pháp Thành công (%) Khó khăn (%) Thất bại (%) 
Dự án mọi kích cỡ Agile 39 52 9 
Waterfall 11 60 29 
Dự án cỡ lớn Agile 18 59 23 
Waterfall 3 55 42 
Dự án cỡ Vừa Agile 27 62 11 
Waterfall 7 68 25 
Dự án cỡ nhỏ Agile 58 38 4 
Waterfall 44 45 11 
Dữ liệu trên được lấy từ 10000 dự án từ năm 2011 đến năm 2015. Từ kết quả trên cho thấy, mô hình 
Waterfall không có khả năng mở rộng tốt. Về tổng thể, khả năng thành công của Agile cao gần 
gấp 4 lần so với Waterfall, và khả năng thất bại của Waterfall cao gấp 3 lần so với Agile, Agile thích 
hợp để mở rộng các dự án, và khi kích cỡ dự án càng nhỏ, sự khác biệt giữa Agile và Waterfall càng 
thu hẹp.[5 
Tuy nhiên, càng thu nhỏ kích cỡ dự án, càng thấy rõ được lợi thế của mô hình Agile, khi quan sát 
những dự án cỡ nhỏ, chỉ 4 số dự án thất bại, nhưng 80% team trong số này không có kỹ năng 
hoặc kỹ năng Agile k m, trong khi đó, 70 team với sản phẩm đúng hạn, chi phí không vượt ngân 
sách và kết quả mỹ mãn lại có kỹ năng Agile tốt. Vậy, có thể kết luận rằng với dự án Agile càng nhỏ 
và một team có kỹ năng Agile tốt, khả năng thành công của dự án sẽ càng cao.[6] 
3 THỰC NGHIỆM MÔ HÌNH AGILE 
Để phân tích hiệu quả và tính khả thi của mô hình Agile, bài viết phân tích ở 2 mức độ, mức team 
và mức tập đoàn, dữ liệu được thu thập từ trường hợp của Zonmob, một công ty lập trình game ở 
Việt Nam, nay đã đổi tên thành BraveStar và Cisco, một tập đoàn công nghệ đa quốc gia của Mỹ. 
947 
ZONMOB 
Quy trình Agile sử dụng: Scrum 
Sản phẩm: Dòng game thủ thành Tower Defense 4: Invasion 
Trước khi sử dụng Scrum, chất lượng của sản phẩm không được bảo đảm, để khắc phục vấn đề 
này, Zonmob chia công việc thành các Sprint với time-bo là 1 tuần, mỗi Sprint hoàn thành một 
phần các Product Backlog, được cập nhật bằng 1 dashboard, Scrumboard được sử dụng theo dõi 
Sprint Backlog, sau mỗi Sprint, cả đội test lại sản phẩm và cập nhật Burndown Chart. 
Hình 3: Quy trình Scrum của Zonmob[7] 
Hình 4: Product Backlog dashboard[7] 
Hình 5: Scrum board và Burndown Chart[7] 
948 
Hình 6: Sản phẩm hoàn thành[8] 
 ảng 2: So sánh năng suất lao động qua các Sprint[7] 
Sprint 
Object 
points 
Effort 
Productivity 
(OP/Man/Week) 
Average 
Productivity 
in 2 sprint 
% 
Productivity 
increased 
1 35.90 4.10 8.76 Total Point Done 1016.39 
2 177.28 3.42 51.89 30.32 Effort 30.15 
3 27.40 1.80 15.22 33.55 10.66 Points/Man/Spri 33.71 
4 213.49 4.10 52.07 33.65 0.27 
5 179.70 5.90 30.46 41.26 22.64 
6 167.10 3.93 42.48 36.47 -11.62 
7 21.52 6.90 31.23 36.86 1.07 Average 
Productivity 
increased in 1 
Sprint 
4.61% 
Kết quả thu được: 
Chất lượng sản phẩm được đảm bảo, tinh thần làm việc tăng lên đáng kể. 
Thời gian hoàn thành: Giảm từ dự kiến 8 tháng xuống còn 6 tháng.[7] 
CISCO 
Phương pháp sử dụng: Scaled Agile Framework (SAFe). [9] 
Sản phẩm: Subscription Billing Platform (SBP).[9] 
Trước quý 4/2015, Cisco áp dụng Waterfall cho Subscription Billing Platform của họ (SBP , Cisco có 4 
đội dành cho việc design, build, test và desploy. Team build không thể bắt đầu công việc nếu như 
design chưa hoàn thành ong, và cứ thế, việc này dẫn tới chậm trễ, sản phẩm k m chất lượng và 
làm thêm giờ. [9] 
949 
Hình 7: Quy trình làm việc trước Agile[10] 
Hướng giải quyết: Cisco sử dụng Agile Release Trains (ARTs , tức đội-của-đội, cho SBP, Cisco thành 
lập 3 ARTs bao gồm capabilities, defects and fi es, và projects, cả 3 ARTs cùng nhau build và test 
từng thành phần của SBP, từng bước tích hợp vào hệ thống. Vào mỗi ngày, các team họp cùng nhau
15 và viết các công việc cần làm lên bảng Kanban, những ai làm việc ở a có thể em qua một 
bảng chung được share trên WebE , một nền tảng khác của Cisco. [9] 
Hình 8: Quy trình làm việc sau Agile[10] 
Kết quả: 
Cải thiện chất lượng: Bản SBP mới hoàn thành đúng thời hạn, với 100% các tính năng theo kế 
hoạch. So với các bản phát hành dựa trên phương pháp thác nước, Defect Rejected Ratio (DRR) đã 
giảm 16 phần trăm. Các lỗi hoặc sai sót lớn và nghiêm trọng giảm 40%. [9] 
Hình 9: Defect Rejected Ratio của Agile(Q4FY15 so với Waterfall(Q3FY15)[9] 
Cải thiện năng suất: hiệu quả loại bỏ lỗi (Defect Removal Efficiency - DRE) lên 14%. Lý do cho việc cải 
thiện bao gồm: 
– Cải thiện sự hợp tác giữa các nhóm nhà phát triển ở Hoa Kỳ, Trung Quốc và Ấn Độ[9] 
– Các thành viên trong nhóm xác định các cơ hội để cải thiện trong các scrum hàng ngày. [9] 
950 
Hình 10: Defect Removal Efficiency của Agile(Q4FY15 so với Waterfall(Q3FY15) [9] 
4 KẾT LUẬN 
Qua các kết quả trên cho thấy, việc chuyển đổi phương thức làm việc sang Agile/Scrum đóng vai trò 
quan trọng trong gia tăng năng suất lao động, tăng hiệu quả dự án và đổi mới sáng tạo. Tại Việt 
Nam, nhiều tên tuổi lớn như FPT, Viettel, VNG hay những doanh nghiệp nhỏ mới khởi sự cũng đã 
sớm bắt kịp xu thế áp dụng Agile/Scrum[11]. Tuy nhiên, Agile ở Việt Nam vẫn còn non trẻ và chỉ 
dừng lại ở các dự án cỡ nhỏ bởi vì thiếu kinh nghiệm áp dụng Agile, vẫn còn rất nhiều trường hợp 
sử dụng Agile không đúng cách dẫn tới thất bại. 
Mặc dù việc sử dụng Agile mang lại rất nhiều lợi ích, không thể áp dụng Agile vào mọi dự án, bởi vì 
mỗi dự án lại cần một mô hình phát triển phù hợp khác nhau. Agile không phải là một công cụ 
toàn diện có thể sử dụng bất cứ hoàn cảnh nào, mà là một kỹ thuật cần được sử dụng đúng cách, 
vì thế, việc áp dụng Agile cần phải được sử dụng bởi một tập thể có kinh nghiệm hoặc được đào 
tạo kỹ lưỡng. 
TÀI LIỆ TH M KHẢO 
[1] Sanjana Panicker and Maitreyi Kv (2016), Use of Agile Methodology for Mobile Applications 
[2] Stageofagile.com (2019), 13th annual State of Agile report 
[3] Mendix.com (2020), Agile Framework – A Quick Introduction & Overview of Agile Project 
Management Methodology 
[4] Granville G. Miller (2001), The Characteristics of Agile Software Processes 
[5] The Standish Group International (2015), CHAOS Report 2015 
[6] Jim Johnson and Hans Mulder (2015), Factors of Success 2015 
[7] Hocvienagile.com, Case study: Zonmob 
[8] Gamestudio.vn (2016), Tower Defense 4: Invasion – Game thủ thành đỉnh nhất hiện nay đã 
xuất hiện - GameStudio Việt 
[9] Cisco (2016), How Cisco IT Uses Agile Development with Distributed Teams and Complex 
Projects 
[10] Alesia Krush (2018), 5 Success Stories That Will Make You Believe in Scaled Agile -
ObjectStyle.com 
[11] Tú Trâm (2016), Thiếu nhân lực Agile trầm trọng ở Việt Nam - Agile Breakfast 

File đính kèm:

  • pdfphan_tich_dinh_tinh_viec_ap_dung_mo_hinh_agile_vao_quy_trinh.pdf