Tôi mới bắt đầu một công việc với Scrum và dường như thiếu một cái gì đó. Tôi chưa quen với Scrum

Mã này là một mớ hỗn độn hoàn chỉnh của sự kết hợp giữa ASP / ASP.NET cổ điển. Scrum bao gồm chúng tôi vá những mớ hỗn độn lớn hoặc bổ sung cho nó. Tất cả chúng ta đều quá bận rộn để làm điều đó để bắt đầu viết lại nên tôi tự hỏi ..

Phần nào trong Scrum, nơi các nhà phát triển có thể có quyền nói rằng đủ là đủ và yêu cầu họ có thời gian để bắt đầu viết lại lớn? Chúng tôi dường như trong một vòng lặp vô tận chỉ là vá mã cũ bằng 'Câu chuyện'.

Vì vậy, mọi thứ đang được điều hành bởi những người phi kỹ thuật, những người dường như không muốn viết lại bởi vì họ không hiểu được codebase đã trở nên tồi tệ như thế nào ..

Vì vậy, ai chịu trách nhiệm thực hiện thay đổi viết lại lớn này xảy ra? Các nhà phát triển? Bậc thầy Scrum?

Chiến lược hiện nay là chỉ để tìm thời gian và làm điều đó bản thân mình mà không có sự-up cao hơn tham gia kể từ khi họ chủ yếu là để đổ lỗi cho sự lộn xộn hiện nay chúng ta đang ở .. <-chèn rant về người phi kỹ thuật nói với mọi người kỹ thuật phải làm gì đây ->.

Tôi không chắc tại sao điều này lại khó khăn với mọi người. Trường hợp kinh doanh của anh ta ở ngay đây:

We seem in an endless loop of just patching old code with 'Stories'.

Thời gian phát triển là tiền. Rất nhiều tiền. Tôi đã rời một công ty có kế hoạch cải tổ UI của họ hơn một năm trước và hy vọng rằng việc áp dụng scrum sẽ giúp họ ngừng quay bánh xe. Chuyện gì đã xảy ra? Cùng ol 'cùng ol'. Họ tiếp tục cải tiến các tính năng mới và "nợ kỹ thuật" không có trường hợp kinh doanh mặc dù một nửa mã chúng tôi đã viết trở nên vô nghĩa với mỗi lần lặp lại do cơ sở mã cơ sở là một mớ hỗn độn lỗi thời. Không có một điều gì thay đổi ở mặt trước của họ kể từ khi tôi rời đi, và tôi được đưa vào với mục đích hoàn toàn cải tạo nó. Trong hai tháng tôi ở đó, tôi đã không thực sự chạm vào một chút CSS hay JavaScript. Tôi chỉ gặp rắc rối với HTML và một số hệ thống tạo khuôn mẫu Java cổ đại từ cuối những năm 1990.

Câu trả lời của tôi? Hãy làm những gì bạn có thể, nhưng nếu các nhà phát triển khác đã từ bỏ và làm việc muộn để đạt được mục tiêu chạy nước rút thay vì khẳng định thời hạn thực tế hơn và khẳng định rằng nợ công nghệ thực tế là một vấn đề ngăn chặn, hãy giả định điều tồi tệ nhất và bắt đầu tìm kiếm một công việc mới hiện nay. Các nhà phát triển của bạn không thể hoặc không được phép truyền đạt mối quan tâm của họ hoặc doanh nghiệp cũng vậy! @ # $ Ing thiển cận để hiểu số tiền họ đang bỏ ra.

