애자일을 제대로 하려면 2주동안 Release 하면 되는건가요?
아니다.
그것은 애자일이 아니라 계획을 2주동안 잡고 새로 계획을 바꾸는 것에 불과하다.
애자일의 핵심은 커뮤니케이션이기 때문이다.
커뮤니케이션은 무엇인가?

"누구나 알아 들을 수 있는 말로 목표를 전 구성원 즉, 개발팀과 고객이 공유하고 있어야 한다"
그것이 바로 제대로된 커뮤니케이션이다.

혹자는 PM만이 알고 있는 혹은 개발 PL만이 알고 있는 부분이 있어야 자신의 영역이 생긴다고 믿는다.
그것은 정확하고 명확하게 틀렸다.

PM과 PL은 커뮤니케이션이 능통해야하며 고객의 어려운 이야기를 풀어서 개발팀원을 이해시켜야 하는 자리이다. 따라서, PM이나 PL이 커뮤니케이션에 능통하지 못하고 구시대적인 정치적인 발상으로 인해 자기만 알고 있거나 확정되지 않았다는 이유로 공개를 하지 않는다면 프로젝트는 망한다.
개발팀원들은 방향을 잡지 못하고 우왕좌왕하다 고객(돈주는 사람)이 전혀 원하지 않는 시스템을 구축할 확률이 매우 높아진다.

또한 어려운 아키텍쳐나 어려운 개념만 들고나오면 그것도 개발팀원들을 고객을 혼란스럽게 할 뿐이다.

따라서, 모든 용어는 분명하고 쉬운 용어를 사용하고 설계도 누가 보더라도 이해하기 쉽게 해석이 가능해야 한다.

다음의 영화는 혹자들은 정치적인 내분이라고 하지만 내가 보기에는 커뮤니케이션 문제로 발생하는 극단적인 드라마이다.
그영화는 바로 크림슨 타이드 (Crimson Tide)

USS Alrabama는 작전중에 러시아 핵이 쿠테타 세력에게 탈취되어 미국으로 발사예정이라는 전문을 접하고 사전에 차단하라는 명령을 받지만 뒤이어 쿠테타 세력에게 공격받으며 무선이 끊긴다.
불명확한 정보만 가지고 핵을 발사할 수 없다고 버티는 부함장과 지금 발사하지 않으면 핵전쟁이 일어날거라 믿는 함장간의 갈등이 고조되고 부함장이 함장을 직위해제하고 다시 함장이 지휘권을 잡지만 부함장은 다시 탈출하고 결국은 무선을 재수신한 결과 작전이 취소되어 평화를 찾는다는 이야기다.

문제의 발단은 어디 있다고 보는가?
EAM (Emergency Action Message)는 "핵미사일 발......"로 끝났다.
여기서 부터 두 케릭터는 스스로 옳다고 생각하는 방향이상은 생각하지 않았고 대화보다는 완력으로 누르려 하였다.
결국 전문을 다 수신하고 나서의 스샷이다.

우리속담에 "아"다르고 "어"다르다는 말이 있다. 우리는 스스로 아와 어를 구분해서 사용하고 있었는가?
XP방법론에서 Pair programming이란 이러한 Communication 을 극대화한 시스템이다.
개발자 2명에 고객 1명을 한방에 가두고 프로젝트기간 내내 붙어 다니게 만든다.
한국사회에서는 거의 불가능에 가깝기에 나는 프로젝트 기간 내내 Wiki 시스템을 활용하였다.

TRAC의 Wiki는 훌륭하게 작동되고 보고서의 양식이 반드시 텍스트 기반일 필요는 없었다.
가령 보고서를 만드는데 동영상으로 촬영해서 지금 워킹되는 상태를 보여주는 것은 일반 MS WORD나 한글워드가 할 수 있는 범위가 아니다.
물론 억지로 하자면 하겠지만 그 많은 데이터를 어떻게 전송하고 언제 열어 볼것인가?

Youtube에 업로드하고 링크 걸어두는 편이 훨씬 싸게 접근이 가능한것이다.
또한 Wiki의 경우는 용어의 혼란을 없앨수 있다.

따라서, TRAC Wiki를 사용함으로써 보고서, 이슈관리, 개인별 업무관리 등등이 가능해지는 것이다.

마지막으로 커뮤니케이션의 중요함을 한번 더 강조하자 ^^

