USER STORY LÀ GÌ

     

Trong ngành trở nên tân tiến phần mềm, từ "Yêu cầu" xác minh mục tiêu, phần đa gì người sử dụng cần đúng mực và điều gì sẽ khiến cho công ty phân phát triển. Rất có thể là một công ty sản phẩm làm đến sản phẩm phần mềm hoặc một công ty dịch vụ hỗ trợ các thương mại dịch vụ trong các nghành phần mềm không giống nhau, cơ sở chính cho tất cả chúng là yêu cầu và sự thành công được xác định bởi những yêu ước được đáp ứng nhu cầu như vắt nào.

Bạn đang xem: User story là gì

Thuật ngữ "yêu cầu" có tên khác nhau trong các phương pháp luận dự án công trình khác nhau.

Trong mô hình water fall , nó được gọi là "Requirement / Specification Document", vào Agile hoặc SCRUM nó được hotline là "Epic", "User Story".

User Story là gì?

User Story là yêu mong đối với ngẫu nhiên chức năng hoặc tài năng nào được ghi vào một hoặc hai loại và tối đa 5 dòng. Một User Story thường là yêu thương cầu dễ dàng và đơn giản nhất rất có thể và là về một và chỉ một công dụng (hoặc một tính năng).

Định dạng tiêu chuẩn chỉnh được sử dụng thịnh hành nhất cho việc tạo User Story được nêu dưới đây:

Là nhằm tôi có thể .

Thí dụ:

Là người dùng WhatsApp, tôi mong có một biểu tượng máy hình ảnh trong vỏ hộp thoại viết để chụp và gửi hình ảnh để tôi có thể nhấp và phân tách sẻ hình ảnh của tôi cùng với tất cả bạn bè của tôi.

*

Tiêu chí đồng ý là gì?

Tiêu chí gật đầu là một tập hợp những điều khiếu nại được gật đầu đồng ý hoặc những quy tắc nhiệm vụ mà tác dụng hoặc công dụng phải thỏa mãn nhu cầu và đáp ứng, để được đồng ý bởi nhà sở hữu thành phầm / các bên liên quan.

Đây là một trong những phần rất đặc biệt trong việc chấm dứt User story và buộc phải được phân tích bởi công ty sở hữu sản phẩm và chuyên viên phân tích hết sức tỉ mỉ cũng chính vì thiếu một tiêu chí duy nhất rất có thể tốn tương đối nhiều chi phí. .

Định dạng của nó như sau:

"Cho một vài tiền đk khi tôi có tác dụng một số hành vi và tôi mong mỏi đợi kết quả".

Ví dụ (từ User story nghỉ ngơi trên):

Hãy lưu ý rằng tôi đang nói chuyện với một người chúng ta và tôi sẽ hoàn toàn có thể chụp một bức tranh.Khi tôi nhấp vào một trong những bức tranh, tôi sẽ hoàn toàn có thể thêm một chú thích mang đến hình ảnh trước khi gởi nó.Nếu có một số vấn đề với việc khởi rượu cồn camera điện thoại của tôi, một thông báo lỗi như "Không thể bước đầu camera". Vv, đề nghị được hiển thị đến phù hợp.

Do đó, User story xác minh yêu cầu đối với ngẫu nhiên chức năng hoặc tuấn kiệt nào trong những lúc Tiêu chí gật đầu xác định " hoàn thành" mang lại User story hoặc yêu cầu.

Là một QA, rất quan trọng đặc biệt để hiểu được User story và các tiêu chí đồng ý của nó một cách thâm thúy thậm chí không thể nghi ngờ gì nữa khi bắt đầu thử nghiệm.Đào sâu vào User storyĐể bắt đầu, trước tiên bọn họ hãy đọc tầm đặc trưng của một nghiên cứu sâu về một điều căn bản và cơ bản, sẽ là User story.

Các trường vừa lòng sau đây là kinh nghiệm thực tế của riêng rẽ tôi.

Trường đúng theo 1:

3 năm trước, tôi đã thao tác trên một dự án ứng dụng dành cho thiết bị cầm tay và thành phầm là một áp dụng được thiết kế cho người giao hàng.

Bạn đang thấy người phục vụ đến nơi phục vụ của bạn. Và họ có điện thoại di động mà họ yêu mong bạn cung ứng chữ ký của công ty sau khi giao hàng. Chữ ký kết này đề đạt trên cổng thông tin của các nhà hỗ trợ dịch vụ chuyển phát nhanh như DTDC, FedEx vv

Hãy tưởng tượng rằng ứng dụng dành riêng cho thiết bị di động mới được khởi chạy và cổng thông tin của mình đã gồm sẵn và đang hoạt động.

