2017.12.22

애자일 방법론의 가치를 극대화하는 방법

Isaac Sacolick | InfoWorld

애자일 개발 프로세스를 진행하거나 참여 중인 사람이라면, 그리고 스크럼(scrum) 방법론과 같은 애자일 모델을 선택한 사람이라면 제품 오너와 고객 니즈, 그리고 여러 팀을 결과 산출에 맞춰 조정하기 위한 기본적인 프로세스를 갖추고 있다고 할 수 있다. 각 팀이 맡고 있는 책무를 뚜렷하게 정의하고, 미팅 스트럭처를 규정하고 일정을 정했으며, 백로그를 관리하기 위한 애자일 협업 툴을 갖춘 상태다.

이 모든 구조, 프로세스, 그리고 협업의 조합이 제대로 갖춰져 있다면 그 어떤 분야의 팀도 애자일 프랙티스를 수월하게 수행할 수 있다. 사실, 애자일 방법론은 애자일 마케팅 등 다양한 비 기술적 분야에도 적용되고 있다.

그렇다면 좋은 소프트웨어를 개발하는 데 있어서 애자일 프로세스만으로 충분할까?

그렇지 않다. 애자일 프로세스 외에도 테크놀로지가 뒷받침 된 일련의 규율이 존재해야만 애자일 방법론의 가치를 극대화 할 수 있다. 애자일의 가치를 극대화 한다는 것은 이 방법론을 통해 기업에서 만족할만한 성과를 거둔다는 의미다.

오늘 이 글에서 다룰 주제는 아래와 같다.

- 애자일 협업 툴이 주요 소프트웨어 개발 라이프사이클(SDLC)을 확실히 지원하도록 하려면 어떤 기술적 문제들을 고려해야 하는가?

- 애플리케이션이 제작 준비가 되었는지, 그리고 변경 내용을 제작 및 컴퓨팅 환경에 반영하기 위한 프로세스를 갖추고 있는지 소프트웨어 개발팀에서 어떻게 확인할 수 있는가?



애자일 개발 방법론의 기술적 부채 정의 및 해결
애자일 개발에서 사용자 시나리오를 구성하기 위해서는 많은 타협과 절충안에 도달해야만 한다. 특히 사용자 시나리오를 구성 시 기능적인 측면에서 타협이 많이 논의 되는데, 스토리 포인트를 예측하기 위해 애자일 추정(agile estimation)을 사용할 경우 더욱 그러하다.

사용자 시나리오가 끝나면, 이제 개발팀에서 그 이행에 대한 기술적 결정을 내릴 시간이다. 이러한 결정을 내릴 때에는 설령 엄격한 기술적 기준이 존재한다 하여도 어느 정도 이행 상의 타협이 불가피하다. 그리고 이러한 타협은 결국 추후 갚아야 할 기술적 부채(technical debt)로 남게 된다.

개발 과정에서는 이러한 기술적 부채가 가시적으로 드러나지 않을 지도 모른다. 이러한 기술적 부채는 이행 단계에서 사용자 행위가 기술적 한계를 노출시킴에 따라 드러나게 된다. 혹은 퍼포먼스나 확장성으로 인해 드러날 수도 있다. 아니면 업그레이드가 필요한 기저의 소프트웨어 요소 라이프사이클이 그 원인일 수도 있다.

애자일 개발 팀에 있는 개발자에게는 이러한 기술적 부채를 기록할 중요한 의무가 있다. 문제가 심각하지 않고 작다면, 코드에 투-두(to-do) 코멘트를 달아 다음 개발자가 해결하도록 두면 된다. 그러나 리팩토링(refactoring)이 필요할 정도의 큰 문제는 백로그에 아이템화 시켜두어야 한다. (여러 개의 코드 변경이 필요하거나, 추가적인 테스팅이 요구되는 기저의 소프트웨어 아키텍처나 컴포넌트 업그레이드와 같은) 애플리케이션 라이프사이클에 따른 니즈는 에픽(epics)으로 정리해 두는 것이 최선이다.

