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.

—-English version—-

Some facts about Agile approach

A student asks me: “If Agile is a good approach to develop software then why do we have to study other development approach?”

My answer: Agile is a good approach to develop software, especially when project is small and requirements are NOT well understood. However, Agile is NOT a solution for everything. There are different methods for different types of project. By the way, Agile only works if certain conditions exist.

First, Agile requires all team members to receive training on the approach (Scrum, Extreme Programming, Crystal etc.). Without proper training, Agile will NOT work. I have seen many students misunderstood Agile as an undisciplined way to do whatever they want such as “code first, ask question later”. This is NOT acceptable because Agile is about getting the work done accordingly which means team members must follow certain rules and processes. For example, with Scrum, the project is divided in small cycles called “Sprint” (About 2 to 4 weeks) where the team is focusing on certain functions that they must develop and test within that specific time. This iterative, incremental process is well documented and must be followed. There are several articles claimed that with Agile you do NOT need to follow a process. It is FALSE. The fact is you always follow a “defined process” whether you are using Scrum, Crystal or Extreme programming. There is a different between Agile and traditional waterfall lifecycle, where the traditional method requires many documents but with Agile, these documents are being reduce to a minimum. However, it does NOT mean Agile has NO documentation. Because Agile projects are small ranging from 3 to eight people, developers can communicate with each other often so they do NOT need a lot of paperwork. This is NOT a case for large waterfall type project that have eighty to three hundred people where team members need certain documents to share information.

Second, Agile requires the involvement of customers or a representative of the customers. Without this involvement, Agile will NOT work. The incremental delivery of working functionality required that the customers and users must actively participate throughout the entire project. They must explain all changes that they want in a clear and concise manner. They must set priorities and agree to each product release. They must participate in every key reviews and make decisions accordingly. Basically, they must be part of the team.

Third, Agile requires a certain level of technical skills. Without the highly skilled team, Agile will NOT work. It needs experienced and disciplined developers to guide the technical evolution of the system from concept to implementation thoroughly. It requires skilled developers who can balance the need to produce software functions in the short term according to a well defined architectural. It needs developers who can provide guidance necessary to ensure the system can be extended over time with additional functionality and achieve the desired level of performance and scalability.

Fourth, Agile requires teamwork among developers. Without these soft-skills, Agile will NOT work. Basically, teamwork is the heart of Agile because the time is short and the requirements are NOT well defined. It does NOT allow time for team members to argue with each other. With this approach, there is no such thing as “My work” or “Your work” but only “Our work”. Individuals will have to play several roles and assume several responsibilities and ready to help others when asked. They must share technical knowledge so every team member will be able to participate in the common work. To do that, it requires a technical lead or Scrum Master to oversee the activities and motivate the team. There must be highly collaborative interaction between team members to meet the customers’ requirements. With the entire team commit to the project goals, team members who have completed their tasks must help the one who has not completed so the project can finish on time.