Quản lý dự án Agile là gì? Giải thích & Cách bắt đầu

Nhóm của bạn vừa dành sáu tháng để xây dựng chính xác những gì khách hàng yêu cầu. Buổi demo diễn ra hoàn hảo. Rồi họ nói: “Đây không còn là điều chúng tôi cần nữa. Thị trường đã thay đổi.”

Tôi đã chứng kiến kịch bản này phá hủy các dự án, ngân sách và tinh thần nhóm nhiều lần đến mức không thể đếm xuể.

Vấn đề không phải là yêu cầu thay đổi. Chúng luôn thay đổi. Vấn đề là xây dựng các quy trình giả định rằng chúng sẽ không thay đổi.

Trong quá trình phát triển, các nhóm phát triển phần mềm đã nhận ra một điều quan trọng: tại sao chúng ta không ngừng chống lại sự thay đổi mà thay vào đó, hãy đón nhận nó?

Sự thay đổi trong tư duy đó đã dẫn đến sự ra đời của quản lý dự án linh hoạt.

Điểm chính

Quản lý dự án linh hoạt là gì?

Quản lý dự án linh hoạt là một phương pháp tiếp cận lặp lại, mang lại giá trị thông qua các chu kỳ công việc ngắn gọi là sprint, thường kéo dài từ hai đến bốn tuần, trong đó các nhóm liên tục lập kế hoạch, thực hiện, đánh giá và điều chỉnh thay vì tuân theo một kế hoạch tuần tự cứng nhắc.

Thay vì mất hàng tháng để phát triển mọi thứ trước khi nhận được phản hồi, các nhóm sẽ phát hành phần mềm hoạt động sau mỗi vài tuần và điều chỉnh dựa trên những gì họ học được.

Điều này trực tiếp giải quyết vấn đề mà hầu hết các nhóm đang gặp phải với các chu kỳ phát triển kéo dài, khi mọi thứ được bàn giao cùng một lúc, chỉ để phát hiện ra rằng các yêu cầu đã thay đổi từ nhiều tháng trước.

Phương pháp quản lý dự án truyền thống theo mô hình thác nước (waterfall) cố định các yêu cầu ngay từ đầu và tiến hành qua các giai đoạn tuyến tính, trong đó mỗi giai đoạn phải hoàn thành trước khi giai đoạn tiếp theo bắt đầu.

Sự tham gia của khách hàng chủ yếu diễn ra trong giai đoạn thu thập yêu cầu ban đầu và giai đoạn bàn giao cuối cùng, không có hoạt động cụ thể nào ở giữa.

Phương pháp Agile hoàn toàn đảo ngược điều này. Khách hàng tham gia xuyên suốt vòng đời dự án, được xem phần mềm hoạt động sau mỗi đợt sprint.

Các nhóm sẵn sàng đón nhận những thay đổi về yêu cầu ngay cả khi đã ở giai đoạn phát triển muộn, coi đó là lợi thế cạnh tranh thay vì những vấn đề tốn kém.

Phương pháp này tập trung vào giá trị mang lại cho khách hàng trong phạm vi thời gian và ngân sách đã định bằng cách biến sự thay đổi thành điều bình thường thay vì ngoại lệ.

Tại sao Quản lý Dự án Linh hoạt lại quan trọng

Các tổ chức thực hiện thành công quá trình chuyển đổi linh hoạt báo cáo mức tăng khoảng 30% về hiệu quả, sự hài lòng của khách hàng và sự gắn kết của nhân viên.

Khi họ chuyển sang các chu kỳ sprint hai tuần, họ đã ra mắt tính năng hoạt động đầu tiên sau bốn tuần và điều chỉnh hướng đi dựa trên phản hồi thực tế từ khách hàng. Sự điều chỉnh đó đã cứu vãn dòng sản phẩm.

Tôi đã chứng kiến một khách hàng thuộc danh sách Fortune 500 vật lộn trong chín tháng với phương pháp lập kế hoạch theo mô hình thác nước trước khi nhận ra thị trường của họ đã thay đổi hoàn toàn.

