Hỏi đáp công nghệ

Mô hình Agile là gì? Chi tiết ưu và nhược điểm của Agile

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Table of Contents

Trong những năm trước đây, mô hình Iterative Waterfall rất phổ biến để quản lý và hoàn thành một dự án. Nhưng ngày nay các lập trình viên phải đối mặt với nhiều vấn đề khác nhau khi sử dụng nó để phát triển phần mềm. Những khó khăn chính bao gồm xử lý các yêu cầu thay đổi từ khách hàng trong quá trình phát triển dự án, chi phí cao và thời gian cần thiết để kết hợp những thay đổi này. Để khắc phục những nhược điểm này của mô hình Waterfall, vào giữa những năm 1990, mô hình phát triển phần mềm Agile đã được đề xuất.

Mô hình Agile là gì?
Mô hình Agile là gì?

Trong bài viết này, Hỏi đáp Công nghệ sẽ giúp bạn tìm hiểu đáp án cho câu hỏi Mô hình Agile là gì, các nguyên tắc cùng chu trình phát triển của nó. Cùng bắt đầu nhé!

Mô hình Agile là gì?

Mô hình phát triển phần mềm Agile – còn được gọi đơn giản là mô hình Agile –  là một phương thức được thực hiện trong các dự án công nghệ phần mềm, giúp khuyến khích sự thay đổi trong quá trình phát triển dự án và đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

Mô hình Agile đòi hỏi một sự thay đổi văn hóa ở nhiều công ty vì nó tập trung vào việc phân phối rõ ràng từng mảng hoặc từng phần của phần mềm chứ không phải trên toàn bộ ứng dụng.

Lợi ích của Agile bao gồm khả năng giúp các team trong bối cảnh đang phát triển mà vẫn duy trì sự tập trung vào việc phân phối hiệu quả giá trị kinh doanh. Văn hóa hợp tác được hỗ trợ bởi mô hình này cũng cải thiện tính hiệu quả trong toàn tổ chức khi các nhóm làm việc cùng nhau và hiểu rõ vai trò cụ thể của họ trong quy trình.

Cuối cùng, các công ty sử dụng mô hình phát triển phần mềm Agile có thể cảm thấy tự tin rằng họ đang phát hành một sản phẩm chất lượng cao vì thao tác kiểm thử được thực hiện trong suốt quá trình phát triển, mang lại cơ hội thực hiện các thay đổi nhanh chóng khi cần thiết và cảnh báo các nhóm về bất kỳ vấn đề tiềm ẩn nào.

Agile đã thay thế mô hình thác nước như một phương pháp phát triển được lựa chọn ở hầu hết các công ty, nhưng bản thân nó có nguy cơ bị lu mờ bởi sự phổ biến nhanh chóng của DevOps.

Bốn giá trị của Agile

Vào năm 2001, 17 chuyên gia phát triển phần mềm đã tập hợp lại để thảo luận về các khái niệm xung quanh ý tưởng phát triển phần mềm lightweight và cuối cùng Tuyên ngôn Agile (Agile Manifesto) đã được tạo ra. Tuyên ngôn này nêu ra bốn giá trị cốt lõi của Agile và mặc dù đã có những tranh luận sôi nổi về việc liệu nó có còn tồn tại lâu hơn nữa hay không, nhưng những tuyên ngôn này vẫn tiếp tục là cốt lõi của phong trào Agile.

Các tương tác riêng lẻ quan trọng hơn các quy trình và công cụ

Con người thúc đẩy quá trình phát triển và đáp ứng nhu cầu kinh doanh. Họ là phần quan trọng nhất của sự phát triển và cần được đánh giá cao hơn so với các quy trình và công cụ. Nếu các quy trình hoặc công cụ thúc đẩy sự phát triển, thì nhóm sẽ ít có khả năng phản ứng và thích ứng với sự thay đổi hơn và do đó, ít có khả năng đáp ứng nhu cầu của khách hàng hơn.

Tập trung vào phần mềm chạy tốt hơn là tài liệu kỹ lưỡng

Trước khi Agile ra đời, một lượng lớn thời gian đã được dùng cho việc ghi chép dữ liệu sản phẩm trong suốt quá trình phát triển để phân phối. Danh sách các yêu cầu thường được lập thành những văn bản rất dài và sẽ gây ra sự chậm trễ lâu dài trong quá trình phát triển.

