Có thể tự gọi chính mình (hoặc nhóm của bạn) "Agile" nếu bạn không thực hiện TDD (Phát triển dựa trên thử nghiệm)?

Vâng, vâng, vâng, một triệu lần có.

Agile là một triết lý, TDD là một phương pháp cụ thể.

Nếu tôi muốn thực sự kén chọn, tôi có thể chỉ ra rằng có khá nhiều biến thể của xDD - mà những người ủng hộ của họ sẽ giải thích sâu không phải là TDD - nhưng những điều đó về cơ bản vẫn bị ràng buộc với thử nghiệm vì vậy sẽ là gian lận.

Vì vậy, hãy nói điều này - bạn có thể nhanh nhẹn mà không cần thực hiện phát triển "thử nghiệm trước" (xem cách thức hoạt động của scrum - không có thông tin cụ thể nào về cách bạn viết mã). Nhìn vào một bảng Kanban, nhìn vào tất cả các loại phương pháp nhanh.

Bạn có muốn kiểm tra đơn vị? Tất nhiên là bạn làm, vì tất cả các loại lý do - và bạn cũng có thể đưa ra một lập luận rằng bạn không thể nhanh nhẹn nếu không có bài kiểm tra đơn vị (mặc dù tôi nghi ngờ rằng bạn có thể) - nhưng trước tiên bạn không phải viết chúng nhanh nhẹn.

Và cuối cùng, cũng đúng như vậy, bạn có thể thực hiện Thử nghiệm đầu tiên mà không cần phải nhanh nhẹn và lập luận mạnh mẽ để thực hiện thử nghiệm trước bất kể triết lý nhà phát triển tổng thể của bạn.

Có vẻ như những người khác (với một đại diện RẮN hơn) có cùng quan điểm ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Mặc dù không thể làm Agile nếu không có TDD và OOD, nhưng điều đó thật khó. Không có TDD, tốc độ lặp của ...

(Liên kết trong tweet là câu trả lời đầy đủ trên LinkedIn)

"Nhanh nhẹn" chỉ đơn giản là tuân thủ các giá trị và nguyên tắc của bản tuyên ngôn nhanh . Không có gì trong tài liệu đó đề cập đến TDD, hoặc thậm chí kiểm tra đơn vị cho vấn đề đó.

Vì vậy, có, bạn có thể nhanh nhẹn mà không cần làm TDD hoặc kiểm tra đơn vị.

Tôi sẽ không đề nghị nó mặc dù ...

Có ,

Nhìn vào một trong những giá trị nhanh:

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

Điều đó sẽ trả lời nó rồi. TDD là một phương pháp nhất định, một quá trình. Thật vậy, một quá trình có thể có thể được sử dụng trong các quy trình phát triển nhanh, nhưng không có gì hơn thế. Tôi nghĩ rằng có lẽ TDD là trạng thái của nghệ thuật bây giờ khi nhanh nhẹn. Nhưng tôi nghĩ rằng khái niệm nhanh nhẹn vẫn có thể tồn tại, ngay cả khi có thể TDD đã được thay thế bằng các thực tiễn khác.

Tôi sẽ tổng hợp nó như sau:

• Ngày nay TDD là một tiêu chuẩn không chính xác để nhanh nhẹn

• Có thể có những cách nhanh nhẹn mà không cần TDD

tôi nói

Không có [loại]

Nếu bạn quay lại nguồn ban đầu http://en.wikipedia.org/wiki/Extreme_Programming TDD là nền tảng cho quy trình; các thử nghiệm thay thế các thông số kỹ thuật yêu cầu và trường hợp sử dụng của thác nước, đóng vai trò là tài liệu sống và các ví dụ hoạt động, v.v ... Chúng không thể thiếu.

Tuy nhiên, có rất nhiều hương vị 'nhanh nhẹn' khác nhau trôi nổi xung quanh đến nỗi hoàn toàn có khả năng một trong số họ tránh khỏi TDD

