19 Jan, 2021
Phát triển phần mềm Agile
Agile là cách tiếp cận phát triển phần mềm trong đó tổ xây dựng phần mềm trong vài lần lặp ngắn, thay vì mọi thứ đi từ bắt đầu tới kết thúc. Agile cung cấp ích lợi như linh hoạt, dễ thay đổi, chất lượng tốt, ít rủi ro và thoả mãn khách hàng tốt hơn nhưng có “tiền điều kiện” mà tổ chức phải có để đạt tới những ích lợi này.
Agile yêu cầu sự tham gia của khách hàng trong mọi khía cạnh của dự án. Nếu khách hàng bận rộn và không thể tham gia được thì Agile sẽ KHÔNG có tác dụng. Một trong các phương pháp phổ biến nhất trong Agile là “Scrum”. Phương pháp này định nghĩa ba vai trò then chốt: “Người chủ sản phẩm” người đại diện cho khách hàng và chịu trách nhiệm viết yêu cầu và ưu tiên hoá chúng trong “tồn dư sản phẩm”. “Thầy Scrum,” người hướng dẫn và giúp đỡ tổ dự án vượt qua các chướng ngại và giữ cho họ hội tụ vào những điều họ phải làm. Tổ dự án, một nhóm “tự tổ chức” làm mọi điều một cách hiệu quả nhất để đạt tới kết quả. Dùng cách tiếp cận Agile là thay đổi chính trong tổ chức với cấu trúc phân cấp và mọi người thường nhận được “chỉ đạo” từ ông chủ. Đó là lí do tại sao tôi mạnh mẽ khuyến cáo rằng trước khi vào từng dự án, tổ phải nhận được đào tạo Agile “chính thức” để chắc rằng sẽ KHÔNG có hiểu lầm nào hay quan niệm lầm nào về cách tiếp cận này. Không có đào tạo đúng, Agile có thể bị DÙNG SAI vì một số người lập trình coi nó là “Làm bất kì điều gì bạn muốn,” “Mã trước, hỏi câu hỏi sau,” “Không tài liệu, không qui trình.”
Agile bao gồm một số thực hành mà hình thành nên nền tảng cho tổ chức muốn tuân theo cách tiếp cận này.
1) Tổ Agile phải xác định cho bản thân họ cách họ sẽ làm việc (thiết lập qui trình) và cách họ sẽ làm công việc (phát triển sản phẩm). Tổ Agile phải hiểu giá trị của dự án. Giá trị có thể được mô tả là “Linh hoạt”, “Chất lượng”, “Dễ thay đổi”, “Tự học, tổ học” v.v. Trong cách tiếp cận Agile, tổ đi qua “các giai đoạn phát triển tổ” khi họ thực hiện công việc của họ. Kết quả của phát triển tổ là bản thân tổ, và không phải là kĩ năng và năng lực mà các cá nhân học. Làm việc tổ là bản chất trong Agile, không có nó, Agile sẽ KHÔNG có tác dụng.
2) Lúc bắt đầu dự án, người chủ sản phẩm chuẩn bị một danh sách các yêu cầu của khách hàng hay “Tồn dư sản phẩm”, danh sách các tính năng được sắp ưu tiên bởi giá trị được chuyển giao cho khách hàng. Với từng lần lặp (Sprint – chặng nước rút), một số trong những khoản mục đó trong tồn dư sản phẩm được lựa ra và đưa vào trong “Sprint Backlog – Tồn dư nước rút”, danh sách những điều cần được làm trong từng chặng nước rút Sprint. Trong cách tiếp cận Agile, thay đổi là bình thường và được đưa vào trong tồn dư sản phẩm bởi người chủ sản phẩm vì khách hàng liên tục cung cấp phản hồi hay thêm nhiều tính năng. Tổ tiếp tục công việc trong vài lần lặp (Sprint) cho tới khi họ hoàn thành tồn dư sản phẩm.
3) Agile dùng các thời kì thời gian ngắn hay “Sprint” (phương pháp Scrum) điển hình quãng 2 tới 4 tuần, để chuyển giao cái gì đó cho khách hàng. Từng “Sprint” được tổ chức để cho tổ thực tế hoàn thành một mảnh của sản phẩm toàn bộ. Ngay khi mảnh này của sản phẩm có thể được chuyển giao, nhiều giá trị hơn có thể được thu lấy. Tính linh hoạt này giúp khách hàng có cái gì đó nhanh chóng để dùng, tổ cũng nhận phản hồi ngay lập tức, và giảm rủi ro dự án.
4) Mọi “Sprint” đều được cai quản bởi “phạm vi được xác định” trong tồn dư nước rút Sprint. Tổ ước lượng nỗ lực và chi phí của từng Sprint và điều phối với người chủ sản phẩm. Cách tiếp cận Agile dùng “chu kì học” tường minh (tức là, lập kế hoạch, làm, kiểm tra, hành động) hay (Lập kế hoạch, hành động, suy nghĩ, học) để cho tổ thường xuyên học, cải tiến và sẵn sàng điều chỉnh khớp theo thay đổi. Sau từng lần lặp (Sprint), tổ sẽ kiểm điểm công việc riêng của họ hay “nội quan-quan sát bên trong” để nhận diện công việc nào, cái gì không có tác dụng để cải tiến qui trình riêng của họ để cho họ có thể làm nó tốt hơn lần sau. Đó là lí do tại sao dự án Agile thường có chất lượng cao.
5) Tổ Agile phải có phương tiện trao đổi hiệu quả giữa các thành viên tổ và khách hàng. Để đạt tới điều đó, tổ cần trao đổi giữa con người thay vì bất kì cách nào khác như email, thư, văn bản hay tài liệu. Mặc dầu một số người nói rằng Agile cũng có thể được thực hiện trong phát triển toàn cầu, có các thành viên tổ ở nhiều chỗ hay ở nhiều nước. Theo kinh nghiệm của tôi, tôi thấy điều đó khá khó. Không có trao đổi tốt, tổ có thể phí thời gian về thông tin, các thành viên có thể hiểu lầm nhau, dự án có thể có nhiều lỗi hay phải làm lại. Không có trao đổi mặt đối mặt điều đó có thể làm chậm phát triển dự án, khó xây dựng tin cậy giữa các thành viên tổ, khó xây dựng tổ, và có thể KHÔNG có khả năng gióng thẳng cảm nhận về thực tại. Khuyến cáo cá nhân của tôi là đối với cách tiếp cận Agile, cách tốt nhất là để mọi thành viên tổ ở cùng một chỗ nơi họ có thể làm việc cùng nhau, hỗ trợ lẫn nhau, và chia sẻ thông tin một cách tự do.
6) Bằng kiểm thử mọi thứ, bằng việc tạo ra các trường hợp kiểm thử để kiểm tra mọi công việc, tổ có thể đạt tới mức chất lượng cực kì cao. Khả năng này để ngăn cản khiếm khuyết là rất quan trọng trong Agile bởi vì “chất lượng là KHÔNG thương lượng được”. Trong cách tiếp cận này, loại bỏ khiếm khuyết là kiểu làm việc duy nhất được coi là ưu tiên so với bất kì tính năng /chức năng/sản xuất mới. Nếu kết quả cuối cùng được mong muốn là làm cực đại chất lượng, thì loại bỏ khiếm khuyết là điều quan trọng nhất. Tổ có nghĩa vụ đạo đức để kiểm tra một cách hiệu quả công việc của họ bằng bất kì phương tiện nào họ có thể làm bằng việc dùng công cụ, cơ chế phản hồi đa dạng, tự động hoá để chắc họ có sản phẩm chất lượng cao nhất có thể được.
7) Mọi thành viên tổ Agile đều phải nhận trách nhiệm “phát quang con đường” hay loại bỏ chướng ngại ngăn cản công việc được thực hiện một cách hiệu quả. “Phát quang con đường” KHÔNG chỉ có nghĩa là mưu kế cách thức, sửa nhanh vấn đề, mà thay vì thế là để thời gian nhìn vào chướng ngại và làm tốt nhất có thể được để loại bỏ nó vĩnh viễn để cho nó không bao giờ chắn đường lần nữa. Trong cách tiếp cận Agile, người dẫn qui trình (thầy Scrum) là người chịu trách nhiệm theo dõi chướng ngại và đảm bảo rằng con đường được phát quang. Phát quan con đường đôi khi là công việc đau đớn làm phơi bày những điều mọi người thà không giải quyết. Kết quả là, điều mấu chốt là mọi người xây dựng năng lực của họ để chân thực và làm việc để phát triển tin cậy lẫn nhau.
—-English version—-
Agile software development
Agile is the software development approach in which the teams build software in several short iterations, instead of everything from start to finish. Agile offers benefits like flexibility, easy to change, good quality, less risks and better customer satisfaction but there are “pre-conditions” the organization must have in order to achieve these benefits.
Agile requires customer involvement in every aspect of the project. If the customer is busy and cannot participate then Agile will NOT work. One of the most popular method in Agile is “Scrum”. This method defines three key roles: The “Product owner” who represents the customers and responsible for writing requirements and prioritizes them in the “product backlog”. “Scrum-Master,” who guides and help the project team to overcome obstacles and keep them focusing on things they must do. The project team, a “self-organizing” group that do thing in the most efficient way to achieve the result. Using Agile approach is a major change in organizations with the hierarchical structure and people who used to receive “direction” from the boss. That is why I strongly recommend that before each project, the team must receive “formal” Agile training to make sure that there will NOT be any misunderstanding or misconception about the approach. Without proper training, Agile can be MISUSED as some programmers consider it as “Do whatever you want”, “Code first, ask question later”, “No documentation, no process”.
Agile consists of some practices that form the foundation for organization that wishes to follow this approach.
1) The Agile team must determine for themselves how they are going to work (establish the process) and how they are going to do the work (develop the product). Agile team must understand the value of the project. Value can be described as “Flexibility”, “Quality”, “Easy to change”, “Self learning, Team learning” etc. In Agile approach, the team goes through “stages of team development” as they perform their work. The result of team development is the team itself, and not the skills and abilities that the individuals learn. Teamwork is essential in Agile, without it, Agile will NOT work.
2) At the beginning of the project, the product owner prepares a list of customer requirements or “Product Backlog”, a list of features prioritized by value delivered to the customer. For each iteration (Sprint), some of these items in the product backlog is selected and put on the “Sprint Backlog”, a list of things to be done for each Sprint. In Agile approach, changes are normal and put in the Product backlog by the Product owner as customers continue to provide feedbacks or add more features. The team continue the work in several iterations (Sprint) until they complete the product backlog.
3) Agile uses short fixed periods of time or “Sprint” (Scrum method) typically about 2 to 4 weeks, to deliver something to customer. Each “Sprint” is organized so that the team actually finishes a piece of the total product. The sooner the piece of the product can be delivered, the more value it can be obtained. This flexibility help customers to have something quickly to use, the team also gets feedback immediately, and reduce project risks.
4) Every “Sprint” is governed by a “defined scope” in the Sprint backlog. The team estimates the efforts and costs of each Sprint and coordinate with the Product owner. Agile approach uses an explicit “learning cycle” (i.e., plan, do, check, act) or (Plan, action, reflection, learning) so the team is constantly learning, improving and readying to accommodate changes. After each iteration (Sprint), the team would review their own work or “retrospective” to identify what works, what does not work to improve their own process so they can do it better next time. That is why Agile project usually has high quality.
5) Agile team must have effective means of communicating among team members and to customers. To achieve it, a team needs in-person communication rather than any other way such as email, letter, text or document. Although some people claimed that Agile can also be done in global development, having team members located in several places or in several countries. In my experience, I found it rather difficult. Without a good communication, the team may waste time waiting for information, members may misunderstandings each other, project may have more defects or re-work. Without a face to face communication it may slow the project development, difficult to build trust among team members, difficult to build team, and may NOT be able to align perceptions of reality. My personal recommendation is for Agile approach, it is best to put all team members in a same place where they can work together, support each other, and share information freely.
6) By testing everything, by creating test cases to check all the works, a team can achieve extremely high quality levels. This ability to prevent defects is very important in Agile because “quality is NOT negotiable”. In this approach, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize quality, then removing defects is the most important thing. A team has an ethical duty to effectively test their work by whatever means they can do using tools, various feedback mechanisms, automation to make sure they have the highest quality product possible.
7) Every Agile team member must take responsibility for “clearing the path” or removing the obstacles that prevent work from being done effectively. “Clearing the Path” does NOT just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again. In Agile approach, the Process Facilitator (Scrum Master) is the person who is responsible for tracking obstacles and ensuring that the path is cleared. Clearing the Path is sometimes painful work that exposes things people would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other.