Từ Tính năng đến Giá trị: Làm chủ Kỹ thuật Phân lát Trường hợp Sử dụng để Thành công trong Agile

Giới thiệu

Trong thế giới phát triển phần mềm đầy tốc độ, các phương pháp Agile đã trở thành tiêu chuẩn vàng để cung cấp các sản phẩm chất lượng cao đáp ứng nhu cầu ngày càng thay đổi của người dùng. Tuy nhiên, dù việc áp dụng các thực hành Agile đã trở nên phổ biến, nhiều đội vẫn tiếp tục gặp khó khăn với một thách thức cơ bản: làm thế nào để phân tách các yêu cầu phức tạp thành các công việc đủ nhỏ để hoàn thành trong một sprint và đủ ý nghĩa để mang lại giá trị thực sự cho người dùng.

Cách tiếp cận truyền thống phân tách tính năng thành các nhiệm vụ kỹ thuật hoặc màn hình giao diện người dùng thường dẫn đến những gì các chuyên gia gọi là “cắt dọc”—tạo ra các mục trong backlog chỉ đại diện cho các bước tiến tới giá trị chứ không phải là giá trị thực sự. Các đội phải xây dựng từng phần một, chỉ để phát hiện ra rằng người dùng không thể nhận được bất kỳ lợi ích nào cho đến khi tất cả các phần được lắp ráp lại. Mẫu hình tiêu cực này làm suy yếu chính lời hứa của Agile: cung cấp phần mềm hoạt động thường xuyên và liên tục mang lại giá trị.

Hãy cùng xem xétkỹ thuật phân lát trường hợp sử dụng, một khái niệm mang tính chuyển đổi từ Use-Case 2.0, cung cấp một cách tiếp cận hệ thống cho việc phân tách theo chiều ngang. Bằng cách cắt ngang qua các yêu cầu, thiết kế, triển khai và kiểm tra đồng thời, các đội có thể xác định các lát dọc mỏng của chức năng mang lại giá trị người dùng trọn vẹn trong từng giai đoạn tăng trưởng. Bài viết này khám phá lý thuyết và thực hành của kỹ thuật phân lát trường hợp sử dụng, chứng minh cách nó cầu nối khoảng cách giữa các mục tiêu người dùng cấp cao và công việc phát triển chi tiết trong khi vẫn duy trì nguyên tắc Agile về việc liên tục cung cấp giá trị.

Thông qua phân tích toàn diện, các ví dụ thực tế và hướng dẫn thực tiễn, chúng ta sẽ xem xét tại sao kỹ thuật phân lát trường hợp sử dụng đại diện cho một bước tiến hóa quan trọng trong lập kế hoạch Agile và các đội có thể tận dụng cách tiếp cận này để đạt được kết quả tốt hơn, giảm thiểu rủi ro và tối đa hóa tỷ suất lợi nhuận.

---

Bắt buộc phải Phân lát: Tại sao Điều này Quan trọng

Hầu hết các hệ thống đều yêu cầu công việc rộng lớn trước khi trở nên hữu dụng. Chúng có nhiều yêu cầu với mức độ quan trọng và ưu tiên khác nhau, và nhiều phụ thuộc tồn tại giữa chúng. Việc cố gắng xây dựng một hệ thống như vậy trong một lần là công thức dẫn đến thất bại. Hệ thống phải được xây dựng theo từng lát, mỗi lát mang lại giá trị rõ ràng cho người dùng.

Hình 1: Cách tiếp cận Cắt dọc Truyền thống so với Phân lát Ngang

Công thức rất đơn giản:

1. Xác định điều hữu ích nhất mà hệ thống phải làm

2. Phân lát nó thành các lát mỏng hơn, dễ quản lý

3. Xác định các trường hợp kiểm tra đại diện cho việc chấp nhận các lát đó

4. Chọn lát trung tâm nhất chạy xuyên suốt toàn bộ khái niệm

5. Ước lượng nó như một đội và bắt đầu xây dựng

Cách tiếp cận này cơ bản chuyển trọng tâm từ “chúng ta có thể xây dựng những tính năng gì?” sang “chúng ta có thể mang lại giá trị gì?”. Bằng cách đảm bảo mỗi lát mang lại lợi ích cụ thể, các đội duy trì sự tham gia của các bên liên quan, xác minh các giả định sớm và tạo ra nhịp độ cung cấp bền vững.

---

Phân lát Ngang so với Cắt dọc: Một Sự Phân biệt Quan trọng

Sự phân biệt giữa việc phân lát đúng cách và mẫu hình tiêu cực phổ biến là “cắt dọc” là yếu tố then chốt cho sự thành công của Agile.

Mẫu hình Tiêu cực: Cắt dọc

Khi các đội không sử dụng chiến lược phân lát trường hợp sử dụng, họ thường tạo ra các mục trong backlog sản phẩm bằng cách “cắt dọc” ứng dụng theo chiều dọc thành các “bước nhỏ tiến tới giá trị”. Điều này cảm thấy dễ dàng và tự nhiên vì:

• Chủ sở hữu sản phẩm có thể dễ dàng viết các câu chuyện người dùng nhỏ cho các bước này

• Nhà thiết kế giao diện người dùng biết cách thiết kế bản đồ màn hình cho từng bước

