Agile có nên về với cội nguồn của nó - 1 Software Development Style thay vì được biết đến như là 1 quy trình phát triển phần mềm?

Sau 25 năm, Agile vẫn còn đó nhưng trọng tâm đã thay đổi

Tôi đã tham gia không ít dự án tự giới thiệu là đang vận hành theo Agile. Các team có sprint hai tuần, daily meeting vào mỗi buổi sáng, backlog được quản lý trên Jira và velocity được trình bày đều đặn trong những buổi review. Mọi thứ nhìn từ bên ngoài đều đúng quy trình, nhưng một thay đổi nhỏ vẫn mất vài tuần để đi qua development, integration test, security review và deployment. Release vẫn diễn ra theo quý, môi trường tích hợp thường xuyên bị nghẽn, còn developer gần như không có cơ hội trao đổi trực tiếp với người sử dụng sản phẩm. Những dự án như vậy có đầy đủ hoạt động Agile nhưng chưa có khả năng thay đổi phần mềm một cách an toàn và liên tục.

Tháng 2 năm 2026 đánh dấu tròn 25 năm kể từ khi Agile Manifesto được hình thành tại Snowbird, Utah. Một phần tư thế kỷ là khoảng thời gian đủ dài để một ý tưởng đi từ cộng đồng chuyên môn ra thị trường đại chúng, trở thành tiêu chuẩn của ngành, rồi dần mang những ý nghĩa khác với thời điểm ban đầu. Agile ngày nay thường được nhắc đến cùng sprint planning, story point, Scrum Master, roadmap, portfolio và các chương trình chuyển đổi tổ chức. Trong khi đó, tên đầy đủ của bản tuyên ngôn năm 2001 là Manifesto for Agile Software Development — Tuyên ngôn về phát triển phần mềm linh hoạt.

Sự khác biệt giữa hai cách nhìn không chỉ nằm ở thuật ngữ. Agile ban đầu được hình thành bởi những người trực tiếp thiết kế, lập trình, kiểm thử và giao phần mềm. Họ muốn tìm một cách làm phù hợp hơn với bản chất bất định của software development. Sau 25 năm, trọng tâm ở nhiều tổ chức đã dịch chuyển từ việc tạo ra một đội ngũ phát triển phần mềm chuyên nghiệp sang việc quản lý tiến độ của đội ngũ đó bằng một bộ quy trình mới.

Bài viết này không phủ nhận vai trò của quản lý dự án. Một chương trình phần mềm lớn vẫn cần ngân sách, kế hoạch, quản trị rủi ro, điều phối phụ thuộc và trách nhiệm giải trình. Vấn đề xuất hiện khi lớp quản lý được xem là toàn bộ Agile, còn năng lực engineering trở thành phần việc mà team có thể bổ sung sau.

Agile ra đời từ nỗi thất vọng của những người làm phần mềm

Trong thập niên 1990, nhiều tổ chức phát triển phần mềm bằng những quy trình nặng về tài liệu và kế hoạch ban đầu. Yêu cầu được cố gắng hoàn thiện trước, kiến trúc được thiết kế cho toàn bộ hệ thống, các giai đoạn phân tích, phát triển và kiểm thử được tách thành những chặng riêng biệt. Mỗi thay đổi sau khi baseline được phê duyệt thường phải đi qua một quy trình kiểm soát chính thức.

Cách tổ chức này tạo cảm giác chắc chắn cho hoạt động quản lý, nhưng phần mềm hiếm khi phát triển trong một môi trường chắc chắn. Khách hàng thường chỉ hiểu rõ nhu cầu sau khi sử dụng một phiên bản thực tế. Developer chỉ nhìn thấy nhiều ràng buộc kỹ thuật khi bắt đầu tích hợp. Thị trường, luật pháp, hạ tầng và hành vi người dùng đều có thể thay đổi trước khi kế hoạch ban đầu đi đến cuối vòng đời.

Song song với các quy trình nặng nề đó, nhiều phương pháp phát triển nhẹ hơn đã xuất hiện: Extreme Programming, Scrum, Crystal, Dynamic Systems Development Method, Adaptive Software Development, Feature-Driven Development và những cách tiếp cận pragmatic khác. Chúng không giống nhau về kỹ thuật hay quy trình, nhưng đều cố gắng rút ngắn vòng phản hồi, đưa phần mềm đến tay người dùng sớm hơn và trao nhiều quyền chủ động hơn cho đội ngũ thực hiện.

Từ ngày 11 đến 13 tháng 2 năm 2001, 17 người đại diện cho những trường phái này gặp nhau tại khu nghỉ dưỡng Snowbird, bang Utah. Họ không xây dựng một framework thống nhất, không thiết kế hệ thống chứng chỉ và cũng không đưa ra một quy trình chuẩn cho mọi dự án. Kết quả của cuộc gặp là bốn cặp giá trị cùng 12 nguyên tắc định hướng cách phát triển phần mềm.

