Agile - Chúng ta đang làm gì sai?

Tôi là nhà phát triển trong một nhóm nhanh nhẹn và chúng tôi cố gắng sử dụng Scrum.

Vì vậy, tôi sẽ đặt ra một vấn đề giả thuyết để minh họa tình huống này.

Chúng tôi có một ứng dụng rất cũ, sử dụng một số mã JQuery lộn xộn và có khả năng bảo trì kém. Chúng tôi cũng có các phần của ứng dụng bằng React và những phần đó dễ cập nhật / bảo trì hơn. Bên cạnh đó, mục tiêu của công ty là tạo ra một ứng dụng một trang khách, trên React, vì vậy sử dụng JQuery sẽ giúp bạn tránh xa điều đó.

Khi chúng tôi lập kế hoạch, chúng tôi luôn tìm giải pháp dễ dàng về thời gian phát triển, vì vậy, nếu chúng tôi đang tạo một hộp thoại mới hoặc một cái gì đó, chúng tôi sử dụng JQuery cũ vì nó nhanh hơn và chúng tôi nói rằng chúng tôi sẽ quay lại sau đó để dọn dẹp và biến thành React, nhưng điều đó hiếm khi xảy ra.

Chúng tôi nhận được các yêu cầu của những gì chúng tôi phải làm từ các câu chuyện của người dùng (IMO được thực hiện tốt, chúng mỏng nhưng chúng giải thích những gì chúng tôi đang làm và tại sao chúng tôi đang làm điều đó).

Đôi khi, các yêu cầu của các tính năng mới rất mỏng, vì vậy, ví dụ nếu một yêu cầu nói "tạo một hộp thoại tải hàng tấn nội dung" nhưng không nói là thực hiện tính năng tải, trong hầu hết các trường hợp, chúng tôi sẽ không thực hiện nó , mặc dù tất cả chúng ta đều biết rằng sẽ tốt hơn cho khách hàng, với lý do điều này có thể làm ảnh hưởng đến mục tiêu chạy nước rút của chúng tôi (mặc dù cá nhân tôi tin rằng nó sẽ không).

Kết quả là cơ sở mã của chúng tôi là một mớ hỗn độn lớn với khả năng bảo trì rất tệ và đôi khi các tính năng mới, rất nhỏ và phải chạy nước rút đầy đủ (điều có thể đạt được trong một ngày trong một cơ sở mã tốt) chủ yếu là do sự phát triển này chiến lược, chỉ cần đi nhanh, làm tối thiểu.

Trong trường hợp này, chúng ta đang làm gì sai? Chúng ta có nên giải quyết các giải pháp một cách đầy đủ hơn để chúng ta không phải viết mã xấu và viết lại mã mà chúng ta vừa viết tuần trước không? Hoặc chúng ta nên tiếp tục làm điều đó chỉ để đảm bảo rằng tất cả mã đó đang được viết lại? Điều gì sẽ là một cách tiếp cận nhanh nhẹn tốt cho vấn đề này?

Điều này không có gì để làm với Agile hoặc Scrum.

Vấn đề với "băng keo ngay bây giờ và chúng tôi sẽ sửa nó sau" là sau này không bao giờ đến và trong thời gian đó bạn đang tích lũy rất nhiều nợ kỹ thuật .

Bước đầu tiên để phục hồi là nhận ra vấn đề và ngừng làm cho nó tồi tệ hơn.

Đối với mỗi câu chuyện người dùng mới, nhóm nên xem xét "cách nào đúng để mã hóa điều này?", Chứ không phải "cách nhanh nhất để hack thứ này là gì?" và lập kế hoạch nước rút cho phù hợp.

Để làm sạch vấn đề hiện tại, hãy xem các câu trả lời tuyệt vời cho tôi đã thừa hưởng 200K dòng mã spaghetti - bây giờ phải làm sao?

Những gì bạn có đó là những gì Martin Fowler gọi là "flacid scrum".

Nếu bạn đọc đúng tất cả 12 Nguyên tắc đằng sau Tuyên ngôn Agile , bạn sẽ thấy rằng bạn thất bại ở hầu hết chúng.

Cung cấp phần mềm làm việc thường xuyên, từ vài tuần đến vài tháng, với ưu tiên thời gian ngắn hơn.