EDIT: @ Murph's giải thích câu hỏi dường như là câu hỏi ưa thích. Tôi thậm chí còn ủng hộ nó, đó là một câu trả lời tốt. Tuy nhiên , tôi duy trì quan điểm của mình rằng Tuyên ngôn Agile là một tập hợp các nguyên tắc, không phải là một phương pháp phát triển. Tôi thấy không có ích gì khi nói "ồ, tôi nhanh nhẹn" mà không thực sự thực hiện các thực hành mang lại lợi ích. Đặc biệt:

Phần mềm làm việc là thước đo chính của sự tiến bộ.

và

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.

Đối với tôi, hai nguyên tắc này ngụ ý nếu không yêu cầu TDD - ít nhất tôi biết không có cách nào khác để đạt được chúng mà không có nó!

EDIT 2: có, về mặt kỹ thuật bạn có thể viết các bài kiểm tra sau đó; nhưng tôi vẫn coi test-first / TDD là cơ bản. Không phải vì bạn không thể "nhanh nhẹn" nếu không có nó, mà bởi vì bạn sẽ nhanh nhẹn hơn với nó. Thử nghiệm đầu tiên / thử nghiệm dựa trên thử nghiệm là một cách tiếp cận hiệu quả hơn nhiều so với thử nghiệm sau / thử nghiệm sau. Các mô tả thử nghiệm là các yêu cầu . Đừng để chúng ra sau này ;-)

EDIT 3: Cuối cùng tôi đã tìm ra điều gì làm phiền tôi rất nhiều về câu trả lời được viết rất tốt của Murph. Đó là khái niệm rằng người ta có thể "nhanh nhẹn" mà không thực sự làm điều đó . Và "làm điều đó" (như được hiển thị ở trên) khá nhiều đòi hỏi TDD.

Nghiêm túc, bạn nhanh nhẹn bằng cách tuân thủ tuyên ngôn nhanh nhẹn . Trong thực tế, một cơ sở mã không nhanh nhẹn trừ khi nó có phạm vi kiểm tra tốt. Bạn có thể làm TDD và viết các bài kiểm tra trước / trong quá trình phát triển chức năng hoặc viết các bài kiểm tra cho chức năng sau khi nó được phát triển. Nó thường dễ dàng và hiệu quả hơn để làm theo cách TDD.

Bạn có thể nhanh nhẹn, nhưng có lẽ có chỗ để cải thiện.

Một trong những nguyên tắc nhanh nhẹn là bạn phải có khả năng đáp ứng với sự thay đổi. Điều này có nghĩa là không biết trước những gì bạn phải xây dựng. Nếu bạn đang theo dõi quá trình thác nước, bạn sẽ biết trước x tháng chính xác những gì bạn cần xây dựng và bạn có thể thiết kế các thành phần phần mềm riêng lẻ để chúng tham gia vào một sơ đồ lớn hơn, đạt đến sản phẩm cuối cùng (ít nhất là bạn sẽ nghĩ rằng nó là như vậy). Nhưng vì nhanh nhẹn ra lệnh rằng bạn không biết sản phẩm cuối cùng là gì, nên bạn không bao giờ biết mã của mình sẽ được sử dụng để làm gì và quan trọng hơn là khi nào nó sẽ được thay đổi.

Do đó, bạn cần có bộ kiểm tra kỹ lưỡng để đảm bảo rằng các tính năng mà bạn đã xây dựng tiếp tục hoạt động khi cơ sở mã được sửa đổi.

Nhưng đó không phải là TDD. Nếu bạn viết các bài kiểm tra sau khi bạn viết mã, thì đó không phải là TDD. Nhưng TDD giúp với một khía cạnh khác, nó ngăn chặn sản xuất thừa.

Trong nhóm nhanh nhẹn của riêng tôi, tôi đã phải vật lộn với các nhà phát triển viết mã mà họ tin rằng sẽ trở nên hữu ích sau này trong dự án. Nếu đó là sự phát triển thác nước có lẽ sẽ ổn, bởi vì họ đã thêm hỗ trợ cho một cái gì đó trong kế hoạch dự án cho x tháng tới.