Vấn đề: chủ cài Sản phẩm của người tiêu dùng có User story dành cho ứng dụng bên trên thiết bị cầm tay này "Với tư phương pháp là Admin, tôi sẽ rất có thể xem chữ ký của người ship hàng tại thời gian giao hàng". Ở phía trên cổng thông tin (ứng dụng web) được đổi khác và cập nhật cho cân xứng để phản ánh chữ ký.

Với tư biện pháp là quản lý chất lượng, chúng ta phải xác minh coi chữ ký kết đã chụp vào ứng dụng dành riêng cho thiết bị di động đang phản ảnh như muốn đợi trong cổng thông tin không.

Nếu các bạn nhìn vào User story này, bao gồm vẻ dễ dàng nhưng gồm một yêu ước ẩn tại đây rằng "Đối với lịch sử hào hùng giao hàng, ko có công dụng phản chiếu chữ ký, vậy điều gì sẽ xảy ra nếu những người truy cập cổng xem lịch sử giao hàng?” Dữ liệu lịch sử dân tộc cần xóa ?

Giải pháp: Khi các bảng DB tương xứng được cập nhật để thêm một cột bắt đầu cho vị trí Chữ ký, dữ liệu cũ nên gồm một giá trị NULL hoặc 0 rất cần được kiểm tra cùng một thông báo cho thấy thêm "Không bao gồm chữ cam kết tồn tại" nên được hiển thị.

Điều này rất có thể được hotline là thiếu thốn sót từ chủ sở hữu thành phầm hoặc chuyên gia phân tích nhưng điều này phải được thực hiện. Thực hiện một tính năng thành công xuất sắc nhưng phá vỡ lẽ một cái gì đó cùng với nó chưa phải là mong ước của khách hàng hàng.

Trường vừa lòng số 2

6 năm trước, tôi đã làm việc về Ứng dụng Tài thiết yếu Kế hoạch Hưu Trí (không gồm BA), một vận dụng toàn cầu hoàn toàn có thể sử dụng nó cho các loại tiền tệ khác nhau đặt trên kế hoạch đầu tư, ngày tiết kiệm

Vấn đề: chủ sở hữu sản phẩm cung cấp cho mình User story "Với tư giải pháp là fan cố vấn, tôi ao ước xem report của quý khách hàng của tôi dựa trên những thông tin tài bao gồm được cung cấp".

Xem thêm: Cách Sử Dụng Veet Tẩy Lông Vùng Kín Veet Của Nhật Bản Nội Địa Mới

Ở đây bao gồm 2 yêu mong ẩn cùng tôi sẽ gọi nó là một User story không vừa đủ bởi vì:

Các báo cáo nên cẩn thận tỷ lệ biến hóa tiền tệ mỗi ngày và chưa phải là tỷ lệ thay đổi trong lịch sử hào hùng như trong báo cáo được xem lần cách đây không lâu nhất và

Nếu đồng tiền được biến đổi sau lúc cung cấp chi tiết tài chính của khách hàng hàng, report sẽ hiển thị bằng đơn vị tiền tệ đã ráng đổi

Giải pháp: Tôi nêu ra mối niềm nở này trực tiếp với nhà sở hữu sản phẩm của chúng tôi và tạo nên anh ta biết rằng cả hai vấn đề đó phải được tiến hành càng mau chóng càng tốt. Ông đã đồng ý với tôi và tạo ra 2 User story khác nhau cho sprint tiếp đây với sự ưu tiên.

Ghi chép để gia công cho các thứ tiện lợi hơn và bàn thảo với cha và những nhà phát triển về xem xét của họ.

Xem xét Tiêu chí gật đầu theo chiều sâu

Hiểu được những tiêu chí gật đầu và toàn bộ các đk và quy tắc khác một giải pháp triệt để thậm chí còn đặc biệt hơn câu hỏi hiểu một User story. Cũng chính vì nếu yêu ước là không đầy đủ hoặc mơ hồ, nó hoàn toàn có thể được gửi lên trong lần chạy sprint tiếp theo nhưng ví như một tiêu chí gật đầu bị quăng quật qua, user story sẽ không thể được release.

Tôi đoán tất cả chúng ta đã hoàn toàn có thể sử dụng ngân hàng và hầu hết chúng ta sử dụng nó hàng ngày và tôi download về báo cáo lịch sử của tôi rất nhiều. Nếu khách hàng quan gần kề nó cẩn thận, có một số tùy chọn cụ thể có sẵn để cài chúng.

Có một tùy lựa chọn để chọn các loại tệp nhằm tải report của bạn. Bao gồm một tùy lựa chọn để chọn nếu như khách hàng chỉ mong mỏi tải về các Tín dụng / Nợ / cả hai.

Bây giờ đồng hồ hãy tưởng tượng rằng chủ sở hữu sản phẩm cung cấp cho mình user story này "Là khách hàng hàng, tôi muốn tải xuống bản sao kê tài khoản của chính bản thân mình để tôi rất có thể xem tất cả các thanh toán giao dịch của tôi được tiến hành trong một khoảng thời hạn cụ thể".

Với những Tiêu chí đồng ý sau phía trên khi vẫn ở trang download xuống lịch sử dân tộc giao dịch :

khoảng thời hạn mà tôi mong mỏi tải xuống lịch sử vẻ vang giao dịch.tài khoản nhưng tôi mong muốn tải xuống .không được phép sở hữu xuống lịch sử dân tộc cho ngày vào tương lai.không được phép chọn ngày 10 năm ngoái trong vượt khứ.có thể xem tệp tin đã download xuống.có thể cài đặt xuống trong định hình doc, excel và pdf.

Có 3 điều thiếu sống các tiêu chí trên :

Tên với định dạng của tên tệp sẽ được tải xuống.Thông tin gì (Tên cột) sẽ được hiển thị vào tệp.Danh sách tùy chọn để lựa chọn loại giao dịch thanh toán mà quý khách hàng muốn, tức là chỉ ghi nợ hoặc chỉ có những khoản tín dụng thanh toán hoặc cả hai.Các trường phù hợp như vậy hoàn toàn có thể xảy ra một lần trong một thời gian, mặc dù vẫn nghiên cứu tốt về mỗi tiêu chí đồng ý và nỗ lực hình dung nó cùng với tham chiếu cho User story. Bạn càng nghiên cứu sâu rộng về những điều kiện với quy tắc nhiệm vụ thì chúng ta càng có khá nhiều kiến thức về tính chất năng này.

Lỗi tìm kiếm thấy trong giai đoạn lúc đầu không tất cả gì chi phí so với phần lớn gì nó tất cả thể ngân sách chi tiêu trong tiến trình kiểm thử.

*

Tầm đặc biệt quan trọng của việc đào bới tìm kiếm kiếm Sự khác biệt giữa user story và tiêu chí chấp nhận

Điều đặc biệt quan trọng là đề xuất thực hiện mày mò sâu sâu user story và các tiêu chí chấp nhận ngay từ quy trình tiến độ đầu ngay cả trước khi sự cách tân và phát triển hoặc kiểm demo bắt đầu.

Bởi vì nó bao gồm:

Tốn Thời gian:Nếu sự khác hoàn toàn hoặc sai sót trong các tiêu chí đồng ý / user story được tìm thấy khi trở nên tân tiến đang ra mắt hoặc kiểm thử đang diễn ra, thì không ít việc làm lại có thể cần đề xuất được tiến hành trong thời hạn sprint còn lại.

Điều này sẽ không xảy ra ngay cả khi Chủ mua sản phẩm bỏ qua vài điều, chúng ta sẽ gửi user story cho lần sprint sắp tới tới. 95% là họ yêu mong đội tiến hành việc công viêc cần thiết và release trong cùng 1 sprint.

Do đó nó vươn lên là một cơn ác mộng đến đội trở nên tân tiến vì họ nên dành thêm thời gian, đến vào cuối tuần hoặc thao tác vào cuối đêm. Điều này hoàn toàn có thể tránh được bằng phương pháp nghiên cứu vớt và đàm luận các tiêu chuẩn / user story ngơi nghỉ giai đoạn sớm nhất có thể có thể.

Tốn công sức:Các developer cùng QA nên xem lại code được tiến hành và test cases một lần nữa. Cập nhật, thêm và vứt bỏ theo yêu mong không phải là 1 trong những nhiệm vụ dễ dàng dàng. Nó sẽ phát triển thành áp lực.

Trong tình huống như vậy, sẽ có được những không đúng sót trong giai đoạn cải cách và phát triển hoặc kiểm thử.

*

Phần kết luận

Hiểu sâu về User story và tiêu chí gật đầu chỉ rất có thể đạt được bằng phương pháp dành thời gian nghiên cứu và phân tích nó.

Không gồm công thay hoặc khóa học cụ thể sẵn gồm trên thị trường để triển khai điều này cho bạn vì đấy là tất cả về tư duy logic, kinh nghiệm và kiến thức và kỹ năng về sản phẩm.

Tham gia vào cuộc họp trước khi lên planer một cách tích cực, thì thầm với BA, tự nghiên cứu và phân tích . Các bạn càng đặt những nỗ lực, chúng ta càng học thì càng phát triển.

Xem thêm: Bánh Pretzel Là Gì ? Ý Nghĩa Của Loại Bánh Pretzel Như Thế Nào?

Dù là QA xuất xắc developer, toàn bộ mọi fan phải sinh hoạt cùng hướng về user story và những tiêu chí gật đầu của họ, chỉ lúc đó sự thành công của khách hàng mới rất có thể đạt được.