Xem Nhiều 2/2023 #️ User Story Và Use Case # Top 6 Trend | Toiyeucogaihalan.com

Xem Nhiều 2/2023 # User Story Và Use Case # Top 6 Trend

Cập nhật thông tin chi tiết về User Story Và Use Case mới nhất trên website Toiyeucogaihalan.com. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất.

Các lập trình viên thường có thói quen đi vào dự án và bắt đầu lập trình ngay. Họ nói với người dùng của mình rằng: “Tôi biết tất cả những gì mà bạn cần” khi nghe người dùng nói về yêu cầu của họ.

Những phương pháp Agile chỉ ra rằng đó là một cái bẫy cho các lập trình viên. Agile cũng cho thấy những nhà phát triển phải làm việc với người dùng trong suốt dự án để hiểu người dùng cần gì nếu muốn tránh bẫy lỗi lập trình.

Đó là lý do tại sao User Story là một trong những công cụ tốt nhất để triển khai theo phương pháp Agile.

1. User Story là gì?

Khái niệm User Story

User Story còn được một số người gọi với cái tên là Scenario (kịch bản) để mô tả một yêu cầu từ người dùng.

Hầu hết User Story được viết bằng ngôn ngữ của người dùng. Vì thế, bất kì người dùng nào cũng có thể đọc và hiểu ngay. User story thường gần gũi với từ ngữ thường ngày của người dùng.

User Story thường được viết trên Card, giấy note, tài liệu Words, Excels… tùy dự án.

2. Use Case là gì?

Khái niệm Use Case

Use case cũng có vài điểm gần giống như một User Story nhưng nó sẽ mô tả cách tương tác giữa người dùng và phần mềm. Use Case là một mô tả đầy đủ về tất cả những trường hợp mà người dùng sử dụng phần mềm sẽ gặp phải.  

Qua đó, giúp người lập trình nắm bắt những cách giúp người dùng tương tác với phần mềm để đạt kết quả mong muốn. Đồng thời, loại bỏ những thao tác sai khiến người dùng không đạt kết quả khi sử dụng phần mềm.

3. Sự giống và khác nhau giữa User Story và Use Case

3.1 Giống nhau:

Các User Story thường được bắt đầu giống như các Use Case. Mỗi User Story sẽ mô tả một cách sử dụng phần mềm, tập trung vào kết quả và đều được viết bằng ngôn ngữ người dùng.

Cả User Story và Use Case đều sử dụng ngôn ngữ tự nhiên của của doanh nghiệp và chỉ kể một phần chứ không phải tất cả.

3.2 Khác nhau:

Mặc dù User Story và Use Case được định nghĩa khá giống nhau chúng vẫn có những khác biệt. Đảm nhận những vai trò khác nhau trong một dự án phần mềm và giúp dự án được vận hành tốt hơn.

“Tính năng tìm kiếm và thay thế trong trình soạn thảo văn bản”

Hãy so sánh một User Story cho chức năng tìm kiếm và thay thế bằng một Use Case với cùng tính năng sẽ giúp bạn hiểu được sự khác nhau.

Không khó để tìm ra User Story cho ví dụ trên. Có rất nhiều cách để tìm ra User Story bạn có thể bắt đầu bằng cách viết ra một tấm thẻ (card) như sau:

Ví dụ về chức năng tìm kiếm và thay thế User Story (Serch and Replace)

Bây giờ, nếu bạn không quen với User Story, bạn có thể nghĩ rằng: “chức năng tìm kiếm và thay thế trong trình soạn thảo của tôi cần nhiều hơn thế”.Thông thường User Story sẽ không đủ thông tin để giúp người dùng hiểu được phần mềm sẽ cần gì.

Còn đây là ví dụ về Use Case để bạn có thể hiểu được cách mà Use Case hoạt động:

 

 

Nếu tôi là một nhà phát triển và đang xây dựng một trình soạn thảo, tôi có thể viết một chức năng tìm kiếm và thay thế theo một Use Case cụ thể như trên.

