단위 테스트없이 민첩

작업중인 코드베이스에 0 % 단위 테스트 적용 범위가있는 경우 "민첩한 개발"에 대해 이야기하거나 "민첩한 방법론"을 적용한다고 주장하는 것이 합리적입니까? (그리고 팀으로서 당신은 그것에 대해 아무것도하지 않습니다).

분명히하기 위해, 나에게는 이해가되지 않습니다. 개인적 경험에 따르면 단위 테스트는 실제로 "민첩"할 수있는 유일한 도구 (예 : 변경에 응답하고 설계를 개선하며 지식을 공유하는 등)이며 TDD가 유일한 방법입니다. .

다른 방법이 있을지 모르지만 여전히 어떻게 작동하는지 알 수 없습니다.

애자일 선언문이나 스크럼 안내서에있는 내용 중 하나라도 단위 테스트 나 TDD와 같은 기술 관행을 전혀 언급하지 않습니다. 따라서 이론적으로는 협업 없이도 협업과 가치에 중점을두고 조기에 제공하고 애자일이라고 부르면 실제로 민첩성을 가질 수 있습니다 .

그러나 실제로 는 테스트 스위트없이 몇 주마다 지속적으로 가치를 ( 생산으로 ) 제공하는 것은 거의 불가능합니다 . 여기에는 통합 테스트와 단위 테스트가 포함됩니다. 단위 테스트는 지금까지만 진행되었습니다. 피라미드가 아니며 직사각형이 아닌 이유가 있습니다.

안전망으로 테스트하지 않으면 각 릴리스에 많은 회귀 버그가 발생하거나 리팩토링이 무서워집니다. 두 가지 모두 지속 가능한 속도 로 계속 발전하는 데 큰 영향을 미칩니다 . 필요한 경우 페이스를 유지하거나 코스를 변경 (재 설계) 할 수 없다면 민첩성이 없습니다. 결국 민첩성은 우리가 추구하는 목표입니다.

민첩한 선언문은 단순히 다음과 같이 말합니다.

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

포괄적 인 문서에 대한 작업 소프트웨어

계약 협상을 통한 고객 협업

계획에 따라 변경 에 응답

거기에 단위 테스트에 대한 언급이 없습니다. 12 가지 원칙 조차 테스트를 언급하지 않습니다.

따라서 기술적으로 단위 테스트를 작성하지 않고도 민첩한 팀이 될 수 있습니다. 그러나 실제로 팀이 지속적으로 변경하는 데 도움이되는 테스트없이 민첩한 환경에서 작동하는 소프트웨어를 어떻게 유지 관리 할 수 ​​있는지 알기가 매우 어렵습니다.

다른 사람들이 여기에서 대답 한 것처럼 애자일 매니페스트에 단위 테스트 또는 TDD 또는 모든 종류의 테스트에 대한 직접적인 단어는 없지만 훌륭한 스크럼 마스터 또는 개발자는 매니페스트의 진술 중 하나를 식별 할 수 있다고 생각합니다.

 포괄적 인 문서에 대한 작업 소프트웨어 .

소프트웨어가 작동하는지 어떻게 알 수 있습니까? 선언문은 테스트라는 용어를 명시 적으로 언급 할 필요는 없습니다. 간결합니다.

단위 테스트 (주제와 관련하여)는 초기 단계에서 코딩 단계가 느리게 진행되지만 진행함에 따라 가치가 높아져 개발 속도가 훨씬 빨라집니다. 코드 수준 테스트에 대한 세밀한 제어를 제공하고 설계를 확장 가능하게하여 소프트웨어가 작동하고 회귀를 쉽게 처리 할 수 ​​있다는 확신을줍니다. 개발을 민첩하게 만들 수 있습니다.

절대적으로 의미가 있습니다. 애자일은 다른 사람들이 이미 언급했듯이 테스트에 관한 것이 아니라 귀하의 질문에 구체적으로 답변합니다.

아니요, 단위 테스트가 전혀 필요하지 않습니다.

통합 테스트만으로 민첩한 프로세스를 실행할 수 있습니다. 예를 들어 매일 밤 자동 통합 테스트를 실행하고 다음 날 발견되는 버그를 수정할 수 있습니다. 원하는 경우 지속적으로 통합 테스트를 실행하는 수동 테스터를 가질 수 있습니다. 시스템에 관계없이 단위 테스트는 전적으로 선택 사항입니다.

