Trong Scrum, bạn có nên phân chia tồn đọng trong một tồn đọng chức năng và tồn đọng kỹ thuật hay không?

Trong các nhóm Scrum của chúng tôi, chúng tôi sử dụng một hồ sơ tồn đọng, chủ yếu chứa các chủ đề chức năng, nhưng đôi khi cũng chứa các chủ đề kỹ thuật. Ưu điểm của việc có 1 backlog là dễ dàng chọn chủ đề cho lần chạy nước rút tiếp theo, nhưng tôi có một số câu hỏi:

• Đầu tiên, đối với tôi có vẻ hợp lý hơn khi có một hồ sơ kỹ thuật riêng biệt, trong đó chính các nhà phát triển có thể thêm các mục kỹ thuật thuần túy, như: chúng tôi có thể cải thiện hiệu suất trong phương pháp này, lớp này thiếu một số tài liệu kỹ thuật, ... Bằng cách có một hồ sơ tồn đọng, tất cả các nhà phát triển luôn phải thông qua chủ sở hữu sản phẩm để thêm chủ đề của họ vào hồ sơ tồn đọng, có vẻ như là công việc bổ sung, không cần thiết cho chủ sở hữu sản phẩm.
• Thứ hai, nếu bạn có chủ sở hữu sản phẩm chỉ tập trung vào các mặt hàng chức năng thuần túy, các mặt hàng kỹ thuật thuần túy (như thiếu tài liệu kỹ thuật, mã bị xói mòn và nên được tái cấu trúc, các lớp luôn gặp sự cố trong quá trình gỡ lỗi vì chúng không có một nền tảng ổn định và cần được tái cấu trúc, ...) luôn kết thúc ở cuối danh sách vì "họ không phục vụ khách hàng trực tiếp". Bằng cách có một tồn đọng kỹ thuật riêng biệt và thời gian dành riêng cho mỗi lần chạy nước rút cho các hạng mục kỹ thuật thuần túy này, chúng tôi có thể cải thiện các ứng dụng một cách chức năng, nhưng cũng giữ cho chúng khỏe mạnh bên trong.

Đâu là cách tiếp cận lí tưởng nhất? Một hoặc hai tồn đọng?

Tôi không phải là chuyên gia nhưng tôi muốn nói rằng bạn chỉ có thể có một hồ sơ tồn đọng cho mỗi đội. Nhóm cần quyết định vấn đề nào là khẩn cấp và vấn đề nào có thể được hoãn lại. Nếu bạn phân tách các vấn đề thành các loại ngăn xếp riêng biệt, bạn đi ngược lại ý tưởng cốt lõi là cốt lõi của scrum, đó là có một nhóm vấn đề và mỗi lần chạy nước rút mà nhóm làm việc khẩn cấp nhất trong số chúng. Nếu bạn (phụ) chia các nhóm, bạn có thể phân chia các loại nhiệm vụ có liên quan đến họ, nhưng về cơ bản, bạn sẽ thiết lập các nhóm hoạt động song song. Sự khẩn cấp / cần thiết là người quyết định số một khi lên kế hoạch cho lần chạy nước rút tiếp theo. Bạn có thể phân loại các nhiệm vụ, nhưng điều này không nên cản trở quá trình quyết định của bạn.

Tôi muốn thêm tiếng nói của mình cho những người đề xuất một hồ sơ tồn đọng cho mỗi sản phẩm. Tạo một hồ sơ tồn đọng khác là một phản ứng hợp lý, nhưng thực sự chỉ là tránh vấn đề cốt lõi: Tại sao Chủ sở hữu sản phẩm không ưu tiên các mặt hàng kỹ thuật hơn các mặt hàng tính năng? Bạn nên tập trung vào giải quyết điều này hơn là làm việc xung quanh nó. Bạn có thể sử dụng kỹ thuật 5 Whys , ví dụ, để cố gắng đi đến tận cùng của mọi thứ.