Một vài điểm thú vị của Use Case đó là trong khi bạn đọc về ví dụ trên hẳn bạn đang nghĩ về thứ gì đó giống như khung tìm kiếm và thay thế (Replace dialog) trong Notepad hoặc Microsoft Word.

Chức năng tìm kiếm và thay thế của Microsoft Word

Và có rất nhiều cách khác nhau để bạn xây dựng phần mềm để thực hiện Use Case. Bạn đã từng sử dụng chức năng tìm kiếm và thay thế trong Word hoặc Notepad chưa? Chúng có gì khác nhau?

Chức năng tìm kiếm và thay thế của Notepad++

Có rất nhiều điểm khác biệt giữa chúng về giao diện, cách sử dụng… Tuy nhiên, nếu bạn so sánh chúng với Use Case trong ví dụ trên, bạn sẽ thấy rằng chúng đều đi theo cùng diễn biến của những sự kiện cơ bản.

User Story là những gì cần thiết:

User Story thường được viết trên Cards

Khi bạn viết một User Story, những gì bạn mô tả là nhu cầu của người dùng. Một điều gì đó mà người dùng cần để thực hiện công việc của họ mà nếu bạn không tạo ra phần mềm cho họ thì điều đó sẽ tồn tại mãi.

Chẳng hạn trong ví dụ trên là chức năng tìm kiếm và thay thế. Nếu không có phần mềm người dùng sẽ phải tìm và thay thế một cách thủ công, mất nhiều thời gian và không hiệu quả.

Use Case là cách mà phần mềm sẽ tương tác đối với yêu cầu của người dùng:

Một nhà phát triển phần mềm cần khả năng đọc một Use Case và hiểu phần mềm cần làm gì. Có rất nhiều chi tiết và mô tả mọi thứ mà người phát triển cần xây dựng để đáp ứng nhu cầu người dùng.

Đó là lý do tại sao Use Case cần được chi tiết, rõ ràng và không mơ hồ. Bạn có thể thấy Use Case trong ví dụ trên được viết chi tiết từng bước thao tác người dùng và cách mà phần mềm phản hồi.

User Story phải dễ đọc và hiểu đối với người dùng:

Cấu trúc thường có của 1 user story

Khi bạn viết một User Story, điều bạn cần tập trung là làm cách nào để bất kì ai cũng có thể đọc hiểu. User Story cần được mô tả một cách đầy đủ trong vài câu, đó là lý do vì sao User Story thường là một bảng tóm tắt và được viết trong những tấm thẻ, giấy note, ghi chú…

Use Case sẽ mô tả một đầy đủ về cách phần mềm tương tác với người dùng:

Khi bạn lên danh sách các Use Case, điều bạn cần làm chính là đưa ra một giải pháp về chức năng phần mềm cho nhu cầu của người dùng. Nó phải là một giải pháp mà những người phát triển có thể triển khai khi xây dựng phần mềm.

Một User Story có thể có nhiều Use Case và khi bạn tập hợp tất cả Use Case vào một tài liệu. Lúc đó, bạn sẽ có một tập hợp đầy đủ mô tả những tương tác giữa người dùng với phần mềm mà bạn sẽ làm.

Và nếu phần mềm của bạn phải tương tác với nhiều hệ thống, bạn có thể xem các hệ thống như là những người dùng trong Use Case.

Để hiểu rõ hơn về user story và use case trong quá trình sử dụng bạn có thể tham gia khóa đào tạo phân tích nghiệp vụ phần mềm của BAC. Nguồn:

Tham khảo bài viết: Phân biệt User Scenirio, User Story và Use Case

CÁC KHOÁ HỌC BUSINESS ANALYST chúng tôi DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất. 

BAN BIÊN TẬP NỘI DUNG BAC

Nhóm Tài Liệu Cho Ba: User Story, Use Case Và Functional Specification Document