Mặc dù Agile không loại bỏ việc sử dụng những tài liệu này, nhưng nó hợp lý hóa chúng theo cách chỉ cung cấp cho nhà phát triển thông tin cần thiết để thực hiện công việc – chẳng hạn như user story. Tuyên ngôn Agile vẫn coi trọng quy trình ghi chép tài liệu, nhưng nó đặt giá trị cao hơn vào việc phần mềm chạy tốt.

Hợp tác với khách hàng thay vì đàm phán hợp đồng

Agile tập trung vào sự hợp tác giữa khách hàng và người quản lý dự án hơn là đàm phán giữa hai bên, để tìm ra các chi tiết của việc phân phối. Cộng tác với khách hàng có nghĩa là họ được tham gia trong toàn bộ quá trình phát triển, không chỉ ở phần đầu và phần cuối, do đó, các nhóm sẽ dễ dàng đáp ứng nhu cầu của khách hàng hơn.

Ví dụ, trong phát triển phần mềm Agile, khách hàng có thể được tham gia vào các khoảng thời gian khác nhau cho các bản demo của sản phẩm. Tuy nhiên, khách hàng cũng có thể có mặt và tương tác với các nhóm phát triển hàng ngày, tham dự tất cả các cuộc họp và đảm bảo sản phẩm đáp ứng được đầy đủ mong muốn của họ.

Tập trung vào việc đáp ứng với sự thay đổi

Các mô hình phát triển phần mềm truyền thống được sử dụng để tránh các thay đổi vì nó được coi là một khoản chi phí không mong muốn. Agile loại bỏ hoàn toàn ý tưởng này. Các lần lặp lại ngắn trong chu trình Agile cho phép nhóm phát triển dễ dàng thực hiện các thay đổi, giúp họ sửa đổi quy trình để phù hợp nhất với nhu cầu của họ thay vì ngược lại. Nhìn chung, mô hình Agile tin rằng thay đổi luôn là cách để cải thiện dự án và cung cấp các giá trị bổ sung.

Xem thêm >> PWA là gì? Tại sao nó lại cực kì quan trọng trong E-commerce

12 nguyên tắc của Agile

Tuyên ngôn Agile cũng nêu ra 12 nguyên tắc cốt lõi cho quá trình phát triển phần mềm. Chúng bao gồm:

  1. Làm hài lòng khách hàng thông qua việc bàn giao công việc có giá trị sớm và liên tục.
  2. Chia công việc lớn thành các task nhỏ hơn để có thể hoàn thành nhanh chóng.
  3. Ghi nhận rằng công việc tốt nhất đến từ các nhóm tự tổ chức.
  4. Cung cấp cho các cá nhân những môi trường và hỗ trợ cần thiết và tin tưởng họ hoàn thành công việc.
  5. Tạo ra các quy trình thúc đẩy các nỗ lực bền vững.
  6. Duy trì một tốc độ không đổi cho công việc đã hoàn thành.
  7. Hoan nghênh các yêu cầu thay đổi, thậm chí là muộn trong một dự án.
  8. Họp với đội dự án và chủ doanh nghiệp hàng ngày trong suốt dự án.
  9. Yêu cầu nhóm phản ánh định kỳ về cách để công việc trở nên hiệu quả hơn, sau đó đánh giá và điều chỉnh hành vi cho phù hợp.
  10. Đo lường tiến độ bằng khối lượng công việc đã hoàn thành.
  11. Liên tục tìm kiếm sự xuất sắc.
  12. Khai thác sự thay đổi để có lợi thế cạnh tranh.

Chu trình phát triển phần mềm Agile

Chu trình phát triển phần mềm Agile có thể được chia thành sáu bước: khái niệm, khởi động, lặp lại/xây dựng, phát hành, production và nghỉ hưu.

Bước đầu tiên, khái niệm (concept), liên quan đến việc xác định các cơ hội kinh doanh trong mỗi dự án tiềm năng cũng như ước tính khoảng thời gian và lượng công việc sẽ cần thiết để hoàn thành dự án. Thông tin này sau đó có thể được sử dụng để sắp xếp thứ tự ưu tiên cho các dự án và phân biệt những dự án nào đáng để theo đuổi dựa trên tính khả thi về kinh tế và kỹ thuật.

