Cẩm nang SDLC chuẩn AI: Cách Anthropic tái định nghĩa quy trình phát triển phần mềm với Claude

Code không còn là điểm nghẽn

Các tổ chức đã bắt đầu sử dụng AI để viết code với tốc độ không tưởng so với một năm trước, tuy nhiên các quy trình xoay quanh code lại chưa thay đổi với tốc độ tương xứng.

Nhiều đội ngũ kỹ thuật vẫn duy trì các cổng phê duyệt, đánh giá, bàn giao và chính sách cũ, làm đình trệ những lợi ích về năng suất có được từ việc sử dụng các giải pháp lập trình tác tử (agentic coding) như Claude Code.

Vòng đời phát triển phần mềm (SDLC) là quy trình đưa phần mềm từ ý tưởng đến giai đoạn vận hành thực tế. Hầu hết các tổ chức đều áp dụng một phiên bản của sáu giai đoạn giống nhau, bao gồm lập kế hoạch, thiết kế, xây dựng, kiểm thử, triển khai và bảo trì phần mềm. Theo truyền thống, mỗi giai đoạn là một bước riêng biệt do các vai trò khác nhau đảm nhiệm. Quản lý sản phẩm viết yêu cầu, kiến trúc sư kỹ thuật chuyển chúng thành thiết kế, kỹ sư xây dựng dựa trên thiết kế đó, đội ngũ QA tại các doanh nghiệp có quy định nghiêm ngặt sẽ kiểm chứng, đội ngũ phát hành thực hiện triển khai và bộ phận vận hành giám sát những gì đang chạy. Công việc luân chuyển giữa các giai đoạn thông qua tài liệu, phiếu yêu cầu (tickets) và các chữ ký phê duyệt.

SDLC truyền thống là một quy trình nặng nề nhằm đảm bảo trách nhiệm và quyền kiểm soát ở từng bước. Tuy nhiên, SDLC truyền thống được thiết kế để tối đa hóa hiệu quả trong thời đại mà giai đoạn tốn thời gian và chi phí nhất là viết và triển khai code, điều mà hiện nay không còn đúng nữa. Các tài liệu PRD, nghi thức ước tính và đánh giá bảo mật sản phẩm đều tồn tại để buộc sự đồng nhất trong suốt quá trình phát triển kéo dài hàng tuần, hàng tháng hoặc hàng quý.

SDLC truyền thống cũng có các biện pháp kiểm soát giả định rằng mọi bước đều do con người thực hiện. Những tổ chức tạo ra nhiều giá trị nhất đã xây dựng lại quy trình của họ dựa trên những gì AI tác tử có thể làm hiện nay, đồng thời đảm bảo con người vẫn nằm trong vòng lặp kiểm soát. Trong hướng dẫn này, chúng tôi sẽ đi qua một số phương pháp thực hành tốt nhất từ đội ngũ Applied AI của chúng tôi để tích hợp Claude vào nội bộ trong từng giai đoạn của SDLC nhằm tăng tốc phát triển và làm cho quy trình vận hành nhanh hơn, lấy cảm hứng từ quá trình làm việc với khách hàng của chúng tôi.

Khi code không còn là điểm nghẽn và giai đoạn xây dựng diễn ra nhanh hơn mức SDLC truyền thống cho phép, ba điều sau đây sẽ trở thành sự thật:

Hãy lấy điểm nghẽn bảo mật làm ví dụ. Các đội ngũ bảo mật được định biên dựa trên năng suất của con người, vì vậy khi các tác tử (agents) nhân rộng sản lượng code, hàng đợi đánh giá sẽ bị ùn ứ hoặc code sẽ được phát hành mà chưa được kiểm duyệt kỹ lưỡng. Một tổ chức có quy định nghiêm ngặt không thể chấp nhận cả hai kết quả này, vì vậy các bước kiểm tra bảo mật và chính sách của họ phải bắt kịp tốc độ của các tác tử.

Để hiện thực hóa tốt hơn những lợi ích về năng suất và bảo mật của AI tác tử, vòng đời SDLC truyền thống đòi hỏi sự chuyển đổi tương đương với những gì giai đoạn triển khai đã trải qua.

SDLC AI-native là gì?

SDLC AI-native là một quy trình được tái hình dung, kết hợp các mục tiêu kiểm soát cũ với các phương thức thực thi mới. Thay vì một luồng tuyến tính, quy trình trở thành một vòng lặp và AI được nhúng vào từng điểm. SDLC AI-native thúc đẩy việc bàn giao và kích hoạt tự động các bước tiếp theo, giúp giải quyết tính chất thủ công và cồng kềnh trong việc bàn giao giữa các giai đoạn của SDLC truyền thống.

Những thay đổi

Bảng dưới đây làm nổi bật các thái cực giữa SDLC truyền thống và SDLC AI-native, được hỗ trợ bởi Claude. Hầu hết các tổ chức đều nằm ở đâu đó giữa hai cột này.