Khi họ chuyển sang các chu kỳ sprint hai tuần, họ đã ra mắt tính năng hoạt động đầu tiên sau bốn tuần và điều chỉnh hướng đi dựa trên phản hồi thực tế từ khách hàng. Sự điều chỉnh đó đã cứu vãn dòng sản phẩm.

Nghiên cứu của Standish Group cho thấy các dự án linh hoạt đạt tỷ lệ thành công 42%, so với chỉ 13% đối với các dự án theo mô hình thác nước. Trong khi đó, các dự án theo mô hình thác nước thất bại 59% số lần, so với chỉ 11% đối với các dự án linh hoạt.

Đây không phải là những khác biệt nhỏ. Chúng thể hiện những cải thiện cơ bản trong cách các nhóm xử lý sự không chắc chắn và mang lại giá trị khi yêu cầu thay đổi.

Bạn đang tìm kiếm một cách dễ dàng để quản lý nhóm Agile của mình tại một nơi duy nhất? Tải miễn phí Mẫu Quản lý Agile của ClickUp tại đây!

Các nguyên tắc cốt lõi của quản lý dự án linh hoạt

Tuyên ngôn Agile đã xác lập bốn giá trị vào năm 2001, và những giá trị này vẫn tiếp tục định hướng cho các nhóm hiện đại. Đây không phải là những triết lý trừu tượng mà là những ưu tiên thực tiễn định hình các quyết định hàng ngày.

Những giá trị này không có nghĩa là từ bỏ hoàn toàn các quy trình, tài liệu, hợp đồng hay kế hoạch. Chúng chỉ đơn giản là ưu tiên những gì mang lại giá trị cao nhất khi buộc phải lựa chọn.

Cách thức công việc của Agile [Từng bước]

Các nhóm thực hiện phương pháp linh hoạt thông qua các chu kỳ sprint lặp lại, biến ý tưởng thành phần mềm hoạt động.

Mỗi sprint đều tuân theo cùng một nhịp độ, thường kéo dài hai tuần, giúp tạo ra sự dự đoán được đồng thời vẫn duy trì tính linh hoạt trong khuôn khổ đó.

1. Lập kế hoạch sprint

Chu kỳ bắt đầu với cuộc họp lập kế hoạch sprint, nơi nhóm lựa chọn các mục trong danh sách công việc (product backlog) mà họ tin rằng có thể hoàn thành trong suốt sprint.

Tuy nhiên, đây không phải là việc chọn công việc một cách ngẫu nhiên. Chủ sở hữu sản phẩm giải thích điều gì là quan trọng nhất vào thời điểm hiện tại, và các nhà phát triển đánh giá điều gì là khả thi dựa trên sức chứa hiện tại và tốc độ thực hiện trong quá khứ của họ.

Cùng nhau, họ xác định mục tiêu sprint mang lại ý nghĩa cho công việc, vượt xa việc chỉ hoàn thành danh sách công việc.

Nhóm cũng chia các công việc đã lựa chọn thành các công việc nhỏ hơn và lập kế hoạch để hoàn thành công việc.

2. Cuộc họp hàng ngày

Mỗi ngày trong suốt giai đoạn sprint, nhóm tổ chức một cuộc họp kiểm tra tiến độ kéo dài 15 phút để đảm bảo sự đồng bộ.

Đây không phải là các báo cáo trạng thái gửi cho quản lý. Thay vào đó, đây là các phiên làm việc nơi các nhà phát triển kiểm tra tiến độ hướng tới mục tiêu sprint và xác định các rào cản đang cản trở công việc.

Mỗi người chia sẻ những gì họ đã hoàn thành hôm qua, những gì họ đang xử lý hôm nay và bất kỳ điều gì cản trở tiến độ công việc.

Thời gian giới hạn chặt chẽ giúp mọi người tập trung vào vấn đề chính, và các cuộc thảo luận chi tiết sẽ diễn ra sau đó với sự tham gia của những người có liên quan.

3. Thực hiện sprint

Giữa các cuộc họp, các nhà phát triển tạo ra các phần công việc hoàn thiện đáp ứng định nghĩa "hoàn thành" của nhóm, tự quản lý công việc của mình và điều chỉnh kế hoạch hàng ngày dựa trên những gì họ học được.

