Một số sự kiện về cách tiếp cận Agile
Một sinh viên hỏi tôi: “Nếu Agile là cách tiếp cận tốt để phát triển phần mềm thì tại sao chúng ta phải học cách tiếp cận khác?”
Câu trả lời của tôi: Agile là cách tiếp cận tốt tới phát triển phần mềm, đặc biệt khi dự án là nhỏ và yêu cầu KHÔNG được hiểu rõ. Tuy nhiên, Agile KHÔNG là giải pháp cho mọi thứ. Có những phương pháp khác nhau cho các kiểu dự án khác nhau. Nhân tiện, Agile chỉ có tác dụng nếu những điều kiện nhất định tồn tại.
Thứ nhất, Agile yêu cầu mọi thành viên tổ nhận được đào tạo về cách tiếp cận này (Scrum, lập trình cực đoan, Crystal v.v.). Không có đào tạo đúng, Agile sẽ KHÔNG có tác dụng. Tôi đã thấy nhiều sinh viên hiểu lầm Agile như cách thức không kỉ luật để làm bất kì cái gì họ muốn như “viết mã trước, hỏi câu hỏi sau”. Điều này là KHÔNG chấp nhận được bởi vì Agile là về việc làm cho công việc được thực hiện tương ứng, điều có nghĩa là các thành viên tổ phải tuân theo những qui tắc và qui trình nào đó. Chẳng hạn, với Scrum, dự án được chia thành các chu kì nhỏ được gọi là “Sprint - nước rút” (quãng 2 tới 4 tuần) nơi tổ hội tụ vào những chức năng nào đó mà họ phải phát triển và kiểm thử bên trong thời gian xác định đó. Qui trình lặp, tăng dần được làm tài liệu tốt và phải được tuân theo. Có vài bài báo nói rằng với Agile bạn KHÔNG cần tuân theo qui trình. Điều đó là SAI. Sự kiện là bạn bao giờ cũng tuân theo “qui trình được xác định” dù bạn dùng Scrum, Crystal hay lập trình cực đoan. Có khác biệt giữa Agile và vòng đời thác đổ truyền thống, nơi phương pháp truyền thống yêu cầu nhiều tài liệu nhưng với Agile, những tài liệu này đang bị rút gọn tới tối thiểu. Tuy nhiên, điều đó KHÔNG có nghĩa là Agile KHÔNG có tài liệu. Bởi vì dự án Agile là nhỏ chạy từ 3 tới 8 người, những người phát triển có thể trao đổi với nhau thường xuyên cho nên họ KHÔNG cần nhiều công việc giấy tờ. Điều này KHÔNG phải là trường hợp cho dự án kiểu thác đổ có tám tới ba trăm người nơi các thành viên tổ cần những tài liệu nào đó để chia sẻ thông tin.
Thứ hai, Agile yêu cầu sự tham gia của khách hàng hay đại diện của khách hàng. Không có sự tham gia này, Agile sẽ KHÔNG có tác dụng. Việc chuyển giao tăng dần chức năng làm việc yêu cầu rằng khách hàng và người dùng phải tham gia tích cực trong toàn dự án. Họ phải giải thích mọi thay đổi họ muốn có theo cách thức rõ ràng và chính xác. Họ phải đặt ưu tiên và đồng ý cho từng việc đưa ra sản phẩm. Họ phải tham gia vào mọi cuộc kiểm điểm then chốt và ra quyết định tương ứng. Về căn bản, họ phải là một phần của tổ.
Thứ ba, Agile yêu cầu mức độ kĩ năng kĩ thuật nào đó. Không có tổ có kĩ năng cao, Agile sẽ KHÔNG có tác dụng. Nó cần những người phát triển có kinh nghiệm và có kỉ luật để hướng dẫn tiến hoá kĩ thuật của hệ thống từ khái niệm tới thực hiện đầy đủ. Nó yêu cầu người phát triển có kĩ thuật, người có thể cân bằng nhu cầu tạo ra chức năng phần mềm trong thời gian ngắn tương ứng với kiến trúc được xác định tốt. Nó cần những người phát triển có thể cung cấp hướng dẫn dần thiết để đảm bảo hệ thống có thể được mở rộng qua thời gian với chức năng phụ và đạt tới mức độ mong muốn về hiệu năng và tính đổi qui mô được.
Thứ tư, Agile yêu cầu làm việc tổ giữa những người phát triển. Không có những kĩ năng mềm này, Agile sẽ KHÔNG có tác dụng. Về căn bản, làm việc tổ là trái tim của Agile bởi vì thời gian ngắn và yêu cầu KHÔNG được xác định rõ. Nó KHÔNG cho phép các thành viên tổ tranh cãi với nhau. Với cách tiếp cận này, không có những điều như “công việc của tôi” hay “công việc của bạn” mà chỉ có “công việc của chúng ta”. Các cá nhân sẽ phải giữ nhiều vai và giả định giữ vài trách nhiệm và sẵn sàng giúp đỡ người khác khi cần. Họ phải chia sẻ tri thức kĩ thuật để cho mọi thành viên tổ sẽ có khả năng tham gia vào công việc chung. Để làm điều đó, nó yêu cầu người lãnh đạo kĩ thuật hay Scrum Master để giám sát các hoạt động và động viên tổ. Phải có tương tác cộng tác cao độ giữa các thành viên tổ để đáp ứng yêu cầu của khách hàng. Với toàn thể tổ cùng cam kết với mục đích dự án, các thành viên tổ đã hoàn thành nhiệm vụ của mình phải giúp cho người còn chưa hoàn thành để cho dự án có thể kết thúc đúng thời gian.
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
