Cách quản lý tồn đọng sản phẩm / câu chuyện người dùng

Chúng tôi sắp bắt đầu một dự án mới bằng Agile (sử dụng TFS) và tôi có một vài câu hỏi "thực hành tốt" liên quan đến việc tồn đọng sản phẩm: -

Khi chúng tôi lần đầu tiên bắt đầu thêm câu chuyện của người dùng, bạn nên đặt chúng vào (nói) một lần lặp "Backlog" hoặc chỉ để trống lần lặp của họ? Rõ ràng khi đến lúc bắt đầu làm việc ở Mỹ, nó sẽ được chuyển sang tồn đọng lặp lại thích hợp.

Khi phá vỡ một thiên anh hùng ca thành những nước Mỹ nhỏ hơn, tôi có thể đơn giản đóng lại sử thi gốc, vì nó không còn cần thiết nữa? Hay tôi nên tạo ra những người Mỹ mới như những đứa trẻ của sử thi? (sau đó ai đó có trách nhiệm đóng lại bản anh hùng ca một khi tất cả các US US đã hoàn thành).

Cuối cùng, sản phẩm tồn đọng có liệt kê tất cả người Mỹ bất kể trạng thái hay chỉ những người chưa được bắt đầu (tức là trong lần lặp "Backlog" được đề xuất của tôi)?

Tôi nhận ra những câu hỏi này không phải là sống hay chết, nhưng thật tuyệt khi biết người khác quản lý các sản phẩm tồn đọng của họ như thế nào để chúng ta có thể sắp xếp mọi thứ đúng cách ngay từ đầu.

Tôi không quen thuộc với TFS (đó có phải là một công cụ phần mềm không?) Nhưng tôi có thể cung cấp cho bạn một số câu trả lời dựa trên Schwarber.

1. Thùng chứa câu chuyện

Chỉ có hai thùng chứa câu chuyện mà bạn nên nghĩ đến, tồn đọng sản phẩm và tồn đọng nước rút. Các công cụ phần mềm để theo dõi scrum có thể cho phép bạn giữ các hồ sơ nước rút cũ để phân tích lịch sử và không sao, nhưng bạn phải đóng một hồ sơ tồn đọng nước rút cũ (nghĩa là đảm bảo mọi thứ trong đó đã kết thúc hoặc chuyển ra ngoài) trước khi thực hiện bất kỳ công việc nào trên nước rút tồn đọng tiếp theo.

Đôi khi có xu hướng tạo tồn đọng của lần chạy nước rút tiếp theo trong một công cụ phần mềm trong khi vẫn ở giai đoạn nước rút hiện tại. Đừng làm điều này. Nếu tồn đọng nước rút trong tương lai đó, mọi người sẽ cố gắng đưa câu chuyện vào đó. Điều này phá vỡ quy trình lập kế hoạch phù hợp, làm gia tăng căng thẳng và gây nhầm lẫn các vấn đề lập kế hoạch.

Nếu bạn không giữ được ranh giới thích hợp giữa các lần chạy nước rút của mình thì về bản chất, bạn đang chạy nhiều lần, chạy nước rút tương tự. Bạn là người đa tác vụ. Ít nhất thì chi phí chuyển đổi nhiệm vụ sẽ làm bạn chậm lại; nghiên cứu chỉ ra rằng một chuyển đổi bối cảnh đầy đủ ở người, từ câu đố A sang câu đố B, mất 15 phút. Kinh nghiệm của tôi cho thấy lực cản này có thể bằng 50% hoặc hơn năng suất của bạn.

2. Sử thi

Giữ sử thi của bạn xung quanh. Có người hỏi về tính năng này, có lẽ họ sẽ quay lại và muốn biết tình trạng của sử thi. Người đó, bộ phận hoặc khách hàng sẽ nghĩ về 'câu chuyện' mà họ đã gửi, giờ được quảng bá thành sử thi. Họ sẽ không nghĩ về những câu chuyện nhỏ hơn có liên quan và thậm chí có thể không nhận ra rằng câu chuyện Foo có liên quan đến yêu cầu của họ. Sử thi là một tay cầm thuận tiện cho việc giao tiếp giữa phát triển và khách hàng.

Vì các sử thi không thực sự tự làm việc, chỉ là những câu chuyện liên quan, nên các sử thi chuyển trực tiếp từ sản phẩm tồn đọng của bạn sang đống thành phẩm của bạn.

3. Những câu chuyện đi đâu?

