Story Map - Lập kế hoạch tổng quát trong Agile

24/09/20

Viện Quản lý dự án Atoha

Trong chuỗi các công cụ, kỹ thuật lên kế hoạch của Agile, chúng ta không thể không kể đến Story map - xây dựng kế hoạch xây dựng phần mềm/sản phẩm cho dự án một cách bao quát nhất. Trong bài viết này, chúng ta sẽ cùng khám phá các khía cạnh của story map, để hiểu rõ lý do tại sao story map lại có giá trị như vậy.

Lịch sử của story map

Jeff Patton được coi là người phát minh ra story map và ông đã viết cuốn sách theo đúng nghĩa đen (User Story Map). Phát minh này được ra đời từ nhận thức rằng các tài liệu bằng văn bản dễ bị hiểu sai, truyền đạt chưa đúng và đủ ý, trong khi đó một cuộc trao đổi trực tiếp sẽ dễ giúp các nhóm Scrum hiểu đúng yêu cầu của người dùng/khách hàng, từ đó cung cấp một sản phẩm thực sự đáp ứng nhu cầu của người dùng/khách hàng mong muốn.

Mặc dù Jeff đã bắt đầu giới thiệu khái niệm này với thế giới từ năm 2005, nhưng nó vẫn chưa được chính thức gọi là “story map” cho đến năm 2008. Trong thập kỷ kể từ khi được giới thiệu, story map đã được nhiều “tín đồ” Agile áp dụng, tích hợp vào quá trình phát triển phần mềm/sản phẩm.

Story map là gì?

Story Map là một phương pháp sắp xếp user stories để tạo ra một cái nhìn tổng thể hơn, trực quan hơn về các tính năng của phần mềm/sản phẩm, là một công cụ lập kế hoạch ở mức high-level (tổng quát) mà các bên liên quan có thể sử dụng để sớm vạch ra các hạng mục ưu tiên của dự án trong quá trình lập kế hoạch, dựa trên thông tin có sẵn tại thời điểm đó. Story Map về cơ bản là một ma trận được sắp xếp theo thứ tự ưu tiên các tính năng và user story cho sản phẩm đang được xây dựng.

Story Map

Tại sao nên sử dụng story map?

User stories là một cách hữu ích giúp xây dựng Product Backlog tốt hơn, trong đó lấy người dùng làm trung tâm và mô tả các yêu cầu phần mềm theo cách thực tế. Nhưng user stories không tiết lộ toàn bộ bức tranh, nó chỉ gợi ý cho chúng ta một bức tranh về quá trình người dùng/khách hàng trải qua từng bước từ lúc tải ứng dụng cho đến khi họ đạt được mục tiêu cuối cùng.

User story map có thể giúp chúng ta sắp xếp user stories thành một mô hình có thể quản lý để lên kế hoạch, hiểu và sắp xếp chức năng của hệ thống một cách có hệ thống. Bằng cách thể hiện trực quan, Story Map có thể xác định các lỗ hổng và thiếu sót trong chức năng hoặc các hạng mục backlog cần tập trung. Từ đây, Story Map giúp các nhóm lập kế hoạch toàn diện một cách hiệu quả, mang lại giá trị tối ưu cho người dùng/khách hàng.

Dưới đây là một vài lý do chúng ta nên xem xét sử dụng công cụ này:

Story Map cho phép chúng ta nhìn thấy bức tranh lớn, đầy đủ trong backlog dự án.
Story Map còn là một công cụ tuyệt vời để đưa ra quyết định một cách trơn tru và sắp xếp thứ tự ưu tiên cho backlog của dự án.
Story map sẽ minh họa những gì chúng ta đã có và những phần còn thiếu mà chúng ta cần làm để cho phần mềm/sản phẩm hoạt động tốt.
Story Map là một cách tuyệt vời để xác định MVP (Minimum Viable Product - sản phẩm hữu hiệu tối thiểu). Nó sẽ hạn chế việc bạn “quên” những phần quan trọng của phần mềm/sản phẩm.
Story Map thúc đẩy việc cả nhóm cùng brainstorming để tạo ra user story cho dự án.
Sắp xếp thứ tự ưu tiên cho các công việc cần làm.
Quản lý user stories hiệu quả, để giữ cho mọi thành viên trong nhóm cùng hướng về một mục tiêu.
Story Map là một thay thế trực quan tuyệt vời so với kế hoạch của các dự án truyền thống.
Story Map là một mô hình hữu ích để hỗ trợ tại các cuộc thảo luận về chất lượng sản phẩm và quản lý phạm vi dự án.
Cách sử dụng phổ biến nhất của story map là sử dụng nó như một giải pháp thay thế cho việc quản lý backlog “phẳng” - chỉ là một danh sách. Việc xử lý công việc backlog không có ngữ cảnh có thể sẽ hiệu quả, nhưng chúng ta sẽ bỏ lỡ cơ hội xem mối liên hệ và tầm quan trọng của từng mục đối với bức tranh tổng thể của cả dự án.

Ai nên tham gia vào user story map?

Vì user story map tạo ra một cái nhìn tổng thể về sản phẩm, nên quá trình tham gia sẽ rất cần thiết khi bao gồm các thành viên của bất kỳ nhóm nào chịu trách nhiệm trong quá trình xây dựng sản phẩm hoàn chỉnh:

Kỹ thuật
UX / thiết kế
Quản lý sản phẩm
Bán hàng
Tiếp thị
Hỗ trợ khách hàng
Hoạt động / CNTT
Tài chính
….

User story map hoạt động như thế nào?

User story mapping bắt đầu với quyết định về phương tiện nào sẽ sử dụng để xây dựng story map. Có thể được thực hiện với các công cụ đơn giản chẳng hạn như bảng trắng và sticky notes - hoặc bằng nhiều công cụ phần mềm có sẵn để tạo map ảo. Bất kể là sử dụng phương tiện nào, các nhóm Scrum muốn triển khai đều phải thực hiện qua các bước sau:

Story map bắt đầu bằng cách xác định các nhóm tính năng (hoặc đôi khi là trình tự sử dụng) cho sản phẩm theo chiều ngang trên đầu ma trận, từ trái sang phải. Dưới các cột, nhóm sẽ sắp xếp user story cards trong mỗi tính năng theo thứ tự ưu tiên giảm dần.
Tại thời điểm này, nhóm vẫn chưa biết sẽ cần bao nhiêu lần lặp lại để xây dựng từng tính năng hay thời gian releases như thế nào.
Ở hàng trên cùng của story map, nhóm đặt các stories mô tả các chức năng thiết yếu cần thiết để hệ thống hoạt động. Nhóm này được gọi là Backbone.
Ở hàng tiếp theo, nhóm đặt các stories mô tả các chức năng của hệ thống sẽ đáp ứng nhu cầu cơ bản nhất của khách hàng. Nhóm này được gọi là Walking Skeleton. Khi các user stories trong nhóm walking skeleton hoàn thành, phần mềm/sản phẩm có thể hoạt động được, nhưng ở mức cơ bản nhất.
Cuối cùng, nhóm đặt tất cả user stories khác bên dưới walking skeleton, theo thứ tự ưu tiên giảm dần cho khách hàng. Từ đó, nhóm có một bức tranh tổng quát theo sản phẩm, theo tính năng, theo thứ tự giá trị mang lại từ sản phẩm/phần mềm.

Một số thách thức của user story map

User story map có thể có lợi cho các nhóm muốn phát triển sản phẩm nhanh và xây dựng sản phẩm mà khách hàng kỳ vọng, nhưng nó cũng có thể mang lại kết quả đáng thất vọng nếu các nhóm không có sự chuẩn bị kỹ càng. Đây là một số thách thức cần chú ý:

Không xác định được khách hàng rõ ràng: Nếu chúng ta không biết chính xác khách hàng là ai, thì không thể biết họ trải nghiệm sản phẩm như thế nào. Chúng ta phải biết mình đang mapping stories cho ai.
Không có vấn đề rõ ràng: Nếu không biết sản phẩm của dự án đang giải quyết vấn đề gì cho khách hàng, thì toàn bộ quá trình user story mapping có thể phản tác dụng. Việc xây dựng stories hướng tới mục tiêu khách hàng sai có thể dẫn đến sự lãng phí thời gian và nguồn lực - không chỉ trong bản thân việc thiết lập user story map mà còn cho sprints và releases dựa trên nó.
Tiện ích hạn chế: Story map được tạo từ sticky notes trên bảng trắng rất khó cập nhật. Notes có thể bị rơi ra, bảng trắng có thể bị xóa dẫn đến những story được ghi trên đó bị mất,.... Ngoài ra, story maps được xây dựng và bố trí ở một vị trí cố định, vì vậy sẽ có một số thành viên cảm thấy bất tiện khi ngồi ở các vị trí bị khuất tầm nhìn, không thấy được story map một cách trực diện. Tuy nhiên có thể khắc phục bằng cách xây dựng story map những phần mềm máy tính.
Công việc bị lặp lại: Những stories từ user story map thường cần được tạo lại trong product backlog “phẳng” (dạng danh sách). Kết quả là, việc này có thể khiến các nhóm cảm thấy rằng họ đang làm cùng một công việc hai lần.

Tổng kết

Story map là một công cụ tuyệt vời để đạt được nhiều mục tiêu mà một số dự án khác không thể đạt được. Với story map, chúng ta có thể thể hiện được bức tranh toàn cảnh về mục tiêu của dự án mà không cần phải giải thích cặn kẽ cho từng thành viên. Giúp tạo ra một môi trường cộng tác cho tất cả mọi người cùng tham gia vào quá trình xây dựng sản phẩm.

Tuy nhiên, việc sử dụng story map cần phải tốn thời gian, vì vậy bản thân project manager cần phải thuyết phục các bên liên quan, đặc biệt là các cấp quản lý cao hơn rằng story map đáng được sử dụng hơn so với các công cụ lập kế hoạch truyền thống. Và project manager sẽ phải đảm bảo triển khai story map hiệu quả, đem lại lợi ích tối ưu nhất cho sản phẩm, cho khách hàng.

Kiến thức tổng hợp bởi Trainer Nguyễn Hải Hà (PMP®, PMI-ATP Instructor)

References: PMI-ACP Exam Prep, Head First Agile, ProductPlan.com, aha.io