Bỏ qua những vấn đề này LUÔN LUÔN chi phí nhiều hơn trong thời gian dài. Và không nhiều hơn một chút, nhưng rất nhiều. Không chỉ là vết thương ở ngực khi thời gian phát triển có liên quan, mà chắc chắn sẽ làm giảm mức độ tài năng của bạn vì các nhà phát triển biết rõ hơn và có các lựa chọn khác sẽ tránh công ty của bạn như bệnh dịch. Sếp hiện tại của tôi là một nhà phát triển VÀ chủ sở hữu của công ty. Có những thứ chúng tôi sẽ không viết lại để tập trung vào các ưu tiên khác, nhưng khi một cái gì đó thực sự cần một bộ tái cấu trúc do là một khoảng thời gian nhất quán, nó sẽ có một bộ tái cấu trúc phù hợp. Và kết quả là rõ ràng. Sửa đổi và thêm công cụ mới trở nên dễ dàng và nhanh hơn bởi nhiều yếu tố. Những gì một lần có thể mất hàng giờ có thể mất vài phút với kiến ​​trúc phù hợp. Doanh nghiệp không thích nghe nó, nhưng nó đáng để giữ mọi thứ cho điều đó.

Scrum là một thất bại trong môi trường mà các nhà phát triển không nắm giữ nhiều ảnh hưởng, IMO, bởi vì các loại hình kinh doanh quá dễ dàng bỏ qua việc bảo trì và cập nhật có lợi cho các gạch đầu dòng mà họ có thể đưa vào danh sách "sáng kiến ​​thành công" của mình khi thời gian đánh giá đến xung quanh. Họ sẽ luôn ưu tiên cho sự che giấu của họ và tiềm năng thăng tiến có lợi cho lâu dài, ngay cả khi nó liên tục cắn vào mông họ để bỏ qua những vấn đề này.

Scrum cũng là một ngành công nghiệp có lợi nhuận và sau đó một số. Các công ty trả rất nhiều tiền cho đào tạo scrum. Những người muốn nhận nuôi nên đưa ra một cái nhìn cảnh giác về người đang được tiếp thị và thực tế nó sẽ như thế nào trong văn hóa nhất định của họ.

Bất kể, nếu bạn thực sự cho một sự chết tiệt về sự phát triển, một cơ sở mã hóa xảo quyệt, quản lý bằng sáp trong tai và các nhà phát triển không có gai là một công thức cho sự khốn khổ và một môi trường sẽ làm rất ít để nâng cao kỹ năng của bạn trong bất kỳ vấn đề hữu ích nào. Đừng ngần ngại bắt đầu chuyển các bước sang GTFO trước khi bạn thực sự phát hiện ra liệu những nỗ lực khắc phục vấn đề của bạn có thực sự được đền đáp hay không.

Nếu bạn thực sự sẽ làm Scrum, điều mà tôi nghi ngờ, Chủ sở hữu sản phẩm sẽ chịu trách nhiệm quyết định viết lại. Hầu hết các lần viết lại không phải là một ý tưởng tốt, btw, bởi vì nó không tạo ra chức năng mới, chỉ giới thiệu các lỗi mới.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Để mở rộng về "viết lại không phải là một ý tưởng tốt":

Hầu như luôn luôn tốt hơn để thử một cải tiến dần dần. Giống như Jarrod Robertson đã viết trong một bình luận, tìm một mô-đun cần cải tiến trở thành chuyên gia cho mô-đun đó và viết một câu chuyện cho lần chạy nước rút tiếp theo để cải thiện mô-đun cụ thể đó. Giải thích cho chủ sở hữu sản phẩm tại sao mô-đun đó cần làm việc.

Tôi sẽ thực sự cùn ...

• Bạn có phụ trách các nhà phát triển trong công việc này?
• Bạn có phải là người lãnh đạo dự án?
• Các nhà phát triển nắm giữ bao nhiêu "cổ phần" trong dự án?
• Biện minh kinh doanh của bạn cho một viết lại là gì?
• Điều gì về cơ sở mã làm cho nó hoàn toàn vô dụng và không thể phục hồi?

