IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

애자일방법론

애자일 프랙티스라는 책을 읽어보셨나요?
아래는 “Agile vs. Waterfall A Tale of Two Teams – Quality Testing” 이라는 유투브 동영상입니다.
http://youtu.be/PHS-ycbRwqI

약간 동의되지 않는 부분도 있지만, 재미있게 표현되었다는 생각이 듭니다.

책에 나오는 이야기가 아니라 Agile을 해보면서 느꼈던 점을 정리해볼까 합니다.

1. 왜 Agile 을 하는가?

“은행이나 무역처럼 이미 시스템화해야 할 업무가 명백한 경우, 공공부문 처럼 법이나 프로세스가 명확한 경우, 회계나 인사처럼 일반화된 업무인 경우”

위와 같은 환경은 업무요건들이 거의 바뀌지 않고, 업무간 의존성이 높고 복잡합니다.
하나의 결과를 위해 긴 업무처리 절차가 필요합니다.
정형화된 업무는 새로운 업무설계 및 탐색 비용이 거의 없는 반면, 높은 복잡도와 정확성을 가지고 효율적인 결과를 내는 것이 더 중요합니다.

업무 복잡도와 의존도가 높으므로 치밀하게 설계해야 하고, ROI와 효율화가 중요하므로 충분히 예측한 후에 실행하는 Waterfall 만한 방법이 없다고 할 수 있습니다.

하지만, 재미를 추구하는 엔터테인먼트형 서비스들은 다릅니다.
충분한 서비스 기획의도를 바탕으로 어떤 디테일 요소가 사용자들에게 먹힐지 모릅니다.
재미있어 보이는 기능을 제공해보고, 반응이 시원치 않으면 삭제하기도 합니다.
기획자의 요구사항이 명확할리 없으며, “효율”보다는 “효과”가 우선시 되는 환경입니다.
(효율화라는 관점에서 상충되는 부분이 있습니다만…)

즉, Agile 방법론은 예측하기 힘든 “개척형 사업모델”에 적합하다고 볼 수 있습니다.

2012021616151287880_162638_0

Agile은 Try and Error를 작게 자주 반복하는 것입니다.
만일 Try 를 작게 만들지 않고 Error 를 학습하지 않으면, Agile 하지 않다고 보아야 합니다.

그러면, Try and Error 를 왜 할까요?

그것은 “경험학습”을 통해 사업자의 “통찰력”을 높이기 위해서입니다.
“통찰력”을 높이는 이유는 “좋은 선택(Better Selection)”을 하기 위해서입니다.
즉, 작은 결정환경에서 “좋은 선택”을 자주 하는 것으로 위험부담을 줄이는 겁니다.

길고 치밀한 고민을 한 후에 옳은 결정 Right decision을 시도하는 것은 Agile이 아닙니다.
실패할 경우에 대한 부담이 매우 큽니다.

Try and error로만 불안한 사업환경은 다른 수단을 보완할 필요가 있습니다.

2. Iteration, 왜 하는가?

Iteration 은 산출물을 만들어내는 하나의 Cycle 입니다.
왜 산출물을 만들까요? 그것은 “보고 확인하기” 위해서입니다.
왜 그렇게 할까요? 보아야 알 수 있기 때문입니다.

사용자User 가 보기 전까지 제작자가 판단하지 않는 겁니다.
왜 볼까요? 그게 사용자User 와 제작자Producer의 Gap 을 없애는 가장 좋은 방법이기 때문입니다.

모든 걸 보아야 알까요? 아닙니다.
반복한다는 Iteration 이라는 단어에 매몰되면 안됩니다.
반복한다는 것은 제작팀 내에서 Try와 Error에 대해 자주 소통Communication한다는 뜻입니다.

그렇다면, Iteration 단위를 어떻게 잘라야 할까요? 무조건 2주이어야 할까요?

“어떤 단위의 결과물을 보고 커뮤니케이션 할 것인가”가 중요합니다.
“참여자들과, 또는 최종사용자들과 어떻게 커뮤니케이션을 자주 할 것인가?”
이것이 Iteration 의 단위가 됩니다.

