User Story — Câu chuyện người dùng
User Story là gì ?
Là công cụ phát triển phần mềm trong Agile
Mục đích của US là gì ?
Hỗ trợ giao tiếp và tạo ra sự hiểu biết chung giữa các bộ phận trong team về một feature trong phần mềm từ quan điểm của người dùng cuối. ( share understanding )
Làm nổi bật lên các chức năng chính của sản phẩm rõ ràng, những gì người dùng cuối thực sự muốn, hơn là những idea mà bạn nghĩ rằng họ cần ( user-centric)
Tại sao tôi cần viết US
Giúp tổ chức và ngăn nắp , thay vì một mớ hỗn độn các tính năng. ( right software)
Giúp hiểu rõ được mục tiêu (goal) của người dùng và lý do tại sao họ lại muốn điều này. Do đó, chúng mở ra cơ hội cho nhóm phát triển sáng tạo trong việc tìm kiếm các giải pháp, không hạn chế về cách thức làm sao để đạt được mục tiêu này nhằm cung cấp thứ tốt nhất thỏa mãn mong muốn của người dùng, từ việc hiểu rõ lý do tại sao khách hàng mong muốn tính năng đó sẽ khiến cho developer dễ dàng phán đoán được mục đích cho công việc của họ. Nó giống như việc bạn bơi giữa đại dương và biết rõ hướng nào là bờ.
Giúp mở ra cơ hội cho một cuộc thảo luận để khám phá vấn đề (discovery , explore) và đây là giai đoạn phát huy tối đa sức sáng tạo.
Làm sao để biết được tôi cần những US nào ?
Cách tốt nhất là trao đổi, trò chuyện TRỰC TIẾP với khách hàng.
Cấu trúc như nào để viết được một US tốt
As a [type of user], I want to [perform some task] so that I can [achieve some goal].
Để có được một US tốt có 4 câu hỏi sau cần được trả lời
- WHO: sẽ là người sử dụng tính năng này: Cần xác định rõ tập khách hàng
- WHY: họ lại cần đến tính năng này hay nói cách khác mục tiêu/lợi ích sẽ nhận được khi dùng chức năng đó
- WHAT: cần được thực hiện để đạt được mục tiêu đó, liệt kê ra được các công việc (Task) cần làm.
- HOW: để hoàn thành được các task.
Feature mô tả một chức năng của chương trình, US mô tả cái gì đó bạn muốn làm. Trong một feature có thể có nhiều US góp phần vào việc cải tiến feature đó.
Bởi vậy US nên được viết làm sao có tính độc lập. Sau khi hoàn thành nó phải cung cấp cho người dùng một tính năng có thể dùng được và sau đó lấy phản hồi nhằm cải tiến liên tục. Đó là lý do vì sao trong agile người ta chia nhỏ các giai đoạn thành các iteration đóng vai trò như những thử nghiệm để ném đá dò đường nhằm tìm ra được điều khách hàng cảm thấy thỏa mãn. Chứ không phải mỗi một chu kỳ (như sprint trong scrum ) là hoàn thành một mảnh ghép cho một bức tranh tổng thể đã được định hình sẵn. Hãy quan sát bức tranh sau để nắm rõ điều này.
Một US tốt khi nó thể hiện được modeling user behavior thay vì modeling GUI application. Vì modeling giao diện người dùng (GUI) ràng buộc bạn trong khuôn khổ của GUI. Nó khiến cho suy nghĩ của bạn bị chi phối, làm cho bạn sẽ không còn khả năng sáng tạo nữa.
Tác hại của điều này là làm cho suy nghĩ của bạn hoàn toàn bị tê liệt khi bấu víu vào GUI. Điều này đi ngược lại hoàn toàn với mục đích ( lợi ích) của US đó là phát huy hết mức khả năng sáng tạo khi cùng nhau thảo luận (brainstorming) vấn đề mà khách hàng đang gặp phải.
Xóa bỏ GUI ra khỏi tâm trí, khiến chúng ta mang lại cho khách hàng những thứ chỉ có trong tưởng tượng.
Einstein: “Logic sẽ đưa chúng ta từ điểm A đến điểm B. Trí tưởng tượng sẽ đưa chúng ta tới mọi nơi”
Minh chứng rõ ràng nhất cho điều này chính là Apple đã xóa bỏ hoàn toàn bàn phím cơ trên các thiết bị smartphone để cho ra đời một thế hệ điện thoại màn hình cảm ứng. Nó không chỉ giúp người dùng có trải nghiệm tốt mà còn giúp cho các nhà phát triển ứng dụng phần mềm trên điện thoại thảo sức sáng tạo.
Hãy tưởng tượng bàn phím vật lý giống như màn hình ứng dụng trên web hoặc app cho người dùng. Nó bao gồm các nút bấm, các field, các link… các web element. Hãy vứt nó sang một bên để giải phóng sự sáng tạo của bạn
Đôi khi chúng ta thấy những US được viết ra mà đọc xong thấy rất vô thưởng, vô phạt. Nó chẳng sai nhưng chẳng có ý nghĩa gì. Họ tập trung vào các kịch bản không quan trọng hoặc đơn giản hơn nữa là nêu lên những điều hiển nhiên.
Là người dùng, tôi muốn biết thông tin lương nên tôi xem payslip
Là người dùng, tôi muốn họp nên tôi đặt phòng họp
Là người dùng, tôi muốn xem sơ đồ công ty để tôi biết cấu trúc của công ty
Là người dùng, tôi muốn ….
Chúng ta đều biết US mô tả các business rule cần được giải quyết một cách RÕ RÀNG và ĐƠN GIẢN nhưng ta thấy có những US QUÁ đơn giản.
Einstein: “Everything should be made as simple as possible, but not simpler”
Chẳng ai có được bài học gì từ những US kiểu như thế này. Không có bài học thì làm sao có thể cải tiến