Bạn đã nói rằng bạn vừa mới bắt đầu một công việc, nhưng bạn dường như đã làm chủ được tình huống ở đó. Có lẽ tôi đã hiểu sai ý định của câu hỏi của bạn, nhưng tôi có ấn tượng rằng bạn đã vào một công việc mà bạn thấy một số vấn đề và bạn đã nhảy đến kết luận dễ nhất trong đó mã bị hỏng và cách duy nhất là viết lại, nhưng bạn đã thực sự xem xét chi phí cho chủ nhân của bạn để làm như vậy chưa?

Với bất kỳ cơ sở mã hiện có nào - cho dù trạng thái của nó kém đến mức nào - chủ sở hữu thường sẽ có một khoản đầu tư lớn vào (các) sản phẩm mà mã đại diện. Có cả chi phí trực tiếp và gián tiếp liên quan đến cơ sở mã và viết lại thường là điều cuối cùng bạn muốn làm với tư cách là nhà phát triển phần mềm, vì bạn có nguy cơ phá giá tài sản mã của mình và do đó thu được lợi nhuận thấp hơn trước tất cả nỗ lực.

Lấy hệ điều hành của Window làm ví dụ. Với mỗi phiên bản mới được tạo, đã có một đoạn mã lớn được chuyển từ phiên bản trước. Đôi khi, toàn bộ thư viện và API được kéo về phía trước qua nhiều thế hệ HĐH. Tại sao? Bởi vì các nhà phát triển biết rằng các yếu tố này hoạt động, đã được thử nghiệm, đã được vá và sửa chữa để ngăn chặn các vấn đề về bảo mật và bộ nhớ và vì chúng đã tốn rất nhiều tiền để vào trạng thái đó. Không ai muốn vứt bỏ mã làm việc khi họ kiếm được tiền, ngay cả khi chi phí bảo trì tương đối cao, chi phí để bắt đầu từ đầu sẽ luôn cao hơn và trong một công ty như trường hợp của Microsoft, họ có hàng tỷ trong ngân hàng cho phép họ bắt đầu lại từ đầu nếu họ muốn, nhưng họ không ' t vì họ muốn tối đa hóa lợi nhuận của họ từ khoản đầu tư của họ. Nhà tuyển dụng của bạn không khác gì Microsoft, ngoại trừ một chút về việc có hàng tỷ tiền mặt để ném vào một dự án.

Vì vậy, mã là một mớ hỗn độn, và có vẻ như có vấn đề giao tiếp và ranh giới giữa các lĩnh vực khác nhau của công ty. Bạn hoặc đồng nghiệp của bạn có thể làm gì về điều này?

Một lựa chọn đơn giản là tiếp tục như đội đã và hy vọng vào một phép màu trong tương lai. Có lẽ không phải là một ý tưởng tốt, và có khả năng chỉ làm tăng sự thất vọng và căng thẳng của bạn.

Một lựa chọn tốt hơn là chỉ đơn giản là quỳ xuống và thực hiện công việc của bạn, nhưng như một phần của cơ hội này để tìm cơ hội thêm các bài kiểm tra để hỗ trợ các khu vực mã có vẻ dễ vỡ nhất, sau đó cấu trúc lại chúng cho đến khi chúng ổn định hơn. Bạn sẽ có một thời gian dễ dàng hơn để đưa ra một lập luận thuyết phục để cải thiện đầu tư của công ty thay vì tranh cãi chỉ đơn giản là vứt bỏ tất cả.