Mục tiêu của sprint vẫn giữ nguyên, nhưng cách thức mà nhóm thực hiện có thể thay đổi khi họ gặp phải các thách thức kỹ thuật hoặc phát hiện ra các phương pháp hiệu quả hơn.

Không có thay đổi nào được thực hiện nếu điều đó đe dọa đến mục tiêu của sprint, mặc dù phạm vi có thể được làm rõ và đàm phán lại với chủ sở hữu sản phẩm khi nhóm thu thập thêm thông tin.

4. Đánh giá sprint

Vào cuối sprint, nhóm sẽ trình diễn công việc đã hoàn thành cho các bên liên quan trong một phiên làm việc thay vì một phiên thuyết trình chính thức, giúp phản hồi được phản ánh ngay lập tức vào các ưu tiên tiếp theo.

Các bên liên quan có thể xem phần mềm đang hoạt động, thực sự kiểm thử và đưa ra phản hồi dựa trên trải nghiệm thực tế thay vì các yêu cầu lý thuyết.

Danh sách công việc sản phẩm thường được điều chỉnh ngay tại chỗ dựa trên những gì mọi người học được từ việc xem xét bản phát triển.

5. Buổi đánh giá sprint

Buổi lễ kết thúc mỗi sprint bằng việc đánh giá những điều đã làm tốt, những vấn đề đã phát sinh và những cải tiến nào là quan trọng nhất cho sprint tiếp theo.

Nhóm sẽ đánh giá quá trình diễn ra của sprint về các khía cạnh liên quan đến cá nhân, tương tác, quy trình và công cụ.

Họ xác định những thay đổi có tác động lớn nhất để nâng cao hiệu quả và hoặc triển khai ngay lập tức, hoặc đưa chúng vào danh sách công việc của sprint tiếp theo.

Cơ chế cải tiến tích hợp sẵn này giúp các nhóm tránh lặp lại những sai lầm tương tự trong từng đợt sprint.

Nhịp điệu này tạo ra sự minh bạch, nơi mọi người đều có thể theo dõi công việc; quá trình kiểm tra, nơi tiến độ được đánh giá thường xuyên; và sự điều chỉnh, nơi quy trình được điều chỉnh khi quá trình kiểm tra phát hiện ra các vấn đề.

Các phương pháp Agile phổ biến nhất

Agile không phải là một phương pháp duy nhất mà là một hệ thống các khung làm việc. Ba khung làm việc chủ đạo trong thực tiễn hiện đại, và việc lựa chọn giữa chúng phụ thuộc vào loại công việc mà nhóm của bạn đảm nhận và mức độ dự đoán được của công việc đó.

Scrum

Scrum là khung làm việc phổ biến nhất với tỷ lệ áp dụng lên đến 63%, và điều này hoàn toàn có lý do.

Nó cung cấp các vai trò có cấu trúc bao gồm chủ sở hữu sản phẩm, người điều phối Scrum và các nhà phát triển, cùng với các nghi thức quy định và các sản phẩm đầu ra rõ ràng, giúp các nhóm có một điểm khởi đầu cụ thể.

Cấu trúc sprint có thời gian giới hạn tạo ra nhịp điệu và tính dự đoán được, đồng thời vẫn cho phép điều chỉnh trong từng chu kỳ.

Khung làm việc này phát huy hiệu quả tốt nhất trong quá trình phát triển sản phẩm phức tạp với các nhóm có 10 thành viên trở xuống, nơi các yêu cầu thay đổi liên tục sẽ được hưởng lợi từ việc lập kế hoạch linh hoạt.

Nếu bạn đang phát triển một sản phẩm mới mà nhu cầu của khách hàng thay đổi theo quá trình tìm hiểu, phương pháp lặp lại của Scrum cho phép bạn điều chỉnh hướng đi sau mỗi vài tuần thay vì cam kết với một kế hoạch dài hạn cứng nhắc.

Kanban

Kanban áp dụng một cách tiếp cận khác bằng cách nhấn mạnh vào luồng liên tục thay vì các chu kỳ cố định.

