You are on page 1of 5

1.

Phương pháp quản lý dự án Agile


Agile là một phương pháp hiệu quả, đơn giản trong những dự án phần mềm
yêu cầu nhiều về sự linh hoạt. Bí quyết là sự giao tiếp, chia sẻ ý tưởng thường
xuyên giữa những đội ngũ, cụ thể hơn là các gợi ý dưới đây:
• Tổ chức các cuộc họp hàng ngày để theo dõi sát sao tiến độ công việc
của mọi người
• Sau mỗi giai đoạn triển khai, tổ chức một buổi ra mắt thành phẩm để
khích lệ đội ngũ đã đóng góp
• Thu thập, chia sẻ phản hồi để sự phối hợp trong công việc đạt hiệu quả
cao nhất
• Tiếp nhận nhiều ý kiến, nhưng hãy biết chắt lọc những gì tốt nhất cho
sản phẩm

1.1. Ưu điểm
● Tăng tính linh hoạt trong dự án
Phương pháp Agile cho phép dự án phát triển theo từng giai đoạn ngắn hạn,
giúp tăng tính linh hoạt trong quá trình quản lý dự án. Việc chia dự án thành
các giai đoạn ngắn hạn cũng giảm thiểu các rủi ro trong việc phát triển sản
phẩm dự án.
● Tập trung vào phản hồi của khách hàng và người dùng
Cả khách hàng và người dùng cuối đều có thể cung cấp ý tưởng và phản hồi
của họ về dự án. Chính vì vậy gây tác động mạnh mẽ và tích cực đến sản phẩm
cuối cùng.
● Đưa sản phẩm ra thị trường nhanh hơn
Bằng cách giao các phần việc trong các chu kỳ ngắn, các dự án Agile có thể đạt
được thời gian đưa sản phẩm ra thị trường nhanh hơn so với các phương pháp
truyền thống. Điều này cho phép tổ chức nắm bắt cơ hội thị trường sớm hơn và
thu thập phản hồi từ người dùng sớm trong quá trình phát triển.
● Không ngừng cải tiến
Nó khuyến khích các thành viên trong nhóm và khách hàng cung cấp phản hồi
của riêng họ. Khi đó các giai đoạn khác nhau của sản phẩm cuối cùng có thể
được kiểm tra và cải tiến nhiều lần nếu cần.
● Giảm chi phí và tăng hiệu quả trong việc quản lý dự án
Bằng cách sử dụng các công cụ và phương pháp linh hoạt.

1.2. Nhược điểm


• Khả năng dự báo thấp: Vì Agile ưu tiên sự thích ứng và sự linh hoạt,
việc dự đoán được sản phẩm hoặc dịch vụ cuối cùng có thể khá khó khăn.
• Khó khăn trong việc ước lượng thời gian và chi phí: Do tính linh hoạt và
khả năng thay đổi thường xuyên, việc ước lượng thời gian và chi phí để hoàn
thành dự án có thể trở nên khó khăn.
• Đòi hỏi sự tham gia mạnh mẽ của khách hàng: Agile đề cao việc tương
tác và phản hồi thường xuyên từ khách hàng. Tuy nhiên, nếu khách hàng không
tham gia đủ mạnh mẽ, dự án có thể mắc phải vấn đề về thiếu thông tin hoặc
quyết định chậm chạp.
• Dễ dẫn đến việc thiếu tài liệu: Với việc tập trung vào sản phẩm hoạt
động hơn là tài liệu, dự án Agile có thể dẫn đến việc thiếu tài liệu cần thiết cho
việc hiểu rõ quá trình phát triển và sản phẩm cuối cùng. Điều này có thể gây
khó khăn trong việc duy trì và chia sẻ kiến thức về dự án trong tương lai.
• Khó khăn trong việc quản lý dự án lớn: Agile thường hoạt động tốt cho
các dự án nhỏ đến trung bình. Tuy nhiên, khi đối mặt với dự án lớn và phức
tạp, việc duy trì sự linh hoạt và quản lý các tương tác phức tạp có thể trở nên
khó khăn hơn.
• Đòi hỏi kỹ năng và kiến thức cao: Agile đòi hỏi các thành viên trong
nhóm dự án có kỹ năng và kiến thức cao trong việc làm việc hợp tác, quản lý
thời gian và giải quyết vấn đề một cách linh hoạt.
• Không phù hợp với mọi loại dự án: Phương pháp Agile thích hợp cho
các dự án có tính linh hoạt cao và yêu cầu thay đổi thường xuyên. Tuy nhiên,
nó không phù hợp với mọi loại dự án, đặc biệt là các dự án có tính chất cố định
và yêu cầu kế hoạch chi tiết từ đầu.