Câu mở đầu của bản tuyên ngôn nói rằng những người tham gia đang khám phá các cách tốt hơn để phát triển phần mềm bằng việc trực tiếp thực hiện và giúp người khác thực hiện. Chi tiết “bằng việc trực tiếp thực hiện” rất đáng chú ý. Agile không khởi đầu như một lý thuyết quản trị được áp từ bên ngoài vào team. Nó được đúc kết từ kinh nghiệm của những người đang làm phần mềm và phải sống cùng hậu quả của các quyết định kỹ thuật mỗi ngày.

17 người đứng sau Agile Manifesto

Gọi cả 17 người là “kỹ sư phần mềm” có thể chưa phản ánh hết vai trò của họ. Trong nhóm có programmer, tester, architect, consultant, author và những người xây dựng phương pháp phát triển. Điểm chung quan trọng hơn là hầu hết đều có nền tảng thực hành phần mềm sâu và đã trực tiếp tạo ra hoặc vận hành những cách phát triển nhẹ trước khi thuật ngữ Agile xuất hiện.

• Kent Beck — Người khởi xướng Extreme Programming, phổ biến Test-Driven Development và đồng sáng tạo JUnit.
• Mike Beedle — Một trong những người áp dụng Scrum từ rất sớm, kết hợp Scrum với XP và đồng tác giả cuốn Agile Software Development with Scrum.
• Arie van Bennekum — Chuyên gia DSDM, facilitator và coach tập trung vào việc kết nối nhu cầu thực tế của business với quá trình phát triển.
• Alistair Cockburn — Người phát triển họ phương pháp Crystal và có ảnh hưởng lớn đến cách sử dụng use case trong phân tích hệ thống.
• Ward Cunningham — Người tạo ra WikiWikiWeb, đóng góp cho CRC cards, pattern community và các thực hành của Extreme Programming.
• Martin Fowler — Tác giả Refactoring, chuyên gia về software design, evolutionary architecture và các phương pháp phát triển thích nghi với con người.
• James Grenning — Chuyên gia embedded software, người sáng tạo Planning Poker và tác giả Test-Driven Development for Embedded C.
• Jim Highsmith — Người phát triển Adaptive Software Development và có nhiều đóng góp cho tư duy lãnh đạo trong môi trường bất định.
• Andrew Hunt — Đồng tác giả The Pragmatic Programmer, developer và consultant theo đuổi những thực hành kỹ thuật không phụ thuộc một framework cụ thể.
• Ron Jeffries — Một trong những coach đầu tiên của Extreme Programming và đồng tác giả Extreme Programming Installed.
• Jon Kern — Software architect, contributor của Feature-Driven Development và người ủng hộ việc giao kết quả hoạt động được theo từng vòng lặp ngắn.
• Brian Marick — Programmer và chuyên gia kiểm thử, một trong những người đặt nền móng cho cách tiếp cận Agile Testing.
• Robert C. Martin — Software engineer, consultant và tác giả có ảnh hưởng lớn về thiết kế, chất lượng code và trách nhiệm nghề nghiệp của developer.
• Steve Mellor — Đồng phát triển phương pháp Shlaer–Mellor và là một trong những tác giả quan trọng của Executable UML cùng model-driven development.
• Ken Schwaber — Đồng sáng tạo Scrum, developer, product manager và consultant về phát triển sản phẩm phần mềm.
• Jeff Sutherland — Đồng sáng tạo Scrum, từng giữ nhiều vai trò CTO và VP Engineering trong các công ty công nghệ.
• Dave Thomas — Đồng tác giả , developer và người nhấn mạnh rằng năng lực cùng sự tham gia của con người quan trọng hơn methodology.

Danh sách này giúp đặt Agile về đúng bối cảnh. Đây không phải một nhóm project manager tìm cách tối ưu hóa việc báo cáo tiến độ. Những người ở Snowbird mang theo kinh nghiệm về programming, testing, object-oriented design, patterns, refactoring, iterative delivery, facilitation và tổ chức team. Họ khác nhau về phương pháp, nhưng đều nhìn thấy một vấn đề chung: quy trình không thể thay thế năng lực của những người trực tiếp xây dựng sản phẩm.

Bốn giá trị của Agile Manifesto dưới góc nhìn phát triển phần mềm

