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 để phát triển chính xác những gì khách hàng yêu cầu. Buổi trình diễn 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ỏng các dự án, ngân sách và tinh thần làm việc của 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 chủ động đón nhận nó?

Dưới đây là cách để trở thành một nhà quản lý dự án (PM) am hiểu về AI →

Trong cẩm nang quản lý dự án dành cho AI, bạn sẽ nhận được:

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

Những điểm chính cần lưu ý

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ì dành hàng tháng trời để phát triển toàn bộ sản phẩm 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 được 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: chu kỳ phát triển kéo dài, trong đó mọi thứ được bàn giao cùng một lúc, chỉ để rồi 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 theo 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, trong khi không có hoạt động cụ thể nào diễn ra ở 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 và đượ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 cuối của quá trình phát triể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 luôn 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 coi sự thay đổi là điều bình thường chứ không phải là 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 cho biết 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 tăng khoảng 30%.

Khi chuyển sang các đợt sprint kéo dài hai tuần, họ đã ra mắt tính năng hoạt động đầu tiên chỉ 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 phải vật lộn trong chín tháng với quy trình 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 chuyển sang các đợt sprint kéo dài hai tuần, họ đã ra mắt tính năng hoạt động đầu tiên chỉ 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 trong 59% trường hợp, 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 các yêu cầu thay đổi.

Bạn đang tìm kiếm một cách đơn giản để 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à phải 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 yếu tố 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 Agile thông qua các chu kỳ sprint lặp đi lặp lại, biến ý tưởng thành phần mềm hoạt động được.

Mỗi đợt 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 tính dự đoán được đồng thời vẫn duy trì sự linh hoạt trong khuôn khổ đó.

1. Lập kế hoạch sprint

Chu kỳ bắt đầu bằng phiên 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 sản phẩm (product backlog) mà họ tin rằng có thể hoàn thành trong suốt sprint.

Tuy nhiên, đây không chỉ đơn thuần là việc chọn các công việc một cách ngẫu nhiên. Chủ sở hữu sản phẩm sẽ giải thích điều gì là quan trọng nhất vào thời điểm hiện tại, còn các nhà phát triển sẽ đánh giá xem đ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 của sprint, giúp công việc có ý nghĩa hơn là chỉ đơn thuần hoàn thành một danh sách công việc.

Nhóm cũng chia nhỏ các mụ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 buổi 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 tiến độ gửi cho quản lý. Thay vào đó, đây là các phiên làm việc mà tạ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ì mình đã hoàn thành hôm qua, những việc đang thực hiện hôm nay và bất kỳ trở ngại nào đang 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à bất kỳ cuộc thảo luận chi tiết nào cũng 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 định kỳ, các nhà phát triển tạo ra các giai đoạn hoàn thiện đáp ứng định nghĩa về "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 được giữ nguyên, nhưng cách thức mà nhóm thực hiện để đạt được mục tiêu đó có thể thay đổi khi họ gặp phải những thách thức kỹ thuật hoặc phát hiện ra những 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 đó có thể đe dọa mục tiêu của sprint, mặc dù phạm vi công việc 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 mỗi sprint, nhóm sẽ trình diễn các 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 nhận được ngay lập tức định hướng cho các ưu tiên tiếp theo.

Các bên liên quan có thể trải nghiệm phần mềm đang hoạt động, từ đó 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 các đợt phát triển.

5. Buổi tổng kết sprint

Buổi lễ tổng kết sẽ khép lại mỗi đợt sprint bằng cách đá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 đợt 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ự từ sprint này sang sprint khác.

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à khả năng thích ứng, 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. 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 cũng như 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 tới 63%, và điều này hoàn toàn có lý do chính đáng.

Các phương pháp này quy định các vai trò có cấu trúc, bao gồm chủ sở hữu sản phẩm (Product Owner), người điều phối Scrum (Scrum Master) và các nhà phát triển, cùng với các nghi thức được quy định sẵn và các tài liệu 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 cố định 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 linh hoạt 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ó quy mô 10 người trở xuống, nơi các yêu cầu thay đổi liên tục đòi hỏi 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 bạn tìm hiểu thêm, 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ì phải commit 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ỳ lặp cố định.

Các nhóm trình bày 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 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 nhóm hỗ trợ sản xuất, nhóm bảo trì phải đối mặt với khối lượng công việc liên tục và khó dự đoán, cũng như các nhóm vận hành cung cấp dịch vụ liên tục, nơi công việc liên tục đổ về.