1.3. Mô hình Agile phù hợp với các dự án có các đặc điểm sau:
• Yêu cầu thay đổi thường xuyên: Các yêu cầu của dự án có thể thay đổi
theo thời gian, chẳng hạn như do sự thay đổi của thị trường, nhu cầu của khách
hàng hoặc các yếu tố bên ngoài khác. Mô hình Agile cho phép các dự án thích
ứng với những thay đổi này một cách nhanh chóng và hiệu quả.
• Sản phẩm hoặc dịch vụ phức tạp: Các sản phẩm hoặc dịch vụ phức tạp
thường khó dự đoán về thời gian và chi phí hoàn thành. Mô hình Agile chia
nhỏ dự án thành các giai đoạn nhỏ hơn, dễ quản lý hơn, giúp giảm thiểu rủi ro
và chi phí phát sinh.
• Có sự tham gia của nhiều bên liên quan: Các dự án có sự tham gia của
nhiều bên liên quan, chẳng hạn như khách hàng, nhà cung cấp, đối tác,...
thường cần sự phối hợp chặt chẽ giữa các bên. Mô hình Agile nhấn mạnh vào
sự hợp tác và giao tiếp giữa các bên liên quan, giúp đảm bảo dự án được thực
hiện thành công.
Một số ví dụ về các dự án phù hợp với mô hình Agile bao gồm:
• Phát triển phần mềm
• Thiết kế website
• Marketing
• Sales
• Sản xuất
• Dịch vụ khách hàng
• Giáo dục
Tuy nhiên, không phải tất cả các dự án đều phù hợp với mô hình Agile. Mô
hình Agile đòi hỏi sự tham gia tích cực của các thành viên trong nhóm, sự phối
hợp chặt chẽ giữa các bên liên quan và khả năng thích ứng với thay đổi. Nếu
một dự án không đáp ứng được các yêu cầu này, thì việc áp dụng mô hình
Agile có thể không hiệu quả.
Dưới đây là một số điều kiện tiên quyết cần đáp ứng để áp dụng mô hình Agile
thành công:
• Sự cam kết của các bên liên quan: Tất cả các bên liên quan cần cam kết
thực hiện theo các nguyên tắc và phương pháp của mô hình Agile.
• Sự sẵn sàng thay đổi: Các thành viên trong nhóm cần sẵn sàng thay đổi
kế hoạch và cách thức làm việc khi cần thiết.
• Kỹ năng giao tiếp và hợp tác: Các thành viên trong nhóm cần có kỹ
năng giao tiếp và hợp tác tốt để làm việc cùng nhau hiệu quả.
Nếu một dự án đáp ứng được các điều kiện tiên quyết này, thì việc áp dụng mô
hình Agile có thể giúp dự án đạt được thành công.