Các nhóm thể hiện công việc của mình trên bảng và cài đặt giới hạn công việc đang thực hiện để tránh quá tải và việc chuyển đổi ngữ cảnh.

Công việc được đưa vào hệ thống khi có đủ sức chứa, tạo ra một luồng công việc trơn tru và dễ dự đoán.

Phương pháp này đặc biệt phù hợp với các đội ngũ hỗ trợ sản xuất, đội bảo trì có khối lượng công việc liên tục và không thể dự đoán trước, cũng như các đội vận hành cung cấp dịch vụ liên tục với khối lượng công việc đến không ngừng.

Nếu nhóm của bạn xử lý các yêu cầu hỗ trợ, sửa lỗi hoặc yêu cầu về hạ tầng mà không thể chờ đến phiên lập kế hoạch sprint tiếp theo, mô hình liên tục của Kanban sẽ là lựa chọn phù hợp.

Lập trình Cực đoan (XP)

XP tập trung mạnh mẽ vào sự xuất sắc về mặt kỹ thuật thông qua các thực hành kỹ thuật có kỷ luật. Lập trình cặp (Pair programming) cho phép hai nhà phát triển làm việc cùng nhau tại một máy tính để thực hiện việc kiểm tra mã liên tục.

Phát triển hướng kiểm thử (Test-driven development) viết các bài kiểm thử thất bại trước khi viết mã. Tích hợp liên tục (Continuous integration) kiểm thử mã ngay lập tức khi được thêm vào để phát hiện vấn đề nhanh chóng.

Phương pháp này phù hợp nhất khi chất lượng mã là yếu tố quan trọng hàng đầu, các nhóm có quy mô nhỏ và có thể làm việc cùng nhau tại một địa điểm để phối hợp hiệu quả, và các yêu cầu thay đổi thường xuyên.

XP cung cấp các thực hành kỹ thuật giúp duy trì tính bảo trì của mã nguồn ngay cả khi yêu cầu thay đổi, khiến nó đặc biệt hữu ích cho các sản phẩm có tuổi thọ dài, nơi nợ kỹ thuật trở nên tốn kém.

Kết hợp các khung làm việc

Các nhóm thường kết hợp các khung làm việc để tận dụng những ưu điểm tốt nhất của từng phương pháp.

Scrum kết hợp với XP là mô hình kết hợp phổ biến nhất, sử dụng Scrum để xây dựng cấu trúc quản lý dự án trong khi XP đảm bảo chất lượng kỹ thuật thông qua các thực hành kỹ thuật có kỷ luật.

Sự kết hợp này mang đến cho bạn quy trình kế hoạch theo sprint và sự tham gia của các bên liên quan từ Scrum, cùng với các thực hành đảm bảo chất lượng mã nguồn từ XP giúp ngăn chặn nợ kỹ thuật tích tụ.

Khi Agile phát huy hiệu quả tối đa

Phương pháp linh hoạt phát huy hiệu quả khi có các điều kiện nhất định:

Các tình huống này chia sẻ một chủ đề: sự không chắc chắn, vốn được giải quyết hiệu quả hơn thông qua quá trình khám phá lặp đi lặp lại thay vì lập kế hoạch từ đầu.

Mặt trái của vấn đề cũng quan trọng không kém. Các yêu cầu cố định mà không có sự thay đổi dự kiến sẽ lãng phí tính linh hoạt của Agile, vì bạn đang phải chịu chi phí phát sinh từ việc thích ứng mà không thực sự cần thiết.

Tương tự, các môi trường chịu sự quản lý chặt chẽ như ngành dược phẩm lại đặt ra một thách thức khác do yêu cầu lượng tài liệu khổng lồ, điều mà phương pháp linh hoạt với cách tiếp cận gọn nhẹ vốn không đáp ứng được một cách tự nhiên.

Một số dự án cũng phải đối mặt với những hạn chế khiến việc lặp lại trở nên không thực tế. Các dự án xây dựng vật lý có những mối phụ thuộc chặt chẽ, trong đó các phương pháp tuần tự đơn giản là hợp lý hơn.