Trong bài viết trước, BAC đã gửi đến bạn đọc quy trình làm việc đầu tiên của người BA với loại tài liệu Project Vision Document với mục đích để có một góc nhìn tổng quan đối với dự án.

Tiếp đến, để mô hình hóa được các yêu cầu đó cho team dev hiểu và bắt đầu thực thi dự án, người BA cần xây dựng các loại tài liệu. Có thể kể đến là Use Case/ User Story và Functional Specification.

1. User story (US) và Use case (UC)

User story (còn được gọi là Scenario) dùng để mô tả một nhu cầu /yêu cầu của người dùng. Trong khi đó Use case là cách thể hiện sự tương tác giữa người dùng và hệ thống. Tuy nhiên, cả 2 đều được tạo ra nhằm mục đích cụ thể hóa những yêu cầu của người dùng đối với hệ thống.

Với những dự án thực hiện theo phương pháp Agile, họ tập trung vào cách nào là hiệu quả nhất để delivery sản phẩm tốt nhất đến cho khách hàng. Và loại tài liệu phổ biến được dùng đó là User story. User story được viết dưới dạng mong muốn của người dùng với hệ thống nhưng cũng chính là những chức năng mà hệ thống cần có.

Xác định rõ ràng với các thành viên trong team của bạn cần thực hiện những phần nào trước (Cụ thể trong kì Sprint này cần làm những gì?)

Đảm bảo mọi người có chung một cái hiểu đúng về vấn đề

Là điều kiện mà tester dựa vào đó để kiểm thử US

Ví dụ về một US: Là một người dùng, tôi muốn đăng nhập vào hệ thống để mua sắm online.

Nguồn ảnh: www.visual-paradigm.com

Vậy để viết User story được tốt nhất, bạn có thể áp dụng theo phương pháp INVEST. Đây là từ viết tắt của:

I – Independent: US có thể đứng độc lập như một chức năng của hệ thống hay không?

N – Negotiable: US có thể thay đổi hay xóa đi mà không ảnh hưởng đến những phần còn lại của dự án hay không?

V – Valuable: US này có thực sự hữu ích đối với người dùng cuối hay không?

E – Estimable: Bạn có thể ước tính được độ rộng của US này hay không? Điều này sẽ giúp bạn quyết định xem liệu có nên tách ra US thành nhiều US không?

S – Small: Liệu US này có vừa đủ thực hiện trong Sprint kì này không?

T – Testable: Bạn có thể đánh giá được US này hay không?

Bạn có thể có thể tham khảo bài viết sau để hiểu hơn UC/US: Link

Hay một ví dụ về sơ đồ UC: Làm thủ tục checkin và kiểm tra tại sân bay

Nguồn ảnh: chúng tôi

Mục đích của UC: Mô tả lại quy trình làm thủ tục check-in và kiểm tra tại sân bay

Business actors: Hành khách (Passenger) bao gồm đối tương như Trẻ nhỏ (Minor Passenger), Người khuyết tật (Passenger with Special Needs), người hướng dẫn (Tour Guide).

Bối cảnh: Làm thủ tục checkin theo cá nhân, theo nhóm và kiểm tra. Đối với trường hợp kí gửi hàng hóa là một case extend của case checkin.

2. FSD

Tài liệu Functional Specification Document (FSD) (hay tên gọi khác là Functional Requirements Document (FRD)), hỗ trợ cho các quản lí dự án phát triển phần mềm hạn chế những nhầm lẫn hay đi lệch hướng của dự án.

Nhu cầu đào tạo doanh nghiệp

là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của quốc tế. Ngoài các khóa học public, còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

Khoá học Online:

Khoá học Offline:

User Story Là Gì? User Story Mẫu Và Nguyên Tắc Ứng Dụng Trong Agile

Với những nhóm dùng bảng vật lý thì User Story được viết trên các thẻ nhỏ hoặc trên các miếng giấy dán. Nhóm có thể dán các thẻ này lên bảng như những hạng mục của Product Backlog.

User story có định dạng:

Mô hình của User Story

