태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (1308)
마이크로소.. (132)
민수네 가족 (17)
호랭이 사.. (141)
열이아빠의.. (7)
PlayPhone (98)
NetworkON (1)
ratharn의.. (10)
큐브 해법 (10)
사람들 (6)
개발 이야기 (94)
아이티 이.. (539)
영어 이야기 (2)
좋은책 이.. (8)
대기중인.. (1)
발명 이야기 (2)
건강하게.. (15)
삼성전자  호랭이  개발자  LG전자  아이폰  구글  마이크로소프트웨어  마이크로소프트  마소  블로그 
 free offers
└>free offers
 online pharma..
└>online pharma..
 Go here
└>Go here
 visit my webp..
└>visit my webp..
 Go Source
└>Go Source
«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 R⋯
+ Gsong.s Blog
+ 비주얼스튜디⋯
+ 광파리의 글⋯
+ LovedWeb
+ 블루오션의⋯
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로⋯
+ Total : 2,100,946
+ Today : 5
+ Yesterday : 5
  

 

 

 

안영회 _해당되는 글 2건
2009.11.23   개발 방법론에 생명 불어넣기 (3)
2009.02.18   애자일 프랙티스의 실제 활용사례 (2)

 

개발 방법론에 생명 불어넣기
+   [마이크로소프트웨어]   |  2009. 11. 23. 08:32  


대체로 그렇기는 하지만 꼭 잘생기거나 예쁜 사람이 이성 친구가 많은 것은 아닙니다.

성실하고 일을 열심히 하는 사람이 꼭 성공하게 되는 것도 아니지요.

이처럼 세상의 이치는 참으로 오묘해서 정답이란 걸 찾기가 여간 어렵지 않습니다.

이번 글은 월간 마이크로소프트웨어에 실린 글인데요.

맹목적인 방법론의 적용이나 배타 대신 보다 제대로 개발 방법론을 활용하는데 도움이 될 듯하여 옮겨봅니다.

좋은 제품과 잘 팔리는 제품은 다르듯, 잘 만들어진 개발방법론과 널리 쓰이는 개발방법론은 반드시 같지 않을 수 있다. 개발방법론이 널리 쓰이지 않는다면, 그리고 상황에 맞게 변화하지 않는다면 과연 가치 있는 것이라 할 수 있을까? 이런 고민은 방법론 무용론으로도 이어질 수 있다. 그러므로 방법론이 쓸모가 없다고 생각된다면 그 방법론을 의심하기 전에 제대로 활용하고 있는 건지를 먼저 의심할 필요가 있다. 이 컬럼은 이런 전제에서 시작한다.

안영회 ahnyounghoe@gmail.com|(주)아이티와이즈 컨설팅 SE 그룹에서 컨설턴트로 일하고 있으며, 국내 대규모 프로젝트에서 다년간 방법론, 모델링, 아키텍처 수립, 프로젝트 관리 등의 다양한 역할을 수행하고 있다. 현재는 보험사 시스템 구축 프로젝트에서 소프트웨어 아키텍트로 일하고 있으며 한국스프링사용자모임(KSUG)의 대표를 맡고 있기도 하다. 본인의 블로그인 Younghoe.info를 통해 현장 경험 나누기를 즐기고 있으니 교류를 원하는 분은 언제라도 환영한다.

여러분이 어떤 조직의 IT 운영팀장이라고 가정해보자. 우리 회사는 이미 오래 전에 선진 사례라고 알려진 RU P(Rational Unified Process)를 받아들였다(http://en.wiki pedia.org/wiki/RUP). 예산을 편성해서 프로젝트를 발주했고, 유명 컨설팅 회사가 우리 회사에 맞도록 RUP를 테일러링(tailoring)했다. 결과물은 우리 회사 표준 개발방법론으로 지정했다. 표준 개발방법론은 시스템 개발 과정에서 필요한 역할, 작업 진행을 위한 프로세스를 설명하고 있다. 또한, 각 작업마다 참조할 수 있는 지침과 표준 양식 그리고 점검표 등을 포함하고 있다. 표준 방법론을 만든 이후에 시행하는 모든 시스템 개발 프로젝트에 적용해 보았지만 반응은 기대 이하다. 성과가 없다 보니 자조적인 평가도 나왔다. UML 표기법을 썼다는 점이나 유스케이스(use case) 단위로 산출물을 다룬 형식적인 측면을 빼면 예전보다 나아진 점이 없다고 불평하는 직원도 있었다. 더구나 UML 표기법이나 유스케이스 개념은 조직 내에서 널리 쓰이고 있지도 않다.

방법론은 표준 산출물 양식집?
필자가 최근 3년에 걸쳐 진행한 프로젝트 중에서 두 번은 방법론 담당자로 일했다. 두 차례 모두 표준 방법론을 갖고 있는 회사였다. 하지만, 흥미롭게도 가능하면 그대로 지키는 일은 피해달라고 했다. 현실과 맞지 않기 때문에 자사 표준이지만 가능하면 유연하게 해석해 달라고 했다. 시간과 노력을 들여 만든 방법론을 지키지 말라니 아이러니한 주문 아닌가? 하지만, 프로젝트 경험이 많은 베테랑이라면 입가에 미소를 머금으며 충분히 수긍할 수 있는 부분이다. 모든 상황에는 원인이 있는 법이다. 방법론을 거추장스러운 절차나 복잡한 문서양식 따위로 취급하는 경우는 왜 발생할까? 우선 방법론을 만든 후에 문자 그대로 고지식하게 적용하려고 했던 아픈 기억(?)탓일 수 있다. 개발방법론 도입 초창기에는 사용자가 방법론을 충분히 이해하지 못한 상태에서 곧이곧대로 따르던 시절이 있었다(필자 경력상 주로 객체지향 분석설계에 바탕을 둔 개발방법론 도입 시기에 국한한다). 시스템 개발과 동시에 팀원 다수가 방법론 훈련을 병행해 상당한 스트레스를 받았다고 할 수 있다.

개발방법론이 숨 쉬게 하기

개발방법론을 답답한 문서 안에서 숨도 못 쉬게 놓아두지 말고 현실과 만나게 하라. 현실과 만나야만 방법론이 숨을 쉰다. 현실은 방법론에 변화를 요구하는 다양한 변수를 갖고 있다. 어떤 변수가 있을까? 참여하는 사람만 놓고 봐도 일하는 방식을 바꿀 소지는 쉽게 찾을 수 있다. 일단 사람이 많아지면 모든 의사 소통을 구두로 할 수는 없다. 더구나 참여 기간이 달라지거나, 물리적으로 떨어진 공간에서 일하는 경우에 똑같이 일할 수 있을까? 또한, 숙련된 개발자와 그렇지 않은 개발자 모두에게 같은 방법을 고수하면 결과는 어떨까? 사람을 기준으로 얼핏 살펴보았지만, 개발하는 기능 개수, 사용하는 기술 플랫폼 종류, 계약이나 납품 절차 등을 하나하나 꺼내보면 변수는 매우 다양하다. 방법론을 프로젝트에 효과적으로 사용하기 위한 방법은 매우 간단하게도 정리할 수 있다. 방법론이 현실을 만나게 하라. 다시 말해, 널리 써라. 그리고 불편한 부분을 그냥 지나치지 말고 지속적으로 개선하라. 번거로운 부분은 과감하게 제거하거나 단순하게 하고, 모호한 부분은 분명하게 해둬라. 이 글의 이후 분량은 두 줄 남짓 정리한 비법을 실천할 수 있도록 경험을 담은 부연이다.

첫 단추는 개발 케이스 만들기

필자가 가장 익숙한 RUP에는 세 개의 케이스(Case)가 있다. 비즈니스 케이스(Business Case), 유스케이스(Use Case) 그리고 개발 케이스(Development Case)다. 비즈니스 케이스는 사업 수행을 다루고, 유스케이스는 시스템 사용 시나리오를 다루지만 모두 “어떻게 하겠다”는 내용을 정형화한다. 개발 케이스도 마찬가지로 어떻게 개발하겠다는 시나리오를 정의한다. 개발에 관한 모든 사항을 처음부터 모두 세세하게 정의하기는 힘들다. 기존에 정의한 방법론 내용이 있다면 큰 노력이 들지 않는 부분만 초기에 수정하고, 문제에 봉착했을 때 해당 부분을 수정한다. 개발 케이스를 어떤 형식으로 얼마나 상세하게 하느냐는 프로젝트마다 달리해야 한다. 하지만 개발 케이스를 집약해서 모두에게 누가 무슨 일을 하는지 알려야 한다. 그래야만 역할이 분명해지고, 필요한 사람을 찾을 수 있다. <그림1>에서 빈칸에 담당자를 명기하면 각 단계별로 산출물 작업 기준이 드러나고, 특정 업무에 따라 산출물 작성자를 한 눈에 볼 수 있다. 이러한 표를 만들어 공유하면 모호했던 역할과 서로 다르게 생각하고 있는 부분이 드러난다. 자연스레 이어지는 협의 과정에서 점차 역할과 책임이 명확해진다. 한 가지 팁이라면 프로젝트 규모가 커서 여러 장의 표를 작성해야 할 정도라면, 프로젝트 관리자는 대표자를 명기한 표만 활용하고, 상세 내용은 각 업무 단위로 관리를 위임한다.


방법론의 핵심은 R&R

예전에 어떤 개발자가 R&R이란 표현이 폼나게 여겨졌는지, 문맥에 관계없이 R&R이란 표현을 남발했다. 옆에서 보면서 드는 생각이 R&R이 폼나는 표현이 아니란 사실을 알기 전까지는 그 의미를 전혀 모르겠구나 싶었다. 그리고 어떤 관리자는 틈만 나면 R&R 따지지 말고 서로 도와가며 일하라고 말했다. 우습게도 그 말에 반박했던 필자 역시 얼마 후 다른 이에게 비슷한 말을 했다. 올해로 8년째 방법론과 직간접적으로 인연을 맺어왔다. 누군가에겐 우습게 들릴 수 있지만, 방법론에 대한 애증이 쌓였다. 요즘 누가 필자에게 방법론이 무어냐고 물으면, ‘방법론은 R&R이다.’라고 말해주고 싶다. R&R은 ‘Role and Responsibility’의 약자다. 우리말로 역할과 책임이다. 역할과 책임을 규정하지 않고 일하는 조직이 어디 있을까? 하지만, 방법론이 효과를 발휘하려면 R&R이 더 명확해야 한다. 마치 오랫동안 잘 돌아가는 프로그램을 만들려면, 함수 시그니처가 명확해야 하고, 컴포넌트 인터페이스 규약이 명확해야 하고, 계층(layer)간 주고받는 항목과 제약사항이 명확해야 하는 것과 같은 이치다. 산출물(deliverable)이라는 명확한 ‘부가가치’의 연쇄구조(chain)를 통해 최종 제품을 만든다. 마치 컨베이어 벨트처럼 방법론을 기계화 수준의 시스템으로 만들면 효율성은 극대화한다. 하지만 아쉽게도 아직 소프트웨어 개발에 있어서는 제조업의 노하우를 그대로 쓸 수는 없다. 개념적으로는 이미 오래 전에 소프트웨어 공장을 논했다. 하지만 산업 경계를 넘어가면 재해석을 해서 새로운 행동 계획(action plan)이 필요하다. 물리적으로는 하나의 산출물이라도 여기에 부여한 부가가치의 생산자는 다르다. 이를 명확하게 해야 효과를 내는 R&R 정립이다. 소프트웨어 설계를 고민하면서 동시에 혹은 번갈아 방법론을 고민하다 보면 무척 닮았음을 알 수 있다. R&R 정립이 가져오는 팀 협업 구도는 loosely-coupled로 불리는 시스템 연동 방식과 원리가 같다.


모호한 부분 구석구석 밝혀내기

규모를 막론하고 개발 프로젝트 초기에는 단계별 산출물을 기준으로 책임자를 명기해두고 합의를 이끄는 과정을 반드시 수행해야 한다. <그림1>의 표는 만들고 나면 매우 명확하지만, 앉은 자리에서 그냥 작성할 수 있는 내용이 아니다. 필자는 주로 외주 계약 기반인 SI 프로젝트에 컨설턴트로 참여하는데, 복잡한 하도급 계약을 고려하면 어떤 역할을 수행하는지 세부 사항은 매번 새로 정의해야한다. 대부분 기존에 해오던 방식을 선호하는 경향이 있어 필연적으로 갈등이 빚어지고, 노련한 개발자가 많으면 서로 자신에게 유리하게 협상하려 해서 설득과 조정 과정이 필요하다. 한편, 여러 업무나 여러 단위 시스템으로 구성된 프로젝트의 경우 역할이 상충하게 마련이다. 주고 받는 데이터가 발생하면 누가 전송을 책임지느냐 여부가 관건이다. 함께 쓰는 기능이 있다면 공통 기능 개발 주체가 초미의 관심사다. 항상 분명한 사실은 오래 끌어봐야 갈등만 커진다는 점이다. 가능한 빨리 문제를 이슈화해서 초반에 정리해야 한다.


프로젝트 초반에 이슈화하기

내포된 위험을 전혀 혹은 거의 모르고 있는 프로젝트 시작 초기에 노련한 프로젝트 관리자라면 마치 상처의 고름을 짜내듯 문제를 미연에 파헤치는 시도가 필요하다. RUP를 보면 프로젝트 관리자는 위험요소 목록(Risk List)을 도입단계(Inception Phase)부터 생성하고 관리한다. 보다 구체적으로는 비전문(Vision)으로부터 바로 위험을 식별하고 확인하라고 한다. 즉, 사업 계획서(Business Case) 작성 과정에서 이미 만들어져야 하는 것이다. 어찌 보면 당연한 이야기다. 프로젝트를 실패로 끌고 갈 수 있는 위험을 조기에 파악해 위험 관리 계획(Risk Management Plan)을 세우라는 것은 문자 그대로 너무나 당연한 말이다. 그러나 문제는 생각처럼 쉽게 그 모습을 드러내지 않는다. 명확해 보이는 문제는 누구나 이를 알고 있기 때문에 설사 프로젝트에 미치는 영향력이 지대하다고 하더라도 덜 위험하다. 오히려 진짜 큰 위험요소들은 쉽게 눈에 띄지 않는 것들이다. 삼국지류의 책에서 대패하는 경우는 뜻하지 않던 습격에 당하는 경우가 많다. 너무나 당연하게 수행되리라고 믿었던 일들이 되지 않을 때, 이를 고칠 수 있을 시점이 훨씬 지나서 문제를 알게 된다면 경우에 따라서는 그간의 산출물이 모두 쓸모 없어진다.

예를 들어 요구사항의 원천인 고객과 분석가가 서로 다르게 인식하고 있다고 해보자. 또한, 고객 입장에서 아직 결정되지 않은 요소가 너무 많아서 분석가에게 충분한 흐름을 제시할 수 없다. 언제 결정될지 모르는 사항을 무작정 기다리는 대신에 분석가가 나름의 시나리오를 기술해 고객에게 의견을 제시했다. 이때, 고객이 요구사항 기술 방식이 생소해 가령, 기본 흐름과 대안 흐름으로 시나리오를 기술하는 유스케이스 명세가 익숙지 않아서 내용 파악을 어려워한다거나 검토를 꺼린다. 고객은 요구사항 정의 내역을 검토해야 하는 것을 알지만 위와 같은 문제로 검토를 차일피일 미루고 또한 본연의 업무가 있기 때문에 요구사항에 대한 검증이 이뤄지지 않은 채 시간은 계속 흘러간다. 이보다 더 심한 문제는 고객이 마치 검토를 충분히 한 것처럼 인지될 때이다. 사실 이런 문제는 모든 프로젝트가 갖고 있는 가장 큰 위험요소 중에 하나이다. 다만, 이렇게 명백해 보이는 문제마저 실제 프로젝트에서는 다양한 양상으로 벌어지기 때문에 이를 잡아내서 의사소통 경로나 방식의 문제를 해결하기 쉽지는 않다. 적어도 필자가 경험한 모든 프로젝트에서 가장 큰 문제는 의사소통 경로나 방식에서 나왔다. 프로젝트 초기에 의사소통을 원활히 할 수 있는 환경을 만들어내는 일은 무척 중요하다. 그렇게 하기 위해서 프로젝트에 영향력이 큰 인물을 찾아내고 그 힘을 적절히 활용하라. 주요 실무자를 확실한 우군(?)으로 만드는 일과 정보가 물 흐르듯 소통할 수 있게 하는 일은 너무나 중요하다. 예전에 PM만 8년 하셨다는 분이 프로젝트 관리는 한 마디로 ‘정치’라고 단언했던 말이 떠오른다.


실행 능력 키우기 

단조로움을 피하기 위해 잠시 다른 이야기를 해보겠다. 한일월드컵 4강 신화를 이뤄낸 거스 히딩크 등장 이전에 국가대표는 4(four)백을 잘 쓰지 않았다. 4백이란 수비수 네 명이 일렬로 서서 수비 라인을 구축하는 전형을 말한다. 4백 대신 중앙 수비수 세 명을 두는 3(three)백 시스템을 썼다. 당시 선진 축구 흐름은 전원공격과 전원수비를 함께 하는 이른바 ‘토탈사커’였다. 토탈사커를 구사할 때 4백을 구성하는 측면 수비수 2명은 특히 중요한 역할을 했다. 기본적인 위치는 좌우 측면 수비이지만, 공격할 때는 공을 갖고 상대편 깊숙이 침투해 크로스를 올리는 역할을 맡았다. 따라서, 공수 양면에서 탁월한 능력과 함께 기동력, 그리고 강한 체력을 요구했다. 동시에 중앙 수비수는 역습 상황에서 둘이서 최후방을 책임져야 하기 때문에 강력한 대인 마크 능력을 요구했다. 당시 우리나라는 홍명보와 짝을 이룰 중앙 수비수 재목이 약했고, 측면 침투와 수비를 책임질 측면 수비수 재목이 없었다. 히딩크는 어떻게 4백을 도입할 수 있었을까? 히딩크 역시 처음부터 4백을 고집하지 않았다. 월드컵 본선 직전까지 3백과 4백을 함께 사용하다가 끝내 본선에서 주요 경기에 4백을 사용했다. 이를 가능하게 한 힘은 극한에 이르는 체력훈련이다. 히딩크가 수행한 체력훈련을 빼고 4백(4-3-3) 도입을 논하는 일은 무의미하다.

필자가 히딩크의 접근방식을 꺼내놓은 이유는 방법론 적용에 대해서도 마찬가지의 노력이 필요하기 때문이다.

실행 능력을 키우는 코치
지난 해 바쁜 시간을 쪼개서 ‘소트웍스 앤솔러지: 소프트웨어 기술과 혁신에 관한 에세이’ 번역에 참여했다. 번역 작업은 처음이었지만, 7장 ‘반복 관리자’ 내용이 무척 실무적인 터라 번역 요청에 응했다. 때마침 프로젝트 관리를 하고 있었고, 소수의 팀원에 비해 개발 물량이 무척 많아 애자일 방법론을 채택한 상황이기도 했다. 책 내용 일부를 소개하면, 반복 관리자가 팀이 일정을 지키게 하기 위해 다음과 같은 질문을 하라고 한다.

- 개발자가 자신이 맡은 스토리 범위를 이해하고 있는가?
- 애초 예측 이후 스토리 작업에 변경이 있었는가? 그렇다면, 어떻게 변했는가?
- 개발자가 해당 스토리가 목표로 하는 상태에 대해 더 잘 이해하기 위해 업무 분석가나 고객 도움이 필요한가?
- 개발자에게 선임 개발자 도움이 필요한가?
- 개발자의 스토리 완수에 장애가 있는가? 가령 하드웨어, 소프트웨어 또는 기반구조 문제가 있는가?
- 개발자가 다른 프로젝트에도 참여하고 있거나 스토리 완수를 위해 지나치게 많은 잡다한 회의까지 참석하고 있지 않는가?

필자는 번역을 수행할 당시, 스스로 뽑은 최고의 팀원으로 프로젝트 관리를 수행하고 있었다. 하지만, 기대만큼 좋은 결과를 내지 못했다. 얼마간의 시행착오를 겪은 이후에 필자는 팀원의 작업 내용에 직접 개입하기보다는 위 질문과 같은 내용으로 도움을 주려고 노력했다. 스스로 해결할 수 없는 문제는 빨리 도움을 요청하도록 유도했고, 회의는 주로 관리자인 내가 전담하면서 검토를 수행할 경우에 한해서 개발 담당자를 참여시켰다. 또 가장 중요한 점은 스스로 자신의 작업 계획을 수립하게 한 것이다. 약 4개월 동안은 주마다 계획을 하고, 매일 아침 진척을 보고하게 했다. 주단위로 보면 늘 조금은 지연(기능을 완료한 경우에도 주석이나 도움말이 빠졌거나 단위 테스트가 없었다)이 있었고, 매일 아침 물어봐야 며칠 동안 같은 작업을 진행 중이라고 답했다. 속으로 답답했지만, 인내심을 가지고 기다렸다. 매번 반복해서 가능한 일을 잘게 나누어 보고하라고만 요청했다. 놀랍게도 4개월 이후부터는 하루 단위 작업 추정이 가능했다. 주 단위로는 거의 모든 팀원이 자신의 말을 지켰다. 처음에는 상상도 못할 작업 측정과 관리가 가능했다.

거스 히딩크가 했던 일도 이와 비슷한 일종의 코치가 아니었을까? 반복 관리자는 애자일 코치(agile coach)라고 부르기도 한다. 갑자기 방법론 이야기하다 말고 왜 애자일 코치 이야기를 꺼냈을까? 앞서 이야기했지만, 기초체력훈련 없이 4백은 불가능하다. 최소한의 체력이나 개인기가 없는데 마법 같은 부분전술이나 훌륭한 전략을 소화할 수는 없다. 마찬가지로 효과적인 방법론 적용을 위해 팀원의 기본 역량 강화는 필수다(아쉽게도 프로젝트 동안만 만나는 팀원이라면 ROI는 장담할 수 없겠다).

팀워크 빌딩

축구팀이나 개발팀이나 팀워크는 중요하다. 축구는 11명이 하지만, 개발팀 구성원 숫자는 이보다 많을 수 있다. 특히, 방법론을 도입하는 프로젝트는 수 십, 수 백명인 경우가 많다. 숫자가 늘면 팀워크를 갖추기는 더욱 어렵다. 더구나 서로 다른 회사에 속한 팀원을 모아놓았을 때 이들을 진정한 팀으로 만드는 일은 과연 가능할까 싶을 정도로 힘들다. 대규모 프로젝트에서는 팀워크를 위해 워크샵을 가기도 하고 몇 차례 회식을 한다. 얼마나 효과가 있을지는 의문이다. 함께 일하는 빈도가 높은 팀원 사이에서라면 필자가 했던 다음과 같은 시도를 한번쯤 권해보고 싶다. 필자는 함께 일하는 팀원을 불러다 놓고 자신과 관계된 담당자와 산출물을 표기한 후 관계를 그려보라고 했다. 훈련된 팀이어서 산출물을 빠뜨리는 경우는 없었지만, 다른 사람과의 관계는 팀원 대부분이 빠뜨리고 그렸다. 놀라운 점은 서로가 그린 그림을 공유하는 정도만으로도 팀워크 개선이 있었다는 점이다. 보지 못하던 부분이 드러난 이후에는 굳이 계속해서 지적하지 않아도 새로 인지한 부분을 고려해서 작업했다.
획일화의 함정에 빠지지 말라

지금까지는 사람에 초점을 맞췄는데 세부적으로 들어가면 방법론은 각종 산출물 작성법을 포함한다. 종종 방법론과 표준 양식을 대등하게 생각하는 사람도 있다. 올바른 판단은 아니지만, 그만큼 표준 양식은 모두가 명확히 인지하고 필요로 한다. 문서 작성 방식이 명확하다면 작성도 편하지만, 읽기에도 좋다. 그러나, 프로젝트가 커지면 지나치게 관리 편의성을 내세우기도 한다. 지나치게 일관성을 강조하면 획일화의 함정에 빠질 수 있다. 대규모 프로젝트에서 프로그램 식별자(ID)는 여러 가지 용도로 쓰인다. 사업 관리 측면에서 진척 관리 기준으로 쓰이기도 하고, 설계자, 개발자 및 테스트 담당자가 작업 항목을 식별하고 서로 추적할 용도로 쓰기도 한다. 수많은 프로그램 가운데서 일관성을 부여하기 위해 대개는 다양한 약어와 일련번호를 조합한 이름을 지정한다. 그러나, 프로그램 내부의 변수에까지 모두 동일한 체계를 부여해 프로그램을 암호처럼 만드는 경우를 종종 목격할 수 있다. 산출물 특성을 무시하고 모두 똑같이 처리하려고 시도한 탓이다. 엑셀 문서에서 특정 프로그램을 지칭하기 위해 ‘IF-CMD-001’과 같은 식별자를 쓰는 일은 긴 이름에 비해 효율적일 수 있다. 하지만 프로그램 이름을 ‘IF-CMD-001.java’ 혹은 ‘IF-CMD-001.jsp’ 라고 만드는 일은 과연 적절할까(물론, 암호와 같은 작명 체계를 고객의 기존 시스템에서 오랫동안 사용했다면, 이미 의미 있는 관행이기 때문에 준수해야 할 수도 있다)? 비슷한 획일화 함정의 예로 ‘유스케이스 크기 기준’을 들 수 있다.


유스케이스 크기 기준

유스케이스 크기에 대한 이슈(http://cavin.egloos.com/4869054)는 억지로 유스케이스를 콘트롤(control)이나 설계요소와 일정규칙으로 연관 지으려는 경향에서 발생한다. 이는 유스케이스를 소프트웨어 설계원리로 오인하면서 발생하는 대표적인 오해이다. 유스케이스 모델링 책에서 동일한 크기를 강조한 데에서 비롯된 잘못된 양상이라 할 수 있다. 실제로 일정한 크기를 갖고 한 사람이 모델링하는 것을 베스트로 추천하곤 한다. 유스케이스는 전달자와 수집자간에 요구사항에 대한 본인들의 관심사를 담아 다른 사람과 소통하기 위한 ‘스케치’다. 비즈니스 특성이 다르고 각각의 관심사가 다르기 때문에 일정 크기로 수렴하는 것은 전혀 의미가 없다. 일정한 크기로 강제하다 보니 유스케이스가 1,000개 단위로 나오는 어이없는 사태가 발생하기도 한다. 요구사항이 조밀한 수준에서 높은 가치를 갖는 비즈니스가 있고 반대로 큰 수준에서 가치를 갖는 비즈니스도 있다. 전자와 같은 비즈니스에 대해 유스케이스 크기 기준을 들이미는 것은 입도가 조밀한 수준의 관심사를 더 큰 크기로 나타내고 소통하라는 얘기가 된다. 원자에 대한 커뮤니케이션이 필요한데 분자크기로 요건을 작성하라는 얘기이다. 말도 안 된다. 비즈니스 특성도, 개개인의 관심사도 다르니 크기에 대한 ‘정답’도 없는 것이 당연하다. <중략> 유스케이스는 커뮤니케이션 도구다. 고객과 협업하는 사람들, 그리고 자신을 포함한 모두의 커뮤니케이션이 가장 큰 목적이다.


프로세스 최적화와 도구의 적용
산출물 형식뿐 아니라 용도와 상황에 부합하게 산출물 작성 프로세스를 최적화한다. 산출물 작성 프로세스의 경우에도 <그림 4와> 같이 시각화해 공유해야 한다. 누가 무엇을 하고, 이어지는 작업은 무엇인지, 관련자나 관련 시스템은 무엇인지 명확하게 해서 혼선을 없애야 한다.

프로세스가 복잡해지면, 단순화를 위해 시스템 도입을 고려해야 한다. 최근에 다양한 협업 도구가 오픈소스로 개발하고 쓰여지고 있다. 필자가 수행하는 최근 프로젝트에서는 사용하는 형상관리 도구(Subversion, Subversive), 작업관리 도구(Redmine, Eclipse Mylyn), 결함관리 도구(Redmine), 빌드 및 테스트 자동화 도구(Ant, Hudson) 등은 모두 무료로 사용할 수 있는 오픈소스 도구이다.

의사소통을 문서로만 관리할 때보다 도구를 도입하면 효율적이지만, 소수 관리자의 관리 편의성이나 도구에 대한 거부감으로 문서를 고집하는 경우도 있다. 명심하라. 개발 프로젝트에서 최종 산출물은 소스 코드다. 그 이전에 만들어지는 수많은 문서는 결국 중간 결과를 담는 그릇이다. 의사결정 사항을 알려 오류를 찾아내고, 누락시킨 요구사항을 다시 수렴하고, 다음 단계로 진화하고, 필요하다면 변경을 수행하기 위한 정보 전달에 사용한다. 목적에 부합하는 수단과 방법을 쓰고 있는지 항상 고민해야 한다.

생생하게 유지하기
얼마 전 모회사에서 꽤 잘 만든 조직 표준 체계를 열람했다. 2년 전에 만든 것인데, 내용이 그대로였다. 만들기는 잘했지만, 널리 쓰이지는 않았구나 짐작했다. 널리 쓰이지 않는다면, 그리고 상황에 맞게 옷을 갈아입지 않는다면 가치가 있을까? 방법론 무용론도 같은 맥락이 아닐까? 아무리 욕을 해도 마구잡이 개발보다 나쁜 방법론은 없다. 방법론이 쓸모가 없다고 생각한다면 자신이 제대로 활용하고 있는가 돌아보자.





     개발 방법론, 개발자, 마소, 마이크로소프트웨어, 블로그, 안영회, 월간 마소, 히딩크
     0   
BlogIcon 소리바람 2009.11.23 11:53 신고
IT개발에 지대한 영향을 끼친 것은 건축공학이라는고 알고 있습니다. 그 영향으로 용어가 그대로 차용되고 있지요. 그러나, 용어가 같다고 그것을 받아들이는 사람에게 IT의 개발이라는 것이 건축과 같이 단계단계 바로 눈으로 확인이 되는 것이 아니라는 것이 IT개발방법론이 무수히 변형/생성되는 원인이라고 봅니다.(건축공학에서도 새로운 시도를 많이 하고 있지만.)
결론적으로 말씀을 드리면, IT개발뿐만 아니지만 개발 그 자체가 중심이 아닌 그것을 주도하고 사용하는 사람이 중심이라는 겁니다. 그 많은 방법론의 목적은 원하는 결과물이 잘 나오느가에 따라 생명 연장를 받는다고 봅니다.

저의 경험으로,
1. 갑과 을의 입장을 없애라. 다만, 공동의 목표를 향한 파트너만 있을 뿐이다.
2. 정치가 아닌, 정직히 확실히 커뮤니케이션을 원활히 하라.
3. 에러 발생과 원인도 공유할 수 있도록 시스템을 도입하라.
4. 마일스톤을 지켜라. 그리고 요구사항 추가나 변경이 필요하면 기간연장과 비용발생에 대해서 확실히 정하라.
5. 초기에 위의 사항들을 반영한 개발계획서과 계약서를 작성하라.
BlogIcon 소리바람 2009.11.23 12:02 신고
위에 조금은 이상적인 내용을 적었지만, 사람 사는 세상아니겠습니까. 아깐의 의사소통이 있어도 영향을 받을 수 밖에 없지요.

커뮤니케이션을 잘하는 것도 PM만의 몫이 아닌, 개발자들도 잘 해야 한다고 봅니다.
특히, SI쪽은 새로운 기술의 시도보다는 기존의 안전하고 검증된 시스템을 구성하는 것이 프로젝트의 목표가 되는 것이 많았다고 봅니다. 그리고, 기존 애플리케이션 개발자들이 SI에 적응 못하는 경우도 많이 보아왔습니다.(나름 기술에 집착 아니 아집에 가까운 장인정신?)
그런 문제에 대해서 PM이 잘 조절하고 개발자의 재능도 함께 키워나가는 것이 필요하다고 봅니다.
(PM은 발바닥에 무좀도 생기지 않을 정도로 열심히 뛰어다녀야 한다는...것이 되겠지요.)
BlogIcon 소리바람 2009.11.23 12:19 신고
참고로,
저의 경우는 소스명은 개발자들을 위한 코딩규약을 정해서 임의의 숫자 조함이 아닌, 개발자 전체가 이해할 수 있는 이름으로 정합니다. 물론, 들여쓰기, 주석양식, doxygen를 위한 주석, 클래스명명 등등.
위에 'IF-CMD-001.java'는 지양해야 할 명명이라고 생각이 듭니다. 담당 개발자가 봐서 바로 알 수 없는 것은 관리 이외에 의미가 없다고 봅니다.(ex. CCmdServerToClent.java 서버에서 클라이언트으로 명령어를 보내는 클래스: 알기 쉽지요. 길어도 바로 알 수 있는 이름이 좋습니다.)

이와 반대로 개발문서는 화일명을 중앙집중 관리를 하는 편이 좋다고 봅니다.
예로, 하나의 엑세스 화일에서 열람해서 접근 가능하도록 구성하거나, 웹페이지에서 바로 볼 수 있도록 한다든지.
고객뿐만 아니라 개발자들도 바로 사양을 확인할 수 있는 시스템의 도입이 반드시 필요로 합니다. 그리고, 변경/수정된 내용을 메일등으로 알려 주어서 사양반영에 누락이 없도록 해야 합니다. 또한 책임소재를 분명이 할 수 있는 문서마다 로그 페이지를 넣는 것도 빠질 수 없지요.

이 모든 것이 의사소통의 원할함을 위한 것임을 언제나 상기해야 성공적인 프로젝트가 되겠지요.

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

애자일 프랙티스의 실제 활용사례
+   [마이크로소프트웨어]   |  2009. 2. 18. 09:38  




애자일 방법론을 공부하거나 실무에 적용하려고 노력하는 분들은 많지만

막상 우리나라의 정서나 실무 환경에서 적용해서 성공을 거두기란 참 어려운 일입니다.

오늘은 한국 스프링 유저 그룹 KSUG 와 블로그 http://www.younghoe.info/를 운영하고 있는

안영회 님이 자실의 활용 사례를 기반으로 마이크로소프트웨어에 기고해 주신 내용을 옮겨봅니다.

애자일 방법론에 관심있는 개발자 분들께 도움 되시길 바라며

아이마소 홈페이지에 더 유익하고 재미있는 자료들이 많다는 점 참고해 주시길... ^-^*

국내 SI 프로젝트 현장에서는 문화적인 요소 때문에 애자일 방법론 보급이 힘들다는 얘기를 종종 듣는다. 애자일 방법론 도입을 통해 이미 구축한 기존의 방법론을 대치하거나 지금까지 해오던 방식을 완전히 바꿔버리겠다는 발상은 오히려 애자일(?)하지 못하다. 필자는 애자일 방법론이나 프랙티스 전문가는 아니지만, 현장에서 애자일 프랙티스(Agile Practices)를 적절히 적용하여 효과를 보았다. 실제 사례를 널리 알려 현장에서 소프트웨어 구축에 힘쓰는 이들에게 작은 영감이라도 주고자 이 글을 쓴다.


안 영 회 ahnyounghoe@gmail.com | ㈜ITwise 컨설팅에서 소프트웨어 공학 컨설턴트로 일하고 있다. 지난 2005년 국내 대규모 프로젝트에 스프링 프레임워크 적용을 성공한 이후 한국스프링사용자모임(KSUG)을 만들어 운영하고 있기도 하다. Younghoe.info 블로그를 통해 자신의 경험을 공유하고 있다.

프로젝트 제안 단계에서 애자일 방법론을 채택한 이유는 프로젝트 특성 때문이다. 프로젝트 팀원의 숫자는 적은데 반해, 개발 범위는 다소 무리가 아닌가 싶은 수준이었다. 이런 가운데 국내 SI에서 주류로 채택하는 CBD 방법론은 많은 산출물을 요구하기 때문에, 애자일 방법론의 하나인 스크럼(Scrum)을 선정했다. 다만, 산출물 명칭과 양식만 기존 SI 프로젝트의 형식과 유사하게 수정하여, 새로운 방법론 도입에 따른 거부감을 최소화하려고 노력했다. 프로젝트 착수 이후 3.5개월여 시간이 흐른 지금 프로젝트 양상은 애초에 예상했던 것보다 바람직한 모습으로 진행되고 있다.

아직 두 달여 시간이 남은 시점에서 성공을 운운하는 것은 성급한 일이지만, 애자일 소프트웨어 개발(Agile Software Development) 적용만 놓고 보면 분명 성공적이었다. 이 글에서는 성공적이었다고 스스로 평하는 내용들에 대해서 살펴보고자 한다. 그러나 다른 프로젝트에서도 보편적으로 적용하기 위한 일반화를 시도하는 것은 아니며, 애자일 소프트웨어 개발이 지향하는 원칙에 입각해서 어떻게 해법을 찾았는지 그 과정을 공유하려는 것이 이 글의 목적이다.

애자일 선언

이 글에서는 애자일 소프트웨어 개발 혹은 애자일 방법론 자체에 대해 설명하지는 않을 것이다. 실제로 스크럼(Scrum)을 채택했다고는 하나, 이미 필자는 RUP(Rational Unified Process) 류의 방법론에 익숙해 있고, 스크럼 자체에 대한 필요 이상의 학습비용을 지불할 생각이 없다. 그보다는 과거의 프로젝트 수행 경험에 비춰볼 때 애자일 선언(Agile Manifesto, http://www.agilemanifesto.org/)은 매우 공감하는 가치 기준을 제시해 주었고, 이를 현장에서 활용하고자 했다. 애자일 선언에서는 소프트웨어 개발 방식에 있어 대비되는 가치를 기준으로 추구하는 바를 정의한다.

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

각 항목에 대한 내용을 여기서 설명하기보다 사례와 함께 이야기하도록 하겠다.

프로젝트 단계

프로젝트는 도입, 구축 및 이행의 3단계로 나누어 진행하고 있다. 아직 이행 단계를 수행하지 않은 시점이라 도입과 구축 단계에 대해 사례를 짚어본다. 각 단계별로 애자일 선언의 가치 기준을 기초로 애자일 프랙티스 적용이 종래의 경험에 비해 어떠한 개선을 가져왔는지 살펴보자. 사전 정의 없이 애자일 프랙티스라는 말을 사용했는데, 앞으로 ‘애자일 선언의 가치에 준하는 문제 해결책’을 애자일 프랙티스라고 지칭하겠다. 

도입 단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 초반 4주에 해당한다. 프로젝트 범위를 결정하는 기간인데, 이때 가장 초점을 맞춘 부분은 실현 가능한 계획 수립과 요구사항의 확정이다. 여기까지는 사실 애자일 소프트웨어 개발이 어떤 도움을 주었는지 살펴보자. 자, 이제 애자일 선언의 가치 기준이 등장할 시간이다.

● 변화를 수용할 수 있는 계획을 세운다 - Responding to change over following a plan

애자일 선언에서는 계획을 따르는 것도 가치가 있지만, 그보다는 변화에 대한 적응에 더 높은 가치를 부여한다고 강조한다. 필자가 앞서 참여한 대부분의 프로젝트에서는 WBS를 작성하는 데 많은 공수를 소요했다. 고객과 개발팀은 WBS를 PMS 등을 이용하여 공유하고, WBS 상의 계획을 기준으로 진척을 산정했다. 프로젝트가 새로운 업무나 기술을 다룰수록,  그리고 규모가 클수록 더 많은 변화의 가능성을 내포하고 있다. 하지만 대개의 경우 조기에 수립한 계획을 변경하는 일은 무척 번거로운 과정을 거쳐야 했다.

우리 프로젝트의 경우도 단위 시스템 개발이 아닌 플랫폼 성격의 제품 개발이기 때문에 전략적 결정에 의해 요구사항 변경의 여지가 많다. 또한 고객 스스로도 필요한지 확신을 갖지 못하는 요구사항에 대해서도 유리한 고지를 점하기 위해 계약에 명시하고 있었다. 이와 같이 변경 가능성을 내포하고 있는 항목을 기준으로 계획을 수립한다면, 계획 변경의 여지가 많아진다. 이런 경우 먼저 변경할 수 있는 것과 할 수 없는 것을 구분해야 한다. 가장 먼저 고객사의 WBS 양식과 샘플을 구했다. 계획 사항 중에서 내규에 따라 진척 평가가 어떻게 이루어지는지 파악했다. 이를 기준으로 특정 단계까지는 가중치를 고정하고, 해당 단계 하위의 작업 항목에 대해서는 변경하여도 진척 평가에 영향을 미치지는 않게 했다.


<화면 1>에서 우측 음영 처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입 단계에서 고정해 두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다. 

● 소프트웨어에 집중하라 - Working software over comprehensive documentation

현장에서 종종 지나치게 상세한 명세 작업 혹은 표준화 및 기법에만 초점을 맞춘 요구사항 모델링으로 비생산적인 분석 작업을 하는 것을 경험한다. 종국의 결과물은 작동하는 소프트웨어란 사실을 잊지 말아야 한다. 도입 단계에서 모호한 요구사항을 밝혀내는 일은 쉽지 않았다. 고객들마저 정확하게 무엇이 필요한지 모르는 상황이기 때문이다. 조기에 확정하기 어려운 것을 정하는 데 지나치게 시간을 투여할 우려가 있어 명세 자체보다는 요구사항 충족 기준이 되는 검증 기준 수립에 초점을 두었고 이는 <표 1>에서 보는 바와 같다. 이로써 약 10주 후에 소프트웨어를 구현했을 때 사용할 지표를 2주 만에 만들 수 있었다. 앞서 말했던 것처럼 무리한 듯 보이는 개발 범위에도 불구하고, 10주 후 70개의 모든 기준을 충족시킬 수 있었던 요인 중에 하나는 ‘5대1’ 비율, 즉 ‘요구사항 정의 2주 대 소프트웨어 개발10주’에 있다.




구축단계에서의 애자일 프랙티스

도입 단계는 전체 26주의 기간 중에서 중반 15주에 해당한다. 실제 제품 개발의 대부분을 수행하는 단계이다. 애자일 프랙티스를 도입했을 때 구축 단계의 가장 두드러진 특징 중 하나는 조기에 통합이 이뤄진다는 점이다. 이는 이행 단계의 부담을 한결 줄여준다. 결론부터 말하자면 조기 통합 및 상시 통합 수행은 구축단계에서 빠른 피드백과 팀 협력을 가속화하는 효과를 가져왔고, 이행 단계로 연착륙할 수 있게 하는 데 큰 공헌을 했다. 

● CI 적용 과정에서 배운 협업의 가치 - Individuals and interactions over processes and tools

프로젝트 초기에 필자는 툴과 프로세스에 초점을 맞춰 환경을 잘 구비하고 단위테스트만 잘 실시하면 CI(Continuous Integration), 다시 말해 지속적인 통합이 가능할 것이라고 보았다. 그러나 툴의 이점은 분명히 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트 처음으로 손발을 맞춘 팀이었고, 당연히 프로세스가 몸에 밴 팀은 아니었다. 또한 프로젝트 일정 역시 프로세스를 익힐 만큼 여유 있지는 않았다. 여기서 필자는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 프로젝트를 하면서 종종 그 사실을 잊어버리지만, 우린 모두 개성을 지닌 존재이다.


우선 각자 자신이 만들어야 할 산출물을, 그리고 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 필자는 이를 문맥도(context diagram)라 칭하고 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 관리자인 필자와는 달리, 대부분의 사람들이 주변 개발자와의 관계를 완벽하게 알지 못했다. 필자는 그 부분을 찾아서 그려주었다. 이후에 팀원 개인과 서로가 맺고 있는 관계(Individuals and interactions)가 정형화된 부분에 대해서만, 이를 프로세스로 정의해 공유했다.
문맥도를 그려보기 이전에는 팀원들이 자신의 작업에만 관심을 둔다고 오해했다. 팀원들은 다른 팀원의 일에 관심이 없었던 것이 아니었다. 전체를 볼 수 있는 사람이 서로 협력이 필요함을 알게만 해준다면 문제는 스스로 해결되었다.

● 고객과 마치 하나의 팀처럼 협력하라 - Customer collaboration over contract negotiation

프로젝트에 잔뼈가 굵은 사람이라면 ‘계약서’, ‘날인한 회의록’, ‘명세서’ 등을 중요하게 취급한다. 하지만 분쟁이 발생했을 때 이들이 개발팀을 유리한 입장에 놓을 수 있을지 몰라도, 그 이상의 가치는 없다. 구축 기간 초반에 앞서 언급한 것처럼, 70개의 기준을 충족했을 때 고객과 개발팀 사이에 신뢰 관계가 형성됐다. 신뢰 관계는 고객과 사전 협의한 사항에 대한 변경이 용이해졌음을 의미한다. 개발팀은 애초부터 지나치게 기술적인 어려움을 의식해서 요구사항 수용을 거부할 필요가 사라졌다. 고객은 언제든지 개발팀의 입장을 이해할 준비가 되어 있었다. 개발팀은 신뢰를 깨뜨리는 우를 범하지 않는 이상 계약관계에 입각해 서로를 인식하는 데 에너지를 쏟는 대신에 본연의 활동 즉, 개발에 대해 집중할 수 있었다. 자신감을 얻은 우리는 고객의 요구사항 수집에 있어서도 장벽을 제거했다.

우리는 <화면 3>과 같이 개발도구에서 작업목록을 볼 수 있는 환경을 구축하고 있는데, 고객이 직접 올린 요청사항을 작업목록에 포함시켰다. 고객 요청의 즉각적인 수렴과 기민한 커뮤니케이션은 고객의 개발팀에 대한 신뢰감을 더욱 높여주었다. 종국에 고객과 개발팀의 협력은 마치 오랫동안 함께 해온 조직 구성원의 일상적인 협력을 보는 듯했다. 물론 이러한 협력을 모든 프로젝트에서 실현할 수 있다고 할 순 없을 것이다. 착수 보고 때 프로젝트 스폰서인 임원이 ‘고객’이라는 말에 대해 거부감을 표시하며, ‘어차피 같이 일하는 사람인데 고객은 무슨’이라며 호칭을 나무랐다. 고객들은 향후 인수인계와 기술 이전을 받는 데 매우 적극적이었기 때문에 고객과 마치 한 조직 내에 속한 다른 팀처럼 일할 수 있었다.




경험의 산물, 애자일 프랙티스

애자일 프랙티스는 SI 개발 환경에서 오랜 논의 끝에 나온 경험의 산물이다. 연구소나 학계에서 나온 것이 아니란 점에서 ‘새로운 방법론의 하나’로 취급하는 것은 실용적이지 않다. 오히려 현재 사용하는 혹은 익숙한 방법론이나 개발 프로세스를 사용하면서도 단계적으로 애자일 프렉티스를 충분히 적용할 수 있다. 이 글은 이에 대한 하나의 사례를 제공함으로 해서 현장에 응용하기 위한 논의의 단초를 제공하는 데 의미를 지닌다.

 

<프로젝트 수행 과정에서의 갈등 그리고 조화>

나이가 들수록 조화와 균형을 배운다. 어릴 때는 ‘이것이 옳다’ 싶은 것에 대해선 물러서지 않았다. 다른 사람과 어울림을 통해 다른 생각이 있다는 것을 배우고, 점차 나를 둘러싼 주변과의 어울림을 받아들인다. 어떤 이는 이를 세상과 타협하는 것이라 하지만, 조화를 이루기 위해 나와 생각이 다른 사람과 타협할 뿐이다. 프로젝트를 수행하다 보면 필연적으로 많은 변수를 맞이한다. 참여하기로 했던 개발자가 불가피한 이유로 참여를 못할 수도 있다. 다른 업체나 부서의 사정으로 장비 구매가 늦을 수도 있다. 더러는 가장 중요한 협업 담당자가 장기 출장을 가버리기도 한다. 어디 이런 일이 한 두 가지뿐이겠는가? 흔히 발생하는 경우는 아니지만, 개발 도중에 법이 바뀌거나 고객 조직의 대대적인 인사이동으로 인해 프로젝트 자체가 위기에 몰리기도 한다. 만일 프로젝트 초반에 구체적으로 일정을 수립했다고 했을 때, 앞서 언급한 일이 벌어져도 이를 완벽하게 맞출 수가 있을까?

또뜨웍스(ThoughtWorks)사의 직원들이 출간한 책 “The Thought Works Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)”의 7장에서 의사결정의 적기에 대해 이야기하는 부분은 이 문제에 대해 훌륭한 영감을 준다.

많은 사람들이 불확실한 것을 미리 분명하게 계획해 두려는 경향이 있다. 하지만 예측이 힘든 일은 너무나도 많을 뿐더러 판단에 필요한 정보를 충분히 수집한 후에 결정해야 실행에 옮기기 쉽다. 필자는 일년 단위로 업무 성과를 측정하는 기업에서 발주한 프로젝트에 참여한 바 있다. 담당 부서에서는 프로젝트 진척을 자신들이 해오던 식으로 파악하고자 했다. 그래서 매 2주마다 진척 산정이 가능한 작업을 계획해주길 원했고, 가능하다면 모든 작업은 고유한 산출물을 제출해주길 원했다. 그런데 우리 프로젝트는 요구사항에 대한 가변성이 너무 높았다. 우리는 이미 수십여 개의 기능 목록을 달성한 프로젝트를 수행한 이후였다. 고객은 우리가 만든 제품을 특정 프로젝트마다 필요한 다양한 기능을 추가하기 위해 좀 더 튜닝해주길 원했다. 하지만 우리 제품을 채택한 프로젝트의 요구에 따라 작업 내용은 달라질 수밖에 없었다. 물론 사전에 요구사항을 정하면 되겠지만, 고객들은 해당 시점에 결정하길 원했다. 이런 경우 우리는 어떻게 가변적인 요소를 수용하면서 해당 기업의 평가 방식에 부합하는 계획을 만들 수 있을까?

우리는 나름의 답을 찾았다. 그것은 어디에나 적용할 수 있는 답은 아니고, 만들어낸 과정조차 명확하지 않다. 필자는 개발팀을 대표하여, 해당 부서 책임자와 함께 평가조직 담당자를 만나 머리를 싸매 협의했다. 그리고 또 다른 실무자들과 머리를 맞대어 논의한 후, 부족하게라도 합의한 것을 메모로 정리했다. 이를 기초로 초안을 계획하고, 다시 해당 부서 책임자와 검토했다. 그는 다시 스스로 이를 정제한 후에 검토를 요청했고, 수일 후에는 앞서 협의에 참여한 이해관계자가 고개를 끄덕일만한 계획표를 만들어냈다. ‘조화’라는 말은 듣기에 좋다. 하지만 조화를 이뤄낸 과정을 들어다 보면, 이와 같이 끈질긴 갈등과 타협으로 이루어진다.





     KSUG, MSW, SI프로젝트, 개발자, 마소, 마이크로소프트웨어, 스프링, 스프링프레임워크, 아이마소, 안영회, 애자일, 애자일 프랙티스, 월간마소, 한국스프링사용자모임, 호랭이
     1   
BlogIcon okgosu 2009.02.20 11:40 신고
잘 보고갑니다
실제는 방법론보다는 고객의 요구사항이 더 애자일해서리...
개발자들이 늘 밤새며 고생하지요....
BlogIcon 호랭이 2009.02.26 01:52 
으하하하하하하하하하하하
프로젝트보다 더 애자일 한 고객 요구사항이라니...
아이고 깰꾸닥!!!

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 다음>>

열이아빠's Blog is powered by Daum