Xử lý công việc có liên quan trên đường sắt trong một mục công việc nhanh nhẹn

Tôi thuộc nhóm dự án gồm 4 nhà phát triển, bao gồm cả bản thân tôi. Chúng tôi đã có một cuộc thảo luận dài về cách xử lý công việc bổ sung xuất hiện trong quá trình của một mục công việc duy nhất.

Công việc làm thêm này thường là những thứ hơi liên quan đến nhiệm vụ, nhưng không phải lúc nào cũng cần thiết để hoàn thành mục tiêu của mục (đó có thể là một ý kiến). Ví dụ bao gồm nhưng không giới hạn ở:

• tái cấu trúc mã được thay đổi bởi mục công việc
• tái cấu trúc mã lân cận mã được thay đổi bởi mục
• kiến trúc lại khu vực mã lớn hơn xung quanh vé. Ví dụ: nếu một mục có bạn thay đổi một chức năng, bạn nhận ra toàn bộ lớp bây giờ có thể được làm lại để phù hợp hơn với thay đổi này.
• cải thiện giao diện người dùng trên một hình thức bạn vừa sửa đổi

Khi công việc làm thêm này nhỏ, chúng tôi không bận tâm. Vấn đề là khi công việc bổ sung này gây ra sự mở rộng đáng kể của mặt hàng vượt ra ngoài ước tính điểm tính năng ban đầu. Đôi khi một mục 5 điểm thực sự sẽ mất 13 điểm thời gian. Trong một trường hợp, chúng tôi đã có một mục 13 điểm mà nhìn lại có thể đã được 80 điểm trở lên.

Có hai lựa chọn xung quanh trong cuộc thảo luận của chúng tôi về cách xử lý việc này.

1. Chúng ta có thể chấp nhận công việc làm thêm trong cùng một mục công việc và viết nó ra dưới dạng ước tính sai. Đối số cho điều này đã bao gồm:

   • Chúng tôi lên kế hoạch "đệm" vào cuối giai đoạn nước rút để giải thích cho việc này.
   • Luôn để lại mã trong hình dạng tốt hơn bạn tìm thấy nó. Đừng kiểm tra công việc nửa vời.
   • Nếu chúng ta rời khỏi tái cấu trúc để sau này, thật khó để lên lịch và có thể không bao giờ được thực hiện.
   • Bây giờ bạn đang ở trong "bối cảnh" tinh thần tốt nhất để xử lý công việc này, vì bạn đã hiểu sâu về mã. Tốt hơn là đưa nó ra khỏi đường ngay bây giờ và hiệu quả hơn là mất bối cảnh đó khi bạn quay lại sau.

2. Chúng tôi vẽ một dòng cho mục công việc hiện tại và nói rằng công việc làm thêm đi vào một vé riêng. Các đối số bao gồm:

   • Có một vé riêng cho phép ước tính mới, vì vậy chúng tôi không nói dối bản thân về việc có bao nhiêu điểm thực sự, hoặc phải thừa nhận rằng tất cả các ước tính của chúng tôi là khủng khiếp.
   • Chạy nước rút "đệm" có nghĩa là cho những thách thức kỹ thuật bất ngờ là rào cản trực tiếp để hoàn thành các yêu cầu vé. Nó không dành cho các mặt hàng phụ chỉ là "những thứ tốt đẹp".
   • Nếu bạn muốn lên lịch tái cấu trúc, chỉ cần đặt nó ở đầu của hồ sơ tồn đọng.
   • Không có cách nào để chúng tôi tính toán chính xác các công cụ này trong một ước tính, vì nó có vẻ hơi độc đoán khi đưa ra. Một người đánh giá mã có thể nói "những điều khiển UI đó (mà bạn thực sự không sửa đổi trong mục công việc này) hơi khó hiểu, bạn có thể sửa nó không?" giống như một giờ, nhưng họ có thể nói "Chà nếu điều khiển này bây giờ thừa hưởng từ cùng một lớp cơ sở với các lớp khác, tại sao bạn không chuyển tất cả (hàng trăm dòng) mã này vào cơ sở và tua lại tất cả những thứ này , tầng thay đổi, v.v.? " Và phải mất một tuần.
   • Nó "làm ô nhiễm hiện trường vụ án" bằng cách thêm các công việc không liên quan vào vé, làm cho ước tính điểm tính năng ban đầu của chúng tôi trở nên vô nghĩa.
   • Trong một số trường hợp, công việc làm thêm sẽ hoãn đăng ký, gây chặn giữa các nhà phát triển.

Một số người trong chúng ta hiện đang nói rằng chúng ta nên quyết định cắt giảm, như nếu các công cụ bổ sung ít hơn 2 FP, thì nó sẽ nằm trong cùng một vé, nếu có nhiều hơn, hãy biến nó thành một vé mới.

