Làm thế nào để viết câu chuyện người dùng hiệu quả với các nguyên tắc INVEST?

Nguyên tắc INVEST để tạo ra các câu chuyện người dùng

Ngoài định dạng tiêu chuẩn và các yếu tố hoàn chỉnh, một câu chuyện người dùng cũng nên tuân theo các nguyên tắc INVEST : 1. Iđộc lập; 2. Nthương lượng; 3. Vcó giá trị; 4. Ecó thể ước lượng; 5. Snhỏ; 6. Tcó thể thiết lập.

1. Độc lập – Điều quan trọng là làm cho một câu chuyện người dùng càng độc lập càng tốt so với các câu chuyện người dùng khác. Duy trì tính độc lập giữa các câu chuyện người dùng không chỉ giúp dễ dàng ưu tiên và điều chỉnh, làm cho việc lập kế hoạch phát hành và lặp lại dễ dàng hơn, giúp hiểu biết độc lập, theo dõi, thực hiện, kiểm tra và giao hàng thường xuyên, mà còn làm cho phạm vi ước lượng kích thước câu chuyện người dùng rõ ràng hơn và do đó làm giảm thiên lệch ước lượng.

2. Thương lượng – Nội dung của một câu chuyện người dùng có thể thương lượng; một câu chuyện người dùng không phải là một hợp đồng. Một câu chuyện người dùng chỉ là một mô tả ngắn gọn về câu chuyện người dùng mà không có nhiều chi tiết; các chi tiết cụ thể được sản xuất trong giai đoạn giao tiếp. Một câu chuyện người dùng có quá nhiều chi tiết thực sự hạn chế người dùng, ý tưởng và giao tiếp của nhóm.

3. Có giá trị – Mỗi câu chuyện phải có giá trị đối với khách hàng (dù là người dùng, người mua, hay một vai trò nội bộ trong công ty). Các câu chuyện người dùng có giá trị đối với người dùng cuối, vì vậy chúng nên được viết từ góc nhìn của người dùng, mô tả một TÍNH NĂNG thay vì một NHIỆM VỤ.

Tính năng này tạo điều kiện cho việc chuyển đổi từ phong cách làm việc dựa trên chỉ đạo truyền thống sang phong cách làm việc tự chủ, định hướng giá trị cho các thành viên phát triển và kiểm thử trong nhóm, để mọi người trong nhóm đều biết giá trị của công việc họ làm mỗi ngày.

4. Có thể ước lượng (có thể được đánh giá) – Một phần rất quan trọng trong cuộc họp lập kế hoạch là ước lượng điểm câu chuyện. Thực tế, đây là một ước lượng thô về Câu chuyện người dùng sẽ được phát triển để nhóm có thể biết được độ phức tạp (khối lượng công việc) của câu chuyện người dùng này.

Trọng tâm là xem liệu câu chuyện người dùng có thể hoàn thành trong lần lặp hiện tại theo các điều kiện tiếp nhận của câu chuyện người dùng đó và DoD (tiêu chí hoàn thành) do nhóm xác định hay không, và nếu không thể hoàn thành, lý do sẽ được đưa ra và PO quyết định xem có nên chia nhỏ hoặc thiết kế lại câu chuyện người dùng hay không.

Các vấn đề khiến cho các nhà phát triển khó ước lượng câu chuyện đến từ: thiếu kiến thức về lĩnh vực (trong trường hợp này cần nhiều giao tiếp hơn), hoặc câu chuyện quá lớn (trong trường hợp này cần phải cắt thành các phần nhỏ hơn).

5.Nhỏ – Một câu chuyện tốt nên ngắn gọn nhất có thể về khối lượng công việc, tốt nhất là không quá 10 người lý tưởng/ngày, ít nhất để đảm bảo rằng nó được hoàn thành trong một lần lặp. Câu chuyện người dùng càng lớn, rủi ro trong việc lập lịch, ước lượng khối lượng công việc, v.v. càng cao.

6. Có thể kiểm tra (có thể kiểm tra) – Một câu chuyện người dùng nên có thể kiểm tra để xác nhận rằng nó có thể được hoàn thành. Nếu một câu chuyện người dùng không thể kiểm tra, thì bạn không thể biết khi nào nó sẽ được hoàn thành. Một ví dụ về một câu chuyện người dùng không thể kiểm tra: phần mềm nên dễ sử dụng.

Ba hướng dẫn

Một câu chuyện người dùng cơ bản là một câu chuyện người dùng tốt khi các nguyên tắc INVEST được tuân theo. Sau đó, chúng ta tập trung vào ba hướng dẫn để giúp tuân thủ tốt hơn các nguyên tắc khi sản xuất các câu chuyện người dùng.

Ba hướng dẫn là: một người dùng, giá trị hoàn chỉnh, và không có sự phụ thuộc.