Card (Thẻ): Thông thường, User Story được viết trên một thẻ nhỏ. Điều đó có nghĩa là nó thường ngắn để có thể viết trên một thẻ. Nếu bạn có viết trên một hệ thống khác như Trello, Jira, Assembla hoặc Redmine cũng nên giữ nó ngắn.

Conversation (Trao đổi): Story là những câu chuyện giữa khách hàng và Các Nhà . Do đó chi tiết của User Story được làm rõ thông qua các cuộc trao đổi (nên là trực tiếp) với khách hàng. Nội dung của User Story sẽ ngày càng cụ thể tùy thuộc vào độ ưu tiên của nó (nếu ưu tiên cao, cần làm sớm thì sẽ có nội dung chi tiết, nếu ưu tiên thấp thì chỉ chứa nội dung chung).

Confirmation (Xác nhận): User Story có tiêu chí chấp nhận (Acceptance Criteria) để khách hàng suy nghĩ cụ thể về yêu cầu và các Nhà Phát triển có thể hiểu yêu cầu rõ hơn và xác nhận được khi nào sản phẩm hoàn thành.

Ai là người làm ra User Story?

Trong trường hợp lý tưởng nhất, người dùng thực sự của sản phẩm sẽ tham gia viết User Story.

Trong những trường hợp khác, Product Owner có thể đại diện cho người dùng, nhưng phải luôn viết User Story với vai trò của người dùng, không phải với vai trò của Product Owner.

Các tiêu chí của User Story

Independent (Độc lập): Độc lập với các User Story khác. Điều này giúp Product Owner tự do thay đổi thứ tự của nó trong và Nhà Phát triển dễ dàng phát triển.

Negotiable (Thương lượng được): Tính đàm phán được giúp cho Nhóm Phát triển và Product Owner cùng nhau xây dựng nội dung chi tiết và phù hợp hơn cho những thay đổi trong tương lai. Nếu không có tính năng này thì việc thích nghi với sự thay đổi gặp khó khăn.

Valuable (Có giá trị): User Story phải có giá trị với khách hàng. Những người làm kỹ thuật có thể thấy việc làm khung làm việc, cơ sở dữ liệu hoặc thiết kế là quan trọng. Tuy nhiên với khách hàng thì không. Điều này rất lưu ý với những Product Owner có nền tảng kỹ thuật, có thể họ sẽ biết Agile thành một mô hình phát triển Waterfall trá hình!

Estimable (Ước lượng được): Một User Story tốt có thể ước lượng được mặc dù không cần chính xác. Những User Story lớn hoặc không rõ ràng thường khó để ước lượng. Khả năng ước tính được giúp nhóm ước lượng tốt hơn công việc sẽ làm và cả kế hoạch phát hành. Rõ ràng điều này phụ thuộc vào khả năng của nhóm.

Sized appropriately (Kích thước phù hợp): Những User Story sắp được đưa vào sản xuất cần có kích thước nhỏ (đồng nghĩa với việc được mô tả rõ ràng hơn), những User Story chưa được đưa vào sản xuất trước mắt có thể có kích thước lớn hơn.

Testable (Kiểm thử được): Nếu nhóm phát triển biết như thế nào là User Story đó hoàn thành – có thể kiểm thử được rõ ràng thì họ có thể hiểu rõ hơn công việc của mình, ít gây hiểu nhầm. Các mô hình phát triển BDD hoặc ATDD có giá trị vì yêu cầu có thể kiểm thử được.

Khi nào thì cần viết User Story?

Việc này thường được tiến hành thông qua tổ chức một buổi viết User Story (User Story Writing Workshop). Ở đó, tất cả các thành viên đều tham gia tạo ra các User Story cơ bản, đủ để sản xuất trong một thời gian. Có thể có các User Story lớn, chúng ta sẽ sẽ được làm mịn hơn song song với quá trình phát triển thông qua hoạt động làm mịn Product Backlog.

Ví dụ cụ thể về User Story