Nhưng nếu bạn đang tuân theo các nguyên tắc nhanh, bạn không nên viết mã này, bởi vì bạn không biết liệu điều đó có cần thiết hay không. Tính năng đã được lên kế hoạch cho tuần tới có thể đột nhiên bị hoãn vô thời hạn.

Nếu bạn tuân thủ đúng nguyên tắc TDD, thì một dòng mã duy nhất không thể tồn tại trước khi kiểm tra chỉ ra dòng mã này (cá nhân tôi có thể viết một số mã tầm thường mà không cần kiểm tra) và nếu bạn bắt đầu bằng cách viết thử nghiệm chấp nhận, thì bạn chỉ thực hiện chính xác những gì cần thiết để cung cấp các tính năng cần thiết.

Vì vậy, TDD giúp tránh sản xuất thừa, cho phép nhóm làm việc hiệu quả nhất có thể, đây cũng là một nguyên tắc nhanh nhẹn cốt lõi.

Phần mềm làm việc là thước đo chính của sự tiến bộ

Bạn có thể Agile mà không cần làm TDD (phát triển theo hướng kiểm tra) không?

Câu trả lời ngắn gọn: Có.

Câu trả lời dài hơn: Có rất nhiều câu trả lời thực sự tốt cho câu hỏi này và tài liệu tham khảo rất tốt. Tôi sẽ không cố gắng tranh luận về những điểm đó.

Theo kinh nghiệm của tôi, Agile là về việc chọn đúng mức Lean-ness cho dự án trong tay. Lean-ness có ý nghĩa gì? Và, tại sao tôi lại đưa nó vào câu trả lời này?

Lean không có nghĩa là cắt mọi thứ có thể ra khỏi phương pháp của bạn. Như một trong những đồng nghiệp của chúng tôi đã lưu ý, bạn không cần phải đưa TDD hoặc Kiểm tra đơn vị vào hành vi của mình. Tuy nhiên, trong bối cảnh dự án bạn thấy mình, nó có thể có hoặc không có lợi.

Hãy nghĩ về chuỗi cung ứng cho một nhà bán lẻ lớn không tên ở AK. Có người tiêu dùng. Họ đi vào cửa hàng. Cửa hàng nhận được nhiều sản phẩm thông qua xe tải. Những chiếc xe tải, có lẽ, lấy những sản phẩm đó từ một nhà kho. Các kho được lấp đầy bởi các lô hàng từ các nhà sản xuất khác nhau. Các nhà sản xuất lần lượt có toàn bộ chuỗi cung ứng.

Điều gì xảy ra khi tổng giám đốc vận chuyển trong chuỗi cung ứng nói trên nói rằng anh ta sẽ nhận được tiền thưởng hàng năm 1 triệu đô la cho mỗi năm khi anh ta có ít hơn 10 xe tải trong đội tàu? Anh ta sẽ ngay lập tức chặt hạm đội tới 9 xe tải. Trong kịch bản "khủng khiếp" này, điều này sẽ thúc đẩy lượng hàng hóa được lưu trữ trong kho (tăng chi phí trong nút đó). Và, nó sẽ "bỏ đói" mặt tiền cửa hàng.

Vì vậy, chuỗi cung ứng tổng thể bị ảnh hưởng nếu tối ưu hóa cục bộ được cho phép mà không xem xét toàn bộ.

Quay lại TDD và UT. TDD là một cơ chế biểu hiện yêu cầu. Hệ thống PHẢI thực hiện theo những ràng buộc đó. Đủ công bằng. TDD có thể thay thế hành vi yêu cầu của Use Case Development hoặc hành vi yêu cầu của User Story Driven Development. Nó có lợi ích "nghiêng" khi kết hợp tải công việc Kiểm tra đơn vị và Yêu cầu. Đó là một lợi ích nếu tải công việc tổng thể giảm. Không, nếu khối lượng công việc của chuỗi cung ứng tổng thể tăng lên (hãy sửa chữa chất lượng).

Và vì vậy, bạn đã hỏi: Bạn có thể Agile mà không cần thực hiện TDD (phát triển theo hướng kiểm tra) không?

Chắc chắn bạn có thể. Một câu hỏi khác, và có lẽ tốt hơn, là: - Nếu tôi áp dụng TDD cho dự án này, nó sẽ dẫn đến việc phân phối phần mềm hiệu quả hơn hay hiệu quả thấp hơn?

Để trích dẫn một tác giả yêu thích ... JRR Tolkien

Chúa tể của những chiếc nhẫn. Học bổng của những chiếc nhẫn. PGS 94 'Và người ta cũng nói', đã trả lời Frodo, 'Đừng đến với yêu tinh để được tư vấn, vì họ sẽ không và có.'

Vì vậy, cuối cùng, ... nó phụ thuộc. Bạn phải trả lời câu hỏi. Con đường nào sẽ dẫn bạn đến mục tiêu mong muốn của bạn một cách hiệu quả nhất.

Đến TDD hay không TDD. Đó vẫn là câu hỏi. :-)

Tái bút - Tôi cũng đang đăng lại câu trả lời này trên một trang web khác. https://www.ibm.com/developerworks/mydeveloperworks/bloss/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

So sánh với kỹ thuật một lâu đài.

Lâu đài Agile

Nếu bạn thiết kế một lâu đài bằng Agile. Bạn sẽ viết các phần có chức năng cụ thể và khuyến khích người dùng sử dụng các bộ phận chức năng, điều chỉnh thiết kế trong tương lai theo phản ứng của người dùng. Vì vậy, bạn xây dựng ngục tối và liên lạc với người giữ ngục tối, bạn sẽ kiểm tra nền tảng được cung cấp bởi đất và ngục tối. Bạn sẽ xây dựng lan can và hỏi những người chơi đêm nếu nó tốt. Bạn sẽ xây dựng các bức tường và yêu cầu các binh sĩ kiểm tra giá trị phòng thủ. Bạn sẽ xây dựng nhà bếp và để đầu bếp nhìn qua. Và trong quá trình này, mọi bộ phận cho đến nay sẽ hoạt động cùng với cấu trúc hiện tại. Vì vậy, khi bạn hoàn thành ngục tối, bạn có thể di chuyển các tù nhân vào. Và cứ thế. Nhưng cuối cùng khi bạn hoàn thành lâu đài, bạn phát hiện ra các tù nhân đã trốn thoát.

Lâu đài TDD

Với TDD, bạn xuất hiện cùng các tù nhân và xem họ có trốn thoát không. Sau đó, bạn viết các ô tù cho đến khi chúng không thể trốn thoát. Sau đó, bạn sẽ cấu trúc lại mã một cách sạch sẽ loại bỏ các ô không cần thiết và loại bỏ các thanh nằm sai vị trí và kiểm tra lại. Các tù nhân đã không trốn thoát. Bạn không phải liên lạc với giám thị. Và bạn có thể giao toàn bộ lâu đài sau khi hoàn thành tất cả. Vào thời điểm đó, quản ngục nói rằng ngục tối cần nhiều tế bào hơn và bây giờ bạn phải đào thêm nền tảng.

Lâu đài TDD nhanh nhẹn

Nếu bạn kết hợp Agile và TDD. Bạn sẽ thấy các tù nhân trốn thoát, sau đó hỏi quản ngục những gì cần thiết. Ông nói rằng bạn cần nhiều tế bào hơn. Bạn sẽ bắt một số người ngẫu nhiên giả làm tù nhân và xem họ có trốn thoát không. Nếu họ không, sau đó bạn đưa nó cho giám thị, và anh ta hài lòng với nó. Sau đó, bạn bắt đầu xây dựng lan can.

Phần kết luận