Bốn giá trị được viết theo cấu trúc “X over Y”. Phần bên phải vẫn có giá trị, nhưng phần bên trái được ưu tiên khi hai phía xung đột, qua đó tạo ra một hệ thống định hướng quyết định thay vì một bộ luật tuyệt đối. Process, tool, documentation, contract và plan vẫn cần thiết trong nhiều bối cảnh. Một hệ thống ngân hàng cần tài liệu kiểm soát, một nền tảng y tế cần traceability, và một chương trình chính phủ cần hợp đồng cùng cơ chế governance. Những cơ chế đó nên phục vụ quá trình tạo ra sản phẩm và giúp đội ngũ kiểm soát rủi ro, thay vì biến việc tuân thủ cơ chế thành mục tiêu chính.

Individuals and interactions over processes and tools

Quy trình và công cụ giúp một team duy trì tính nhất quán. Source control, issue tracker, CI pipeline, coding convention hay definition of done đều có giá trị. Tuy nhiên, không công cụ nào tự giải quyết được sự khác biệt trong cách hiểu domain, một quyết định kiến trúc chưa rõ ràng hoặc một dependency đang bị bỏ quên giữa hai team.

Tôi từng gặp một chương trình có ba team cùng tích hợp qua một nhóm API dùng chung. Quy trình yêu cầu mọi thay đổi phải có ticket, cập nhật OpenAPI specification và được review trước khi merge. Trên bảng quản lý, mọi bước đều đã hoàn tất. Đến ngày tích hợp, một team hiểu trường status là trạng thái của giao dịch, team khác lại hiểu đó là trạng thái của quá trình đối soát. Schema đúng, pipeline xanh, tài liệu tồn tại, nhưng hệ thống vẫn sai vì không có cuộc trao đổi đủ sâu giữa những người chịu trách nhiệm cho hai domain.

Một buổi design session kéo dài 45 phút, có developer của cả hai phía và một domain expert, có thể giải quyết vấn đề tốt hơn nhiều ngày trao đổi qua ticket. Sau cuộc trao đổi, team vẫn cần cập nhật API contract, test và Architecture Decision Record. Điểm khác biệt là process và documentation lúc này ghi lại một sự hiểu biết đã được hình thành, thay vì cố thay thế sự hiểu biết đó.

Giá trị đầu tiên cũng liên quan trực tiếp đến quyền tự chủ kỹ thuật. Một team không thể tự tổ chức nếu mọi quyết định từ cách chia module, thiết kế API đến chiến lược test đều được áp xuống bởi một nhóm bên ngoài. Governance vẫn cần thiết ở hệ thống lớn, nhưng governance hiệu quả nên đưa ra guardrail, quality attributes và các ràng buộc bắt buộc; phần còn lại cần được trao cho những người gần vấn đề nhất.

Daily meeting là một ví dụ dễ thấy. Khi team dùng nó để phối hợp công việc, phát hiện dependency và điều chỉnh kế hoạch trong ngày, đây là interaction được hỗ trợ bởi process. Khi từng người lần lượt báo cáo trạng thái cho manager, cuộc họp đã biến thành một công cụ giám sát. Hình thức giống nhau nhưng giá trị hoàn toàn khác nhau.

Working software over comprehensive documentation

Tài liệu mô tả điều chúng ta tin rằng hệ thống sẽ làm, còn phần mềm hoạt động cho thấy hệ thống thực sự đang làm gì. Khoảng cách giữa hai thứ này là nơi rất nhiều dự án thất bại. Một tài liệu yêu cầu có thể mô tả chi tiết quy trình phê duyệt khoản vay với hàng chục trường dữ liệu và nhiều nhánh quyết định. Business, BA, developer và tester đều có thể đọc cùng một đoạn nhưng hình dung ra những hành vi khác nhau. Khi một vertical slice nhỏ được triển khai trên dữ liệu gần với thực tế, sự khác biệt thường xuất hiện ngay: người dùng cần lưu nháp ở một bước mà tài liệu không đề cập, một rule tự động hóa không áp dụng cho nhóm khách hàng đặc biệt, hoặc thời gian phản hồi của dịch vụ bên ngoài khiến luồng thao tác không thể sử dụng được.

Working software không có nghĩa là một màn hình demo được dựng để chạy qua happy path. Một increment chỉ tạo ra phản hồi có giá trị khi nó đủ gần với điều kiện thật: có integration cần thiết, dữ liệu đại diện, kiểm soát bảo mật, logging và một cách triển khai lặp lại được. Nếu mỗi sprint team demo trên máy cá nhân nhưng phải mất hai tháng để đưa code lên môi trường production-like, tổ chức mới chỉ có iteration ở lớp trình diễn, chưa có agility ở lớp delivery.

