Vòng đời thác đổ và cách tiếp cận Agile
Một sinh viên khoa học máy tính viết cho tôi: “Trường em đang dạy về vòng đời thác đổ nhưng chú em, làm việc cho một công ti phần mềm lại nói rằng nó không có tác dụng và không ai dùng mô hình này nữa. Chú ấy nói rằng em phải học Agile thay cho nó. Khi em kể với thầy giáo, thầy không đồng ý và nói rằng chú em chả biết gì cả. Bây giờ em bị lẫn lộn. Xin thầy lời khuyên.”
Đáp: Từng vòng đời phần mềm đều được thiết kế cho một kiểu phát triển đặc thù. Không có một vòng đời khớp cho mọi thứ. Vòng đời thác đổ có ưu điểm và nhược điểm và cách tiếp cận Agile cũng vậy. Trong trường hợp này bạn không thể nói ai đúng và ai sai được.
Mặc dầu có những nhược điểm, vòng đời thác đổ vẫn là cách tiếp cận phát triển phổ biến trong công nghiệp và vẫn được dạy trong hầu hết các đại học. Nó là đơn giản, dễ hiểu, và vẫn được dùng trong nhiều kiểu dự án, đặc biệt các dự án lớn. Với sinh viên còn chưa có nhiều kinh nghiệm, mô hình này là rất tốt để học về cách phát triển phần mềm làm việc thế nào. Một khi sinh viên hiểu rõ mô hình thác đổ, họ có thể học về các mô hình khác như Xoáy ốc, Gia tăng, và Agile v.v.
Vòng đời thác đổ tổ chức các hoạt động vào các pha phân biệt để cho người quản lí có thể đặt lịch cho các nhiệm vụ được hoàn thành trong một thời kì thời gian nhất định. Chỉ sau khi các nhiệm vụ trong một pha đặc thù được làm xong thì pha tiếp mới có thể bắt đầu. Không có chờm lấp các pha trong vòng đời này. Từ cách nhìn của người quản lí dự án, vòng đời này dễ quản lí vì tiến bộ xảy ra theo cách tuần tự tuyến tính. Tại cuối mỗi pha, có một tài liệu đặc biệt và sản phẩm được thực hiện cho nên người quản lí có thể theo dõi tiến bộ của các hoạt động dự án. Vòng đời này dựa trên tình huống hoàn hảo với yêu cầu được xác định rõ ràng và có thay đổi tối thiểu trong phát triển.
Tất nhiên, các yêu cầu không được xác định rõ ràng và thay đổi xảy ra thường xuyên cho nên người phát triển phải quay lại và thay đổi công việc của họ (làm lại). Vấn đề này thường làm cho dự án bị trượt lịch, cần nhiều nỗ lực hơn và làm cho chi phí cao và chất lượng thấp. Nó có thể tạo ra hệ thống có cấu trúc kém khó bảo trì. Thỉnh thoảng do lịch chặt, không phải mọi vấn đề đã được giải quyết cho nên phần mềm được đưa ra vẫn có lỗi. Khi yêu cầu của khách hàng được thêm vào về sau trong khi phát triển, chúng làm ngắt quãng công việc và không phải mọi yêu cầu đều được thực hiện đúng. Những điều này tạo ra sản phẩm chất lượng thấp và làm cho khách hàng không hài lòng.
Agile là cách tiếp cận phát triển tốt cho dự án nhỏ hơn nhưng nó có một số ưu điểm nữa. Agile giả định rằng người dùng sẽ tham gia tích cực và cộng tác với người phát triển. Trong thực tế, người dùng thường bận rộn và có thể không có thời gian hay kĩ năng để tham gia vào dự án. Không có người dùng tham gia, Agile có thể không làm việc được. Điều tốt nhất trong Agile là nó đón chào các thay đổi nhưng nó cũng có thể là điều phủ định nữa. Khi nhiều thay đổi được thêm vào và phạm vi cứ thay đổi, dự án có thể không bao giờ kết thúc tương ứng (phạm vi luồn lọt). Agile là qui trình đang tiến hoá và thường được điều chỉnh để đáp ứng cho thay đổi của khách hàng, do đó khó lập kế hoạch về ngân sách dự án sẽ tốn bao nhiêu. Agile yêu cầu người phát triển có kĩ năng cao và kinh nghiệm mà có thể giả định giữ được nhiều vai trò, từ tương tác với khách hàng, lập ưu tiên, viết mã và kiểm thử liên tục. Phần lớn các công ti không có đủ những công nhân này và công nhân thiếu kinh nghiệm thường không làm được trong Agile, đặc biệt nếu họ không có đủ đào tạo đúng và huấn luyện Agile tốt để giúp họ.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