Một lựa chọn thậm chí tốt hơn là được tổ chức thành một nhóm và để đảm bảo bạn có được một người có đủ thâm niên để họ có thể tạo ra một trường hợp tốt để cho phép nhóm linh hoạt hơn để sắp xếp thời gian để cải thiện cơ sở mã. Tôi không quan tâm đến việc một công ty bận rộn như thế nào, hoặc lịch trình có vẻ cứng nhắc như thế nào, luôn có những "khoảng trống" thỉnh thoảng trong hoạt động có thể được sử dụng để siết chặt trong một hoặc hai cải tiến. Tuy nhiên, thậm chí còn tốt hơn nếu các cải tiến có thể được thực hiện trong khi hoàn thành các nhiệm vụ khác. Nếu là tôi, tôi sẽ làm quen với một người quản lý và giới thiệu cho họ các khái niệm trong một số cuốn sách kinh điển mà các nhà phát triển phần mềm đọc. Mã sạchcó lẽ là người mà đội của bạn cần nhất Trồng một vài hạt giống về cách cải thiện mã và cung cấp một vài ví dụ về ý nghĩa của bạn. Một người quản lý tốt sẽ thấy giá trị của việc thêm các cải tiến gia tăng vào mã, đặc biệt nếu bạn có thể mô tả khái niệm Nợ kỹ thuật . Giúp trưởng nhóm hoặc người quản lý của bạn tạo ra một trường hợp kinh doanh tốt để cải thiện mã và họ sẽ có động lực tốt hơn để hành động.

Cũng không đủ để nói "mã không gọn gàng". Bạn cần khuyến khích các đồng nghiệp của mình thực hành mã hóa sạch mọi lúc và sử dụng kỹ thuật mã hóa sạch để khuyến khích một chút dọn dẹp khi bạn đi. Tôi có một poster nhỏ mà tôi in ra và treo trên tường văn phòng mỗi khi tôi nhận một công việc mới. Nó nói "Luôn luôn cố gắng để lại mã đẹp hơn một chút so với bạn tìm thấy". Ngay bên cạnh tôi thêm một cái khác có nội dung "Hoa loa kèn không cần được mạ vàng". Cả hai đều phục vụ để nhắc nhở tôi rằng tôi nên luôn cố gắng cải thiện những gì tôi tìm thấy, nhưng tránh đơn giản là mạ vàng một vấn đề khác. Viết lại ồ ạt thường là loại "mạ vàng" tồi tệ nhất, bởi vì chúng thường được thực hiện vì những lý do sai lầm. Chắc chắn một phiên bản sản phẩm hoàn toàn mới có thể hợp lý tại một số điểm,

Dưới đây là định nghĩa chính thức của Nhóm phát triển Scrum từ Hướng dẫn Scrum chính thức . Tôi nhấn mạnh vào những phần liên quan trực tiếp đến bạn:

Nhóm phát triển bao gồm các chuyên gia thực hiện công việc phân phối một sản phẩm Gia tăng có thể phát hành có thể tin cậy vào cuối mỗi Sprint. Chỉ các thành viên của Nhóm Phát triển tạo Phần tăng. Các nhóm phát triển được cấu trúc và trao quyền bởi tổ chức để tổ chức và quản lý công việc của chính họ . Sức mạnh tổng hợp kết quả tối ưu hóa hiệu quả và hiệu quả chung của Nhóm phát triển. Nhóm phát triển có các đặc điểm sau:

• Họ tự tổ chức. Không ai (kể cả Scrum Master) nói với Nhóm phát triển cách biến Product Backlog thành các phần tăng thêm chức năng có thể tin cậy được;

• Các nhóm phát triển có nhiều chức năng, với tất cả các kỹ năng như một nhóm cần thiết để tạo ra một Sản phẩm gia tăng;

• Scrum nhận ra không có tiêu đề nào cho các thành viên của Nhóm phát triển ngoài Nhà phát triển, bất kể công việc đang được thực hiện bởi người đó; Không có ngoại lệ cho quy tắc này;

• Các thành viên của Nhóm Phát triển Cá nhân có thể có các kỹ năng chuyên môn và các lĩnh vực trọng tâm, nhưng trách nhiệm giải trình thuộc về toàn bộ Nhóm Phát triển; và,

• Nhóm phát triển không chứa các nhóm phụ dành riêng cho các miền cụ thể như thử nghiệm hoặc phân tích kinh doanh.

Do đó, Nhóm Phát triển chịu trách nhiệm về sự lộn xộn của chính mình và nên tự giải quyết, mà không phải hỏi bất kỳ ai ngoài nhóm.