Bạn có thể nói bạn cung cấp phần mềm thực sự làm việc? Hay chỉ là phần mềm hầu như không hoạt động?

Các quy trình nhanh nhẹn thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì tốc độ không đổi vô thời hạn.

Bạn có thể nói quá trình của bạn là bền vững? Bạn có đưa ra quyết định với sự bền vững trong tâm trí? Hay bạn chọn giải pháp giải quyết vấn đề hiện tại mà không tính đến các hiệu ứng dài hạn?

Liên tục chú ý đến sự xuất sắc kỹ thuật và thiết kế tốt tăng cường sự nhanh nhẹn.

Các nguyên tắc thực sự chính. Tôi tin rằng điều này nên được đưa vào LỚP LỚN trên trang. Đây là nơi bạn thất bại nhiều nhất.

Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh và điều chỉnh hành vi của nó cho phù hợp.

Và rõ ràng nhất. Nếu bạn phát hiện ra hành vi của mình không dẫn đến kết quả mong muốn, bạn nên thay đổi nó. Nếu nhóm của bạn không thể thấy nó có vấn đề, thì nó không thể bắt đầu sửa chúng.

Từ bình luận của bạn

Làm thế nào để prevend mà nhanh nhẹn?

Đầu tiên, bằng cách học những gì nhanh nhẹn thực sự là. Scrum không nhanh nhẹn. Một số người sẽ nói Scrum là tồi tệ nhất trong các khung nhanh, vì nó quá dễ để đạt được tình huống chính xác của bạn. Bạn nên tìm hiểu về các khung nhanh nhẹn khác. Một trong những tôi muốn giới thiệu là lập trình cực đoan. Mà rõ ràng giải quyết vấn đề của bạn. Các giải pháp không đơn giản (tập trung vào sự xuất sắc kỹ thuật thông qua thử nghiệm tự động mạnh mẽ, lập trình cặp và phân phối liên tục), nhưng hiệu quả cao. Như đã báo cáo trong báo cáo của State of DevOps .

Những gì bạn mô tả là - ít nhất là theo kinh nghiệm của tôi - một mô hình xuất hiện khá phổ biến của các đội đang cố gắng "trở nên nhanh nhẹn". Nó được mở cho cuộc tranh luận nếu đây thực sự là một phần của chính Agile hoặc là một sự thực thi sai lầm phổ biến của nó, chống lại các biểu hiện / nguyên tắc nhanh nhẹn hoặc hậu quả cố hữu của nó, v.v. Chỉ từ quan điểm thực nghiệm và chỉ dựa trên tập hợp kinh nghiệm mẫu nhỏ của riêng tôi (và những người tôi nói chuyện), nếu một nhóm nhanh nhẹn, dường như có cơ hội cao hơn so với cơ hội chạy theo mô hình này. Hãy để nó ở đó và tập trung vào ví dụ cụ thể của bạn.

Có hai khía cạnh riêng biệt với những gì bạn mô tả:

• Thiếu hiểu biết / tầm nhìn chung và do đó không hiệu quả
• Cách đo lường thành công / tiến độ và tổng chi phí

Đi sai đường hoặc chạy trong vòng tròn

Theo kinh nghiệm của tôi, lý do chính cho điều này xảy ra là trong nỗ lực sản xuất mã nhanh chóng, các nhóm tích cực đẩy các trường hợp sử dụng hoặc yêu cầu mà họ đã biết hoặc có thể dễ dàng tìm ra. Hãy nghĩ về nó theo cách này: 10-20 năm trước, mọi người đã cố gắng viết các thông số kỹ thuật khổng lồ và nghĩ về mọi thứ trước và thường thất bại. Họ hoặc mất quá nhiều thời gian hoặc bỏ qua một cái gì đó. Một trong những điều học được trong quá khứ là trong phát triển phần mềm có những điều bạn không thể biết và mọi thứ thay đổi rất nhiều, do đó ý tưởng lặp lại nhanh chóng và tạo ra một số đầu ra hợp lý nhanh chóng. Đó là một nguyên tắc rất tốt. Nhưng ngày nay, chúng ta ở một thái cực khác: "Tôi không quan tâm đến điều này bởi vì đó là một phần của lần chạy nước rút tiếp theo" hoặc "Tôi không gửi lỗi đó, tôi xử lý nó khi nó xuất hiện trở lại".

