Bài viết này đề cập đến sự không chắc chắn và rủi ro trong phát triển dự án theo phương pháp Agile.

Một số dự án có sự không chắc chắn đáng kể về các yêu cầu và cách đáp ứng các yêu cầu đó nếu sử dụng công nghệ và kiến thức hiện tại. Những sự không chắc chắn này làm tăng nguy cơ thay đổi và sự phức tạp của dự án. Điều đó được minh họa bằng hình ảnh dưới đây:

Khi sự không chắc chắn của dự án tăng lên, đồng nghĩa với việc bạn có thể phải làm lại càng cao và cần phải sử dụng một phương pháp tiếp cận khác. Để giảm thiểu ảnh hưởng của những rủi ro này, các team phát triển lựa chọn vòng đời sản phẩm cho phép giải quyết các dự án có độ không chắc chắn cao thông qua những bước tiến nhỏ (small increments) của công việc.

Việc chia và làm nhỏ công việc như vậy giúp các thành viên trong team hiểu rõ và nhanh yêu cầu của khách hàng hơn. Họ cũng có thể thay đổi hành động cần làm tiếp theo dễ dàng hơn. Đảm bảo được tính linh hoạt.

Các team phát triển có thể lên kế hoạch và quản lý dự án với những yêu cầu đồng nhất và rõ ràng, có thể giải quyết các thách thức về mặt kỹ thuật với ít khó khăn. Tuy nhiên không phải lúc nào đời cũng như mơ, nếu sự không chắc chắn của dự án tăng lên, thì những sự thay đổi, làm lại, làm việc vô ích cũng sẽ tăng lên. Điều này làm lãng phí thời gian và tiền bạc.

Một số team phát triển vòng đời dự án sử dụng cách tiếp cận lặp lại và tăng trưởng (iterative and incremental approaches). Các team phát hiện ra rằng: khi họ khám phá các yêu cầu lặp đi lặp lại và dần dần cung cấp thường xuyên hơn, thì các team sẽ thích ứng với sự thay đổi dễ dàng hơn. Cách tiếp cận lặp lại và tiếp cận gia tăng này giảm sự lãng phí, giảm làm lại công việc nhờ các phản hồi (feedback). Cơ sở cho các cách tiếp cận này là:

• Vòng phản hồi rất ngắn
• Sự thích ứng thường xuyên của quá trình
• Sắp xếp lại ưu tiên
• Cập nhật kế hoạch thường xuyên
• Chuyển giao sản phẩm định kỳ thường xuyên

Việc phát triển các ứng dụng phần mềm của mình cũng đang tuân thủ các cơ sở trên. Các tính năng quan trọng sẽ được ưu tiên và phát hành trước, không cần phải chờ cho đến khi ứng dụng hoàn thiện 100%. App có lịch phát hành đều đặn theo định kỳ 2 – 3 tuần/lần. Mỗi bản phát hành sẽ thu hút một số lượng người dùng đủ lớn và kêu gọi họ rating và review để thu về các phản hồi nhanh nhất có thể. Từ đó, mình đúc rút ra các vấn đề và điều chỉnh trong các bản tiếp theo. Nhờ đó, ứng dụng có được những phản hồi tích cực từ người dùng và đem lại tỷ lệ chuyển đổi cao.

Thông tin về ứng dụng của mình: Migii TOPIK

Các cách tiếp cận Agile, lặp lại và tăng trưởng hoạt động hiệu quả với các dự án có đặc điểm:

• Yêu cầu nghiên cứu và phát triển
• Có mức độ thay đổi cao
• Không biết hoặc không rõ yêu cầu, không chắc chắn, rủi ro
• Khó mô tả mục tiêu cuối cùng

Tóm lại là khi bạn làm một việc không rõ mục tiêu và định hướng thì hãy chia nhỏ việc ra, liên tục test và kiểm tra lại dựa trên các phản hồi và tạo nên vòng lặp lặp đi lặp lại. Đừng lao vào làm từ A đến Z tốn kém chi phí, thời gian mà chưa biết hiệu quả ra sao.

Tuy nhiên, với các cách tiếp cận lặp lại và tăng trưởng, nếu sự không chắc chắn về công nghệ và yêu cầu ở mức rất cao (complex hoặc chaotic như ảnh trên) thì sẽ gặp hạn chế. Lúc này để dự án khả thi hơn, bạn nên có thêm biến số.