Bao gồm thời gian sửa nợ kỹ thuật trong mỗi ước tính trong tương lai của bạn và đảm bảo rằng chất lượng của phần mềm bạn cung cấp là đỉnh cao.

Nếu bạn thực sự phải viết lại hoàn chỉnh, bạn phải giải quyết vấn đề tại Scrum Restros perspective. Chủ sở hữu sản phẩm cuối cùng có thể hủy dự án và bắt đầu một dự án mới. Chủ sở hữu sản phẩm cũng là người duy nhất có thể hủy bỏ chạy nước rút.

Như bạn mô tả này, tôi phải nói rằng tôi không nhìn thấy bất cứ điều gì mà có bất cứ điều gì để làm với SCRUM, hoặc nhóm phát triển sản phẩm của bạn trở thành một vấn đề hiện nay .

Điều này là bình thường

Những gì bạn mô tả là entropy bình thường của một cơ sở mã. Trong trường hợp của bạn, nhóm có thể bắt đầu xa hơn lý tưởng, nhưng cuối cùng mọi cơ sở mã đều trở thành Big Ball of Mud .

Trong một kịch bản trường xanh hoàn toàn hoàn hảo , tất cả những gì bạn có thể làm là bắt đầu xa hơn với entropy tuyệt đối và tiến về phía nó chậm hơn.

Tôi đồng ý với những người khác, mã cơ sở lộn xộn là do các nhà phát triển. Tôi chắc chắn rằng nó có trước khi áp dụng SCRUM trong nhiều năm.

Đây không phải là một quyết định kỹ thuật hoặc nhà phát triển để viết lại, nó là một quyết định kinh doanh.

Bạn không biết tại sao chủ sở hữu sản phẩm không muốn viết lại. Bạn là một nhà phát triển nghĩ rằng nó là cần thiết, nhưng thực sự có trường hợp kinh doanh nào cho nó không?

Nếu có một trường hợp kinh doanh thực sự , không chỉ là một bàn tay vẫy; "Mã là một mớ hỗn độn mà tôi muốn bắt đầu từ trường xanh vì đó là điều tôi muốn" , sau đó ban quản lý sẽ giải trí chi phí cho việc viết lại, xem xét lợi tức của khoản đầu tư đó.

Bạn đã không cho một rắn trường hợp kinh doanh cho một viết lại, chỉ cần một rant về bạn ý kiến về cách mọi người khác gây ra lộn xộn này và bạn không muốn để đối phó với nó.

Bằng chứng - Lợi nhuận thúc đẩy các quyết định kinh doanh đưa ra phần mềm hoạt động, không phải OCD cần một cơ sở mã sạch

Nếu bạn thực sự có thể đưa ra bằng chứng , không chỉ là lý thuyết mà là bằng chứng cứng rắn rằng việc chi Xđô la cho việc viết lại trường xanh sẽ được đảm bảo KIẾM X * N đô la cho doanh nghiệp trong Ykhung thời gian (ở Nmức cao và Yngắn), bạn có thể nhận được một lực kéo từ ban quản lý . Đây là một trường hợp rất khó xảy ra mà bạn có thể trình bày và chứng minh.

Nếu không, bạn chỉ cần đối phó với nó, đây là thực tế. Trái với khẳng định kiên quyết của bạn rằng hoàn toàn không có cách nào để không viết lại, tôi sẽ đặt cược rằng hơn 5 năm kể từ bây giờ cơ sở mã mà bạn đang phàn nàn sẽ vẫn hoạt động và chạy ở đâu đó cung cấp chức năng và giá trị cho ai đó sau đó bạn đã rời khỏi công ty

