Nhanh nhẹn mà không cần kiểm tra đơn vị

Liệu có ý nghĩa gì khi nói về "phát triển nhanh" hay tuyên bố rằng bạn đang áp dụng "phương pháp nhanh" nếu cơ sở mã bạn đang làm việc có độ bao phủ kiểm tra đơn vị 0%? (Và bạn, với tư cách là một đội, không làm gì về điều đó).

Để làm cho nó rõ ràng: với tôi, nó không có ý nghĩa. Theo kinh nghiệm cá nhân của tôi, tôi thấy rằng các bài kiểm tra đơn vị là công cụ duy nhất cho phép bạn thực sự "nhanh nhẹn" (tức là phản ứng với các thay đổi, cải thiện thiết kế, chia sẻ kiến ​​thức, v.v ...) và TDD là cách thực hành duy nhất đưa bạn đến đó .

Có thể có một số cách khác, nhưng tôi vẫn không thể thấy chúng có thể hoạt động như thế nào.

Để trở thành mô phạm, không có gì trong Tuyên ngôn Agile hoặc Hướng dẫn Scrum làm cho bất kỳ tài liệu tham khảo nào về thực hành kỹ thuật, như thử nghiệm đơn vị hoặc TDD, cả. Vì vậy, vâng, về lý thuyết bạn có thể giao hàng sớm và thường tập trung vào sự hợp tác và giá trị mà không có họ và tự gọi mình là Agile, bạn thậm chí có thể thực sự nhanh nhẹn .

Tuy nhiên, trên thực tế, gần như không thể cung cấp giá trị ( vào sản xuất ) một vài tuần mà không có bộ kiểm tra tốt. Điều này bao gồm các bài kiểm tra tích hợp cũng như các bài kiểm tra đơn vị. Kiểm tra đơn vị chỉ đi cho đến nay. Có một lý do đó là kim tự tháp và không phải là một hình chữ nhật.

Nếu không có các thử nghiệm như một mạng lưới an toàn, bạn sẽ giới thiệu rất nhiều lỗi hồi quy trong mỗi bản phát hành, hoặc sợ hãi khi tái cấu trúc. Cả hai sẽ tác động lớn đến khả năng tiếp tục phát triển bền vững của bạn . Nếu bạn không thể duy trì tốc độ của mình hoặc thay đổi khóa học (thiết kế lại) khi được yêu cầu, thì bạn không có sự nhanh nhẹn. Nhanh nhẹn, sau tất cả, là mục tiêu chúng ta phấn đấu.

Bản tuyên ngôn nhanh nhẹn chỉ đơn giản là:

Các cá nhân và tương tác qua các quy trình và công cụ

Phần mềm làm việc trên tài liệu toàn diện

Hợp tác khách hàng qua đàm phán hợp đồng

Đáp ứng để thay đổi theo kế hoạch

Không đề cập đến các bài kiểm tra đơn vị ở đó. Ngay cả 12 nguyên tắc không đề cập đến thử nghiệm.

Vì vậy, về mặt kỹ thuật, có thể trở thành một đội nhanh nhẹn mà không cần viết bài kiểm tra đơn vị. Trong thực tế, thật khó để thấy làm thế nào một nhóm có thể duy trì phần mềm làm việc trong môi trường nhanh nhẹn mà không cần kiểm tra để giúp họ thực hiện các thay đổi liên tục.

Mặc dù không có từ trực tiếp nào nói về thử nghiệm đơn vị hoặc TDD hoặc bất kỳ loại thử nghiệm nào trong bản tuyên ngôn nhanh như những người khác đã trả lời ở đây, tôi tin rằng một Scrum Master hoặc Developer tốt sẽ có thể nhận ra một trong những tuyên bố trong bản tuyên ngôn.

Phần mềm làm việc  trên tài liệu toàn diện.

Làm thế nào có ai biết nếu phần mềm đang hoạt động? Bản tuyên ngôn không cần phải nêu rõ ràng việc kiểm tra thuật ngữ. Nó cô đọng.

Kiểm thử đơn vị (trong ngữ cảnh của chủ đề) sẽ làm cho giai đoạn mã hóa của bạn chậm lại ở giai đoạn trước nhưng sẽ có giá trị khi bạn tiến bộ, giúp phát triển nhanh hơn rất nhiều. Nó cung cấp cho bạn quyền kiểm soát hạt tốt trong kiểm tra mức mã cũng như làm cho thiết kế của bạn có thể mở rộng, giúp bạn tự tin rằng phần mềm của bạn đang hoạt động và có thể dễ dàng xử lý hồi quy; mà sẽ làm cho sự phát triển của bạn nhanh nhẹn.

Nó hoàn toàn có ý nghĩa. Agile không phải là về thử nghiệm, như những người khác đã đề cập, nhưng để trả lời cụ thể câu hỏi của bạn:

Không, bạn hoàn toàn không cần thử nghiệm đơn vị.

Bạn chỉ có thể chạy một quy trình nhanh với kiểm tra tích hợp. Bạn có thể chạy thử nghiệm tích hợp tự động hàng đêm chẳng hạn và sửa các lỗi được tìm thấy vào ngày hôm sau. Bạn có thể có một người kiểm tra thủ công chạy thử nghiệm tích hợp liên tục nếu bạn muốn. Bất kể hệ thống, kiểm tra đơn vị là hoàn toàn tùy chọn.

Bạn có thể thấy thử nghiệm đơn vị giúp bạn phát triển và đủ công bằng với điều đó, nhưng có nhiều điều có thể giúp phát triển mà bạn có thể không có.

Mặc dù vậy, bạn cần một số hình thức kiểm tra, ngay cả khi đó là 'trình kiểm tra beta khách hàng cũ'. Nếu khách hàng của bạn tham gia nhiều vào quá trình và không bận tâm đến việc tìm lỗi, thì điều này có thể hoạt động - vì họ có xu hướng tìm thấy các lỗi mà không ai khác nghĩ là lỗi!

Nó không bắt buộc. Kiểm tra là tuyệt vời khi bạn có những người thực sự biết cách sử dụng nó. Khi bạn không, không chỉ không cần thiết, nó trở thành một trách nhiệm pháp lý. Tôi muốn nói có nhiều lập trình viên không giỏi về nó.

Tôi rất vui vì bạn đã thừa nhận trong câu hỏi của mình rằng nhanh nhẹn là về cách bạn thực sự phát hành phần mềm thay vì làm theo một số phương pháp. Bản tuyên ngôn Agile là một tài liệu tham khảo hay, nhưng nó không phải là hướng dẫn dứt khoát. Agile tồn tại trước khi nó xảy ra. Có nhiều cách để phát triển phần mềm trở nên "nhanh nhẹn hơn" nhưng các kết hợp khác nhau có thể được sử dụng cho các dự án khác nhau.

Nếu bạn đang phát hành phần mềm mới với tốc độ được khách hàng chấp nhận, có lẽ bạn nhanh nhẹn. Tôi cũng sẽ bao gồm việc không có quá nhiều phản hồi và phàn nàn về những thay đổi tính năng của các nhà phát triển. Sửa một thứ chỉ để phá vỡ một thứ khác cũng không lý tưởng. Khi người dùng của bạn chậm một số phiên bản nâng cấp, có thể bạn không nhanh nhẹn cho dù bạn có kiểm tra hay không.

Tôi muốn phản bác lại (các câu trả lời khác) rằng bản tuyên ngôn Agile có nêu rõ điều gì đó về điều này, cụ thể là:

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.

Tôi thực sự thích định nghĩa LeSS về sự xuất sắc kỹ thuật và nó bao gồm kiểm tra đơn vị và TDD. Bây giờ bạn có thể lập luận rằng bạn có thể không cần kiểm tra đơn vị và hoặc TDD để đạt được điều này, nhưng đó là cách phổ biến nhất và có thể được khuyên.

Agility tổ chức bị hạn chế bởi Agility kỹ thuật

Nói cách khác, khi bạn chậm thực hiện các thay đổi cho sản phẩm của mình, thì việc bạn cấu trúc các nhóm, tổ chức của bạn hoặc khuôn khổ bạn áp dụng là gì, bạn sẽ chậm phản ứng với các thay đổi.

Nếu bạn có thể ngăn sản phẩm của mình chống lại sự thay đổi theo cách khác, bạn có thể đang đi đúng hướng, nhưng:

Tôi đã phát minh ra lập trình cực đoan để làm cho thế giới an toàn cho các lập trình viên. - Kent Beck

Scrum thiếu bất kỳ thực hành kỹ thuật nào, nhưng Jeff đã nói như sau về nó:

Tôi chưa bao giờ thấy một nhóm Scrum siêu năng suất không sử dụng các thực tiễn phát triển Lập trình cực đoan. - Jeff Sutherland

Trích dẫn từ bài viết này: http://ronjeffries.com/articles/017-02ff/gathering2017/

Tôi mong đợi các nhóm Scrum không có thực hành kỹ thuật cuối cùng bằng cách sử dụng các hồi cứu đưa ra một thực tiễn tương tự. Bạn muốn siêu năng suất quá, phải không?

Các fluence Agile mô hình, đề cập đến nó trong mức hai ngôi sao:

Các kỹ thuật hữu ích bao gồm tích hợp liên tục, phát triển dựa trên thử nghiệm , lập trình cặp và sở hữu tập thể.

Nếu bạn chỉ nhắm mục tiêu mức độ lưu loát Agile đầu tiên, bạn có thể bỏ qua việc thực hành, nhưng bất kỳ sản phẩm nào lớn hơn và chạy lâu hơn đều nên cố gắng đạt được mức hai sao.

Vì vậy, sự đồng thuận chung là có mà không có kiểm thử đơn vị tốt, mã sạch và thực hành tái cấu trúc, hiện tại không thể thực sự Agile. Điều này có thể thay đổi trong tương lai khi các thực hành kỹ thuật mới xuất hiện.

Bạn nghĩ câu trả lời sẽ là gì nếu chúng ta hỏi một số người ký tuyên ngôn như Robert C. Martin, Martin Fowler hay Kent Beck? Có thể họ sẽ nói nó phụ thuộc, nhưng nói chung đó là điều bạn nên làm.