Nợ kỹ thuật / nâng cấp công nghệ nên được lên kế hoạch như một tính năng (điểm đã cho) hoặc việc vặt (không có điểm)?

Chúng ta nên làm gì cho câu chuyện của người dùng về nợ kỹ thuật trong Pivotal Tracker? Chúng ta nên xem đây là những tính năng (cho điểm) hay là việc vặt (không cho điểm, do đó làm giảm vận tốc)?

Tôi bối rối những gì nên được coi là một việc vặt:

1. Sao chép mã - Rõ ràng rằng nếu chúng tôi đặt cùng một mã ở nhiều nơi, đó thực tế là mã thực sự xấu và cho thấy các nhà phát triển trong nhóm nên suy nghĩ nhiều hơn để bảo trì phần mềm, hãy tái cấu trúc và nhóm nên dành thời gian cho việc đánh giá mã. Vì tất cả điều này sẽ cần đến sự trưởng thành, thời gian và trải nghiệm ở cấp độ mã, tốt hơn là cung cấp ít điểm hơn để chất lượng mã không bị ảnh hưởng. Vì vậy, những sai lầm như vậy nên bị phạt và tốc độ nên được hạ xuống bằng cách không cho điểm để làm việc vặt.

2. Nâng cấp công nghệ - Giống như di chuyển để mô đun hóa JS, HTTP2, React, MVC hoặc bất kỳ công nghệ mới / tốt hơn nào khác. Các bước này sẽ làm cho hiệu suất và bảo trì mã tốt hơn. Nhưng điều này nên là việc vặt hay tính năng? Tôi tin rằng đây là thế giới công nghệ, các công nghệ mới xuất hiện mọi lúc và bạn phải chuyển sang nó. Vì vậy, tôi thấy không có điểm nào trong việc xử phạt vận tốc của đội cho công việc như vậy. Gợi ý?

3. Mã trùng lặp / Mã tiêu chuẩn phụ trong mã kế thừa - Rất ít mã được sử dụng từ lâu HOẶC khi một nhóm mới được thành lập nhưng cơ sở mã hơi cũ, chúng tôi phải đối mặt với thử thách này. Nhóm nghiên cứu cho biết họ chưa mã hóa phần này, vậy tại sao vận tốc của họ phải bị phạt bằng cách chọn các khoản nợ kỹ thuật như vậy vì họ không bao giờ tạo ra các khoản nợ đó.

4. Mã tiêu chuẩn phụ do tính cấp bách của doanh nghiệp - Đôi khi, các nhà phát triển buộc phải đẩy các tính năng ASAP trực tiếp do áp lực của đối thủ / mục tiêu / doanh nghiệp / người dùng. Có nên coi việc làm sạch mã xấu như vậy không? Đội ngũ phát triển thời gian này không có lỗi, vậy tại sao vận tốc của họ phải được kéo xuống, trong khi thực tế họ chủ yếu đặt thêm giờ trong những trường hợp như vậy.

Tôi tin rằng tất cả các loại việc vặt được đề cập ở trên, nếu được thực hiện một cách khôn ngoan, sẽ cải thiện vận tốc của đội trong tương lai. Nhưng làm thế nào chúng ta nên giữ cân bằng b / w duy trì vận tốc của đội cũng như xử phạt những lỗi kỹ thuật mà đội đang làm bằng cách đưa ra các quyết định tồi?

Câu hỏi tương tự như: Nợ kỹ thuật nên được lên lịch như một tính năng hoặc một việc vặt (hoặc một lỗi)? , nhưng tôi đã không tìm thấy câu trả lời thuyết phục bao gồm cả 4 điểm vì vậy tôi đang đăng lại nó theo một cách khác.

Câu trả lời ngắn gọn: trả nợ kỹ thuật là một việc vặt. Bạn không cung cấp chức năng mới cho người dùng cuối, vì vậy nó không được chỉ ra.

Câu trả lời chính thức:

Lỗi và công việc không thể ước tính theo mặc định

Câu chuyện tính năng được ước tính bởi vì chúng đóng góp vào giá trị kinh doanh. Lỗi và công việc được coi là một phần của chi phí sản phẩm phần mềm thông thường, chúng xuất hiện theo thời gian và là chi phí liên tục, chi phí kinh doanh liên tục. Tính toán vận tốc tự động của Tracker cho việc này là chi phí tích hợp và ước tính số lượng công việc có giá trị kinh doanh có thể được hoàn thành mỗi lần lặp. Điều này cho phép bạn tập trung kế hoạch của bạn vào giá trị kinh doanh, rủi ro và ưu tiên. Do đó, lỗi và công việc trong Tracker thường không được ước tính. Bạn có thể kích hoạt ước tính cho các lỗi và công việc trong Cài đặt dự án; tuy nhiên, chúng tôi không khuyến khích bật dự toán lỗi và việc vặt. Bạn không thể tắt nó sau nếu bạn đổi ý.

https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores

Đây là lý do tại sao các câu chuyện được phân loại là lỗi và công việc không thể có ước tính được gán cho chúng với cài đặt mặc định của PT, nhưng tôi nghĩ cũng giải thích lý do tại sao bạn không nên coi các tác vụ này là các tính năng chỉ để lấy điểm cho chúng.

Đầu tiên, tôi không nghĩ bạn nên coi việc giảm vận tốc là một hình phạt: đó chỉ là thông tin. Có lẽ đó là một điều tự nhiên, giống như một người mới tham gia mà bạn phải dành thêm thời gian đào tạo. Có lẽ đó là một điều bất ngờ làm giảm khả năng của bạn (ví dụ như bệnh tật) hoặc tiêu thụ thêm (ví dụ: lỗi "ngăn chặn thế giới"). Có lẽ bạn đã không ước tính tốt các tính năng, vì bất kỳ lý do gì; đây là điều bạn có thể học hỏi Hoặc có lẽ là do bạn đã quyết định, với tư cách là một nhóm, ưu tiên thanh toán một số khoản nợ kỹ thuật hơn là cung cấp các tính năng mới (và có thể phát sinh thêm nợ).

Thứ hai, nó không nhất thiết là một sai lầm để phát sinh nợ kỹ thuật. Chẳng phải là lý tưởng để vô tình phát sinh nó , nhưng nếu bạn quyết định xây dựng thứ "nhanh và bẩn" ngay bây giờ theo kiến ​​thức mà bạn sẽ cần phải dọn dẹp sau này, chẳng hạn để bạn có thể nhận được nhiều phản hồi của người dùng hơn hoặc gặp khó khăn hạn chót, đó là một lựa chọn có chủ ý mà bạn đã thực hiện với tư cách là một nhóm và vẫn ổn.

Về việc một cái gì đó có phải là một tính năng hay không, một nguyên tắc đơn giản là: người dùng cuối có quan tâm không? Bạn đề cập đến việc cải thiện SEO: đây có phải là điều mà họ quan tâm không? Hiệu suất mà họ có thể quan tâm, nhưng mặt khác, có lẽ họ muốn có một số tính năng mới hơn so với cùng một công cụ với thời gian tải vài trăm mili giây. Thực hiện một số nghiên cứu: đi và hỏi họ những gì họ muốn. Hãy để họ giúp bạn ưu tiên những gì tốt nhất để dành thời gian cho đội.

Bạn có thể quyết định rằng các lựa chọn công nghệ hiện tại của bạn đang ngăn cản bạn cung cấp các tính năng nhất định hiệu quả như bạn muốn, trong trường hợp đó hoàn toàn hợp lý để (một lần nữa, cố tình) dành thời gian di chuyển tất cả hoặc một phần của ứng dụng sang một thứ mới.

Tôi tin rằng tất cả các loại việc vặt được đề cập ở trên, nếu được thực hiện một cách khôn ngoan, sẽ cải thiện vận tốc của đội trong tương lai.

