Tìm hiểu quy trình phát triển phần mềm linh hoạt Agile | Môn Công nghệ phần mềm - Đại học Xây Dựng Hà Nội

lOMoAR cPSD| 58933639
1. Tìm hiểu quy trình phát triển phần mềm linh hoạt Agile 1.1Agile là gì ?
Agile là phương pháp quản lý dự án linh hoạt, tập trung vào việc chia nhỏ
công việc thành các phần nhỏ (gọi là Sprint hoặc Iteration), phản hồi liên tục
và cải tiến liên tục trong quá trình phát triển. Agile giúp đội ngũ nhanh chóng
thích ứng với thay đổi và tăng hiệu quả hoàn thành sản phẩm. Phương pháp
này được xây dựng dựa trên nguyên tắc phân đoạn vòng lặp (iterative) và
tăng trưởng tiệm tiến (incremental).
Agile nhấn mạnh sự hợp tác liên tục giữa các thành viên trong nhóm và các
bên liên quan, cũng như cải tiến liên tục trong mọi giai đoạn của dự án. Mục
tiêu là đưa sản phẩm đến tay khách hàng nhanh chóng, đáp ứng tối ưu nhu cầu thực tế
1.2 Bối cảnh ra đời của Agile
Trước Agile, các mô hình phát triển truyền thống như Waterfall (thác nước)
hay V-model thường được áp dụng. Tuy nhiên, hạn chế của các mô hình này là:
- Cứng nhắc: toàn bộ kế hoạch, tài liệu và sản phẩm đều được xác định
gần như ngay từ đầu, khó thay đổi giữa chừng.
- Thời gian phát triển dài: khách hàng chỉ nhìn thấy sản phẩm sau giai
đoạn cuối, dẫn đến rủi ro nếu yêu cầu thay đổi.
- Khoảng cách giữa khách hàng và nhóm phát triển: dễ gây ra sản phẩm
không đúng mong muốn thực tế.
Để khắc phục, năm 2001, 17 chuyên gia phần mềm đã họp tại Snowbird (Mỹ)
và đưa ra Tuyên ngôn Agile (Agile Manifesto) – đặt nền móng cho phương pháp Agile.
1.3 Nguyên tắc cốt lõi của Agile
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 lOMoAR cPSD| 58933639
1.4 Các mô hình agile phổ biến
- Scrum → Làm theo Sprint (1–4 tuần), có Product Owner – Scrum Master – Dev Team.
- Kanban → Quản lý công việc bằng bảng Kanban (To Do – Doing –
Done), luồng liên tục, có WIP limit.
- Extreme Programming (XP) → Tập trung kỹ thuật: Pair
Programming, TDD, Refactoring.
- Lean Software Development → Tinh gọn, loại bỏ lãng phí, tăng giá trị cho khách hàng.
- Crystal → Nhấn mạnh con người hơn quy trình, linh hoạt cho nhóm nhỏ.
- DSDM → Có vòng đời đầy đủ, dùng kỹ thuật MoSCoW, thích hợp dự án lớn có deadline.
- FDD → Phát triển theo tính năng, phù hợp dự án quy mô lớn. 1.5Quy
trình phát triển Agile (kanban)
a. Thiết lập bảng Kanban •
Dùng công cụ quản lý (Trello, Jira, Asana…) hoặc bảng trắng với sticky notes. •
Các cột (list) cơ bản trong Kanban:
o Backlog → chứa toàn bộ yêu cầu/tính năng (nguồn công việc). o To
Do → những việc đã được chọn để làm. o Doing (In Progress) →
việc nhóm đang thực hiện. o Testing/Review → việc cần kiểm thử hoặc chờ đánh giá.
o Done → việc đã hoàn thành. •
Có thể thêm cột tùy nhu cầu (VD: “Code Review”, “Deploy”). b. Tạo và
quản lý thẻ công việc (Card) •
Mỗi card = 1 nhiệm vụ hoặc tính năng cụ thể. • Thẻ nên ghi rõ:
o Tiêu đề ngắn gọn (VD: “Xây dựng màn hình đăng nhập”). o Mô tả
chi tiết hoặc link tài liệu yêu cầu. o Người phụ trách (Assignee).
o Nhãn (Labels) để phân loại: Tính năng mới (Feature), Sửa lỗi (Bug), Cải tiến (Improvement).
o Ngày hoàn thành (Deadline) nếu cần.
c. Giới hạn công việc đang làm (WIP – Work In Progress Limit) •
Đặt giới hạn cho mỗi cột, đặc biệt là Doing, để tránh làm dở nhiều việc
cùng lúc. o Ví dụ: “Doing” tối đa 3 task → nếu đã đủ 3 thì phải hoàn
thành một cái trước khi kéo thêm việc mới. lOMoAR cPSD| 58933639 •
Giúp tập trung, giảm tắc nghẽn, nâng cao chất lượng. d. Luồng công
việc liên tục (Continuous Flow) Không có Sprint như Scrum. • Quy trình làm việc:
o Chọn task từ Backlog → đưa vào To Do.
o Thành viên kéo task sang Doing khi bắt đầu làm. o Khi xong,
chuyển sang Testing/Review.
o Được kiểm duyệt/kiểm thử xong thì chuyển sang Done.
Luồng công việc diễn ra liên tục, không cần đợi hết
Sprint. e. Theo dõi và cải tiến •
Họp định kỳ (weekly/bi-weekly):
o Kiểm tra luồng công việc. o Xem chỗ nào bị nghẽn (VD:
nhiều task nằm ở Testing).
o Điều chỉnh quy trình, vai trò hoặc giới hạn WIP. •
Dùng các chỉ số để đo hiệu suất:
o Lead Time: thời gian từ lúc tạo task đến khi hoàn thành. o
Cycle Time: thời gian từ lúc bắt đầu làm đến khi hoàn thành.
o Cumulative Flow Diagram: theo dõi số lượng task trong
từng cột theo thời gian.
1.6Quản lý dự án bằng trello
Trello là một công cụ quản lý dự án trực quan, thường được dùng theo
mô hình Kanban. Khi quản lý dự án bằng Trello, bạn có thể hình dung
toàn bộ tiến trình công việc qua các thẻ (cards) và bảng (boards). lOMoAR cPSD| 58933639
2. Biểu đồ phân rã chức năng (BFD – Business Function Diagram) 2.1 Khái niệm
Biểu đồ phân rã chức năng (BFD – Business/Functional Decomposition
Diagram) Là biểu diễn phân rã có thứ bậc các nhiệm vụ chức năng của phần
mềm. Mỗi nhiệm vụ chức năng lại được chia ra làm nhiều công việc con. Số
mức phân chia theo chiều sâu và theo chiều rộng lại phụ thuộc vào độ phức tạp của hệ thống.
2.2 Mục đích sử dụng
• Xác định phạm vi và cấu trúc chức năng của hệ thống.
• Giúp quản lý dự án bằng cách chia nhỏ công việc phức tạp thành các nhiệm vụ rõ ràng.
• Là cơ sở để xây dựng các mô hình khác (DFD, Use Case…).
• Tạo ngôn ngữ trực quan giúp giao tiếp hiệu quả giữa nhà phát triển, khách hàng và nhà quản lý.
2.3 Ký hiệu trong BFD
• Chức năng: hình chữ nhật, tên chức năng ngắn gọn, rõ ràng.
• Cây phân cấp dọc/ngang: thể hiện quan hệ phân rã từ chức năng cha xuống các chức năng con. • Mức phân rã:
o Mức 0: hệ thống tổng thể.
o Mức 1, 2…: các chức năng con chi tiết hơn.
Nguyên tắc đặt tên: tên chức năng cần diễn đạt công việc cần làm một cách cụ thể, dễ hiểu.
2.4 Nguyên tắc phân rã
• Áp dụng phương pháp Top-down: mỗi chức năng mức trên được phân rã
thành nhiều chức năng mức dưới. • Đảm bảo:
o Các chức năng con thực sự tham gia vào việc thực hiện chức năng cha.
o Tập hợp tất cả các chức năng con phải bao quát đầy đủ chức năng cha. • Lưu ý:
o Không nên có quá 50 chức năng con trực tiếp dưới một chức năng cha.
o Với hệ thống lớn không nên quá 6 mức phân rã; hệ thống nhỏ không nên quá 3 mức.
o Các chức năng cùng cấp nên có độ quan trọng và mức chi tiết tương đồng.
o Chức năng mức lá nên chỉ còn một nhiệm vụ cụ thể (hoặc nhóm nhiệm
vụ nhỏ gắn với người dùng).
2.5 Quy trình xây dựng BFD
1. Xác định chức năng chính của hệ thống từ yêu cầu nghiệp vụ. lOMoAR cPSD| 58933639
2. Phân rã chức năng chính thành các chức năng con cấp 1 theo nguyên tắc phân rã.
3. Tiếp tục phân rã đến mức chi tiết cần thiết.
4. Mô tả chi tiết chức năng mức lá bằng lời hoặc kết hợp với các mô hình khác (như BPM).
- Ví dụ minh hoạ :
Hệ thống quản lý bán hàng:
• Mức 0: Quản lý bán hàng.
• Mức 1: Quản lý sản phẩm – Quản lý khách hàng – Quản lý đơn hàng – Quản lý thanh toán. • Mức 2:
o Quản lý đơn hàng → Tạo đơn hàng, Sửa đơn hàng, Xem chi tiết đơn hàng.
o Quản lý thanh toán → Thanh toán tiền mặt, Thanh toán chuyển khoản.
2.6 Ưu điểm và hạn chế
• Ưu điểm: trực quan, dễ hiểu, cho cái nhìn tổng thể và chi tiết, giúp chia
nhỏ vấn đề phức tạp thành phần dễ quản lý.
• Hạn chế: chỉ tập trung vào chức năng, chưa thể hiện dữ liệu và luồng
thông tin; hệ thống lớn dễ rối rắm; cần kết hợp với các mô hình khác để có cái nhìn toàn diện.
2.7 Ứng dụng thực tế
• Phân tích yêu cầu trong phát triển phần mềm.
• Giảng dạy các môn Phân tích & Thiết kế hệ thống.
• Doanh nghiệp: mô tả quy trình nghiệp vụ (quản lý nhân sự, bán hàng, thư viện, v.v.).
• Bài toán minh họa: chương trình quản lý bán đồ uống (sữa hạt, sữa thực vật). lOMoAR cPSD| 58933639
Biểu đồ phân rã (BFD) cho chương trình quản lý bán đồ uống sữa hạt