Và khi các hợp đồng bao gồm cấu trúc giá cố định với các kết quả đã được xác định trước và các hình phạt nghiêm ngặt, chúng mâu thuẫn cơ bản với việc phương pháp linh hoạt chấp nhận phạm vi công việc có thể thay đổi.

Trước khi commit, ba điều kiện tiên quyết sau đây sẽ quyết định tính khả thi:

Nếu bạn trả lời "không" cho bất kỳ câu hỏi nào, các phương pháp kết hợp (hybrid) kết hợp các thực hành linh hoạt với cấu trúc dự án truyền thống thường hợp lý hơn so với việc áp dụng một phương pháp luận không phù hợp với các hạn chế của bạn.

Cách bắt đầu với quản lý dự án linh hoạt

Để bắt đầu áp dụng agile, cần có một lộ trình có chủ đích thay vì cố gắng thực hiện sự chuyển đổi ngay lập tức. Dưới đây là cách chuyển từ giai đoạn kế hoạch sang sprint thành công đầu tiên của bạn.

Trước khi đi vào chi tiết, video này sẽ cung cấp một nền tảng vững chắc về cách thức áp dụng agile trong thực tế:

Trước khi công bố một cuộc chuyển đổi linh hoạt, hãy đánh giá xem môi trường của bạn có thực sự hỗ trợ được điều đó hay không. Hãy xem xét loại dự án của bạn trước tiên và xác nhận rằng nó có các yêu cầu thay đổi liên tục và cần phản hồi thường xuyên. Sau đó, hãy xem xét liệu các thành viên trong nhóm có sẵn sàng thay đổi cách làm việc của họ hay không, hay bạn sẽ phải đối mặt với sự kháng cự đã ăn sâu. Cuối cùng, hãy đảm bảo các bên liên quan và lãnh đạo hiểu rằng họ cần tham gia tích cực trong suốt quá trình thay vì chỉ nhận báo cáo trạng thái vào cuối cùng. Nếu thiếu bất kỳ yếu tố nào trong số này, hãy khắc phục những lỗ hổng đó trước khi tiến hành. Các cuộc chuyển đổi linh hoạt thường thất bại do thiếu sự hỗ trợ từ tổ chức hơn là do các vấn đề kỹ thuật trong quá trình thực hiện.

Sau khi xác nhận đã sẵn sàng, hãy chọn một khung làm việc và cam kết áp dụng nó trong ít nhất ba tháng. Scrum cung cấp cấu trúc phù hợp cho các nhóm phát triển sản phẩm, trong khi Kanban thích hợp cho các công việc theo luồng như hỗ trợ và bảo trì. Nếu chất lượng kỹ thuật là mối quan tâm hàng đầu của bạn, XP tập trung vào các thực hành kỹ thuật như lập trình cặp và phát triển hướng kiểm thử. Chìa khóa là nắm vững hoàn toàn một phương pháp trước khi kết hợp các khung làm việc, vì bạn cần hiểu lý do tồn tại của từng yếu tố trước khi bắt đầu tùy chỉnh nó cho tình huống cụ thể của mình.

Sau khi đã chọn được khung làm việc, hãy chọn một dự án quan trọng đối với kinh doanh nhưng sẽ không gây tổn hại nghiêm trọng cho công ty nếu gặp vấn đề. Điều này giúp bạn có không gian để học hỏi mà không phải đối mặt với hậu quả thảm khốc. Lập kế hoạch cho hai đến ba sprint (từ bốn đến mười hai tuần) làm giai đoạn đánh giá, giữ quy mô nhóm nhỏ từ bốn đến năm người để chi phí điều phối không làm lu mờ việc liệu phương pháp linh hoạt có thực sự hiệu quả hay không. Đảm bảo họ có thể dành toàn bộ thời gian cho dự án thử nghiệm thay vì phân tán sự chú ý vào nhiều dự án khác nhau.

