User Story là gì ?

User Story là một tài liệu sơ giản về yêu cầu sản phẩm với góc nhìn người dùng. Thông thường, User Story do khách hàng, hoặc đại điện của khách hàng viết, tuy nhiên nếu có sự cộng tác của Các Nhà Phát triển thì nhóm và khách hàng sẽ có sự chia sẻ hiểu biết về sản phẩm tốt hơn.

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

User story có định dạng:

Là  ười>

tôi muốn àm>

để ục>

Mô hình của User Story

User story nên theo quy mô 3C :

• 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à

  Phát triển. Do đó cụ thể của User Story được làm rõ trải qua những cuộc trao đổi ( nên là trực tiếp ) với người mua. Nội dung của User Story sẽ ngày càng đơn cử 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 cụ thể, 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 ?

Product Owner là người quản lý tất cả các User Story nhưng không phải là người viết toàn bộ User Story. Các Nhà Phát triển đều có thể tham gia vào việc viết User Story. Các Nhà Phát triển đóng vai trò quan trọng trong việc mô tả các tính năng của sản phẩm.

Trong trường hợp lý tưởng nhất, người dùng thực sự của mẫu sản phẩm sẽ tham gia viết User Story .Trong những trường hợp khác, Product Owner hoàn toàn có thể đại diện thay mặt 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 chuẩn của User Story

Tiêu chí INVEST cụ thể:

• Independent (Độc lập): Độc lập với các User Story khác. Điều này giúp

  Product Ownertự do đổi khác thứ tự của nó trongProduct BacklogvàNhà Phát triểnthuận tiện tăng trưởng .

• Negotiable (Thương lượng được): Tính đàm phán được giúp cho

  Nhóm Phát triểnvàProduct Ownercùng nhau thiết kế xây dựng nội dung chi tiết cụ thể và tương thích hơn cho những đổi khác trong tương lai. Nếu không có tính năng này thì việc thích nghi với sự biến hóa gặp khó khăn vất vả .

• 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 Ownercó nền tảng kỹ thuật, hoàn toàn có thể họ sẽ biến Agile thành một quy mô tăng trưởng 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.

  Xem thêm: PAGES là gì? -định nghĩa PAGES

• 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 ?

Hoạt động viết User Story diễn ra trong suốt quy trình tăng trưởng dự án Bất Động Sản, có nghĩa là bất kỳ khi nào những thành viên cũng hoàn toàn có thể thêm vào những User Story mới .Việc này thường được triển khai trải qua tổ chức triển khai một buổi viết User Story ( User Story Writing Workshop ). Ở đó, tổng thể những thành viên đều tham gia tạo ra những User Story cơ bản, đủ để sản xuất trong một thời hạn. Có thể có những User Story lớn, tất cả chúng ta sẽ sẽ được làm mịn hơn song song với quy trình tăng trưởng trải qua hoạt động giải trí làm mịn Product Backlog .

Ví dụ đơn cử về User Story

Là một người học trực tuyến, tôi muốn thấy list những khóa học ưu thích của mình để thuận tiện truy vấn .

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

 Là ột>

Tôi muốn

Để ễ>

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 trị, 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 list những khóa học ưu thích của mình. Danh sách này chỉ gồm có những khóa học mà học giả chăm sóc 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ó list này là để thuận tiện truy vấn khi cần đến .Từ việc miêu tả nhu yếu của người mua, những thành viên tăng trưởng làm rõ tiêu chuẩn gật đầu với Product Owner và sau đó sẽ cùng nhau nghiên cứu và phân tích chi tiết cụ thể giao diện, mã, thêm bảng tài liệu, tương tác tài liệu, … để thực thi một cách hiệu suất cao .Để khám phá kĩ hơn cũng như biết cách viết 1 User Story, những Product Owner cần có cái nhìn tổng quan để quản trị dự án Bất Động Sản 1 cách ngặt nghèo nhất .

Làm sao để sử dụng User Story hiệu suất cao ?

User Story có vai trò rất quan trọng trong dự án Bất Động Sản. Nếu nhóm của bạn hay Product Owner không hiểu hoặc hiểu sai nhu yếu của người dùng, thì tác dụng sẽ là một loại sản phẩm thất bại .

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 –

Nếu biết cách sử dụng User Story hiệu suất cao, nhóm dự án Bất Động Sản hoàn toàn có thể phát hành được những loại sản phẩm chất lượng cao, nhận được sự tin cậy và hài lòng từ phía người mua. Sau đây là một vài quan tâm để bạn hoàn toàn có thể sử dụng User Story hiệu suất cao :

• Giữ bản miêu tả User Story ngắn gọn .
• Hãy đặt mình vào tâm lý 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 tiến hành tăng trưởng .
• Ước lượng User Story trước khi thực thi để chắc như đinh khối lượng việc làm của team nằm trong tầm trấn áp .
• Các nhu yếu sẽ được khai thác từ người dùng sau cuối, chứ không phải bởi người dùng cuối hay nhóm tăng trưởng .
• 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 ở đầu cuối .

Product Owner là người chịu nghĩa vụ và trách nhiệm truyền đạt lại User Story của những Stakeholder cho nhóm. Để làm tốt vai trò này, bên cạnh kinh nghiệm tay nghề, Product Owner cần hiểu rõ kỹ năng và kiến thức về Agile / Scrum để sử dụng User Story hiệu suất cao nhất .Thấu hiểu những yếu tố trên, Học viện Agile đã kiến thiết xây dựng những khóa học phân phối kiến thức và kỹ năng nền tảng về Scrum, những kỹ thuật và công cụ thực hành thực tế, dưới sự huấn luyện và đào tạo, dẫn dắt của đội ngũ giảng viên là những chuyên viên Scrum số 1 .

Hình ảnh Học viện Agile giảng dạy tại ngân hàng nhà nước MSBHọc viện Agile đã có kinh nghiệm tay nghề tiến hành thành công xuất sắc hàng chục lớp học với hơn 400 học viên, trong đó có nhiều quản trị của những doanh nghiệp như : Viettel, FPT Software, VNPT, Techcombank, MSB, NTQ Solution, Bravestars, SotaTek …Tham khảo ngay những khóa học dành cho Product Owner :

Đọc thêm:

6 bước giúp bạn sống sót qua quy trình quy đổi DevOpsXây dựng mạng lưới đội nhóm để vượt qua khủng hoảng cục bộDiễn giải về Agile