Một người phát triển phần mềm hỏi tôi: “Người quản lí của tôi nói rằng hoạt động chính của Agile chỉ là viết mã và kiểm thử. Bạn không cần tài liệu cho nên chúng tôi có thể hoàn thanh nhanh và đó là lí do tại sao cái tên “Agile – mau lẹ” tới. Điều đó có đúng không?”

Đáp: Nếu người quản lí của bạn coi “Agile” CHỈ là viết mã, kiểm thử và không có tài liệu thì tôi sẽ gọi nó là: “Agile muốn vậy”, “Agile giả” KHÔNG phải “Agile thực”. Mặc dầu mục đích chính của Agile là nhanh và linh hoạt nhưng nó cũng bao gồm các nguyên tắc kĩ nghệ phần mềm để đảm bảo sản phẩm đạt tới chất lượng. Chẳng hạn, kiểm điểm tình trạng dự án bằng họp hàng ngày; giảm rủi ro bằng dựng tăng dần; xác định yêu cầu bằng “câu chuyện của người dùng”. Mô tả này về yêu cầu được kể từ quan điểm của người dùng cũng là tài liệu. Bỏ những nguyên lí này sẽ tạo ra rủi ro về chi phí cao, và chuyển giao chậm.

Có nhiều hiểu lầm về cách tiếp cận Agile và “không tài liệu” là một cách hiểu sai. Nhiều người dùng cái tên “Agile” để bảo vệ cho việc “thiếu kỉ luật” của họ và “thiếu tri thức” trong điều họ làm. Nếu họ bỏ qua thiết kế và nhày vào viết mã, họ nói họ đang dùng Agile. Khi họ không có đủ thời gian, họ bỏ qua việc kiểm thử và nói vì họ dùng Agile. Có chuyện ngụ ngôn cổ về gà và cáo thảo luận về cơ hội mở tiệm ăn. Cáo gợi ý cho gà: Tớ sẽ là người nấu, vì cậu đã cam kết cho thành công của tiệm ăn, tớ đề nghị chúng ta có mục menu kiểu như “Gà rán” “Súp gà”, “Gà ca ri” v.v.”. Câu chuyện này được ngụ ý chỉ ra sự khác biệt giữa những người nói và những người cam kết làm công việc.

Ý định của Agile là xây dựng cấu phần sản phẩm theo những việc lặp nhỏ. Trong phương pháp Scrum, từng lần lặp được gọi là “Sprint” (chặng nước rút) vào quãng hai tới bốn tuần. Một dự án điển hình có thể bắt đầu với tài liệu của người chủ sản phẩm về yêu cầu dự án trong tồn dư sản phẩm Product Backlog (Scrum có yêu cầu tài liệu ở đây). Người quản lí dự án hay thầy Scrum sẽ lập kế hoạch đưa ra sản phẩm bằng việc xác định cần bao nhiêu “Sprints” để hoàn thành dự án và thời hạn cho từng Sprint (2 hay 4 tuần). Với từng Sprint, tổ sẽ làm việc với người chủ sản phẩm, thầy Scrum để xác định những thứ họ phải làm và làm tài liệu chúng trong tồn dư của Sprint (nhiều tài liệu hơn). Tổ sẽ phân tích tồn dư này, bắt đầu thiết kế, viết mã, kiểm thử và thảo luận về tiến độ, vấn đề, rào chắn, và phân bổ công việc trong cuộc họp hàng ngày của họ. Tại cuối từng Sprint, tổ đưa ra sản phẩm và tiến hành nội quan suy ngẫm về Sprint để xác định cái gì có tác dụng và không có tác dụng rồi tái tổ chức lại công việc của họ để cho họ có thể làm nó tốt hơn trong Sprint tiếp. Thầy Scrum làm tài liệu điều tổ đã học được ttrong một tài liệu để được kiểm điểm vào chặng nước rút tiếp. Về căn bản, với Agile bạn cũng làm một số tài liệu.

Agile KHÔNG ngụ ý bỏ qua cái gì mà chỉ làm mọi sự theo từng mảnh nhỏ vào từng lúc. Nó chủ trương đưa ra tăng dần sản phẩm phần mềm với từng việc đưa ra chứa vài chức năng vào mỗi lúc. Điều này là tốt hơn cách tiếp cận khác bởi vì với từng việc đưa ra, tổ sẽ lấy phản hồi từ người dùng ngay lập tức. Điều quan trọng là giải thích cách tiếp cận tăng dần trước khi dự án bắt đầu để cho người dùng biết rằng họ sẽ có thêm chức năng với từng lần đưa ra. Người dùng có thể nói cho tổ liệu chức năng đưa ra là đúng hay không, đôi khi nếu đó không phải là điều họ có trong tâm trí, họ có thể yêu cầu thay đổi. Khi tổ tiếp tục nhận được phản hồi từ người dùng, họ có thể tiếp tục xây dựng phần mềm với mọi chức năng mà người dùng cần. Đây là khác biệt với cách tiếp cận thác đổ nơi tổ chỉ đưa ra cho người dùng khi họ kết thúc đầy đủ toàn bộ phần mềm.

