2018.04.20

"BDD부터 TDD까지" 다양한 애자일 기법의 장단점

Keith Skronek | InfoWorld
외부에서 보면 애자일은 한 가지 방식으로 보인다. 그러나 안으로 들어와서 보면 애자일 실천가들은 각자 다양한 방식에 전념해 작업을 한다. 어떻게 하면 나와 내 팀에 잘 맞는 기법을 찾을 수 있을까?

걱정할 필요 없다. 실용적 애자일리스트(Pragmatic Agilist)가 여러분을 위해 다양한 애자일 프레임워크와 기법의 장단점을 비교해봤다.

Image Credit : GettyImagesBank

행동 중심 개발(BDD, Behavior-driven development)

정의 : BDD는 팀원들이 시스템의 예상된 행동을 논의해서 예상되는 기능에 관한 공통된 이해를 구축하는 방식이다. 테스트 중심 개발(TDD)과 수락 테스트 중심 개발(ATDD)에 기인한 방식을 합치고 다듬는 방법이다.

효과적인 이유 : BDD는 가능한 가장 작은 단위가 아니라 특정 기능을 제공하는 데 초점을 둔다. 비즈니스에서 요구하는 가치를 제공한다는 측면에서 중요하다.

효과를 거두지 못하는 경우 : 기능을 측정하지만 그 기반이 되는 작업의 품질을 놓칠 수 있다. 테스트 중심 개발을 병행하지 않는 한, 결과가 좋다 해도 나중에 유지 또는 확장하기 어려운 코드를 사용해 잘못된 방식으로 그 결과를 쌓아 올릴 위험성이 상존한다. 또한 BDD를 지원하는 소프트웨어 툴은 비교적 적다.

분산 애자일(Distributed agile)
정의 : 분산 애자일은 다양한 위치, 조직, 시간대의 애자일 팀원을 사용하는 것을 의미한다. 분산 애자일 팀은 직접 대면하는 회의 대신 인스턴트 메시징, 이메일, 화상 회의 및 기타 툴을 사용해서 일상적인 작업을 조율한다.

효과적인 이유 : 분산 애자일은 현재 처한 장소의 공간, 기술, 경험의 제약을 벗어날 수 있게 해준다. 슬랙, 스카이프, 팀스, 행아웃 같은 현대적인 협업 툴 덕분에 가능해진 방법이다. 같은 장소에 있지 않더라도 함께 스토리 작업을 할 수 있고, 동료의 흐름을 방해하지 않고도 질문을 할 수 있다.

신뢰, 관계, 소통은 여전히 필수적이다. 그래서 분산 애자일은 특정 위치에 최소 두 명의 팀원이 있고 이들이 정기적으로 대면하고 서로의 언어와 문화를 잘 이해할 때 가장 효과적이다. 가상 협업은 물론 필요에 따라 실제 대면 협업도 쉽게 할 수 있도록 팀 전체가 서로 멀지 않은, 비슷한 시간대에 위치하는 것이 좋다. 이러한 팀 결속은 까다로운 문제를 해결하거나 비즈니스 또는 사용자 피드백을 받거나 새로운 팀원이 합류할 때 큰 차이로 이어진다.

효과를 거두지 못하는 경우 : 애자일은 스탠드업 및 기타 공식적, 비공식적 협업을 통한 빠르고 빈번한 소통이 있을 때 가장 효과적이다. 전통적인 애자일리스트들이 팀원 100% 전체가 한 곳에 있을 때만 애자일이 가능하다고 믿는 이유도 여기에 있다.

필자의 경험으로 보면 한두 개의 시간대 정도에 걸친다면 충실한 협업을 달성할 수 있다. 그러나 시간대와 언어, 문화 간극이 클 경우 균열이 시작된다. 스탠드업의 요점은 팀의 소통과 진전이다. 글로벌한 상태 회의를 그럴듯하게 할 수는 있겠지만 모든 인원이 글로벌 스탠드업에 효과적으로 참여할 수 있는 시간을 선정하는 것 자체가 거의 불가능하다.

칸반(Kanban)
정의 : “칸반 방법은 지식 작업을 위한 흐름 시스템을 설계, 관리, 개선하기 위한 수단이다. 또한 조직은 칸반을 통해 기존 워크플로에서 시작해서 진화적 변화를 이끌 수 있다. 그 방법은 작업 흐름을 시각화하고, 진행 중인 작업(WIP)을 제한하고 시작하기를 멈추고 마무리에 착수하는 것이다. 칸반 방법의 이름은 무형의 작업물에 대한 진행 중인 작업을 제어하기 위한 시각적 신호 메커니즘인 칸반(Kanban)을 사용하는 데서 따왔다.”

효과적인 이유 : 칸반은 언제 작업이 들어올지 모르는 지원 티켓 관리와 같은 시나리오에 효과적이다. 특히 예를 들어 해결된 결함과 같은, 가치/생산성을 측정하는 대안 방법이 있는 경우 유용하다. 또한 칸반은 일일 스탠드업, 데모, 레트로스펙티브와 같은 “오버헤드” 활동에 시간을 덜 소비할 수 있게 해준다.

효과를 거두지 못하는 경우 : 칸반은 애자일을 새로 접하는 팀에는 어려울 수 있다. 다른 방법론과 달리 프로세스가 명확하게 정의되어 있지 않기 때문이다. 데모가 없으므로 팀은 제대로 된 결과물을 제공하고 있는지에 관해 비즈니스로부터 피드백을 받을 수 없다. 또한 스프린트 레트로스펙티브가 없으므로 프로세스를 개선하기가 어려울 수 있다. 좋지 않은 프로세스에 무기한으로 빠지기 쉽다.

페어 프로그래밍(Pair programming)
정의 : 페어 프로그래밍은 두 프로그래머가 하나의 워크스테이션을 공유한다(두 명이 하나의 화면, 키보드, 마우스 사용). 키보드를 사용하는 프로그래머를 드라이버, 프로그래밍에 적극적으로 관여하지만 전체적인 진행 방향에 더 초점을 두는 다른 한 명을 내비게이터라고 한다. 두 프로그래머는 몇 분마다 한 번씩 역할을 교대한다.

효과적인 이유 : 페어 프로그래밍은 복잡한 작업을 진행하기 위해 고안된 방법이다. 신규 개발자를 온보딩할 때 지식을 전달하는 수단으로도 좋다. 페어 프로그래밍을 사용하면 전체적인 품질이 개선된다.

효과를 거두지 못하는 경우 : 페어 프로그래밍은 예를 들어 패턴이 이미 확립된 경우, 또는 값 객체를 만드는 등의 일상적인 작업에는 과도한 방법일 수 있다. 이러한 작업에 두 명의 프로그래머가 달라붙는 것은 비즈니스 비용을 사용하는 방법 측면에서 최선은 아니다. 또한 개발자에 따라서는 단독으로 작업할 때 훨씬 더 만족스럽게, 생산적으로 일하기도 한다. 그런 사람은 혼자 두는 것이 좋다. 필자는 페어 프로그래밍이 효과적일 때와 그렇지 않을 때에 대해 팀에 어느 정도의 자율성을 제공한다는 전제 하에 페어 프로그래밍을 지지한다.

스크럼(Scrum)
정의 : 스크럼은 제품 개발 및 기타 지식 작업을 관리하는 데 사용되는 프로세스 프레임워크다. 스크럼은 어떤 것의 작동 원리에 대한 가설을 세우고 그 가설을 실험하고 경험을 돌아보고 적절한 조정을 하기 위한 수단을 제공한다는 측면에서 실증적이다.

효과적인 이유 : 스크럼은 명확한 프로세스 정의다. 즉, 팀원들은 자신이 무엇을 해야 할지를 정확히 안다. 경로를 이탈하지 않으면서 지속적으로 가치를 제공하는지 확인하기 위한 체크포인트가 많다. 전체적으로 스크럼은 제품 개발을 위한 뛰어난 방법론이다.

효과를 거두지 못하는 경우 : 스크럼은 팀이 어떤 일을 하는 이유를 온전히 이해하지 못한 채 프로세스(“하고 있는 일”)만 아는 경우 제대로 되지 않는다. 예를 들어 일일 스탠드업은 프로젝트 진전을 위해 투명성을 제공하고 장애물을 발견하기 위한 빠른 모임이 되어야 한다. 그러나 좋지 않은 스탠드업은 40분 길이의 현황 보고 자리로 변질될 수 있다. 비즈니스 담당자를 만족시킬 수야 있겠지만 작업을 진척시키지는 못한다. 마찬가지로, 솔직한 반추 없는 레트로스펙티브는 미래 스프린트를 개선하기 위한 기회가 아니라 그냥 서로 “격려하는” 세션으로 변질될 수 있다.

