Sharkly vs. Jira: AI Agent của bạn thực sự nên chạy ở đâu?

Backlog của bạn nằm trong Jira. Không ai có ý định chuyển nó đi đâu. Các epic vẫn ở đó, báo cáo sprint vẫn gửi lên ban lãnh đạo, và ba nhóm khác đang phụ thuộc vào những mã work item ấy. Vậy nên khi ai đó hỏi liệu một AI coding agent có nên nhận JIRA-4821 hay không, câu hỏi không phải là "chúng ta có nên thay thế Jira không". Nó hẹp hơn và thực tế hơn nhiều: agent thực sự chạy ở đâu, ai kiểm duyệt những gì nó tạo ra, và liệu kết quả đó có quay trở lại ticket hay không?

Đó mới là phép so sánh thực sự. Jira hiện đã có agent, và chúng hoạt động được. Sharkly cũng chạy agent, trên những máy tính do bạn kết nối, rồi đồng bộ kết quả trở lại Jira. Bài viết này phân định rạch ròi ranh giới giữa hai bên, kể cả những trường hợp mà việc thêm Sharkly là thừa thãi.

TL;DR

Jira là một hệ thống lưu trữ chính thức, nay được bổ sung khả năng thực thi agent. Sharkly là một lớp thực thi kết nối tới hệ thống lưu trữ chính thức của bạn. Rovo Dev của Atlassian đảm nhận lập kế hoạch, viết code và review bên trong môi trường của Atlassian, và bạn có thể giao work item cho agent ngay từ danh sách người được giao việc. Sharkly chạy bất kỳ Runtime nào mà nhóm bạn đã trả phí, trên những Computer bạn kết nối, lưu dấu vết thực thi trên một Task dùng chung, và đồng bộ hai chiều với Jira Cloud, Server hoặc Data Center. Nếu công việc agent của bạn nằm gọn trong các môi trường mà Atlassian hỗ trợ thì chỉ riêng Jira là đủ. Còn nếu agent cần chạy trên máy của chính bạn, với runtime của bạn và cổng kiểm duyệt của bạn, Sharkly sẽ bổ sung lớp đó mà không đá Jira ra khỏi cuộc chơi.

Điểm mạnh của Jira, nói thẳng ra

Hãy để Jira thể hiện ở phiên bản tốt nhất của nó, bởi vì phiên bản trung thực vốn đã rất mạnh.

Jira là nơi một công ty thống nhất xem công việc nào đang tồn tại. Sự thống nhất đó có giá trị thật: mã dùng chung, mô hình phân quyền, lịch sử kiểm toán, những báo cáo mà bộ phận tài chính và ban lãnh đạo vẫn đọc hằng ngày. Bất kỳ công cụ nào yêu cầu một nhóm từ bỏ nó đều đang đòi hỏi một thứ rất đắt.

Atlassian cũng không ngồi yên trước làn sóng agent. Rovo Dev được Atlassian mô tả là "một AI agent nhận biết ngữ cảnh, giúp tăng tốc vòng đời phát triển phần mềm bằng cách xử lý lập kế hoạch, viết code, review và tự động hóa các công việc lặp lại ở quy mô lớn". Nó đối chiếu các thay đổi code với tiêu chí chấp nhận trong Jira, và hoạt động xuyên suốt terminal CLI, Bitbucket Cloud, GitHub và VS Code. Atlassian cho biết Rovo Dev Standard đã chính thức khả dụng cho mọi khách hàng mới và hiện hữu, với hạn mức credit theo tháng đang được triển khai trên các gói Cloud Standard, Premium và Enterprise.

Mô hình giao việc này thực sự rất hay. Bạn mở danh sách người được giao việc trên một work item và chọn một agent y như chọn một đồng nghiệp, và danh sách đó có cả agent của bên thứ ba như GitHub Copilot coding agent. Đội ngũ kỹ thuật của chính Atlassian đã công bố bài viết về việc giao 120 PR trong hai tuần nhờ dùng Rovo Dev trong Jira. Đó không phải con số demo. Đó là một nhóm báo cáo năng suất trên công việc thật.

Vậy nên điểm xuất phát không phải là "Jira đang tụt lại phía sau", mà là "Jira đã có câu trả lời, và bạn nên biết chính xác câu trả lời đó bao phủ những gì".

Jira dừng lại ở đâu

Ranh giới nằm ở chỗ quá trình thực thi diễn ra ở đâu và nó có thể với tới những công cụ nào.

