Nhiều người phát triển phần mềm nói rằng họ dùng cách tiếp cận Agile, nhưng thực tế họ chỉ dùng nó như cơ hội để nhảy qua qui trình phát triển và làm tài liệu để cho họ có thể nhảy vào viết mã.

Những “người phát triển vô kỉ luật” này biết rằng quản lí cấp trung và người chủ công ti không có ý tưởng về Agile thực sự là gì. Đó là lí do tại sao nhiều người quản lí bảo với tôi rằng Agile không có tác dụng trong công ti của họ. Trong khảo cứu của tôi về 250 dự án phần mềm trong ba năm qua, tôi thấy rằng Agile là tuyệt hảo cho các dự án phần mềm nhỏ (ít hơn 10 người), nó có thể giúp cải tiến chất lượng và sự thoả mãn của khách hàng đáng kể.

Điều thành công then chốt trong Agile là có tổ dự án có kinh nghiệm và có kĩ năng. Dự án Agile đòi hỏi mọi thành viên tổ đóng nhiều vai trò khi được cần, từ kiến trúc, thiết kế tới phát triển và kiểm thử. Người lập trình chỉ viết mã sẽ không có khả năng dùng Agile một cách thành công. Bên cạnh những người phát triển có kĩ năng, dự án cần người đảm bảo chất lượng (QA) tốt, người có thể xây dựng và thực hiện các kiểm thử, và người quản lí cấu hình (CM) người có thể giúp kiểm soát các thay đổi và dựng sản phẩm phần mềm. Một vai trò quan trọng trong Agile là người chủ sản phẩm (PO). Vai trò này yêu cầu người có kinh nghiệm cao để làm việc với khách hàng và đảm bảo mọi người trong tổ hiểu nhu cầu khách hàng. (Vai trò này cũng được gọi là người phân tích nghiệp vụ hay kĩ sư yêu cầu trong cách tiếp cận khác.) PO phải nhận diện khách hàng đúng để đảm bảo yêu cầu là chính xác và cung cấp giá trị cho công ti. Đôi khi đại diện khách hàng sẽ được phân công cho dự án để hành động như PO. Việc chính của PO là kiểm nghiệm điều tổ đang dựng là cái gì đó mà khách hàng thực sự muốn.

Vai trò then chốt khác trong Agile (phương pháp Scrum) là Thầy Scrum. Thầy Scrum xác định các qui trình và thực hành cho dự án và đảm bảo tổ tuân theo chúng. Nhiệm vụ then chốt khác của Thầy Scrum là loại bỏ bất kì chướng ngại hay khối chắn nào cho dự án. Thầy Scrum cũng tạo điều kiện cho phiên lập kế hoạch nước rút Sprint, theo dõi hàng ngày, suy ngẫm, và phiên lập kế hoạch đưa ra. Nếu tổ chức của bạn là mới với Agile, điều quan trọng là đưa vào một huấn luyện viên Agile, người đã kinh nghiệm sâu sắc trong cách tiếp cận Agile để đảm bảo cho tổ đang thực hiện Agile một cách hiệu quả. Huấn luyện viên cũng cung cấp đào tạo cho tổ và phải chắc rằng họ sẽ không làm “lối tắt” hay “thủ đoạn” nào để nhảy lùi lại thói quen cũ như “mã trước, thiết kế sau.”

Để chắc chắn rằng công ti dùng Agile đúng, điều quan trọng là đào tạo cả người quản lí cấp trung và người chủ nữa. Họ phải hiểu qui trình Agile, vai trò và trách nhiệm của thành viên tổ và tin cậy vào tổ của họ làm công việc. Họ nên tham gia và kiểm điểm Sprint (phương pháp Scrum) để thu được cảm giác tiến bộ thay vì chỉ đọc báo cáo trạng thái. Họ phải hiểu rằng ý định chính của nó là xây dựng giá trị khách hàng điều chung cuộc có thể có nghĩa là nhiều thu nhập hơn cho công ti. Tất nhiên, họ KHÔNG cần là chuyên gia nhưng tối thiểu họ phải hiểu khái niệm về tổ tự tổ chức, cộng tác. Họ cần giúp đỡ PO bằng các yêu cầu và làm sáng tỏ để đảm bảo rằng tổ xây dựng cái gì đó mà khách hàng cần. Họ cần hiểu rằng tồn lưu sản phẩm và mục đích đưa ra được PO sở hữu và tránh đưa ra hứa hẹn cho khách hàng mà không có PO trong thoả thuận. Về căn bản, cách tiếp cận Agile KHÔNG chỉ dành cho tổ phát triển mà mọi người bên trong công ti phải hiểu qui trình và ích lợi của nó. Nó đưa tổ tới thành công và với Agile, tổ là toàn bộ công ti.