애자일 팀은 자체적인 규칙에 따라 이러한 기술적 부채의 우선 순위를 결정하게 된다. 내가 애자일 프로그램 팀을 이끌 때는 제품 오너들에게 백로그의 최소 30%를 기술적 부채 해결에 할애해 달라고 부탁했다. 수치를 30%로 정한 이유는 소프트웨어 벤더들이 지원 계약에 평균적으로 부과하는 수준이 20~30% 가량이기 때문이다. 그러나 새로운 애플리케이션의 경우 이보다 더 낮은 비율만 할애해도 괜찮다. 반대로, 레거시 애플리케이션이라면 이보다 훨씬 더 높아야 할 것이다.

기술적 부채는 여러 가지 층위에서 해결할 수 있다.

- 대규모 애플리케이션의 라이프사이클 문제의 경우, 업그레이드를 실행하기 위해 하나 이상의 릴리즈를 계획해 두는 것이 좋다. 그리고 이러한 업그레이드에는 새로운 기능이나 변경된 기능을 도입하지 않을 것을 추천한다. 그렇게 해야만 테스팅 팀에서 테스트를 통해 업그레이드의 문제를 파악하기가 더 쉽고, 근본 원인 파악이 수월해 진다.

- 릴리즈 시 제품 오너가 개발팀과 협력하여 사용자, 개발자 생산성에 가장 큰 영향을 미치거나, 애플리케이션을 기타 리스크에 노출시킬 수 있는 기술적 부채를 파악한다. 이러한 채무를 우선순위화하여 사용자 시나리오로써 아이템화 해 두어야 한다.

- 단일 유저 시나리오의 경우, 기저의 기술적 부채 문제를 해결할 수 있도록 개발 팀이 수용 기준을 제안할 수 있다.

유능하고 규율이 확실한 애자일 팀이라면 기술적 부채를 측정하여 채무가 수용 가능 레벨을 넘어섰음을 알리는 지표를 만들어 낼 것이다.

애자일 개발과 QA의 양립
애자일 개발팀 리더들로부터 가장 많이 받는 질문 중 하나가 어떻게 하면 품질 보증(QA, quality assurance)을 애자일 개발 프로세스와 양립시킬 수 있겠느냐 하는 것이다. 특히 스크럼 방법론을 사용하는 팀에서 흔하다.

매 스프린트(sprint) 마지막에 ‘끝난다’는 것은 QA가 그 어떤 새로운 기능 테스트나 회귀 테스트도 스프린트 내에 이행할 수 있게 된다는 의미이다. 그러나 스프린트 지속 시간이 짧고 개발자들이 데모 시점까지 코딩 하기를 원할 경우 이것인 생각보다 쉬운 일이 아닐 수 있다.

또한 유닛 테스팅, 자동화, 그리고 테스트 주도형 개발 관행 등으로 QA와 개발팀 간 책임선이 흐릿해진 가운데 QA를 애자일에 끼워 넣기란 쉽지 않다. 아울러 테스팅에도 여러 종류가 있는데 API, 기능성, 데이터, 모바일 인터페이스, 애플리케이션 보안, 퍼포먼스, 확장성 테스팅 등이 그것이다. 애자일을 통해 시장에 더 빨리 새로운 기능을 공급해야 한다는 기대가 형성된 상태에서 이 모든 테스트를 다 거치는 것은 불가능하거나, 가능하더라도 용납되지 않을 가능성이 높다.

따라서, 애자일 방법론을 통해 더 중요한 것은 ‘빨리 빨리’가 아니라 ‘더 안전하게,’ ‘더 퀄리티 높은’ 기능을 조달하는 것임을 애자일 팀 리더를 비롯하여 모두에게 상기시키는 것이 중요하다. 그러기 위해서는 애플리케이션 개발 단계에 품질보증 관행이 필요하다. 리스크를 관리하고, 개발자와 QA간에 책임을 나누고 규정하며, 애자일 개발 프로세스에 테스팅 일정을 포함시킬 수 있도록 말이다.

테스팅과 개발 관행의 조화를 위해서는 우선 개발 프로세스의 어느 단계에 테스팅이 들어가는 것이 적합할지 생각해 보자. 예컨대, 스크럼 프로세스에서는 아래와 같을 것이다.

- 사용자 시나리오의 초기 테스트는 개발과 동시에 시작되어야 한다. 특히 리스크가 높은 시나리오나, 스프린트 초기에 테스팅이 필요한 시나리오에 대한 테스팅을 먼저 완수하는 것이 중요하다.

- 부가적인 테스트들은 대개 스프린트 막바지에 마무리 된다. 개발자는 기능성 테스트 및 회귀 테스트가 얼마나 오래 걸리느냐에 따라 스프린트가 끝나기 수 일 전에 코드 동결(code freeze)을 계획해 두고 보고된 문제점을 테스트 및 해결하기 위해 노력해야 한다.

- 보안 테스트, 코드 분석, 그리고 퍼포먼스 테스트는 지난 스프린트에서 완성된 코드를 대상으로 진행해도 된다. 코드가 릴리즈 되기 전 일련의 마지막 테스트를 진행한다.

정해진 스프린트 시간 제한 내에 모든 QA와 테스팅을 다 하려면 상당한 수준의 자동화가 필요하다. 기능성 테스트 케이스를 자동화 하여 회귀 테스트에 추가하여야 한다. 이러한 테스트들 중 일부분은 퍼포먼스 테스팅으로 그 용도를 변경할 필요가 있다. 역량 있는 팀일수록 스스로 테스트 커버리지와 자동화 된 테스트 케이스의 비율을 측정할 것이다.




2017.12.22

애자일 방법론의 가치를 극대화하는 방법

Isaac Sacolick | InfoWorld

애자일 개발 프로세스를 진행하거나 참여 중인 사람이라면, 그리고 스크럼(scrum) 방법론과 같은 애자일 모델을 선택한 사람이라면 제품 오너와 고객 니즈, 그리고 여러 팀을 결과 산출에 맞춰 조정하기 위한 기본적인 프로세스를 갖추고 있다고 할 수 있다. 각 팀이 맡고 있는 책무를 뚜렷하게 정의하고, 미팅 스트럭처를 규정하고 일정을 정했으며, 백로그를 관리하기 위한 애자일 협업 툴을 갖춘 상태다.

이 모든 구조, 프로세스, 그리고 협업의 조합이 제대로 갖춰져 있다면 그 어떤 분야의 팀도 애자일 프랙티스를 수월하게 수행할 수 있다. 사실, 애자일 방법론은 애자일 마케팅 등 다양한 비 기술적 분야에도 적용되고 있다.

그렇다면 좋은 소프트웨어를 개발하는 데 있어서 애자일 프로세스만으로 충분할까?

그렇지 않다. 애자일 프로세스 외에도 테크놀로지가 뒷받침 된 일련의 규율이 존재해야만 애자일 방법론의 가치를 극대화 할 수 있다. 애자일의 가치를 극대화 한다는 것은 이 방법론을 통해 기업에서 만족할만한 성과를 거둔다는 의미다.

오늘 이 글에서 다룰 주제는 아래와 같다.

- 애자일 협업 툴이 주요 소프트웨어 개발 라이프사이클(SDLC)을 확실히 지원하도록 하려면 어떤 기술적 문제들을 고려해야 하는가?

- 애플리케이션이 제작 준비가 되었는지, 그리고 변경 내용을 제작 및 컴퓨팅 환경에 반영하기 위한 프로세스를 갖추고 있는지 소프트웨어 개발팀에서 어떻게 확인할 수 있는가?



