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
Trang 1
Trang 2
Trang 3
Trang 4
Trang 5
Trang 6
Trang 7
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
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:
- phan_tich_dinh_tinh_viec_ap_dung_mo_hinh_agile_vao_quy_trinh.pdf