User Story Và Use Case

--- Bài mới hơn ---

  • Test Javascript Code Với Jest
  • Tìm Hiểu Unit Testing Trongcore
  • Viết Thư Upu Quốc Tế
  • Bật Mí Cách Trình Bày Văn Bản Đẹp Trong Excel
  • Cách Viết Bài Essay Agree
  • 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

    --- Bài cũ hơn ---

  • Cách Viết Content Quảng Cáo Facebook Giúp Tăng Đơn Hàng
  • Từ Điển Phương Trình Hóa Học
  • Mẫu Offer Letter Tiếng Anh Chuẩn Nhất
  • Ielts Writing Task 1
  • 07 Bí Quyết Để Viết Kịch Bản Video Quảng Cáo Thành Công
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile

    --- Bài mới hơn ---

  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Viết Unit Test Trong C# Với Nunit
  • Quản lý các yêu cầu và lập kế hoạch dự án thông qua một khái niệm chung về các câu chuyện của người dùng (User stories – US) là mấu chốt của phương pháp phát triển phần mềm Agile. Tập hợp của nhiều US cùng mô tả cho một bức tranh lớn hơn thì có thể được gọi là Epic. Tuy nhiên, những gì thực sự đi vào câu chuyện người dùng phụ thuộc rất nhiều vào bối cảnh nhóm của bạn.

    User Stories giúp việc quản lý và lập kế hoạch trở nên khoa học

    1. User Stories cho một nhóm phân tán theo địa lý

    Mỗi User Story sẽ có 1 hoặc nhiều Acceptance Criteria (AC)

    Điều này có nghĩa là các User stories cần mô tả chi tiết hơn về các yêu cầu chức năng, vì nhà phát triển sẽ không dễ để làm rõ các yêu cầu theo thời gian thực. Nội dung cho mỗi câu chuyện được lưu trữ trên Team Foundation System, có thể vừa trên một trang đơn nhưng hiếm khi vừa trên một thẻ chỉ mục.

    Vì thế, các User stories chứa nhiều thông tin và khá chi tiết, họ đã nhắc ít hơn về cuộc trò chuyện của người dùng so với những người nhắc nhở về những gì chúng tôi đã quyết định và tại sao. Các user stories của người dùng chứa thông tin chi tiết về mọi lĩnh vực trên trang, mọi ngoại lệ và ghi chú về cách doanh nghiệp có thể thấy trang này mở rộng trong các lần lặp lại trong tương lai.

    3. User Stories cho một giải pháp phần mềm dựa trên nền tảng Web

    Các câu chuyện sẽ miêu tả chức năng được yêu cầu

    Trong User story, Business Analyst sẽ đề cập đến giao diện người dùng cụ thể từ bộ khung hoặc đính kèm mô tả giao diện người dùng chi tiết để xác định các trường, quy tắc kinh doanh và quy tắc hiển thị.

    4. User Stories giữ cho sự phát triển đồng bộ với các yêu cầu

    Phương pháp Agile được đánh cao trong thực tiễn

    Tổng thể, phương pháp này đã đạt được những hiệu quả mong muốn. Đội ngũ phát triển phần mềm nhận được các yêu cầu cụ thể để xây dựng, người kiểm thử có các thử nghiệm chấp nhận rõ ràng để xác minh và tổ chức đã hỗ trợ nhiều khía cạnh khác của phương pháp Agile, như lập kế hoạch nước rút.

    Một điểm tích cực mà nhóm có được từ kinh nghiệm Agile này là một nhóm phát triển rất nhỏ với công suất tối thiểu cung cấp một thứ gì đó hoạt động và đáp ứng các yêu cầu, nhất quán và tuần này qua tuần khác. Nhóm đã đạt được động lực mỗi tuần khi họ kiểm tra ngày càng nhiều User stories ra khỏi danh sách, ngay cả khi những user stories mới được phát hiện và thêm vào. Giờ đây, nhóm nghiên cứu đã có thể tập trung vào việc giao hàng, ngay cả khi ở giữa một dự án có quy mô đáng kể có thể dễ dàng áp đảo.

    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:

    Tại Tp.HCM:

    Tại Hà Nội:

    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

    --- Bài cũ hơn ---

  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu
  • Những Điều Cần Biết Khi Viết Thư Cảm Ơn Bằng Tiếng Anh
  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?

    --- Bài mới hơn ---

  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Trong thời gian tới tụi mình sẽ làm series giải thích đưa ví dụ một số khái niệm và techniques BA, đặc biệt là mấy thuật ngữ Business Analysis hay có chữ User làm chúng ta nhức đầu như:

    User Story (US) là một câu chuyện có người dùng, việc cần làmkết quả.

    Các bạn sẽ sử dụng User Story khi tham gia vào một dự án Agile Scrum. User Story giúp tóm tắt nhanh yêu cầu của người dùng về một tính năng của phần mềm và được viết bằng ngôn ngữ kinh doanh, từ góc nhìn của người dùng.

    Epic Story kể một câu chuyện lớn tổng quát, bao gồm nhiều User Story, lớn tương đương khối lượng công việc phải làm trong nhiều đợt hay nhiều sprint. Khi bạn hoàn thành xong Epic Story nghĩa là bạn đã hoàn thành xong tất cả các story con của nó.

    Ví dụ:

    Epic Story

    Là người dùng Foody, tôi muốn biết hiện tại có những chương trình giảm giá nào, để tôi có thể đặt món ăn với giá rẻ hơn, tiết kiệm tiền.

    Theo cách phân tích tâm lý và thói quen hành vì của người dùng, các nhà thiết kế và lập trình ứng dụng Foody sẽ chia ra các mục giảm giá khác nhau để thu hút người dùng qua các story như: giúp thông tin được tổ chức theo đúng mối quan tâm của Foodie.

    Ví dụ User Story thuộc Epic Story

    1. Là người dùng Foody, tôi muốn biết hiện tại ở gần chỗ tôi ở có quán nào giảm giá hay không, để tôi có thể đặt món ăn với giá rẻ hơn, tiết kiệm tiền ship và đồ ăn nóng hổi.

    2. Là người dùng Foody, tôi muốn biết các quán nào có chương trình giảm giá được cộng đồng thích nhất, để tôi có thể đặt món ngon hot với giá rẻ.

    3. Là người dùng Foody, tôi muốn biết quán ăn nào đang có chương trình giảm giá mạnh nhất, để tôi có thể đặt món với chi phí tiết kiệm nhất.

    Trên lý thuyết, Scrum Member nào cũng có thể tham gia hoàn thiện User Story.

    Còn ở các dự án in-house hay Start-up, đôi khi bạn sẽ thấy có Developer tham gia viết luôn (vì thiếu người hoặc họ phải kiêm vai trò, hoặc đơn giản họ muốn giúp đỡ BA đẹp trai, đẹp gái, tốt tính các kiểu).

    1. Dễ đọc, dễ hiểu với người dùng và cả stakeholders
    2. I-Independent: Có thể triển khai độc lấp
    3. V-Valuable: Có giá trị rõ ràng cho người dùng cuối
    4. E-Estimatable: Đôi ngũ lập trình có thể hiểu rõ, chia task để ước lượng được độ phức tạp
    5. S-Small: Story nhỏ vừa đủ, thường phải hoàn thành được trong vài ngày (max 40 giờ làm việc)
    6. T-Testable: Kiểm thử được

    Các bạn hãy theo dõi các kênh chia sẻ về nghề BA, PO của Khang & Mia

    Cám ơn các bạn!

    --- Bài cũ hơn ---

  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu
  • Những Điều Cần Biết Khi Viết Thư Cảm Ơn Bằng Tiếng Anh
  • 6 Mẫu Thư Cảm Ơn Thông Dụng Nhất
  • Cách Viết Một Bài Thơ Tình Yêu Hay Ngắn Đơn Giản Nhất
  • Hướng Dẫn Viết Các Nét Cơ Bản Thư Pháp Bút Lông Âu Khải
  • User Story Là Gì? User Story Mẫu Và Nguyên Tắc Ứng Dụng Trong Agile

    --- Bài mới hơn ---

  • Unit Test Là Gì? Khái Niệm Và Vai Trò
  • Business Analyst Cần Học Gì: Chuyên Nghiệp Khi Viết Hướng Dẫn Sử Dụng
  • Dịch Thuật Sách Hướng Dẫn Sử Dụng (User Manual / User Guide) Chuẩn
  • Unit Test Với Junit 4X
  • Nhập Môn Unit Testing Trong .net
  • 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

    --- Bài cũ hơn ---

  • 20+ Mẫu Thư Cảm Ơn Nhà Tài Trợ, Khách Hàng, Quý Đối Tác Chi Tiết Nhất
  • Tổng Hợp Nét Cơ Bản, Bảng Chữ Cái Thư Pháp Việt Đẹp
  • Cách Viết Mở Đầu Ăn Điểm Cho Bài Writing Trong Ielts
  • Cách Viết Thêm Số 0 Vào Đầu, Viết Số Điện Thoại Trong Excel Mọi Phiên Bản.
  • Cách Viết Sơ Yếu Lý Lịch Theo Đúng Tiêu Chuẩn
  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu

    --- Bài mới hơn ---

  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • User stories là một phần của phương pháp Agile giúp dịch chuyển từ việc viết về yêu cầu sang kể về yêu cầu. Các user stories theo phương pháp agile sẽ là một hoặc hai câu hoặc một chuỗi câu đối thoại về chức năng mong muốn.

    User stories là gì?

    User stories là những mô tả ngắn gọn, đơn giản về một feature và được kể từ cách nhìn của nhóm người dùng (user hoặc customer của phần mềm) muốn có feature đó. Một cách điển hình user stories có dạng:

    Ví dụ về user story

    Một ích lợi của user stories là chúng có thể được viết ra theo những mức độ chi tiết khác nhau. Người ta thậm chí có thể viết chỉ một user story chứa đựng cả một lượng lớn các chức năng. Kiểu user story này được gọi là Epic. Chẳng hạn đây là một ví dụ về epic của một phần mềm sao lưu dành cho máy trạm:

    “Với tư cách một người dùng, tôi có thể sao lưu toàn bộ ổ cứng laptop của tôi”

    Bởi vì một epic thường quá to để một agile team có thể hoàn thành trong vòng một iteration, nó sẽ được chia nhỏ thành nhiều user stories con trước khi agile team bắt tay thực hiện epic. Khái quát thì epic có thể chia thành mươi mười lăm user stories con, hoặc thậm chí cả trăm. Ví dụ epic nói trên bao gồm 2 user stories con như sau:

    “Với tư cách một power user, tôi có thể chỉ ra các file hoặc folder sẽ được sao lưu, căn cứ theo kích thước file, ngày tạo và ngày sửa đổi”

    “Với tư cách một user tôi có thể chỉ ra các folder không cần sao lưu để ổ đích sao lưu của tôi khỏi bị chiếm chỗ bởi những thư mục tôi không cần sao lưu”

    Cách thêm chi tiết vào một user story

    Chi tiết có thể được thêm vào user story theo hai cách

    • Bằng cách chia nhỏ thành nhiều user story con
    • Bằng cách thêm các điều kiện cần thỏa mãn

    Khi chia nhỏ một user story lớn thành nhiều user story con thì rõ ràng là chi tiết đã được thêm vào. Bạn đã phải viết nhiều hơn về user story đó.

    Các điều kiện cần thỏa mãn thì đơn giản một dạng viết tiêu chí nghiệm thu ở high-level (high-level acceptance test) đối với user story đó.

    Hãy xét ví dụ sau đây:

    “Với tư cách một phó chủ tịch Marketing, tôi muốn chọn ra kỳ nghỉ lễ để sử dụng khi review kết quả của các chiến dịch marketing trong quá khứ để tôi có thể nhận biết đâu là kỳ nghỉ lễ sinh lợi nhất đối với chiến dịch”

    Chi tiết được thêm vào user story nói trên nếu chỉ rõ điều kiện cần thỏa mãn là

    “Danh sách các kỳ nghỉ lễ có thể chọn là bao gồm Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.” Hoặc

    “Hỗ trợ các kỳ nghỉ lễ bắc qua 2 năm”. Hoặc

    “Có thể chọn ra số ngày cụ thể trước một ngày nghỉ lễ”

    Ai viết user stories?

    Bất kỳ ai cũng có thể viết user stories. Product Owner là người chịu trách nhiệm bảo đảm rằng phải tồn tại một Product backlog bao gồm các user stories, nhưng không nhất thiết phải trực tiếp viết ra các user stories. Với một Development Team đã có kinh nghiệm làm tốt một dự án agile thì người ta có thể kỳ vọng mỗi một thành viên của team đều có năng lực viết user stories.

    Khi nào thì viết user stories?

    Các user stories được viết ra trong suốt vòng đời của một dự án agile. Thường thường sẽ có một workshop để viết user stories trước khi sắp bắt đầu dự án. Mọi người trong team cùng tham gia với mục tiêu tạo ra một product backlog mô tả đầy đủ các chức năng sẽ được phát triển dần trong cả vòng đời dự án hoặc các chức năng sẽ được release trong vòng từ 3 đến 6 tháng sắp tới.

    Hiển nhiên sẽ có những user stories lớn, đích thị là các epic. Thì sau này các epic sẽ cần được phân rã nhỏ hơn thành các user stories con mà có thể hoàn thành chỉ trong một iteration. Ngoài ra cũng sẽ có những user stories mới được thêm vào.

    Liệu user stories có thể thay cho tài liệu phát biểu yêu cầu?

    Các dự án agile, nhất là dự án theo phương pháp Scrum, sử dụng một Product backlog, tức là một danh sách các chức năng được sắp xếp theo thứ tự ưu tiên cần được phát triển khi xây dựng sản phẩm phần mềm. Mặc dù Product backlog thực tế bao gồm bất cứ item nào mà team muốn đưa vào, nhưng về cơ bản các user stories là hình thức phổ biến nhất và tốt nhất của các item trong Product backlog.

    Theo Mike Cohn

    User Stories

    --- Bài cũ hơn ---

  • Những Điều Cần Biết Khi Viết Thư Cảm Ơn Bằng Tiếng Anh
  • 6 Mẫu Thư Cảm Ơn Thông Dụng Nhất
  • Cách Viết Một Bài Thơ Tình Yêu Hay Ngắn Đơn Giản Nhất
  • Hướng Dẫn Viết Các Nét Cơ Bản Thư Pháp Bút Lông Âu Khải
  • Cách Luyện Viết Chữ Thư Pháp Đẹp
  • Để Tạo Ra Những User Story Tốt Nhất

    --- Bài mới hơn ---

  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • User story là gì?

    User story là một câu chuyện có người dùng, hành động và kết quả. Nó thường được mô tả theo cấu trúc sau:

    Là một để tôi có thể [nhận được một kết quả nào đó]

    Trong bài viết này, tôi sẽ sử dụng những ví dụ về một công ty tưởng tượng có tên là Enable Quiz. Công ty này đang xây dựng một ứng dụng giúp cho các quản lý nhân sự tìm kiếm các ứng viên dựa trên những kỹ năng cụ thể tương ứng với một bản mô tả công việc.

    Ví dụ cho user story:

    epic story mô tả một câu chuyện tổng quát. Epic story này sẽ bao gồm nhiều user story, mỗi user story sẽ thực hiện một chức năng riêng biệt. Mỗi user story sẽ có nhiều test case để kiểm tra chúng

    Ví dụ cho epic story:

    Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên

    Những thứ cần có để xây dựng user story

    Người dùng là ai?

    Nếu bạn không xác định rõ người dùng sản phẩm là ai thì sẽ rất khó để xây dựng user story. Và có thể bạn sẽ gặp phải lỗi the twin anti-poles of design failure:

    • Nếu bạn làm chính xác những gì người dùng yêu cầu, thì cuối cùng bạn sẽ rơi vào vòng lặp vô tận Product Death Cycle :
      1. hỏi khách hàng chức năng nào đang thiếu
      2. xây dựng những chức năng thiếu
      3. không ai sử dụng sản phẩm của bạn
      4. cuối cùng lại quay trở lại 1
    • Nếu bạn cho rằng mình biết rõ người dùng muốn gì, cuối cùng thì cũng không ai sử dụng sản phẩm của bạn
    • Cô ấy nghĩ như thế nào về các mọi thứ vận động hàng ngày?
    • Cô ấy muốn trở thành người như thế nào?
    • Cô ấy nhìn thấy người khác làm những gì, và điều đó ảnh hưởng đến quan điểm của cô ấy như thế nào?
    • Cô ấy cảm nhận như thế nào về công việc của mình?
    • Cô ấy thực sự đang làm gì trong lĩnh vực nghiệp vụ mà phần mềm của bạn sẽ đụng chạm tới nó?

    Nếu thật sự hiểu người dùng nghĩ – nhìn thấy – cảm nhận – làm những gì, bạn sẽ tìm ra được nhiều user story.

    Người dùng muốn gì?

    Hãy xây dựng một tình huống để mô tả cái mà người dùng muốn làm. Nó phải tương đối tổng quát để có thể tương đương với nhiều tình huống khác.

    Ví dụ

    • Tình huống Tìm kiếm các tài năng kỹ thuật tương đương với đọc các CV hay là gọi điện cho các ứng viên. Vì vậy mà tình huống này sẽ xây dựng được những user story tốt
    • Tình huống Thuê được những tài năng kỹ thuật thì quá rộng
    • Các tình huống chi tiết hơn như Người quản lý nhân sự chuẩn bị một quiz cho một vị trí cần tuyển hoặc Người quản lý nhân sự gửi những ghi chú về các ứng viên cho một nhân viên HR khác thì quá chi tiết

    Để thiết kế những user story tốt hơn

    User story nên có mức độ chi tiết như thế nào là đủ?

    Các user story nên chi tiết, mô tả hành động cụ thể, có thể test được và gắn liền với các tình huống

    Ví dụ

    • User story Tôi muốn tìm kiếm các ứng viên kỹ thuật để công ty của tôi có thể thu được lợi ích tuyển dụng cao nhất thì quá rộng và không thể test được trực tiếp
    • Với tình huống Tìm kiếm các tài năng kỹ thuật thì user story Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật để tôi có thể biết được những kỹ năng của họ là cụ thể hơn, có thể test được

    Để tìm kiếm được hết các user story của một epic story, bạn nên sử dụng các storyboard. Đây là một công cụ bao gồm những hình ảnh với người dùng, hành động và bối cảnh. Nó mô tả epic story theo cách của một câu truyện tranh

    Ví dụ với epic story Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên

    Kết quả phải có thể test được, và là những gì người dùng muốn nhận được khi họ thực hiện hành động. Ví dụ với user story ở trên Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật thì kết quả biết được những kỹ năng của các ứng viên có thể test được, nhưng nó không phải là kết quả mong muốn của Helen. Không phải ngẫu nhiên mà Helen tìm kiếm các ứng viên kỹ thuật, mà thường đó là do yêu cầu từ các phòng ban khác. Vì vậy mà kết quả có thể sử dụng thông tin các ứng viên khi phỏng vấn họ mới là cái mà Helen cần.

    Test các User Story

    Cần phải test những gì?

    Việc test các user story không phải là kiểm tra với hành động của người dùng, họ có thu được kết quả đúng như trong user story hay không. Mà việc test các user story là kiểm tra xem họ có muốn thực hiện hành động trong user story hay không?

    Vì thế mà bạn nên sử dụng công cụ BJ Fogg’s curve để mô tả nó:

    • Đưa ra một sự phân biệt rõ ràng giữa động cơ (motivation) thôi thúc người dùng sử dụng chức năng gắn với user story và tính dễ dùng (usability) của chức năng đó
    • Hiểu được mối quan hệ giữa động cơ và tính dễ dùng: nếu người dùng thật sự cần dùng ứng dụng của bạn thì cho dù nó có khó dùng đi nữa họ vẫn sẽ dùng. Còn nếu họ không cần dùng nó (ví dụ như trong trường hợp ứng dụng của bạn có nhiều đối thủ cạnh tranh) thì bạn phải cố gắng làm tăng tính dễ dùng của chức năng để lôi kéo họ

    Test như thế nào?

    Việc test các story nên được chia thành các giai đoạn (phase), mỗi giai đoạn bao gồm nhiều vòng lặp thiết kế (design)- xây dựng nguyên mẫu (prototype) – kiểm thử (test).

    Khi nào story kết thúc?

    Để trả lời câu hỏi này, cần phải hiểu rằng bạn không thể dự đoán được cái gì là có giá trị với người dùng. Do đó, bạn cần phải có những ý tưởng mà có thể test được và kiểm chứng nó bằng những thử nghiệm.

    Trong trường hợp lý tưởng, story của bạn bắt đầu bằng việc quan sát người dùng và những vấn đề họ gặp phải. Sau đó bạn đưa ra 1 mô hình để đo lường được tính hữu ích của giải pháp của bạn.

    Phát triển ứng dụng với user story và story map

    Ai viết các user story?

    Vì user story là một khái niệm của Agile, nên người viết các user story tất nhiên sẽ là PO (Product Owner). Nhưng bạn hãy chú ý vài vấn đề sau:

    • 1/40: theo một nghiên cứu của Stanford, mọi người chỉ hiểu 1/40 những gì bạn đã nói. Vì vậy nếu như PO đưa user story lên JIRA hay trello và cho rằng mọi thành viên đội phát triển đã hiểu, thì sớm muộn sẽ có hiểu nhầm.
    • Chúng ta đo hiệu suất của chính mình theo cách chủ quan: Bản chất của con người chỉ muốn biết đủ mức để giải quyết công việc của họ, và muốn biết rõ mình đã làm được đến đâu. Họ luôn muốn sự chắc chắn và cảm thức lập tức về sự hoàn thành. Nhưng làm phần mềm thì không như thế. Nếu bạn không hợp tác với đội phát triển để xây dựng lên các user story, họ sẽ cảm thấy mình không phải chịu trách nhiệm về nội dung của user story và không cần thiết phải suy nghĩ về tính khả dụng, tính thực tiễn của user story đó. Họ chỉ nghĩ rằng công việc của mình là biến user story đó thành chức năng chạy được.

    Sử dụng story trong nội bộ team như thế nào?

    Chúng ta nên sử dụng story map, một công cụ giúp kết nối các story trong một epic với nhau và làm cho chúng trở nên trực quan với team phát triển.

    Dải đầu tiên (stripe 0) là trục x của story map, mô tả các hành động của người dùng theo thời gian trong một epic story. Nó nên được mô tả bằng các hình ảnh lấy từ storyboard. Trục y mô tả thứ tự ưu tiên của các user story, như trong hình vẽ thì các user story trong dải 1(stripe 1) có độ ưu tiên thực hiện cao hơn dải 2 (stripe 2).

    Sử dụng story hàng ngày như thế nào?

    Để user story trở nên thân thiện dễ dùng, thì nó nên tuân theo quy tắc INVEST: Độc lập (Independent), Có thể trao đổi(Negotiable), Hữu ích (Valuable), Có thể ước lượng (Estimable), Nhỏ (Small), và Có thể kiểm chứng được (Testable).

    • Independent: các user story phải độc lập không phụ thuộc vào nhau. mỗi story đều có thể triển khai độc lập.
    • Negotiable: user story không phải là các yêu cầu bắt buộc phải tuân theo chính xác, mà nó có thể bị thay đổi cho phù hợp
    • Valuable: mỗi user story phải đem lại giá trị gì đó cho người dùng
    • Estimable: có thể ước lượng được độ lớn của user story (ví dụ cần bao nhiêu man day hoặc bao nhiêu point)
    • Small: user story nên đủ nhỏ để có thể đưa vào hệ thống, và dễ dàng thực hiện kiểm thử tích hợp (incremental integration testing)
    • Testable: người viết ra user story nên viết ra các test case cho nó.

    --- Bài cũ hơn ---

  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu
  • Những Điều Cần Biết Khi Viết Thư Cảm Ơn Bằng Tiếng Anh
  • 6 Mẫu Thư Cảm Ơn Thông Dụng Nhất
  • Cách Viết Một Bài Thơ Tình Yêu Hay Ngắn Đơn Giản Nhất
  • User Story Là Gì Và Tiêu Chí Chấp Nhận

    --- Bài mới hơn ---

  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story
  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • 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ài cũ hơn ---

  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu
  • Những Điều Cần Biết Khi Viết Thư Cảm Ơn Bằng Tiếng Anh
  • 6 Mẫu Thư Cảm Ơn Thông Dụng Nhất
  • Nhóm Tài Liệu Cho Ba: User Story, Use Case Và Functional Specification Document

    --- Bài mới hơn ---

  • 14 Mẹo Để Viết Requirement Tốt Hơn
  • Trích Dẫn Và Lập Danh Mục Tài Liệu Tham Khảo Theo Chuẩn Chicago
  • Cách Tạo Danh Mục Tài Liệu Tham Khảo Có Trích Dẫn Trong Microsoft Word
  • Cách Viết Email (Phần 1)
  • Cách Viết Email Rõ Ràng Và Chuyên Nghiệp
  • 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:

    --- Bài cũ hơn ---

  • Process Documentation: Ý Nghĩa Và Cách Để Viết Tài Liệu Mô Tả Quy Trình
  • 7 Quy Tắc Viết Chữ Hán Trong Tiếng Trung Chuẩn, Đẹp, Nhanh
  • 5 Cách Viết Chữ Kiểu Trên Facebook Độc Đáo 2022
  • Cover Letter Là Gì? Những Cách Viết Cover Letter Chuyên Nghiệp Mẫu
  • 8 Cover Letter Để Đọc Thử Nếu Chưa Biết Viết Như Thế Nào
  • Làm Sao Để Mô Tả Phần Lợi Ích (Why) Trong User Story

    --- Bài mới hơn ---

  • Unit Test Là Gì? Giới Thiệu Về Unit Test Và Ví Dụ
  • Unit Test Dùng Để Làm Gì Và Kinh Nghiệm Viết Unit Test Tốt Nhất
  • Hướng Dẫn Viết Unit Test Cho Laravel (P2)
  • Viết Unit Test Trong C# Với Nunit
  • Unit Test Cho Nodejs Với Mocha
  • Như đã giải thích User Story là gì? Trong Agile, User Story được coi là một công cụ lõi quan trọng để truyền tải giá trị giữa người dùng và đội phát triển sản phẩm, công việc nói chung chỉ được coi là tốt chỉ khi người dùng nhận được đúng giá trị, lợi ích mà họ thực sự mong muốn. Tuy nhiên việc nêu ra và thấu hiểu được giá trị – lợi ích của user story là một việc khó khăn đối với người dùng, product owner và đội phát triển.

    Hãy khám phá xem các biểu hiện, nguyên nhân và cách khắc phục vấn đề trên.

    1. User story thể hiện giá trị như thế nào?

    Một user story được cấu trúc ngắn gọn thành một câu mô tả:

    “Là sinh viên tôi muốn nhìn thấy điểm số các môn học của tôi trên một màn hình”

    User story trên chưa nêu được lợi ích của việc nhìn thấy điểm số môn học để làm gì, cần phải khảo sát người dùng kỹ hơn mong muốn của họ, có thể là một hoặc nhiều lợi ích sau:

    • “để anh ta lên kế hoạch học tập khắc phục các môn còn chưa đủ điểm”
    • “để anh ta biết được thứ hạng trong trường để có động lực ganh đua xếp hạng nhận học bổng”
    • “để anh ta có thể nộp bảng điểm khi đi xin việc”
    • “để anh ta được động viên khi nhìn thấy sự tiến bộ trong học tập của mình”

    2. Các nhầm lẫn phổ biến khi mô tả giá trị của user story.

    Khi viết phần mô tả lợi ích – giá trị, thường rất khó khăn và hay gặp nhầm lẫn do sự hiểu nhầm của tất cả các bên, bao gồm của Product Owner và Stake Holder. Hãy xem thử các loại nhầm lẫn sau:

    • Nhầm lẫn tính năng và giá trị: Ví dụ: “Là thu ngân tại cửa hàng tôi muốn nhìn tổng số tiền khách phải thanh toán để báo khách biết số tiền phải thanh toán”. Ta vẫn hiểu số tièn phải báo cho khách để thanh toán tại quầy là tính năng đương nhiên, nhưng tại sao việc nhìn thấy số tiền này lại là quan trọng? Đầy đủ hơn phải hiểu rằng điều này giúp thu ngân thông báo ngay số tiền khách phải thanh toán mà không phải mất công tìm xem con số nó nằm lẩn khuấn đâu trên màn hình, điều mà khách hàng quan tâm nhất và đầu tiên khi thanh toán.
    • Mô tả giá trị chung chung: “Là 1 vận động viên marathon, tôi muốn nhận thông tin nhịp tim để không gặp vấn đề về tim”. Tất nhiên giá trị user story này giúp vận động viên nhận biết vấn đề về tim nhưng cần cụ thẻ hơn là vấn đề gì. Trái tim có thể gặp rất nhiều vấn đề khác nhau cần phải bóc tách ra phân tích và có phương án phù hợp, đó có thể là vấn đề bệnh lý, vấn đề quá sức hoặc vấn đề nhịp tim không đúng theo bài tập chuyên môn. Mỗi loại vấn đề trên có thể lại có mức nghiêm trọng khác nhau nên nếu chỉ ghi chung chung sẽ khó xử lý vì có vấn đề có thể dẫn đến chết người trên đường đua, có vấn đề ít nghiêm trọng hơn chỉ ảnh hưởng đến kết quả luyện tập.
    • Mô tả lòng vòng: “Là phi công tôi muốn biết độ cao máy bay để tôi biết mình đang ở độ cao nào”. Như vậy phần giá trị để biết độ cao là một mô tả lòng vòng lặp lại đúng với phần tính năng.
    • Mô tả cái tất yếu: “Là quản lý tôi muốn có web site thương mại để tăng doanh thu”. Tăng doanh thu là một giá trị tất yếu của doanh nghiệp, nên nếu giá trị chỉ nêu vậy thì rất chung chung, cần cụ thể hơn, ví dụ có thể sẽ phát biểu là “để mở thêm kênh bán hàng mới với khách hàng mới nhằm tăng doanh thu”. Khi xác định rõ giá trị như vậy thì khi thiết lập một website thương mại cần phải tiếp cận khách hàng mới và tăng doanh thu thay vì tiếp cận khách hàng cũ và tăng thêm doanh thu từ khách hàng này, hai giá trị như vậy sẽ tạo ra hai cách tiếp cận khác nhau.

    3. Tác hại khi nhầm lẫn giá trị.

    Khi không xác định chính xác giá trị sẽ dẫn đến việc thiết kế các tính năng vừa thừa vừa thiếu để đáp ứng thỏa mãn nhu cầu thực sự của người dùng. Phần lớn người sử dụng khi đến với chúng ta hay phát biểu yêu cầu dưới dạng các tính năng mà không chỉ ra được giá trị lợi ích thực sự họ mong muốn là gì, nếu Product Owner chủ quan không đánh giá kỹ mà cho phát triển sản phẩm y hệt như những gì người dùng mô tả thì tất yếu sau khi làm xong họ sẽ cảm thấy đó không phải thực sự là cái họ muốn vì không thực sự giải quyết vấn đề của họ, tất yếu dẫn đến các yêu cầu thay đổi tiếp theo dẫn đến thiệt hại về công sức cho cả đội phát triển và người dùng.

    Vấn đề thay đổi yêu cầu còn tạo ra các mâu thuẫn phát sinh khi đội phát triển quy kết và tranh cãi đổ lỗi người dùng thay đổi yêu cầu, product owner thì đau đầu khi vừa lo giữ chân khách hàng vừa lo đội phát triển đình công, còn khách hàng thì mãi vẫn không thể dùng được sản phẩm. Kết quả cuối cùng là dự án đổ bể trong mâu thuẫn đầy tranh cãi, tất cả các bên cùng thua.

    Ví dụ quay lại với user story đầu tiên

    Là sinh viên tôi muốn nhìn thấy điểm số các môn học của tôi trên một màn hình

    Khi không xác định được giá trị chính xác, mặc định đầu tiên đội làm sản phẩm sẽ máy móc theo yêu cầu người dùng là làm một chức năng liệt kê điểm số tất cả các môn học và ghi nhận là hoàn thành.

    Khi tiếp nhận sản phẩm, nếu sâu trong tâm trí người dùng là “để anh ta lên kế hoạch học tập khắc phục các môn còn chưa đủ điểm” thì sẽ không thấy hài lòng với chức năng trên, anh ta sẽ đòi hỏi thêm các yêu cầu khác như bôi đỏ phần điểm dưới trung bình. Lúc này mâu thuẫn thay đổi yêu cầu phát sinh.

    Sau khi đội phát triển bổ sung yêu cầu trên, anh ta thấy rằng việc bôi đỏ điểm kém không giúp ích đủ cho việc lên kế hoạch, anh ta sẽ đòi hỏi thêm việc hiển thị số tín chỉ của mỗi môn, và vẫn tuyên bố rằng sản phẩm không đáp ứng đúng mong muốn của anh ta.

    Sau đó anh ta thấy rằng vẫn khó lên kế hoạch nên sẽ thêm yêu cầu sắp xếp thứ tự ưu tiên môn gì cần khắc phục ôn tập và thi lại trước phải được đưa lên đầu.

    Như vậy mâu thuẫn “thay đổi yêu cầu” đã xảy ra liên tiếp 3 lần chỉ trên 1 tính năng đơn giản, trong khi mâu thuẫn này sẽ được lường trước hơn nếu product owner và người dùng cùng phân tích kỹ mục đích thực sự của user story này, từ đó phân tích tiếp hiểu được cách mà sinh viên lên kế hoạch học tập như thế nào rồi từ đó mới bắt tay vào phát triển tính năng phù hợp.

    4. Có những loại giá trị nào.

    • Lợi ích tài chính: tăng doanh thu, tiết kiệm chi phí, tăng dòng tiền, tăng lợi nhuận.
    • Lợi ích phi tài chính: thỏa mãn khách hàng, gắn kết nhân viên, giảm rủi ro, thương hiệu và hình ảnh công ty, tăng cường chất lượng sản phẩm và dịch vụ

    Để dễ xác định giá trị – lợi ích của các user story, cần thực hiện phân loại và liệt kê các mẫu giá trị hay gặp.

    • Tăng trưởng: doanh thu, thêm khách hàng, thêm nhân viên.
    • Tiết kiệm: tiền bạc, công sức, thời gian, nhân sự.
    • Chủ động: ước đoán tình hình để lên kế hoạch và phương án, ra quyết định.
    • Gắn kết: động viên nhân viên, giữ chân khách hàng.
    • Kiểm soát: điều chỉnh tối ưu, tránh mất mát, tránh thất thoát, tránh lãng phí.
    • Tránh rủi ro: tuân thủ pháp luật, theo dõi ngưỡng tử thần.
    • Ra quyết định: nắm bắt thông tin, phân tích số liệu đã ra quyết định.

    Theo phân loại như trên, ta có các hình mẫu giá trị hay gặp như sau:

    • “Là người dùng thẻ tín dụng, tôi muốn được thông báo nếu có hoạt động chi tiêu để biết ngay có người lén dùng thẻ ăn cắp tiền của tôi để tôi khóa thẻ ngay tránh mất tiền”
    • “Là marketing tôi muốn khách hàng được cộng điểm thưởng khi giới thiệu website bán hàng của tôi đến bạn bè để khuyến khích phát triển thêm khách hàng mới.”
    • “Là quản lý kho tôi muốn thấy vận tốc bán và dự đoán tồn kho để ra quyết định nhập kho kịp thời nhằm không bị thiếu hàng gây mất cơ hội kinh doanh”

    Xét các ví dụ sau:

    5. Giá trị quyết định phương án thiết kế.

    Như vậy khi xác định rõ ý nghĩa, giá trị lợi ích của người dùng trong một user story, đội phát triển có thể chủ động phương án thiết kế tính năng một cách thực dụng nhất và nhanh nhất đáp ứng trực tiếp và chính xác điều mà họ cần. Các tính năng thừa không phục vụ lợi ích cho user story được loại bỏ không đưa vào phát triển nhờ đó tránh lãng phí cũng như hạn chế thay đổi yêu cầu.

    • “Là người mù tôi muốn có thiết bị cảnh báo vật cản để giúp tôi không bị tai nạn”. Khi nắm rõ mục đích này, phương án thiết kết sản phẩm sẽ phải tính toán cụ thể cảnh báo từ khoảng cách tối thiểu bao nhiêu là hợp lý nhằm tránh gây tai nạn, vì nếu cảnh báo muộn thì người mù sẽ không kịp tránh vật cản; từ đó xem xét năng lực công nghệ về thiết bị, phần cứng và cảm biến có cho phép phát hiện vật cảnh từ khoảng cách tối không.
    • “Là thu ngân tại cửa hàng tôi muốn nhìn tổng số tiền khách phải thanh toán để trả lời luôn số tiền khách phải thanh toán nhằm tiết kiệm thời gian phục vụ”. Như vậy tổng số tiền khách phải thanh toán tốt nhất nên hiện to và rõ ràng trên màn hình thay vì xuất hiện nhỏ bé lẩn khuấn đâu đó khiến thu ngân phải cuộn màn hình tìm số tiền rồi đọc cho khách, thậm chí có siêu thị tại máy tính tiền còn có màn hình số hiển thị số tiền riêng quay sang cho khách hàng nhìn thấy.
    • “Là sinh viên tôi muốn nhìn thấy điểm số các môn học của tôi trên một màn hình để biết được thứ hạng trong trường để có kế hoạch ganh đua”. Với giá trị này cần thiết kế hiển thị tổng điểm, thứ hạng của sinh viên so với các sinh viên khác hơn là hiển thị số điểm của từng môn học. Như vậy nắm rõ giá trị sẽ giúp tránh phương án thiết kế sai lầm.
    • “Là sinh viên tôi muốn nhìn thấy điểm số các môn học của tôi trên một màn hình để có thể nộp bảng điểm khi đi xin việc”. Với giá trị này thì phương án thiết kế cần 1 bảng điểm có khả năng in ra theo hình thức đẹp hoặc có thể gửi online với link truy cập công khai thay vì bắt phía nhà tuyển dụng phải đăng nhập.

    Ví dụ:

    6. Kết luận:

    Như vậy việc hiểu thấu và nêu đúng giá trị và lợi ích mà người sử dụng mong muốn sẽ giúp người làm sản phẩm dịch vụ quyết định phương án thiết kế và tiếp cận một cách hợp lý, đem lại giá trị cao nhất với chi phí thấp nhất.

    Vấn đề tiếp theo đặt ra là, khi người dùng đến với các yêu cầu chức năng mà chưa nêu được giá trị họ mong muốn một cách rõ ràng thì phải làm thế nào để khám phá được lợi ích thật sự mà họ mong muốn.

    Tuyển dụng Product Owner: Định hình hướng đi của giải pháp bán lẻ quốc tế. Môi trường làm việc từ xa, quản lý linh hoạt theo Agile

    --- Bài cũ hơn ---

  • Cách Viết User Stories: Trải Nghiệm Phương Pháp Agile
  • User Story Là Gì Và Tiêu Chí Chấp Nhận
  • Để Tạo Ra Những User Story Tốt Nhất
  • User Story Là Gì? Ví Dụ? Cách Viết Tốt Nhất?
  • Hướng Dẫn Viết User Stories Và Các Ví Dụ Mẫu
  • Dịch Thuật Sách Hướng Dẫn Sử Dụng (User Manual / User Guide) Chuẩn

    --- Bài mới hơn ---

  • Unit Test Với Junit 4X
  • Nhập Môn Unit Testing Trong .net
  • 8 Cách Trình Bày Văn Bản Trong Word Giúp Văn Bản Đẹp Hơn
  • Et Cetera (Etc.), And So On, And So Forth… In Ielts Writing
  • Bí Kíp Viết Đoạn Văn Bằng Tiếng Anh
  • Dịch Thuật Phương Đông ” Dịch Thuật ” Dịch thuật sách hướng dẫn sử dụng máy móc thiết bị (User Manual)

    Dịch vụ dịch sách hướng dẫn sử dụng (user manual, user guide) chính xác cho nhiều loại tài liệu bao gồm tài liệu kỹ thuật, phần mềm và sản phẩm được sản xuất sang 50+ ngôn ngữ như tiếng Anh, tiếng Nhật, tiếng Hàn, tiếng Trung,… Chúng tôi giúp các công ty cung cấp thông tin kỹ thuật trên các ngôn ngữ với chất lượng cao và tốc độ nhanh nhất. Liên hệ với chúng tôi để được tư vấn miễn phí ngay bây giờ.

    Dịch vụ dịch thuật tài liệu hướng dẫn sử dụng máy móc thiết bị chính xác

    Là công ty dịch thuật chuyên nghiệp, Dịch Thuật Phương Đông cung cấp dịch vụ dịch thuật tài liệu hướng dẫn sử dụng chất lượng cao cho nhiều hệ thống kỹ thuật và sản phẩm kỹ thuật như máy công nghiệp, ô tô – xe máy, thiết bị ngoại vi máy tính, thiết bị gia dụng, thiết bị y tế, thiết bị điện – điện tử, và các ứng dụng phần mềm.

    Chúng tôi có các tài nguyên ngôn ngữ, đội ngũ các dịch giả chuyên nghiệp, giàu kinh nghiệm am hiểu kỹ thuật cho phép Dịch Thuật Phương Đông liên tục cung cấp các bản dịch kỹ thuật chất lượng cao cho tất cả các lĩnh vực công nghiệp.

    Chúng tôi hiểu tầm quan trọng của việc truyền đạt chính xác thông tin kỹ thuật cao qua các ngôn ngữ cho khách hàng của chúng tôi. Đối với mỗi tài liệu hướng dẫn sử dụng, chúng tôi luôn chọn các biên dịch viên tốt nhất với chuyên môn phù hợp với chuyên ngành để đạt được độ chính xác kỹ thuật cao nhất ngay lần đầu tiên.

    Quy trình dịch thuật tài liệu hướng dẫn sử dụng

    Để tạo thuận lợi cho khách hàng, chúng tôi đã đơn giản hóa quy trình chỉ với 3 bước đơn giản. Để có được bản dịch thuật hướng dẫn sử dụng (User Manual) sang tiếng Anh, tiếng Nhật, tiếng Hàn, tiếng Trung hoặc từ các ngôn ngữ khác sang tiếng Việt, bạn chỉ cần gửi cho chúng tôi File tài liệu cần dịch (PDF, Word, Excel, Powerpoint, InDesign, AI,…). Các chuyên viên tư vấn của chúng tôi sẽ phối hợp với biên dịch viên để phân tích, lập kế hoạch và tạo báo giá dịch tài liệu cho bạn.

    Sau khi bạn xác nhận dịch, chúng tôi sẽ chọn các biên dịch viên phù hợp với chuyên ngành của bạn để lập tức bắt tay vào dịch tài liệu của bạn theo đúng kế hoạch đã đặt ra.

    Dịch thuật tất cả các định dạng của tài liệu hướng dẫn sử dụng

    Các giải pháp dịch thuật của Phương Đông cho phép các biên dịch viên dịch thuật các văn bản trong khi vẫn giữ được bố cục của thiết kế ban đầu của tài liệu. Với 08+ kinh nghiệm trong ngành dịch thuật, chúng tôi là sự lựa chọn hàng đầu khi bạn cần dịch thuật tài liệu hướng dẫn sử dụng (User Manual) sang các ngôn ngữ như: Dịch thuật tiếng Anh, dịch thuật tiếng Nhật, dịch thuật tiếng Hàn, dịch thuật tiếng Trung, dịch thuật tiếng Nga, tiếng Đức.

    Dịch thuật sách hướng dẫn sử dụng ngành sản xuất công nghiệp

    Ngành công nghiệp sản xuất là một trong những ngành phụ thuộc nhiều vào dịch thuật. Các sản phẩm được sản xuất ra như công cụ máy móc, thiết bị, phương tiện, thiết bị ngoại vi máy tính,… phải được kèm theo hướng dẫn sử dụng bằng ngôn ngữ của khách hàng để đảm bảo các quy trình vận hành được an toàn và tuân thủ nghiệm ngặt để đạt được trải nghiệm tốt nhất của khách hàng.

    Đây cũng chính là lý do tại sao bạn cần tới công ty dịch thuật như Phương Đông, vì chúng tôi có các giải pháp ngôn ngữ toàn diện từ A-Z để cung cấp dịch vụ dịch thuật hướng dẫn sử dụng tốt nhất với 50+ ngôn ngữ.

    Cho dù bạn cần hướng dẫn sử dụng nhanh (Quick Start Guide) hay hướng dẫn sử dụng của nhà sản xuất bằng tiếng Anh, tiếng Nhật, tiếng Hàn, tiếng Trung, tiếng Nga, tiếng Đức,… Chúng tôi đều có thể đáp ứng với chất lượng cao và tốc độ tốt nhất.

    Dịch thuật sách hướng dẫn sử dụng ngành thiết bị y tế

    Hướng dẫn sử dụng hay còn được gọi là Thông tin sử dụng (Information For Use – IFU), hướng dẫn sử dụng thiết bị y tế phải được dịch chính xác để đảm bảo an toàn cho bệnh nhân cũng như tuân thủ quy định quốc tế. Dịch Thuật Phương Đông có kinh nghiệm dịch thuật ngành y tế có thể tự tin dịch IFU cho nhiều loại thiết bị y tế như dụng cụ chẩn đoán, thiết bị hình ảnh y tế và máy xạ trị. Các biên dịch viên chuyên nghiệp của chúng tôi sử dụng hệ thống quản lý thuật ngữ có sẵn của chúng tôi để cung cấp các bản dịch hướng dẫn sử dụng chất lượng cao bằng tất cả các ngôn ngữ Châu Âu, Châu Á và Mỹ La Tinh.

    Dịch thuật sách hướng dẫn sử dụng phần mềm, ứng dụng (Software, App, Game)

    Các công ty phần mềm như Microsoft, Apple, Adobe, Oracle đều yêu cầu dịch ngôn ngữ cho hướng dẫn sử dụng và hệ thống hỗ trợ trực tuyến cho các chương trình máy tính khác nhau.

    Ngày nay với sự phát triển nhanh chóng của các nền tảng ứng dụng trong các cửa hàng phần mềm như App Store, Google Play thì nhu cầu dịch thuật các phần mềm và ứng dụng ngày càng nhiều.

    Không giống như các loại hướng dẫn sử dụng khác, hướng dẫn sử dụng phần mềm thường bao gồm các ảnh chụp màn hình đưa ra những thách thức duy nhất cho bản dịch chất lượng. Để dịch đúng hướng dẫn sử dụng phần mềm, trước tiên chương trình phần mềm phải được bản địa hóa. Tiếp theo, ảnh chụp màn hình được bản địa hóa được chụp để chúng có thể được sử dụng cho hướng dẫn sử dụng được dịch. Các chuỗi giao diện người dùng được dịch phải được sử dụng để tạo bảng chú thích để đảm bảo tính thống nhất về ngôn ngữ giữa GUI và tài liệu phần mềm. Dịch Thuật Phương Đông tự tin dịch các tài liệu hướng dẫn sử dụng phần mềm, game, app cho các công ty. Hãy liên hệ ngay với chúng tôi khi bạn có nhu cầu này.

    Bạn cần dịch thuật sách hướng dẫn sử dụng chuyên nghiệp?

    --- Bài cũ hơn ---

  • Business Analyst Cần Học Gì: Chuyên Nghiệp Khi Viết Hướng Dẫn Sử Dụng
  • Unit Test Là Gì? Khái Niệm Và Vai Trò
  • User Story Là Gì? User Story Mẫu Và Nguyên Tắc Ứng Dụng Trong Agile
  • 20+ Mẫu Thư Cảm Ơn Nhà Tài Trợ, Khách Hàng, Quý Đối Tác Chi Tiết Nhất
  • Tổng Hợp Nét Cơ Bản, Bảng Chữ Cái Thư Pháp Việt Đẹp
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100