Khả năng thực thi agent gốc trong Jira chỉ diễn ra bên trong các môi trường mà Atlassian hỗ trợ. Đó là một lựa chọn thiết kế có chủ đích, và với rất nhiều nhóm thì đó là lựa chọn đúng. Nó cũng đồng nghĩa câu hỏi về runtime đã được trả lời sẵn cho bạn. Nếu lập trình viên của bạn đã chuẩn hóa trên Claude Code với một bộ Skills cụ thể, trên Codex thông qua gói đăng ký ChatGPT, trên Gemini CLI, trên OpenCode, hay trên thứ gì đó bạn tự xây theo một giao thức tùy chỉnh, thì con đường gốc của Jira không chạy những thứ đó theo đúng cách mà lập trình viên của bạn vẫn chạy trên máy local.

Còn một ranh giới thứ hai mà phần lớn các bài so sánh không chịu thừa nhận: cỗ máy. Công việc của agent không chỉ là một lần gọi model. Nó cần một bản checkout, một trình quản lý gói, các biến môi trường, một cơ sở dữ liệu local, tuyến VPN tới API staging của bạn, cùng hai mươi thứ nhỏ nhặt khiến repo của bạn build được trên laptop nhưng lại không build được trong một container chung chung. Các nhóm thường đụng phải chuyện này vào tuần thứ hai, chứ không phải tuần đầu.

Và còn một câu hỏi về kiểm duyệt. Khi một agent tạo ra thay đổi, sản phẩm hữu ích không chỉ là pull request. Đó còn là dấu vết thực thi: agent được yêu cầu điều gì, nó đã đọc gì, đã thử gì, mắc kẹt ở đâu, và con người đã quyết định thế nào về kết quả đó. Bản ghi ấy cần một chỗ lưu mà người tiếp theo có thể đọc được.

Khi nào nên dùng cái nào

Tài liệu của chính Sharkly nói thẳng về sự phân chia công việc, và ở đây chúng tôi cũng nói thẳng như vậy.

Chỉ dùng Jira khi công việc agent của bạn nằm gọn trong các môi trường Atlassian hỗ trợ, repository của bạn nằm trên Bitbucket hoặc GitHub, và những agent bạn muốn dùng chính là những agent mà Jira đã có thể giao việc. Bạn có cả hệ thống lưu trữ chính thức lẫn đường thực thi trong một sản phẩm, chỉ trả tiền một lần. Thêm một lớp nữa chỉ mang lại sự phức tạp không cần thiết. Đây là khuyến nghị thật lòng, không phải câu nói nước đôi.

Thêm Sharkly khi quá trình thực thi buộc phải diễn ra trên phần cứng và runtime do bạn kiểm soát. Một Computer trong Sharkly đóng vai trò máy chủ thực thi cho công việc của Agent, và nó có thể là máy local, một server từ xa, một container, hoặc một cloud host được hỗ trợ. Một dịch vụ local nhỏ sẽ kết nối Computer đó với Sharkly, phát hiện các Runtime sẵn có, nhận việc, chuẩn bị thư mục task, khởi chạy Runtime được chọn và truyền tiến độ về theo thời gian thực. Đó chính là phần mà Jira không hề cố gắng đảm nhận.

Xin định nghĩa một khái niệm, vì phần còn lại đều dựa vào nó. Task là đơn vị công việc chính trong Sharkly. Nó chứa mục tiêu và phần mô tả, người chịu trách nhiệm, Agent hoặc Crew được giao thực thi, các bình luận, trạng thái thực thi, dấu vết thực thi và kết quả. Nếu một issue trên Jira ghi nhận rằng công việc đang tồn tại, thì một Task trong Sharkly ghi nhận công việc đó đã được làm như thế nào, bởi agent nào, trên cỗ máy nào.

Bạn không nhất thiết phải chọn: con đường đồng bộ

Đây là chỗ mà hầu hết các bài viết theo kiểu "Sharkly vs Jira" làm sai. Hai công cụ không loại trừ nhau, và khả năng tích hợp đã được ghi trong tài liệu chứ không chỉ là mong muốn.

Tính năng tích hợp Jira của Sharkly hỗ trợ Jira Cloud và Jira Server hoặc Data Center, với ba chế độ:

• Import sao chép dữ liệu Jira hiện có vào Sharkly. Dùng cho công việc lịch sử hoặc một cuộc di trú có kiểm soát.
• Sync liên kết một dự án Jira với một Space trong Sharkly và giữ cho các thay đổi gần đây luôn được kết nối. Bản thân Sync không nhập dữ liệu lịch sử.
• Import rồi sync đưa phần lịch sử được chọn sang và có thể bật đồng bộ liên tục bằng thông tin xác thực đã nhập sẵn trong wizard.

Một liên kết đồng bộ ghép một dự án Jira với một Space trong Sharkly. Mỗi dự án Jira chỉ có thể có một liên kết đang hoạt động, tuy nhiên nhiều dự án Jira có thể cùng liên kết tới một Space. Ở chế độ hai chiều, các issue và epic trên Jira đồng bộ với Task và Project trong Sharkly theo cả hai hướng, và các Task, Project mới trong Space được liên kết có thể tạo ra issue và epic trên Jira. Nếu bạn muốn giữ Jira là nguồn thông tin gốc, chế độ Jira to Sharkly sẽ tạo và cập nhật các bản ghi Sharkly được liên kết mà không đẩy bản ghi mới trở lại.

Hai lưu ý vận hành nên biết trước khi bắt đầu. Việc cài đặt webhook tự động cần quyền quản trị Jira; nếu thiếu quyền tạo webhook thì kết nối vẫn không bị chặn, nhưng các thay đổi từ Jira sẽ không đến được. Xoá một liên kết sẽ dừng đồng bộ về sau mà không xoá bất cứ thứ gì ở cả hai bên, nhờ đó bạn có thể đảo ngược quyết định nếu thấy không phù hợp.

Về quy trình ở cấp độ ticket, bài hướng dẫn của chúng tôi về giao một ticket Jira cho AI agent sẽ đi hết vòng lặp từ đầu đến cuối.

Một ví dụ cụ thể

Một nhóm thanh toán dùng Jira như chuẩn chung của công ty. Bộ phận hỗ trợ tạo JIRA-4821: một cơn bão retry webhook đang tính tiền hai lần cho một số ít khách hàng.

Tech lead phân loại ticket trong Jira, đặt mức ưu tiên và liên kết nó với epic sự cố. Vì Space được liên kết đồng bộ hai chiều, công việc đó xuất hiện trong Sharkly dưới dạng một Task với phần mô tả và tiêu chí chấp nhận còn nguyên vẹn.

Tới đây thì việc định tuyến trở nên cụ thể. Task được giao cho một Agent đã được cấu hình cho việc sửa backend: vai trò được định nghĩa rõ ràng, repository thanh toán, và Claude Code làm Runtime, chạy trên một Computer đã kết nối và đã có sẵn thông tin xác thực staging cùng tuyến VPN. Một Agent thứ hai phụ trách độ phủ kiểm thử trong một worktree riêng biệt để cả hai không bao giờ đụng vào cùng một tệp. Bài hướng dẫn của chúng tôi về chạy các agent song song trong worktree riêng biệt giải thích vì sao sự tách biệt đó lại quan trọng khi có nhiều hơn một agent cùng làm việc.

Agent đọc issue, tái hiện cơn bão retry trên một bản replay local, đề xuất thay đổi idempotency key, chạy bộ test và báo cáo lại. Mọi thứ nó đã đọc, đã thử và đã thất bại đều nằm trên Task, trong phần dấu vết thực thi, ngay cạnh các bình luận. Tech lead xem xét diff, đặt thêm một câu hỏi trong bình luận của Task — câu hỏi này khởi động một lượt chạy mới — rồi chấp nhận kết quả.

Kết quả chảy ngược về JIRA-4821 cho những người chưa từng rời khỏi Jira: ticket được đóng, báo cáo sprint chính xác, và bộ phận hỗ trợ thấy được cách xử lý ngay trong công cụ họ vẫn dùng. Không ai phải chuyển đi đâu cả.

Sharkly vs Jira: so sánh công bằng

Những sai lầm thường gặp

Coi đây là một cuộc di trú. Sai lầm phổ biến nhất là biến việc thực thi agent thành lý do rời bỏ Jira. Bộ phận tài chính, hỗ trợ và ba nhóm khác đều đọc những báo cáo đó. Hãy đồng bộ, đừng đá nó ra ngoài.

Bỏ qua phần trao đổi về webhook. Liên kết Jira cần quyền quản trị viên để tự động cài đặt webhook. Nếu bạn không có quyền đó, hãy gửi gói cấu hình một lần cho quản trị viên Jira từ sớm, thay vì phải ngồi gỡ lỗi trong im lặng về sau.