• Nhà phát triển và người kiểm thử có thể độc lập phát triển và kiểm tra các bước trường hợp sử dụng nhỏ này

Tuy nhiên, cách tiếp cận này tạo ra hai vấn đề nghiêm trọng:

• Người dùng không nhận được bất kỳ giá trị nàocho đến khi tất cả các bước cho toàn bộ trường hợp sử dụng đã được phát triển và kiểm tra

• Các nhà tài trợ nhận được tỷ suất lợi nhuận (ROI) tệ nhất có thể—đầu tư lớn ban đầu mà không có lợi nhuận nào cho đến tận cuối cùng

Điều này vi phạm quy tắc vàng của Agile: mỗi sprint phải tạo ra thứ có thể được phát hành.

Hình 2: Mẫu hình chống lại (Anti-Pattern) Cắt dọc – Các bước không mang lại giá trị
[Vị trí chèn hình ảnh minh họa cách cắt dọc tạo ra chức năng chưa hoàn chỉnh, không mang lại giá trị cho người dùng cho đến khi được lắp ráp đầy đủ]

Cách tiếp cận đúng đắn: Cắt ngang

Việc cắt theo trường hợp sử dụng (use-case) đúng đắn là “ngang”—mỗi lát cắt đại diện cho một tương tác từ đầu đến cuối, cho phép một nhóm người dùng đạt được mục tiêu của họ. Cách tiếp cận này:

• Giao giá trị thực sự trong mỗi lần tăng trưởng

• Cho phép nhận phản hồi sớm từ người dùng thực tế

• Giảm rủi ro dự án bằng cách chứng minh giá trị sớm

• Mang lại tỷ suất lợi nhuận (ROI) tốt hơn cho các nhà tài trợ

 

Hình 3: Cắt ngang mang lại giá trị từ đầu đến cuối

Sự khác biệt về mặt trực quan là rất rõ rệt: trong khi cắt dọc tạo ra các thành phần kỹ thuật rời rạc, cắt ngang tạo ra trải nghiệm người dùng thống nhất và có thể tự đứng vững. Mỗi lát cắt kể một câu chuyện hoàn chỉnh từ góc nhìn của người dùng.

---

Cách thức cắt lát hoạt động trong thực tế

Bước 1: Xác định các trường hợp sử dụng

Bắt đầu bằng việc tạo một sơ đồ mô hình trường hợp sử dụng hiển thị:

• Ai là người dùng (các vai diễn)

• Những mục tiêu nào họ cần đạt được

• Phạm vi và mục đích của giải pháp

Ví dụ, trong hệ thống xin vay vốn sinh viên, trường hợp sử dụng chính sẽ là “Xin vay vốn sinh viên.”

Hình 4: Sơ đồ mô hình trường hợp sử dụng hiển thị các vai diễn và mục tiêu

Góc nhìn tổng thể này đảm bảo mọi người đều hiểu mục đích của hệ thống và giúp xác định trường hợp sử dụng nào mang lại giá trị quan trọng nhất. Nó đóng vai trò như một lộ trình để ưu tiên hóa và ngăn chặn các đội ngũ bị lạc vào chi tiết kỹ thuật trước khi hiểu rõ nhu cầu của người dùng.

Bước 2: Xác định các câu chuyện (stories)

Một trường hợp sử dụng bao gồm nhiều câu chuyện liên quan với mức độ quan trọng và ưu tiên khác nhau. Các câu chuyện đại diện cho các cách cụ thể để đạt được mục tiêu của trường hợp sử dụng—cả cách thành công và cách xử lý các vấn đề phát sinh dọc đường.

Đối với trường hợp sử dụng “Mượn sách” trong hệ thống thư viện, các câu chuyện có thể bao gồm:

• Mượn sách thành công (luồng cơ bản)

• Đã đạt giới hạn số lượng sách được mượn (luồng ngoại lệ)

• Người mượn nợ tiền phạt (luồng ngoại lệ)

 

Hình 5: Các câu chuyện trường hợp sử dụng ánh xạ các luồng cơ bản và luồng ngoại lệ
[Vị trí chèn hình ảnh hiển thị sơ đồ luồng hoặc bảng ánh xạ các đường dẫn câu chuyện khác nhau trong một trường hợp sử dụng duy nhất, làm nổi bật kịch bản thành công chính và các đường dẫn thay thế/ngoại lệ]

Việc xác định các câu chuyện này đòi hỏi sự hợp tác giữa chủ sở hữu sản phẩm, nhà phát triển, người kiểm thử và các chuyên gia trong lĩnh vực. Mục tiêu là nắm bắt không chỉ con đường thành công mà còn cả các kịch bản thực tế mà người dùng sẽ gặp phải, bao gồm các điều kiện lỗi và các trường hợp biên.

Bước 3: Tạo các lát cắt

Một lát cắt trường hợp sử dụng là một hoặc nhiều câu chuyện được chọn từ một trường hợp sử dụng để tạo thành một công việc có giá trị rõ ràng cho khách hàng. Việc tạo lát cắt nên được thực hiện hợp tác với các bên liên quan để đảm bảo mỗi lát cắt đều mang lại giá trị.

