애자일 피드백

애자일 프로젝트에서 우리는 작고 많은 변경을 지속적으로 조정하기 위해 피드백을 항상 추구합니다.

지속적인 모니터링은 코드 베이스의 품질이 떨어지지 않았으며 나아지진 않았지만 적어도 코드 베이스가 어제 작동한 것처럼 돌아간다는 사실을 확인시켜주는 피드백입니다.

그 외의 피드백을 얻을 수 있는 부분에 대해 아래에서 살펴보도록 하겠습니다.

 

- 단위테스트

 

애자일은 변화를 관리하는 것이고 아마 가장 많이 변하는 것은 코드일 것입니다.

코드 변화에 대처하려면, 코드의 건강함에 대해 지속적인 피드백이 필요하고 이는 곧 자동화된 단위테스트가 필요하다는 말과 같습니다.

 

• 코딩 피드백

 

애자일 형식의 단위테스트에서는 스텁 코드를 치워버리지 않고 보존해서 계속해 스텁 코드를 자동적으로 실행합니다.

(스텁 코드: 디버깅을 위해 구현한 작은 코드)

일단 단위테스트 몇 개가 있다면, 이것들을 자동화해서 컴파일이나 빌드를 할 때마다 코드에서 단위테스트를 실행하게끔 합니다.

이후 백그라운드에 빌드 머신을 준비해서 소스코드의 최신 버전을 끊임없이 가져다가 컴파일하고, 단위테스트를 실행해서 실패하면 즉시

알 수 있도록 설정합니다.

 

단위테스트가 자리를 잡으면 회귀 테스트처럼 작동하기 때문에 코드 베이스를 쉽게 리팩토링할 수 있습니다.

즉 단위테스트는 무언가 뜻하지 않게 망가뜨리는 실수를 막아줍니다.

저도 팀에서 lint 적용 혹은 js 에서 ts 로의 전환 작업 등을 하며 상당히 많은 라인의 코드 변경을 수행한 적이 있습니다.

작업 후 pr 을 올릴때 이게 production 에서 잘 동작할까 와 같은 생각이 있었지만, 자동화된 단위테스트가 있었기에 좀 더 자신감을 가질 수 있었고 별 이상없이 작업을 마칠 수 있었습니다.

 

단위테스트를 해야 하는 추가적인 이유가 아래처럼 몇 있습니다.

 

• 단위테스트로 즉각 피드백을 받는다

• 단위테스트는 코드를 강건하게 한다

• 단위테스트는 유용한 디자인 툴이 될 수 있다 (실용적이고 더 간단한 설계를 얻도록 해준다)

• 단위테스트는 자신감을 증진시킨다

• 단위테스트는 프로브 역할을 할 수 있다 (문제가 발생하면 코드의 내부 작동 상태를 빨리 보여준다)

• 단위테스트는 믿을만한 문서다

• 단위테스트는 학습 도우미다 (새로운 API 를 빨리 배우기 위해 테스트를 작성하는 데서 시작할 수 있다)

 

- 만들기 전에 사용하라

 

• 코드를 작성하기 전에 테스트를 작성하라

 

테스트 주도 개발(TDD) 로 알려진 기술을 사용한다면 작성하려는 코드에 실패하는 단위테스트를 만든 다음에만 실제 코드를 작성합니다.

테스트를 먼저 작성하면, 구현하는 사람의 관점이 아닌 사용자 관점에서 코드를 자세히 살펴볼 수 있습니다.

사용자 관점에서 코드를 자세히 살피면 스스로 코드를 사용해야 하기 때문에 훨씬 더 유용하고, 일관된 인터페이스를 설계할 수 있습니다.

 

- 차이는 다른 결과를 만든다

 

여기서의 차이는 테스트를 하더라도 플랫폼, 운영체제, 기기와 같은 환경에 따라 다른 결과가 나올 수 있다는 점을 의미합니다.

코드를 수정하거나 리팩토링할 때마다 코드를 체크인 하기 전에 테스트 케이스를 시험해야 하고, 그 테스트는 지원하는 플랫폼이나 환경마다 되어야 할 것입니다.

 

• 시간을 줄이기 위해 자동화하자

 

다수의 플랫폼에서 테스트를 돌릴 시간은, 지속적 통합으로 마련할 수 있습니다.

다수의 플랫폼에서 테스트하기 위해 각 플랫폼에 지속적 통합 시스템을 간단히 설정해 테스트를 자동으로 실행할 수 있습니다.

코드를 체크인한 뒤 몇 분 안에 어떤 플랫폼에서 실패 메세지를 받을 수 있다면, 지속적 통합 시스템을 통해 현명하게 자원을 사용할 수 있다고 볼 수 있습니다.

 

- 인수 테스트를 자동화하라

 

보통의 단위테스트와 인수 테스트는 다릅니다.

핵심 비즈니스 로직에 해당하는 테스트를 만들어 고객이 격리 상태에서 검증하게 하고, 일반적인 테스트 수행의 일부로 이러한 테스트를 자동적으로 시험하게 해야 합니다.

 

- 실제 진척 상황을 측정하라

 

시간의 흐름은 훌륭한 피드백을 제공합니다.

하지만 단순 근무시간 기록표 등을 사용해 작업 기간에 대한 피드백을 얻을 순 없습니다.

 

• 가려는 곳에 집중하라

 

예측한 작업을 끝냈을 때, 이 작업이 진짜로 얼마나 오래 걸렸는지 기록하고 이를 반복합니다.

한동안은 작업량을 과소평가하거나 과대평가하는 식으로 우왕좌왕하겠지만, 시간이 지나면서 예측은 점점 정확해지고 앞으로 해야 할 작업에 대해 명확한 일정을 알게 될 것입니다.

 

프로젝트의 진척 상황을 측정하는 방법도 유용합니다. 이 진척 상황을 잘 보이게 유지하는 가장 좋은 방법은 백로그를 사용하는 것입니다.

백로그는 단순 완료해야 하는 작업 목록일 뿐인데, 작업들에는 우선순위가 있으므로 이를 사용해 다음에 해야 할 가장 중요한 작업에 대한 파악이 가능해집니다. 시간이 흐르고 예측 기술이 향상되면서 작업이 얼마나 걸릴지 더 나은 아이디어도 얻을 수 있습니다.

 

최근에 제가 속한 팀에서는 Jira 라는 프로젝트 관리 툴을 도입하면서 스프린트와 백로그를 적절히 활용하고 있습니다.

백로그의 우선순위를 통해 다음에 먼저 해야 할 작업에 대한 빠른 파악이 가능하고, 업무에 대한 최초 예상치와 종료 후 걸린 시간 비교를 통해 이후의 업무 진행에 대한 피드백을 얻고 있습니다. 이런 툴의 도움을 받는 것도 꽤 유용하다고 생각합니다.

 

 

출처 : 애자일 프랙티스(책)