Ở đây tôi hoàn toàn đồng ý với bạn, nhưng sau đó không nhận được điểm cho những việc lặt vặt này? Nếu bạn đang thực hiện công việc để bạn có thể cung cấp nhiều tính năng hơn sau đó, thì bạn sẽ thấy tốc độ cao hơn sau khi bạn thực hiện nó, chứ không phải trong khi bạn đang thực hiện nó.

Ngoài ra, những thứ như đánh giá mã và tái cấu trúc cơ bản trong quá trình phân phối (ví dụ: phần "tái cấu trúc" của chu trình TDD) đã là một phần của công việc đang diễn ra của bạn và do đó đã được đưa vào như một phần của vận tốc chung của nhóm.

Tiết lộ : Tôi là một Pivot, làm việc cho Pivotal Labs ở London, nhưng không thuộc nhóm Tracker.

Chỉ cần là người tương đối, chúng tôi xử lý các lỗi và nợ kỹ thuật như bất kỳ PBI nào khác. Trên thực tế, chúng ta thậm chí không có loại "lỗi". Tất cả mọi thứ là một PBI. Backlog của chúng tôi được sắp xếp theo giá trị kinh doanh được gán cho PBI. Do đó, một lỗi nổi bật đối với người dùng đang gây ra sự cố sẽ có giá trị kinh doanh cao được gán cho nó, vì bạn có nguy cơ mất tiền với những thứ tương tự, và đó có thể sẽ là một trong những điều đầu tiên được thực hiện. Mặt khác, một lỗi không thực sự có nhiều tác động và không ảnh hưởng đến điểm mấu chốt sẽ có giá trị kinh doanh tương đối thấp và có thể không được khắc phục trong một thời gian. Đó là một bức tường tinh thần quan trọng cần được phá bỏ: không phải mọi lỗi đều phải được sửa. Nghe có vẻ như bất khả xâm phạm, tôi biết, nhưng nếu nỗ lực sửa lỗi nhiều hơn giá trị doanh nghiệp sửa chữa thì nó sẽ mang lại, thì ROI âm. Đối xử với mọi thứ như một PBI cho phép bạn tự do đưa ra các loại quyết định theo kinh nghiệm này mà không bị phân tâm chỉ vì đó là một "lỗi".

Tương tự như vậy, với nợ kỹ thuật, vẫn còn rất nhiều giá trị kinh doanh. Một số nợ kỹ thuật có thể phát sinh với rất ít chi phí và có thể tồn tại lâu dài, nhưng một số nợ kỹ thuật sẽ giết chết doanh nghiệp của bạn theo thời gian và do đó có giá trị kinh doanh rất cao. Chìa khóa một lần nữa là nhận ra rằng mọi thứ chỉ là PBI. Mọi thứ đều đi vào tồn đọng và bạn làm việc trên các mục trong hồ sơ tồn đọng đó dựa trên giá trị họ thêm vào doanh nghiệp. Cho dù đó là một tính năng, một lỗi, hoặc nợ kỹ thuật thực sự là vấn đề quan trọng.

Điều này cũng có lợi ích của việc bỏ qua hoàn toàn câu hỏi của bạn. Vì mọi thứ đều là PBI, mọi thứ đều đóng góp vào vận tốc. Ý tưởng thực hiện công việc không thực sự có kích thước và được tính trong vận tốc của bạn là một điều điên rồ với tôi. Về cơ bản bạn đang tạo ra một lỗ đen khổng lồ trong dữ liệu thực nghiệm của bạn. Vận tốc đã là một số liệu khá thô, đó là một ước tính dựa trên ước tính dựa trên các ước tính thậm chí nhiều hơn. Thêm vào một loạt các công việc khác nhau không được theo dõi, và bây giờ con số này là tất cả nhưng vô nghĩa. Tất cả mọi thứ nhóm của bạn làm trong một lần chạy nước rút là một phần của vận tốc của bạn.