Agile là qui trình phát triển phần mềm “hướng theo tổ” được thiết kế cho dự án nhỏ nơi yêu cầu không ổn định và liên tục thay đổi.

Để làm công việc mau lẹ, sự tham gia của khách hàng được yêu cầu và tổ sẽ hội tụ vào các hoạt động chứ không chỉ kết quả bởi vì hoạt động chất lượng sẽ tạo ra kết quả chất lượng. Chương trình khoa học máy tính truyền thống nhấn mạnh vào cái ra hay kết quả (sản phẩm) nhưng không nhấn mạnh mấy tới hoạt động (qui trình) tạo ra kết quả. Trong lớp, sinh viên tập trung hầu hết vào kết quả đúng nhưng không được dạy về qui trình phát triển phần mềm. Đây là một trong các vấn đề của đào tạo ngôn ngữ lập trình nơi sinh viên có thể làm bất kì cái gì họ muốn chừng nào họ còn đi tới câu trả lời đúng. Tương phản lại, đào tạo kĩ nghệ phần mềm hội tụ nhiều vào kỉ luật xây dựng phần mềm tương ứng với qui trình đã xác định. Một trong các phương pháp được dạy là phương pháp agile (mau lẹ).

Có vài phương pháp trong agile nhưng phổ biến nhất là “Scrum” một qui trình được xác định để giám sát và kiểm soát các hoạt động phát triển phần mềm. Khía cạnh then chốt của Scrum là vai trò, trách nhiệm và tính đảm nhiệm của mọi người trong tổ như sau:

Người chủ sản phẩm chịu trách nhiệm cho những điều sau:

Xác định tính năng của sản phẩm;

Quyết định về ngày đưa ra và nội dung;

Ưu tiên hoá các tính năng tương ứng với nhu cầu của khách hàng;

Điều chỉnh các tính năng và ưu tiên cứ sau 30 ngày, khi cần; và

Chấp nhận hay bác bỏ kết quả công việc.

Thầy Scrum là người lãnh đạo tổ làm việc chặt chẽ với người chủ sản phẩm. Thầy Scrum:

Đảm bảo rằng tổ hoạt động và có năng suất đầy đủ;

Tạo khả năng cho hợp tác chặt chẽ qua tất cả các vai trò và chức năng;

Che chắn cho tổ khỏi bị can nhiễu bên ngoài; và

Đảm bảo rằng qui trình được tuân theo,

Tổ:

xuyên chéo chức năng, với các thành viên có kinh nghiệm;

lựa chọn mục đích Sprint (đợt chạy nước rút) và xác định kết quả công việc;

có quyền tự tổ chức bên trong biên giới của hướng dẫn để đạt tới mục đích của Sprint;

đề mô kết quả công việc cho người chủ sản phẩm.

Dự án phần mềm Scrum được quản lí bằng việc duy trì đơn hàng chưa làm xong của sản phẩm (danh sách yêu cầu) và các rủi ro. Đơn hàng chưa xong của sản phẩm là phát biểu về công việc mà dự án phải thực hiện. Rủi ro là những điều nhận diện ra trong đơn hàng sản phẩm chưa làm xong mà tổ phải giảm nhẹ. Scrum cho phép tổ dự án xác định khi nào hệ thống là “đủ tốt” để được đưa ra cho khách hàng. Với Scrum, mọi dự án tiến triển qua một chuỗi lặp, thường có chiều dài bốn tuần, có tên là “Sprints – chạy nước rút” (thời hạn ngắn). Ở lúc bắt đầu của từng Sprint – Sprint, cuộc họp lập kế hoạch Sprint được tổ chức trong đó người chủ sản phẩm lập ưu tiên việc tồn dư chưa hoàn thành và tổ lựa ra các nhiệm vụ họ có thể hoàn thành bên trong việc chạy nước rút đó. Những nhiệm vụ này rồi được chuyển từ tồn dư sản phẩm sang Sprint chưa xong. Mỗi ngày cuộc họp hàng ngày có tên là Sprint hàng ngày – Daily Scrum – đều được tổ chức, để nhận diện hoạt động nào đã được hoàn thành và hoạt động nào không phải được hoàn thành vào ngày đó. Loại họp này tạo ra tính thấy được công việc của từng cá nhân để tạo điều kiện cho chia sẻ tri thức, giảm nhiệm vụ trùng lặp, và đảm bảo rằng công việc của họ được hoàn toàn tích hợp. Đến cuối của từng Sprint, tiến hành đề mô chức năng đã hoàn thành tại cuộc họp kiểm điểm chạy nước rút Sprint. Bằng việc có nhiều Sprint, tổ dự án có thể xây dựng phần mềm trong thời hạn ngắn tăng dần với sự linh hoạt và mau lẹ (Agile).