Trong các hệ thống regulated, comprehensive documentation vẫn là một deliverable thật. Architecture document, data lineage, threat model, test evidence và operational runbook có thể là điều kiện bắt buộc. Tuy nhiên, tài liệu tốt nhất thường được xây dựng cùng phần mềm và được kiểm chứng bởi phần mềm. Một sơ đồ deployment không còn đúng với pipeline thực tế chỉ tạo thêm cảm giác an toàn giả. Một API specification được kiểm tra bằng contract test có giá trị hơn một tài liệu được phê duyệt nhưng không còn đồng bộ với implementation.

Giá trị này kéo theo những năng lực kỹ thuật rất cụ thể: automated testing, continuous integration, reproducible environments, incremental database migration, observability và deployment automation. Không có những năng lực đó, “working software mỗi vài tuần” chỉ là một lời hứa mà team phải thực hiện bằng overtime và rủi ro.

Customer collaboration over contract negotiation

Contract negotiation trong bản tuyên ngôn không chỉ nói về hợp đồng pháp lý. Nó còn mô tả một kiểu quan hệ trong đó mỗi bên cố xác định ranh giới trách nhiệm thật chặt để tự bảo vệ mình. Business viết requirement, BA chuyển requirement thành user story, developer thực hiện đúng acceptance criteria, tester kiểm tra theo test case. Khi sản phẩm không giải quyết đúng vấn đề, mỗi nhóm vẫn có thể chứng minh rằng mình đã hoàn thành phần việc được giao. Cách tổ chức đó tối ưu trách nhiệm cục bộ nhưng thường làm mất trách nhiệm đối với kết quả chung. Trong một hệ thống xử lý hồ sơ, requirement có thể ghi rằng hồ sơ thiếu thông tin thu nhập phải bị từ chối. Developer triển khai rule này chính xác, test case cũng pass. Khi người vận hành sử dụng phiên bản đầu tiên, họ mới giải thích rằng một số hồ sơ đến từ kênh đối tác chưa có dữ liệu thu nhập tại thời điểm tiếp nhận và cần được chuyển sang hàng đợi xác minh thủ công. Team đã làm đúng câu chữ nhưng xây sai hành vi nghiệp vụ.

Một vòng cộng tác ngắn với người vận hành sẽ thay đổi cả thiết kế functional lẫn kiến trúc. Hệ thống không còn hai trạng thái đơn giản là accepted và rejected; nó cần một workflow có trạng thái pending verification, audit trail, quyền xử lý và timeout. Đây là lý do developer và architect cần được tiếp xúc với business context, thay vì chỉ nhận một danh sách ticket đã được phân rã qua nhiều tầng trung gian.

Customer collaboration không đồng nghĩa với việc khách hàng có thể thay đổi mọi thứ mà không quan tâm chi phí. Một quan hệ hợp tác trưởng thành phải làm rõ trade-off. Khi business muốn đưa một rule mới vào release gần nhất, team cần giải thích ảnh hưởng đến security, data migration, testing và các cam kết khác. Hai phía cùng lựa chọn, thay vì một phía đưa yêu cầu và phía còn lại chỉ estimate.

Ở góc độ kiến trúc, sự cộng tác thường tạo ra những quyết định tốt hơn vì team hiểu điều gì thực sự biến động trong domain. Một rule pricing thay đổi hàng tuần nên được cô lập khỏi core transaction flow. Một quy trình chỉ xuất hiện trong một thị trường không nên làm phức tạp toàn bộ domain model. Những hiểu biết này hiếm khi xuất hiện đầy đủ trong một tài liệu ký ở đầu dự án; chúng được hình thành qua các vòng phản hồi với người sử dụng sản phẩm.

Responding to change over following a plan

Một kế hoạch luôn được xây dựng từ lượng thông tin hữu hạn tại một thời điểm. Khi dự án bắt đầu, chúng ta thường biết ít nhất về hệ thống nhưng lại được yêu cầu đưa ra những cam kết dài nhất. Agile không loại bỏ planning; nó xem plan như một giả thuyết cần được cập nhật khi xuất hiện thông tin mới.

Tôi từng tham gia một dự án mà kiến trúc ban đầu giả định toàn bộ người dùng sẽ được xác thực qua một identity provider duy nhất. Sau vài tháng, chương trình mở rộng sang một thị trường mới với yêu cầu lưu trữ dữ liệu và cơ chế định danh khác. Nếu team xem architecture baseline là kế hoạch bất biến, thay đổi này sẽ trở thành một ngoại lệ đắt đỏ. Nếu authentication đã được tách khỏi business domain qua một boundary rõ ràng, thay đổi vẫn tốn effort nhưng không buộc team viết lại toàn bộ hệ thống.