Từ trường hợp sử dụng “Mượn sách”, các lát cắt có thể là:

Trường hợp sử dụng	Các câu chuyện trường hợp sử dụng	Lát cắt trường hợp sử dụng
Mượn sách	Mượn sách (Cơ bản)	Mượn sách thành công
Mượn sách	Đã đạt giới hạn số lượng bản ghi mượn	Mượn sách thất bại
Mượn sách	Người mượn nợ tiền phạt	Mượn sách thất bại

Mỗi lát cắt đóng vai trò là điểm giữ chỗ cho tất cả công việc cần thiết—yêu cầu, thiết kế, triển khai và kiểm thử—để hoàn thành các câu chuyện đã chọn.

Hình 6: Ma trận chọn lát cắt trường hợp sử dụng

Điểm mấu chốt ở đây là một lát cắt không cần phải bao gồm tất cả các câu chuyện từ một trường hợp sử dụng. Thay vào đó, nó nên bao gồm đủ các câu chuyện để mang lại một trải nghiệm mạch lạc và có giá trị. Đôi khi, một câu chuyện đơn lẻ đã tạo thành một lát cắt hoàn chỉnh; vào những lúc khác, nhiều câu chuyện phải được kết hợp lại để tạo ra giá trị.

Bước 4: Phân công cho các Sprint

Các lát cắt có thể được điều chỉnh kích thước để phù hợp với một Sprint hoặc một cột Kanban. Một lát cắt có thể chứa một câu chuyện hoặc nhiều câu chuyện—cơ chế tạo lát cắt đủ linh hoạt để tạo ra các lát cắt lớn hoặc nhỏ tùy theo nhu cầu nhằm thúc đẩy quá trình phát triển.

Hình 7: Lập kế hoạch Sprint với các lát cắt trường hợp sử dụng

Sự linh hoạt này cho phép các đội thích ứng với tốc độ và năng lực của mình trong khi vẫn duy trì nguyên tắc rằng mỗi lần tăng trưởng đều mang lại giá trị. Các đội có thể điều chỉnh độ chi tiết của lát cắt dựa trên mức độ phức tạp, rủi ro và ưu tiên của các bên liên quan.

---

Ví dụ thực tế

Nền tảng Thương mại điện tử: Thanh toán cho khách không đăng ký

Trong phương pháp lát cắt trường hợp sử dụng, tính năng “Thanh toán cho khách không đăng ký” có thể được chia thành các lát cắt như sau:

Trường hợp sử dụng: Thanh toán

• Lát cắt 1: Khách thêm sản phẩm vào giỏ hàng và hoàn tất giao dịch (luồng cơ bản)

  • Giá trị: Khách có thể mua hàng mà không cần tạo tài khoản

  • Kiểm thử: Khách hoàn tất thanh toán và nhận được xác nhận

• Lát cắt 2: Khách áp dụng mã giảm giá trong quá trình thanh toán (phương án thay thế)

  • Giá trị: Chức năng giảm giá

  • Kiểm thử: Mã giảm giá được áp dụng cho tổng tiền giỏ hàng

• Lát cắt 3: Khách nhận được xác nhận qua email (phương án thay thế)

  • Giá trị: Khả năng xem đơn hàng của khách

  • Kiểm thử: Email xác nhận được gửi với thông tin chính xác

Hình 8: Chiến lược lát cắt quy trình thanh toán cho khách hàng trong thương mại điện tử

Hãy nhận thấy cách mỗi lát cắt mang lại giá trị độc lập. Sau Lát cắt 1, khách hàng thực sự có thể mua hàng. Sau Lát cắt 2, họ có thể tiết kiệm tiền. Sau Lát cắt 3, họ có hồ sơ đơn hàng. Mỗi bước tăng cường đều cải thiện trải nghiệm mà không yêu cầu các lát cắt tiếp theo phải hoạt động.

Ứng dụng ngân hàng di động: Chuyển tiền

Trường hợp sử dụng: Chuyển tiền

• Lát cắt 1: Chuyển tiền cơ bản giữa các tài khoản của chính mình

  • Giá trị: Người dùng di chuyển tiền nội bộ

  • Kiểm thử: Giao dịch chuyển tiền xuất hiện trong số dư của cả hai tài khoản

• Lát cắt 2: Chuyển tiền cho khách hàng khác (phương án thay thế)

  • Giá trị: Người dùng gửi tiền ra bên ngoài

  • Kiểm thử: Người nhận nhận được tiền

• Lát cắt 3: Xử lý khi số dư không đủ (ngoại lệ)

  • Giá trị: Xử lý lỗi một cách tinh tế

  • Kiểm thử: Thông báo lỗi xuất hiện; không có tiền nào được chuyển đi

Hình 9: Các lát cắt chuyển tiền trong ngân hàng di động với sự tiến triển về giá trị

Ví dụ này minh họa cách xử lý ngoại lệ có thể trở thành một lát cắt có giá trị riêng. Mặc dù việc ưu tiên các kịch bản lỗi có vẻ phản trực giác, nhưng sự thất bại một cách tinh tế lại rất quan trọng đối với niềm tin và sự hài lòng của người dùng. Người dùng gặp phải các thông báo lỗi rõ ràng và hữu ích sẽ có trải nghiệm tốt hơn so với những người phải đối mặt với các lỗi hệ thống gây nhầm lẫn.