Tôi thường hoài nghi khi mọi người thúc đẩy "viết lại lớn". Có một số trường hợp chắc chắn có ý nghĩa nhưng hầu hết thời gian, mã kế thừa đó có giá trị (trong đó nó đã được sản xuất và được sử dụng cho các mục đích truyền cảm hứng cho sự sáng tạo của nó). Thực hiện viết lại lớn trong nhiều trường hợp ngược lại với nhanh nhẹn. Sẽ mất bao lâu để đưa phiên bản mới của ứng dụng đến một điểm mà nó có thể thay thế hoàn toàn ứng dụng hiện có.

Cách tiếp cận tôi thích là cái mà Martin Fowler gọi là cây nho bóp cổ . Thực hiện chức năng mới (bao gồm các thay đổi đối với chức năng hiện có) bằng cách sử dụng phương pháp mới nhưng sử dụng ứng dụng hiện có như một mạng lưới mà chức năng mới có thể phát triển theo. Điều này mang đến cho bạn những điều tốt nhất của cả hai thế giới, bạn không cần phải dừng tất cả mọi thứ trong khi việc viết lại lớn đang được đưa ra để hít vào, nhưng bạn có được lợi ích của việc viết mã mới tận dụng các khung cập nhật. Đó chắc chắn là một cách tiếp cận khó khăn hơn là bắt đầu sạch sẽ và có thể không gợi cảm, nhưng nó mang lại nhiều giá trị cho doanh nghiệp hơn là vứt bỏ mọi thứ ở đó vì nó đã lỗi thời.

Tôi đang ở đâu và làm việc như thế nào, đây là những gì chúng tôi sẽ làm: Viết một câu chuyện mới và trao cho chủ sở hữu sản phẩm, người sau đó sẽ quyết định cách ưu tiên nó. Một ví dụ sẽ là: "Là nhà phát triển sản phẩm X, tôi muốn viết lại mã trong lĩnh vực này để sự phát triển trong tương lai hiệu quả hơn" Các tiêu chí chấp nhận sau đó sẽ cần phải tuân theo: Viết lại / tái cấu trúc x theo cách này là tốt hơn theo cách này

Tôi không biết về tình huống của bạn nhưng ở đây nếu chúng tôi muốn bắt đầu lại từ đầu, đó là trường hợp ngồi xuống với chủ sở hữu sản phẩm và thuyết phục họ tại sao và sau đó viết một đống câu chuyện để tạo lại chức năng.

Những việc khác mà chúng tôi đã thực hiện để thử và xử lý mã xấu và / hoặc di sản là bao gồm các tác vụ để làm lại khi thực hiện các câu chuyện của người dùng.

Quyết định viết lại lớn là một quyết định kinh doanh. Bạn có thể cố gắng tác động đến các quyết định kinh doanh bằng cách bán theo quan điểm của bạn cho những người chịu trách nhiệm cho phần kinh doanh của mọi thứ.

Tuy nhiên; thay đổi chất lượng mã từ lần lặp này sang lần lặp tiếp theo là quyết định của nhà phát triển. Nếu bạn cho phép chất lượng mã giảm, bạn đang thêm nợ kỹ thuật để đáp ứng mong đợi của chủ sở hữu sản phẩm ngay bây giờ. Những gì bạn có thể làm là bắt đầu chịu trách nhiệm về mã bạn viết và đảm bảo rằng nó cải thiện cơ sở mã chứ không phải theo cách khác. Bây giờ điều này có nghĩa là bạn sẽ mất vận tốc, vì bạn liên tục giảm số nợ kỹ thuật, và chủ sở hữu sản phẩm của bạn chắc chắn sẽ thất vọng. Bạn có thể cố gắng giải thích rằng để háo hức, bạn đã để chất lượng mã giảm và hiện bạn đang thực hiện các bước để khắc phục vấn đề này.

Bây giờ, tôi nhận ra rằng đó là một bước đáng sợ để thực hiện và có thể cảm thấy muốn trì hoãn nó chỉ một lần chạy nước rút để bạn có thể thoát khỏi tính năng X trước thời hạn quan trọng. Thật không may, nó sẽ chỉ trở nên khó khăn hơn khi bạn chờ đợi lâu hơn.

