Phương pháp quản lí dự án Agile ngày càng được áp dụng rộng rãi hơn. Vậy bạn có thực sự hiểu rõ Agile là gì, hay với bạn, đây đơn thuần chỉ là một phương pháp làm việc nhanh chóng hơn. Hãy đọc bài viết sau để có một cái nhìn tổng quát hơn về phương pháp Agile nhé.
Với những lãnh đạo doanh nghiệp không thực sự hiểu phương pháp Agile là gì, họ thường nghĩ Agile đơn giản là làm việc nhanh hơn.
Tôi thường nghe các doanh nghiệp tuyên bố “Chúng tôi giờ là doanh nghiệp Agile…” hoặc một ai đó trong bộ phận quản lý nói với nhóm phát triển: “Hãy áp dụng phương pháp Agile...” mà chẳng cho họ một chương trình đào tạo nào. Một vài người trong ban lãnh đạo có thể rất hào hứng với ý tưởng này và nói “chúng ta cần phải “Agile” hơn…”, trong khi có người lại hoàn toàn nghi ngờ và tin rằng nếu không có các tài liệu thông thường thì không thể làm việc hiệu quả. Từ những ví dụ này, hẳn các bạn có thể thấy rằng một trong những thách thức lớn nhất khi áp dụng một mô hình mới như Agile chính là “quản lý” kì vọng của ban lãnh đạo.
Với những lãnh đạo doanh nghiệp không thực sự hiểu phương pháp Agile là gì, họ thường nghĩ Agile đơn giản là làm việc nhanh hơn. Họ không hiểu hoặc quan tâm đến việc sẽ cần có những thay đổi trong cả quy trình và cách thức làm việc để phương pháp này có hiệu quả. Các lãnh đạo rất vui mừng với triển vọng công việc được hoàn thành nhanh hơn, nhưng họ vẫn muốn có biểu đồ Gantt trong Microsoft Project, báo cáo tiến độ, báo cáo ngân sách và một phạm vi công việc được trình ký đầy đủ. Chưa kể là khi họ cần xử lý một cuộc khủng hoảng, họ muốn có quyền được dừng dự án của bạn lại và phân bổ tài nguyên của bạn đến các dự án khác - nhưng bạn vẫn cần phải hoàn thành dự án trong thời gian sớm, vì giờ bạn đã áp dụng Agile! Để tránh gặp phải những điều này, cung cấp đào tạo và trao đổi thông tin từ sớm chính là chìa khóa thành công.
Dưới đây là một vài yếu tố quan trọng bạn cần các nhà quản lý và ban lãnh đạo trong doanh nghiệp hiểu về phương pháp Agile:
Phân đoạn đầu tiên bao giờ cũng khó khăn nhất. Vì nhóm phát triển phải học cách ước tính công việc của mình theo theo một cách hoàn toàn mới là “story points” và đánh giá khối lượng công việc có thể đưa vào một khung thời gian đã được thiết lập sẵn. Thường thì nhóm phát triển hay đánh giá sai và không thể hoàn thành hết mọi công việc họ đã đề ra. Phải sau 1 hoặc 2 phân đoạn (iteration) thì nhóm phát triển mới ước lượng được đúng tốc độ (velocity) hoặc số lượng “story points” mà họ có thể hoàn thành trong một phân đoạn. Chỉ khi đó thì chúng ta mới nên đưa ra một kế hoạch cụ thể để xác định xem cần bao nhiêu phân đoạn để hoàn thành hết tất cả các tính năng được đưa ra trong bản kế hoạch.
Một trong các lợi thế của Agile là sự linh hoạt trong việc thay đổi phạm vi công việc giữa các phân đoạn. Tuy nhiên có một nguyên tắc cơ bản mọi người cũng cần nhớ là một khi phạm vi hay “sprint” đã được thiết lập, không ai được can thiệp vào hoạt động của nhóm. Điều này đồng nghĩa với việc không lãnh đạo cấp cao nào có thể điều phối các thành viên nhóm phát triển chuyển sang làm một dự án khác. Đây là một trong những lí do tại sao các phân đoạn thường diễn ra trong thời gian ngắn - không quá 30 ngày hoặc ngắn hơn - để các thành viên có thời gian “đổi gió” và làm công việc khác. Nhưng cách này cũng có thể gặp vấn đề khi một đội vừa phải sửa lỗi, vừa phải phát triển tính năng mới cho sản phẩm. Một giải pháp cho vấn đề này là tạo ra trong mỗi phân đoạn một vài “buffer stories” cho việc sửa các lỗi chưa xác định được. Nếu có lỗi nghiêm trọng xảy ra, công việc này có thể được giao cho một thành viên trong nhóm.
Trong một nhóm Agile, sẽ không có kiểu ra lệnh hay kiểm soát truyền thống. Cụ thể hơn, sẽ không có nhà quản lý theo kiểu truyền thống nào. Chuyên gia về Mô hình phát triển phần mềm Scrum - một quy trình của phương pháp Agile - không có quyền hạn trực tiếp mà có vai trò giống như một điều phối viên. Khi áp dụng Agile, các thành viên trong nhóm tự nhận nhiệm vụ từ danh sách công việc - đây là điều nhiều nhà quản lý không thích vì họ không tin là các thành viên có đủ động lực làm việc khi không có sự tồn tại của một người giám sát.
Hầu hết các chuyên gia về Scrum lại không đồng tình với ý kiến này. Ngược lại, họ nghĩ khi theo Agile, họ còn phải “hãm” các thành viên trong nhóm để các thành viên không ôm đồm quá nhiều việc. Lí do là vì khi tự chịu trách nhiệm về công việc của mình, các thành viên thường luôn cố gắng nỗ lực hơn để chứng tỏ năng lực bản thân. Vai trò của một “scrum master” là huấn luyện các thành viên tập trung hoàn thành số lượng “story” phù hợp hơn là ôm quá nhiều việc mà chẳng hoàn thành được việc nào. Chỉ các “story” có khả năng demo cuối mỗi phân đoạn mới được coi là “story” hoàn chỉnh.
Áp dụng Agile đồng nghĩa với việc sử dụng ít giấy tờ biểu mẫu hơn. Chúng ta thường chỉ có product backlog (danh sách các tính năng mong muốn của sản phẩm công nghệ) với user story (bản tóm tắt nhu cầu người dùng), iteration backlog và một vài biểu đồ theo dõi tiến độ công việc. Nếu có gì hơn thì điều này tùy thuộc vào yêu cầu doanh nghiệp. Khi doanh nghiệp và nhà phát triển phần mềm (developer) bắt đầu trao đổi về quy trình kỹ thuật, các yêu cầu chứng nhận (với những mô tả chi tiết) sẽ được xây dựng và đưa vào như là một phần trong quy trình phát triển dựa trên thử nghiệm - đây cũng là lúc các yêu cầu như vậy có giá trị nhất.
Thử nghĩ xem, bạn đọc các tài liệu yêu cầu trên bao nhiêu lần sau khi chúng được soạn ra? Chắc chắn là, một khi một dự án mới được triển khai, các tài liệu này đã bị lỗi thời phần nào, kể cả khi có được lưu lại, thì cũng chẳng ai xem chúng cả. Và mọi nỗ lực dành vào đó đều lãng phí. Vậy nên, hãy cố gắng chọn được đúng người truyền tải các yêu cầu và tài liệu hóa các yêu cầu ấy khi cần để không gây lãng phí về thời gian và công sức.
Tóm lại, trước khi áp dụng Agile, hãy đảm bảo là ban lãnh đạo / quản lý doanh nghiệp hiểu phương pháp làm việc của Agile và cách thức nhóm làm việc với các bộ phận khác. Chắc chắn ban lãnh đạo sẽ trân trọng những kiến thức bạn “dạy” họ và trợ giúp cho đội ngũ làm việc phát triển thành công.
Theo SAGA
