Visual Paradigm Desktop | 
Visual Paradigm Online
Việc tạo ra một danh sách có cấu trúc các mục công việc là nền tảng cho bất kỳ nỗ lực Agile thành công nào. Tài liệu này trình bày quy trình xây dựng một danh sách công việc sản phẩm Agile chức năng. Chúng tôi tập trung vào các bước thực tế có thể hoàn thành nhanh chóng mà vẫn đảm bảo chất lượng và sự rõ ràng. Mục tiêu là thiết lập một lộ trình rõ ràng cho đội nhóm mà không bị mắc kẹt trong khối lượng công việc hành chính.
Danh sách công việc sản phẩm Agile là một danh sách được sắp xếp các thứ mà chúng ta biết là cần thiết cho sản phẩm. Đây là nguồn duy nhất cung cấp yêu cầu cho mọi thay đổi được thực hiện đối với sản phẩm. Nó không chỉ đơn thuần là một danh sách việc cần làm; mà là một tài liệu động, thay đổi theo thời gian khi sản phẩm và điều kiện thị trường thay đổi.
Không có một danh sách công việc được duy trì tốt, các đội nhóm có nguy cơ làm việc trên những tính năng ít giá trị, bỏ sót các phụ thuộc quan trọng hoặc kiệt sức do mở rộng phạm vi công việc. Hướng dẫn này đảm bảo bạn có một điểm khởi đầu vững chắc.
Trước khi bạn bắt đầu điền vào danh sách, hãy đảm bảo bạn đã chuẩn bị đầy đủ các yếu tố sau. Việc chuẩn bị này giúp tiết kiệm thời gian trong giai đoạn thực hiện tạo lập.
Xác định mục tiêu dài hạn của sản phẩm. Bạn đang giải quyết vấn đề gì? Đối tượng mục tiêu là ai? Không có tầm nhìn rõ ràng, các mục trong danh sách công việc sẽ thiếu định hướng.
Thu thập các yêu cầu ban đầu từ các bên liên quan then chốt. Bạn không cần chi tiết từng chút, nhưng cần có nhu cầu cấp cao để bắt đầu xây dựng các epic.
Xác định một không gian vật lý hoặc kỹ thuật số nơi đội nhóm có thể xem và chỉnh sửa danh sách công việc. Điều này có thể là một bảng trắng, tài liệu chia sẻ hoặc bảng quản lý. Tránh nêu tên nhà cung cấp cụ thể; hãy tập trung vào tính năng hữu ích của công cụ.
Phần này chi tiết quy trình điền đầy danh sách công việc của bạn một cách hiệu quả. Chúng tôi hướng đến việc hoàn thành cấu trúc cốt lõi trong vòng 30 phút.
Bắt đầu bằng bức tranh tổng thể. Các epic là những khối công việc lớn có thể chia nhỏ thành các nhiệm vụ nhỏ hơn. Chưa cần lo lắng về chi tiết ngay lúc này.
Ví dụ:
Các Epic quá lớn để thực hiện trong một lần sprint. Hãy chia nhỏ chúng thành Các câu chuyện người dùng. Một Câu chuyện người dùng mô tả một tính năng từ góc nhìn của người mong muốn nó.
Sử dụng định dạng chuẩn:
Là một [loại người dùng], tôi muốn [mục tiêu nào đó] để [lý do nào đó].
Ví dụ chia nhỏ từ Epic A:
Một Câu chuyện người dùng sẽ không hoàn chỉnh nếu không có các tiêu chí rõ ràng về thành công. Đây là những điều kiện cần được đáp ứng để coi câu chuyện là đã hoàn thành.
Sử dụng các điểm đánh dấu để liệt kê các yêu cầu cụ thể. Điều này loại bỏ sự mơ hồ trong quá trình phát triển và kiểm thử.
| Thành phần | Định nghĩa | Ví dụ |
|---|---|---|
| Đầu vào | Dữ liệu nào là cần thiết? | Địa chỉ email, Mật khẩu |
| Quy trình | Điều gì xảy ra khi hành động được thực hiện? | Kiểm tra xác thực, Email đã được gửi |
| Đầu ra | Kết quả là gì? | Thông báo thành công, Chuyển hướng đến bảng điều khiển |
Sắp xếp các mục trong danh sách công việc theo giá trị và mức độ ưu tiên. Các mục ở đầu danh sách phải là những mục quan trọng nhất cho vòng phát triển tiếp theo. Sử dụng một khung ưu tiên để đưa ra quyết định khách quan.
Các phương pháp phổ biến bao gồm:
Để đảm bảo bạn đang xây dựng đúng những điều cần thiết, hãy sử dụng một phương pháp có cấu trúc để sắp xếp các mục. Bảng này nêu rõ hai phương pháp phổ biến.
| Phương pháp | Dùng tốt nhất cho | Cách hoạt động |
|---|---|---|
| MoSCoW | Tuân thủ quy định hoặc thời hạn nghiêm ngặt | Phân loại mỗi mục vào một trong bốn nhóm. Tập trung chỉ vào các mục “Phải có” cho bản phát hành đầu tiên. |
| Giá trị so với Nỗ lực | Các đội ngũ bị hạn chế nguồn lực | Đánh giá các mục theo thang điểm 1-5 về Giá trị và thang điểm 1-5 về Nỗ lực. Ưu tiên các mục có giá trị cao, nỗ lực thấp. |
Chất lượng danh sách công việc của bạn phụ thuộc vào chất lượng các câu chuyện người dùng. Những câu chuyện mơ hồ dẫn đến lãng phí nỗ lực và kỳ vọng không đồng bộ. Hãy tuân theo các hướng dẫn này để đảm bảo sự rõ ràng.
Đảm bảo các câu chuyện của bạn đáp ứng các tiêu chuẩn sau:
Viết cho người dùng cuối, chứ không phải nhà phát triển. Thay vì nói “Thực hiện điểm cuối API”, hãy nói “Cho phép người dùng truy xuất dữ liệu hồ sơ của họ”. Điều này giúp duy trì sự tập trung vào giá trị.
Bao gồm ảnh chụp màn hình, bản mô phỏng hoặc liên kết đến các tệp thiết kế nếu có sẵn. Các công cụ trực quan giúp giảm đáng kể sai sót trong việc diễn giải.
Xây dựng danh sách công việc không phải là một sự kiện duy nhất. Nó đòi hỏi sự tinh chỉnh liên tục, thường được gọi là dọn dẹp. Điều này đảm bảo phần đầu danh sách luôn sẵn sàng cho lần phát hành tiếp theo.
Trong các buổi này, đội ngũ nên:
Ngay cả các đội có kinh nghiệm cũng mắc sai lầm khi thiết lập danh sách công việc của họ. Hãy cảnh giác với những lỗi phổ biến này.
Một khi danh sách công việc của bạn đã được điền đầy, bạn cần ước lượng nỗ lực cần thiết. Điều này giúp trong lập kế hoạch sprint.
Sử dụng kích thước tương đối thay vì giờ. Gán điểm (ví dụ: dãy Fibonacci: 1, 2, 3, 5, 8) dựa trên độ phức tạp, nỗ lực và rủi ro.
Tập hợp đội ngũ để bỏ phiếu về các ước lượng. Điều này khuyến khích thảo luận và đảm bảo sự hiểu biết chung về yêu cầu.
Nợ kỹ thuật tích lũy khi lựa chọn các giải pháp nhanh thay vì các giải pháp vững chắc. Nó phải được quản lý một cách rõ ràng trong danh sách công việc.
Bỏ qua nợ sẽ dần làm chậm quá trình phát triển. Hãy coi nó như một yếu tố hàng đầu trong kế hoạch của bạn.
Danh sách công việc là một tài liệu sống. Nó cần được chăm sóc để duy trì tính hữu ích.
Tính nhất quán là chìa khóa. Nếu bạn ngừng cập nhật danh sách công việc, nó sẽ trở thành một tài liệu lịch sử thay vì công cụ lập kế hoạch.
Danh sách công việc là một công cụ giao tiếp. Nó giúp lấp đầy khoảng cách giữa nhu cầu kinh doanh và thực thi kỹ thuật.
Đảm bảo danh sách công việc được hiển thị cho mọi người. Nếu các bên liên quan không thể nhìn thấy kế hoạch, họ sẽ không thể đưa ra phản hồi.
Trong các buổi tinh chỉnh, đảm bảo các nhà phát triển và người sở hữu sản phẩm thống nhất về việc “hoàn thành” trông như thế nào.
Đảm bảo thông tin dễ tìm thấy. Tránh chôn vùi các chi tiết quan trọng trong những tài liệu dài.
Yêu cầu sẽ thay đổi. Điều này là bình thường trong Agile. Đừng chống lại sự thay đổi; hãy điều chỉnh danh sách công việc của bạn.
Không bao giờ bỏ qua yêu cầu của bên liên quan nếu nó mang lại giá trị. Xem xét lại thứ tự và điều chỉnh kế hoạch cho phù hợp.
Làm sao bạn biết danh sách công việc của mình có khỏe mạnh không? Hãy tìm những dấu hiệu sau.
| Chỉ số | Trạng thái khỏe mạnh | Trạng thái không khỏe mạnh |
|---|---|---|
| Các mục hàng đầu | Rõ ràng, sẵn sàng cho sprint | Mơ hồ, thiếu tiêu chí chấp nhận |
| Các mục cuối danh sách | Ưu tiên thấp, có thể đã được lưu trữ | Ưu tiên cao, bị chôn sâu trong danh sách |
| Kích thước | Dễ quản lý, vừa với tầm nhìn | Hàng ngàn mục chưa liên kết |
| Cập nhật | Được cập nhật hàng tuần hoặc hai tuần một lần | Không thay đổi trong nhiều tháng |
Xây dựng danh sách công việc sản phẩm Agile là kỹ năng nền tảng để mang lại giá trị. Bằng cách tuân theo các bước này, bạn sẽ tạo ra con đường rõ ràng cho đội nhóm của mình đi theo. Quy trình này mang tính lặp lại. Khi tích lũy được kinh nghiệm, bạn sẽ tinh chỉnh phương pháp của riêng mình.
Tập trung vào sự rõ ràng, hợp tác và cải tiến liên tục. Một danh sách công việc được duy trì tốt sẽ trao quyền cho đội nhóm của bạn để liên tục cung cấp các sản phẩm chất lượng cao. Bắt đầu từ những điều cơ bản được nêu ở đây, và phát triển quy trình của bạn theo sự phát triển của sản phẩm.
Hãy nhớ, mục tiêu không phải là sự hoàn hảo ngay từ ngày đầu tiên. Mục tiêu là tiến bộ. Bắt đầu bằng một tầm nhìn, chia nhỏ ra, ưu tiên và bắt đầu làm việc. Danh sách công việc sẽ trưởng thành cùng với sản phẩm của bạn.