Trong bước thứ hai, khởi đầu (inception), các thành viên tham gia nhóm được xác định, quỹ được thiết lập và các yêu cầu ban đầu được thảo luận với khách hàng. Một mốc thời gian cũng nên được đặt ra để vạch ra các trách nhiệm khác nhau của các nhóm và xác định rõ ràng khi nào các công việc dự kiến ​​sẽ được hoàn thành cho mỗi sprint. Sprint là một khoảng thời gian nhất định được xác định trong đó công việc cụ thể phải được hoàn thành và sẵn sàng để review.

Bước thứ ba, lặp lại/xây dựng (iteration/construction), là khi các nhóm bắt đầu tạo phần mềm hoạt động dựa trên các yêu cầu và phản hồi liên tục. Chu trình phát triển phần mềm Agile dựa trên các lần lặp lại – hoặc các chu kỳ phát triển đơn lẻ – xây dựng gối lên nhau và đưa dần đến bước tiếp theo của quy trình phát triển tổng thể cho đến khi dự án đó hoàn thành. Mỗi lần lặp lại thường kéo dài từ khoảng hai đến bốn tuần, với một deadline đã được định trước. Mục tiêu là có một sản phẩm hoạt động để thử khởi chạy vào cuối mỗi lần lặp.

Nhiều lần lặp lại được diễn ra trong suốt chu kỳ phát triển và chúng có quy trình làm việc riêng. Luồng lặp lại điển hình bao gồm:

  • xác định các yêu cầu dựa trên backlog sản phẩm, backlog của sprint cũng như phản hồi của khách hàng và các bên liên quan;
  • phát triển phần mềm dựa trên các yêu cầu đặt ra;
  • thực hiện kiểm tra đảm bảo chất lượng, đào tạo nội bộ cũng như bên ngoài và ghi chép tài liệu;
  • cung cấp và tích hợp sản phẩm đang hoạt động vào sản xuất;
  • thu thập phản hồi của khách hàng và các bên liên quan về quá trình lặp lại để xác định các yêu cầu mới cho sprint tiếp theo.

Bước thứ tư, phát hành (release), liên quan đến viếc kiểm tra đảm bảo chất lượng cuối cùng, giải quyết mọi khiếm khuyết còn lại, hoàn thiện hệ thống cùng tài liệu người dùng và cuối cùng là phát hành phiên bản cuối cùng thành bản production.

Sau khi phát hành, bước thứ năm, production, tập trung vào hỗ trợ liên tục nếu cần thiết để duy trì phần mềm. Các nhóm phát triển phải giữ cho phần mềm hoạt động một cách trơn tru đồng thời training người dùng chính xác cách sử dụng nó. Giai đoạn production được tiếp tục cho đến khi hỗ trợ kết thúc hoặc sản phẩm được lên kế hoạch nghỉ hưu.

Bước cuối cùng, nghỉ hưu (retirement), kết hợp tất cả các hoạt động cuối cùng, chẳng hạn như thông báo cho khách hàng và những Di chuyển cuối cùng. Bản release hệ thống phải được xóa khỏi production. Điều này thường được thực hiện khi một hệ thống cần được thay thế bằng một bản release mới hoặc nếu hệ thống trở nên lỗi thời, không cần thiết hoặc bắt đầu đi ngược lại với mô hình kinh doanh.

Trong suốt chu trình Agile, các tính năng khác nhau có thể được thêm vào backlog của sản phẩm, nhưng toàn bộ quy trình phải được lặp đi lặp lại từng bước cho đến khi mọi mục trong backlog đã được giải quyết. Điều này làm cho chu trình Agile giống như một vòng lặp hơn là một quy trình tuyến tính. Tại mọi thời điểm, một doanh nghiệp có thể bao gồm nhiều dự án diễn ra cùng lúc với các lần lặp lại được ghi trên các dòng sản phẩm khác nhau và nhiều khách hàng nội bộ và bên ngoài cung cấp các nhu cầu kinh doanh khác nhau.

Các loại phương pháp Agile

Mô hình Agile là gì
Mô hình Agile là gì? Các loại phương pháp Agile