Một số người KHÔNG thích họp hàng ngày của Agile vì họ nghĩ họp là phí thời gian. Theo kinh nghiệm của tôi, tôi bao giờ cũng yêu cầu thành viên tổ tuân theo qui trình này bằng việc nói cho tổ: Tôi đã làm cái gì (Kiểm điểm công việc ngày hôm trước với tổ); Tôi làm nó thế nào (Kiểm về phản hồi chất lượng); Tôi sẽ làm gì (Hỏi về phân công hôm nay), Tôi cần gì (Kiểm về bất kì thông tin thêm nào). Điều này có thể xảy ra trong cuộc họp ngắn, thường không quá nửa giờ cho nên tổ có thể tiếp tục với công việc của họ. Vì tổ Agile là “tự tổ chức”, người có kĩ năng là nhân tố quan trọng nhất cho thành công của dự án. Điều quan trọng là lựa người đúng và đào tạo họ theo cách tiếp cận này bởi vì không có người lãnh đạo tổ toàn diện, người quyết định người nào sẽ làm nhiệm vụ nào hay vấn đề sẽ được giải quyết thế nào. Đấy là những vấn đề được quyết định bởi tổ như một toàn thể. Trong kiểu tổ này, từng người làm bất kì cái gì được cần tới để hoàn thành công việc. Điều đó cũng có nghĩa là mọi người phải có mọi kĩ năng được cần trong phát triển phần mềm vì có thể không có người kiểm thử hay người lập trình hay người thiết kế  nhưng các thành viên tổ có thể phải làm cả ba việc đó.

Agile là cách tiếp cận phát triển phần mềm tốt cho dự án nhỏ và dự án có yêu cầu không được xác định rõ mà phải được hoàn thành nhanh. Giống như mọi cách phát triển, các thành viên tổ phải được đào tạo đúng và hiểu cả nguyên lí cũng như phương pháp. Agile KHÔNG phải là giải pháp cho mọi thứ, bạn phải biết giới hạn của nó và cẩn thận tránh một số hiểu lầm và dùng lầm.

—-English version—-

Issues with Agile approach

A software developer asked me: “My manager said that the main activities of Agile are only coding and testing. You do not need documentation so we can finish fast and that is why the name “Agile” come from. Is it correct?”

Answer: If your manager considered “Agile” as ONLY Code, Test and No documentation then I would call it: “Agile want-to-be”, “Fake Agile” NOT “Real Agile”. Although the main goals of Agile are fast and flexible but it also includes software engineering principles to ensure product achieve quality. For example, review project status by daily meetings; reduce risks by incremental build; define requirements by “User stories”. This description of requirements told from the view of users is also documentation. Abandoning these principles will increase the risk of high costs, low quality, and late delivery.

There are many misconceptions about Agile approach and “No documentation” is one. Many people use the name “Agile” to defend their “Lack of discipline” and “Lack of knowledge” in what they do. If they skip design and jump to code, they say that they are using Agile. When they do not have enough time, they skip testing and said because they are using Agile. There is an old fables about a chicken and a fox discussing the opportunity of opening a restaurant. The fox suggested to the chicken: I will be the cook, since you are committed to the success of our restaurant, I propose we have on the menu items such as “Fried Chicken” “Chicken soup”, “Chicken curry” etc.”. The story is meant to point out the difference between those who talked and those committed to do the work.

The intent of Agile is to build product components in small iterations. In Scrum method, each iteration is called “Sprint” which is about two to four weeks. A typical project may start with the Product Owner document the project requirements in the Product Backlog (Scrum does require documentation here). The project manager or Scrum Master will plan the product release by determine how many “Sprints” are needed to complete the project and the duration of each Sprint (2 or 4 weeks). For each Sprint, the team will work with the Product Owner, Scrum Master to determine things that they must do and document them in the Sprint Backlog (More documentation). The team will analyze this Backlog, start design, code, test and discuss progress, issues, barriers, and work assignment in their Daily meeting. At the end of each Sprint, the team release the product and conduct Sprint retrospective to determine what worked and not worked then re-organize their works so they can do it better in the next Sprint. The Scrum Master documents what the team learned in a document to be reviewed at next sprint. Basically, with Agile you do some documentation too.

Agile does NOT mean skipping anything but only do thing in smaller pieces at a time. It advocates an incremental release of software product with each release contains few functions at a time. This is better than other approach because for each release, the team will get feedback from users immediately. It is important to explain the incremental approach before the project starts so users know that they will get more functions with each releases. Users can tell the team whether the released function is correct or not, sometime if that was not what they have in mind, they can request changes. As the team continue to receive feedback from users, they can continue to build the software with all functions that users need. This is different from the waterfall approach where the team only releases to users when they completely finish the entire software.

Some people do NOT like the Agile daily meeting because they think meeting is a waste of time. In my experience, I always ask team member to follow the process by telling the team: What did I do (Review their previous day work with the team); How did I do it (Check for quality feedbacks); What will I do (Ask for today assignment), What do I need (Check for any additional information). This can happen in a short meeting, usually no more than half an hour so team can continue with their work. Since Agile team is “Self organizing”, skilled people are the most important factor for the success of the project. It is important to select the right person and train them in the approach because there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. In this type of team, each person does whatever it needed to complete the work. That also means people must have all the skills needed in developing software since there may not be tester or programmer or designer but team members may have to do all three.

Agile is a good software development approach for small project and project that requirements are not well defined but must be completed fast. Like every development approach, team members must be trained properly and understand both the principles as well as the method. Agile is NOT a solution for everything, you must know its limitation and be careful to avoid some misconceptions and misuses.