Làm thế nào để mô hình hóa việc chuẩn bị câu chuyện cho các vấn đề được giải quyết trong một số dự án

Trong công ty của chúng tôi, một số nhóm sẽ làm việc trên các thành phần khác nhau của một số dự án cùng một lúc. Ví dụ: một nhóm có thể tạo ra các loại phần mềm (hoặc phần cứng) cụ thể cho một số dự án, một nhóm khác là một loại phần mềm cụ thể khác. Chúng tôi sử dụng các dự án Jira để lưu trữ các vấn đề cho các dự án cụ thể và bảng Jira để chạy nước rút cho các đội khác nhau.

Chúng tôi phải đối mặt với vấn đề tránh sao chép mã giữa các dự án và đã phát triển một bộ thư viện cốt lõi mà chúng tôi sử dụng trong các dự án đó. Khi làm việc trên một dự án, một số nhà phát triển sẽ nhận ra rằng một đoạn mã họ đã viết được quan tâm nhiều hơn và nên được trích xuất vào thư viện lõi hoặc một số mã lõi mà họ đang sử dụng có lỗi, cần thêm một số tham số hoặc tính năng mới ... bạn đặt tên cho nó.

Vì vậy, họ tạo ra một vấn đề thư viện cốt lõi đi vào tồn đọng của dự án cốt lõi. Tất cả các vấn đề này được xem xét, ưu tiên và ước tính trong một cuộc họp thư viện cốt lõi (mỗi tuần một lần) và sẽ được giải quyết theo mức độ ưu tiên của chúng (bên cạnh các vấn đề cụ thể của dự án) trong một số lần chạy nước rút trong tương lai.

Ưu tiên được thực hiện bằng cách sắp xếp các vấn đề và chúng tôi đặt sortednhãn cho các vấn đề được sắp xếp (để chúng tôi có thể tìm kiếm các vấn đề không được sắp xếp). Sau đó, chúng tôi tự đặt một vấn đề cho mỗi thành phần cốt lõi lên trên cùng của hồ sơ tồn đọng để chúng được xử lý trước. Khi một số đội đặt vấn đề như vậy vào giai đoạn nước rút của họ, họ phải tự kéo một mục khác lên trên cùng của hồ sơ tồn đọng.

Điều này khá dễ bị lỗi. Về cơ bản, những gì chúng ta có là các trạng thái vấn đề bổ sung "được sắp xếp" và "ước tính" giữa "mở" và "đang tiến hành". Phản ánh điều này thông qua sortednhãn và vị trí của chúng trong bảng khá cồng kềnh và dễ bị lỗi. (Ví dụ: nếu ai đó di chuyển một vấn đề trong một số lần chạy nước rút lên xuống, điều này sẽ được phản ánh trong bảng cốt lõi, âm thầm xáo trộn thứ tự các vấn đề mà nhóm có thể đã quyết định trong một cuộc thảo luận rộng rãi trước đó.)

Vì vậy, điều gì sẽ là một cách tốt hơn để thực hiện điều này?

Nếu bạn muốn theo dõi điều này trong JIRA, tôi sẽ theo dõi nó như thể đó là một nhiệm vụ mới.

Ví dụ:

Giả sử bạn có câu chuyện CORE-75: Foo the Bar .

Khi đã quyết định đội nào sẽ nhận nhiệm vụ, họ có thể tạo một nhiệm vụ mới: HPORT TRỢ-123: Foo the Bar in Core .

Sau đó, bạn có thể chặn CORE-75 với HPORT TRỢ-123 . Sau khi HPORT TRỢ-123 kết thúc, bạn có thể quay lại CORE-75 . Hoặc bạn có thể hợp nhất các đánh giá hoặc xem lại mã hai lần (một lần bởi nhóm được chỉ định, một lần bởi một nhóm cụ thể cốt lõi hơn).

Đây thực sự là những gì bạn đang làm: Hãy coi thư viện cốt lõi là sản phẩm / khách hàng của chính mình, đừng đi nửa đường.

Một cách tiếp cận là nhóm nghiên cứu tạo ra một vấn đề mới cho lần chạy nước rút của họ liên kết trở lại vấn đề thư viện cốt lõi. Nó giống như bạn đang thực hiện một nhiệm vụ phụ cho một nhiệm vụ nhưng trên các bảng / tồn đọng.

Một cách tiếp cận khác là chỉ theo dõi điều này một cách riêng biệt bên ngoài JIRA. Xuất các hồ sơ tồn đọng hiện có dưới dạng CSV hoặc bảng tính và tổ chức đó.

Bằng cách tách biệt các vấn đề khỏi JIRA, bạn có thể linh hoạt xác định mức độ ưu tiên trong cuộc họp lập kế hoạch và không phải lo lắng về thuật toán sắp xếp của JIRA trên bảng và bạn cũng sẽ không phải sử dụng nhãn.

Trong cuộc họp lập kế hoạch ưu tiên cho thư viện lõi, bạn có thể tạo một danh sách ngắn các nhiệm vụ cần hoàn thành cho thư viện lõi và bất kỳ ai chịu trách nhiệm / chịu trách nhiệm cho thư viện lõi có thể đảm bảo các nhiệm vụ này được bắt đầu bởi các nhóm dự án khác nhau và hoàn thành.

Có quan điểm cho rằng các Thư viện lõi đóng gói rất nhiều chức năng phổ biến, nhưng không liên quan là một 'điều xấu' (tm)

Có một vài lý do cho việc này

• Họ lấy các phụ thuộc và mã mà bạn không cần
• Thay đổi chúng gây ra thay đổi cho tất cả các ứng dụng
• Không có 'chủ sở hữu' duy nhất

Trong trường hợp của bạn, tôi nghĩ rằng việc phân chia nhiệm vụ của bạn theo ứng dụng, sự thay đổi sẽ được thực hiện là gốc rễ của vấn đề. Một loại luật ngược của Conway.

Tôi nghĩ rằng giải pháp tốt nhất cho bạn là tránh xa việc có 'Thư viện lõi' Thư viện nên có một bộ (nhỏ) cụ thể của chức năng được nhóm hợp lý. Nó có thể được hoàn thành chúng. tức là JsonParser, LogWriter, v.v ... hiếm khi có ý nghĩa để thêm một tính năng mới.

Tuy nhiên, giả sử đây sẽ là một nhiệm vụ dài và khó khăn, vì là một giải pháp thứ cấp, tôi chỉ đơn giản là giữ các nhiệm vụ thư viện cốt lõi với nhóm cần chức năng. I E.

Nhiệm vụ: thêm tính năng X vào sản phẩm Y

Dev: hmm một số mã cho tính năng X nên có trong thư viện corel .. Tôi sẽ đặt nó ở đó như một phần của nhiệm vụ này