Khả năng đáp ứng thay đổi vì thế không chỉ nằm trong backlog refinement. Nó được quyết định bởi cấu trúc của codebase, mức độ coupling, test coverage có ý nghĩa, khả năng quan sát hệ thống và độ tin cậy của deployment pipeline. Một Product Owner có thể đổi thứ tự backlog trong vài phút, nhưng nếu một business rule nhỏ chạm vào mười service và cần ba tuần regression test thủ công thì tổ chức không thực sự linh hoạt.

Đây cũng là nơi kiến trúc cần tránh hai cực đoan. Thiết kế toàn bộ tương lai từ đầu tạo ra nhiều abstraction chưa được kiểm chứng. Không đầu tư vào kiến trúc lại khiến mọi thay đổi mới làm tăng coupling. Cách tiếp cận phù hợp hơn là xác định những quality attributes quan trọng, tạo boundary quanh phần domain có khả năng biến động, trì hoãn những quyết định có thể đảo ngược và liên tục cải thiện thiết kế dựa trên điều team học được.

Responding to change không có nghĩa là thay đổi thiếu kỷ luật. Một team có khả năng phản ứng tốt thường có discipline mạnh hơn: test tự động đáng tin cậy, review kỹ thuật, feature flag, backward-compatible API, migration plan và cơ chế rollback. Chính kỷ luật kỹ thuật làm cho thay đổi trở thành hoạt động bình thường thay vì một cuộc khủng hoảng.

Agile nguyên bản chứa một nền tảng engineering rất rõ

Nếu chỉ đọc bốn giá trị ở mức khẩu hiệu, Agile có thể trông giống một triết lý quản lý mang tính khái quát. Mười hai nguyên tắc phía sau bản tuyên ngôn cho thấy phạm vi cụ thể hơn nhiều. Chúng nói đến việc giao phần mềm có giá trị sớm và liên tục, giao working software thường xuyên, xem working software là thước đo chính của tiến độ, duy trì nhịp độ bền vững, để business và developer làm việc cùng nhau hằng ngày, xây team quanh những cá nhân có động lực, liên tục quan tâm đến technical excellence và good design, đồng thời để kiến trúc cùng thiết kế hình thành từ team tự tổ chức. Những nguyên tắc này mô tả năng lực vận hành của một đội ngũ phát triển phần mềm, trong đó technical excellence là điều kiện để giữ chi phí thay đổi ở mức chấp nhận được chứ không phải phần trang trí chỉ được bổ sung khi lịch trình cho phép. Good design giúp team tiếp tục delivery sau sprint thứ 20 mà không bị chính codebase của mình kéo chậm lại. Sustainable pace cũng không chỉ là một chính sách nhân sự; nó ngăn việc team dùng overtime để che giấu một quy trình build, test và release thiếu ổn định.

Agile ban đầu cũng không đồng nhất với một methodology duy nhất. Nhóm Snowbird không chọn Scrum, XP hay Crystal làm tiêu chuẩn. Họ giữ lại bốn giá trị vì hiểu rằng bối cảnh của mỗi sản phẩm khác nhau. Một startup đang tìm product–market fit không cần cùng một governance model với hệ thống thanh toán quốc gia. Một embedded system có chu kỳ hardware dài không thể release giống một web application. Giá trị chung định hướng quyết định, còn practice phải thích nghi với môi trường.

Vì sao Agile dần trở thành một cách quản lý dự án

Sự dịch chuyển này không xảy ra trong một ngày và cũng không thể quy cho một nhóm nghề nghiệp cụ thể. Khi Agile chứng minh được sức hấp dẫn, các tổ chức lớn bắt đầu tìm cách áp dụng nó trên quy mô rộng. Để một ý tưởng đi vào doanh nghiệp, nó thường được diễn đạt thành vai trò, quy trình, artifact, maturity model, chương trình đào tạo và tiêu chí đánh giá. Đây là phản ứng dễ hiểu của một tổ chức cần phối hợp hàng trăm hoặc hàng nghìn người, nhưng những phần dễ đóng gói nhất của Agile thường không phải những phần trực tiếp tạo ra agility.

Ceremony dễ triển khai hơn năng lực engineering

Có thể thiết lập sprint hai tuần chỉ bằng việc đổi lịch làm việc. Có thể tạo backlog, bổ nhiệm Product Owner, tuyển Scrum Master và đưa toàn bộ công việc lên một board trong thời gian tương đối ngắn. Việc xây dựng một test suite đáng tin cậy, chia nhỏ một monolith, tự động hóa deployment, cải thiện observability hoặc phát triển khả năng thiết kế của team lại cần nhiều tháng, đôi khi nhiều năm.

Vì vậy, transformation program thường bắt đầu và kết thúc ở phần dễ quan sát. Ban lãnh đạo nhìn thấy nhiều ceremony hơn, nhiều dashboard hơn và một hệ thống vai trò mới. Codebase vẫn như cũ, release process vẫn như cũ, dependency giữa các team vẫn như cũ. Tổ chức đã thay ngôn ngữ quản lý nhưng chưa thay đổi khả năng phát triển phần mềm.

