Để giảm thiểu vấn đề này, tổ phát triển phần mềm phải hội tụ vào làm việc với người dùng để phát triển yêu cầu rõ ràng và chính xác. Tuy nhiên, khi người dùng không biết họ muốn gì, hay thường đổi ý thì tổ phát triển có thể chấp thuận cách tiếp cận gia tăng bằng việc xác định điều người dùng có thể giải thích được vào lúc đó rồi ưu tiên hoá chúng thành nhiều bản đưa ra với bản họ đã biết được thực hiện trước nhất.

Cách tiếp cận này được gọi là “Cách tiếp cận Agile” bao gồm nhiều cách phát triển phần mềm. Một trong những cách phổ biến nhất là “Scrum”, chia hoạt động phát triển thành nhiều nỗ lực nhỏ, từng nỗ lực kéo dài từ 2 tới 4 tuần có tên là “Sprint- Nước rút”. Với từng nước rút, nhu cầu của người dùng được ưu tiên hoá thành “Tồn đọng nước rút- Sprint backlog” (Yêu cầu đối với một nước rút đặc biệt) nơi tổ có thể tập trung vào làm việc về nhu cầu của người dùng mà không phải lo lắng về các yêu cầu khác. Bằng việc xây dựng tăng dần phần mềm tương ứng theo ưu tiên của người dùng, tổ tiếp tục chuyển giao phần mềm làm việc thoả mãn cho người dùng thay vì chuyển giao mọi thứ một lần như với vòng đời thác đổ. Bằng việc đưa ra một mảnh phần mềm mỗi lúc, người dùng không phải chờ đợi lâu mà có thể dùng vài tính năng mỗi vài tuần và có thể đo được tiến bộ của tổ tương ứng. Với từng việc đưa ra, tổ cũng suy nghĩ về điều gì có tác dụng và điều gì không và tiếp tục cải tiến cách họ làm việc cùng nhau.

Trước khi dự án mau lẹ bắt đầu, cả tổ phát triển và người dùng phải đồng ý về cách qui trình này sẽ được thực hiện. Vai trò, trách nhiệm và đảm nhiệm phải được xác định và phân công để đảm bảo rằng người quản lí, người dùng và tổ dự án hiểu họ được giả định làm gì. Theo cách tiếp cận mau lẹ, trao đổi là yếu tố quan trọng nhất cho nên người dùng phải phân công ai đó làm việc cùng tổ dự án để phối hợp các yêu cầu và ưu tiên trên cơ sở hàng ngày. Đại diện này làm việc cùng “Thầy Scrum” của tổ dự án để xácđịnh “tồn đọng” cho từng nước rút Sprint. Đại diện của người dùng cũng phải có khả năng trả lời nhanh chóng mọi câu hỏi đặt ra cho tổ và lập ưu tiên mới, nếu cần. Nếu với bất kì lí do nào, người dùng bận rộn và không thể tham gia được vào giao tiếp hàng ngày với tổ, tính mau lẹ sẽ KHÔNG có tác dụng.

Thầy Scrum chịu trách nhiệm cho mọi dự án trong việc phối hợp các hoạt động với người dùng, đảm bảo rằng mọi người đều tuân theo qui trình agile tương ứng với vai trò, trách nhiệm của họ và thúc đẩy công việc tổ trong các thành viên tổ. Như đã đăng trước đây trong blog của tôi, cách tiếp cận Agile có tác dụng tốt cho các dự án nhỏ (4 tới 10 người) và mọi người trong tổ đều phải nhận được việc đào tạo agile để cho họ có thể làm việc tương ứng. Tuy nhiên, xung đột giữa mọi người trong tổ có xảy ra. Chính công việc của Thầy Scrum là giải quyết những vấn đề này nhanh chóng và hiệu quả. Thầy Scrum phải có kĩ năng giải quyết xung đột tổ bởi vì với cách làm mau lẹ, thời gian là cốt yếu (2 tới 4 tuần cho từng nước rút), cho dù với một người “khó làm việc”, toàn tổ cũng có thể bị tác động. Thầy Scrum cũng làm việc để loại bỏ bất kì chướng ngại nào được báo cáo trong cuộc họp hàng ngày và bảo vệ tổ khỏi bất kì việc ngắt quãng nào từ bên ngoài bởi vì công việc mau lẹ là rất dồn dập.