Qui trình Scrum bao gồm bốn hoạt động: Lập kế hoạch Sprint, Scrum hàng ngày, Kiểm điểm Sprint, và Suy ngẫm về Sprint.

1) Lập kế hoạch Sprint

Chuẩn bị cho Sprint bắt đầu khi Người chủ sản phẩm xây dựng kế hoạch sản phẩm. Người chủ sản phẩm phải có viễn kiến về sản phẩm và có khả năng chia nhỏ sản phẩm thành những mảnh nhỏ tương ứng với bản kế hoạch có nhiều lần đưa ra, mỗi lần tập trung vào tính năng nào đó. Người chủ sản phẩm chuẩn bị phần tồn dư sản phẩm, danh sách các tính năng được khách hàng ưu tiên.

Scrum bắt đầu với người chủ sản phẩm kiểm điểm lại viễn kiến, kế hoạch, lịch biểu đưa ra, và tồn dư sản phẩm cùng tổ. Tổ kiểm điểm lại các ước lượng về tính năng theo các phần tồn dư sản phẩm và quyết định bao nhiêu công việc nó có thể nhận trong việc chạy nước rút dựa trên kích cỡ tổ, giờ sẵn có, và mức độ tri thức chuyên gia của tổ. Tổ kéo các khoản mục từ tồn dư sản phẩm mà họ có thể làm trong phạm vi nước rút ba mươi ngày vào trong tồn dư chưa thực hiện của Sprint này rồi thầy Scrum lãnh đạo tổ trong phiên lập kế hoạch để chia các tính năng này thành các nhiệm vụ nước rút. Đây là những hoạt động phát triển đặc biệt được yêu cầu để thực hiện một tính năng cho sprint.

2) Scrum hàng ngày

Một khi lập kế hoạch được hoàn tất, Sprint bắt đầu vòng lặp của nó. Từng ngày thầy Scrum lãnh đạo tổ trong cuộc họp Scrum hàng ngày. Scrum hàng ngày là cuộc họp ngắn được thiết kế để làm sáng tỏ trạng thái của Scrum. Từng thành viên tổ trả lời cho ba câu hỏi: 1) Bạn đã làm gì kể từ cuộc họp Scrum trước? 2) Bạn lập kế hoạch làm gì hôm nay? 3) Có chướng ngại nào ngăn cản bạn thực hiện công việc bạn lên kế hoạch làm hôm nay không? Mục đích là để có được trạng thái của dự án, khám phá ra vấn đề mới, đề cập tới nhu cầu cá nhân của thành viên tổ, và điều chỉnh kế hoạch theo thời gian thực theo nhu cầu của ngày.

3) Suy ngẫm về Sprint

Cuộc họp này được tổ tham dự cùng thầy Scrum, và người chủ sản phẩm.  Cuộc họp này bắt đầu với tất cả các thành viên tổ đều trả lời cho hai câu hỏi: 1) Cái gì diễn ra tốt trong kì chạy nước rút vừa rồi? 2) Cái gì có thể được cải tiến trong việc chạy nước rút vừa rồi?  Thầy Scrum làm tài liệu về câu trả lời của tổ dưới dạng tóm tắt, và tổ ưu tiên hoá thứ tự nó muốn nói tới về cải tiến tiềm năng. Thầy Scrum tạo điều kiện thuận tiện cho việc tìm kiếm của tổ để cải tiến các cơ hội cho các qui trình Scrum, nhận diện hành động có thể được bổ sung cho việc chạy nước rút tiếp để cải tiến.

4) Họp kiểm điểm sprint

Họp kiểm điểm được tổ chức ở cuối sprint. Phần đầu là đề mô cho người chủ sản phẩm về mã đã được phát triển trong kì chạy nước rút. Người chủ sản phẩm cũng mời khách hàng tới dự và xác định tính năng nào trên đơn hàng chưa thực hiện của sản phẩm đã được hoàn thành trong Sprint này. Khách hàng, người chủ sản phẩm, thầy Scrum cũng thảo luận về cách đặt ưu tiên lại cho tồn dư chưa được thực hiện của sản phẩm cho lần chạy nước rút tiếp. Thế rồi mục đích cho sprint tiếp được xác định và thảo luận  về cách tổ sẽ làm việc cùng nhau trong sprint tiếp.  Sau cuộc họp kiểm điểm này, qui trình lại bắt đầu với việc chạy nước rút khác cho tới khi tất cả các tính năng đã được thực hiện để hoàn thành sản phẩm.

—-English version—-