눈에 보이는 FrontEnd 개발은 화면 중심으로 자주 하는게 좋습니다.
눈에 보이지 않는 Backend 는 기능단위로 맥을 짚어 하는게 좋습니다.
당연히 두 개의 Cycle 은 다릅니다.

참고로, “최종 사용자”란 API는 API개발자이며, “서비스 기획자”에게는 “서비스 사용자”를 말합니다. 즉, 상대적인 개념입니다. 관점에 따라서는 제작자Producer는 사용자User일 수 있습니다.

Agile 과 Iteration 을 책보고 공부하듯 하면 안됩니다.
합리적으로 생각해야 합니다.

얻어야 할 것은 “경험”과 “통찰력”입니다.
이것이 실패를 줄여주고, 더 좋은 길(Better direction)로 가게끔 이끌어 줍니다.

3. 무엇에 집중해야 하는가?

Agile 은 일을 하기 위한 도구입니다.
단기적으로는 Iteration 이 돌 때 마다 얻어내야할 작은 성과에 집중해야 합니다.
그러나, 성과에 앞서서 본질(=Communication)을 놓치지 말아야 합니다.

커뮤니케이션에 집중해야 합니다.
커뮤니케이션은 피아가 구별되지 않는 칠흑과 같은 암흑 속에서 서로의 존재를 확인시켜주는 유일한 수단입니다.

Try and Error 하지 않으면 아는 길만 가게 됩니다.
만일 아는 길이라면 굳이 Agile 하지 않아도 좋습니다.
그러나, 모르는 길이라면 Agile을 필수로 추천드립니다.

더 좋은 선택(Better Selection)를 위해 현재 하고 있는 일의 틀을 깰 수 있어야 합니다.
사고패턴과 틀에 갖혀서 사고하는 것으로는 충분하지 않습니다.

최종사용자End User에게 집중하십시요.
서비스라면, 결국 최종사용자의 선택(Selection)이 성공과 실패를 가늠짓습니다.
“개척형 비즈니스”에게는 도구와 틀을 잘 준수하는 것이 미덕이 되지는 않습니다.

4. 전제조건이 있나?

불행히도 Agile 과 Iteration 의 전제조건은, 참여자가 내용을 잘 이해하는 경험자이거나 고급자라는 가정에서 출발합니다.
즉, 쌍방향 커뮤니케이션이 원활히 되고 협조가 잘 된다는 전제가 필요합니다.

따라서 Agile과 Iteration 은 서로에 대한 신뢰와 운명공동체라는 의식이 없으면 어렵습니다.
쉽게 이야기하면, 효과적 커뮤니케이션을 위해 복잡한 절차를 없이 일한다는 뜻이므로, 서로의 호흡이 맞지 않으면 Agile 은 실패한다고 보아야 합니다.

필수 전제조건은 같이 죽고 같이 산다는 “운명 공동체 의식”입니다.
이것은 말로 강조해서는 되지 않고, 적절한 조직적,제도적 틀을 만들어줘야 합니다.

5. Agile이 만능인가?

Agile 과 Iteration은 개발방법론입니다.
더 큰 소프트웨어 공학 관점에서 보면, 많은 다양한 것들이 있습니다.
좋은 도구는 새로운 시각을 선사합니다.
왜 좋은 도구를 쓰는지 이해를 하고, 도구에 매몰되지 않는 것이 중요할 것 같습니다.

※ 엮인글 : Agile하게 일하기

Advertisements

애자일방법론”에 대한 3개의 댓글

  1. 공돌이pooh
    2014년 5월 12일

    글 감사합니다.

    • subokim
      2014년 5월 12일

      부족한 글 읽어주셔서 감사합니다.

  2. 핑백: Agile하게 일하기 « IT의 중심에서

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2013년 1월 31일에 님이 API와 기술에 게시하였으며 , , 태그가 지정되었습니다.

내비게이션

누적 조회수

  • 956,079 Visits

페이스북 페이지

%d 블로거가 이것을 좋아합니다: