Là mã tái cấu trúc ngẫu nhiên được phép trong scrum

Lý lịch

• Nhóm của tôi sử dụng scrum
• Tôi hiện không có nhiệm vụ được giao
• Không có thêm nhiệm vụ chờ xử lý trong backlog
• Hôm nay là ngày Lao động cho khách hàng của tôi.

Không có nhiều việc phải làm hôm nay tôi muốn bắt đầu tái cấu trúc một số mã mà tôi vẫn thấy trong dự án tôi đang làm, nhưng hiện tại tôi không được giao cho bất kỳ nhiệm vụ chạy nước rút nào để thực hiện bất kỳ tái cấu trúc quy mô lớn nào.

Is it OK trong Scrum nếu tôi bắt đầu một cách ngẫu nhiên refactoring mã mà tôi đã và chưa viết rằng luôn luôn làm phiền tôi nhưng không có thời gian những ngày khác để sửa chữa nó vì ngày nhiệm vụ khác?

Còn những ngày khác mà tôi có thời gian rảnh rỗi giữa những lần chạy nước rút.

Tôi thực sự làm và tin vào tái cấu trúc liên tục. Tôi luôn luôn làm điều đó trên các đoạn mã mà tôi đang làm việc khi được gán một câu chuyện nhưng còn một số mã khác tôi thấy hiện tại không liên quan đến những gì tôi đang làm việc vào lúc đó thì sao?

Tôi thực sự không có ý định tấn công các câu trả lời khác, nhưng có ai khác đang viết bài kiểm tra tự động ở đây không? Đây là một bài đọc thú vị từ Martin Fowler cho bất cứ ai làm Scrum mà không có các thực hành kỹ thuật phần mềm thích hợp. Robert C. Martin cũng nói rất nhiều về điều này ở đây .

Vì vậy, với câu trả lời của tôi ... Tóm lại, nó diễn ra như sau:

Có, mã tái cấu trúc "ngẫu nhiên" được cho phép trong Scrum , miễn là nhóm quyết định rằng nó nên được thực hiện. (Rốt cuộc, nó là tự tổ chức)

Và bây giờ cho câu trả lời dài:

Rõ ràng là để lại ngày càng nhiều nợ kỹ thuật sau mỗi Sprint là một công thức cho thảm họa. Chẳng mấy chốc, mọi người sẽ chậm lại vì các mã bocomes lộn xộn hơn; mọi thay đổi sẽ khó thực hiện hơn vì mã quá rối và lộn xộn đến nỗi mất nhiều thời gian hơn để tìm các điểm cần thay đổi so với thực hiện thay đổi thực tế. Thậm chí còn tệ hơn nếu bạn phải thay đổi một mô-đun lớn và lộn xộn mà bạn không biết gì, không thể đạt được / giữ năng suất khi thêm / chuyển đổi mọi người trong dự án, v.v.

Nếu một đội muốn giữ tốc độ ổn định, họ phải có khả năng giữ cho cơ sở mã sạch sẽ để liên tục tăng phần mềm. Tái cấu trúc là một cách thực hành bắt buộc nếu bạn muốn duy trì vận tốc của mình trong suốt vòng đời của dự án và nếu bạn muốn giảm thiểu rủi ro khi thêm / chuyển người vào dự án và nếu bạn muốn có thể thay đổi mô-đun, bạn không biết gì về, và như vậy.

Tuy nhiên, tái cấu trúc là một hoạt động rất nguy hiểm. Tôi nhắc lại - đó là một hoạt động rất nguy hiểm . Đó là, trừ khi bạn có đủ phạm vi kiểm tra để có thể thay đổi cơ sở mã một cách an toàn và tự do. Nếu bạn chỉ có thể nhấn nút để kiểm tra xem có gì bị hỏng hay không, tái cấu trúc trở thành một hoạt động rất an toàn; Thực tế, rất an toàn, đó là một phần của chu trình TDD , đây là cách thực hành cho phép bạn tạo ra một bộ thử nghiệm như vậy ngay từ đầu.