1. Tập hợp tất cả các trường hợp sử dụng cấp cao , yêu cầu, phụ thuộc và hạn chế bạn có thể tìm thấy. Đặt nó trong một số wiki để tất cả các bên liên quan và nhà phát triển có thể nhìn thấy chúng. Thêm vào họ khi một cái gì đó mới xuất hiện. Nói chuyện với các cổ đông và người dùng của bạn. Sử dụng danh sách này làm danh sách kiểm tra trong khi phát triển để ngăn chặn việc triển khai những thứ không đóng góp cho sản phẩm cuối cùng hoặc là cách giải quyết / hack để giải quyết một vấn đề nhưng gây ra ba vấn đề mới.
2. Xây dựng một khái niệm cấp cao . Tôi không nói về việc thiết kế giao diện hoặc lớp, mà thay vào đó phác họa sơ bộ miền vấn đề. Các yếu tố chính, cơ chế và tương tác trong giải pháp cuối cùng là gì? Trong trường hợp của bạn, nó sẽ làm cho nó rõ ràng khi sử dụng jquery-workaround giúp như một bước trung gian và khi nó chỉ gây ra công việc bổ sung.
3. Xác thực khái niệm của bạn bằng cách sử dụng danh sách bạn thu thập. Có bất kỳ vấn đề rõ ràng trong đó? Liệu nó có ý nghĩa? Có những cách hiệu quả hơn để đạt được cùng một giá trị người dùng mà không gây ra nợ công nghệ lâu dài?

Đừng làm quá. Bạn chỉ cần một cái gì đó để mọi người trong nhóm (bao gồm cả những người không phải là nhà phát triển) có một sự hiểu biết chung về con đường tốt nhất đến MVP của bạn là gì. Mọi người nên đồng ý rằng không có sự giám sát rõ ràng và nó thực sự có thể hoạt động. Điều này nói chung giúp ngăn chặn đi vào ngõ cụt hoặc phải làm lại điều tương tự nhiều lần. Agile có thể giúp bạn đối phó tốt hơn với những điều bất ngờ, không có gì phải bàn cãi khi bỏ qua những gì đã biết.

Lưu ý về sai lầm chi phí chìm : nếu bạn bắt đầu với một kiểu kiến ​​trúc hoặc cơ sở dữ liệu, hầu hết mọi người đều do dự khi thay đổi nó giữa dự án. Vì vậy, đó là một ý tưởng tốt để đầu tư một chút thời gian để có một "dự đoán tốt nhất có giáo dục" trước khi bắt đầu thực hiện công cụ. Các nhà phát triển có xu hướng muốn viết mã nhanh chóng. Nhưng thường có một vài giả, nguyên mẫu sống, ảnh chụp màn hình, khung dây, vv cho phép lặp lại nhanh hơn so với viết mã. Chỉ cần lưu ý rằng mỗi dòng mã được viết hoặc thậm chí các bài kiểm tra đơn vị làm cho việc thay đổi khái niệm tổng thể của bạn trở nên khó khăn hơn.

Đo lường thành công

Một khía cạnh hoàn toàn riêng biệt là cách bạn đo lường tiến độ. Giả sử mục tiêu của dự án của bạn là xây dựng một tòa tháp cao 1m bằng những thứ nằm xung quanh. Xây dựng một ngôi nhà thẻ có thể là một giải pháp hoàn toàn hợp lệ nếu ví dụ thời gian đưa ra thị trường quan trọng hơn sự ổn định. Nếu mục tiêu của bạn là xây dựng một cái gì đó tồn tại lâu dài, sử dụng Lego sẽ tốt hơn. Vấn đề là: những gì được coi là hack và những gì một giải pháp tao nhã phụ thuộc hoàn toàn vào cách đo lường thành công của dự án .

Ví dụ của bạn về "tải" là khá tốt. Tôi đã có những thứ như thế này trong quá khứ nơi mọi người (bao gồm bán hàng, PO, người dùng) đồng ý rằng điều đó thật khó chịu. Nhưng nó không có tác động đến sự thành công của sản phẩm và không gây ra nợ dài hạn. Vì vậy, chúng tôi đã bỏ nó đi vì có nhiều thứ có giá trị hơn để làm với các tài nguyên dev.

Lời khuyên của tôi ở đây là:

1. Giữ tất cả mọi thứ, ngay cả những lỗi nhỏ, như vé trong hệ thống vé của bạn . Đưa ra quyết định chủ động những gì trong phạm vi dự án và những gì không. Tạo các mốc quan trọng hoặc lọc các hồ sơ tồn đọng của bạn để bạn luôn có một danh sách "đầy đủ" tất cả mọi thứ vẫn cần phải hoàn thành.
2. Có một trật tự quan trọng nghiêm ngặt và điểm cắt rõ ràng trong đó dự án có thể được coi là thành công. Mức độ ổn định / chất lượng mã / tài liệu nào mà sản phẩm cuối cùng thực sự cần? Cố gắng dành mỗi ngày làm việc tốt nhất có thể bằng cách chọn từ đầu. Khi làm việc trên một vé, hãy cố gắng giải quyết hoàn toàn mà không giới thiệu vé mới (trừ khi nó có ý nghĩa đối với những thứ sau khi được ưu tiên do mức độ ưu tiên thấp hơn). Mỗi cam kết sẽ đưa bạn về phía trước về phía mục tiêu cuối cùng của bạn, không đi ngang hoặc lùi. Nhưng để nhấn mạnh một lần nữa: đôi khi một bản hack tạo ra công việc bổ sung sau này vẫn có thể là một mạng lưới tích cực cho dự án!
3. Sử dụng PO / người dùng của bạn để tìm ra giá trị người dùng nhưng cũng có nhà phát triển của bạn tìm ra chi phí công nghệ . Những người không phải là nhà phát triển thường không thể đánh giá được chi phí dài hạn thực sự (không chỉ là chi phí thực hiện!), Vì vậy hãy giúp đỡ họ. Hãy nhận biết vấn đề ếch sôi: rất nhiều vấn đề nhỏ, không liên quan có thể theo thời gian có thể khiến một đội bị giữ lại. Cố gắng định lượng hiệu quả làm việc nhóm của bạn.
4. Giữ một mắt trên mục tiêu / chi phí tổng thể. Thay vì suy nghĩ từ chạy nước rút đến chạy nước rút, thay vào đó hãy suy nghĩ "chúng ta có thể làm một nhóm làm mọi thứ cần thiết cho đến khi kết thúc dự án" . Nước rút chỉ là một cách để phá vỡ mọi thứ và có điểm kiểm tra.
5. Thay vì muốn hiển thị một cái gì đó sớm, hãy vẽ khóa học của bạn trên con đường nhanh nhất đến một sản phẩm khả thi tối thiểu có thể được cung cấp cho người dùng. Tuy nhiên, chiến lược tổng thể của bạn sẽ cho phép kết quả có thể kiểm chứng ở giữa.

Vì vậy, khi ai đó làm điều gì đó không phù hợp với mục tiêu thực hiện cuối cùng của bạn, lý tưởng nhất là đừng xem xét câu chuyện đã hoàn thành. Nếu có lợi khi đóng câu chuyện (ví dụ để nhận phản hồi từ khách hàng), ngay lập tức mở một câu chuyện / lỗi mới để giải quyết các câu chuyện ngắn. Hãy minh bạch rằng việc dùng các phím tắt không làm giảm chi phí, nó chỉ che giấu hoặc trì hoãn chúng!

Mẹo ở đây là tranh luận với tổng chi phí của dự án: ví dụ, nếu PO đẩy mạnh việc sử dụng các phím tắt để đưa ra thời hạn, hãy định lượng số lượng công việc phải hoàn thành sau đó để xem xét dự án đã hoàn thành!

Ngoài ra, hãy cẩn thận với tối ưu hóa dựa trên tiêu chí : nếu nhóm của bạn được đo bằng số lượng câu chuyện họ có thể hiển thị khi xem xét nước rút, cách tốt nhất để đạt được "điểm số" tốt là cắt mọi câu chuyện thành mười câu chuyện nhỏ. Nếu nó được đo bằng số lượng bài kiểm tra đơn vị được viết, nó sẽ có xu hướng viết nhiều bài không cần thiết. Đừng đếm các câu chuyện, thay vào đó hãy đo lường xem có bao nhiêu chức năng người dùng cần thiết hoạt động, chi phí của khoản nợ công nghệ được giải quyết trong phạm vi dự án là bao nhiêu, v.v.