Sợi chỉ đỏ xuyên suốt cột bên phải là các sản phẩm bàn giao (artifact) được cam kết. Mỗi giai đoạn kết thúc bằng việc ghi một sản phẩm vào hệ thống kiểm soát phiên bản (bao gồm intent.md, spec.md, plan.md, diff và các bài kiểm tra của nó, PR cùng các kết quả đánh giá, và hồ sơ sự cố) và giai đoạn tiếp theo bắt đầu bằng việc đọc nó. Đối với các giai đoạn đầu, các tệp.md là sản phẩm chủ đạo vì cả chủ sở hữu sản phẩm và tác tử đều có thể đọc và hành động trên cùng một tệp. Từ giai đoạn Xây dựng trở đi, sản phẩm là code và các hồ sơ của nó. Chuỗi các commit cũng chính là dấu vết kiểm toán: ai đã yêu cầu điều gì, tác tử đã tạo ra những gì và ai đã phê duyệt nó.

Con người vẫn chịu trách nhiệm cho mọi quyết định đòi hỏi sự phán đoán. Trong thế giới SDLC tác tử, sự chú ý của con người chuyển dịch cùng với các sản phẩm cần được đánh giá.

Mỗi giai đoạn cam kết một sản phẩm mà giai đoạn tiếp theo có thể đọc được. Cùng với nhau, intent, spec, plan, diff và các kết quả đánh giá tạo thành dấu vết kiểm toán.

Các bước thực hiện (Plays)

Các bước thực hiện là cốt lõi của bộ quy trình và được nhóm thành sáu giai đoạn phi tuyến tính (Lập kế hoạch, Thiết kế, Xây dựng, Kiểm thử, Triển khai, Bảo trì), cùng nhau bao quát toàn bộ vòng đời.

Mỗi bước thực hiện bao gồm:

Các bước này có tính mô-đun và các tổ chức có thể chọn ưu tiên chuyển đổi các giai đoạn khác nhau vào các thời điểm khác nhau dựa trên nhu cầu riêng của họ. Mỗi bước thực hiện liệt kê các phụ thuộc của nó trong phần "Điều kiện tiên quyết", điều này được minh họa rõ hơn bởi biểu đồ phụ thuộc.

Một giai đoạn kết thúc bằng việc cam kết một sản phẩm, với commit đó sẽ khởi động giai đoạn tiếp theo. Một tệp intent.md được chấp nhận sẽ kích hoạt các yêu cầu và giai đoạn thiết kế, một tệp spec.md được phê duyệt sẽ kích hoạt chế độ lập kế hoạch, một PR được hợp nhất sẽ kích hoạt đường ống (pipeline), và một ngưỡng kiểm soát bị vi phạm trong môi trường vận hành sẽ ghi ra tệp intent.md tiếp theo, và cứ thế vòng lặp tiếp tục.

Đầu tiên, bạn nhắc lệnh (prompt) từng bước bằng tay với trạng thái kết thúc là một vòng lặp, trong đó mỗi sản phẩm được chấp nhận sẽ kích hoạt cổng tiếp theo. Sự chú ý của con người tập trung vào các cổng, đánh giá những gì tác tử đã gắn cờ thay vì bắt đầu lại từng giai đoạn từ đầu.

01

Lập kế hoạch

Các ý tưởng không còn phải chờ đợi ai đó viết chúng ra. Ý định (intent) được ghi lại một lần, bằng chính ngôn từ của người khởi xướng, dưới dạng một sản phẩm được kiểm soát phiên bản mà giai đoạn tiếp theo có thể hành động dựa trên đó.

Ghi lại dưới dạng intent.md

Tệp intent.md, thứ khởi động quy trình phát triển phần mềm, có thể đi vào thông qua các con đường khác nhau. Một người có ý tưởng, một phiếu yêu cầu được tạo, hoặc một sự cố được phát hiện thông qua cảnh báo (xem Giai đoạn 6: Bảo trì).

Khi một người có ý tưởng, họ thảo luận với Claude và tạo ra một bản proto-spec (bản đặc tả sơ bộ) định dạng markdown. Trong SDLC truyền thống, cùng người đó sau đó phải thuyết phục một thành viên của nhóm sản phẩm viết ý tưởng đó ra cùng họ hoặc thay mặt họ.

Bản proto-spec do Claude tạo ra có thể đọc được bởi con người, được kiểm soát phiên bản và có thể được tiêu thụ ngay lập tức bởi giai đoạn tiếp theo. Bản proto-spec được lưu dưới dạng intent.md.

Bất kể ý định bắt nguồn từ một sự kiện kích hoạt hay từ một tác tử, các bước tương tự vẫn được áp dụng: chủ sở hữu sản phẩm xem xét và chỉnh sửa tệp intent.md do tác tử viết trước khi nó được cam kết.

Truyền thống: Một ý tưởng phải đi qua các mục trong backlog, các câu chuyện người dùng (user stories), điểm câu chuyện (story points) và các cuộc họp tinh chỉnh trước khi bất kỳ ai có thể hành động trên đó. Quyền sở hữu chuyển giao tại mỗi lần bàn giao, vì vậy những gì đến tay bộ phận kỹ thuật đã bị sai lệch vài bước so với ý định ban đầu của người khởi xướng.

AI-native: Người khởi xướng thảo luận với Claude và viết kết quả xuống dưới dạng intent.md, một bản proto-spec theo chính thuật ngữ của người khởi xướng. Sản phẩm này chứa đựng những gì được mong muốn, tại sao, và dưới những ràng buộc nào. Các quy trình lặp lại được mã hóa thông qua các kỹ năng (skills).

Bắt đầu

Điều kiện tiên quyết

Không có.

Hạ tầng