Vì chúng tôi chỉ mới sử dụng Agile vài tháng, ý kiến ​​của tất cả các cựu chiến binh Agile dày dạn hơn ở đây về cách xử lý vấn đề này?

Lập kế hoạch nhanh và câu chuyện người dùng được tập trung vào việc cung cấp giá trị và tính minh bạch cho các bên liên quan của dự án và người dùng phần mềm. Đây là một điều tốt, nhưng nó không và không nên thay thế, bao gồm hoặc giảm bớt tầm quan trọng của hướng dẫn kiến ​​trúc tốt, quản lý thiết kế, thực hành phát triển tốt và duy trì nợ kỹ thuật.

Agile không làm tốt điều này vì nó không nhằm mục đích trả lời cho những vấn đề và vấn đề kỹ thuật chủ yếu này.

Biết rằng tôi rất không đồng ý rằng việc tái cấu trúc các nhiệm vụ, xử lý nợ kỹ thuật và công việc thiết kế nên giải thích cho các câu chuyện của người dùng riêng biệt trong một lần chạy nước rút nhất định. Đây chỉ là các nhiệm vụ mà nhà phát triển có thể thực hiện để giúp đáp ứng câu chuyện của người dùng cho lần chạy nước rút đó.

Hãy nhớ rằng Nhiệm vụ là bất kỳ đơn vị công việc có thể phân công nào giúp chuyển câu chuyện người dùng nhất định đến hoàn thành trong hướng dẫn kiến ​​trúc và duy trì toàn bộ thiết kế và thực hành phát triển của phần mềm.

Đây là lý do tại sao việc ước tính giờ nên có trong các nhiệm vụ chứ không phải trên các câu chuyện của người dùng. Đây cũng là lý do tại sao một số tác vụ rất quan trọng đối với việc hoàn thành nhiều câu chuyện của người dùng.

Đỏ, Xanh, Tái cấu trúc. Đó là phạm vi của một mục công việc duy nhất. Viết một bộ kiểm tra thất bại bao gồm phạm vi thay đổi, mã số lượng tối thiểu cần thiết để vượt qua bài kiểm tra của bạn, sau đó tái cấu trúc để đáp ứng các tiêu chuẩn mã hóa trong khi vẫn vượt qua các bài kiểm tra. Tất cả ba bước này là bắt buộc; bạn không thể mã hóa giải pháp cho đến khi bạn xác định được vấn đề, nếu bạn tái cấu trúc khi bạn viết dòng mã, bạn sẽ luôn vi phạm YAGNI, nhưng nếu bạn không tự mình đứng sau và tái cấu trúc sau khi vượt qua các bài kiểm tra, theo định nghĩa, bạn sẽ phải chịu nợ kỹ thuật rằng cuối cùng bạn sẽ phải trả nợ.

Đưa ra định nghĩa này và nó đã được tuân theo, một con trỏ 5 mà hóa ra là 13 con trỏ là một ước lượng sai. Những gì bạn sẽ xem xét tái cấu trúc công việc có lẽ giống như tái cấu trúc; bạn phải tổ chức lại một khu vực khá quan trọng của cơ sở mã để chức năng mới được đưa vào một cách dễ hiểu, có thể duy trì được. Điều đó thường chỉ ra sự thất bại của nhóm trong việc hiểu con đường phát triển chung trong tương lai, dẫn đến một điều gì đó được thực hiện rất đơn giản trong một lần lặp trước đó khi cuối cùng nó sẽ được yêu cầu rất RẮN. Giao tiếp tốt hơn giữa các BA và PM, những người biết những gì sâu hơn trong hồ sơ tồn đọng và nhóm phát triển thường tập trung vào giai đoạn nước rút hiện tại, có thể giảm thiểu điều này. Thay phiên, câu chuyện này cho thấy một số lượng lớn nợ kỹ thuật phát sinh trong quá khứ, và nó chỉ đơn giản là bắt kịp với đội. Các quy trình xem xét mã tốt hơn, ngoài kiến ​​thức khái niệm tốt hơn về các mẫu thiết kế và về con đường tương lai chung của dự án, có thể giúp giảm các sự cố như vậy.

