Một người lập trình viết cho tôi: “Tuần trước em tham dự một xê mi na Agile trong đó nhà tư vấn giải thích rằng Agile có thể được áp dụng cho bất kì kích cỡ nào của các dự án. Ông ấy cung cấp đào tạo đặc biệt này cho công ti của em. Em nhớ rằng thầy viết “Agile chỉ tốt cho dự án nhỏ.” Em thấy lẫn lộn, xin thầy giúp.”

Đáp: Theo kinh nghiệm riêng của tôi, các qui trình Agile dường như có tác dụng tốt nhất với tổ nhỏ những người làm việc trên dự án nhỏ. Tôi đã quản lí nhiều dự án Agile với các kích cỡ khác nhau và tôi có thành công tốt hơn với Agile trong các dự án nhỏ (ít hơn 10 người). Ken Beck, tác giả của Lập trình cực đoan (EP) cũng viết trong cuốn sách nổi tiếng của ông ấy: “Kích cỡ rõ ràng thành vấn đề, bạn có lẽ không cho chạy được dự án XP với hàng trăm người lập trình. Cũng không được với năm mươi người. Không được với hai mươi người, có lẽ. Mười dứt khoát là có thể làm được.”

Sức mạnh của Agile là ở điều phối tốt hơn, quan hệ tốt hơn, trao đổi tốt hơn và tri thức được chia sẻ. Bằng việc đặt Agile vào dự án kích cỡ lớn hơn, bạn làm loãng những điểm mạnh này và làm cho khó xây dựng sản phẩm chất lượng. Có các cách tiếp cận khác như phương pháp xoáy ốc và dẫn lái theo kế hoạch được thiết kế cho các dự án lớn. Những phương pháp này yêu cầu các vai trò, trách nhiệm được xác định rõ và tài liệu nghiêm ngặt để điều phối các hoạt động ngang qua các nhóm lớn. Bạn cần hiểu rằng từng cách tiếp cận được thiết kế cho kiểu dự án nào đó. Agile là tốt cho dự án nhỏ mà không có yêu cầu tốt hay các yêu cầu thường xuyên thay đổi. Các qui trình Agile yêu cầu chu kì lặp ngắn để cho khách hàng có thể có phần mềm nhanh chóng nhất có thể được vì bạn không phải chuyển giao mọi thứ một lúc. Tuy nhiên, Agile cần quan hệ làm việc tốt với khách hàng và người dùng để có được phản hồi nhanh chóng và ưu tiên về điều cần làm tiếp. Nó cũng yêu cầu rằng các thành viên tổ có kinh nghiệm và có thể được tự tổ chức để làm việc hướng tới mục đích chung.

Tôi không tin vào cách tiếp cận “một cỡ khớp cho tất cả.” Có các nhà tư vấn đưa ra hứa hẹn mà họ không thể giữ lời được. Một số người chỉ muốn làm tiền và sẽ làm bất kì cái gì để được trả tiền. Họ không quan tâm về liệu bạn học được cái gì đó đúng hay không. Tôi đã thấy nhiều xê mi na và khoá đào tạo mà nhà tư vấn sẽ dạy cho khách hàng cách qua kì thi nào đó để được chứng chỉ nhưng không về cách thực hiện nó cho đúng. Kết quả là người lập trình có chứng chỉ nhưng không có kĩ năng. Kiểu đào tạo này là phổ biến cho những người chỉ muốn mảnh giấy để trưng trong văn phòng của họ nhưng không chăm nom về tri thức hay kĩ năng của họ. Nếu bạn phải trả tiền cho ai đó dạy bạn cái gì đó, phải chắc bạn tìm người tư vấn giỏi có nhiều năm kinh nghiệm làm việc và thực sự chăm nom rằng khách hàng của họ sẽ có khả năng có việc làm tốt sau khi đào tạo. Đó là tiền bạc của bạn và kĩ năng của bạn cho nên phải cực kì để ý tới những người hứa quá nhiều.

—-English verrsion—-

Agile and project size

A programmer wrote to me: “Last week I attended an Agile seminar where the consultant explained that Agile can be applied to any size of projects. He offered to provide this special training for my company. I remembered that you wrote “Agile is only good for small project”. I am confused, please help.”

Answer: Based on my own experience, Agile processes seem to work best with small team of people working on small project. I have managed several Agile projects with differenet sizes and I had better success with Agile in small projects (less than 10 people). Ken Beck, the author of Extreme Programming (EP) also wrote in his famous book: “Size clearly matter, you probably coul not run an XP project with hundred of programmers. Not fifty. Nor twenty, probably. Ten is definitely doable.”

The strengths of Agile are better coordination, better relationships, better communication, and shared knowledge. By putting Agile in larger size project, you are diluting these strengths and make it more difficult to build a quality product. There are other approaches such as plan-driven and spiral methods designed for larger projects. These methods require well defined roles, responsibilities and strict documentations to coordinate activities across large groups. You need to understand that each approach is designed for certain type of project. Agile is great for small projects that do not have good requirements or requirements are often change. Agile processes require short iterative cycles so customers could get the software as quickly as possible because you do not have to deliver everything at once. However, Agile needs good working relationship with customers and users to get quick feedbacks and priority of what to do next. It also requires that the team members have experiences and can be self-organized to work toward a common goal.

I do not believe in a “one size fits all” approach. There are consultants who make promises that they cannot keep. Some only want to make money and would do anything to get paid. They do not care about whether you are learning something correctly or not. I have seen many seminars and trainings where consultants would teach customers how to pass certain tests to get certificates but not how to do it correctly. The result is programmers have the certificates but no skills. This type of trainings is popular to people who only want a piece of paper to display in their office but do not care about their knowledge or skills. If you have to pay someone to teach you something, make sure you find a good consultant who have many years of working experiences and really care that their customers would be able to a good job after the training. It is your money and your skills so be extremely careful with people who promise too much.