---

Tác động đến việc quản lý danh sách công việc

Khi được sử dụng cùng với Scrum, các lát cắt trường hợp sử dụng sẽ trở thành các mục ứng viên trong danh sách công việc sản phẩm. Điều này mang lại nhiều lợi ích:

Bối cảnh giá trị rõ ràng

Mô hình trường hợp sử dụng cung cấp một “dấu hiệu lớn, dễ nhận thấy” về mục đích của giải pháp, thể hiện:

• Ai là người dùng

• Những mục tiêu nào họ cần đạt được

• Bối cảnh giá trị của từng mục trong hàng đợi công việc

Điều này cho phép ưu tiên hóa một cách khách quan: “Tập trung trước tiên vào các trường hợp sử dụng quan trọng nhất giúp tinh chỉnh phần ‘đầu của hàng đợi công việc’ để sẵn sàng triển khai trước.”

Hình 10: Hàng đợi công việc sản phẩm đã được ưu tiên, được tổ chức theo các lát cắt trường hợp sử dụng

Không có bối cảnh này, các mục trong hàng đợi công việc xuất hiện như những tính năng biệt lập cạnh tranh sự chú ý. Với việc lát cắt theo trường hợp sử dụng, mối quan hệ giữa các mục trở nên rõ ràng, và các quyết định ưu tiên được căn chỉnh với các mục tiêu chiến lược của người dùng thay vì sự thuận tiện về mặt chiến thuật.

Kiểm tra và phát hành độc lập

Mỗi lát cắt có thể được phát triển và kiểm tra một cách độc lập. Điều này hỗ trợ phát triển dựa trên kiểm tra chấp nhận, nơi các trường hợp kiểm thử giúp định nghĩa và xác thực từng lát cắt.

Hình 11: Các trường hợp kiểm thử chấp nhận được căn chỉnh với các lát cắt trường hợp sử dụng

Sự căn chỉnh này đảm bảo rằng việc kiểm tra tập trung vào giá trị người dùng thay vì chỉ đúng về mặt kỹ thuật. Khi một lát cắt vượt qua các bài kiểm thử chấp nhận, các bên liên quan có thể tự tin nói rằng nó mang lại giá trị dự định.

Tinh chỉnh đúng thời điểm

Các nhóm có thể chia các mục trong hàng đợi công việc sản phẩm thành các lát cắt mỏng hơn khi cần, với mỗi lát cắt vẫn mang lại giá trị mới cho người dùng cuối. Hướng dẫn rõ ràng là: “Đừng lát cắt tất cả các trường hợp sử dụng cùng một lúc. Chỉ cần xác định đủ các lát cắt để đáp ứng nhu cầu trước mắt của nhóm.”

Hình 12: Quy trình tinh chỉnh đúng thời điểm cho các lát cắt trường hợp sử dụng

Phương pháp này ngăn ngừa lãng phí do lập kế hoạch quá mức trong khi đảm bảo nhóm luôn có công việc được định nghĩa rõ ràng và có giá trị sẵn sàng. Nó thể hiện nguyên tắc Agile về việc phản ứng với sự thay đổi thay vì tuân theo kế hoạch.

---

Lát cắt trong kỷ nguyên AI

Cần lưu ý rằng mặc dù việc lát cắt được thiết kế cho phát triển thủ công, nơi các nhà phát triển con người cần các mục công việc nhỏ và dễ quản lý, thì phát triển hỗ trợ AI đã thay đổi phương trình này. Khi AI tạo ra phần thực hiện, các nhóm có thể làm việc với toàn bộ trường hợp sử dụng cùng một lúc thay vì yêu cầu các lát cắt.

Tuy nhiên, khái niệm lát cắt vẫn có giá trị cho:

• Lập kế hoạch và ước lượng: Hiểu rõ phạm vi công việc

• Ưu tiên hóa: Xác định những gì mang lại giá trị cao nhất trước tiên

• Quản lý rủi ro: Cung cấp các chức năng quan trọng nhất sớm

• Giao tiếp với các bên liên quan: Thể hiện tiến độ bằng các thuật ngữ giá trị cụ thể

Hình 13: Lát cắt trường hợp sử dụng trong quy trình phát triển hỗ trợ AI

Ngay cả với sự tăng tốc của AI, thách thức cơ bản về việc quyết định xây dựng cái gì trước tiên vẫn còn đó. Lát cắt cung cấp một khung để đưa ra các quyết định này dựa trên giá trị thay vì sự thuận tiện về mặt kỹ thuật. Hơn nữa, các bên liên quan vẫn cần thấy tiến bộ tăng dần, và các lát cắt cung cấp các đơn vị minh chứng và phản hồi giúp dự án luôn căn chỉnh với nhu cầu của người dùng.

---

Nghiên cứu điển hình: Chuyển đổi quá trình di chuyển hệ thống kế thừa

Để minh họa sức mạnh của việc lát cắt trường hợp sử dụng trong thực tế, hãy xem xét một công ty dịch vụ tài chính đang di chuyển từ hệ thống xử lý khoản vay kế thừa sang một nền tảng đám mây hiện đại.