Nhưng, vì các nhóm trong Scrum là tự tổ chức, cuối cùng, nhóm của bạn phải quyết định điều gì là đúng. Tôi hy vọng đã đưa ra một số lập luận trong trường hợp bạn phải thuyết phục bất cứ ai. (Đặc biệt chú ý đến các liên kết trong đoạn đầu tiên và mọi bài viết khác mà chúng trỏ đến)

Scrum không thực sự nói bất cứ điều gì về tái cấu trúc.

Điều Scrum nói là nếu bạn không có bất kỳ nhiệm vụ nào trong giai đoạn nước rút để làm việc, bạn nên hỗ trợ phần còn lại của nhóm để đạt được mục tiêu chạy nước rút. Ngay cả khi điều đó có nghĩa là lấy cà phê cho họ.
Nếu nhóm của bạn đồng ý rằng tái cấu trúc mã là cách tốt nhất bạn có thể hỗ trợ chúng (và điều đó bao gồm việc có cơ sở hạ tầng để đảm bảo việc tái cấu trúc không đưa ra quá nhiều lỗi mới), thì bằng mọi cách, hãy tìm cách đó.

Tôi sẽ nói không, không phải vậy. Điều này là bất kể loại công việc (tái cấu trúc, vv).

Tối thiểu, các nhiệm vụ nên được tạo và đẩy vào giai đoạn nước rút hiện tại của bạn. Mục đích của việc theo dõi thời gian là để nắm bắt vận tốc của bạn để có hiệu quả có thể vạch ra những lần chạy nước rút trong tương lai. Nếu bạn đang làm việc trên mọi thứ mà không theo dõi chúng, bạn sẽ tác động đến vận tốc và nó sẽ không trở nên tốt hơn theo thời gian như dự định với theo dõi thích hợp (bạn có thể thường xuyên không có đủ công việc vì vận tốc dự kiến ​​của bạn thấp hơn vận tốc thực của bạn ).

Đối với việc tự tái cấu trúc công việc, tôi có thể tiếp tục nói về vấn đề đó, nhưng tôi sẽ không nghĩ rằng đó là câu hỏi cốt lõi mà bạn đang cố gắng trả lời.

Tôi sẽ nói không là tốt. Tái bao thanh toán thường dẫn đến các lỗi không lường trước được nếu nó không được quản lý đúng cách.

Là một GM, định kỳ tôi sẽ đưa mọi người vào một dự án khác và dành một tuần để thực hiện đánh giá mã / tái bao thanh toán / đổi tên và thực thi các quy ước cho một dự án. Những lần chạy nước rút này bao gồm hầu như luôn luôn là mỹ phẩm trong tự nhiên. Bất kỳ bao thanh toán lại chức năng sẽ được lên kế hoạch trước thời hạn và liên quan đến nhà phát triển ban đầu.

Việc bao thanh toán lại chức năng phải luôn được lên kế hoạch và phối hợp như một phần của quy trình scrum để có thể theo dõi thời gian và tất cả các thành viên nhóm cần thiết đều có sẵn để xác nhận quy trình. Một nhà phát triển không nên thay đổi mã được viết bởi một người khác vì rất có thể nó sẽ gây rối cho cuộc đua nước rút hiện tại cho mọi người. Đặc biệt là khi nói đến thời gian hợp nhất mã.

Nếu đó là một dự án mà bạn là người duy trì duy nhất và đó là thời gian rảnh của riêng bạn thì có thể khác với giả định bạn thực hiện các bước để đảm bảo rằng bạn không gây ra sự chậm trễ không cần thiết trong lần chạy nước rút hiện tại.

Khi nghi ngờ, hãy hỏi người quản lý của bạn.

EDIT: Tôi cũng muốn đề cập rằng một đoạn mã nhất định mà bạn không thích có thể có một mục tiêu hiệu suất nhất định được liên kết với nó. Bạn có thể không thích nó nhưng nó có thể nhanh hơn bất cứ thứ gì bạn có thể xây dựng phù hợp với cách bạn muốn sử dụng nó. Chỉ một lý do khác tại sao bao thanh toán lại chức năng phải luôn luôn là một quá trình được quản lý.