Vô tình trỏ nhiều dự án Jira vào cùng một Space. Mỗi dự án Jira chỉ có thể có một liên kết Space đang hoạt động, và cặp ghép này không thể thay đổi sau khi tạo. Hãy quyết định ánh xạ trước khi tạo liên kết, vì sửa nó đồng nghĩa với việc xoá đi rồi tạo lại.

Giao những công việc chưa sẵn sàng cho agent. Một ticket chỉ ghi "sửa lỗi thanh toán" sẽ tạo ra một lượt chạy tồi, bất kể dùng nền tảng nào. Tiêu chí chấp nhận mới là thứ tạo nên khác biệt, và đó cũng chính là kỷ luật mà một ticket tử tế xưa nay vẫn cần. Bài tổng quan của chúng tôi về quản lý dự án với AI agent đề cập những gì thay đổi khi người được giao việc không phải là con người.

Kết luận

Jira trả lời câu hỏi "công việc nào đang tồn tại và ai sở hữu nó". Với Rovo Dev và các agent có thể giao việc, giờ đây nó cũng trả lời một phần câu hỏi "ai làm việc đó", trong phạm vi các môi trường mà Atlassian hỗ trợ. Nếu như thế là đủ cho stack của bạn thì bạn xong rồi, và bạn nên ngừng đọc các bài so sánh.

Sharkly trả lời một câu hỏi khác: quá trình thực thi agent diễn ra ở đâu khi nó cần đến máy của bạn, runtime của bạn và cổng kiểm duyệt của bạn, và làm sao để bản ghi đó vẫn dễ đọc với cả nhóm. Nó không thay thế Claude Code hay Codex, cũng không thay thế Jira. Nó bổ sung task dùng chung, Computer được kết nối, ngữ cảnh, khả năng kiểm soát và lớp kiểm duyệt quanh những công cụ nhóm bạn đã dùng, rồi đồng bộ kết quả trở lại ticket mà mọi người khác vẫn đọc.

Nếu đó chính là khoảng trống bạn đang cảm thấy, hãy bắt đầu với Sharkly và kết nối một dự án Jira với một Space trước khi động đến bất cứ thứ gì khác.

Câu hỏi thường gặp

Sharkly có thay thế Jira không? Không. Nó liên kết với Jira thông qua import, đồng bộ một chiều hoặc đồng bộ hai chiều. Xoá một liên kết sẽ dừng đồng bộ về sau mà không xoá issue, epic trên Jira hay Task, Project trong Sharkly.

Tôi có thể giữ Jira là nguồn thông tin gốc không? Có. Chiều Jira to Sharkly sẽ tạo hoặc cập nhật các bản ghi Sharkly được liên kết mà không tạo bản ghi Jira mới từ Sharkly. Những cập nhật được hỗ trợ trên các bản ghi đã liên kết vẫn có thể được ghi ngược trở lại.

Cách này có hoạt động với Jira tự host không? Cả Jira Cloud lẫn Jira Server hoặc Data Center đều được hỗ trợ. Bản cài Server và Data Center còn có thêm tuỳ chọn proxy mạng riêng mà Jira Cloud không hiển thị.

Còn chi phí model thì sao? Việc dùng model vẫn diễn ra qua các gói đăng ký hoặc API key đã cấu hình trong công cụ lập trình của bạn. Hạn mức model phụ thuộc vào các công cụ AI coding, gói dịch vụ và tài khoản API mà nhóm bạn kết nối.

Jira có thể giao việc gốc cho những agent nào? Agent Rovo cùng các agent bên thứ ba được hỗ trợ như GitHub Copilot coding agent, chọn từ danh sách người được giao việc của work item. Hãy kiểm tra tài liệu hiện hành của Atlassian, vì danh sách được hỗ trợ vẫn thay đổi.

Tôi có cần cả hai công cụ ngay từ đầu không? Không. Bạn có thể chạy Sharkly với các Space riêng của nó trước rồi kết nối Jira sau. Những nhóm vốn đã sống trong Jira thường thấy việc đồng bộ dễ được chấp thuận hơn khi một squad đã có vòng lặp agent hoạt động. Bài so sánh của chúng tôi về các lựa chọn thay thế Jira cho nhóm làm việc giữa người và agent đề cập trường hợp Jira chưa ăn sâu vào tổ chức.