Làm thế nào để phát hành với Kanban?

Question

Trong Scrum, rõ ràng là chúng tôi có thể tạo bản trình diễn sau mỗi lần chạy nước rút.

Tôi không biết cách tạo bản trình diễn ở Kanban vì nó không có khái niệm chạy nước rút (tôi có thể sai).

Bạn vui lòng khai sáng cho tôi về cách tạo bản phát hành ở Kanban?

Cảm ơn sự giúp đỡ và thời gian.

Answer 1

Khi chúng tôi thực hiện Kanban tại công việc cuối cùng của tôi, các phiên bản đi một trong ba cách:

1. phát hành mỗi hai tuần trên một lịch trình.
2. Nếu đủ ghi chú dán kết thúc trong thùng "đã thực hiện" trên bảng để nhận được thông báo ngoài chu kỳ, hãy thông báo cho đơn vị kinh doanh mà chúng tôi đang phát hành để chúng tôi có thể ngăn quá đồng bộ.
3. Đơn vị kinh doanh yêu cầu bản phát hành ngoài vòng cho một tính năng cụ thể của tập hợp các tính năng cần thiết ngay lập tức.

Nó thực sự khá cởi mở.

Answer 2

Chúng tôi tạo bản trình diễn điều kiện di chuyển đối tượng địa lý từ "Thử nghiệm" sang "Sẵn sàng phát hành". Vì vậy, tính năng theo từng tính năng thay vì chạy nước rút, và bản chất của đối tượng địa lý sẽ xác định bản chất của bản trình diễn. Sự tham gia của doanh nghiệp càng lớn trong quá trình phát triển thì vấn đề này càng ít.

Answer 3

Không có định nghĩa duy nhất. Thông thường ở Kanban, chúng tôi thêm MMF (Tính năng có thể tiếp thị tối thiểu), theo định nghĩa, có nghĩa là mọi tính năng sẽ thêm giá trị cho khách hàng, do đó bạn có thể phát hành mọi tính năng độc lập.

Điều này không có nghĩa là bạn phải giải phóng từng tính năng riêng biệt, vì vậy bạn sẽ tìm thấy toàn bộ phạm vi tiếp cận (David đề cập đến một số phương pháp). Tôi thấy nó là một trường hợp phổ biến mà nhóm Kanban phát hành thường xuyên hơn họ sẽ làm nếu họ theo một trong những cách tiếp cận thời gian đóng hộp.

Bản trình diễn ở Kanban là tùy chọn nhưng nếu khách hàng sẵn sàng có chúng, bạn có thể giới thiệu các tính năng ngay cả khi bạn phát hành mọi tính năng độc lập. Về lý thuyết, mọi tính năng nên thêm giá trị để phương pháp này hoạt động tốt.

Answer 4

Kanban nói cách quản lý luồng công việc và hạn chế công việc đang tiến hành, nó không nói bất cứ điều gì về tần suất phát hành như vậy. Tuy nhiên, nó là khá khó khăn vì nó đòi hỏi một phiên bản tích hợp làm việc của sản phẩm được giữ ở tất cả các lần với các tính năng mới được bổ sung ngay sau khi chúng được coi là hoàn thành (thực hiện, cột cuối cùng trên diễn đàn).

Một khái niệm thường được sử dụng là có "nhịp" - khoảng thời gian thường xuyên khi "sản phẩm sẵn sàng" này được thực hiện và triển khai thực sự đến hệ thống trực tiếp/được giao.

Tuy nhiên, tôi nghĩ rằng một khái niệm rất rõ ràng trong Scrum cũng có thể trợ giúp ở đây. Trong Scrum, rõ ràng là Scrum gọi "tăng sản phẩm có thể chuyển đổi" (xác nhận định nghĩa DONE) vào cuối mỗi lần chạy nước rút. Cho dù thực sự gửi nó/triển khai nó nằm ngoài phạm vi của quá trình phát triển, bởi vì nó cuối cùng là một quyết định kinh doanh. Tương tự như tôi nghĩ áp dụng cho Kanban, một sản phẩm tích hợp sẵn sàng luôn sẵn sàng, dù thực sự sử dụng nó như là một quyết định kinh doanh nằm ngoài phạm vi của quá trình phát triển và quản lý của nó.

Answer 5

Bạn có thể thử thêm bước đăng xuất vào DOD của mình nơi bạn có thể sắp xếp bản trình diễn nhanh. Nhưng sự khác biệt sẽ là, nó sẽ là một bản demo một-trong-một trong khi trong đánh giá chạy nước rút scrum, bản demo là dành cho tất cả những người tham dự.

Về chu kỳ phát hành, nó đã được đề cập trong các câu trả lời trước. Tôi muốn thêm một điểm nữa, bạn có thể có giới hạn cho việc phát hành các mục. Ví dụ, nếu bạn có 10 MMF trong bảng sẵn sàng để được phát hành thì quá trình phát hành có thể được khởi động sau đó và ở đó.

Phương pháp này có thể giúp bạn theo dõi thông lượng theo cách.