Một điều cần lưu ý là tái cấu trúc là công việc "không lý tưởng". Trong Agile SCRUM, các nhiệm vụ được ước tính trong "giờ lý tưởng"; đó là, số giờ dành cho việc viết mã hoàn toàn mới chưa từng tồn tại và làm xáo trộn cơ sở tính năng của dự án. Một ngày phát triển 8 giờ có thể thực tế chỉ có 5 giờ lý tưởng; đôi khi bạn có thể tin tưởng vào 6, đặc biệt là trong "đoạn đường" của dự án nơi nhóm thực sự ồn ào. Tái cấu trúc, hoặc quay trở lại và thực hiện các thay đổi không ảnh hưởng đến chức năng của dự án nhưng cải thiện cơ sở mã theo những cách khác, là công việc không lý tưởng, như lập kế hoạch, thiết kế, giao tiếp, đánh giá, nghỉ hoặc ngừng hoạt động kỹ thuật. Khác với thời gian chết kỹ thuật, công việc không lý tưởng là quan trọng, nhưng không đạt được tiến bộ trong mắt chủ sở hữu sản phẩm.

Vì vậy, với điều kiện là tái cấu trúc không gấp đôi số giờ thực tế đã bỏ ra, một số lượng công việc tái cấu trúc nhất định sẽ được dự kiến ​​khi bạn ước tính trong giờ lý tưởng. Giả sử, vì tôi không biết chính xác thang điểm của nhóm bạn được hiệu chỉnh như thế nào, rằng một con trỏ 5 tương đương với một tuần nhà phát triển lý tưởng, hoặc khoảng 25 giờ lý tưởng. Con số 5, biến thành con số 13 (hơn hai tuần của nhà phát triển theo cùng một tỷ lệ), là nguyên nhân cho một số hồi tưởng về nguyên nhân gây ra sự phức tạp. Có lẽ codebase không cần tái cấu trúc nhiều như đã thực hiện, có lẽ một khoản nợ kỹ thuật lớn đã chồng chất không biết đến nhóm phải giải quyết để làm cho các tính năng mới hoạt động,

Trong một vũ trụ thay thế, hãy tưởng tượng rằng 5 như ước tính trong giờ lý tưởng đã trở thành 7 (~ 35 giờ) dựa trên số giờ thực tế, bởi vì bạn cần 10 giờ tái cấu trúc bổ sung để đưa mã mới và một số bit trước đó vào đúng mẫu thiết kế kiến ​​trúc. Trong trường hợp đó, phần bổ sung nằm trong "khoảng cách" giữa lý tưởng và tổng số giờ trong số ngày nhà phát triển được cho là câu chuyện. Vì vậy, với tư cách là người quản lý dự án, tôi gọi số 5 trở thành số 7 ước tính hợp lý và tiếp tục.

Điểm câu chuyện là một ước tính về độ phức tạp tương đối của một câu chuyện người dùng nhất định. Có vẻ như bạn đang sử dụng các điểm câu chuyện để nói rằng điều này sẽ mất X man ngày / giờ. Thay vào đó, phấn đấu cho hai mục tiêu

1. Chia nhỏ các câu chuyện cho đến khi chúng ở trong một phạm vi nhất quán (3, 5 hoặc 8 điểm)
2. Giả sử rằng câu chuyện bao gồm bất kỳ tái cấu trúc cần thiết

Theo thời gian điều này sẽ cung cấp cho bạn một đường cơ sở cho vận tốc. Mỗi câu chuyện 5 điểm sẽ không mất cùng thời gian với những câu chuyện khác nhưng vận tốc trung bình trên mỗi lần chạy nước rút (bao nhiêu điểm câu chuyện mà nhóm có thể hoàn thành) sẽ nhất quán.

Lo lắng về việc một câu chuyện cụ thể sẽ mất bao nhiêu thời gian là phản tác dụng. Các ước tính chỉ tính trung bình trên các câu chuyện có kích thước nhất quán về khối lượng (con trỏ IE một 5 có thể mất nhiều thời gian hơn do tái cấu trúc nhưng bạn nhận được lợi ích của nỗ lực đó trên một câu chuyện liên quan).

Cần có một sự cắt giảm tương đối về số lượng trong mục công việc ban đầu và bao nhiêu là một thứ khác. Câu chuyện của người dùng là điểm khởi đầu cho các cuộc thảo luận và do đó có thể có tất cả các loại yếu tố phạm vi để tìm hiểu trong khi chạy nước rút trong khi thực hiện một câu chuyện.

Có thể đôi khi trong kế hoạch chạy nước rút, một câu chuyện có thể được thêm các tiêu chí bổ sung vào đó để tránh "creep scope" có thể xảy ra khi người dùng muốn một hình thức mới và sau đó 101 thay đổi thành hình thức đó không thực tế đôi khi được thực hiện trong nước rút 2 tuần.

Một mặt trái cần lưu ý là có bao nhiêu giá trị thu được từ công việc làm thêm này. Có thể có hàng tấn tái cấu trúc có thể được thực hiện nhưng có bao nhiêu lợi ích cho bất cứ ai cho tất cả các công việc đó? Đây là nơi phải có một số hướng dẫn để giúp nhóm làm việc tốt nhưng không bị lạc trong việc cố gắng làm cho mã hoàn hảo.