TDD (Test-Driven Development)를하지 않으면 자신 (또는 팀)을 "Agile"로 올바르게 호출 할 수 있습니까?

예, 그렇습니다

애자일은 철학이고 TDD는 특정 방법론입니다.

정말 까다 롭고 싶었다면 xDD에는 몇 가지 변형이 있다는 것을 지적 할 수 있습니다. xDD에는 깊이있는 설명이 TDD 가 아니라고 설명 합니다.

따라서 "먼저 테스트"개발을 수행하지 않고도 민첩 할 수 있습니다 (스크럼 작동 방식을 살펴보십시오. 코드 작성 방법에 대한 구체적인 내용은 없습니다). 칸반 보드를보고 모든 종류의 민첩한 방법론을보십시오.

단위 테스트를 원하십니까? 물론, 당신은 모든 종류의 이유로-당신은 (단지 당신이 할 수 있다고 생각하지만) 단위 테스트없이 민첩 할 수 없다는 주장을 할 수 있습니다-그러나 당신은 그것을 먼저 쓸 필요는 없습니다. 기민한.

마지막으로 전반적인 개발 철학에 관계없이 먼저 테스트를 수행하는 민첩하고 강력한 주장 없이 Test First 를 수행 할 수 있다는 것도 마찬가지입니다 .

SOLID 담당자가 더 많은 다른 사람들도 비슷한 의견을 가지고있는 것 같습니다 ...

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

@unclebobmartin : http://t.co/huxAP5cS TDD 및 OOD없이 Agile을 수행하는 것은 불가능하지 않지만 어렵습니다. TDD가 없으면 반복 속도는 ...

(Tweet의 링크는 LinkedIn의 전체 답변에 대한 링크입니다)

"민첩한"이란 민첩한 선언문 의 가치와 원칙을 준수한다는 의미 입니다. 이 문서에는 TDD 또는 해당 문제에 대한 단위 테스트에 대한 언급이 없습니다.

따라서 TDD 또는 단위 테스트를 수행하지 않고도 민첩 할 수 있습니다.

그래도 권장하지 않습니다 ...

예 ,

민첩한 가치 중 하나를 살펴보십시오.

프로세스 및 도구에 대한 개인 및 상호 작용

그것은 이미 대답해야합니다. TDD는 특정 방법론, 프로세스입니다. 실제로 민첩한 개발 프로세스에 사용될 수있는 프로세스이지만 더 이상은 없습니다. 아마 민첩 할 때 TDD가 최첨단이라고 생각합니다. 그러나 TDD가 다른 관행으로 대체 된 경우에도 민첩성의 개념은 계속 지속될 수 있다고 생각합니다.

나는 그것을 다음과 같이 요약 할 것이다.

• 오늘날 TDD는 민첩성을위한 사실상의 표준입니다.

• TDD없이 민첩 해지는 방법이있을 수 있습니다

내가 말하다

아니오 [정렬]

원래 소스로 돌아 가면 http://en.wikipedia.org/wiki/Extreme_Programming TDD는 프로세스의 기본입니다. 이 테스트는 폭포수의 요구 사항 사양 및 사용 사례를 대체하고 실제 문서 및 기능 예제 등을 제공합니다. 필수 불가결합니다.

그러나 주위에 떠 다니는 다양한 '민첩한'풍미가 너무 많아서 그중 하나가 TDD를 피할 수 있습니다.

편집 : @ 머프의 질문 해석은 선호되는 것으로 보입니다. 나는 심지어 그것을 upvoted, 좋은 답변입니다. 그러나 Agile 선언은 개발 방법론이 아니라 일련의 원칙이라는 입장을 유지합니다. 나는 실제로 이점을 가져 오는 관행을 구현하지 않고 "아, 민첩하다"라고 말하는 데 아무런 소용이 없습니다. 특히:

작동하는 소프트웨어는 기본 진행 측정입니다.

과

민첩한 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야합니다.

나에게이 두 가지 원칙은 TDD가 필요하지 않다면 암시한다. 적어도 나는 그것이 없이는 TDD를 달성 할 수있는 다른 방법을 모른다!

