Scrum là một khung làm việc khá phổ biến hiện nay. Nó có thể đáp ứng và linh hoạt thay đổi với tình hình chuyển biến của nhu cầu kinh doanh. Từ đó các câu chuyện người dùng – còn gọi là User Story – được tạo ra nhằm đáp ứng những yêu cầu mới. Vậy có những gì cần lưu ý và hiểu nhầm khi viết một câu chuyện người dùng .
Làm Scrum là phải viết User Story
Có một điều phổ biến là các nhóm Scrum hay rất thường sử dụng từ User Story để chỉ những yêu cầu người dùng. Nhưng làm Scrum không có nghĩa là phải viết User Story.
- Scrum Guide không hề nhắc gì đến việc dùng User Story để miêu tả yêu cầu người dùng.
- User Story là một cách diễn đạt mong muốn của người dùng, không phải bản đặc tả yêu cầu.
- User Story nếu không xài ta vẫn có thể Scrum/Agile, vì bản chất nó cũng chỉ là một hình thức diễn đạt.
Chỉ Product Owner mới có quyền viết User Story
Theo Scrum thì Product Backlog sẽ là nơi để chứa tất cả các yêu cầu của người dùng cho Scrum Team. Cụ thể nó là kết quả của việc Product Owner làm việc với các bên liên quan bao gồm cả người dùng, và đưa vào Product Backlog thành dạng các items.
Thực tế yêu cầu có thể xuất phát từ những người trực tiếp sửa dụng sản phẩm phản ánh cho Product Owner. Tuy nhiên, trong quá trình làm Scrum team vẫn có những đề xuất và phát kiến riêng dựa trên hiểu biết và kinh nghiệm của họ trên sản phẩm. Nên việc tạo ra User Story có thể xuất phát từ Scrum Team.
Vậy có thể nói, ai cũng có quyền tạo User Story và đặt nó vào trong Product Backlog, còn việc sắp xếp nó, ưu tiên cho nó và đánh giá xem giá trị của nó với người dùng vẫn là do Product Owner quyết định.
Khi viết theo User Story là có được yêu cầu đầy đủ
As a < type of user >, I want < some goal > so that < some reason >
Cách viết trên là một công thức để có thể diễn đạt ý muốn của người dùng.
- As a <type of user> : Xác định loại người dùng
- I want <some goal>: mục tiêu đem đến là gì
- so that < some reason> : lý do và giá trị đem lại cho người dùng.
Vì thế nếu hiểu đúng sẽ diễn đạt đúng mà không cần theo công thức như trên. Vì những nhầm tưởng nên việc viết User Story trở thành việc :
- Viết cho có lệ và theo hình thức, vì đã Scrum thì phải viết User Story
- Lúc nào cũng as an user mà không biết user là ai, giám đốc, nhà tuyển dụng, quản lý, hay là một chức vụ nào cụ thể .
- Đề ra mục thiếu mà thiếu lý do hoặc không hiểu lý do – reason – nên lúc nào cũng thiếu vế này, chỉ viết và nêu ra yêu cầu của người dùng. Scrum Team sẽ không hiểu tại sao họ lại cần và mang lại giá trị gì, đôi khi nó không đem lại giá trị gì lớn và Product Owner chỉ đơn thuần là làm những gì người dùng bảo.
Cố gắng nhồi nhét vào User Story nhiều nhất có thể
Tâm lý khi viết yêu cầu sẽ sợ thiếu sót, nên đa phần người viết User Story sẽ ráng đưa hết tất cả các thứ vào trong User Story. Vì vậy User Story sẽ biến thành
- User Story trở thành tài liệu đặc tả yêu cầu và nặng về tính tài liệu. có những User Story được đính kèm cả một tập tin SRS (Software Requirement Specification ) và yêu cầu Software Engineer phải thỏa mãn hết toàn bộ. Kết quả là quay về hình thức truyền thống, giảm đi tính linh hoạt và nhanh nhẹn.
- Mọi thứ đưa vào làm cho User Story quá lớn : tính phức tạp cao, thời gian làm cao, độ rủi ro cũng cao theo.
- Việc sai sót sẽ bị thiếu vì Engineers thường khó mà đọc chi tiết hết mọi thứ trong một user story. Thay vì đó hãy tập trung vào những phần có thể xài được và có giá trị .
- Không đủ công sức để kiểm tra hết toàn bộ (testable)
- Cuối cùng là bạn đang cố gắng nhét quá nhiều nhân vào một chiếc bánh mì