테스트 중심 개발(TDD, Test-driven development)
정의 : 테스트 중심 개발은 코딩, 테스트(단위 테스트 형식), 설계(리팩터링 형식)의 세 가지 활동이 밀접하게 연계되는 프로그래밍 스타일이다.

효과적인 이유 : TDD는 더 고품질의 프로그래밍을 실현한다. TDD를 사용하면 테스트를 충족하기에 충분한 코드만 작성하게 된다. 그 결과 테스트를 거쳤을 뿐만 아니라 확장성과 유지보수 편의성도 높은, 더 모듈성이 강하고 군더더기 없는 코드가 생산된다. TDD는 또한 총소유비용(TCO) 절감으로도 이어진다. 결함의 수가 더 적다. 결함 수정 비용이 덜 드는 사이클의 조기에 결함을 포착할 수 있다.

효과를 거두지 못하는 경우 : TDD는 숙련되기까지 4~6개월이 소요된다. 이 램프업 기간 동안 TDD는 팀의 속도를 떨어트린다. 또한 선행 투자도 더 많이 필요하다. 그러나 장기적인 비용이 절감되므로 이 비용은 결국 상쇄된다.

지금까지 가장 일반적으로 사용되는 몇 가지 애자일 방식을 알아봤다. 그러나 이 목록에 소개한 방법은 일부일 뿐이다. 중요한 점은 애자일은 딱딱한 규칙 또는 규정집이 아니란 것이다. 애자일은 유연하고 반복적인 소프트웨어 개발 접근 방법으로, 특히 제품 중심 사고방식(Product Mindset)을 추구하는 기업에 잘 맞으며 민첩성, 출시 속도, 고객 경험을 강조한다. 다양한 조직이 다양한 방법으로 그 목적지에 도달한다. 각자 가장 잘 맞는 애자일 변형을 찾으면 애자일의 혜택을 얻을 수 있다.  editor@itworld.co.kr


2018.04.20

"BDD부터 TDD까지" 다양한 애자일 기법의 장단점

Keith Skronek | InfoWorld
외부에서 보면 애자일은 한 가지 방식으로 보인다. 그러나 안으로 들어와서 보면 애자일 실천가들은 각자 다양한 방식에 전념해 작업을 한다. 어떻게 하면 나와 내 팀에 잘 맞는 기법을 찾을 수 있을까?

걱정할 필요 없다. 실용적 애자일리스트(Pragmatic Agilist)가 여러분을 위해 다양한 애자일 프레임워크와 기법의 장단점을 비교해봤다.

Image Credit : GettyImagesBank

행동 중심 개발(BDD, Behavior-driven development)

정의 : BDD는 팀원들이 시스템의 예상된 행동을 논의해서 예상되는 기능에 관한 공통된 이해를 구축하는 방식이다. 테스트 중심 개발(TDD)과 수락 테스트 중심 개발(ATDD)에 기인한 방식을 합치고 다듬는 방법이다.

효과적인 이유 : BDD는 가능한 가장 작은 단위가 아니라 특정 기능을 제공하는 데 초점을 둔다. 비즈니스에서 요구하는 가치를 제공한다는 측면에서 중요하다.

효과를 거두지 못하는 경우 : 기능을 측정하지만 그 기반이 되는 작업의 품질을 놓칠 수 있다. 테스트 중심 개발을 병행하지 않는 한, 결과가 좋다 해도 나중에 유지 또는 확장하기 어려운 코드를 사용해 잘못된 방식으로 그 결과를 쌓아 올릴 위험성이 상존한다. 또한 BDD를 지원하는 소프트웨어 툴은 비교적 적다.

분산 애자일(Distributed agile)
정의 : 분산 애자일은 다양한 위치, 조직, 시간대의 애자일 팀원을 사용하는 것을 의미한다. 분산 애자일 팀은 직접 대면하는 회의 대신 인스턴트 메시징, 이메일, 화상 회의 및 기타 툴을 사용해서 일상적인 작업을 조율한다.