Ngược với khái niệm sai về Agile rằng nó chỉ yêu cầu “kĩ năng viết mã để làm điều đó cho nhanh”, có nhiều thực hành Agile nghiêm ngặt. Đó là lí do tại sao điều quan trọng là có đào tạo Agile tốt trước khi thích nghi nó cho công ti. Có kỉ luật tốt giúp cho năng suất và chất lượng vì kỉ luật đảm bảo rằng mọi người được hội tụ vào công việc. Nếu bạn nghe ai đó nói rằng Agile là về “viết mã nhanh hơn và chóng hơn”, điều rõ ràng là họ chắc chắn chưa bao giờ thực tế làm Agile mà chỉ giả vờ biết cái gì đó về nó.

—-English version—-

The Agile approach

Many software developers say that they are using Agile approach, but actually they only use it as an opportunity to skip development process and documentation so they can jump into coding. These “undisciplined developers” know that middle level managers and company owners have no idea of what Agile really is. That is why many managers told me that Agile does not work in their companies. In my study of 250 software projects in the past three years, I found that Agile is excellent for small software projects (Less than 10 people), it can helps improve quality and customers’ satisfaction significantly.

The key success thing in Agile is to have a skilled and experienced project team. Agile project demand every team members to play several roles when needed from architect, design to develop and test. A programmer who only write code will not be able to use Agile successfully. Beside skilled developers, the project need good Quality Assurance (QA) who can build and execute tests, and Configuration Management (CM) who can help control the changes and build the released software product. One important key role in Agile is the Product Owner (PO). This role requires an highly experienced person to work with customers and ensure everyone on the team understands customer needs. (This role is also called as Business Analyst or Requirements Engineers in other approach) The PO must identify the right customers to ensure requirements are accurate and provide value to the company. Sometime a customer representative will be assigned to the project to act as the PO. The main job of the PO is to validate what the team is building is something that the customer actually wants.

Another key role in Agile (The Scrum method) is the Scrum Master. The Scrum Master defines the processes and practices for the project and ensures the team follows them. Another key task of Scrum Master is to remove any obstacles or roadblocks for the project. The Scrum Master also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Release Planning session. If your organization is new to Agile, it is important to include an Agile coach who has deep experienced in Agile approach to ensure the team is implementing Agile effectively. The coach also provides training to the team and make sure that they will not do any “Shortcut” or “Trick” to jump back to old habits such as “Code first, Design later”.

To make sure that the company is using Agile correctly. It is important to train both middle level managers and owner too. They must understand Agile process, roles and responsibilities of team members and trust their teams to do the work. They should attend the Sprint Review (The Scrum method) to gain a sense of progress instead of just read a status report. They must understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. Of course, they do NOT need to be an expert but at the minimum, they must understand the concept of self-organizing teams, collaboration. They need to help the PO with requirements and clarification to ensure that the team is building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the PO and avoid making promises to customers without the PO in agreement. Basically, Agile approach is NOT only for the development team but everyone within the company must understand the process and benefits of it. It takes teamwork to succeed and with Agile, the team is the entire company.

Contradict to the wrong notion about Agile that it only requires “coding skill to do it fast”, there are many rigorous Agile practices. That is why it is important to have good Agile training before adapting it for the company. Having good discipline helps with productivity and quality because the discipline ensures that everyone is focused on the work. If you hear someone says that Agile is about “Coding faster and quicker”,  it is clear that they certainly have never actually done Agile but only pretend to know something about it.