Thách thức

Hệ thống cũ xử lý hàng trăm loại khoản vay với các quy tắc kinh doanh phức tạp được tích lũy trong suốt 20 năm. Dự án di chuyển bao gồm:

• Di chuyển hơn 50.000 khoản vay đang hoạt động

• Triển khai các yêu cầu tuân thủ quy định mới

• Hiện đại hóa giao diện người dùng dành cho nhân viên cho vay

• Tích hợp với các API chấm điểm tín dụng mới

Các nỗ lực ban đầu trong việc di chuyển đã theo đuổi một cách tiếp cận dọc truyền thống: di chuyển sơ đồ cơ sở dữ liệu trước, sau đó là lớp logic kinh doanh, rồi đến giao diện người dùng. Sau sáu tháng và một khoản đầu tư đáng kể, nhóm đã di chuyển cơ sở hạ tầng nhưng không thể xử lý một khoản vay nào từ đầu đến cuối. Các bên liên quan trở nên lo lắng và dự án đối mặt với nguy cơ bị hủy bỏ.

Giải pháp cắt lát

Trưởng nhóm mới đã giới thiệu phương pháp cắt lát theo trường hợp sử dụng, bắt đầu bằng một hội thảo mô hình hóa trường hợp sử dụng có sự tham gia của nhân viên cho vay, chuyên gia tuân thủ và nhà phát triển. Họ đã xác định được năm trường hợp sử dụng cốt lõi:

1. Xử lý đơn xin vay mới

2. Xem xét và phê duyệt khoản vay

3. Dịch vụ cho khoản vay hiện có (thanh toán, điều chỉnh)

4. Tạo báo cáo tuân thủ quy định

5. Xử lý khoản vay bị vỡ nợ

Thay vì cố gắng di chuyển mọi thứ, họ đã chọn “Xử lý đơn xin vay mới” làm trường hợp sử dụng có giá trị cao nhất và bắt đầu cắt lát nó theo chiều ngang.

Hình 14: Mô hình trường hợp sử dụng di chuyển hệ thống cũ

Định nghĩa và thực hiện cắt lát

Nhóm đã định nghĩa các lát cắt sau cho “Xử lý đơn xin vay mới”:

Lát cắt 1: Đơn xin vay cá nhân đơn giản

• Hỗ trợ các khoản vay cá nhân cơ bản với hồ sơ tài liệu tiêu chuẩn

• Tích hợp với một API của cơ quan tín dụng

• Quy trình phê duyệt thủ công

• Giá trị: Nhân viên cho vay có thể xử lý loại khoản vay phổ biến nhất (chiếm 60% khối lượng)

• Thời gian: 3 tuần

Lát cắt 2: Ra quyết định tự động cho các đơn xin vay rủi ro thấp

• Thêm phê duyệt tự động cho các đơn xin vay đáp ứng các tiêu chí đã định trước

• Tích hợp các nguồn dữ liệu bổ sung để đánh giá rủi ro

• Giá trị: Giảm thời gian xử lý từ vài ngày xuống còn vài phút cho 40% hồ sơ

• Thời lượng: 2 tuần

Phân đoạn 3: Các loại khoản vay phức tạp (Ô tô, Bất động sản)

• Mở rộng để hỗ trợ khoản vay ô tô và bất động sản với tài liệu chuyên biệt

• Thêm hỗ trợ cho người đồng nộp hồ sơ

• Giá trị: Phủ 40% còn lại của khối lượng hồ sơ

• Thời lượng: 4 tuần

Phân đoạn 4: Xử lý ngoại lệ và các trường hợp biên

• Xử lý hồ sơ chưa hoàn chỉnh, thiếu tài liệu, và các tình huống đặc biệt

• Thêm quy trình chuyển cấp

• Giá trị: Hệ thống vững chắc xử lý được độ phức tạp trong thực tế

• Thời lượng: 3 tuần

 

Hình 15: Lộ trình phân đoạn hồ sơ vay vốn với thời gian giao giá trị

Kết quả và bài học rút ra

Sau khi hoàn thành Phân đoạn 1, nhóm đã trình diễn một hệ thống hoạt động xử lý các hồ sơ vay vốn thực tế. Các nhân viên cho vay đã cung cấp phản hồi ngay lập tức về các vấn đề về khả năng sử dụng, những vấn đề này đã được giải quyết trong các phân đoạn tiếp theo. Đến cuối Phân đoạn 2, hệ thống đã xử lý 40% hồ sơ mới với các quyết định tự động, tạo ra các lợi ích hiệu suất có thể đo lường được.

Các kết quả chính bao gồm:

• Giao giá trị sớm: Chức năng hoạt động có sẵn sau 3 tuần thay vì 6+ tháng

• Sự tin tưởng của các bên liên quan: Các buổi trình diễn định kỳ xây dựng niềm tin và đảm bảo nguồn tài trợ liên tục

• Giảm thiểu rủi ro: Các thách thức kỹ thuật được phát hiện sớm khi việc điều chỉnh lộ trình vẫn còn khả thi

• Việc người dùng chấp nhận: Nhân viên cho vay được đào tạo từng bước khi các khả năng mới được triển khai

• Hiện thực hóa ROI: Hiệu quả tăng bắt đầu tích lũy từ tuần thứ 4 trở đi

 

Hình 16: So sánh Trước và Sau – Phương pháp Di chuyển Dọc so với Phương pháp Di chuyển Theo lát cắt

Việc di chuyển hoàn tất thành công trong tổng cộng 14 tuần, với hệ thống hoạt động đầy đủ và hỗ trợ tất cả các loại khoản vay. Quan trọng hơn, tổ chức đã học được một phương pháp mới cho các dự án phức tạp mà họ đã áp dụng cho các sáng kiến tiếp theo.

---

Thực tiễn tốt nhất để triển khai việc lát cắt theo kịch bản sử dụng

Dựa trên các triển khai thành công và các nguyên tắc được nêu ở trên, dưới đây là những thực tiễn tốt nhất cho các đội ngũ áp dụng việc lát cắt theo kịch bản sử dụng:

1. Bắt đầu bằng mục tiêu của người dùng, không phải tính năng

Luôn bắt đầu bằng việc hiểu rõ người dùng đang cố gắng hoàn thành điều gì. Tính năng là phương tiện để đạt được mục đích; mục tiêu của người dùng chính là đích đến. Hãy tự hỏi: “Điều này giải quyết vấn đề gì?” và “Ai được hưởng lợi?”

2. Hợp tác xuyên suốt các lĩnh vực

Việc lát cắt đòi hỏi sự đóng góp từ chủ sở hữu sản phẩm, nhà phát triển, người kiểm thử, nhà thiết kế và các chuyên gia trong lĩnh vực. Không vai trò nào có thể có cái nhìn toàn diện về những gì tạo nên một lát cắt có giá trị.

Hình 17: Hợp tác liên chức năng trong các buổi hội thảo định nghĩa lát cắt

3. Xác thực từng lát cắt một cách độc lập

Đảm bảo mỗi lát cắt có thể được kiểm thử từ đầu đến cuối mà không phụ thuộc vào các lát cắt trong tương lai. Nếu một lát cắt cần chức năng chưa hoàn thiện để chứng minh giá trị, thì có lẽ nó quá mỏng hoặc được định nghĩa không chính xác.

4. Cân bằng kích thước lát cắt với giá trị mang lại

Các lát cắt nên đủ nhỏ để hoàn thành trong một sprint nhưng cũng đủ lớn để mang lại giá trị có ý nghĩa. Nếu một lát cắt cảm thấy tầm thường, hãy kết hợp nó với các câu chuyện liên quan. Nếu nó cảm thấy quá lớn, hãy tìm các điểm phân chia tự nhiên.

5. Duy trì khả năng truy vết

Giữ các liên kết rõ ràng giữa các lát cắt, các kịch bản sử dụng cha của chúng và các mục tiêu kinh doanh mà chúng phục vụ. Khả năng truy vết này hỗ trợ các quyết định ưu tiên và giúp các bên liên quan hiểu rõ lý do chiến lược đằng sau danh sách công việc.

Hình 18: Ma trận truy vết liên kết các lát cắt với các kịch bản sử dụng và các mục tiêu kinh doanh

6. Điều chỉnh độ chi tiết phù hợp với ngữ cảnh

Không phải tất cả các kịch bản sử dụng đều yêu cầu độ chi tiết lát cắt như nhau. Các kịch bản sử dụng có rủi ro cao và giá trị cao sẽ được hưởng lợi từ việc lát cắt chi tiết hơn để cho phép xác thực sớm. Các kịch bản sử dụng có mức độ ưu tiên thấp hơn có thể sử dụng các lát cắt thô hơn để giảm chi phí vận hành.

7. Truyền đạt tiến độ bằng ngôn ngữ về giá trị

Khi báo cáo tiến độ, hãy nhấn mạnh giá trị mà các lát cắt hoàn thành mang lại thay vì các cột mốc kỹ thuật đã đạt được. Hãy nói “Người dùng giờ đây có thể hoàn tất quy trình thanh toán dưới dạng khách” thay vì “Di chuyển cơ sở dữ liệu đã hoàn thành 60%.”

---

Những sai lầm phổ biến và cách tránh chúng

Ngay cả với ý định tốt, các đội ngũ vẫn có thể mắc bẫy khi triển khai việc lát cắt theo kịch bản sử dụng. Dưới đây là những sai lầm phổ biến và các chiến lược giảm thiểu:

Sai lầm 1: Lát cắt quá mỏng

Vấn đề: Tạo ra các lát cắt quá nhỏ đến mức mang lại giá trị không đáng kể, về cơ bản là tái tạo việc cắt dọc nhưng với thuật ngữ khác.

Giải pháp: Áp dụng bài kiểm tra “Liệu chúng ta có thể phát hành điều này không?”. Nếu một lát cắt sẽ không mang lại giá trị nếu được phát hành độc lập, thì có lẽ nó quá mỏng. Hãy kết hợp các câu chuyện liên quan cho đến khi bạn có được trải nghiệm người dùng mạch lạc.

Sai lầm 2: Bỏ qua các luồng ngoại lệ

Vấn đề: Chỉ tập trung vào các kịch bản thành công và trì hoãn việc xử lý ngoại lệ vô thời hạn, dẫn đến các hệ thống kém bền vững.

Giải pháp: Bao gồm các luồng ngoại lệ quan trọng trong các lát cắt ban đầu. Người dùng thường xuyên gặp lỗi, và việc xử lý một cách tinh tế là một phần của giá trị mang lại.

Cạm rẫy 3: Cắt nhỏ quá mức ngay từ đầu

Vấn đề: Cố gắng phân tích chi tiết tất cả các kịch sử dụng trước khi bắt đầu phát triển, dẫn đến tê liệt do phân tích.

Giải pháp: Tuân thủ nguyên tắc tinh chế đúng thời điểm. Chỉ cắt nhỏ những gì cần thiết cho vài sprint tới, cho phép việc học hỏi từ các lát cắt ban đầu định hướng cho các lát cắt sau.

Hình 19: Nhịp độ cắt nhỏ tối ưu – Tinh chế đúng thời điểm

Cạm rẫy 4: Mất đi tầm nhìn tổng thể

Vấn đề: Quá tập trung vào từng lát cắt riêng lẻ đến mức mô hình kịch sử dụng tổng thể và các mục tiêu chiến lược bị che khuất.

Giải pháp: Thường xuyên xem xét lại mô hình kịch sử dụng để đảm bảo các lát cắt phù hợp với các kịch sử dụng ưu tiên cao và mục tiêu kinh doanh. Giữ cho mô hình luôn hiển thị và được cập nhật.

Cạm rẫy 5: Coi các lát cắt là yêu cầu cố định

Vấn đề: Định nghĩa các lát cắt một cách cứng nhắc và chống lại việc thích ứng dựa trên phản hồi hoặc các tình huống thay đổi.

Giải pháp: Chấp nhận nguyên tắc Agile về phản ứng với sự thay đổi. Sẵn sàng định nghĩa lại, sắp xếp lại thứ tự ưu tiên hoặc thậm chí loại bỏ các lát cắt dựa trên thông tin mới.

---

Đo lường thành công với việc cắt nhỏ kịch sử dụng

Để đánh giá xem việc cắt nhỏ kịch sử dụng có mang lại lợi ích như kỳ vọng hay không, hãy theo dõi các chỉ số sau:

Chỉ số giao giá trị

• Thời gian đến giá trị đầu tiên: Mất bao lâu từ khi dự án bắt đầu cho đến khi người dùng nhận được lợi ích cụ thể?

• Giá trị trên mỗi sprint: Giá trị kinh doanh có thể định lượng được giao trong mỗi lần tăng trưởng

• Sự hài lòng của các bên liên quan: Phản hồi thường xuyên về việc các lát cắt được giao có đáp ứng được kỳ vọng hay không

Chỉ số chất lượng

• Tỷ lệ lỗi lọt ra ngoài: Số lượng lỗi được phát hiện sau khi phát hành so với trong quá trình phát triển

• Độ bao phủ kiểm thử: Tỷ lệ phần trăm các bài kiểm thử chấp nhận cho từng lát được tự động hóa và thành công

• Tỷ lệ công việc phải làm lại: Lượng công việc phải làm lại do hiểu sai yêu cầu

Các chỉ số hiệu suất

• Khả năng dự đoán: Độ chênh lệch giữa nỗ lực ước tính và nỗ lực thực tế cho các lát

• Hiệu suất dòng chảy: Tỷ lệ giữa thời gian làm việc chủ động và tổng thời gian chu kỳ

• Tần suất phát hành: Tần suất các bản tăng giá trị được đưa vào môi trường sản xuất

Hình 20: Bảng điều khiển các chỉ số chính cho sự thành công của việc lát theo kịch bản sử dụng

Các chỉ số này nên định hướng cho việc cải tiến liên tục phương pháp lát. Nếu thời gian để đạt được giá trị đầu tiên vẫn cao, các lát có thể quá lớn. Nếu tỷ lệ lỗi tăng lên, các lát có thể thiếu kiểm thử đầy đủ. Các buổi tổng kết định kỳ nên xem xét các chỉ số này và điều chỉnh các thực hành tương ứng.

---

Kết luận

Việc lát theo kịch bản sử dụng đại diện cho một sự thay đổi cơ bản trong cách các nhóm Agile tiếp cận việc phân rã yêu cầu và giao giá trị. Bằng cách chuyển từ việc cắt dọc—nơi các mục công việc đại diện cho các bước kỹ thuật mà không có giá trị độc lập—sang lát ngang—nơi mỗi bản tăng cung cấp chức năng người dùng trọn vẹn—các nhóm đã mở khóa tiềm năng thực sự của các phương pháp Agile.

Bằng chứng là thuyết phục: các tổ chức áp dụng việc lát theo kịch bản sử dụng trải nghiệm thời gian ra thị trường nhanh hơn, sự hài lòng của các bên liên quan cao hơn, rủi ro dự án giảm và tỷ suất lợi nhuận đầu tư tốt hơn. Phương pháp này buộc phải có kỷ luật trong tư duy về giá trị, khuyến khích sự hợp tác liên ngành và tạo ra sự hiểu biết chung về những gì quan trọng nhất đối với người dùng.

Hình 21: Hành trình từ phát triển tập trung vào tính năng sang phát triển tập trung vào giá trị