효과적인 이유 : 분산 애자일은 현재 처한 장소의 공간, 기술, 경험의 제약을 벗어날 수 있게 해준다. 슬랙, 스카이프, 팀스, 행아웃 같은 현대적인 협업 툴 덕분에 가능해진 방법이다. 같은 장소에 있지 않더라도 함께 스토리 작업을 할 수 있고, 동료의 흐름을 방해하지 않고도 질문을 할 수 있다.

신뢰, 관계, 소통은 여전히 필수적이다. 그래서 분산 애자일은 특정 위치에 최소 두 명의 팀원이 있고 이들이 정기적으로 대면하고 서로의 언어와 문화를 잘 이해할 때 가장 효과적이다. 가상 협업은 물론 필요에 따라 실제 대면 협업도 쉽게 할 수 있도록 팀 전체가 서로 멀지 않은, 비슷한 시간대에 위치하는 것이 좋다. 이러한 팀 결속은 까다로운 문제를 해결하거나 비즈니스 또는 사용자 피드백을 받거나 새로운 팀원이 합류할 때 큰 차이로 이어진다.

효과를 거두지 못하는 경우 : 애자일은 스탠드업 및 기타 공식적, 비공식적 협업을 통한 빠르고 빈번한 소통이 있을 때 가장 효과적이다. 전통적인 애자일리스트들이 팀원 100% 전체가 한 곳에 있을 때만 애자일이 가능하다고 믿는 이유도 여기에 있다.

필자의 경험으로 보면 한두 개의 시간대 정도에 걸친다면 충실한 협업을 달성할 수 있다. 그러나 시간대와 언어, 문화 간극이 클 경우 균열이 시작된다. 스탠드업의 요점은 팀의 소통과 진전이다. 글로벌한 상태 회의를 그럴듯하게 할 수는 있겠지만 모든 인원이 글로벌 스탠드업에 효과적으로 참여할 수 있는 시간을 선정하는 것 자체가 거의 불가능하다.

칸반(Kanban)
정의 : “칸반 방법은 지식 작업을 위한 흐름 시스템을 설계, 관리, 개선하기 위한 수단이다. 또한 조직은 칸반을 통해 기존 워크플로에서 시작해서 진화적 변화를 이끌 수 있다. 그 방법은 작업 흐름을 시각화하고, 진행 중인 작업(WIP)을 제한하고 시작하기를 멈추고 마무리에 착수하는 것이다. 칸반 방법의 이름은 무형의 작업물에 대한 진행 중인 작업을 제어하기 위한 시각적 신호 메커니즘인 칸반(Kanban)을 사용하는 데서 따왔다.”

효과적인 이유 : 칸반은 언제 작업이 들어올지 모르는 지원 티켓 관리와 같은 시나리오에 효과적이다. 특히 예를 들어 해결된 결함과 같은, 가치/생산성을 측정하는 대안 방법이 있는 경우 유용하다. 또한 칸반은 일일 스탠드업, 데모, 레트로스펙티브와 같은 “오버헤드” 활동에 시간을 덜 소비할 수 있게 해준다.

효과를 거두지 못하는 경우 : 칸반은 애자일을 새로 접하는 팀에는 어려울 수 있다. 다른 방법론과 달리 프로세스가 명확하게 정의되어 있지 않기 때문이다. 데모가 없으므로 팀은 제대로 된 결과물을 제공하고 있는지에 관해 비즈니스로부터 피드백을 받을 수 없다. 또한 스프린트 레트로스펙티브가 없으므로 프로세스를 개선하기가 어려울 수 있다. 좋지 않은 프로세스에 무기한으로 빠지기 쉽다.

페어 프로그래밍(Pair programming)
정의 : 페어 프로그래밍은 두 프로그래머가 하나의 워크스테이션을 공유한다(두 명이 하나의 화면, 키보드, 마우스 사용). 키보드를 사용하는 프로그래머를 드라이버, 프로그래밍에 적극적으로 관여하지만 전체적인 진행 방향에 더 초점을 두는 다른 한 명을 내비게이터라고 한다. 두 프로그래머는 몇 분마다 한 번씩 역할을 교대한다.

효과적인 이유 : 페어 프로그래밍은 복잡한 작업을 진행하기 위해 고안된 방법이다. 신규 개발자를 온보딩할 때 지식을 전달하는 수단으로도 좋다. 페어 프로그래밍을 사용하면 전체적인 품질이 개선된다.