Vì vậy, cả hai giải quyết các vấn đề khác nhau. Agile giúp thay đổi các yêu cầu dựa trên việc khám phá nhu cầu của người dùng khi họ thấy sản phẩm phát triển tại điểm trong quy trình dễ thích nghi nhất. Nó liên quan đến việc phát hành bổ sung ổn định được chia ra từ thiết kế tổng thể.

TDD giải quyết vấn đề dự đoán thất bại. Khám phá và sửa chữa thất bại khi nó xảy ra tại một điểm trong quy trình dễ khắc phục nhất. Nó liên quan đến việc kiểm tra các đơn vị mã được ghép nối ổn định được chia ra từ thiết kế tổng thể.

Thật dễ dàng để xem TDD như một phần mở rộng cho Agile, bởi vì cả hai đều theo cùng một mô hình, tiến trình và đánh giá theo đơn vị. Sự khác biệt là các đơn vị trong chức năng Agile được cập nhật bên ngoài nói chung, trong khi các đơn vị trong chức năng TDD là một phần và không thể tạo ra một sản phẩm hoạt động để xem xét bên ngoài. Và cả hai quá trình chi phối các nhu cầu khác nhau (khả năng sử dụng so với tính chính xác). Vì cả hai chức năng trong một quá trình phát triển theo đơn vị, cả hai quá trình xem xét đều có thể xảy ra tại các điểm tương tự nhau, với TDD được phân chia chính xác hơn.

Ghi chú

• Có bài kiểm tra đơn vị không có nghĩa là bạn sử dụng TDD. TDD có nghĩa là có thử nghiệm trước đơn vị sản xuất và sử dụng thử nghiệm khi bạn phát triển để xác nhận đơn vị. Kiểm tra đơn vị không có TDD có thể được sử dụng để đảm bảo bạn không làm mất hiệu lực chức năng được xây dựng trước đó.
• Có chạy nước rút và các cuộc họp khác không làm cho bạn nhanh nhẹn. Các mục tiêu của bảng kê khai làm cho bạn nhanh nhẹn. Bạn có thể chia nhỏ các mục tiêu thác nước thành nước rút với các đơn vị công việc, mà không đáp ứng cam kết ủng hộ mọi người qua các quy trình.
• Theo định nghĩa của TDD và Agile. Các bài kiểm tra đơn vị của bạn sẽ chi phối các đơn vị không thể phân phối và do đó TDD sẽ quay vòng nhanh hơn Agile. Và nếu bạn sử dụng cả hai, các chu trình Agile của bạn sẽ chứa một hoặc nhiều chu kỳ TDD (nếu mọi đơn vị được kiểm tra).
• Từ những gì tôi hiểu: Bạn thất bại Agile bằng cách không phát triển một đơn vị có thể phân phối / có ý nghĩa cho người dùng. Các đơn vị có thể có ý nghĩa ngay cả khi nó tăng tốc sản phẩm. Nhưng làm thế nào để Agile giải thích tái cấu trúc để bảo trì dễ dàng hơn? Tôi đã không bao gồm nó đủ để trả lời điều đó.
• Bạn thất bại TDD bằng cách trượt bài kiểm tra đơn vị. Sản xuất mã không sản xuất tính năng chính xác.

Agile buộc bạn phải giải quyết và giảm thiểu rủi ro về lịch trình và chất lượng ở mỗi lần lặp. tức là TDD không cần thiết để được coi là Agile .

Tuy nhiên, TDD là một kỹ thuật to lớn để giảm thiểu rủi ro chất lượng, đặc biệt đối với một dự án có số lượng lặp hoặc số người lớn. Trong một dự án như vậy, TDD sẽ thêm một số rủi ro lịch trình trong các lần lặp đầu tiên, bởi vì bạn cũng phải viết các trường hợp thử nghiệm. Tuy nhiên, TDD mang lại tiết kiệm chi phí rất lớn trong các lần lặp lại sau vì nó liên tục giảm thiểu rủi ro chất lượng. tức là TDD được khuyến nghị.