Những gì đo được dần thay thế những gì có giá trị

Velocity, story point, sprint completion rate và utilization tạo ra số liệu rõ ràng cho báo cáo. Chúng có thể hỗ trợ một team tự lập kế hoạch trong phạm vi hẹp, nhưng trở nên nguy hiểm khi được dùng để so sánh team, đánh giá cá nhân hoặc cam kết output với cấp quản lý.

Khi velocity trở thành mục tiêu, story point sẽ mất ý nghĩa ban đầu. Khi utilization phải đạt gần 100%, team không còn khoảng trống để xử lý technical debt, hỗ trợ nhau hay học về domain. Khi số ticket hoàn thành được xem là tiến độ, những thay đổi nhỏ dễ đóng sẽ được ưu tiên hơn việc giải quyết một bottleneck kiến trúc có ảnh hưởng dài hạn. Working software từng được xem là thước đo chính của tiến độ, nhưng trong nhiều tổ chức, vị trí đó dần được thay bằng mức độ hoàn thành của kế hoạch sprint.

Chứng chỉ và framework tạo ra một thị trường dễ mở rộng

Một năng lực kỹ thuật sâu rất khó được xác nhận sau một khóa học ngắn. Khả năng thiết kế một hệ thống có thể thay đổi, refactor code an toàn hay xây dựng pipeline đáng tin cậy chỉ hình thành qua thực hành và phản hồi trong thời gian dài. Ngược lại, role, event, artifact và vocabulary có thể được chuẩn hóa thành giáo trình, bài thi và chứng chỉ.

Khi Agile trở thành một thị trường đào tạo, tư vấn và transformation, nó cần những sản phẩm có thể lặp lại. Framework mới, cấp độ chứng nhận mới và mô hình operating model mới giúp thị trường tiếp tục phát triển. Điều này không có nghĩa mọi khóa học hay framework đều vô ích. Chúng có thể cung cấp ngôn ngữ chung và giúp tổ chức bắt đầu thay đổi. Rủi ro xuất hiện khi việc hoàn thành framework được xem là bằng chứng rằng tổ chức đã trở nên Agile.

Scrum dần được dùng như một từ đồng nghĩa với Agile

Scrum cung cấp một framework quản lý công việc tương đối dễ hiểu: Product Backlog, Sprint, Product Owner, Scrum Master và các event định kỳ. Nó giải quyết một phần quan trọng của bài toán phối hợp và tạo vòng phản hồi. Tuy nhiên, Scrum không quy định cách thiết kế code, xây test automation, quản lý kiến trúc hay triển khai phần mềm.

Khi Scrum được triển khai mà không có engineering practices tương ứng, team có thể tạo ra increment mới mỗi sprint nhưng chất lượng nội tại giảm dần. Sprint đầu tiên diễn ra nhanh, sprint thứ mười bắt đầu chậm lại, và sau một năm phần lớn thời gian được dùng để sửa regression, xử lý dependency và chờ môi trường. Framework quản lý vẫn hoạt động đúng lịch trong khi khả năng thay đổi sản phẩm suy giảm, vì vậy một team có thể thực hành Scrum rất nghiêm túc nhưng vẫn chưa Agile theo nghĩa ban đầu.

Agile transformation thường được điều hành từ bên ngoài team

Giá trị đầu tiên đặt individuals and interactions cao hơn processes and tools, nhưng nhiều chương trình transformation lại bắt đầu bằng việc áp một process chuẩn lên hàng loạt team. Team được yêu cầu thay đổi cấu trúc họp, cách viết ticket, estimation scale và reporting line trước khi có cơ hội xác định bottleneck thực sự trong delivery flow. Khi transformation được đánh giá bằng mức độ tuân thủ framework, team học cách trình bày rằng mình đang làm đúng: retrospective trở nên an toàn và ít tác động, estimate được điều chỉnh để khớp kỳ vọng, còn những vấn đề như shared database, manual deployment, unstable test hay architecture ownership nằm ngoài phạm vi thảo luận. Cách triển khai mang tính command-and-control này làm giảm chính khả năng tự điều chỉnh mà chương trình đang cố xây dựng.

Lớp vỏ Agile và năng lực thay đổi thật sự