편집 2 : 예, 기술적으로 나중에 테스트를 작성할 수 있습니다. 그러나 나는 여전히 테스트 우선 / TDD를 기본으로 간주합니다. 그것 없이는 "민첩"할 수 없기 때문에, 더 민첩 해질 것입니다. Test-first / test-driven은 시험 후 / 시험 후보다 훨씬 효율적인 접근 방식입니다. 테스트 설명 은 요구 사항 입니다. 나중에까지 미루지 마십시오 ;-)

편집 3 : 마침내 Murph의 잘 작성된 답변에 대해 나를 귀찮게하는 것이 무엇인지 알아 냈습니다. 그것은 하나의 사실없이 "애자가 될"수하는 개념이다 그 일을 . 그리고 "위에서"(위 그림 참조) TDD가 거의 필요합니다.

엄격하게, 당신은 민첩한 선언문 을 준수함으로써 민첩 합니다. 실제로 코드 기반은 테스트 범위가 좋지 않으면 민첩하지 않습니다. 기능 개발 전 / 중에 TDD를 수행하고 테스트를 작성하거나 기능이 개발 된 후 테스트를 작성할 수 있습니다. TDD 방식으로 수행하는 것이 일반적으로 더 쉽고 효과적입니다.

민첩 할 수 있지만 개선의 여지가있을 것입니다.

민첩한 원칙 중 하나는 변화에 대응할 수 있어야한다는 것입니다. 이것은 당신이 무엇을 만들어야하는지 미리 알지 못한다는 것을 의미합니다. 워터 폴 프로세스를 따랐다면, 정확히 무엇을 구축해야하는지 x 개월 전에 미리 알고 있으며 개별 소프트웨어 구성 요소를 설계하여 각각 더 큰 계획에 참여하여 최종 제품에 도달 할 수 있습니다 (적어도 그렇습니다). 그러나 애자일은 최종 제품이 무엇인지 알지 못하므로 코드가 어떤 용도로 사용되는지, 더 중요한 것은 언제 변경되는지 알 수 없습니다.

따라서 코드 기반이 수정 될 때 이미 빌드 한 기능이 계속 작동하는지 확인하기 위해 철저한 테스트 스위트가 필요합니다.

그러나 그 자체는 TDD가 아닙니다. 코드를 작성한 후 테스트를 작성하면 TDD가 아닙니다. 그러나 TDD는 다른 측면에 도움이되며 과잉 생산을 방지합니다.

내 민첩한 팀에서 개발자가 프로젝트 후반에 유용 할 것으로 생각되는 코드를 작성하는 데 어려움을 겪고 있습니다. 그들이 다음 x 개월 동안 프로젝트 계획에서 무언가에 대한 지원을 추가했기 때문에 아마도 폭포 개발이 있었을 것입니다.

그러나 민첩한 원칙을 따르는 경우이 코드를 작성해서는 안됩니다.이 코드가 필요한지 알 수 없기 때문입니다. 다음 주에 계획된 기능은 갑자기 연기 될 수 있습니다.

TDD 원칙을 올바르게 준수하면 테스트 에서이 코드 줄을 지시하기 전에 한 줄의 코드가 존재할 수 없으며 (개인적으로 테스트하지 않고 사소한 코드를 작성할 수 있음) 수락 테스트를 작성하여 시작하면 구현 만 가능합니다 필요한 기능을 제공하는 데 필요한 것.

따라서 TDD는 과잉 생산을 방지하여 팀이 최대한 효율적으로 운영 할 수 있도록하는데 이는 핵심 민첩한 원칙이기도합니다.

작업 소프트웨어는 진행의 주요 척도입니다

TDD (테스트 중심 개발)를 수행하지 않고도 민첩 할 수 있습니까?

짧은 대답 : 그렇습니다.

더 긴 답변 :이 질문에 이미 많은 좋은 답변과 아주 좋은 참고 자료가 있습니다. 나는 그 점에 대해 토론하려고하지 않을 것이다.

내 경험상 애자일은 프로젝트에 적합한 수준의 린을 선택하는 것에 관한 것입니다. Lean-ness는 무엇을 의미합니까? 그리고이 답변에 왜 그것을 가져 옵니까?

린이 방법에서 가능한 모든 것을 자르는 것을 의미하지는 않습니다. 동료 중 한 사람이 언급했듯이 TDD 또는 단위 테스트를 행동에 포함시킬 필요는 없습니다. 그러나 프로젝트 환경에서 자신을 발견하면 도움이 될 수도 있고 그렇지 않을 수도 있습니다.