VÍ DỤ MINH HỌA
Việc áp dụng thực tế trong các doanh nghiệp có vẻ như là không phải doanh
nghiệp nào cũng áp dụng đúng, nhiều doanh nghiệp có áp dụng nhưng chỉ nửa
mùa, không đạt được hiệu quả cao.
Tuy nhiên thì có những công ty áp dụng khá là chuẩn chỉnh và bài bản, ví dụ
quá trình này diễn ra thực tế như sau:
Bước 1: Product Backlog (một danh sách chứa tất cả những thứ cần cho sản
phẩm đó. Là một danh sách được quản lý và sắp xếp thứ tự bởi Product Owner)
sẽ được truyền thông tới team trước 1 hoặc 2 quý, cái này các PO thu thập nhu
cầu từ các stakeholder và định nghĩa ra được một cái roadmap tổng thể.
Bước 2: Tùy vào scope (phạm vi) dự án mà sprint sẽ được triển khai theo 2
tuần, hoặc 3 tuần (rất ít khi), thông thường thì là 2 thôi, còn nếu 3 thì là đính
kèm thêm một vài story nữa.
Bước 3: Trước mỗi sprint (khoảng thời gian tiến hành tất cả các hoạt động cần
thiết để sản xuất được một phần tăng trưởng có khả năng chuyển giao được) cả
team sẽ cùng nhau họp Grooming (một hoạt động quan trọng trong kế hoạch
hoá và chuẩn bị cho Sprint trong phương pháp Agile), mục đích để làm rõ
những yêu cầu chung về dự án, tài liệu, những thứ cần làm và có thể sẽ làm
trong sprint. Ở buổi grooming thì cả team cũng sẽ nhìn lại OKR (công cụ được
triển khai nhằm hỗ trợ việc quản lí mục tiêu, đảm bảo việc hợp tác giữa các cá
nhân trong tổ chức được diễn ra xuyên suốt, tập trung vào các nỗ lực đóng góp
của cá nhân, nhóm, tổ chức, đo lường các đóng góp ấy để giúp tổ chức phát
triển) hiện tại đã đạt được những gì, và giai đoạn sắp tới cần phải đi theo lộ
trình nào cũng sẽ được làm rõ.
Bước 4: Sau buổi họp Grooming sẽ là buổi họp Planning, ở buổi này sau khi
mọi người đã nghiên cứu giải pháp, nghiên cứu tài liệu thì sẽ tiến hành vạch ra
những thứ cần làm, những thứ cần giải quyết một cách chi tiết, đồng thời sẽ
tiến hành estimate nguồn lực chung cho từng story.
Ở buổi này sẽ chốt sprint goal (tức là kiểu mục tiêu đạt được cuối cùng sau khi
kết thúc sprint)
Bước 5: Sau khi estimate xong nguồn lực, tiến hành break sub-task và assgin
task, thường sẽ estimate qua đơn vị point, sau khi break xong thì cả team ngồi
lại và review về khối lượng công việc cũng như nguồn lực trong dự án để điều
chỉnh lại cho phù hợp,
Điều chỉnh ở đây có thể là: cắt bu ủa ỏ scope chưa quan trọng, ưu tiên những
phần scope quan trọng, hoặc các thành viên có người có lịch nghỉ nên cần
backup, hoặc ti tỉ thứ khác nữa cũng quan trọng cần ưu tiên.
Bước 6: Sau khi mọi thứ ở trên đã diễn ra xong, thì việc tiến hành sprint bắt
đầu, hằng ngày sẽ có daily meeting tối đa là 15p để cả nhóm cùng nhau báo cáo
công việc của ngày hôm trước, thường mỗi người báo cáo sẽ theo format sau:
1. Hôm qua đã làm những gì, xử lý những gì
2. Có gặp issue, blocker gì không
3. Hôm nay xử lý những gì
Với những bạn đã quen làm việc với kiểu trong môi trường mà cả tuần mới báo
cáo 1 lần, hoặc có khi cả tháng mới phải báo cáo 1 lần thì có vẻ khi vào môi
trường sử dụng scrum thì sẽ hơi ngợp chút, nhưng sẽ không sao đâu, các bạn sẽ
làm quen rất nhanh thôi.
Bước 7: Cuối mỗi sprint sẽ diễn ra buổi review, cả team ngồi lại với nhau để
thực hiện demo, review lại những thứ đã làm để đánh giá kết quả, thành tựu đạt
được trong sprint.
Bước 8: Buổi retrospective (được tổ chức khi kết thúc mỗi Sprint, để cả team
cùng ngồi lại với nhau, và thảo luận xem điều gì đã làm đúng và điều gì cần cải
thiện. Nhưng vì guồng quay của các Sprint, mà rất nhiều team bỏ qua bước này.
Nhưng thực sự thì nó quan trọng như một buổi kiểm tra sức khỏe, đảm bảo
rằng cả co n thuyền vận hành tốt với thủy thủ có một sức khỏe tốt) có thể diễn
ra cùng buổi review luôn cũng được nếu có nhiều thời gian, hoặc không thì
tách ra thành buổi riêng cũng được, cơ bản thì buổi retro cũng không quá lâu,
chủ yếu để các thành viên trong nhóm đánh giá những điều đã làm tốt, những
điều chưa tốt cần cải thiện và đưa ra các biện pháp cải tiến cho những sprint
tiếp theo.

You might also like