Như chúng ta đã thấy qua giải thích lý thuyết, các ví dụ thực tế và một nghiên cứu trường hợp chi tiết, việc lát theo kịch bản sử dụng không chỉ là một kỹ thuật mà là một tư duy. Nó đòi hỏi các nhóm phải liên tục đặt câu hỏi: “Chúng ta đang giao giá trị gì?” thay vì “Chúng ta đang xây dựng tính năng gì?” Câu hỏi này, dù có vẻ đơn giản, đã biến đổi cách công việc được hình thành, lập kế hoạch, thực hiện và đánh giá.

Nhìn về tương lai, các nguyên tắc của việc lát theo kịch bản sử dụng vẫn còn phù hợp ngay cả khi các thực hành phát triển thay đổi. Trong kỷ nguyên của lập trình hỗ trợ AI, nền tảng low-code và các công cụ tạo mẫu nhanh, thách thức trong việc quyết định xây dựng cái gì trước tiên—và đảm bảo nó mang lại giá trị—trở nên quan trọng hơn, chứ không phải ít đi. Việc lát cung cấp khung để đưa ra các quyết định này một cách có hệ thống thay vì tùy tiện.

Đối với các nhóm đang gặp khó khăn trong việc áp dụng Agile, đặc biệt là những nhóm nhận thấy các sprint chỉ tạo ra hoạt động chứ không tạo ra giá trị, việc lát theo kịch bản sử dụng cung cấp một con đường đã được chứng minh để tiến về phía trước. Nó lấp đầy khoảng cách giữa tầm nhìn chiến lược và thực thi chiến thuật, giữa nhu cầu của người dùng và việc triển khai kỹ thuật, giữa lập kế hoạch và giao hàng.

Hành trình bắt đầu với một câu hỏi duy nhất: “Điều gì có giá trị nhất mà người dùng của chúng ta cần, và lát mỏng nhất của điều đó mà chúng ta có thể giao ngay bây giờ là gì?” Trả lời câu hỏi đó một cách nhất quán, và bạn sẽ không chỉ biến đổi quy trình phát triển của mình, mà còn biến đổi khả năng tạo ra các sản phẩm thực sự phục vụ người dùng của mình.

Như Tuyên ngôn Agile nhắc nhở chúng ta, ưu tiên cao nhất của chúng ta là làm hài lòng khách hàng thông qua việc giao phần mềm có giá trị sớm và liên tục. Việc lát theo kịch bản sử dụng là cơ chế thực tiễn giúp hiện thực hóa khát vọng này. Nó biến lời hứa của Agile thành hiện thực của việc giao giá trị nhất quán, từng lát một.

---

Tài liệu tham khảo

1. Use-Case 2.0: Hướng dẫn thiết yếu cho việc phát triển phần mềm thành công: Hướng dẫn toàn diện giới thiệu việc lát theo kịch bản sử dụng như một khái niệm cốt lõi cho phát triển Agile, giải thích cách phân rã các kịch bản sử dụng thành các bản tăng giá trị cung cấp chức năng trọn vẹn.
2. Ước tính và lập kế hoạch Agile: Khám phá chi tiết các kỹ thuật lập kế hoạch Agile bao gồm phân tách câu chuyện, theo dõi tốc độ và lập kế hoạch phát hành bổ sung cho các phương pháp lát theo kịch bản sử dụng.
3. Lập bản đồ câu chuyện người dùng: Khám phá câu chuyện toàn diện, xây dựng sản phẩm đúng đắn: Hướng dẫn thực tế về việc trực quan hóa hành trình người dùng và phân tách chúng thành các lát có thể hành động, cung cấp các kỹ thuật bổ sung cho việc lát theo kịch bản sử dụng trong quản lý hàng đợi công việc.
4. Nghệ thuật Phát triển Agile: Nguồn tài liệu toàn diện về các thực hành Agile bao gồm phát triển lặp, phản hồi liên tục và ưu tiên dựa trên giá trị, phù hợp với các nguyên tắc cắt lát theo kịch bản sử dụng.
5. Mở rộng Phát triển Lean & Agile: Tư duy và Công cụ cho Các Dự án Quy mô Lớn: Những hiểu biết về việc áp dụng các nguyên tắc Agile và Lean ở quy mô lớn, bao gồm các chiến lược quản lý các yêu cầu phức tạp thông qua việc giao giá trị theo từng bước.
6. Phát triển Dựa trên Kiểm thử Chấp nhận: Giải thích các thực hành ATDD bổ sung cho việc cắt lát theo kịch bản sử dụng bằng cách đảm bảo mỗi lát được định nghĩa và xác thực thông qua các tiêu chí chấp nhận cụ thể.
7. Giao liên tục: Phát hành Phần mềm Đáng tin cậy thông qua Tự động hóa Xây dựng, Kiểm thử và Triển khai: Hướng dẫn thiết lập các quy trình triển khai cho phép phát hành thường xuyên các lát theo kịch bản sử dụng, hỗ trợ nguyên tắc Agile về giao giá trị liên tục.

---

1. Bài viết này là một phần của chuỗi bài viết khám phá việc tích hợp Use-Case 2.0 với các thực hành phát triển Agile.