Có thể có nhiều lý do tại sao PO không ưu tiên các vấn đề kỹ thuật. Ví dụ, có thể nhóm công nghệ không giải thích chi phí dài hạn (bằng $$$) khi không giải quyết được nợ kỹ thuật. Có lẽ đó là một cái gì đó hoàn toàn khác. Có một cơ hội tốt đó là vấn đề giao tiếp, và giải pháp lâu dài là giải quyết nó và giải quyết nó - loại bỏ trở ngại.

Ngoài ra, tôi có một câu hỏi khác để bạn suy nghĩ: Tại sao đầu tiên nợ kỹ thuật lại phát sinh? Công việc lý tưởng như tái cấu trúc, v.v. nên xảy ra trong các câu chuyện chức năng và được hoàn thành trong giai đoạn nước rút. Chúng không nên là những câu chuyện thêm theo cách riêng của chúng nếu không bạn không có khả năng có thể chuyển mã.

Những gì bạn đang đề cập thường được gọi là 'nợ kỹ thuật'. Đôi khi có thể khó thấy được cách thức hoạt động của nợ kỹ thuật phù hợp với quy trình scrum, giống như cách mà các khiếm khuyết có thể xảy ra.

Những gì bạn đang đề xuất cũng tương tự như đề xuất rằng cũng có một "lỗi tồn đọng" riêng biệt, chia tách tồn đọng thành 3.

Cá nhân, tôi sẽ không ủng hộ việc chia tách tồn đọng sản phẩm. Ý tưởng của tồn đọng sản phẩm là đại diện cho các mục công việc xuất sắc . Từ quan điểm đó, sự khác biệt duy nhất giữa một tính năng và một khoản nợ kỹ thuật là yêu cầu đến từ nhóm phát triển, không phải từ khách hàng. Nó vẫn là một mục công việc và nó vẫn cần phải được quản lý, bao gồm cả việc ưu tiên nó so với các mục công việc khác. Điều này đặc biệt đúng nếu mục nợ kỹ thuật yêu cầu thử nghiệm, trong trường hợp đó, nó phải trải qua chính xác quy trình QA giống như một tính năng thông thường.

Tôi đồng ý với Onno rằng chỉ nên có một hồ sơ tồn đọng duy nhất cho mỗi dự án. Mặt khác, nhóm về cơ bản đang nắm trong tay một số quyết định thuộc về chủ sở hữu sản phẩm.

Ngay cả các mặt hàng "thuần túy kỹ thuật" cũng phải có một số giá trị thực tế cho người dùng (và do đó đối với chủ sở hữu sản phẩm) để đủ điều kiện cho tồn đọng nước rút. Nhiệm vụ của bạn là giải thích lợi ích của những điều này cho chủ sở hữu sản phẩm và thuyết phục anh ấy / cô ấy về giá trị gia tăng để chứng minh chi phí. Và quá trình này buộc bạn phải suy nghĩ về những vấn đề này và chọn những thay đổi kỹ thuật mang lại giá trị cao nhất cho dự án với ít nỗ lực nhất.

Tôi đồng tình với tất cả các câu trả lời ở trên. Trong sức nóng của thực tế thương mại, PO sẽ tiếp tục ưu tiên các câu chuyện chức năng hơn các câu chuyện kỹ thuật. Thường đến sự thất vọng của đội. Nhóm nên kiềm chế các câu chuyện kỹ thuật mà không có bất kỳ giá trị người dùng nào (ai quan tâm đến việc tối ưu hóa, nếu tốc độ không phải là vấn đề?) Và học cách xem một số nhiệm vụ kỹ thuật khác theo ngụ ý của các câu chuyện chức năng. "Định nghĩa hoàn thành" cũng đóng một vai trò lớn. Các câu chuyện chức năng còn lại đi vào tồn đọng để PO ưu tiên.