Là một người học trực tuyến, tôi muốn thấy danh sách các khóa học ưu thích của mình để dễ dàng truy cập.

Trong ví dụ trên, user story có 3 phần tách biệt:

Người dùng ở đây được chỉ ra rõ ràng là người học trên môi trường học tập trực tuyến, không phải là người quản lý, cũng không phải là người học trực tiếp.

Người dùng này muốn nhìn thấy danh sách các khóa học ưu thích của mình. Danh sách này chỉ bao gồm những khóa học mà học giả quan tâm nhất trong rất nhiều những khóa học mà mình đã từng học.

Mục đích của việc có danh sách này là để dễ dàng truy cập khi cần đến.

Từ việc miêu tả nhu cầu của khách hàng, các thành viên phát triển làm rõ tiêu chí chấp nhận với Product Owner và sau đó sẽ cùng nhau phân tích chi tiết giao diện, mã, thêm bảng dữ liệu, tương tác dữ liệu,…để thực thi một cách hiệu quả.

Để tìm hiểu kĩ hơn cũng như biết cách viết 1 User Story, các Product Owner cần có cái nhìn tổng quan để quản lý dự án 1 cách chặt chẽ nhất.

Giữ bản mô tả User Story ngắn gọn.

Hãy đặt mình vào suy nghĩ của người dùng cuối khi viết User Story.

Các mục trong User Story cần phải được xác nhận trước khi triển khai phát triển.

Ước lượng User Story trước khi thực hiện để chắc chắn khối lượng công việc của team nằm trong tầm kiểm soát.

Các yêu cầu sẽ được khai thác từ người dùng cuối cùng, chứ không phải bởi người dùng cuối hay nhóm phát triển.

Giao tiếp là điều cực kì quan trọng nếu như bạn muốn hiểu người dùng cuối cùng.

User Story được xem là rất quan trọng trong một dự án. Nếu nhóm của bạn hay Product Owner không thể hiểu được hoặc hiểu sai người dùng cuối, thì kết quả là một sản phẩm mà khách hàng không cần.

Không có gì vô dụng bằng việc thực hiện hiệu quả những việc không nên hoàn thành

– Peter Drucker –

Một điều chắc chắn rằng, nếu bạn tuân thủ theo các nguyên tắc của Agile và áp dụng chuẩn phương pháp Scrum thì không hề khó khăn để có thể hoàn thành một dự án thành công với những User Story thực sự hiệu quả.

Các công ty hàng đầu thế giới và Việt Nam đều đã và đang dịch chuyển sang mô hình Agile một cách rất hiệu quả. Học viện Agile tự hào đồng hành cùng các doanh nghiệp thành công trong việc chuyển đổi Agile. Một số khách hàng của chúng tôi có thể kể đến như Viettel, VinGroup, VNPT, MSB, Techcombank, F88, FPT Software,…

Ở Học viện Agile, chúng tôi sẵn sàng cung cấp cho bạn những kiến thức về Scrum dưới góc nhìn, kinh nghiệm của các chuyên gia Scrum hàng đầu. Vì với kinh nghiệm nhiều năm đào tạo về Agile/Scrum, chúng tôi hiểu rằng Agile/Scrum học dễ nhưng khó tinh thông, người học rất dễ rơi vào trạng thái biết mà thực ra lại không biết. Bởi Scrum nếu áp dụng chuẩn, đúng thì sẽ vô cùng hiệu quả, còn nếu Scrum sai, Scrum không đúng, hay Scrum không bài bản thì có thể hậu quả để lại khá lớn.

Xây dựng mạng lưới đội nhóm để vượt qua khủng hoảng

User Story Là Gì Và Tiêu Chí Chấp Nhận

Hướng dẫn các tiêu chí chấp nhận user story với các kịch bản thực tế.

Trong ngành phát triển phần mềm, từ ‘Yêu cầu’ xác định mục tiêu, những gì khách hàng cần chính xác và điều gì sẽ làm cho công ty phát triển. Có thể là một công ty sản phẩm làm cho sản phẩm phần mềm hoặc một công ty dịch vụ cung cấp các dịch vụ trong các lĩnh vực phần mềm khác 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 các yêu cầu được đáp ứng như thế nào.