Nhân tiện, đây không hoàn toàn là một vấn đề về Scrum, tôi cũng không đề xuất một giải pháp dành riêng cho Scrum. Đây là về các nhà phát triển nắm quyền sở hữu mã.

Các nhà phát triển có trách nhiệm cảnh báo thế giới về trạng thái hiện tại của cơ sở mã. Điều này có thể xảy ra trong một scrum hàng ngày, hồi cứu hoặc chỉ không chính thức. Điều này có vẻ hiển nhiên nhưng nếu bạn không thể hiện rõ ràng nó là một mớ hỗn độn và bạn lãng phí bao nhiêu thời gian vì nó, sẽ không ai nhận ra. Scrum Master thường chịu trách nhiệm truyền thông tin cho PO và những người phụ trách dự án và thuyết phục họ một số việc cần phải làm, sau đó tạo điều kiện cho nhóm thực hiện giải pháp.

Như một lưu ý phụ, viết lại một tiếng nổ lớn là IMO không nhất thiết là câu trả lời đúng cho loại vấn đề này. Tuy nhiên, các nhà phát triển đã chán ngấy với cơ sở mã hiện tại, thực hiện các bước nhỏ có thể đo lường được đối với kiến ​​trúc sạch hơn thường là ý tưởng tốt hơn vì bạn có thể thấy tiến trình, chứng minh công việc của mình bằng cách thường xuyên hiển thị PO thành tích và tiếp tục quá trình triển khai người dùng mới những câu chuyện song song với việc bị lạc trong một cuộc lột xác vô tận, độc quyền về tài nguyên.

Bạn đã hỏi:

Phần nào trong Scrum, nơi các nhà phát triển có thể có quyền nói rằng đủ là đủ và yêu cầu họ có thời gian để bắt đầu viết lại lớn? Chúng tôi dường như trong một vòng lặp vô tận chỉ cần vá mã cũ bằng 'Câu chuyện'. Vì vậy, mọi thứ đang được điều hành bởi những người phi kỹ thuật, những người dường như không muốn viết lại vì họ không hiểu cơ sở mã đã tệ đến mức nào ..

Là một người vừa là người quản lý vừa là nhà phát triển, câu trả lời đơn giản nhất cho câu hỏi của bạn là không có phần nào trong Scrum, hoặc bất kỳ phương pháp nào khác, hoặc trong bất kỳ kịch bản kinh doanh nào, nơi nhà phát triển có quyền nói đủ là đủ và yêu cầu viết lại. Nhiều người ở đây đã đưa ra những lý lẽ tốt, hợp lệ để giải thích tại sao việc viết lại thường là những ý tưởng tồi và để giải thích sự thay đổi có thể và nên được đưa ra theo cách tăng dần, nhanh nhẹn. Và tôi đồng ý với tất cả.

Nhưng điểm mấu chốt thậm chí còn đơn giản hơn. Bạn không thể đưa ra quyết định đó, EVER. Bạn là nhân viên, và quyết định duy nhất bạn thực sự đưa ra là "tôi sẽ tiếp tục làm việc cho những tên khốn này hay tìm một công việc mới khiến tôi sợ kỹ năng điên rồ của mình." Công việc mới của bạn sẽ không cho phép bạn đưa ra quyết định đó, nhưng ít nhất bạn sẽ cảm thấy như bạn đang kiểm soát số phận của mình khi bạn nhảy từ công việc này sang công việc khác.

Tôi cảm thấy nỗi đau của bạn, nhưng tôi không chắc nó phải làm gì với Scrum. Quyết định có viết lại mã không phụ thuộc vào quá trình phát triển.

Đợi .... cái gì?

Bạn đang vá ? Bạn nên tái cấu trúc . Bám sát các giá trị nhanh. Sử dụng TDD và thực hành phù hợp và tình hình cuối cùng sẽ trở nên tốt hơn.