효과를 거두지 못하는 경우 : 페어 프로그래밍은 예를 들어 패턴이 이미 확립된 경우, 또는 값 객체를 만드는 등의 일상적인 작업에는 과도한 방법일 수 있다. 이러한 작업에 두 명의 프로그래머가 달라붙는 것은 비즈니스 비용을 사용하는 방법 측면에서 최선은 아니다. 또한 개발자에 따라서는 단독으로 작업할 때 훨씬 더 만족스럽게, 생산적으로 일하기도 한다. 그런 사람은 혼자 두는 것이 좋다. 필자는 페어 프로그래밍이 효과적일 때와 그렇지 않을 때에 대해 팀에 어느 정도의 자율성을 제공한다는 전제 하에 페어 프로그래밍을 지지한다.

스크럼(Scrum)
정의 : 스크럼은 제품 개발 및 기타 지식 작업을 관리하는 데 사용되는 프로세스 프레임워크다. 스크럼은 어떤 것의 작동 원리에 대한 가설을 세우고 그 가설을 실험하고 경험을 돌아보고 적절한 조정을 하기 위한 수단을 제공한다는 측면에서 실증적이다.

효과적인 이유 : 스크럼은 명확한 프로세스 정의다. 즉, 팀원들은 자신이 무엇을 해야 할지를 정확히 안다. 경로를 이탈하지 않으면서 지속적으로 가치를 제공하는지 확인하기 위한 체크포인트가 많다. 전체적으로 스크럼은 제품 개발을 위한 뛰어난 방법론이다.

효과를 거두지 못하는 경우 : 스크럼은 팀이 어떤 일을 하는 이유를 온전히 이해하지 못한 채 프로세스(“하고 있는 일”)만 아는 경우 제대로 되지 않는다. 예를 들어 일일 스탠드업은 프로젝트 진전을 위해 투명성을 제공하고 장애물을 발견하기 위한 빠른 모임이 되어야 한다. 그러나 좋지 않은 스탠드업은 40분 길이의 현황 보고 자리로 변질될 수 있다. 비즈니스 담당자를 만족시킬 수야 있겠지만 작업을 진척시키지는 못한다. 마찬가지로, 솔직한 반추 없는 레트로스펙티브는 미래 스프린트를 개선하기 위한 기회가 아니라 그냥 서로 “격려하는” 세션으로 변질될 수 있다.

테스트 중심 개발(TDD, Test-driven development)
정의 : 테스트 중심 개발은 코딩, 테스트(단위 테스트 형식), 설계(리팩터링 형식)의 세 가지 활동이 밀접하게 연계되는 프로그래밍 스타일이다.

효과적인 이유 : TDD는 더 고품질의 프로그래밍을 실현한다. TDD를 사용하면 테스트를 충족하기에 충분한 코드만 작성하게 된다. 그 결과 테스트를 거쳤을 뿐만 아니라 확장성과 유지보수 편의성도 높은, 더 모듈성이 강하고 군더더기 없는 코드가 생산된다. TDD는 또한 총소유비용(TCO) 절감으로도 이어진다. 결함의 수가 더 적다. 결함 수정 비용이 덜 드는 사이클의 조기에 결함을 포착할 수 있다.

효과를 거두지 못하는 경우 : TDD는 숙련되기까지 4~6개월이 소요된다. 이 램프업 기간 동안 TDD는 팀의 속도를 떨어트린다. 또한 선행 투자도 더 많이 필요하다. 그러나 장기적인 비용이 절감되므로 이 비용은 결국 상쇄된다.

지금까지 가장 일반적으로 사용되는 몇 가지 애자일 방식을 알아봤다. 그러나 이 목록에 소개한 방법은 일부일 뿐이다. 중요한 점은 애자일은 딱딱한 규칙 또는 규정집이 아니란 것이다. 애자일은 유연하고 반복적인 소프트웨어 개발 접근 방법으로, 특히 제품 중심 사고방식(Product Mindset)을 추구하는 기업에 잘 맞으며 민첩성, 출시 속도, 고객 경험을 강조한다. 다양한 조직이 다양한 방법으로 그 목적지에 도달한다. 각자 가장 잘 맞는 애자일 변형을 찾으면 애자일의 혜택을 얻을 수 있다.  editor@itworld.co.kr


X