Scrum không nói gì về tái cấu trúc (xem bài giảng của Robert C. Martin, "Vùng đất mà Scrum đã quên").

Trong Scrum, các tác vụ nhắm mục tiêu là các tính năng của phần mềm do khách hàng chỉ định, không phải là các khoản nợ kỹ thuật để trả nợ bằng cách tái cấu trúc. Đây là những mức độ trừu tượng hoàn toàn khác nhau. Khách hàng hầu như không thể đánh giá sự cần thiết.

Scrum là quản lý dự án thống kê. Để có được các biện pháp có ý nghĩa về "mất bao lâu", bạn phải biết hiệu suất (sản lượng trên mỗi lần chạy nước rút). Bạn so sánh ước tính và thời lượng thực cho một tính năng trong ít nhất hơn 1 lần chạy nước rút để đi vào thống kê. Tôi đề nghị 5 lần chạy nước rút. Nhưng điều đó phụ thuộc vào đội của bạn.

Điều chính là giữ cho các biện pháp có ý nghĩa và có thể so sánh để thực hiện bất kỳ dự báo có thể. Điều đó sẽ không xảy ra nếu hiệu suất giảm vì nợ kỹ thuật.

Nếu bây giờ bạn vẫn nghĩ đến việc tái cấu trúc các nhiệm vụ, bạn có hai vấn đề: 1. Một khách hàng, không hiểu, tại sao anh ta phải chấp nhận một nhiệm vụ sẽ không tạo ra một tính năng mới 2. Bạn hoàn toàn làm sai lệch số liệu thống kê của mình và do đó khả năng dự báo của bạn khi bạn đột nhiên thay đổi một biến khác không được xem xét trong lần chạy nước rút trước

Trong cả hai trường hợp, bạn thỏa hiệp ý tưởng về scrum khi bạn muốn nói về các tính năng với khách hàng VÀ đưa ra dự báo đáng tin cậy cho "Mất bao lâu?" một cách thống kê. Để an toàn, bạn phải giữ cơ sở mã của mình ở chất lượng không đổi (có thể cao).

Tái cấu trúc hầu hết thời gian là một nhiệm vụ ngầm. Tái cấu trúc "vĩ đại" có nghĩa là tái cấu trúc "nhỏ" chưa từng được xử lý trong quá khứ.

Một lưu ý cuối cùng: Nếu bạn thực hiện tái cấu trúc, hãy đảm bảo rằng bạn có thành phần đang được kiểm tra, bạn đang tái cấu trúc. Ohh, bạn không có bài kiểm tra? Làm một nhiệm vụ để viết bài kiểm tra. Khách hàng của bạn sẽ rất vui khi biết rằng phần mềm anh ta hiện đang sử dụng không đủ phạm vi kiểm tra ...

Giữ các công cụ kỹ thuật cách xa khách hàng và thực hiện công việc của bạn như một nhà phát triển chuyên nghiệp.

Đây là một cách tiếp cận: làm cả hai!

Tái cấu trúc thường dễ bị lỗi hoặc tốn nhiều thời gian hơn mà ban đầu ước tính là @misterb quy định.

Vì vậy, hãy xem xét một nỗ lực để làm điều đó một dự thảo hoặc tăng đột biến. Bạn không cần tìm kiếm sự chấp thuận hoặc quảng cáo nếu ở giai đoạn này.

Sau đó, tìm cách đưa nó qua một trong hai kênh:

• một vé hiện có chạm vào cùng mã / chức năng nơi bạn có thể bọc hợp lý này. Hợp lý theo thỏa thuận với các thành viên trong nhóm.
• toàn bộ một vé để xem xét tại buổi chải chuốt vé tiếp theo (hoặc cuộc họp hàng tuần, vv nếu thác nước). Tại thời điểm đó bạn có thể làm cho trường hợp cho nó.

Khi bạn đã mua thực tế, bạn có thể tìm cách áp dụng hoặc làm lại đột biến của mình và thực tế mã được sáp nhập vào nhánh chính (chính, v.v.).

Điều này sẽ có một số lợi thế:

• Tất cả các mã mã của bạn thông qua cùng một quy trình, được kiểm tra, QA, trong đường ống phát hành, v.v.
• Bạn nhận được mua chính thức, bao gồm từ người quản lý sản phẩm, rằng tái cấu trúc là một phần của nghề thủ công và không phải là thứ cần phải 'lẻn vào' trong một kỳ nghỉ. Tự hỏi bản thân tại sao bạn không 'lẻn vào' một tính năng thực tế có thể giúp ích cho phối cảnh.
• Bạn có thể yêu cầu ghép nối, đánh giá mã, qa, devops và tất cả các hỗ trợ khác có thể cần thiết cho việc thay đổi mã bao thanh toán. Tất cả sẽ là chính thức, theo Chính sách và Thủ tục và trên bảng.
• Nếu bạn là một công ty giao dịch công khai tuân thủ SOX, bạn có thể muốn / cần thực hiện loại quy trình chính thức này (tức là ghi lại tài liệu và sau đó thực hiện theo).
• Bạn có được danh tiếng tốt hơn với cả người quản lý sản phẩm (thay đổi được thực hiện nhanh chóng) và nhóm phát triển (codebase đã được cải thiện).
• Tổ chức đang tìm cách quan tâm đến chất lượng mã tốt cho năng suất, tinh thần, giữ chân nhân viên và nhiều lý do khác.
• Ảnh hưởng đến vận tốc dự án có thể được theo dõi dễ dàng hơn khi bao gồm tất cả các công việc. Có thể không chấp nhận bất kỳ điểm nào vì sự hiện diện có thể được sử dụng để ảnh hưởng đến vận tốc.
• Các nhà phát triển có thể thấy các công cụ khuyến khích đánh giá mã dễ dàng hơn như Fisheye, Github, v.v.
• Các nhà phát triển có nhiều khả năng nhìn thấy một số tiêu chuẩn cơ bản (đôi khi được ghi lại, đôi khi không) giúp việc chia sẻ mã và do đó tái cấu trúc dễ dàng hơn. Đôi khi một phần lớn của tái cấu trúc là chọn một kiểu và sau đó áp dụng nó một cách rộng rãi (thay thế một hỗn hợp các cách tiếp cận bằng một).

Nhận xét cuối cùng: Tránh người quản lý sản phẩm nghe từ 'ngẫu nhiên'. Họ có thể phản hồi thuận lợi hơn với nâng cấp mã 'nhắm mục tiêu, chiến lược, nâng cao hiệu suất'. Hoặc gói dịch vụ ứng dụng. Hoặc bất cứ ngôn ngữ nào cung cấp cho bạn bảo hiểm.

Tái cấu trúc ngẫu nhiên không có ý nghĩa. Điều có ý nghĩa là tái cấu trúc một mã sẽ giới thiệu hầu hết các lợi ích. Điêu đo co nghia la :

• khắc phục sự cố thiết kế hoặc kiến ​​trúc
• cải thiện việc thực hiện

Scrum có ổn không nếu tôi bắt đầu tái cấu trúc ngẫu nhiên mã mà tôi có và không được viết luôn làm phiền tôi nhưng không có thời gian để sửa nó vì các bài tập ngày khác?

Từ câu trả lời này :

Giữ mã cần duy trì là một mục trong danh sách ghi chú của bạn (nếu bạn sử dụng Scrum). Nó cũng quan trọng như sự phát triển mới. Mặc dù có vẻ như không phải là thứ gì đó "hiển thị cho người dùng", nhưng bỏ qua nó sẽ làm tăng nợ kỹ thuật của bạn. Xuống đường khi nợ kỹ thuật chồng chất đủ khiến mã của bạn thiếu khả năng bảo trì làm chậm sự phát triển, sự chậm trễ trong phát triển tính năng mới sẽ hiển thị cho khách hàng.

Trong công việc trước đây của tôi, chúng tôi đã có một số loại scrum, với nước rút lớn hơn (2-3 tháng). Vì chúng tôi có một số chậm trễ giữa các lần chạy nước rút (1 tháng), chúng tôi đã sử dụng thời gian này để phân tích phần mềm và cấu trúc lại mã.