Dự án thử nghiệm của bạn cần ba vai trò chính hoạt động hiệu quả ngay từ ngày đầu tiên. Chủ sở hữu sản phẩm phải được trao quyền để đưa ra các quyết định chi tiêu hàng ngày mà không cần xin phê duyệt từ cấp trên, và họ cần luôn sẵn sàng hỗ trợ nhóm thay vì biến mất hàng ngày liền. Người điều phối Scrum nên hỗ trợ quá trình và loại bỏ các rào cản thay vì quản lý nhân sự theo cách truyền thống. Cuối cùng, hãy tập hợp một nhóm phát triển đa chức năng có đầy đủ các kỹ năng cần thiết để hoàn thành công việc mà không bị phụ thuộc vào các yếu tố bên ngoài làm chậm tiến độ. Những vai trò này không phải là những yếu tố bổ sung tùy chọn mà bạn có thể bỏ qua. Chúng là những yêu cầu cơ bản để phương pháp Agile hoạt động đúng như thiết kế.

Bắt đầu lập kế hoạch sprint bằng cách để chủ sở hữu sản phẩm giải thích các ưu tiên hiện tại trong khi nhóm lựa chọn công việc mà họ tin rằng có thể hoàn thành. Hợp tác để xác định "đã xong" thực sự có nghĩa là gì đối với nhóm của bạn để mọi người đều chia sẻ cùng một tiêu chuẩn, sau đó lên lịch cho tất cả các buổi họp định kỳ như họp đứng hàng ngày, đánh giá sprint và nhìn lại, đồng thời bảo vệ thời gian đó khỏi các cuộc họp khác. Sau đó, bắt đầu xây dựng và hãy chuẩn bị tinh thần rằng sprint đầu tiên sẽ cảm thấy lúng túng, vì điều đó luôn xảy ra. Các nhóm thường cần từ ba đến năm sprint để tìm được nhịp điệu và thiết lập tốc độ đáng tin cậy.

Câu hỏi thường gặp

Sự cải thiện ngay lập tức trong giao tiếp nhóm đã xuất hiện ngay trong sprint đầu tiên. Quá trình chuyển đổi của John Deere cho thấy thời gian chu kỳ giảm 79% trong vòng sáu tháng. Lợi ích trung hạn đạt mức tăng năng suất 165%. Sự trưởng thành lâu dài sau 12 đến 24 tháng tạo ra văn hóa tự duy trì với tỷ suất hoàn vốn (ROI) tối đa.

Agile là một triết lý được đề cập trong Tuyên ngôn Agile, bao gồm các giá trị và nguyên tắc. Scrum là một khung làm việc áp dụng Agile với các vai trò, sự kiện và tài liệu được định nghĩa rõ ràng. Hãy xem Agile như một triết lý sống lành mạnh, trong khi Scrum là một chế độ ăn uống và kế hoạch tập luyện cụ thể.

Đúng vậy, thường là hiệu quả hơn. Hướng dẫn Scrum khuyến nghị ba thành viên tối thiểu, nhưng các nhóm nhỏ hơn cũng thích ứng tốt. Họ liên lạc liên tục, loại bỏ các cuộc họp đứng chính thức. Các nhóm lớn hơn tốn kém gấp ba đến bốn lần và có nhiều lỗi hơn. Duy trì các buổi đánh giá lại và xem xét áp dụng các thực hành Kanban hoặc XP.

Kết luận

Không phải là bí mật khi quản lý dự án Agile là một trong những phương pháp quản lý dự án phổ biến nhất trên thế giới.

Điều này rất đơn giản và nhanh chóng, giúp nhóm của bạn hoàn thành các công việc và dự án một cách dễ dàng và nhanh chóng!

Ngoài ra, vì các phương pháp này nhấn mạnh việc tùy chỉnh dựa trên phản hồi của khách hàng, bạn có thể yên tâm rằng sản phẩm bạn tung ra thị trường sẽ được khách hàng yêu thích.

Nếu bạn đang muốn áp dụng các phương pháp quản lý dự án Agile, tại sao không thử một phần mềm như ClickUp?

Nó có mọi thứ bạn cần để quản lý các dự án và sprint một cách dễ dàng! Đăng ký ngay hôm nay để sử dụng phiên bản miễn phí vĩnh viễn của ClickUp