Mục tiêu của mọi phương pháp Agile là nắm bắt và thích ứng nhanh chóng với sự thay đổi trong khi vẫn cung cấp phần mềm hoạt động hiệu quả nhất có thể. Tuy nhiên, mỗi phương pháp lại khác nhau trong cách xác định các bước phát triển phần mềm. Các phương pháp Agile được sử dụng phổ biến nhất bao gồm:

  • Scrum
  • Phát triển phần mềm tinh gọn (Lean software development)
  • Lập trình cực hạn (Extreme programming)
  • Pha lê (Crystal)
  • Kanban
  • Phương pháp phát triển hệ thống động (DSDM)
  • Phát triển theo hướng tính năng (FDD)

Scrum

Scrum là một framework Agile nhẹ có thể được sử dụng bởi các nhà quản lý dự án (PM) để kiểm soát tất cả các loại dự án lặp đi lặp lại và gia tăng. Trong Scrum, chủ sở hữu sản phẩm (PO) tạo ra một product backlog và làm việc với nhóm của mình để xác định và ưu tiên chức năng hệ thống.

Product backlog là danh sách mọi task cần hoàn thành để cung cấp một hệ thống phần mềm hoạt động thành công – điều này bao gồm các bản fix bug, tính năng cùng các yêu cầu phi chức năng. Sau khi product backlog được xác định, không có chức năng bổ sung nào có thể được thêm vào ngoại trừ team tương ứng.

Sau khi nhóm và PO đã thiết lập các ưu tiên, các nhóm chức năng chéo tham gia và đồng ý cung cấp các phần mềm hoạt động trong mỗi sprint – thường trong vòng 30 ngày. Sau mỗi sprint, product backlog được đánh giá lại, phân tích và định hướng lại để chọn một bộ chức năng mới có thể thực hiện cho sprint tiếp theo. Scrum đã trở nên phổ biến trong những năm qua vì nó khá đơn giản, cũng được chứng minh là hiệu quả và có thể kết hợp các phương pháp tổng thể khác nhau bên trong các phương pháp Agile khác.

Phát triển phần mềm tinh gọn

Phát triển phần mềm tinh gọn là một phương pháp lặp đi lặp lại khác tập trung vào việc sử dụng sơ đồ chuỗi giá trị (value stream mapping – VSM) hiệu quả để đảm bảo nhóm mang lại giá trị cho khách hàng. Phương pháp này khá linh hoạt và đang được phát triển; nó không bao gồm các hướng dẫn hoặc quy tắc cứng nhắc. Phương pháp này sử dụng các nguyên tắc cơ bản sau:

  • Tăng cường học tập
  • Trao quyền cho nhóm
  • Bồi dưỡng tính chính trực
  • Loại bỏ tạp chất
  • Hiểu toàn bộ vấn đề
  • Đưa ra quyết định càng muộn càng tốt
  • Cung cấp sản phẩm nhanh nhất có thể

Phương pháp Lean dựa trên phản hồi nhanh chóng và đáng tin cậy giữa khách hàng với developer để cung cấp quy trình phát triển nhanh chóng và hiệu quả. Để thực hiện điều này, Lean cung cấp cho các cá nhân và nhóm nhỏ quyền đưa ra quyết định thay vì dựa vào luồng kiểm soát phân cấp.

Để loại bỏ lãng phí, phương pháp Lean yêu cầu người dùng chỉ nên chọn các tính năng thực sự có giá trị cho hệ thống của họ, ưu tiên các tính năng được chọn này và sau đó phân phối chúng theo từng đợt nhỏ. Phát triển phần mềm tinh gọn cũng khuyến khích kiểm thử đơn vị tự động được viết đồng thời với code và tập trung vào việc đảm bảo mọi thành viên trong nhóm làm việc hiệu quả nhất có thể.

Phương pháp lập trình cực hạn (XP)

Phương pháp lập trình cực hạn (XP) là một cách tiếp cận rất có kỷ luật tập trung vào tốc độ và phân phối liên tục. Nó thúc khuyến khích sự tham gia của khách hàng, thúc đẩy vòng lặp phản hồi nhanh chóng, lập kế hoạch cùng kiểm thử liên tục và làm việc theo nhóm chặt chẽ. Phần mềm sẽ được phân phối định kỳ – thường là từ một đến ba tuần một lần. Mục tiêu là nâng cao chất lượng và khả năng đáp ứng của phần mềm đó khi đối mặt với những yêu cầu thay đổi từ khách hàng.