Nếu nhóm của bạn phải xử lý các yêu cầu hỗ trợ, sửa lỗi hoặc cá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ã nguồn liên tục.

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

Phương pháp này phù hợp nhất khi chất lượng mã nguồn 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 địa điểm để phối hợp hiệu quả, đồng thời 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 dễ bảo trì của cơ sở mã 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ó vòng đời 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 làm khung 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 phương pháp Agile phát huy hiệu quả tối đa

Phương pháp Agile phát huy hiệu quả khi đáp ứng 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 phương pháp 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 nhẹ nhàng vốn không thể đáp ứng 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 áp dụng phương pháp lặp lại trở nên không khả thi. Các dự án xây dựng công trình 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à phù hợp hơn.

Và khi các hợp đồng áp dụng cơ cấu 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 sẽ mâu thuẫn cơ bản với triết lý của phương pháp linh hoạt, vốn chấp nhận phạm vi dự án có thể thay đổi.

Trước khi commit, có ba điều kiện tiên quyết 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 tiếp cận 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 là lựa chọn 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

Việc bắt đầu áp dụng agile đòi hỏi 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 sâu vào các chi tiết cụ thể, 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ố quá trình 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. Trước tiên, hãy xem xét loại dự án của bạ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 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à ban 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 dự án. 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ếp tục. Các cuộc chuyển đổi linh hoạt thường thất bại do thiếu 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.

Khi đã xác nhận rằng tổ chức của bạ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 với các nhóm phát triển sản phẩm, trong khi Kanban phù hợp với các công việc có luồng liên tục 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ử. Điều quan trọng là phải 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, bởi vì bạn cần hiểu lý do tại sao mỗi yếu tố tồn tại trước khi bắt đầu tùy chỉnh nó cho phù hợp với 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 doanh nghiệp nhưng sẽ không gây ảnh hưởng nghiêm trọng đến 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 những 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 kỳ đánh giá, đồng thời giữ quy mô nhóm nhỏ, khoảng bốn đến năm người, để chi phí điều phối không làm lu mờ hiệu quả thực sự của phương pháp linh hoạt. Đảm bảo rằng họ có thể dành toàn bộ thời gian cho dự án thử nghiệm thay vì phải phân chia sự chú ý cho 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 (Product Owner) 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 (Scrum Master) nên tập trung vào việc điều phối quy trình và loại bỏ các rào cản thay vì quản lý con người theo cách truyền thống. Cuối cùng, hãy thành lập một nhóm phát triển đa chức năng, sở hữu đầy đủ các kỹ năng cần thiết để hoàn thành công việc mà không bị các yếu tố phụ thuộc 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 về mặt cấu trúc để 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ãy cùng nhau 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ẻ 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à tổng kết, đồng thời bảo đảm thời gian đó không bị trùng với các cuộc họp khác. Sau đó, bắt đầu triển khai và hãy chuẩn bị tinh thần rằng sprint đầu tiên sẽ có phần bỡ ngỡ, vì điều này 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 làm việc và thiết lập tốc độ phát triển ổn định.

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

Phải mất bao lâu thì chúng ta mới thấy được kết quả từ phương pháp linh hoạt?

Những cải thiện ngay lập tức trong giao tiếp nhóm đã xuất hiện ngay từ 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. Các lợi ích trung hạn đạt mức tăng năng suất lên đến 165%. Sự trưởng thành lâu dài sau 12 đến 24 tháng sẽ tạo ra một văn hóa tự duy trì với tỷ suất hoàn vốn (ROI) tối đa.

Sự khác biệt giữa phương pháp linh hoạt và Scrum là gì?

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ể.

Các nhóm nhỏ từ hai đến ba người có thể áp dụng phương pháp Agile một cách hiệu quả không?

Đúng vậy, thường là hiệu quả hơn. Hướng dẫn Scrum khuyến nghị ba nhóm nhỏ nhất định, 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, do các phương pháp này nhấn mạnh việc điều chỉnh dựa trên phản hồi của khách hàng, bạn có thể hoàn toàn yên tâm rằng sản phẩm mà bạn tung ra thị trường sẽ được khách hàng yêu thích.

Nếu bạn đang có ý định áp dụng các phương pháp quản lý dự án Agile, tại sao không thử sử dụng 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à các đợt 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