0
1
181
Người đăng: Nhung Nguyễn
Theo Viblo Asia
Agile là một phương pháp thúc đẩy sự lặp lại liên tục của quá trình phát triển và kiểm thử trong suốt vòng đời phát triển phần mềm của dự án. Trong mô hình Agile, cả hoạt động phát triển và kiểm thử đều diễn ra đồng thời, không như mô hình Waterfall diễn ra tuần tự.
Phát triển phần mềm theo Agile là một trong những quy trình đơn giản và hiệu quả để biến tầm nhìn về nhu cầu kinh doanh thành các giải pháp phần mềm. Agile là một thuật ngữ được sử dụng để mô tả các phương pháp tiếp cận phát triển phần mềm mà sẽ liên tục lập kế hoạch, học hỏi, cải tiến, hợp tác nhóm, phát triển tiến hóa và phân phối sớm. Nó khuyến khích các phản ứng linh hoạt để thay đổi.
Việc phát triển phần mềm theo Agile nhấn mạnh vào bốn giá trị cốt lõi:
- Tương tác cá nhân và theo nhóm hơn là các quy trình và công cụ
- Phần mềm có thể làm việc hơn là tài liệu đầy đủ
- Sự hợp tác của khách hàng hơn là quá trình đàm phán hợp đồng
- Đáp ứng với các sự thay đổi hơn là tuân thủ một kế hoạch có sẵn
Mô hình Agile và Waterfall là hai phương pháp khác nhau cho quá trình phát triển phần mềm. Mặc dù chúng khác nhau trong cách tiếp cận, nhưng cả hai phương pháp đều hữu ích vào thời điểm nào đó, tất cả tùy thuộc vào yêu cầu và loại dự án triển khai.
Dưới đây là bảng so sánh về hai mô hình này :
| Mô hình Agile | Mô hình Waterfall |
|---|---|
| Đề xuất cách tiếp cận tăng dần và lặp đi lặp lại đối với thiết kế phần mềm | Quá trình phát triển phần mềm tuần tự từ điểm bắt đầu đến điểm kết thúc |
| Được chia thành các mô hình riêng lẻ mà các nhà thiết kế sẽ làm việc trên các phần này | Quá trình thiết kế không được chia thành các mô hình riêng lẻ |
| Khách hàng có xem sản phẩm sớm và thường xuyên để đưa ra quyết định cũng như thay đổi đối với dự án | Khách hàng chỉ có thể xem sản phẩm khi kết thúc dự án |
| Mô hình Agile được coi là không có cấu trúc so với mô hình Waterfall | Mô hình Waterfall an toàn hơn vì chúng được định hướng theo kế hoạch |
| Với các dự án nhỏ có thể được thực hiện rất nhanh chóng. Tuy nhiên với các dự án lớn, rất khó để ước tính thời gian phát triển. | Tất cả các loại dự án có thể được ước tính và hoàn thành. |
| Lỗi có thể được sửa ở bất kì giai đoạn nào khi đang phát triển dự án | Chỉ khi kết thúc, toàn bộ sản phẩm được kiểm tra. Nếu lỗi yêu cầu được tìm thấy hoặc bất kỳ thay đổi nào phải được thực hiện, dự án phải bắt đầu lại từ đầu |
| Quá trình phát triển là lặp đi lặp lại và dự án được thực hiện trong khoảng thời gian lặp lại ngắn, thường là 2-4 tuần. Lập kế hoạch là rất ít với mỗi quá trình | Quá trình phát triển được diễn ra theo từng giai đoạn, và giai đoạn lớn hơn nhiều so với lặp lại. Mỗi giai đoạn kết thúc với mô tả chi tiết của giai đoạn tiếp theo |
| Tài liệu ít được ưu tiên hơn so với phát triển phần mềm | Tài liệu là ưu tiên hàng đầu và thậm chí có thể sử dụng để đào tạo nhân viên và nâng cấp phần mềm với nhóm khác |
Mỗi vòng lặp (sprint/iteration) đều có giai đoạn kiểm thử riêng. Nó cho phép thực hiện regression test mỗi khi các chức năng hoặc logic mới được phát hành |
Chỉ sau giai đoạn phát triển, giai đoạn kiểm thử mới được thực hiện vì các bộ phận riêng biệt không hoạt động đầy đủ |
Khi kết thúc một sprint, các tính năng có thể thay đổi của sản phẩm sẽ được bàn giao cho khách hàng. Các tính năng mới có thể sử dụng ngay sau. Nó rất hữu ích khi bạn tiếp xúc tốt với khách hàng. |
Tất cả các tính năng được phát triển sẽ được phân phối cùng một lúc sau giai đoạn triển khai dài. |
| Tester và developers làm việc cùng nhau | Tester làm việc riêng biệt với Dev |
Vào cuối mỗi sprint, UAT (User Acceptance Testing) được thực hiện |
UAT được thực hiện khi kết thúc dự án. |
| Đòi hỏi giao tiếp chặt chẽ với các nhà phát triển và cùng nhau phân tích các yêu cầu và lập kế hoạch | Nhà phát triển không tham gia vào quá trình lập kế hoạch và yêu cầu. Thông thường sẽ có độ trễ thời gian giữa các lần kiểm thử và viết code |
Có rất nhiều quy trình phát triển phần mềm dựa theo Agile, dưới đây mình sẽ liệt kê và giải thích chi tiết mô hình Scrum:
4.1 Scrum
4.1.1 Khái niệm
SCRUM là một phương pháp phát triển phần mềm theo Agile tập trung đặc biệt vào cách quản lý các nhiệm vụ trong môi trường phát triển dựa trên nhóm. Về cơ bản, Scrum có nguồn gốc từ hoạt động xảy ra trong một trận đấu bóng bầu dục. Scrum tin tưởng vào việc trao quyền cho nhóm phát triển và ủng hộ làm việc trong các nhóm nhỏ (từ 7 đến 9 thành viên). Chúng ta có 3 vài trò chính như sau:
- Scrum Master: chịu trách nhiệm thiết lập nhóm, tổ chức họp các
sprintvà loại bỏ các trở ngại để giúp cả đội tiến bộ. - Product Owner: tạo ra các
product backlog, ưu tiên cácbacklog(công việc tồn đọng) đó và chịu trách nhiệm cung cấp các chức năng ở mỗisprint. - Development Team: tự quản lý công việc của bản thân và của nhóm, đồng thời tổ chức công việc để hoàn thành
sprint
4.1.2 Product Backlog
Đây là một kho lưu trữ mà các yêu cầu được theo dõi với các chi tiết về user stories (yêu cầu của người dùng) cần được hoàn thành cho mỗi bản release. Nó nên được Product Owner duy trì và ưu tiên, và nó nên được phân phối cho Development Team (nhóm phát triển). Nhóm cũng có thể yêu cầu bổ sung yêu cầu mới, sửa đổi hoặc xóa yêu cầu.
4.1.3 Thực hành Scrum
Các bài thực hành được mô tả trong bảng dưới đây
Trong đó :
- Sprint Planning: cuộc họp diễn ra nhằm mục đích chuyển các yêu cầu người dùng và nghiệp vụ thành bảng
Product Backlog, bảng này sẽ liệt kê chi tiết các đầu việc cần hoàn thành để hướng tới sản phẩm cuối. - Sprint: quá trình chính sẽ diễn ra cho mỗi vòng lặp phát triển, thường sẽ là 2 đến 4 tuần
- Daily Meeting: diễn ra hàng ngày (khoảng 15 phút), cả nhóm sẽ họp và thảo luận về công việc đã làm của ngày hôm trước, kế hoạch cho hôm nay và các vấn đề gặp phải
- Review Meeting: diễn ra khi được yêu cầu để giới thiệu và trình bày về các tính năng đã hoàn thành
- Retrospective Meeting: diễn ra khi kết thúc một
sprint, thường sẽ là buổi họp rút kinh nghiệm cũng như đưa ra các ý tưởng giúp cả nhóm tiến bộ hơn.
Quy trình của Scrum:
- Mỗi lần lặp lại của Scrum được gọi là sprint
- Product backlog là danh sách chứa tất cả các chi tiết về yêu cầu
- Trong mỗi sprint, các user stories của product backlog được chọn và chuyển thành sprint backlog
- Team làm việc dựa trên sprint backlog đã định ra.
- Team kiểm tra các công việc hàng ngày
- Cuối sprint sẽ bàn giao sản phẩm.
Trên đây mình đã giới thiệu về phương pháp phát triển phần mềm Agile cũng như một số mô hình hoạt động dựa trên nguyên tắc của nó. Cảm ơn mọi người đã đọc ạ.