Tóm lược

Để đun sôi nó xuống: Đi nhanh và tối thiểu là một cách tiếp cận tốt. T ông vấn đề là trong việc giải thích "nhanh" và "tối thiểu". Bạn nên luôn luôn xem xét chi phí dài hạn (trừ khi bạn có một dự án mà điều này không liên quan). Sử dụng một phím tắt chỉ mất 1 ngày nhưng tạo ra nợ công nghệ là 1 tháng sau ngày giao hàng khiến công ty của bạn mất nhiều hơn một giải pháp mất 1 tuần. Ngay lập tức bắt đầu viết bài kiểm tra có vẻ nhanh, nhưng không phải nếu khái niệm của bạn bị sai sót và họ đưa ra một cách tiếp cận sai.

Và hãy ghi nhớ "dài hạn" nghĩa là gì trong trường hợp của bạn: Tôi biết nhiều hơn một công ty đã phá sản bằng cách cố gắng viết mã tuyệt vời và do đó vận chuyển quá muộn. Một kiến ​​trúc tốt hoặc mã sạch - từ góc độ công ty - chỉ có giá trị nếu chi phí để đạt được nó thấp hơn chi phí không có nó.

Mong rằng sẽ giúp!

Nghiêm túc từ góc độ scrum, có vẻ như những gì bạn đang làm sai là bạn không làm việc với khách hàng. Bạn cần phải làm việc cùng với khách hàng để hiểu được những gì họ cần và không chỉ những gì họ muốn . Họ có cần một loạt các sửa chữa nhanh chóng, hoặc họ cần một hệ thống ổn định, có thể bảo trì sẽ phục vụ họ lâu dài? Điều đó có thể khó xác định, nhưng chất lượng cũng nhiều như một yêu cầu như màu nền hoặc điểm chuẩn hiệu suất. Khách hàng cần lưu ý rằng tính ổn định và khả năng bảo trì không miễn phí và phải được thiết kế thành sản phẩm.

Nếu họ nói đó là trước đây, bạn không làm gì sai - giả sử bạn đang giải thích cho họ trong các bài đánh giá nước rút rằng bạn đang cắt các góc kỹ thuật để đáp ứng mục tiêu của họ.

Nếu họ nói đó là cái sau, thì điều bạn đang làm sai là bạn không cho họ thứ họ muốn.

Một trong những nền tảng của Scrum là tính minh bạch. Nếu bạn đang làm scrum, bạn nên thực hiện đánh giá nước rút với khách hàng. Trong các đánh giá đó, bạn có nói với khách hàng rằng bạn đang cắt góc để cung cấp phần mềm nhanh hơn không? Nếu không, bạn nên. Bạn cần phải rõ ràng 100% với khách hàng của mình về sự phân chia các lựa chọn thiết kế của bạn, để cho họ cơ hội đưa ra quyết định sáng suốt về việc bạn có cung cấp phần mềm của bạn với mức chất lượng phù hợp hay không.

Ewan nói đúng. Lý do quản lý thích scrum là vì họ yêu cầu các tính năng theo kiểu staccato và nhận được kết quả nhanh chóng. Cho đến khi kết quả lộn xộn là ai đó có vấn đề.

Bây giờ tôi có sự chú ý của bạn, xin vui lòng để tôi giải thích. Nó không phải là Scrum như vậy. Đó là bối cảnh điển hình của một người quản lý sản phẩm mạnh và một nhóm phát triển yếu không thể đưa ra các ước tính hợp lý và thực tế vì họ cảm thấy áp lực. Vì vậy, họ đưa ra những ước tính lạc quan và tiến sâu vào rắc rối, cắt giảm các góc để đưa ra kịp thời.

Trong scrum, bạn (với tư cách là nhà phát triển) có thể tự lên kế hoạch. Không ai bảo bạn cung cấp một số tính năng trong x ngày. Nếu ai đó bảo bạn giao hàng trong x ngày, bạn không làm Scrum.

Dù vấn đề là gì cần được khắc phục, yêu cầu thời gian của bạn. Bạn có nghĩ rằng bạn cần thời gian để làm lại một cái gì đó đầu tiên? Kết hợp nó trong ước tính của bạn. Bạn có đủ khả năng để làm điều đó?