단위 테스트는 개발에 도움이되고 공정에 충분히 공평하지만 개발에 도움이되는 많은 것들이 있습니다.

비록 오래된 '고객 베타 테스터'라하더라도 어떤 형태의 테스트가 필요합니다. 고객이 프로세스에 크게 관여하고 버그를 찾는 것이 마음에 들지 않는다면 다른 사람들도 버그라고 생각하지 않는 버그를 찾는 경향이 있기 때문에 이것이 효과가 있습니다!

필요하지 않습니다. 테스트 사용법을 잘 아는 사람들이있을 때 테스트가 좋습니다. 필요하지 않을 때뿐만 아니라 책임이됩니다. 나는 그것에 숙련되지 않은 많은 프로그래머가 있다고 말하고 싶습니다.

민첩하게 행동하는 것이 방법론을 따르지 않고 실제로 소프트웨어를 출시하는 방법에 관한 것임을 귀하의 질문에서 인정하게되어 기쁩니다. Agile Manifesto는 훌륭한 참고 자료이지만 결정적인 가이드는 아닙니다. 애자일은 존재하기 전에 존재했습니다. "보다 민첩한"소프트웨어를 개발하는 방법이 있지만 다양한 프로젝트에서 다른 조합을 사용할 수 있습니다.

클라이언트가 수용 할 수있는 속도로 새 소프트웨어를 배포하는 경우 민첩 할 것입니다. 또한 푸시 백이 너무 많지 않고 개발자가 변경 한 기능에 대해 불평하는 것도 포함됩니다. 한 가지만 다른 것을 깨는 것만으로는 이상적이지 않습니다. 사용자가 업그레이드 버전이 여러 버전 인 경우 테스트 여부에 관계없이 민첩하지 않을 수 있습니다.

나는 애자일 선언문이 이것에 대해 분명히 말하고 있다고 주장하는 다른 대답들에 반대하고 싶습니다.

기술적 우수성 과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.

저는 기술 우수성에 대한 LeSS 정의를 정말 좋아 하며 단위 테스트 및 TDD가 포함됩니다. 이제 이것을 달성하기 위해 단위 테스트 또는 TDD가 필요하지 않을 수도 있지만 가장 일반적이며 권장되는 방법입니다.

조직의 민첩성은 기술 민첩성에 의해 제한됩니다

즉, 제품을 변경하는 데 시간이 오래 걸리면 팀, 조직 또는 채택한 프레임 워크를 어떻게 구성하든 관계없이 변경에 느리게 응답합니다.

제품이 다른 방식으로 변경에 저항하는 것을 방지 할 수 있다면 올바른 방향으로 가고있는 것입니다.

나는 프로그래머에게 세상을 안전하게 만들기 위해 익스트림 프로그래밍을 발명했습니다. – 켄트 벡

스크럼은 기술적 관행이 없지만 Jeff는 이에 대해 다음과 같이 말했습니다.

Extreme Programming 개발 방법을 사용하지 않은 생산성이 높은 Scrum 팀을 본 적이 없습니다. – 제프 서덜랜드

이 기사에서 인용 : http://ronjeffries.com/articles/017-02ff/gathering2017/

나는 기술적 인 관행이없는 스크럼 팀이 결국 회고를 사용함으로써 비슷한 실천을 할 것으로 기대한다. 당신도 과잉 생산적이기를 원하십니까?

민첩한 플루 언스의 모델은 두 스타 수준에서 언급 :

유용한 기술로는 지속적인 통합, 테스트 중심 개발 , 페어 프로그래밍 및 공동 소유권이 있습니다.

첫 번째 수준의 애자일 유창성 만 목표로 삼 으면 실천을 건너 뛸 수 있지만 더 크고 오래 실행되는 제품은 별 두 개 수준을 달성하려고 시도해야합니다.

따라서 일반적인 합의는 좋은 단위 테스트, 깨끗한 코드 및 리팩터링 연습 없이는 현재는 진정한 민첩성이 될 수 없다는 것입니다. 새로운 기술 관행이 등장함에 따라 향후 변경 될 수 있습니다.

Robert C. Martin, Martin Fowler 또는 Kent Beck과 같은 선언문의 서명자에게 물어 보면 어떤 대답이 될 것이라고 생각하십니까? 어쩌면 그들은 그것이 의존한다고 말하지만 일반적으로 당신이해야 할 일입니다.