Thuật ngữ “yêu cầu” có tên khác nhau trong các phương pháp luận dự án khác nhau.

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

User Story là yêu cầu đối với bất kỳ chức năng hoặc tính năng nào được ghi trong một hoặc hai dòng và tối đa 5 dòng. Một User Story thường là yêu cầu đơn giản nhất có thể và là về một và chỉ một chức năng (hoặc một tính năng).

Thí dụ:

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

Đây là một phần rất quan trọng trong việc hoàn thành User story và cần được nghiên cứu bởi Chủ sở hữu sản phẩm và Chuyên gia phân tích rất tỉ mỉ bởi vì thiếu một tiêu chí duy nhất có thể tốn rất nhiều chi phí. .

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

“Cho một số tiền điều kiện khi tôi làm một số hành động và tôi mong đợi kết quả”.

Ví dụ (từ User story ở trên):

Hãy xem xét rằng tôi đang trò chuyện với một người bạn và tôi sẽ có thể chụp một bức tranh. Khi tôi nhấp vào một bức tranh, tôi sẽ có thể thêm một chú thích cho hình ảnh trước khi gửi nó. Nếu có một số vấn đề với việc khởi động camera điện thoại của tôi, một thông báo lỗi như ‘Không thể bắt đầu camera’. vv, nên được hiển thị cho phù hợp.

Do đó, User story xác định yêu cầu đối với bất kỳ chức năng hoặc tính năng nào trong khi Tiêu chí Chấp nhận xác định ‘ hoàn thành’ cho User story hoặc yêu cầu.

Là một QA, rất quan trọng để hiểu được User story và các tiêu chí chấp nhận của nó một cách sâu sắc thậm chí không còn 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 chúng ta hãy hiểu tầm quan 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, đó là User story.

Các trường hợp sau đây là kinh nghiệm thực tế của riêng tôi.

Trường hợp 1:

3 năm trước, tôi đã làm việc trên một Dự án ứng dụng dành cho thiết bị di động và sản phẩm là một ứng dụng được thiết kế cho những người giao hàng.

Bạn sẽ thấy người giao hàng đến nơi giao hàng của bạn. Và họ có điện thoại di động mà họ yêu cầu bạn cung cấp chữ ký của bạn sau khi giao hàng. Chữ ký này phản ánh trên cổng thông tin của các nhà cung cấp 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 cho thiết bị di động mới được khởi chạy và cổng thông tin của họ đã có sẵn và đang hoạt động.

Vấn đề: chủ sở hữu Sản phẩm của bạn có User story dành cho ứng dụng trên thiết bị di động này “Với tư cách là Admin, tôi sẽ có thể xem chữ ký của người giao hàng tại thời điểm giao hàng”. Ở đây cổng thông tin (ứng dụng web) được thay đổi và cập nhật cho phù hợp để phản ánh chữ ký.

Với tư cách là Quản lý chất lượng, bạn phải xác minh xem chữ ký đã chụp trong ứng dụng dành cho thiết bị di động đang phản ánh như mong đợi trong cổng thông tin không.

Nếu bạn nhìn vào User story này, có vẻ đơn giản nhưng có một yêu cầu ẩn ở đây rằng “Đối với lịch sử giao hàng, không có chức nă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ử cần xóa ?

Giải pháp: Khi các bảng DB tương ứng được cập nhật để thêm một cột mới cho vị trí Chữ ký, dữ liệu cũ nên có một giá trị NULL hoặc 0 cần được kiểm tra và một thông báo cho biết ‘Không có chữ ký tồn tại’ nên được hiển thị.

Điều này có thể được gọi là thiếu sót từ Chủ sở hữu sản 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 nhưng phá vỡ một cái gì đó cùng với nó không phải là mong muốn của khách hàng.

