Tôi đấu tranh để tạo ra sự trực quan/theo dõi tốt cho dự án scrum của tôi và do đó đang cân nhắc một số lựa chọn thay thế. Một khái niệm thú vị là Story Mapping. Bạn có bất kỳ đầu vào nào khi sử dụng bản đồ câu chuyện thay vì sử dụng một backlog phẳng không?Bản đồ câu chuyện hoặc backlog phẳng?
Như mọi khi với Scrum, hãy làm ít nhất bạn nghĩ mình cần. Quá nhiều tài liệu có thể trở thành không thể duy trì và sẽ chỉ buộc bạn xuống.
Điều đó nói rằng: trong vai trò trước đó, chúng tôi có khoảng 15 nhóm Scrum, chúng tôi đã có một "phòng chiến tranh" nơi các câu chuyện được lập bản đồ trên một tấm bảng có kích thước bằng tường.
Hầu hết những câu chuyện này là "sử thi", vì có giả định rằng các nhóm Scrum riêng lẻ sẽ chia nhỏ chúng thành những câu chuyện nhỏ hơn, dễ quản lý hơn sau đó.
Ban đầu, không có ước tính thời gian nào được liên kết với các sử thi này, vì mục tiêu của bản đồ là xác định các phụ thuộc giữa các sử thi và nhận ý tưởng sơ bộ về đội nào sẽ được đặt tốt nhất để thực hiện sử thi nào.
Trong các lần lặp lại sau đây, chúng tôi đã tính toán các ước tính thời gian và bắt đầu viết chì ở nơi họ sẽ ngồi trong phần tồn đọng của mỗi nhóm. Điều này dẫn đến một số xáo trộn xung quanh các câu chuyện nhưng trên toàn bộ dự đoán ban đầu là về đúng.
Bằng hai hoặc ba lần chạy nước rút sau khi chúng tôi bắt đầu "phòng chiến tranh" trở nên khó duy trì, vì vậy chúng tôi chuyển trở lại điểm đó sang bảng tính Excel với các sử thi được liệt kê theo tuần tự. Tuy nhiên, vào thời điểm đó, các chủ sở hữu sản phẩm và khách hàng đã nội bộ hóa kế hoạch dự án nên không cần phải duy trì nó.
Như được mô tả trong bài viết bạn đã liên kết khái niệm Bản đồ câu chuyện là kết quả của việc thay đổi thứ gì đó không hoạt động tốt cho chúng. Tất cả các đội đều khác nhau và điều tốt nhất bạn có thể làm (theo ý kiến của tôi) là chọn một thứ mà bạn (đội) nghĩ rằng có vẻ hứa hẹn và thử nó để chạy nước rút và nói về nó lần nữa ở lần nhìn lại tiếp theo. Thực hiện điều chỉnh và thử thêm một số lần nữa và truy cập lại vào lần xem lại, v.v.
Đúng. Tôi đã hy vọng nhận được một số phản hồi từ những người khác trước khi chúng tôi tiếp tục thử khái niệm này. –
Lập bản đồ câu chuyện là một kỹ thuật lập kế hoạch tuyệt vời, nhưng tôi sẽ không sử dụng bản đồ câu chuyện cho mỗi lần theo dõi. Tôi sẽ sử dụng các Tính năng/Kịch bản được xác định trên bản đồ dưới dạng nhóm chức năng và tôi sẽ sử dụng biểu đồ lô đỗ xe để hiển thị tiến trình trên từng tính năng. Một ý tưởng hay ở đây là xác định chức năng tối thiểu cần thiết để vận chuyển từng tính năng (tất nhiên đây là câu chuyện ưu tiên cao nhất cho tính năng đó) và đặt một dòng trên biểu đồ bãi đậu xe cho từng tính năng cho biết khi nào số lượng tối thiểu chức năng đã được thực hiện. Đây là một cách rõ ràng để hiển thị chính xác vị trí của sản phẩm cho các bên liên quan bên ngoài.
Tobias ở đây là hai quan điểm khác về ánh xạ câu chuyện: John Walpole of Twitter shares their experience with story maps và tôi cũng đã viết một primer on story mapping.
Tôi đang bỏ phiếu để đóng câu hỏi này là không có chủ đề vì nó không phải là về lập trình. –