AK에 위치한 이름없는 대형 소매 업체의 공급망에 대해 생각해 봅시다. 소비자가 있습니다. 그들은 가게에 들어갑니다. 상점은 트럭을 통해 다양한 제품을받습니다. 아마도 트럭은 창고에서 해당 제품을 가져옵니다. 창고는 다양한 제조업체의 선적으로 채워집니다. 제조업체는 공급망 전체를 보유하고 있습니다.

위의 공급망에서 운송 담당 총괄 관리자에게 트럭에 10 대 미만의 트럭이 있다고 매년 연간 백만 달러의 보너스를받을 것이라고 말하면 어떻게됩니까? 그는 함대를 9 대의 트럭으로 즉시자를 것입니다. 이 "무시한"시나리오에서는 창고에 저장되어있는 상품의 양이 증가합니다 (해당 노드의 비용 절감). 그리고 그것은 상점 정면을 "고갈"할 것이다.

따라서 전체 공급망을 고려하지 않고 로컬 최적화를 허용하면 전체 공급망에 문제가 발생합니다.

TDD 및 UT로 돌아 가기 TDD는 요구 사항 표현 메커니즘입니다. 시스템은 이러한 제약 조건을 따라야합니다. 그럴 수 있지. TDD는 유스 케이스 드라이브 개발 요구 사항 동작 또는 사용자 스토리 기반 개발 요구 사항 동작을 대체 할 수 있습니다. 단위 테스트 및 요구 사항 작업 부하를 결합하면 "기울이는"이점이 있습니다. 전체 작업 부하가 줄어드는 것이 좋습니다. 전체 공급망의 작업 부하가 증가하더라도 (수정 품질을 보자) 아닙니다.

TDD (테스트 중심 개발)를 수행하지 않고도 민첩 할 수 있습니까?

물론 넌 할 수있어. 다른, 아마도 더 나은 질문은 :-이 프로젝트에 TDD를 적용하면, 소프트웨어의 전체적인보다 효율적인 전달 또는 덜 효율적인 결과를 가져올 수 있습니까?

좋아하는 작가를 인용하려면 ... JRR Tolkien

반지의 제왕. 반지의 친교. 프로도는 이렇게 대답했다. '그들은 엘프에게 조언을 구하지 마십시오. 그들은 거절 할 것입니다.'

결국, 그것은 ...에 달려 있습니다. 질문에 대답해야합니다. 원하는 경로로 가장 효율적으로가는 경로는 무엇입니까?

TDD로 또는 TDD로 그것은 여전히 ​​질문입니다. :-)

추신-나는이 답변을 다른 사이트에도 다시 게시하고 있습니다. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

성을 설계하는 것과 비교.

애자일 캐슬

애자일을 사용하여 성을 설계하는 경우. 특정 기능을 가진 부분을 작성하고 사용자가 기능 부분을 사용하도록 장려하여 사용자의 반응에 따라 향후 디자인을 조정합니다. 따라서 던전을 만들고 던전지기와 통신하면 땅과 던전이 제공하는 기초를 테스트하게됩니다. 난간을 만들고 나이트 워치 맨에게 좋은지 물어보십시오. 당신은 벽을 쌓고 군인들에게 방어적인 가치를 시험하게합니다. 당신은 부엌을 짓고 요리사가 그것을 보도록 할 것입니다. 그리고이 과정에서 현재 구조와 더불어 현재까지의 모든 부분이 작동합니다. 던전을 마치면 죄수들을 안으로 데려 갈 수 있습니다. 그러나 마침내 성을 완성하면 죄수들이 탈출 한 것을 알게됩니다.

TDD 캐슬

TDD를 사용하면 죄수들과 함께 나타나 탈출 할 수 있습니다. 그런 다음 탈출 할 수 없을 때까지 감옥을 씁니다. 그런 다음 코드를 리팩터링하여 불필요한 셀을 깨끗하게 제거하고 잘못된 위치에있는 막대를 제거하고 다시 테스트합니다. 죄수들은 탈출하지 않았다. 간수와 대화 할 필요가 없습니다. 그리고 모든 것을 마치면 성 전체를 전달할 수 있습니다. 그 시점에서 간수는 지하 감옥에 더 많은 세포가 필요하다고 말하면서 이제 더 많은 기초를 파헤쳐 야합니다.

