Tải bản đầy đủ (.pdf) (7 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (341.21 KB, 7 trang )

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]

944


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 hồ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 hồn thành. Q 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 đồ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]

945



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 q 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 (%)

Agile

39

52

9


Waterfall

11

60

29

Agile

18

59

23

Waterfall

3

55

42

Agile

27

62


11

Waterfall

7

68

25

Agile

58

38

4

Waterfall

44

45

11

Dự án mọi kích cỡ

Dự án cỡ lớn


Dự án cỡ Vừa

Dự án cỡ nhỏ

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 đồn cơng nghệ đa quốc gia của Mỹ.

946



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]

947


Hình 6: Sản phẩm hồn thành[8]
ảng 2: So sánh năng suất lao động qua các Sprint[7]

Sprint

Average
%
Object
Productivity
Productivity Productivity
Effort
points
(OP/Man/Week)

in 2 sprint
increased

1

35.90

4.10

8.76

2

177.28

3.42

51.89

30.32

3

27.40

1.80

15.22

33.55


10.66

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

Total Point Done

1016.39

Effort

30.15

Points/Man/Spri


33.71

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]

948


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 hồ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]

949


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ụ
tồn diện có thể sử dụng bất cứ hồ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]
950

Tú Trâm (2016), Thiếu nhân lực Agile trầm trọng ở Việt Nam - Agile Breakfast




×