지난번에 이은 애자일 이야기이다.
XP와 스크럼 등의 방법들도 매우 좋은 방법이지만 내가 근무하는 환경에서는 당췌 먹히지가 않는 방법들이었다. 그래서 기존 정보공학방법과의 타협이 필요했고 그 무엇인가 없을까?라는 생각에 가상 시나리오 써가면서 그리고 이전에 내가 근무하는 환경과 크게 동떨어지지 않는 환경을 검토하기 시작하였다.

그러던차에 다음의 통상적인 패턴이 보이기 시작한것이다.


위의 그림은 요구사항의 에러를 찾아내고 FIX하는데 드는 비용을 예로 들었지만 요구변경 숫자와도 직접적인 관계가 있다. 딱. 저만큼 요구변경 그 단계에서 일어난다.

또한 우리가 짜는 WBS에도 문제가 있다는 것을 알게 되었다.

+ 요구분석 (총 10일 / 2주)
   +- 1차인터뷰 2일
   +- 1차요구정리 1일
   +- 2차인터뷰 2일
   +- 2차요구정리 1일
   +- 요구사항명세서작업 1일
   +- 요구사항정의서작업 1일
   +- 요구사항분석발표 1일
+ 설계 (총 10일 / 2주)
   +- 프로세스정의서 1일
   +- 프로세스명세서 1일
   +- 인터페이스정의 1일
   +- CRUD정의서 2일
   +- Entity정의서 2일
   +- 테이블정의서 2일
   +- DB정의서/명세서 1일
   +- 화면설계서 10일 (병행)
+ 개발 (총 20일 / 4주)
   +- 열심히 개발 20일
   +- 단위테스트 20일 (병행)
+ 통합 (총 2일)
   +- 알파오픈
+ 테스트 (총 10일 / 2주)
   +- 통합시험/성능시험 3일
   +- 통합시험/성능시험개선 2일
   +- 인수시험 5일
   +- 인수시험개선 5일 (인수시험병행)
+ 전환 (총 3일)
   +- 상용데이터전환 2일
   +- 상용오픈/비상대기 1일
+기타
   +- 주간보고 1주마다 1회
   +- 월간보고 매월말 1회

위는 예시일뿐이지만 흔히 작성하는 WBS이다. (물론 내가 주구장창 작성했던 양식이기도 하고...)
그런데 위의 문제는 바로 크게는 "커뮤니케이션" 비용이 빠져 있다는 것이고 그 다음으로는 "재작업시간"이 과소평가되어 있다는 것이다. 거기다가 "프로젝트관리"에 대한 비용도 빠져 있다.
다시말해 다음의 것들이 빠져있다는 이야기이다.

1. 개발팀원간의 목표공유 (주간/월간회의만 가지고 될까?)
2. 고객과의 목표공유 (주간/월간보고만으로 가능할까?)
3. 재작업시간은 어디에?
4. 매뉴얼 작업 등의 문서작업은 언제하나요?
5. 고객에게 넘기기전에 개발팀원들끼리 리뷰하는 시간은 어디에?
6. 테스트 결과에 따른 품질완성도를 100%에 가깝다고 보고 있다.
7. 결정적으로 의사결정 시간이 없다!!!
8. 기타 등등등한 잔업들은 어디에?
--> 결국 밤새도 안되는 이상한 일정이 되고 만다.

즉, 인간이 내일 일을 예측하는것은 불가능에 가까운데 약 3개월간의 일정을 짜라니 끽해봐야 이정
밖에 안나오는 것이다. 결국은 밤새야 하는것이다. 일정이란게 잡혀 있고 결국 일정에 쫒기며 밤새서 해야 한다는 결론에 도달한다. 밤새서 할수 있으면 다행인데 밤새서도 못하기때문에 일정지연은 필연이다.
결국 밤새서 일하고 욕쳐먹고...
거기다가 요구사항 분석에 따라 설계하고 개발했음에도 고객의 마음과 다르다. 이게 진짜 환장하는 것이다.
그래서 받아 들인것이 공정의 부분 자동화와 작업의 통합이었다.
먼저 분석은 UML의 USE CASE와 Activity diagram를 사용하면 되지 않는가?
그리고 설계는 UML의 Class Diagram과 Sequence diagram으로 해결이 가능하다.
즉, 분석설계는 UML 4종셋으로 해결이 가능하였다.
그리고 개발단계에서 단위테스트는 JUNIT이나 Visual Studio의 단위테스트를 쓰면 빌드할때 마다 유닛테스트는 자동으로 되지 않는가?인터페이스 정의서는 Doxygen이라는 녀석이 있으니 이것을 사용하면 된다.
보고서는 Wiki를 사용하고 issue관리는 issue tracker를 사용하면 되는 것이다.
거기다가 상용으로 전환도 iBatis와 같은 O-R Mapping tool을 사용하면 되지 않을까?
소스관리는 SVN이라는 것으로 하면 그것도 간단할 것 같았다.
이 모든것을 사용하면 어느정도 자동화가 가능할 것 같았다.

그리고 받아 들인것이 가조립이었다.
* 아래의 부품들이 모여서 정확히 무엇이 될지는 조립해봐야 아는것 아닌가?

프라모델강좌나 후기를 보면 항상 다음과 같이 진행된다.

1. 부품분리
2. 가조립
3. 부품별도색
4. 영구조립
5. 마무리

재미 있는 것은 저 가조립이라는 것을 작게는 부품별로 크게는 큰 덩치별로 자주 할수록 더 좋은 품질이 나온다는 것이다.

다시말해 똑같은 프라모델이라도 가조립을 많이하고 어떤 색을 칠할것인지 의사결정을 빨리할 수록 더 나은 품질과 더 빠른 조립시간을 보장한다.

어떻게 보면 가조립은 작은 단위의 유닛테스트와 통합테스트되겠다.
즉, 유닛테스트와 통합테스트를 많이 하면 할 수록 의사결정에 들어가는 시간과 노력을 절감할 수 있다는 결론에 이른것이다.

그래서 하나더 받아들인것이 바로 목업개념이다.

* 1954년 F-4 팬텀II에 적용된 개발목업

최종형상을 눈으로 보고 손으로 만져 볼 수 있도록 하기위해 목업이라는 것을 받아 들였다.
이는 작동해야 한다는 전재를 하고 있으므로 정확하게는 목업보다는 "프로토타잎"에 더 가까운 개념이 되겠다.

다시 정리하면 다음과 같이 공정관리부분을 고쳤다.

1. 요구사항을 들으면서 "프로토타잎"을 만든다.
   -> 이때 중요한것은 디자인 부분인데 디자인보다는 배치와 버튼의 위치와 버튼을
       눌렀을때 작동하는것에 중점을 둔다. 그리고 팀원간의 팀웤을 점검하고 프로세
       스를 점검하는 그런 시간을 가진다.
2. UI에 대한 프로토타잎이 끝나면 프로토타잎을 배포하고 요구사항에 대한 변경을
   받아 2차 프로토타잎으로 갈지 아니면 개발공정으로 갈지 결정한다.
3. 개발공정으로 간다면 프로토타잎을 보며 UML로 역설계한다.
   -> 여기서도 중요한것이 한번에 다하려 하지말고 iteration1에서는 추상화레벨을
       높였다가 단계를 거듭하며 추상화 레벨을 낮춰가라
4. UML로 역설계한다음 논리적으로 이상없는지 검증하고 유닛테스트와 통합테스트
   의 결과를 예측한다.
5. 프로토타잎에서 FIX된 대로 개발자에게 배포하고 개발을 진행하며 HUDSON이라
   는 가조립 빌드툴로 매일 개발 진척도를 체크한다.
   -> 이때 HUDSON에 MS TEST 또는 JUNIT 으로 나온 결과로 개발진척을 평가
       하는것이 중요하다.
6. 개발중간에 2주에 한번씩 중간보고형식으로 가조립된 결과물을 고객과 공유한다.
7. 어느 정도 공정이 마무리되면 고객으로부터 Feedback을 받아 적용한다.
8. 문서 산출물은 쓸데없이 많이 만들지 않고 TRAC을 통해 관리한다.
9. 5~8번을 2주단위로 계속 반복한다.

이렇게 함으로써 문서작업, 통합테스트와 단위테스트 그리고 가장 중요한 의사결정 시간 및 인수시험을 단축할 수 있었다.

다음에는 시간이 되면 구체적으로 개발서버를 어떻게 구성하며 어떻게 유기적으로 시스템을 사용하는지에 대해 이야기해보자.

수행경험을 언젠가는 정리하려 마음 먹고 있었지만 시간이 나지 않아 정리하지 못하였다.
휴가 기간아니면 언제 또 하랴?