애자일 개발 방법론의 기술적 부채 정의 및 해결
애자일 개발에서 사용자 시나리오를 구성하기 위해서는 많은 타협과 절충안에 도달해야만 한다. 특히 사용자 시나리오를 구성 시 기능적인 측면에서 타협이 많이 논의 되는데, 스토리 포인트를 예측하기 위해 애자일 추정(agile estimation)을 사용할 경우 더욱 그러하다.

사용자 시나리오가 끝나면, 이제 개발팀에서 그 이행에 대한 기술적 결정을 내릴 시간이다. 이러한 결정을 내릴 때에는 설령 엄격한 기술적 기준이 존재한다 하여도 어느 정도 이행 상의 타협이 불가피하다. 그리고 이러한 타협은 결국 추후 갚아야 할 기술적 부채(technical debt)로 남게 된다.

개발 과정에서는 이러한 기술적 부채가 가시적으로 드러나지 않을 지도 모른다. 이러한 기술적 부채는 이행 단계에서 사용자 행위가 기술적 한계를 노출시킴에 따라 드러나게 된다. 혹은 퍼포먼스나 확장성으로 인해 드러날 수도 있다. 아니면 업그레이드가 필요한 기저의 소프트웨어 요소 라이프사이클이 그 원인일 수도 있다.

애자일 개발 팀에 있는 개발자에게는 이러한 기술적 부채를 기록할 중요한 의무가 있다. 문제가 심각하지 않고 작다면, 코드에 투-두(to-do) 코멘트를 달아 다음 개발자가 해결하도록 두면 된다. 그러나 리팩토링(refactoring)이 필요할 정도의 큰 문제는 백로그에 아이템화 시켜두어야 한다. (여러 개의 코드 변경이 필요하거나, 추가적인 테스팅이 요구되는 기저의 소프트웨어 아키텍처나 컴포넌트 업그레이드와 같은) 애플리케이션 라이프사이클에 따른 니즈는 에픽(epics)으로 정리해 두는 것이 최선이다.

애자일 팀은 자체적인 규칙에 따라 이러한 기술적 부채의 우선 순위를 결정하게 된다. 내가 애자일 프로그램 팀을 이끌 때는 제품 오너들에게 백로그의 최소 30%를 기술적 부채 해결에 할애해 달라고 부탁했다. 수치를 30%로 정한 이유는 소프트웨어 벤더들이 지원 계약에 평균적으로 부과하는 수준이 20~30% 가량이기 때문이다. 그러나 새로운 애플리케이션의 경우 이보다 더 낮은 비율만 할애해도 괜찮다. 반대로, 레거시 애플리케이션이라면 이보다 훨씬 더 높아야 할 것이다.

기술적 부채는 여러 가지 층위에서 해결할 수 있다.

- 대규모 애플리케이션의 라이프사이클 문제의 경우, 업그레이드를 실행하기 위해 하나 이상의 릴리즈를 계획해 두는 것이 좋다. 그리고 이러한 업그레이드에는 새로운 기능이나 변경된 기능을 도입하지 않을 것을 추천한다. 그렇게 해야만 테스팅 팀에서 테스트를 통해 업그레이드의 문제를 파악하기가 더 쉽고, 근본 원인 파악이 수월해 진다.

- 릴리즈 시 제품 오너가 개발팀과 협력하여 사용자, 개발자 생산성에 가장 큰 영향을 미치거나, 애플리케이션을 기타 리스크에 노출시킬 수 있는 기술적 부채를 파악한다. 이러한 채무를 우선순위화하여 사용자 시나리오로써 아이템화 해 두어야 한다.

- 단일 유저 시나리오의 경우, 기저의 기술적 부채 문제를 해결할 수 있도록 개발 팀이 수용 기준을 제안할 수 있다.