Sau nhiều năm làm việc với các hệ thống enterprise, tôi thường phân biệt hai lớp khi đánh giá một tổ chức đang vận hành Agile đến đâu. Coordination agility thể hiện ở khả năng lập kế hoạch ngắn hạn, nhìn thấy công việc, điều chỉnh ưu tiên và phối hợp stakeholder; Scrum, Kanban, backlog cùng các ceremony hỗ trợ lớp này khá tốt. Technical agility thể hiện ở khả năng thay đổi code, dữ liệu, hạ tầng và kiến trúc với tốc độ đủ nhanh mà vẫn giữ hệ thống ổn định, dựa trên modularity, automated tests, CI/CD, observability, evolutionary design, ownership và kỹ năng của developer.

Nhiều tổ chức đầu tư mạnh vào lớp thứ nhất vì nó dễ nhìn thấy, nhưng kỳ vọng nhận được kết quả của lớp thứ hai. Họ thay đổi backlog thường xuyên rồi thất vọng khi team không thể giao nhanh. Team bị yêu cầu tăng velocity trong khi integration test mất ba ngày, release cần 12 chữ ký và một thay đổi schema phải được đồng bộ giữa sáu hệ thống. Trong hoàn cảnh đó, thêm một ceremony hiếm khi giải quyết được vấn đề vì bottleneck nằm trong kiến trúc và delivery system.

Tôi từng thấy một chương trình có tám squad, đầy đủ Product Owner và Scrum Master, roadmap được quản lý rất kỹ. Tuy nhiên, tất cả service phải tích hợp trên một môi trường dùng chung, contract test gần như không tồn tại, và mỗi lần deployment cần một nhóm vận hành thực hiện thủ công. Các team hoàn thành phần việc trong sprint nhưng phải chờ nhiều tuần để kiểm chứng end-to-end. Velocity của từng squad trông ổn, lead time của toàn hệ thống lại tiếp tục tăng.

Khi chương trình chuyển trọng tâm sang tạo môi trường kiểm thử độc lập, chuẩn hóa contract testing, tự động hóa deployment và phân quyền ownership theo domain, số ceremony không tăng nhưng thời gian đưa thay đổi đến môi trường thật giảm rõ rệt. Đây mới là loại thay đổi mà Agile ban đầu hướng tới: cải thiện khả năng biến phản hồi thành phần mềm hoạt động.

Vai trò của Solution Architect trong một team Agile

Trong nhiều team, Agile bị diễn giải theo hai cực: hoặc kiến trúc không còn cần thiết vì thiết kế sẽ tự hình thành, hoặc architect phải hoàn thành toàn bộ kiến trúc trước khi developer bắt đầu. Cả hai cách tiếp cận đều bỏ qua bản chất học hỏi liên tục của software development.

Trong môi trường Agile, kiến trúc cần tạo ra optionality — khả năng thay đổi hướng với chi phí có thể kiểm soát. Điều này không đòi hỏi dự đoán mọi yêu cầu tương lai. Nó đòi hỏi team nhận biết những quyết định khó đảo ngược, những quality attributes quan trọng và các boundary cần được bảo vệ.

Một Solution Architect không chỉ đưa ra target architecture. Architect cần làm việc đủ gần với delivery để nhìn thấy nơi thiết kế đang giúp team phản ứng nhanh và nơi nó đang trở thành bottleneck. Có những quyết định nên được chuẩn hóa ở cấp chương trình, chẳng hạn identity, audit, encryption hay observability. Có những quyết định nên để team tự chọn, chẳng hạn cấu trúc module nội bộ hoặc cách tổ chức test trong một service. Phân biệt hai loại quyết định này là một phần quan trọng của kiến trúc thích nghi.

Architect cũng cần bảo vệ technical work khỏi việc bị coi là “không tạo business value”. Refactoring một boundary sai, cải thiện build time hay bổ sung contract test có thể không tạo ra một màn hình mới, nhưng chúng làm giảm chi phí của nhiều thay đổi sau đó. Tuy nhiên, technical investment cũng không nên được biện minh bằng những khẩu hiệu chung. Team cần chỉ ra bottleneck cụ thể, rủi ro đang tồn tại và kết quả mong đợi.

Theo kinh nghiệm của tôi, kiến trúc Agile tốt thường xuất hiện dưới dạng những vòng quyết định ngắn: làm rõ quality attribute, thử một vertical slice, đo hành vi thật, ghi lại quyết định quan trọng, rồi điều chỉnh. Tài liệu vẫn tồn tại, nhưng nó sống cùng code và được cập nhật khi hiểu biết thay đổi. Governance vẫn tồn tại, nhưng tập trung vào rủi ro và outcome thay vì kiểm tra xem team đã điền đủ template hay chưa.

Đưa development trở lại trung tâm của Agile