Ví dụ: Tài liệu kỹ thuật: Tính khả dụng của tài liệu kỹ thuật (nếu có) là một mục tiêu biểu thuộc DOD và do đó, việc cập nhật nó được NGAY LẬP TỨC với mọi câu chuyện chức năng.

Ví dụ: Mã tái cấu trúc: nên được thực hiện khi nó mang lại lợi ích cho việc phát triển sản phẩm. Không sớm hơn (nhóm không nên giả định sản phẩm sẽ phát triển theo hướng nào) và không muộn hơn khi nó đã biến thành nợ kỹ thuật. Việc xem xét thiết kế cũng có thể là một phần của DoD.

Tôi đồng ý với MelR. Nếu có bất cứ điều gì đó là 'kỹ thuật', chúng ta cần phải nhìn vào lý do tại sao chúng tôi đang làm nó - hoặc thậm chí là ngắn hạn và dài hạn là những gì nhân quả (cho người sử dụng) ?.

Tôi đã thấy nhiều hồ sơ tồn đọng trong đó cái gọi là 'nhiệm vụ kỹ thuật' có thể dễ dàng được viết theo kiểu giá trị kinh doanh.

Nhiệm vụ kỹ thuật cũng thường là kết quả của những câu chuyện lớn bị phá vỡ vì nó có thể là cách dễ dàng hơn để phá vỡ mọi thứ. Nhưng điều này có thể gây ra sự lặp lại chậm hơn của giá trị gia tăng thực sự (hoặc cơ hội phản hồi) hoặc thậm chí tệ hơn là sự thất bại của nước rút.

Liên quan đến "mã bị xói mòn và nên được tái cấu trúc" như Patrick đề cập, tôi tin rằng chúng ta cần phải hỏi - khu vực nào của chức năng hệ thống mà mã đó ảnh hưởng? và ảnh hưởng lâu dài đến người dùng là gì nếu chúng ta không tái cấu trúc nó bây giờ?

Sau đó, có chủ đề "để mọi thứ tốt hơn một chút so với cách chúng tôi tìm thấy" để giảm nợ kỹ thuật dài hạn và điều này có thể được thực hiện như một phần của những câu chuyện nhỏ trong mỗi lần chạy nước rút mà không ảnh hưởng quá nhiều đến dự án rộng lớn hơn không?

Cuối cùng, tôi không thấy sự cần thiết của hai hồ sơ tồn đọng, điều này mở ra cơ hội để làm chậm các nhu cầu ưu tiên đúng cách - nhưng cần có một chủ sở hữu sản phẩm được giáo dục về các mối quan tâm của các tác động kỹ thuật và có khả năng mạnh mẽ để xác định giá trị thực để chia nhỏ các câu chuyện theo chiều dọc - Adobe cung cấp một lời giải thích tốt về cắt dọc .

Không, bạn không bao giờ nên tạo ra những câu chuyện kỹ thuật. Đây là một lỗi phổ biến. Câu chuyện của bạn phải phản ánh yêu cầu kinh doanh. Công cụ kỹ thuật không bao giờ thực sự từ yêu cầu kinh doanh. Đây là vai trò của chủ scrum và nhóm để đánh giá tất cả các nhiệm vụ kỹ thuật mà họ sẽ phải làm để đạt được mục tiêu hoặc câu chuyện.

Nếu câu chuyện của bạn là về việc tạo một màn hình đăng nhập chẳng hạn, bạn sẽ phải xem xét việc tạo cơ sở dữ liệu nếu chưa được tạo.

Tôi không thấy vấn đề cần tạo, với PO, các tác vụ trong đó nhóm CNTT là người dùng. Nếu PO có thể hiểu nhiệm vụ và có thể được đánh giá theo giá trị doanh nghiệp thì có, bạn có cách để tạo ra các loại câu chuyện kỹ thuật. Bạn chỉ cần sử dụng hệ thống.