유능하고 규율이 확실한 애자일 팀이라면 기술적 부채를 측정하여 채무가 수용 가능 레벨을 넘어섰음을 알리는 지표를 만들어 낼 것이다.

애자일 개발과 QA의 양립
애자일 개발팀 리더들로부터 가장 많이 받는 질문 중 하나가 어떻게 하면 품질 보증(QA, quality assurance)을 애자일 개발 프로세스와 양립시킬 수 있겠느냐 하는 것이다. 특히 스크럼 방법론을 사용하는 팀에서 흔하다.

매 스프린트(sprint) 마지막에 ‘끝난다’는 것은 QA가 그 어떤 새로운 기능 테스트나 회귀 테스트도 스프린트 내에 이행할 수 있게 된다는 의미이다. 그러나 스프린트 지속 시간이 짧고 개발자들이 데모 시점까지 코딩 하기를 원할 경우 이것인 생각보다 쉬운 일이 아닐 수 있다.

또한 유닛 테스팅, 자동화, 그리고 테스트 주도형 개발 관행 등으로 QA와 개발팀 간 책임선이 흐릿해진 가운데 QA를 애자일에 끼워 넣기란 쉽지 않다. 아울러 테스팅에도 여러 종류가 있는데 API, 기능성, 데이터, 모바일 인터페이스, 애플리케이션 보안, 퍼포먼스, 확장성 테스팅 등이 그것이다. 애자일을 통해 시장에 더 빨리 새로운 기능을 공급해야 한다는 기대가 형성된 상태에서 이 모든 테스트를 다 거치는 것은 불가능하거나, 가능하더라도 용납되지 않을 가능성이 높다.

따라서, 애자일 방법론을 통해 더 중요한 것은 ‘빨리 빨리’가 아니라 ‘더 안전하게,’ ‘더 퀄리티 높은’ 기능을 조달하는 것임을 애자일 팀 리더를 비롯하여 모두에게 상기시키는 것이 중요하다. 그러기 위해서는 애플리케이션 개발 단계에 품질보증 관행이 필요하다. 리스크를 관리하고, 개발자와 QA간에 책임을 나누고 규정하며, 애자일 개발 프로세스에 테스팅 일정을 포함시킬 수 있도록 말이다.

테스팅과 개발 관행의 조화를 위해서는 우선 개발 프로세스의 어느 단계에 테스팅이 들어가는 것이 적합할지 생각해 보자. 예컨대, 스크럼 프로세스에서는 아래와 같을 것이다.

- 사용자 시나리오의 초기 테스트는 개발과 동시에 시작되어야 한다. 특히 리스크가 높은 시나리오나, 스프린트 초기에 테스팅이 필요한 시나리오에 대한 테스팅을 먼저 완수하는 것이 중요하다.

- 부가적인 테스트들은 대개 스프린트 막바지에 마무리 된다. 개발자는 기능성 테스트 및 회귀 테스트가 얼마나 오래 걸리느냐에 따라 스프린트가 끝나기 수 일 전에 코드 동결(code freeze)을 계획해 두고 보고된 문제점을 테스트 및 해결하기 위해 노력해야 한다.

- 보안 테스트, 코드 분석, 그리고 퍼포먼스 테스트는 지난 스프린트에서 완성된 코드를 대상으로 진행해도 된다. 코드가 릴리즈 되기 전 일련의 마지막 테스트를 진행한다.

정해진 스프린트 시간 제한 내에 모든 QA와 테스팅을 다 하려면 상당한 수준의 자동화가 필요하다. 기능성 테스트 케이스를 자동화 하여 회귀 테스트에 추가하여야 한다. 이러한 테스트들 중 일부분은 퍼포먼스 테스팅으로 그 용도를 변경할 필요가 있다. 역량 있는 팀일수록 스스로 테스트 커버리지와 자동화 된 테스트 케이스의 비율을 측정할 것이다.


X