Có vài công cụ thương mại sẵn có trên thị trường cho dự án mau lẹ nhưng có những phương án như phần mềm nguồn mở nữa. Tôi thích dùng ba công cụ “tự do” này:

Wiki: Công cụ này có thể được cả người dùng và tổ dự án dùng để trao đổi và cộng tác trên mọi vấn đề có liên quan tới dự án.

Geeklog: Dùng công cụ này các thành viên dự án có thể thảo luận vấn đề lẫn với nhau. Công cụ này sẽ có giá trị cho các thành viên dự án để thảo luận về các vấn đề có liên quan tới các dự án khác nhau.

CVS: Nó là công cụ cấu hình nguồn mở để kiểm soát phiên bản  đưa ra.

Bugzilla: Project team can use this tool to track defects and take various reports on defects.

English version

Agile project

Requirements change is one of the major problems in most software projects. To minimize this problem, software development team must focus on working with users to develop a clear and concise requirements. However, when users do not know what they want, or often change their minds then the development team may want to adopt an incremental approach by determine what users can explain at that time then prioritize them into several releases with the one that they clearly know is to be implemented first.

This approach is called “The Agile approach” which consists several ways of develop software. One of the most popular way is “Scrum” , which divides the development activities into several small efforts, each lasts about 2 to 4 weeks called “Sprint”. For each sprint, the user’s needs are prioritized into a “Sprint backlog” (Requirements for a particular Sprint) where the team can concentrate to work on those user’s needs without have to worry about other requirements. By incrementally build software according to user’s priority, the team continue to deliver working software that satisfy users rather than deliver everything all at once as with the waterfall life cycle. By release one piece of software at a time, users do not have to wait a long time but can use several features every few weeks and can measure the team’s progress accordingly. For each release, the team also can reflect on what is working and what is not and continue to improve the way they work together.

Before the agile project begins, both development team and users must agree on how the process will be executed. Roles, responsibilities and accountability must be defined and assigned to make sure that manager, users, and the project team understand what they are supposed to do. In agile approach, communication is the most important factor so users must assign someone to work with the project team to coordinate the requirements and the priority on a daily basis. The representative works with the “Scrum Master” of the project team to define the “backlog” for each Sprint. The user’s representative must be able to quickly answer all questions to the team and set new priorities, if needed. If for whatever reason, users are so busy and cannot participate in the daily interface with the team, agile will NOT work.

The Scrum Master is responsible for all project coordinating activities with the users, make sure that everyone follows the agile process according to their roles, responsibilities and promote teamwork among team members. As previously posted in my blog, Agile approach works well for small projects (4 to 10 people) and everyone on the team must receive agile training so they can work accordingly. However, conflicts between people on the team do happen. It is the job of the Scrum Master to resolve these issues quickly and efficiently. The Scrum Master must have the skills to deal with team conflict because with agile, time is critical (2 to 4 weeks for each Sprint), even with one “difficult to get along” person, the entire team could be impacted. The Scrum Master must also works to remove any obstacle reported during the daily meeting and protect the team from any disruptive from outside because the agile work is very intensive.

There are several commercial tools available in the market for agile project but there are alternatives such as open source software. I like to use these “Free” tools:

Wiki: This tool can be used by both users and the teams to communicate and collaborate all the project related issues.

Geeklog: Using this tool project member can discuss issues with one another. This tool will be valuable for the project members to discuss on various projects related issues.

CVS: It is an open source configuration tools to control release version.

Bugzilla: Project team can use this tool to track defects and take various reports on defects.