애자일 TDD 캐슬

Agile과 TDD를 결합한 경우 죄수들이 도망 쳤다면 간수에게 무엇이 필요한지 물어보십시오. 그는 더 많은 세포가 필요하다고 말합니다. 당신은 죄수 인 척하고 어떤 사람들이 탈출했는지 확인하기 위해 임의의 사람들을 잡을 것입니다. 그렇지 않다면 간수에게 보여 주면 기뻐합니다. 그런 다음 난간을 만들기 시작합니다.

결론

따라서 둘 다 다른 문제를 해결합니다. 애자일은 사용자가 적응하기 가장 쉬운 프로세스 시점에서 제품이 개발되는 것을 볼 때 사용자 요구를 발견하여 요구 사항을 변경하는 데 도움을줍니다. 전체 설계에서 세분화 된 안정적인 추가를 릴리스합니다.

TDD는 실패 예상 문제를 해결합니다. 해결하기 가장 쉬운 과정에서 발생하는 오류 발견 및 수정. 전체 설계에서 분리 된 안정적인 분리 된 코드 단위를 테스트해야합니다.

TDD는 Agile의 확장으로 쉽게 볼 수 있습니다. 둘 다 동일한 패턴, 단위 중심 진행 및 검토를 따르기 때문입니다. 차이점은 민첩한 단위는 전체적으로 외부 적으로 기능하는 반면 TDD의 단위는 부분적으로 기능하며 외부 검토를 위해 작동하는 제품을 생산하지 않을 수 있다는 것입니다. 그리고 두 프로세스 모두 서로 다른 요구 사항 (사용성 대 정확성)을 관리합니다. 두 가지 모두 단위로 개발하는 프로세스에 대해 작동하기 때문에 두 검토 프로세스는 비슷한 시점에서 발생할 수 있으며 TDD는 더 세분화됩니다.

노트

• 단위 테스트만으로 TDD를 사용하는 것은 아닙니다. TDD는 생산 된 장치보다 먼저 테스트를하고 개발시 테스트를 통해 장치를 확인하는 것을 의미합니다. TDD가없는 단위 테스트를 사용하여 이전에 빌드 한 기능을 무효화하지 않도록 할 수 있습니다.
• 스프린트와 다른 회의를한다고해서 민첩 해지지는 않습니다. 매니페스트의 목표는 민첩하게 만듭니다. 프로세스보다 사람들을 선호하려는 노력을 기울이지 않고도 작업 단위로 폭포수 목표를 스프린트로 나눌 수 있습니다.
• TDD 및 Agile의 정의 단위 테스트는 전달할 수없는 단위를 제어하므로 TDD는 Agile보다 빠르게 순환합니다. 두 가지를 모두 사용하는 경우 애자일주기에는 하나 이상의 TDD주기가 포함됩니다 (모든 단위를 테스트 한 경우).
• 내가 이해 한 것 : 사용자에게 전달 가능하고 의미있는 단위를 개발하지 않으면 애자일이 실패합니다. 이 제품은 제품 속도를 높이더라도 의미가 있습니다. 그러나 애자일은 유지 보수를 쉽게하기 위해 리팩토링을 어떻게 설명합니까? 나는 그것에 대답하기에 충분하지 않았다.
• 단위 테스트에 실패하여 TDD에 실패했습니다. 기능을 올바르게 생성하지 않는 코드 생성

애자일은 매번 반복 할 때마다 일정 및 품질 위험을 해결하고 완화시킵니다. 즉, TDD는 민첩한 것으로 간주 될 필요가 없습니다 .

그러나 TDD는 품질 위험을 완화하는 데있어 특히 반복 작업이 많거나 사람이 많은 프로젝트의 경우 엄청난 기술입니다. 이러한 프로젝트에서 TDD는 테스트 케이스도 작성해야하기 때문에 초기 반복에서 스케줄 위험을 추가합니다. 그러나 TDD는 품질 위험을 지속적으로 완화하기 때문에 이후 반복에서 막대한 비용 절감 효과를 제공합니다. 즉 TDD가 권장됩니다.