Hãy xem xét những gì bạn đang làm, để dành Agile một lúc.

Khi chúng tôi lập kế hoạch, chúng tôi luôn tìm giải pháp dễ dàng về thời gian phát triển, vì vậy, nếu chúng tôi đang tạo một hộp thoại mới hoặc một cái gì đó, chúng tôi sử dụng jquery cũ vì nó nhanh hơn và chúng tôi nói rằng chúng tôi sẽ quay lại sau dọn dẹp và biến thành phản ứng, nhưng điều đó hiếm khi xảy ra.

Điều này được gọi là "Nợ kỹ thuật". Martin Fowler đã mô tả "Quadrant of nợ kỹ thuật" trong một blog của anh ta dọc theo hai trục: "Reckless vs. Prudent" và "Deliberate vs. Inadvertent".

Bạn quyết định rõ ràng sử dụng câu đố công nghệ cũ đã biết giúp bạn tiến xa hơn đến một trong những mục tiêu rõ ràng của bạn (cụ thể là một ứng dụng một trang). Bạn làm điều này để cung cấp "một cách nhanh chóng". Đây là cố ý.

Điều tính toán "nhanh chóng" này không bao gồm là thời gian bạn cần thực hiện chức năng phản ứng sau đó. Bạn chọn một giải pháp thay thế chỉ có nhược điểm so với giải pháp thay thế mà bạn biết là chính xác (cụ thể là dành thời gian để thực hiện tính năng trong phản ứng) dựa trên đánh giá rằng tốc độ là điều cốt yếu. Đây là liều lĩnh.

Martin Fowler tổng hợp loại nợ này theo "Chúng tôi không có thời gian cho thiết kế". Đó là một lựa chọn thích hợp trong một môi trường mà bạn không muốn duy trì mã hoặc thậm chí mong đợi mã trong hơn một vài ngày. Nhưng dự án của bạn là một dự án dài hạn liên quan đến việc bảo trì cho (các) khách hàng của bạn

Những gì bạn đang làm là sai ở cấp độ rất cơ bản. Đó là kỹ thuật tồi !

Bạn đã nhận nợ kỹ thuật, bỏ qua rằng khoản nợ này cần phải được trả và tính lãi. Và bạn tiếp tục làm điều đó cho đến khi lãi suất cho khoản nợ của bạn bắt đầu đóng vào công việc có sẵn của bạn trong giai đoạn nước rút của bạn.

Những gì bạn nên làm là giảm mức nợ . Nói chuyện với sếp của bạn, nói chuyện với khách hàng của bạn. Bạn cần phải làm việc trên khả năng bảo trì ngày hôm qua.

Chỉ cần ngừng sử dụng Agile ...

Hay đúng hơn, hãy ngừng cố gắng làm một cái gì đó theo một cách nào đó hoàn toàn bởi vì đó là những gì (sự hiểu biết của bạn) nhanh nhẹn (hoặc scrum, v.v ...) ra lệnh. Cố gắng áp dụng một (giải thích) sai một trong những điều khoản này cho một dự án ở giai đoạn sai có thể nhanh chóng trở thành hành động tồi tệ nhất. Sử dụng lý do của bạn thay vào đó.

Lý do dự án của bạn, và hầu hết các dự án khác trên thế giới, là một mớ hỗn độn về mã và các cách tiếp cận khác nhau, là do thiếu thiết kế kiến ​​trúc tập trung, toàn tri (ở đó, tôi đã nói vậy).

Những lý do này có thể thiếu là:

• Kiến trúc sư không có chuyên môn (Giống như mười dự án sở thích đầu tiên của bạn)
• Kiến trúc sư không có thời gian
• Kiến trúc sư không có quyền lực (Người quản lý nói không, hoặc có nhưng chỉ với một số phần)
• Nhóm nghiên cứu có niềm tin vào một số phương pháp voodoo sẽ cứu họ (Tất cả sẽ tự giải quyết vì chúng tôi đang sử dụng Agile)

Giải pháp đơn giản là bỏ tất cả những từ kỳ diệu này, và nhìn vào thực tế của tình huống, có thể tóm tắt là:

1. Trạng thái của mã đang cản trở khả năng cung cấp đúng thời gian và không có lỗi của nhóm.
2. Chúng ta càng thêm nhiều tính năng, nó sẽ trở nên tồi tệ hơn.
3. Do đó, nó thực sự có ý nghĩa để tạm dừng, đánh giá lại, và (có lẽ quyết liệt) các bộ phận thiết kế lại.

Bạn sẽ tự nhiên đến để hỏi tại sao nó lại đến trạng thái này ngay từ đầu, với ngón tay đổ lỗi xoay tròn. Câu trả lời là điều này là không thể tránh khỏi: khi thiết kế của bạn trưởng thành, bạn nhận ra rằng bạn nên làm điều đó khác đi, nhưng bạn không thể lường trước được. Hơn nữa, đây không phải là một lần thực hiện mỗi dự án, nó sẽ xảy ra nhiều lần và bạn cần lập kế hoạch cho nó.

Đã nói rằng, có rất nhiều điều các nhà quản lý có thể làm để làm trầm trọng thêm mọi thứ:

1. Deathmarbing devs của bạn đến thời hạn.
2. Nói rằng các nhà phát triển chỉ có thể đăng nhập thời gian với vé, mà không có vé cho "tái cấu trúc, suy nghĩ và tái cấu trúc chất lượng" và trợ cấp thời gian hào phóng cho những người đó.
3. Không cho bất kỳ ai sở hữu kiến ​​trúc đủ lâu để có thể xử lý nó
4. Không cho phép người đó thực hiện các thay đổi mà họ nghĩ là cần thiết

Nhìn vào nó theo cách này, thật dễ dàng để thấy một số cách giải thích về agile & scrum sẽ thực sự đưa bạn xuống tuyến đường này thậm chí nhanh hơn!

Một cách tiếp cận là tạo vé cho mỗi bit tái cấu trúc. Vấn đề là bạn thường không nhận ra rằng bạn cần một công cụ tái cấu trúc lớn cho đến khi bạn bắt đầu làm việc với một vé nhỏ hơn, điều này đẩy thời hạn quay trở lại, và vé đi qua các vòng lặp phê duyệt nó chỉ làm mọi thứ chậm lại.

Một cách tiếp cận khác là lên kế hoạch chạy nước rút chỉ sử dụng 25-50% khả năng của nhóm bạn. Sau đó, các nhà phát triển đăng nhập thời gian của họ trên vé thật (ghi lại thời gian cần thiết mà không cần tái cấu trúc) và thời gian tái cấu trúc (một vé lớn trong tuần, không có vòng lặp phê duyệt, chỉ thảo luận giữa các nhà phát triển). Nếu không có cấu trúc lại, bạn có thể kéo vé từ lần chạy nước rút vào tuần tới. Bạn điều chỉnh thanh trượt tỷ lệ phần trăm trong vài tuần tới khi mã cơ bản của dự án được cải thiện.

Vì vậy, để trả lời "chúng ta đang làm gì sai" Tôi muốn nói rằng bạn đang đặt niềm tin vào một phương pháp theo lẽ thường. Bạn thậm chí yêu cầu một "cách tiếp cận nhanh cho vấn đề này" . Tôi muốn nói thả lời và suy nghĩ về vấn đề thực tế. Nếu sau đó bạn thực sự muốn chọn ra nhiều bản tuyên ngôn khác nhau đang cố gắng giải mã liệu phương pháp tiếp cận thông thường cuối cùng của bạn có thực sự nằm trong chiêu bài "nhanh nhẹn" hay "scrum" hay không, bằng mọi cách hãy làm điều đó :-)

Bạn không làm gì sai cả. Loại phương pháp này được thiết kế để cung cấp các tính năng cho thông số kỹ thuật và nhanh nhất có thể.

Nếu bạn có những mục tiêu thứ yếu mà bạn đang hướng tới thì tốt nhất là thể hiện chúng dưới dạng 'yêu cầu phi chức năng' hoặc 'định nghĩa hoàn thành'.

ví dụ: bạn có thể có một yêu cầu phi chức năng:

"Tất cả các tính năng mới phải được viết bằng React"

và

"Tất cả các cuộc gọi không đồng bộ phải thực hiện một công cụ tải và xử lý lỗi"

Bạn chỉ cần khiến Chủ sở hữu sản phẩm của mình (hoặc tương đương) đồng ý rằng đây là những việc đáng làm, thay vì lén lút vì các nhà phát triển thích chúng.