Just in Chronicles

Life as a Voyage

Archive for the ‘English to Korean’ Category

Translation: The Agile Waterfall

leave a comment »

Disclaimer: This is the translated article, The Agile Waterfall, originally written by Jon Arnold on .net magazine. The translator doesn’t guarantee the quality of the translation.

The Agile Waterfall – 2012년 3월 19일, Jon Arnold

작성자인 Jon Arnold는 Centresource Interactive Agency에서 현재 전략 컨설턴트로 일하고 있습니다. 이 글에서 그는 애자일 방법론과 전통적인 워터폴 방법론을 어떻게 조화롭게 섞어서 쓸 수 있는지 설명합니다.

최근에 우리 팀은 애자일 개발 방법론과 전통적 워터폴 방법론을 조합해서 쓰는 방식을 실험중에 있습니다. 많은 프로젝트 매니지먼트 전문가들은 이것을 “물에 젖은 애자일 (WetAgile)” 이라고 부르기도 합니다. 적절하지만 발음하기가 좀 부담스러운 단어네요. 좀 더 설명하기 전에, 배경지식에 대한 설명을 덧붙이자면:

우리는 표준 워터폴 방식을 4D 어프로치라고 합니다 – Define (정의), Design (설계), Develop (개발), 그리고 Deploy (설치). 각각의 단계는 다음 단계로 넘어가기 전에 명확한 종료지점이 있어서 웹 개발에서는 매우 표준적인 방식이지요. 고객과 함께 마일스톤을 잡고, 기대치를 설정하는데 매우 좋습니다. 하지만, 어떤 면에서는 내부적인 문제 또는 시간관리에 있어서 꽤 어려워지기도 합니다.

이것이 워터폴 방식으로 작업하는 데 있어서 가장 큰 약점입니다. 실제로 각각의 단계를 “정말로” 끝냈다고 말할 수 없기 때문입니다. 아무리 명확한 계획을 세웠다 하더라도 실제로는 개발 단계에서 디자인을 수정할 필요가 생긴다거나, 개발자가 디자이너와 함께 애니메이션 효과라든가 하는 시각적인 효과들을 논의해야 하는 경우가 생기게 마련입니다.

애자일 방법론으로는 우리는 보통 작은 규모의 전담 팀을 회사 내에 만들어서 함께 긴밀하게 일하도록 합니다. 엄청나게 많은 양의 소통과 협업이 있구요, 종종 고객도 이러한 소통에 참여하기도 합니다. 많은 애자일 프로젝트들은 몇 번의 스프린트(30일을 주기로 하는 반복적인 개발 사이클 – 역자 주)를 거치면서, 혹은 일주일 또는 이주일 간격의 집중적인 개발기간 동안, 혹은 실제 웹 사이트에서 기능들을 정의하면서 계속해서 발전해 나갑니다.

Agile Waterfall

만약 당신이 워터폴 방식의 프로젝트를 생각한다면, 애자일은 서로를 기반으로 하는 일련의 동심원들로 시각화를 할 수 있습니다. 우린 이 모델을 루비 프로젝트에 적용시켰구요, 단기간에 집중적인 개발이 필요한 다른 프로젝트들에도 적용시켜 봤습니다. 애자일 방식은 어떤 고객들에게는 짜증스럽게 느끼는 방식이기도 합니다. 짧은 기간과 지속적인 반복 사이클은 좀 더 전통적인 협업을 기대했던 어떤 고객들에게는 굉장히 스트레스 받는 일로 느껴지게 하더군요.

그래서, 우린 마치 초콜렛에 땅콩버터를 섞듯이 그 두가지를 섞어봤습니다. 그것이 바로 Agile Waterfall 방식인데요, 이것은 일반적으로:

  1. 디자이너가 홈페이지 컨셉을 잡습니다. 그리고 그것은 개발자와 기획자와 함께 내부적으로 리뷰를 합니다.
  2. 이렇게 만들어진 리뷰는 고객과 함께 다시 한번 공유를 합니다. 그리고, 고객은 피드백을 주게 됩니다.
  3. 최종 결과물이 만들어지고 디자이너는 이제 세부 페이지 디자인 컨셉을 잡기 시작합니다.

그동안에 두명의 개발자들은 초기 개발을 시작합니다 (보통 한 개발자가 백엔드 개발을 리드하고, 다른 한 개발자는  프론트엔드 개발을 하죠). 그들은 최초 리뷰 회의에서 나온 개발 순서를 갖고 있습니다. 따라서, 대략적으로 무슨 일이 일어날 지는 알고 있죠. 개발자들의 일반적인 방식은 아래와 같습니다.

  1. 선임 백엔드 개발자는 CMS를 셋업한 후 주요 기능요소들을 개발하기 시작합니다 (보통 모델과 콘트롤러들이죠).
  2. 이러한 요소들의 프로토타이핑을 끝낸 후 기획 회의에서 그것들을 디자이너와 기획자와 함께 리뷰합니다. 그렇게 함으로써 모두가 같은 내용을 공유하는지 확인하는 거죠.
  3. 디자이너가 위의 세번째 과정을 끝내면, 선임 프론트엔드 개발자는 홈페이지를 요소별로 잘개 쪼개서 현재 개발하는 곳에 붙여 넣습니다.

… 그리고 여기서부터 모든 것들이 계속해서 굴러갑니다. 이 과정 동안 기획자는 계속해서 고객에게, 때때로 개발환경에 접근권한을 줘서, 진행상황을 알려줍니다. 기획자는 또한 고객의 피드백을 이용해서 시각적, 기술적인 결과물들을 개발팀이 통합할 수 있게끔 도와줍니다.

수많은 애자일 순수주의자들은 아마도 이 글을 읽는 동안 피눈물이 날 겁니다. 좀 더 명확하게 말하자면, 저는 구체적으로 우리 회사에서 전통적인 워터폴 모델로 개발했던 프로젝트들에 대해 얘기하고 있습니다. 이 프로젝트들은 전형적인 적은 예산의 웹 애플리케이션이거나, 커다란 마케팅용 웹사이트 프로젝트입니다. 보통 이것들은 워터폴 방법론으로도 충분합니다. 이것은 또한 또한 애자일 방법론을 혼란스러워하는 고객들에게도 훌륭한 방식입니다. 애자일 방법론은 종종 끝없는 예산과 시간계획이 필요하다고 알려져 있어서 비용 절감을 목표로 하는 마케팅 담당자들은 싫어하기도 합니다.

지금까지 결과들은 다 훌륭했습니다. 마감일을 지켰구요, 예산 절감에 고객 만족까지 실행시켰습니다 – 웹 에이전시가 “성공”이라고 여기는 세가지 조건이지요. 돈이 들어가면 웹사이트가 나오는 블랙박스 같은 웹 에이전시 입장에서는 이 개발 방법론은 빡빡한 예산과 개발 기간 안에서 우리를 끊임없이 돌아보게 하고 고객 중심적으로 만들었답니다.

Advertisements

Written by Justin Yoo

20/03/2012 at 12:34