Viết các truyện người dùng chất lượng cao không chỉ là một nhiệm vụ ghi chép tài liệu; đó là một hành động hợp tác nhằm định nghĩa rõ ràng. Khi các chủ sản phẩm, nhà thiết kế và nhà phát triển cùng nhau xây dựng các yêu cầu, sự rõ ràng thu được sẽ giảm thiểu sự mơ hồ và đẩy nhanh tiến độ giao hàng. Hướng dẫn này nêu ra một cách tiếp cận có cấu trúc để hỗ trợ các buổi làm việc viết truyện, giúp các đội phát triển tiếp cận gần hơn với giá trị mà họ đang xây dựng.
Quá thường xuyên, các yêu cầu đến dưới dạng các vé mơ hồ mà các nhà phát triển phải diễn giải. Khoảng cách diễn giải này dẫn đến công việc phải làm lại, trì hoãn và thất vọng. Bằng cách chuyển sang định dạng buổi làm việc hợp tác, các đội đảm bảo rằng các giới hạn kỹ thuật và nhu cầu người dùng được hiểu rõ ngay từ đầu. Mục tiêu là xây dựng một mô hình tư duy chung về công việc trước khi viết bất kỳ dòng mã nào.
Chuẩn bị cho buổi họp 📅
Thành công trong buổi làm việc bắt đầu trước khi giờ đầu tiên bắt đầu. Việc chuẩn bị đảm bảo rằng các thành viên tham gia được thống nhất và sẵn sàng đóng góp một cách có ý nghĩa. Vội vàng bước vào buổi họp mà không có bối cảnh thường dẫn đến những cuộc thảo luận hời hợt.
- Xác định mục tiêu: Bạn đang tinh chỉnh một Epic lớn thành các truyện nhỏ hơn sao? Bạn đang làm rõ các tiêu chí chấp nhận cho một tính năng phức tạp sao? Đặt ra một mục tiêu rõ ràng.
- Chọn người tham gia: Bạn cần có Chủ sản phẩm (hoặc đại diện) để xác định giá trị, các Nhà phát triển để ước lượng tính khả thi, và Kỹ sư kiểm thử để thách thức các trường hợp biên. Các nhà thiết kế nên tham gia nếu có liên quan đến giao diện người dùng.
- Chuẩn bị môi trường: Dù là trực tuyến hay trực tiếp, hãy đảm bảo không gian cho phép nhìn thấy rõ ràng. Mọi người đều phải nhìn thấy cùng một bảng hoặc màn hình. Tai nghe khử tiếng ồn hoặc một căn phòng yên tĩnh sẽ giúp tập trung hơn.
- Chuẩn bị danh sách công việc: Xác định trước các tính năng cấp cao. Đừng bắt đầu từ con số 0 trong buổi làm việc; hãy bắt đầu từ danh sách đã được ưu tiên.
Luồng buổi làm việc 🔄
Một chương trình có cấu trúc giúp nhóm tiến triển. Không có thời gian biểu, các cuộc thảo luận có thể đi lệch sang những phân tích kỹ thuật sâu khiến tiến độ bị đình trệ. Dưới đây là luồng được đề xuất cho một buổi họp tiêu chuẩn kéo dài hai giờ.
1. Thiết lập bối cảnh (15 phút)
Bắt đầu bằng việc xem xét lại “Tại sao”. Tại sao chúng ta đang xây dựng điều này? Ai là người dùng? Điều này giúp toàn đội thống nhất về giá trị kinh doanh. Nếu đội không hiểu vấn đề, họ sẽ không thể giải quyết nó một cách hiệu quả.
2. Soạn thảo truyện (30 phút)
Làm việc lần lượt từng mục trong danh sách công việc. Sử dụng định dạng truyện người dùng chuẩn. Đọc bản nháp đầu tiên thành tiếng. Mời các nhà phát triển đặt câu hỏi làm rõ ngay lập tức. Đừng chuyển sang mục tiếp theo cho đến khi truyện trở nên rõ ràng với những người sẽ xây dựng nó.
3. Tinh chỉnh và tiêu chí INVEST (30 phút)
Áp dụng các tiêu chí INVEST để đảm bảo chất lượng: Độc lập, Có thể thương lượng, Có giá trị, Có thể ước lượng, Nhỏ gọn và Kiểm thử được. Nếu một truyện quá lớn, hãy chia nhỏ nó. Nếu truyện phụ thuộc vào một truyện khác, hãy ghi chú mối phụ thuộc đó.
4. Tiêu chí chấp nhận (45 phút)
Đây là phần quan trọng nhất. Xác định rõ “Hoàn thành” trông như thế nào. Sử dụng các ví dụ cụ thể. Tránh dùng những từ mơ hồ như “nhanh” hay “thân thiện với người dùng”. Hãy rõ ràng về đầu vào và đầu ra.
Cấu trúc truyện người dùng 🧱
Một truyện được viết tốt tuân theo một mẫu cụ thể, cân bằng giữa sự ngắn gọn và rõ ràng. Mẫu chuẩn tập trung vào người dùng, hành động và lợi ích.
Định dạng:Là một [vai trò], tôi muốn [tính năng], để [lợi ích].
Mặc dù mẫu này phổ biến, nội dung quan trọng hơn cú pháp. Dưới đây là các ví dụ về cách tinh chỉnh một phát biểu mơ hồ thành một truyện hành động được.
- Mơ hồ: “Cải thiện quy trình đăng nhập.”
- Vấn đề:Không có người dùng, không có tính năng, không có lợi ích.
- Cụ thể:“Là mộtkhách hàng quay lại, tôi muốnđăng nhập bằng số điện thoại của tôi, đểtôi có thể truy cập tài khoản của mình nhanh chóng mà không cần nhớ mật khẩu.”
- Cải thiện:Vai trò được xác định, tính năng cụ thể, lợi ích rõ ràng.
Khi viết những câu chuyện này, hãy tránh dùng thuật ngữ kỹ thuật trong tiêu đề. Câu chuyện mô tả nhu cầu của người dùng, chứ không phải sơ đồ cơ sở dữ liệu. Chi tiết triển khai kỹ thuật nên nằm trong phần ghi chú hoặc phân tích nhiệm vụ, chứ không nằm trong chính câu chuyện người dùng.
Xác định tiêu chí chấp nhận ✅
Tiêu chí chấp nhận đóng vai trò như hợp đồng giữa đội ngũ và người sở hữu sản phẩm. Chúng xác định ranh giới của câu chuyện. Nếu các tiêu chí này không được đáp ứng, câu chuyện sẽ không hoàn thành.
Sử dụng bảng để theo dõi các tiêu chí này trong buổi làm việc để giữ cho chúng được tổ chức.
| Điều kiện | Kết quả mong đợi | Ưu tiên |
|---|---|---|
| Người dùng nhập địa chỉ email không hợp lệ | Hệ thống hiển thị thông báo lỗi ngay lập tức | Cao |
| Kết nối mạng bị mất | Hệ thống lưu nháp cục bộ và thử lại sau | Trung bình |
| Người dùng nhập thông tin xác thực hợp lệ | Chuyển hướng đến bảng điều khiển trong vòng 2 giây | Cao |
Các thực hành tốt nhất cho tiêu chí:
- Cụ thể: Thay vì nói “Nút bấm nên có màu xanh”, hãy dùng “Nút bấm phải khớp mã màu #00FF00.”
- Xem xét các trường hợp biên: Điều gì xảy ra khi cơ sở dữ liệu trống? Điều gì xảy ra nếu người dùng hủy thao tác?
- Sử dụng Câu/Thì/Thế nào: Cấu trúc này giúp các kỹ sư kiểm thử tự động viết các bài kiểm thử sau này. Nó tách biệt bối cảnh, hành động và kết quả.
- Giữ cho nó có thể kiểm thử được: Nếu bạn không thể viết một trường hợp kiểm thử cho nó, thì đó không phải là tiêu chí chấp nhận hợp lệ.
Quản lý động lực nhóm 🤝
Việc điều phối một buổi làm việc không chỉ đơn thuần là quản lý thời gian; nó còn liên quan đến việc quản lý con người. Những tính cách khác nhau mang đến những điểm mạnh và thách thức khác nhau trong phòng họp.
Xử lý các giọng nói chiếm ưu thế
Một số người tham gia có thể nói vượt lên trên người khác hoặc dẫn dắt cuộc thảo luận quá nhanh. Là người điều phối, bạn cần can thiệp một cách nhẹ nhàng. Hãy dùng những cụm từ như, “Đây là một điểm thú vị, chúng ta hãy ghi lại để hỏi trong phần Q&A, và hãy nghe ý kiến của [Tên] trước đã.” Điều này đảm bảo có sự đa dạng trong ý kiến mà không làm ai cảm thấy bị loại bỏ.
Khuyến khích những thành viên lặng lẽ
Các nhà phát triển thường thích suy nghĩ trước khi nói. Những câu hỏi trực tiếp sẽ giúp ích. Hãy hỏi: “Có ai có lo ngại về mặt kỹ thuật đối với cách tiếp cận này không?” hoặc “Điều gì có thể xảy ra sai với logic này?” Sự im lặng không phải là sự đồng thuận; thường nó có nghĩa là sự bối rối.
Giải quyết các tranh luận kỹ thuật
Dễ dàng bị mắc kẹt trong các tranh luận về kiến trúc trong buổi thảo luận câu chuyện. Nếu cuộc thảo luận chuyển từ “cái gì” sang “làm thế nào” và bị đình trệ, hãy công nhận tầm quan trọng nhưng tạm hoãn quyết định. Nói rằng: “Chúng ta sẽ ghi lại quyết định kiến trúc này và xem xét lại trong giai đoạn thiết kế thử nghiệm, nhưng hãy hoàn tất luồng người dùng trước đã.”
Vai trò và Trách nhiệm 🎭
Sự rõ ràng về ai làm gì sẽ ngăn ngừa sự nhầm lẫn trong buổi làm việc. Bảng sau đây nêu rõ những đóng góp mong đợi cho từng vai trò.
| Vai trò | Trách nhiệm chính | Câu hỏi then chốt cần đặt ra |
|---|---|---|
| Người điều phối | Giữ thời gian, quản lý luồng, đảm bảo sự tham gia | “Chúng ta có đang tiến triển theo chương trình không?” |
| Người sở hữu sản phẩm | Xác định giá trị, ưu tiên và quy tắc kinh doanh | “Tại sao tính năng này quan trọng đối với người dùng?” |
| Nhà phát triển | Đánh giá tính khả thi, ước lượng nỗ lực, xác định rủi ro | “Liệu điều này có thể thực hiện được về mặt kỹ thuật trong khung thời gian đã định không?” |
| Kỹ sư kiểm thử | Thử thách các trường hợp biên, xác định phạm vi kiểm thử | “Chúng ta sẽ kiểm chứng điều này hoạt động như thế nào?” |
Những sai lầm phổ biến cần tránh ⚠️
Ngay cả với những ý định tốt, các buổi làm việc nhóm vẫn có thể thất bại. Nhận diện những cái bẫy phổ biến này sẽ giúp bạn tránh được chúng.
- Quá ưu tiên sự hoàn hảo:Đừng dành ba giờ để hoàn thiện một câu chuyện. Mục tiêu là tiến triển. Bạn có thể tinh chỉnh sau này.
- Bỏ qua phần “Vì vậy là”:Nếu bạn bỏ qua lợi ích, các nhà phát triển có thể xây dựng sai thứ gì đó. Luôn đảm bảo lý do tại sao là rõ ràng.
- Bỏ qua nợ kỹ thuật:Nếu một câu chuyện yêu cầu tái cấu trúc đáng kể, hãy ghi chú lại. Đừng giấu công việc kỹ thuật bên trong một câu chuyện người dùng trừ khi nó hiển thị trực tiếp với người dùng.
- Thiếu theo dõi sau:Một buổi làm việc nhóm mà không có tài liệu chỉ là một cuộc họp. Đảm bảo các câu chuyện được cập nhật ngay lập tức vào hệ thống danh sách công việc sau buổi họp.
Đo lường hiệu quả 📊
Làm sao bạn biết buổi làm việc nhóm thành công? Hãy nhìn vào chất lượng đầu ra và cảm xúc của đội nhóm.
Chỉ số chất lượng:
- Các câu chuyện đủ rõ ràng để được đưa vào vòng lặp mà không cần thêm câu hỏi.
- Tiêu chí chấp nhận bao gồm cả các đường đi tích cực và tiêu cực.
- Các ước lượng do đội nhóm cung cấp là chính xác trong vòng lặp đầu tiên.
Tâm trạng của đội nhóm:
- Các nhà phát triển cảm thấy họ hiểu nhu cầu của người dùng.
- Người sở hữu sản phẩm cảm thấy các giới hạn kỹ thuật đã được hiểu rõ.
- Số lượng vé giải thích qua lại đã giảm.
Thực hiện một cuộc tổng kết ngắn sau vòng lặp đầu tiên. Hỏi đội nhóm xem quá trình viết câu chuyện có giúp họ làm việc nhanh hơn không. Nếu họ báo cáo ít rào cản hơn, phương pháp điều phối là hiệu quả.
Hành động sau buổi làm việc 🏁
Công việc không dừng lại khi buổi họp kết thúc. Theo dõi ngay lập tức sẽ củng cố sự đồng thuận.
- Cập nhật danh sách công việc:Đảm bảo tất cả các câu chuyện mới đều hiển thị trong công cụ theo dõi. Thêm liên kết đến bất kỳ tài liệu thiết kế hay ghi chú nào.
- Chia sẻ ghi chú:Gửi bản tóm tắt các quyết định đã đưa ra cho các bên liên quan không thể tham dự. Điều này giúp toàn bộ tổ chức đồng bộ.
- Xem xét các phụ thuộc: Nếu một câu chuyện phụ thuộc vào một nhóm khác, hãy tạo vé chuyển giao ngay lập tức. Đừng chờ đến chu kỳ lập kế hoạch tiếp theo.
Các Kỹ thuật Nâng cao cho Các Tính Năng Phức Tạp 🔍
Đôi khi một câu chuyện đơn lẻ là chưa đủ. Đối với các tính năng phức tạp, hãy cân nhắc những phương pháp hỗ trợ nâng cao này.
Sắp xếp theo Tính Tương đồng
Nếu bạn có danh sách dài các tính năng tiềm năng, hãy ghi chúng lên từng thẻ riêng biệt. Nhóm các mục tương tự lại với nhau. Điều này giúp xác định các cụm tự nhiên cho các Epic. Đây là cách trực quan để sắp xếp danh sách công việc trước khi đi sâu vào chi tiết.
Ba Người Bạn
Đối với các câu chuyện có rủi ro cao, hãy tập hợp Người sở hữu Sản phẩm, Nhà phát triển và Kỹ sư Kiểm thử Chất lượng trong một buổi họp riêng, ngắn hơn. Bộ ba này đảm bảo rằng giá trị, khả thi và chất lượng đều được kiểm tra trước khi toàn bộ nhóm thảo luận.
Thử nghiệm Mô hình
Nếu luồng người dùng phức tạp, hãy phác họa sơ bộ trên bảng trắng trong buổi làm việc. Một bản phác thảo thô tốt hơn một đoạn văn bản. Điều này cho phép mọi người chỉ vào và thảo luận về các tương tác cụ thể.
Danh Sách Kiểm Tra Cuối Cùng Cho Thành Công 📋
Trước khi kết thúc buổi làm việc, hãy kiểm tra danh sách này để đảm bảo không bỏ sót điều gì.
- ☐ Tất cả các câu chuyện đều có vai trò người dùng rõ ràng.
- ☐ Tất cả các câu chuyện đều có lợi ích rõ ràng.
- ☐ Tiêu chí chấp nhận được viết cho mỗi câu chuyện.
- ☐ Các phụ thuộc được xác định và theo dõi.
- ☐ Các câu chuyện được định kích thước phù hợp với vòng lặp.
- ☐ Các mốc kỹ thuật được tạo nếu cần thiết.
- ☐ Ghi chú được lưu lại và chia sẻ.
Việc điều phối các buổi làm việc viết câu chuyện đòi hỏi luyện tập. Đây là một kỹ năng được cải thiện qua từng buổi họp. Bằng cách tập trung vào sự rõ ràng, hợp tác và các định nghĩa cụ thể, các đội phát triển có thể chuyển từ sự bối rối sang sự tự tin. Kết quả là phần mềm đáp ứng nhu cầu người dùng và xây dựng niềm tin trong tổ chức.