Xem thêm >> Opamp là gì? Cấu tạo và ứng dụng của Opamp

Pha lê (Crystal)

Crystal là phương pháp nhẹ và dễ thích nghi nhất. Nó tập trung nhất vào con người và các tương tác xảy ra trong khi làm việc trên một dự án Agile cũng như mức độ quan trọng của doanh nghiệp và mức độ ưu tiên của hệ thống đang được phát triển.

Phương pháp Crystal hoạt động với châm ngôn rằng mọi dự án đều sở hữu những đặc điểm riêng biệt và cần có một bộ chính sách, hành động và quy trình được điều chỉnh một chút. Do đó, nó được chia thành một bộ sưu tập các mô hình quy trình Agile, chẳng hạn như Crystal Orange, Crystal Clear và Crystal Yellow. Mỗi mô hình cụ thể lại có những đặc điểm riêng biệt được thúc đẩy bởi các yếu tố khác nhau, bao gồm những ưu tiên của dự án, quy mô nhóm và mức độ quan trọng của hệ thống.

Tương tự như các phương pháp Agile khác, Crystal nhấn mạnh việc phân phối thường xuyên phần mềm làm việc với sự tham gia trực tiếp của khách hàng, khả năng thích ứng và loại bỏ sự quan liêu và phiền nhiễu. Các nguyên tắc chính của nó bao gồm giao tiếp, làm việc theo nhóm và sự đơn giản.

Kanban

Kanban sử dụng phương pháp quản lý quy trình làm việc trực quan cho phép các team chủ động quản lý việc tạo ra sản phẩm – nhấn mạnh việc phân phối liên tục – mà không tạo thêm căng thẳng trong vòng đời phát triển phần mềm (SDLC). Phương pháp này đã trở nên phổ biến trong các nhóm cũng sử dụng phương pháp phát triển phần mềm Lean.

Kanban sử dụng ba nguyên tắc cơ bản: visualize quy trình làm việc; giới hạn số lượng công việc đang thực hiện; và cải thiện luồng công việc. Tương tự như Scrum, phương pháp Kanban được thiết kế để giúp các nhóm có thể làm việc hiệu quả hơn với nhau. Nó khuyến khích sự hợp tác liên tục và cố gắng xác định một quy trình làm việc tốt nhất có thể để thúc đẩy một môi trường với sự học hỏi và cải tiến một cách tích cực, liên tục.

Phương pháp phát triển hệ thống động

Phương pháp phát triển hệ thống động (DSDM) là sự đáp ứng nhu cầu về một framework công nghiệp chung để phân phối phần mềm nhanh chóng. DSDM dựa trên tám nguyên tắc chính là:

  1. Hợp tác
  2. Chuyển giao đúng tiến độ
  3. Kiểm soát dùng các công cụ phù hợp
  4. Truyền thông liên tục, rõ ràng
  5. Tập trung vào nhu cầu kinh doanh
  6. Phát triển lặp lại
  7. Sáng tạo theo từng bước từ nền tảng vững chắc
  8. Không thỏa hiệp về chất lượng

Trong DSDM, quá trình làm lại được tích hợp sẵn và tất cả các thay đổi phải có thể hoàn nguyên. Các yêu cầu hệ thống được ưu tiên sử dụng Quy tắc MoSCoW, xếp hạng mức độ ưu tiên là:

  • M – phải có (must have)
  • S – nên có (Should)
  • C – có thể có, nhưng không quan trọng (Could have)
  • W – sẽ không có bây giờ, nhưng có thể có sau (Won’t have now)

Đối với DSDM, không phải mọi yêu cầu đều được coi là quan trọng. Mỗi lần lặp lại thì các mục ít quan trọng hơn có thể được loại bỏ để các yêu cầu ưu tiên cao hơn không bị ảnh hưởng.

Phát triển theo hướng tính năng (FDD)

Cuối cùng, phát triển theo hướng tính năng (FDD) kết hợp các phương pháp hay nhất về kỹ thuật phần mềm – chẳng hạn như phát triển theo tính năng, quyền sở hữu code và mô hình hóa đối tượng miền – để tạo ra một quy trình lặp lại ngắn, theo hướng mô hình và gắn kết. FFD bắt đầu bằng cách xác định hình dạng mô hình tổng thể, từ đó tạo ra một danh sách của tính năng. Sau đó, tiến hành sự lặp lại kéo dài hai tuần và tập trung vào việc lập kế hoạch theo tính năng, thiết kế theo tính năng và xây dựng theo tính năng.

Nếu một tính năng phải mất hơn hai tuần để xây dựng, thì nó nên được chia thành các tính năng nhỏ hơn. Ưu điểm chính của phương pháp FDD là nó có thể mở rộng (scale) – ngay cả đối với các nhóm lớn – vì nó sử dụng khái niệm “thiết kế vừa đủ ban đầu” hay còn gọi là JEDI.

Ưu điểm và nhược điểm của Agile

Nhiều năm qua, các phương pháp Agile vẫn luôn được so sánh với mô hình Waterfall.

Ưu điểm của mô hình Agile

Trong kỷ nguyên phát triển phần mềm của Waterfall, các lập trình viên sẽ làm việc một mình, với rất ít hoặc không có đầu vào trước khi giao phần mềm cho tester và sau đó đưa lên bản production. Các lỗi, sự cố và thay đổi tính năng sẽ không được xử lý tốt hoặc được xử lý quá muộn trong quá trình phát triển khiến cho các dự án bị trì hoãn nghiêm trọng hoặc thậm chí bị loại bỏ.

Ý tưởng đằng sau mô hình Agile, trong đó tất cả mọi người – bao gồm cả phía doanh nghiệp – đều tham gia và được cung cấp đầy đủ thông tin trong quá trình phát triển, thể hiện sự thay đổi sâu sắc trong cả văn hóa công ty lẫn khả năng đưa phần mềm tốt hơn ra thị trường một cách nhanh chóng.

Hợp tác và giao tiếp trở nên quan trọng tương đương công nghệ, Agile đã được điều chỉnh và sửa đổi để phù hợp với các tổ chức thuộc mọi quy mô và loại hình. Sự thay đổi văn hóa Agile cũng mở đường cho sự phát triển phần mềm mới nhất, DevOps.

Ưu điểm của mô hình Agile được tóm tắt như sau:

  • Đáp ứng tốt với sự thay đổi
  • Chấp nhận sự không chắc chắn
  • Chu kỳ đánh giá nhanh hơn
  • Linh hoạt hơn trong việc release các tính năng
  • Giảm thiểu tài liệu

Xem thêm >> UAT là gì? Quy trình thực hiện UAT hiệu quả

Nhược điểm của Agile

Mặt khác, nhiều người nói rằng nhược điểm lớn nhất của Agile là thực tế nó đã bị sửa đổi và bị biến tấu bởi nhiều tổ chức.

Mặc dù Agile khuyến khích sự liên lạc giữa các nhà phát triển và phía doanh nghiệp, nhưng việc đưa kiểm thử và hoạt động vào hỗn hợp đó lại kém thành công hơn – một thiếu sót có thể đã giúp ý tưởng về DevOps có được sức hút.

Một mối quan tâm tiềm ẩn khác về Agile là sự thiếu tập trung vào công nghệ, gây ra những khó khăn cho việc truyền tải những khái niệm cho các nhà quản lý cấp trên, những người không hiểu vai trò của văn hóa trong phát triển phần mềm.

Hơn nữa, sự cần thiết của việc hoàn thành sprint đúng hạn có thể tạo ra một môi trường làm việc rất căng thẳng cho các nhà phát triển phần mềm. Họ có thể bị buộc phải làm thêm giờ và ở lại muộn để hoàn thành thời hạn.

Vậy là trong bài viết trên, Hỏi đáp Công nghệ đã giải thích rất chi tiết về định nghĩa của mô hình Agile cũng như các giá trị , nguyên tắc và chu trình phát triển của nó. Nếu bạn thấy bài viết này có ích, hãy chia sẻ nó cho bạn bè của mình nữa nhé!

Các bài viết liên quan

Leave a Comment

Email của bạn sẽ không được hiển thị công khai.

Bài viết liên quan