Scrum Master, project manager, chứng chỉ và framework vẫn có thể hữu ích trong đúng bối cảnh, miễn là chúng được đặt ở vai trò hỗ trợ team tạo ra sản phẩm thay vì thay thế năng lực tạo ra sản phẩm. Một tổ chức có thể bắt đầu bằng cách thay đổi các câu hỏi trong những buổi review. Thay vì chỉ hỏi team hoàn thành bao nhiêu story point, hãy xem một ý tưởng mất bao lâu để đi từ quyết định đến production. Thay vì chỉ kiểm tra sprint commitment, hãy kiểm tra tỷ lệ deployment thất bại, thời gian khôi phục, số bước thủ công và những dependency khiến team phải chờ. Thay vì đánh giá documentation theo số trang, hãy kiểm tra liệu một developer mới có thể hiểu boundary, vận hành service và thay đổi một rule an toàn hay không.

Ở cấp team, một vài câu hỏi thường cho thấy nhiều hơn cả bảng maturity model:

• Team có thể đưa một thay đổi nhỏ lên production trong vài ngày hay không?
• Developer có thể sửa một business rule quan trọng mà không cần regression test toàn hệ thống trong nhiều tuần hay không?
• Những người viết code có được nghe trực tiếp vấn đề từ user hoặc domain expert hay không?
• Retrospective có dẫn đến thay đổi thật trong cách build, test và release hay chỉ kết thúc bằng vài action item chung chung?
• Architecture đang giảm chi phí thay đổi hay buộc mọi thay đổi phải đi qua thêm nhiều team?
• Metrics đang phản ánh customer outcome và delivery flow hay chỉ phản ánh mức độ bận rộn?

Câu trả lời không cần hoàn hảo. Mỗi hệ thống có constraint riêng, đặc biệt trong các ngành regulated hoặc chương trình có nhiều vendor. Điều quan trọng là tổ chức nhìn đúng vào nơi agility được tạo ra. Một team không linh hoạt hơn chỉ vì backlog có thể thay đổi mỗi ngày. Team linh hoạt hơn khi có thể biến thay đổi đó thành phần mềm hoạt động mà không làm chất lượng suy giảm.

Agile không thất bại, nhưng chúng ta đã dễ dàng chọn phần đơn giản hơn

Sau 25 năm, Agile đã giúp ngành phần mềm thay đổi theo nhiều hướng tích cực. Iterative delivery, cross-functional team, continuous feedback và product thinking đã trở thành những khái niệm quen thuộc, vì vậy mục tiêu không phải quay lại năm 2001 hay sao chép nguyên trạng một phương pháp cũ.

Điều đáng nhìn lại là sự thay đổi về trọng tâm. Agile bắt đầu từ những người làm phần mềm đang tìm cách xây dựng sản phẩm tốt hơn trong một môi trường nhiều bất định. Khi trở nên phổ biến, nó được đóng gói thành role, event, artifact, framework và certification. Phần quản lý dễ truyền đạt hơn, dễ mua hơn và dễ đo lường hơn. Phần engineering khó hơn vì đòi hỏi thời gian, thực hành và những thay đổi sâu trong codebase lẫn cấu trúc tổ chức.

Tôi không cho rằng project management đã “chiếm mất” Agile theo một cách đơn giản. Một tổ chức lớn luôn cần quản lý tốt. Nhưng quản lý tốt không tự tạo ra một team Agile, cũng như một sprint board không tự tạo ra working software. Agile chỉ thực sự tồn tại khi những người xây dựng sản phẩm có đủ kỹ năng, quyền chủ động và nền tảng kỹ thuật để phản ứng với điều họ học được.

Bản tuyên ngôn năm 2001 không hứa rằng mọi dự án sẽ nhanh hơn sau khi đổi quy trình. Nó đặt ra một hệ thống ưu tiên: con người trước cơ chế, phần mềm hoạt động trước bằng chứng trên giấy, cộng tác trước tự bảo vệ trách nhiệm và khả năng thích nghi trước lòng trung thành với một kế hoạch đã cũ.

Một phần tư thế kỷ sau, những ưu tiên đó vẫn còn nguyên giá trị. Việc khó nhất không phải nhớ bốn câu trong Agile Manifesto. Việc khó nhất là xây dựng một tổ chức đủ tin tưởng developer, đủ kỷ luật về engineering và đủ gần khách hàng để sống theo chúng.

Tài liệu tham khảo

• Manifesto for Agile Software Development, 2001.
• Principles behind the Agile Manifesto, 2001.
• History: The Agile Manifesto, Agile Manifesto Authors.
• Authors: The Agile Manifesto, Agile Manifesto Authors.
• Bản tuyên ngôn Agile – lịch sử hình thành Agile, Atoha, 2020.
• The State of Agile Software in 2018, Martin Fowler.
• Robert C. Martin, bài viết phân tích sự dịch chuyển và thương mại hóa của phong trào Agile, Clean Coder Blog, 2018.