애자일이란 것은 어떤 특정한 방법을 이야기하는 것이 아니다. 흔히 많은 사람들이 애자일하면 XP를 연상하지만 애자일은 기존의 WBS Driven / Waterfall 로 대표되는 정보공학 방법들의 문제를 해결하기 위해 만들어진 수많은 방법들을 통칭하며 한번에 긴시간과 많은 자원을 가지고 문제를 해결하기보다는 짧은 시간과 작은 자원을 가지고 반복수행으로 문제를 해결한다는 특징을 지니고 있다.

혹시 기존의 방법들로 해서 이런 문제를 겪어 보지는 못하였는가?

1. 납기일 전 철야
2. 철야에도 불구하고 납기일 지연
3. 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
4. 결국 납기된 솔루션은 고객의 요구를 충족하지 못함

이것이 바로 그 유명하고 대한민국 99%의 개발자들이 겪고 있고 특히 SI업계의 가장큰 문제점이다. 이러한 문제를 해결하기위해 출현한 개념이 바로 "추상화"이다.
대한민국 개발자중 대부분이 알고 있어야 하는 개념인 추상화.
어디서 많이 들어보지 않았는가? 바로 JAVA나 .NET에 빠지지 않고 등장하는 개념이다.

예를 들자면 처음 영업단계에서 고객의 요구사항은 항상 이런식이다.

어~ 그거 간단하게 이렇게 이렇게해서 요렇게만 구현되면돼

그리고 개발초기에는

아~ 그거 이렇게 이렇게 해줘

그리고 복잡도가 조금 올라가는 개발중간에는

아니!? 너희가 전문가라메? 전문가면 전문가 답게 너희가 컨설팅을 해줘야지!!!!

그리고 개발종료시점에는

여기서 조금 갈린다.
능력있는 고객:
- 일정지연되면 안되니까 빨리 마무리 하고 시바 근데 우리 애들중에 이거 받아서 유지보수 할 수 있는 애가 없는데.. 너네가 무상으로 3개월동안 유지보수해
능력없는 고객:
- 배째. 누가 이런거 만들어 달랬어?

이바닥 SI업계가 처한 현실이다.
어렵게 어렵게 돈 받아 내더라도 고객도 나도 상처뿐인 인연으로 끝마치는 아주 이상한 관계를 지난 10여년 동안 지속했었다.

각설하고 위의 고객과 나의 대화를 차분히 상펴보면 바로 추상화 레벨의 차이가 있다.
처음에는 아주 추상적인 그림으로 불명확한 그림을 이야기한다.
유명한 아파치 헬기로 예를 들면 다음과 같다.
먼저 컨설던트 또는 기획자들이 그린 아파치는 이러하다.

그리고 나서 사업수행계획서에 나오는 아파치는 이러하다.
그리고 분석설계를 하면 이렇게 바뀐다.
이제 개발자의 손에 넘겨지고 통합단계 이전의 산출물들은 다음과 같이 만들어 진다.
이제 통합이다. 다음은 통합되고 나서의 모습이다!
테스트과정으로 넘어가면 고객의 요구사항이 쏟아지기 시작하고 거의는 겆잡을 수 없을 정도가 된다.
결국 껴서 팔기 하게된다. 예비부품 몇개 더 주고 도색도 좀 참하게 바꾸고...
결국은 최종 프로젝트 종료때는 이렇게 변해 있다.

어떤가? 처음에는 아파치헬기라는 것부터 시작했다. 그러다가 헬리콥터라고 하는 추상화가 높은 레벨에서 분석 설계가 끝난뒤에 어느정도 디테일한 부분이 추가되기 시작했고 실재 구현은 RC헬리콥터인 아파치로 구현되었다. 그러면서 테스트를 거치며 하나 둘씩 추가기능이나 옵션들이 늘어나고 최종에는 무지많은 옵션을 껴서 결국 종료되는 형태이다.

다시말해 추상화의 레벨이 높은 곳에서 낮은곳으로 흐른 것이다.
애자일은 이러한 추상화의 레벨을 사용자와 개발자의 수준을 동기화 시키기위한 목적으로 고안된 방법론으로 최종의 목표는 커뮤니케이션을 더 잘하는 방법이다.
다음에는 조금 더 구체적인 방법들을 가지고 이야기해보자.