Agile is a “teamwork oriented” software development process designed for small project where requirements are not stable and continue to change. In order to make agile works, customer participation is required and the team would focus on the activities rather than the results because quality activities would produce quality results. Tradition computer science program emphasizes the outputs or results (product) but not much on the activities (process) that created the results. In class, students are focusing mostly on the correct outputs but not taught on the process of develop software. This is one of the problems of programming language training where students can do whatever they want as long as they come up with the correct answers. In contrast, software engineering training is focusing more on the disciplines to build software according to a defined process. One of the methods that are being taught is agile.

There are several methods in agile but the most popular is “Scrum” a defined process to monitors and controls software development activities. The key aspect of Scrum is the defined roles, responsibilities and accountabilities of people in the team as follows:

The Product Owner is responsible for the following:

Define the features of the product;

Decide on release date and content;

Prioritize features according to customers needs;

Adjust features and priority every 30 days, as needed; and

Accept or reject work results.

The Scrum Master is a team leader working closing with the Product Owner. The Scrum Master:

Ensures that the team is fully functional and productive;

Enables close cooperation across all roles and functions;

Shields the team from external interferences; and

Ensures that the process is followed,

The Team:

Is cross-functional, with experienced members;

Selects the Sprint goal and specifies work results;

Has the right to self-organized within the boundaries of the guidelines to reach the Sprint goal;

Demos work results to the Product Owner.

A Scrum software project is managed by maintains a Product backlog (Requirements list) and risks. Product Backlog is statement of works that the project must implement. Risks are things identify in product backlog that the team must mitigate.

Scrum allows project team to determine when the system is “good enough” to be released to customer. With Scrum, every project progresses through a series of iterations, usually four weeks in length, called “Sprints” (Short duration). At the start of each Sprint, a Sprint Planning Meeting is held during which the Product Owner prioritizes the Backlog and the team selects the tasks they can complete within that Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog. Each day a daily meeting called the Daily Scrum is held, to identify which activity has been completed and which is not and must be implemented on that day. This kind of meeting creates a visibility of each person’s work to facilitate knowledge sharing, reduce overlapping tasks, and ensure that their work is fully integrated. At the end of each Sprint, the team demonstrates the completed functionality at a Sprint Review Meeting. By having several sprints, the project team can build the software in several short durations incrementally with flexibility and fast (Agile).

The Scrum process consists of four activities: Sprint Planning, Daily Scrum, Sprint Review, and the Sprint Retrospective.

1) Sprint Planning

Preparation for a sprint begins when the Product Owner develops a plan for a product. The Product Owner must have a vision for the product and be able to breakdown the products into small pieces according to a plan with several releases, each focusing on certain features. The Product Owner prepares a Product Backlog, a list of features prioritized by customer.

The Scrum begins with the Product Owner reviewing the vision, the plan, the release schedule, and the Product Backlog with the team. The team reviews the estimates for features on the Product Backlog and decides how much work it can take into the sprint based on team size, available hours, and level of team expertise. The team pulls items from the Product Backlog that they can do within a thirty-day sprint into sprint backlog then the Scrum Master leads the team in a planning session to break down these features into sprint tasks. These are the specific development activities required to implement a feature for the sprint.

2) Daily Scrum

Once planning is complete, the Sprint begins its iteration cycle. Each day the Scrum Master leads the team in the Daily Scrum Meeting. The Daily Scrum is a short meeting designed to clarify the state of the Scrum. Each team member responds to three questions: 1).What has you done since the last Scrum meeting? 2) What are you planning to do today? 3) Are there any obstacles preventing you from performing work you are planning to do today? The goal is to get an status of the project, discover any new issues, address any personal needs of team members, and adjust the plan in real time to the needs of the day.

3) Sprint Retrospective

The meeting is attended by the team with the Scrum Master, and Product Owner.  The meeting starts with all team members answering two questions: 1) What went well during the last sprint? 2) What could be improved in the last sprint?  The Scrum Master documents the team answers in summary form, and the team prioritizes the order it wants to talk about the potential improvements. The Scrum Master facilitates the team’s search for improvement opportunities to the Scrum process, identified actions that can be added to the next sprint for improvement.

4) Sprint Review Meeting

Sprint Review Meeting is held at the end of a sprint. The first part is to demonstrate to the Product Owner the code that has been developed during the sprint. The Product Owner also invites customers to attend to review and to determine which features on the Product Backlog have been completed in this Sprint. The customers, product owner, Scrum master also discuss how to reprioritize the Product Backlog for the next sprint. Then the goal for the next sprint is defined and discussed on how the team will worked together in the next sprint.  After the Review Meeting, the process begins again with another sprint until all features have been done to complete a product.