Trường hợp số 2

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

Vấn đề: Chủ sở hữu Sản phẩm cung cấp cho bạn User story “Với tư cách là Người cố vấn, tôi muốn xem báo cáo của khách hàng của tôi dựa trên các thông tin tài chính được cung cấp”.

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

Các báo cáo nên xem xét tỷ lệ chuyển đổi tiền tệ hàng ngày và không phải là tỷ lệ chuyển đổi trong lịch sử như trong báo cáo được xem lần gần đây nhất và

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

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

Hiểu được các tiêu chí chấp nhận và tất cả các điều kiện và quy tắc khác một cách triệt để thậm chí còn quan trọng hơn việc hiểu một User story. Bởi vì nếu yêu cầu là không đầy đủ hoặc mơ hồ, nó có thể được đưa lên trong lần chạy sprint tiếp theo nhưng nếu một tiêu chí chấp nhận bị bỏ qua, user story sẽ không thể được release.

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

Có một tùy chọn để chọn loại tệp để tải báo cáo của bạn. Có một tùy chọn để chọn nếu bạn chỉ muốn tải về các Tín dụng / Nợ / cả hai.

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

Với các Tiêu chí Chấp nhận sau đây khi đang ở trang tải xuống lịch sử giao dịch :

khoảng thời gian mà tôi muốn tải xuống lịch sử giao dịch.

tài khoản mà tôi muốn tải xuống .

không được phép tải xuống lịch sử cho ngày trong tương lai.

không được phép chọn ngày 10 năm trước trong quá khứ.

có thể xem tệp tin đã tải xuống.

có thể tải xuống trong định dạng doc, excel và pdf.

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

Tên và đị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ị trong tệp.

Danh sách tùy chọn để chọn loại giao dịch mà khách hàng muốn, nghĩa là chỉ ghi nợ hoặc chỉ có các khoản tín dụng hoặc cả hai. Các trường hợp như vậy có thể xảy ra một lần trong một thời gian, tuy nhiên vẫn nghiên cứu tốt về mỗi tiêu chí chấp nhận và cố gắng hình dung nó với tham chiếu đến User story. Bạn càng nghiên cứu sâu hơn về các điều kiện và quy tắc nghiệp vụ thì bạn càng có nhiều kiến thức về tính năng này.

Lỗi tìm thấy trong giai đoạn ban đầu không có gì chi phí so với những gì nó có thể chi phí trong giai đoạn kiểm thử.

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

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

Tốn Thời gian: Nếu sự khác biệt hoặc sai sót trong các tiêu chí chấp nhận / user story được tìm thấy khi phát triển đang diễn ra hoặc kiểm thử đang diễn ra, thì rất nhiều việc làm lại có thể cần phải được thực hiện trong thời gian sprint còn lại.

Điều này không xảy ra ngay cả khi Chủ sở hữu sản phẩm bỏ lỡ vài điều, họ sẽ chuyển user story đến lần sprint sắp tới. 95% là họ yêu cầu đội thực hiện việc công viêc cần thiết và release trong cùng 1 sprint.

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

Trong tình huống như vậy, sẽ có những sai sót trong giai đoạn phát triển hoặc kiểm thử.

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

Không có công cụ hoặc khóa học cụ thể sẵn có trên thị trường để làm đ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ề sản phẩm.

Tham gia vào cuộc họp trước khi lên kế hoạch một cách tích cực, nói chuyện với BA, tự nghiên cứu . Bạn càng đặt nhiều nỗ lực, bạn càng học thì càng phát triển.

Dù là QA hay developer, tất cả mọi người phải ở cùng hướng về user story và các tiêu chí chấp nhận của họ, chỉ khi đó sự thành công của khách hàng mới có thể đạt được.

Bài viết được dịch lại từ nguồn: http://www.softwaretestinghelp.com/user-story-acceptance-criteria/#more-22289

All Rights Reserved

Bạn đang xem bài viết User Story Và Use Case trên website Toiyeucogaihalan.com. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!