Một câu chuyện chỉ nên ở trong một container tại một thời điểm. Nó sẽ bắt đầu trong tồn đọng sản phẩm, chuyển sang tồn đọng nước rút, và sau đó được hoàn thành. Nếu ai đó đến tìm câu chuyện của họ trong sản phẩm tồn đọng và không tìm thấy nó, điều đó có nghĩa là nó đang trong quá trình hoặc kết thúc.

4. Suy nghĩ cuối cùng về việc quản lý tồn đọng sản phẩm sâu

Thứ tự lực lượng trở nên khá vô nghĩa khi bạn có hàng trăm mặt hàng tồn đọng trong sản phẩm của mình. Chắc chắn, cách bạn sắp xếp các mục 20-70 có thể khá có ý nghĩa, nhưng ai thực sự quan tâm nếu # 300 là trước hay sau # 301?

Một giải pháp khả thi cho vấn đề này là có nhiều hồ sơ tồn đọng thành phần phụ đưa vào tồn đọng sản phẩm chính. Ví dụ: bạn có thể có UI, DB, Backend, API, Cơ sở hạ tầng và Nợ kỹ thuật làm các thành phần phụ của bạn. Mỗi hồ sơ tồn đọng thành phần có thể được ủy quyền cho một người khác nhau để quản lý. Một cuộc họp định kỳ sẽ phải quyết định những câu chuyện để chuyển sang tồn đọng sản phẩm chính. Để duy trì sự cân bằng hợp lý của các câu chuyện trong hồ sơ tồn đọng sản phẩm của bạn, cách tốt nhất là quyết định một nguyên tắc (không phải là quy tắc) cho tỷ lệ các câu chuyện được quảng cáo cho hồ sơ tồn đọng chính. Một câu chuyện API cho mỗi hai câu chuyện UI? Bạn có thể lấy bao nhiêu câu chuyện từ Nợ kỹ thuật so với số lượng Câu chuyện cuối cùng bạn cần thực hiện?

Hệ thống này thêm phức tạp đáng kể và đòi hỏi nhiều sự phối hợp. Chỉ nên thực hiện khi tồn đọng sản phẩm lớn đến mức Chủ sở hữu sản phẩm không thể nghĩ về tất cả các câu chuyện cùng một lúc.

Lặp đi lặp lại trong Agile không phải là nơi chứa nhiều câu chuyện của người dùng vì đây là bản phát hành phần mềm thu nhỏ sau SDLC trong một khoảng thời gian nhỏ và dễ quản lý.

Backlog không phải là một phép lặp, về cơ bản nó là một thùng chứa cho các câu chuyện, sử thi và tác vụ của người dùng mà hiện tại bạn không có thời gian để giải quyết trong lần chạy nước rút hiện tại. Trong kế hoạch trước cho lần chạy nước rút tiếp theo, bạn nên đánh giá lại các ưu tiên hiện tại của các mục trong hồ sơ tồn đọng, so với mức độ nỗ lực để phân phối từng mục trong việc xác định những gì thuộc hoặc không thuộc về lần lặp tiếp theo.

Không lập kế hoạch nhiều hơn một lần lặp trước

Đây không phải là Agile và đánh bại toàn bộ mục đích phát triển lặp lại. Nhu cầu và yêu cầu kinh doanh thường quá biến động để lập kế hoạch dài hạn cho các yêu cầu phần mềm nghiêm ngặt, đó là lý do tại sao chúng tôi chỉ tập trung vào việc lặp lại hiện tại và kế hoạch mà chúng tôi sẽ thực hiện ngay khi chúng tôi thực hiện việc lặp lại này.

Nếu quản lý muốn ước tính dài hạn (dựa trên tồn đọng hiện tại vì nó tồn tại vào thời điểm này) thì người ta có thể nhìn vào kích thước của các hạng mục tồn đọng hiện tại để đưa ra ngày hoàn thành ước tính.

Câu hỏi của bạn về những gì lặp đi lặp lại để đưa các câu chuyện tồn đọng vào cho tôi biết rằng bạn có thể đang cố gắng lên kế hoạch lặp đi lặp lại quá xa.

Khi phá vỡ một thiên anh hùng ca thành những nước Mỹ nhỏ hơn, tôi có thể đơn giản đóng lại sử thi gốc, vì nó không còn cần thiết nữa? Hay tôi nên tạo ra những người Mỹ mới như những đứa trẻ của sử thi? (sau đó ai đó có trách nhiệm đóng lại bản anh hùng ca một khi tất cả các US US đã hoàn thành).

Một bản anh hùng ca nên được chấp nhận khi nó đạt được thỏa đáng mục tiêu kinh doanh đã nêu. Điều này về cơ bản là khi tất cả các câu chuyện người dùng trẻ em của nó đã được hoàn thành và chấp nhận.