Một loại người dùng – Chỉ bao gồm một loại người dùng, vì nhiều người dùng thường có những khác biệt. Thường thì đó là một người dùng điển hình, thường có một nhu cầu chung nào đó.

Giá trị hoàn chỉnh – Cung cấp giá trị cho khách hàng một cách toàn diện. Một câu chuyện người dùng hoàn chỉnh có nghĩa là khi câu chuyện này hoàn thành, người dùng có thể đạt được một mục tiêu rõ ràng và có ý nghĩa.

Không phụ thuộc – Ba loại phụ thuộc phổ biến là: chồng chéo, tuần tự và bao hàm.

Nói chung, các điểm chức năng chồng chéo giữa các câu chuyện cần được tránh; các mối quan hệ tuần tự là một thực tế và có thể được giải quyết bằng một số phương tiện trong hầu hết các trường hợp; và các mối quan hệ bao hàm là hữu ích cho các hệ thống phức tạp, với những tác động đến việc lập lịch phát hành và kế hoạch lặp cần được chú ý.

Phụ thuộc chồng chéo

Phụ thuộc chồng chéo là hình thức phụ thuộc gây ra nhiều rắc rối nhất, đặc biệt khi nhiều câu chuyện người dùng chứa nhiều phần chồng chéo khác nhau. Thật khó để tìm một tập hợp các câu chuyện người dùng có thể đại diện cho tập hợp các tính năng cho sản phẩm khả thi tối thiểu đó, mà nên chứa và chỉ chứa các tính năng cần thiết một lần.

Giải pháp

Tách các phần chồng chéo ra thành các câu chuyện người dùng riêng biệt.
Chia tách hợp lý các câu chuyện người dùng và giữ các phần chồng chéo chỉ trong một trong những câu chuyện người dùng gắn kết nhất.
Sử dụng mô hình phát triển Scrum.

Phụ thuộc tuần tự

Phụ thuộc tuần tự có nghĩa là để một câu chuyện người dùng được hoàn thành, một hoặc nhiều câu chuyện người dùng khác phải được hoàn thành trước đó. Phụ thuộc tuần tự thường không gây hại, và có những cách để giảm thiểu những phụ thuộc như vậy.

Từ góc độ phát triển linh hoạt, toàn bộ hệ thống tiến triển dần dần từ một sản phẩm khả thi tối thiểu ban đầu đến một sản phẩm vững chắc, với mỗi bước sau xây dựng dựa trên các bước trước đó.

Nhưng từ một góc độ khác, các phụ thuộc tuần tự không cần thiết làm cho việc xếp hạng và ưu tiên trở nên khó khăn hơn, điều này lại ảnh hưởng đến việc phát triển kế hoạch phát hành và lặp lại và làm cho việc ước lượng kích thước của các câu chuyện người dùng trở nên khó khăn hơn.

Giải pháp

Làm cho các câu chuyện người dùng trong một vòng lặp càng ít phụ thuộc nội tại càng tốt.
Giữ chỉ các phụ thuộc một chiều giữa các vòng lặp, với chỉ các phụ thuộc một chiều theo thời gian từ các câu chuyện trong các vòng lặp sau đến các câu chuyện trong các vòng lặp trước (phụ thuộc tiến về phía trước).
Tách các phụ thuộc cốt lõi ra thành các câu chuyện riêng biệt và không trộn lẫn các yêu cầu phụ thuộc và không phụ thuộc trong một câu chuyện.

Bao hàm các phụ thuộc

Các phụ thuộc bao hàm đề cập đến việc sử dụng quản lý phân cấp trong việc tổ chức các câu chuyện người dùng, chẳng hạn như quản lý tính năng-câu chuyện hai cấp phổ biến, nơi một tính năng chứa nhiều câu chuyện người dùng, do đó tạo thành một phụ thuộc bao hàm của tính năng đối với các câu chuyện cấp dưới của nó.

Giải pháp

Cấp độ câu chuyện người dùng được sử dụng cho việc lập kế hoạch lặp lại, tránh lập kế hoạch lặp lại thô với cấp độ tính năng, có thể được sử dụng cho việc lập kế hoạch phát hành.

Cấp độ tính năng cũng có thể được chia tách cho đến khi đạt đến cấp độ của một tính năng có thể tiếp thị tối thiểu, và các câu chuyện người dùng mà nó chứa có thể được nhóm riêng thành các tính năng mới được chia tách.

Theo khái niệm sản phẩm khả thi tối thiểu, một tính năng được thực hiện trong nhiều vòng lặp của nhiều câu chuyện người dùng, mỗi câu chuyện có thể dẫn đến một sản phẩm có thể giao hàng hoặc cung cấp phản hồi nội bộ hoặc bên ngoài.

 

Tài liệu tham khảo

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.

Leave a Reply

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *