nguyenhongduc

Danh mục: Agile & sản phẩm

  • Product backlog – mấy điều cơ bản

    Product backlog – mấy điều cơ bản

    Có lẽ ai làm công nghệ theo mô hình agile cũng sẽ quen với khái niệm product backlog. Nếu lên mạng để search từ khóa product backlog là gì, chắc chắn sẽ có rất nhiều bài viết về nó. Nên ở bài viết này, mình sẽ không nói lại quá nhiều những thứ chuyên ngành, đặc điểm hay lý thuyết về nó nữa. Mình sẽ chia sẻ những góc nhìn của bản thân về product backlog, và bạn hãy xem như đó là một góc nhìn tham khảo thêm từ 1 BA.

    Sơ lược về product backlog

    Team mình thường sử dụng Jira để quản lý product backlog và sprint backlog. Product backlog có vai trò là 1 todo list cho toàn team phát triển. Nó giống như 1 cái “hồ chứa task” thập cẩm đủ loại cho tất cả các member trong team.

    Với vai trò BA và kiêm luôn PO của sản phẩm, mình sẽ là người chịu trách nhiệm chính đưa các Product backlog items (PBI) lên jira. Việc này được thực hiện khi các yêu cầu đã rõ ràng, các tài liệu BRD đã được thông qua. Team cần một kế hoạch hành động cụ thể để có thể hiện thực hóa các tính năng.

    Trong suốt quá trình thực hiện dự án, product backlog sẽ liên tục được sàng lọc, bổ sung, điều chỉnh.

    1 product backlog ra đời như thế nào

    Quá trình tiến hóa của 1 product backlog có thể hình dung như sau:

    • Giai đoạn 1 – Khai sinh backlog: đặt vào backlog những Epic lớn và những user story “must have” cho mỗi epic. Việc breakdown này dựa trên tài liệu BRD, làm thành khung sườn của sản phẩm. Cần sắp xếp 1 cách tương đối về thứ tự thực hiện của các Epic lớn để có cái nhìn toàn cảnh về roadmap.
    • Giai đoạn 2 – Sprint backlog: đầu mỗi sprint, các PBI sẽ được kéo thả hợp lý vào sprint sao cho phù hợp với ưu tiên và tiến độ dự án. Động tác này có thể bao gồm luôn việc estimate thời lượng xử lý PBI đó nếu trước đó team chưa thực hiện.
    • Giai đoạn 4 – Backlog escalation: đây là giai đoạn mà các PBI xuất hiện ngày càng nhiều hơn. Các PBI giờ đây không chỉ gồm requirement (đại diện bởi user story) nữa. Xuất hiện các PBI khó chịu như bug (được QA tạo), improvement. Những requirement mới cũng được cân nhắc để bổ sung.
    • Giai đoạn 3 – Backlog refinement: role PO hoặc BA tùy dự án sẽ đảm bảo việc thực hiện sắp xếp thứ tự ưu tiên cho các PBI trong backlog, loại bỏ các PBI lỗi thời, breakdown hoặc group các PBI sao cho việc thực thi backlog hiệu quả nhất.

    Lưu ý khi làm việc với product backlog

    Khi làm Product backlog, có 1 số điều cần lưu ý:

    • Các PBI phải được mô tả chi tiết, definition of done rõ ràng, đủ để team phát triển có thể thực thi. Có thể đính kèm các tài liệu từ Confluence hoặc 1 tool quản lý wiki nào đó chứ không nhất thiết viết dài ngoằng vào description issue trên Jira.
    • Các PBI phải được estimate thời gian: 1 số PBI cần sự tham gia của nhiều member, cần xác định thời gian tối đa để hoàn thành PBI đó.
    • Các PBI phải được sắp xếp ưu tiên: Chú trọng việc đánh giá và sắp xếp mức độ ưu tiên giữa hàng đống PBI trong product backlog, tránh việc không biết phải làm gì tiếp theo.
    • Workflow giữa các thành viên trong team liên quan tới backlog phải được quy ước rõ. Các thành viên phải tuân thủ việc chuyển trạng thái task, comment những vấn đề còn chưa rõ hoặc thực hiện việc breakdown sub-task khi cần thiết.
    • Mỗi PBI có thể dính tới nhiều bên liên quan, cần xác định rõ ai là người chịu trách nhiệm, ai là người support. Đảm bảo không bỏ con giữa chợ.
    • Việc brainstorm và refinement các PBI nên có sự có mặt của cả team và nên thực hiện định kỳ. Giữ cho Product backlog ở trạng thái được cập nhật mới nhất.

    Một số mẹo khi làm việc với product backlog, dù bạn là BA, PO, Dev hay QA… hãy giữ những thói quen này:

    • Khi đã xác định được 1 yêu cầu hay 1 việc cần phải làm, hãy nhanh chóng đặt nó vào product backlog để tránh quên. Nếu siêng nữa thì ngay lập tức estimate thời gian, ưu tiên thực hiện. Hoặc nếu bận, hãy lưu nó ở đâu đó và cuối ngày, đặt nó vào product backlog.
    • Vào đầu mỗi ngày, hãy review lại backlog của bản thân và của dự án, đánh giá xem những gì đang làm hiện tại có phù hợp với tiến độ hoặc cần điều chỉnh gì hay không. Có việc nào gấp cần đẩy lên làm trước hay không.
    • Luôn cập nhật trạng thái task, dùng product backlog như 1 công cụ quản lý hiệu suất cá nhân (ở mức độ subtask).

    Okay, đó là một số chia sẻ của mình về product backlog, hy vọng giúp các bạn có một góc nhìn về cách sử dụng Product backlog.

    Bài viết chia sẻ về quản lý Product Backlog trong Agile. Đề cập đến vai trò và quy trình tạo và cập nhật backlog, cùng những lưu ý và mẹo khi làm việc với nó.

  • Làm sao để viết 1 user story

    Làm sao để viết 1 user story

    Đối với BA, sau khi lấy được requirement từ stakeholder, việc quan trọng tiếp theo chính là ghi nhận các requirement đó thành 1 tài liệu để giao tiếp với stakeholder và team development.

    Có nhiều cách thức để làm việc đó và trong bài viết này tôi sẽ nói về User story 1 trong những cách thức được ưa chuộng nhất đối với các dự án Agile ngày nay.

    User story là gì?

    Đó không phải là 1 tính năng, user story là 1 đơn vị nhỏ nhất của nhu cầu được nêu ra với góc nhìn của người dùng. Diễn đạt 1 cách đơn giản kết quả đầu ra mà 1 người dùng cụ thể mong muốn để thỏa mãn 1 nhu cầu nào đó.

    > Đăng nhập vào hệ thống bằng tài khoản mạng xã hội.
    → Tên của 1 tính năng, cho thấy Góc nhìn hệ thống
    > Là khách hàng, tôi muốn đăng nhập bằng tài khoản Google để có thể truy cập nhanh chóng.
    → Tên của 1 user story, cho thấy Góc nhìn người dùng

    User story không xoay quanh 1 tính năng, 1 giao diện hay 1 luồng business. Để thỏa mãn 1 User story có thể cần sự kết hợp của nhiều tính năng, nhiều màn hình, nhưng cũng có thể chỉ là 1 phần nhỏ được tách ra từ 1 luồng chính.

    Cốt lõi của user story chính là việc đặt người dùng làm trung tâm của mọi thứ. Người dùng cần gì từ hệ thống chứ không phải là hệ thống có thể cung cấp được gì cho người dùng. Đó cũng chính là thứ mà các nguyên tắc Agile luôn hướng tới – User first

    1 tập hợp gồm nhiều user story được gọi là epic. Thật ra một epic cũng có thể xem như là 1 user story, nhưng khác biệt ở chỗ mức độ bao quát của epic cao hơn và phức tạp hơn, cho nên cần phải break down ra thành những user story nhỏ để dễ dàng thực hiện.

    Một todo list (danh sách task) có thể giữ cho team tập trung vào các đầu việc cần phải hoàn thành, còn 1 bộ user story sẽ định hướng team tập trung giải quyết các vấn đề của người dùng thực tế. Sau khi hoàn thành 1 user story, đó chính là thỏa mãn 1 nhu cầu của user, chứ không phải là ghép thêm 1 mảnh ghép để tạo thành hệ thống.

    Cấu trúc của 1 user story

    1 user story gồm 2 phần chính

    • Mở bài: Tóm tắt user story
    • Thân bài: Chi tiết user story

    Mở bài

    Phần mở bài của user story thường được phát biểu dưới dạng một câu ngắn gọn theo cú pháp dưới đây:

    Là <loại user>, tôi muốn <nhu cầu>, để <lý do>.

    Ví dụ:

    • Là thủ quỹ, tôi muốn ghi lại 1 khoản chi tiêu trong nhóm để có thể tính toán thu chi sau này.
    • Là trưởng nhóm, tôi muốn xem báo cáo chi tiêu của nhóm trong 1 tuần vừa qua.

    Chỉ bằng 1 câu ngắn gọn, đã có thể dễ dàng hình dung được nhu cầu này một cách rõ ràng:

    • Loại user: Ai? Chúng ta giải quyết vấn đề này cho ai? Cần phải đặt bản thân vào vị trí của người này, người này là ai và họ có vai trò gì. BA cần đồng cảm sâu sắc cách họ nghĩ và cách họ cảm nhận, từ đó hiểu rõ ngữ cảnh của yêu cầu.
    • Nhu cầu: Làm gì? Mô tả cái mà user kỳ vọng, kết quả cuối cùng mà user muốn đạt được.
    • Lý do: Tại sao? Nhìn thấy rõ đâu business problem nào sẽ giải quyết được sau khi hoàn thành story này. Kỳ vọng này của user có khớp với bức tranh toàn cảnh dự án hay không?

    Thân bài

    Phần thân bài của user story được gọi là Acceptance Criteria – những điều kiện để được gọi là hoàn thành.

    Một user story hoàn thành nghĩa là output phải đáp ứng đủ các điều kiện mà acceptance criteria đề ra.

    Ví dụ:

    Là người tìm việc, tôi muốn lọc danh sách công việc trong một khu vực nhất định.

    Thì acceptance criteria cho user story này có thể là:

    • Hệ thống hiển thị danh sách các khu vực gồm: Hồ Chí Minh, Hà Nội, Khác.
    • User chỉ được chọn 1 khu vực để lọc
    • Hệ thống trả ra danh sách công việc còn hiệu lực thuộc khu vực user đã chọn
    • Hệ thống phân trang các kết quả trả ra, 10 kết quả/trang
    • …

    Việc liệt kê ra các acceptance criteria là cơ sở để triển khai xây dựng các tính năng và phục vụ việc test sau này. Việc định nghĩa kết quả càng rõ thì sẽ càng dễ dàng trong quá trình phát triển sau này. Hãy nhớ viết các acceptance criteria một cách rõ ràng mạch lạc.

    Bạn có thể thấy, acceptance criteria chính là những rule, logic để hoàn thiện hơn cho user story đơn giản được mô tả ở mở bài. Đây chính là 1 input quan trọng để team phát triển và testing

    Bên cạnh acceptance criteria, đôi lúc những user story phức tạp đòi hỏi phải có sự hỗ trợ của sơ đồ workflow, mockup để dễ hình dung được hơn cách mà user và hệ thống tương tác với nhau để cho ra output như mong muốn.

    Nếu user story quá lớn và phức tạp để có thể xong trong 1 sprint, hãy cân nhắc chia ra thành nhiều user story nhỏ hơn với những output cụ thể hơn:

    1 user story tốt cần:

    • Bám sát nhu cầu thực tế của user
    • Định nghĩa được rõ ràng kết quả muốn đạt được.
    • Dễ dàng có thể test được
    • Dễ dàng để ước lượng thời gian thực hiện

    Lưu ý

    User story là một công cụ hữu hiệu để có thể đào sâu vào chi tiết của các tính năng. Việc viết user story cho thật tốt sẽ mất rất nhiều thời gian và nỗ lực. Đôi khi, quá tập trung vào chi tiết cũng có thể khiến bạn mất đi cái nhìn toàn cảnh của dự án. Cho nên, hãy cân bằng giữa tư duy chi tiết và tư duy tổng quát. Nhìn rộng hơn để thấy được bức tranh lớn hơn. Từ đó biết được đâu là chỗ cần đầu tư nhiều thời gian và sáng tạo.