Visual Paradigm Desktop | 
Visual Paradigm Online
Những người sở hữu sản phẩm thường phải đối mặt với một bối cảnh đầy thứ ngôn ngữ kỹ thuật và các mô hình trừu tượng. Trong số những tài liệu phổ biến nhất mà họ gặp phải là sơ đồ trường hợp sử dụng. Dù mạnh mẽ, công cụ này thường bị hiểu nhầm. Những hiểu lầm này có thể dẫn đến lãng phí thời gian, kỳ vọng không đồng bộ và xung đột giữa các đội kinh doanh và kỹ thuật. Hướng dẫn này loại bỏ sự nhầm lẫn để tiết lộ thực chất mà các sơ đồ này đại diện và cách tận dụng chúng một cách hiệu quả.
Hiểu rõ mục đích thực sự của những sơ đồ này là điều cần thiết đối với bất kỳ ai chịu trách nhiệm định hướng sản phẩm. Điều này không phải là vẽ những bức tranh đẹp mắt; mà là xác định rõ phạm vi và ranh giới. Hãy cùng khám phá thực chất đằng sau những ký hiệu.
Sơ đồ trường hợp sử dụng là một biểu diễn trực quan về các yêu cầu chức năng của một hệ thống. Nó mô tả cách người dùng (các tác nhân) tương tác với hệ thống để đạt được các mục tiêu cụ thể. Nó tập trung vào điều gì hệ thống làm, chứ không phải cáchnó làm điều đó như thế nào.
Các thành phần chính bao gồm:
Đối với người sở hữu sản phẩm, sơ đồ này đóng vai trò như một cầu nối giao tiếp. Nó chuyển đổi mục tiêu kinh doanh thành khả năng của hệ thống mà không bị mắc kẹt vào chi tiết triển khai.
Nhiều người cho rằng sơ đồ chỉ thuộc về đội kỹ thuật. Suy nghĩ này giới hạn sự tham gia của người sở hữu sản phẩm vào việc hiểu biết về kiến trúc.
Các nhà phát triển cần thông tin này để xây dựng, nhưng các bên liên quan cần nó để xác minh. Nếu người sở hữu sản phẩm không thể đọc sơ đồ trường hợp sử dụng, họ có thể phê duyệt các tính năng không khả thi về mặt kỹ thuật hoặc bỏ sót các phụ thuộc quan trọng.
Đừng giao việc xem xét sơ đồ này cho người quản lý dự án một mình. Hãy ngồi xuống cùng các kiến trúc sư. Đặt câu hỏi về các tác nhân. Đảm bảo ranh giới hệ thống phù hợp với tầm nhìn sản phẩm. Nếu một bên liên quan là một tác nhân, hệ thống có hỗ trợ quy trình làm việc cụ thể của họ hay không?
Có xu hướng coi sơ đồ là nguồn thông tin duy nhất đáng tin cậy. Một số người cho rằng nếu đã vẽ ra thì yêu cầu đã được xác định.
Một sơ đồ là bản đồ, chứ không phải vùng đất thực tế. Nó chỉ hiển thị bức tranh tổng thể ở cấp độ cao. Nó không mô tả các bước thực hiện bên trong một trường hợp sử dụng, xử lý lỗi hay các quy tắc xác thực dữ liệu.
Không có các thông số chi tiết, sơ đồ sẽ không đủ. Bạn cần:
Sử dụng sơ đồ để tổ chức danh sách công việc của bạn. Liên kết các câu chuyện người dùng với các trường hợp sử dụng cụ thể. Đảm bảo mỗi hình tròn trên sơ đồ đều có tiêu chí chấp nhận tương ứng. Đừng để cách viết tắt trực quan trở thành sự thay thế lười biếng cho sự rõ ràng.
Suy nghĩ sai lầm phổ biến nhất là mỗi hình người vẽ bằng nét đơn giản đều đại diện cho một con người. Điều này giới hạn việc hiểu rõ về tích hợp hệ thống.
Một tác nhân là bất kỳ thực thể bên ngoài nào tương tác với hệ thống. Điều này bao gồm:
Các công cụ thường mặc định sử dụng biểu tượng con người. Các đội quên chuyển sang biểu tượng hệ thống cho các API. Điều này dẫn đến đánh giá thấp độ phức tạp của việc tích hợp.
Nhãn rõ ràng cho các tác nhân của bạn. Nếu đó là một API bên ngoài, hãy ghi nhãn như vậy (ví dụ: “Nhà cung cấp thanh toán”). Điều này báo hiệu cho đội phát triển rằng họ cần quản lý giao diện, chứ không chỉ xây dựng các màn hình giao diện người dùng. Đảm bảo người sở hữu sản phẩm hiểu rõ chi phí duy trì các mối quan hệ bên ngoài này.
Một số đội tin rằng một sơ đồ dày đặc với hàng trăm đường nét chứng tỏ tính toàn diện. Họ hướng đến mức độ kết nối tối đa.
Độ phức tạp che giấu giá trị. Nếu một sơ đồ quá chật chội, nó sẽ trở nên khó đọc. Mục tiêu là sự rõ ràng, chứ không phải sự hoàn chỉnh cho mọi trường hợp đặc biệt.
Hướng đến một bản tổng quan trên một trang nếu có thể. Nếu sơ đồ vượt quá, hãy sử dụng phân rã hệ thống. Tạo một sơ đồ chính cho toàn bộ sản phẩm, sau đó là các sơ đồ chi tiết cho từng module cụ thể. Sự đơn giản là một đặc điểm của kỹ thuật yêu cầu tốt.
Có niềm tin rằng sơ đồ này định rõ lược đồ cơ sở dữ liệu, bố cục giao diện người dùng hoặc cấu trúc mã nguồn.
Sơ đồ trường hợp sử dụng mang tính hành vi. Chúng mô tả tương tác. Chúng không mô tả cấu trúc dữ liệu hay triển khai vật lý. Nhầm lẫn giữa hành vi và kiến trúc dẫn đến các thiết kế cứng nhắc, không thể thích nghi với thay đổi.
Đừng dùng sơ đồ này để lập kế hoạch hạ tầng kỹ thuật. Hãy dùng nó để lập kế hoạch giá trị cho người dùng. Giữ các quyết định kiến trúc riêng biệt. Đảm bảo đội kỹ thuật hiểu rằng sơ đồ này là một hợp đồng về chức năng, chứ không phải bản vẽ thiết kế cho triển khai.
| Nỗi tin sai lầm | Sự thật | Tác động đến Product Owner |
|---|---|---|
| Các tác nhân chỉ là con người | Các tác nhân bao gồm hệ thống và thời gian | Ước lượng chính xác nỗ lực tích hợp |
| Sơ đồ = Yêu cầu đầy đủ | Sơ đồ = Tổng quan cấp cao | Cần có bản đồ chi tiết các câu chuyện người dùng |
| Độ phức tạp = Giá trị | Rõ ràng = Giá trị | Tập trung vào đơn giản hóa phạm vi |
| Chỉ dành cho nhà phát triển | Công cụ giao tiếp cho tất cả | Tham gia tích cực vào các buổi đánh giá thiết kế |
| Xác định kiến trúc | Xác định hành vi | Tách biệt lập kế hoạch chức năng và kỹ thuật |
Ngay cả khi những hiểu lầm đã được làm rõ, các Product Owner thường vấp phải những chi tiết thực thi cụ thể. Việc nhận thức được những sai lầm này giúp duy trì nhịp độ tiến triển.
Khi ranh giới không rõ ràng, việc mở rộng phạm vi là điều tất yếu. Nếu một tính năng nằm ngay ngoài giới hạn, nó có thể bị coi là ngoài phạm vi. Nếu nằm ngay trong giới hạn, nó có thể bị thiết kế quá mức. Hãy xác định rõ ranh giới. Thảo luận về việc dữ liệu sẽ xử lý ra sao khi vượt qua ranh giới đó.
Không nên kết hợp ‘Đăng nhập’ với ‘Tính thuế’ trong cùng một sơ đồ nếu một cái là khả năng hệ thống và cái kia là quy trình kinh doanh. Giữ mức độ chi tiết nhất quán. Nếu ‘Tính thuế’ là một trường hợp sử dụng, hãy đảm bảo ‘Đăng nhập’ được xem xét với mức độ tương đương.
Các sơ đồ thường thể hiện luồng lý tưởng. Tuy nhiên, Product Owner cần đảm bảo rằng xử lý lỗi được xem xét. Sơ đồ có thể hiện điều gì xảy ra khi cổng thanh toán thất bại không? Nếu không, hãy thêm một trường hợp sử dụng cho ‘Xử lý lỗi’ hoặc đảm bảo mô tả bao gồm điều đó.
Một sơ đồ được tạo ra ở đầu dự án thường đã lỗi thời vào sprint tiếp theo. Khi sản phẩm phát triển, các tác nhân và trường hợp sử dụng thay đổi. Xem sơ đồ như một tài liệu sống. Cập nhật nó khi phạm vi thay đổi đáng kể.
Để khai thác tối đa giá trị từ tài liệu này, hãy áp dụng những cách tiếp cận có kỷ luật sau.
Không phải dự án nào cũng cần sơ đồ trường hợp sử dụng. Áp dụng một cách máy móc sẽ làm tăng chi phí.
Một trong những cách hiệu quả nhất để thu hẹp khoảng cách giữa sơ đồ và danh sách công việc là liên kết chúng trực tiếp.
Ví dụ:
Điều này đảm bảo rằng mô hình trực quan không phải là một sản phẩm tách biệt. Nó thúc đẩy công việc thực tế. Người sở hữu sản phẩm đóng vai trò như người phiên dịch giữa mô hình trực quan và các yêu cầu được viết ra.
Thành thạo sơ đồ trường hợp sử dụng ít liên quan đến kỹ năng vẽ hơn là kỹ năng tư duy. Nó đòi hỏi sự kỷ luật trong việc xác định ranh giới, sự khiêm tốn khi thừa nhận điều gì nằm ngoài phạm vi, và sự tự tin để truyền đạt các tương tác phức tạp một cách đơn giản.
Là một người sở hữu sản phẩm, mục tiêu của bạn là cung cấp giá trị. Những sơ đồ này là công cụ để bảo vệ giá trị đó khỏi sự lan rộng phạm vi và sự sai lệch. Hãy sử dụng chúng để làm rõ, chứ không phải làm phức tạp. Bằng cách hiểu được những hiểu lầm và tập trung vào thực tế, bạn có thể đảm bảo rằng đội của bạn xây dựng đúng những gì doanh nghiệp cần, mà không phải đối mặt với sự mơ hồ.
Giữ cho sơ đồ của bạn sạch sẽ, các tác nhân được đánh dấu rõ ràng, và tập trung vào mục tiêu của người dùng. Đó chính là con đường dẫn đến kỹ thuật yêu cầu hiệu quả.