잠들기 전에 누구나 하루를 회상하며 잘된 것과 잘 못된 것들에 대해 어떻게 하면 좀 더 고급스럽고 좋은 일들을 만들 수 있을지 고민한다. 그것이 실현되고 있지 않다면 당신은 매번 시도해서 당신 자신을 개발해라 물론 당신은 그 사이에 많은 것을 성취했다. 누군가는 비용도 들지 않고 정확하게 도움되는 것들은 할 수 있다.-앤 프랜크 15세

과거로부터 얻은 것은 규칙적인 시간을 사용해서 어떤 것을 잘하고 어떻게 다르게 해야하는지를 평가하는 것이다.

당신 조직에서 새로운 아이디어를 소개하기 위해 waters(237)을 사용하므로 당신은 전도자(144)이거나 헌신적인 챔피언이다

팀내에서 같은 전제를 만들어내고 반복적인 전제들을 기반으로 같은 실수를 하게 된다. 일을 하기 위해 최선의 방법인지 아닌지 생각하고 지금 일을 그만 두는 것보다 항상 지금 하고 있는 일을 유지하는 것이 훨씬 쉽다. 매순간(시간)에 맞추기 위해 우리의 시도는 이것 저것을 급하게 처리한다. 이러한 계속적인 면에서 넓은 견해를 얻거나 반영하고 회고하는 것을 어렵게 한다. 우리가 진행하는 일이 더 이상 진행 할 수 없다는 것을 알았다면 계속 진행하면 불편할 수 있다. 신화의 힘의 저자, 베티 슈 플라워는 과거의 추정치로부터 우리의 미래를 만들 수 있다고 설명합니다.

늑대와 춤을, 영화에서 원주민들이 지난 사냥에 대해서 말하고 다시 회고하여 버팔로 상처로부터 성공위해 조사시간을 사용합니다. 이러한 의식은 중요합니다. 모든 사냥꾼들에게 중요한 교훈을 주기 때문입니다. 이것은 성공을 위한 중요한 방법이다. 같은 방법으로 회고하는 일은 중요한 일이다. 이는 지금 하는 일에 대한 반성과 다음에 어떻게 대처할지를 이해하기 위해 최근 프로젝트를 리뷰에 도움을 주는 것이 목적이다.

1998년에 조셉엔M.Juran은 회고분석으로부터 얻은 교훈 유도에 대한 글을 쓴 적이 있다. 이는 철학자 조지 산타나로부터 프로세스로 불려졌다. “누구도 과거를 정확하게 기억 할 수 없다”고 비판 받아 왔습니다. 많은 기업은 산타나 리뷰 양식을 가지고 있으며, 이를 회고(retrospective), 검시(postmortem), 산후(postpartum) 또는 프로젝트 리뷰(Project review)라고 합니다. 이런 생각은 매우 심플하다. 즉 과거 프로젝트를 있었던 일을 생각하고 그로부터 교훈을 얻으면 된다.

비록 실패한 프로젝트라도 가치 있는 성과물로 여겨진다. 또한(그래도 역시) 대부분 성공한 프로젝프로부터 팀의 능력을 향상 할 수 있다. 조직을 배우기 위해서는 우리는 프로젝트의 목적을 알고 목표를 연습하는 것입니다. 마찮가지로, 개인은 배우기 위해 반영에 많은 시간을 들여야 합니다. 링컨 대통령은 언급했다. 올바른 일을 하는 것보다 옳지 않은 일을 할 때 더 많을 것을 배운다. 그러나 시간을 투자하지 않는 다면 얻는 것은 없다.

따라서:

지금 하는 일이 잘 되고 있는지 와 다르게 적용해야 하는 것에 대해서 반영하기 위해 잠시 멈추어야 한다.

규칙적인 시간을 들여야 한다. 반영은 당신이 시간 있을 때 일어날지도 모르는 것 보다는 프로세스 부분에서 발생하기 쉽습니다. 단계적으로 적용하기 위해 프로세스 안에 반영 시간을 넣어라

당신의 전략에서 적용할 수 있도록 평가해라. 당신이 작은 성공(216)을 축하할 때. 다른 사람과 잘 된 점과 고쳐야 할 부분을 이야기 해라. 비록 잘 된 점이 없고 실수와 배우는데 문제가 있더라도 당신은 화내지 마라. 잘못된 원인부터 올바른 일을 하는 것 보다 옳은 원인을 위해 잘 못 했들 때 좀더 많이 배울 수 있기 때문이다.

그룹에 반영하기 위해 프로젝트 회고를 운영하라. 팀원들이 효율적인 생산성을 내기 위해서 과거를 리뷰하고 팀에 도움이 되며 재미 있는 일이 될 것이다. 가능하다면 location, location, location(189)를 사용해라

회고를 이끌기 위해 좀 더 많은 정보를 위해 norm kerth’s의 project retrospectives를 봐라

이러한 패턴은 과거에 있었던 일을 이해하고 미래에 능력을 향상시키기 위해서 도움을 준다. 당신은 당신이 경험하지 못했던 일들을 보게 될 것입니다. 다음 단계을 예상하고 계획 할 수도 있다. 지금 잘 되고 있는 것들에 대해 메모하고 어떻게 향상 시킬 수 있을지 생각해라. 성공한 일들은 다른 사람과 나누기 위해 문서화 해야 한다.

그러나 당신은 반영하기 위한 시간에 대해서 고민해야 하지만 빠르게 변화하는 세상에서 쉽지 않다. 그러나 과거에 관한 생각이 없다거나 다음 단계에서 계획을 준비하지 않는다면 논쟁해야 합니다. 반복되는 실수 때문에 오랜 기간 동안, 많은 시간을 잃어 버릴 수 있기 때문이다.

“매일, 나는 어려운 결정을 해야 한다.  그리고 나는 그것들을 기반으로 과거 작업을 생각한다. – Nathan Myhrvold가 말했다. MS의 chief인 그는 “역사는 중요한 개략사항으로 볼 수 있도록 이끈다. 그리고 많은 교훈을 제공한다….만약 당신이 앞으로 올바른 결정을 한다면 당신 뒤를 돌아 보라.

Blockbuster Inc.는 직원들이 고객과 많은 시간을 보내면서 틀에 박힌 것들을 줄이기를 원한다.

그들은 주의 깊게 살피고 작업을 진행하면서 사람들로부터 제안한 사항들을 브레인 스토밍 한다. 그들의 이런 작업은 개선을 만들어 낸다. 예를 들어 고객들이 편하게 고객카트에서 영화테잎을 놓고 가져갈 수 있도록 직원들이 비디오나 DVD를 놓는 재선반 프로세스를 변경한다. 프로세스 변경은 결국, 고객이 50% 이상의 시간과 비교해서 36% 시간으로 줄었다. 그들은 작업을 돌아보고 개선 사항을 유지 했을 때 이런 결과를 얻을 수 있었다.

커뮤니케이션 활성화와 팀원 존중

팀 구성과 협업을 위한 패턴

일반적으로 팀 구성 이전에 애플리케이션의 특성을 고려해 적합한 프로세스를 정립한 후 팀을 구성하게 된다. 생산성 향상적인 측면에서는 프로세스 정립을 위한 많은 방법론들이 공유되어 왔지만 현재는 팀을 위한 생산성, 구성, 배치에 관한 다양한 패턴이 제시되고 있다. 이 글에서는 기존에 팀 구성 방식을 알아보고 팀 구성을 위한 패턴과 요소들을 소개함으로써 팀을 구성하는 데 적합한 가이드라인을 제공한다.

————————————————————

강현구 h9kang@gmail.com | OOA/D, CBD, PLE를 전공하고 다양한 방법론과 패턴을 알기 위해 데브피아 소프트웨어공학 Eva에서 활동하고 있다. 이론과 실제에서 혼동하며 고민하던 것들을 여러분과 나누어 다양한 문제를 제시하고 풀어가길 기대한다.

————————————————————

보통 팀 구성을 위해 관리자(임원) 입장에서 개인 역량과 경험을 고려해 프로젝트 팀을 구성한 다음, 미리 정의된 프로세스에 팀을 정제하고 배치한다. 하지만 이는 사람 중심이 아닌 기술, 정책 위주로 팀을 구성하고 프로젝트를 진행하게 되면 개인의 능률을 떨어뜨리고, 생산성에도 악영향을 끼치게 된다. 하지만 기술 중심이 아닌 사람 중심의 팀을 구성함으로써, 팀 구성원 모두가 다양한 지식과 경험을 쉽게 공유할 수 있다.

기존 팀 구성 방식

먼저 기존 팀 구성 방식을 살펴보자.

▪ 기능 위주 개발을 위한 팀 구성(Bottom up 방식)

- 기능 위주의 팀 구성

Bottom-Up 프로세스는 기존의 비교 대상이 없는 새로운 소프트웨어를 만들 때 주로 사용하는 방법으로 알려져 있다. 기능 중심으로 진행하기 때문에 모든 기능들이 골고루 진화할 수 있고, 많은 요구사항을 수용하기에 적합한 방식이다. 다양한 요구사항을 수용하기 위해서는 프로세스 단계별 팀 또는 구성원 간에 협업이 필요하고, 요구사항의 명확한 정의로 업무분담이 적절하게 이뤄져야 한다. 그렇지 않다면 각 팀 또는 구성원 간에 업무 범위가 불명확해지고 의사소통, 전체 프로세스, 산출물 등에 부정적인 영향을 미친다. 요구사항을 기능으로 명확하게 구분하기 어려운 상황에서는 기능 위주의 팀 구성은 적합하지 않다.

- 팀원배치의 어려움

기능 중심의 팀 구성은 각 팀원들의 경험이 도메인에 익숙해야 하며, 각 팀 간에 기술 격차도 비슷해야 한다. 그렇지 않으면 업무 범위를 나누기 어렵다. 구성원의 능력을 고려해서 적재적소에 개발자를 배치하지 않으면 시간 낭비와 개인과 팀 전체에 영향을 미칠 수 있다.

사람은 단위나 모듈이 아니고 능력의 범위가 다르기 때문에 이를 수용하고 최상의 팀을 구성하기 위한 방법이 필요하다.

<그림 1> Bottom up

▪ 프로토타입을 위한 팀 구성(Top down 방식)

- 시나리오 방식

시나리오는 마천루처럼 솟아 누구나 식별이 가능한 기준이 된다. 이러한 명백한 기준이 있다는 것은 팀원 간에 시행착오를 줄이고 의사소통을 원활하게 만든다. 시나리오에 문제가 있다면 전체 구조에 악영향을 끼치고 많은 리소스 낭비를 초래하게 된다. 처음부터 많은 요구사항을 적용한다면 일괄적인 구조로 설계되기 어렵고, 특정 요구사항만 방대해질 수 있기 때문에, 시나리오는 가장 일반적이고 추상적인 것부터 시작되어야 한다.

- 구성원 간에 의존성

시나리오는 프로젝트 관련 분야에 많은 지식이 있는 도메인 전문가가 작성해야 한다. 처음부터 시나리오가 흔들리게 되면 나중에 모든 단계와 기능들이 파문 효과(Ripple Effect)처럼 여러 모듈에 영향을 미칠 수 있기 때문이다. 그래서 팀 리더의 영향이 중요하다. 이러한 영향이 골고루 분산되어 일의 범위를 정해야 하지만 그렇지 못한 것이 현실이다. 이러한 영향력을 줄이고 팀 구성원의 능력을 발휘할 수 있도록 하는 것이 프로젝트의 중요한 성공요인이다.

<그림 2> Top Down

기능과 기술 중심으로 팀을 구성한다면 전체 프로세스와 생산성에 영향을 미칠 수 있기 때문에, 최대한 개인의 장점을 살려 가장 높은 생산성을 얻을 수 있다. 따라서 관리자나 프로젝트 리더는 구성원들의 선호도와 능력을 고려하여 팀을 만들어야 한다. 이제 다룰 팀 구성을 위한 패턴을 통해 개인 능력을 최대한 발휘할 수 있도록 하고, 구성원 또는 팀원의 부족한 점을 보완할 수 있다. 이러한 팀 구성은 합리적인 데드라인을 예측하고 생산적인 리듬을 유지할 수 있도록 한다.

팀을 위한 설계 구성요소

설계는 각 팀 구성원간의 활발한 커뮤니케이션을 위해 사용되고 각 프로세스마다 적절한 산출물을 낼 수 있는 밑그림이 된다. 각 도메인의 특성을 고려하여 설계를 하지만 개인의 경험과 시각 차이에 따라 다양한 설계가 나올 수 있다. 군대처럼 개인의 특성을 고려하지 않은 형식적이고 획일적인 산출물을 만들게 되면 커뮤니케이션은 전체 프로세스에 영향을 미치게 된다. 그래서 각기 독특한 성향을 존중해 주고 긍정적인 상호작용을 유도할 수 있는 몇 가지 특징을 제안한다.

<그림 3> 오케스트라의 하모니

- 정확한 목표 의식

도메인의 목표 또는 개인의 업무 목표를 정확하게 인식하고 이에 알맞은 설계와 개발에 집중한다. 즉, 요구사항을 정확하게 분석하고 분석을 위한 다양한 커뮤니케이션이 필요하다. 개인의 목표도 중요하지만 팀의 목표도 못지않게 중요하다. 개인의 목표달성이 각 집단의 공동목표 달성 여부에 달려 있으므로 구성원들이 팀의 목표 달성을 위해 동료들을 도와주고 도움을 받으려 하는 등 활발한 긍정적 상호작용이 필요하다.

- 긍정적인 의존관계

프로젝트 진행 팀은 구성원 간에 또는 팀 간에 커뮤니케이션과 산출물의 의존성이 존재한다. 긍정적인 의존성을 위해 팀 내부에서만 사용되는 용어나 표기 방법은 자제하고 범용적인 용어와 전문 용어를 사용하여 산출물을 객관화해야 한다. 위에서 언급했듯이 개인의 목표와 팀의 목표는 공생관계이므로 목표 달성을 위해서 구성원 간의 커뮤니케이션이 증가해야 하며, 팀 간의 상호작용 산출물을 통해 긍정적인 의존관계가 활발히 이뤄져야 한다.

- 정확한 업무 범위

업무 범위를 정할 때 팀 또는 개인 간에 마찰이 가장 많이 생길 수 있다. 이를 해소하기 위해 팀 또는 개인의 능력과 기존 업무를 기반으로 업무를 나누고, 재사용성을 고려하여 업무의 경계를 구분한다. 또한 일에 분배가 명확하다면 그에 따른 보상 분배도 정확해야 한다. 모든 업무가 경계를 구분하기 쉬운 것은 아니지만, 이를 보완하여 업무 분담을 하기 위해 세분화가 적용되어야 한다. 구성원들이 협의 하에 업무를 세분화하고 분담하게 함으로써 모든 구성원들의 참여율을 높일 수 있다. 구성원의 참여율이 높다는 것은 프로젝트 성공 가능성이 그만큼 높아졌다는 것을 의미한다.

- 협동심

프로젝트의 시작부터 끝까지 끊임없이 문제들이 도출되고 해결되어야 한다. 이런 문제들에 신속하고 합리적으로 접근하기 위해 팀 구성원의 협동심이 필요하다. 확실하고 명확한 결정을 내리기 위해 리더나 관리자 입장에서 문제를 접근하기보다 리더부터 시작해 개발자에 이르기까지 전 팀 계층 차원에 문제를 정리하고 분석하는 커뮤니케이션이 필요하다. 이를 위해 많은 도구들을 사용하기보다 팀에서 익숙한 방법으로 커뮤니케이션을 이끄는 것이 좋다. 또한 문제를 공유하므로 서로의 입장에서 생각하고 구성원의 자발적 노력을 이끌 수 있다. 팀원들이 문제를 보는 시각을 다양화하기 위해서는 서로의 대화가 가장 효율적이다.

- 정확한 산출물 제공

각 프로세스의 산출물을 통해 평가하고 정제하여 다음 프로세스로 진행한다. 이에 산출물 관리가 매우 중요하다. 생산성에 미치는 악영향을 최소화하기 위해서는 부족한 산출물, 버그, 문서 작업을 신속하게 처리할 수 있도록 환경을 구성해야 한다. 또한 산출물 평가를 위해 동시에 여러 단계의 산출물을 진행해서는 안 된다. 검토하면서 부족한 부분을 알아내고 고친 후, 다음 단계로 진행해야 정확한 산출물 관리가 되기 때문이다. 리더는 산출물 관리를 위해 피드백과 검토회의를 통해 구성원의 문제와 그룹의 문제를 발견하여 다듬을 수 있다.

- 커뮤니케이션

커뮤니케이션의 중요성은 앞에서 여러 번 언급했다. 효율적인 커뮤니케이션을 위해 도구나 문서, 공간 등 대화를 위한 환경 구축이 필요하다. 먼저, 서로 대화하기 편하도록 팀만을 위한 공간을 마련하거나 같은 일을 하는 팀원들은 바로 옆에 배치하여 원활한 커뮤니케이션 환경을 만들어야 한다. 하지만 팀 공간을 강요하면서 개인의 공간이 줄어서는 안 된다. 개인 공간은 자신의 문제를 고민하고 해결할 수 있는 환경을 제공하기 때문에 충분한 공간이 확보되어야 한다. 또한 구성원은 문서나 코드, 개념도 등과 같은 도구를 이용해 효율적인 커뮤니케이션이 되도록 노력해야 한다.

위에서 언급한 것처럼 팀 생산성 향상을 위해 구성원의 개성을 살려 팀을 구성한다. 팀 구성뿐만 아니라 환경적인 구성에서도 팀 구성원 중심으로 바뀌어야 한다. 개인을 존중하고 개인의 발전이 팀 능력을 향상시키며 더 큰 생산성을 가져올 수 있다.

다양한 상황으로 보는 팀 구성 패턴

다양한 능력을 지닌 팀원을 최대한 활용하고 팀의 능률을 높일 수 있는 방법은 팀 구성에 달려 있다. 팀 구성을 위해 소프트웨어 설계 단계부터 고려하여 팀을 위한 패턴이 적용되어야 한다. 많은 패턴과 설계에서 한 명 또는 소수의 리더들이 전체 설계를 담당하고 작성한다. 소수의 인원만이 설계에 참여하게 되면 다양한 관점에서 문제를 풀 수 없다. 그러므로 팀 전체가 문제를 공유하여 다양한 관점에서 설계하고 피드백을 줄 수 있는 상황을 만든다면 좀 더 나은 설계를 찾을 수 있을 것이다. 이제 효율적으로 팀을 구성하고 다양한 관점을 도출하기 위한 방법을 이야기해보자.

▪ 다양한 관점에서 디자인 산출물

한 사람의 리더 또는 아키텍트, 설계자에 의한 설계는 다양한 관점으로 올바른 설계를 하는데 한계가 있다. 팀 구성원 모두가 설계에 참여해 각기 다른 관점에서 또는 업무를 고려한 객관적인 설계가 필요하다. 설계자 모두가 다양한 의견을 제시하여 참여율을 높이고 리더가 업무를 분담할 때 분명히 구분할 수 있는 발판을 제공한다.

<그림 4> 다양한 관점에서 설계를 위한 역할

<그림 4>와 같이 다양한 관점을 정리할 수 있는 중재자와 리더가 필요하다. 중재자는 도메인 전문가이거나 설계자가 될 수 있다. 중재자는 다양한 설계를 설계자로부터 받고 정리하여 리더에게 전달한다. 리더 또는 중재자가 다양한 설계를 보고 주요 이슈와 중요한 결정을 내릴 수 있도록 설계 시간은 최대 하루로 계획한다. 하루는 설계 문서에 관해 충분한 피드백 시간을 두고 적용하기 위해 계획된 시간이다. 정해진 시간 안에 설계자들은 설계문서에 대해 자기 의견을 제시하고 설계 목적에 부합한지 살펴보는 것이 가장 중요하다. 중재자는 다양한 설계를 정리하고 다음과 같은 리스트로 리더에게 보고해야 한다.

- 프로젝트 목적에 알맞은 설계 리스트

- 설계에서 도출된 질의사항 리스트

마지막으로 리더(결정권자)는 리뷰에서 나온 의견과 질의사항을 통해 각 설계들을 취합해서 목적에 알맞은 설계 문서를 작성하고 결정한다. 다양한 관점에서 설계하면, 모든 팀원의 생각과 의도가 표현되고 리더는 팀원의 생각과 프로젝트 목적을 고려해 주요 설계를 쉽게 결정할 수 있다.

[적용 시 고려할 점]

이러한 방법으로 단일팀에서는 다양한 설계 산출물이 나올 수 있지만, 정확한 요구사항 분석과 팀이 원하는 결과는 나오지 않을 수 있다. 어떤 리더는 우수한 분석 설계보다는 하나의 완벽한 설계(Closure)가 나오기를 원한다. 그리고 여러 사람이 도출한 다양한 관점과 해결책이 모순되거나 상반되면 의견 절충이 어려울 수 있다(cognitive dissonance).

▪ 다양한 리뷰 방법을 통한 피드백

자신의 실수를 효율적으로 빠른 시간 내에 어떻게 찾을 수 있을까? 개인 스스로가 문제를 찾고 해결하기 위해서는 많은 시간이 소요된다. 실제로 개발과 설계를 위한 시간보다 버그와 런타임 에러를 잡기 위한 시간이 생각보다 많이 소비될 때가 있다. 또한 개인이 예상치 못하거나, 하나의 작은 문제가 파문 효과를 일으켜 팀 전체에 영향을 미치는 민감한 문제들은, 팀 전체가 문제 해결을 위해 서로 토론하고 생각하며 해결책을 찾아야 한다.

다양한 리뷰 방법을 통해 개인 문제뿐만 아니라 팀 문제도 발견할 수 있고 보완점과 해결점을 찾을 수 있다. 설계자가 초안 또는 완벽한 설계를 구상했다면, 한 명 이상의 리뷰어들을 구성하여 피드백을 시작한다. 피드백을 전달하는 많은 방법이 있지만 가장 효율적인 것은 Meeting Review와 Distribution Review이다.

- Meeting Review는 리뷰자들이 직접 해당 문서를 피드백하고 리뷰 리더에게 보고한다. 리더는 많은 리뷰들을 참고하여 해결책을 제시하는 역할을 하고, 기록자는 피드백 의견을 기록한다.

- Distribution Review는 여러 리뷰자들이 설계 문서를 서로 번갈아 가면서 보고, 의견을 수렴하는 형태이다. 때로는 Lotus Note와 같은 메커니즘을 사용해 자동으로 처리할 수 있다.

리뷰자들은 문서를 통해 서로 정형화된 피드백을 주고받을 수 있다. 또한 문서를 이용해 피드백을 공유함으로써, 서로간의 생각과 이슈사항을 공유할 수 있다. 이러한 피드백들을 모아 올바른 설계를 도출해야 한다. 특히 Meeting Review에서는 문서 피드백을 통해, 리더는 정확한 판단으로 올바른 리뷰를 도출해야 한다.

<그림 5> 다양한 리뷰어들을 통한 피드백

다양한 리뷰 패턴에서는 리뷰어, 설계자, 기록자, 리뷰 리더의 역할 모델이 있다. 리뷰 리더는 효율적인 리뷰를 위해 총체적인 역할을 한다. Meeting Review에서 리더는 중재자 역할을 하고, Distribution Review에서는 적절한 시간을 정하고 시간 내에 다양한 의견이 나올 수 있도록 한다.

리뷰를 위해 공통으로 사용하는 리뷰 형식이 있다면 리뷰를 주고받을 때 효율적으로 이용 가능하다. 애플리케이션 전문가, 문서작업의 달인, 설계와 상관없는 리뷰자 등과 같이 다양한 분야에 다양한 재능을 갖춘 리뷰자들을 통해 여러 가지의 피드백 결과를 얻을 수 있다.

피드백을 통해 요구사항을 다시 점검하고 변경사항을 체크하여 잦은 설계변경에서 추적성(Traceability)을 유지해야 한다. 리뷰 단계는 다음 단계를 위한 준비 단계로 두고, 리뷰어는 이 과정이 끝날 때까지 다음 단계로 진행해서는 안 된다. 한 단계를 위한 리뷰에 집중할 수 있게 해야 한다.

[적용 시 고려할 점]

- 설계자들은 어쩌면 자신의 설계에 대해 피드백을 받고 싶지 않을 수도 있다.

- 피드백 의견을 한 동료를 통해 얻는다면 형식에 구애받지 않고 자유롭게 의견을 나눌 수 있다.

▪ 마스터 설계팀을 통한 작업분배

프로젝트 진행에 있어서 작업 분배는 많은 마찰을 불러오기도 한다. 소규모 팀에서는 한 명의 리더가 대부분 시스템에 대한 설계를 통합하고 나눈다. 규모가 큰 프로젝트에서 팀장 혼자 설계가 가능할까? 우리는 작업 분배를 유럽의 중세시대 작업환경에서 배워보자. 장인은 작업 책임을 맡아 일을 분담하고 숙련공들은 할당받은 일을 하게 된다. 즉, 마스터 설계팀은 설계 아키텍처의 밑그림을 제시하고 컴포넌트 단위로 업무를 분담한다. 각 팀원들은 할당 받은 컴포넌트를 설계하고 개발하여 설계 팀장으로부터 피드백을 받는다. 마스터 설계팀은 다음과 같은 내용들을 팀원들에게 제시해야 한다.

- 중심 아키텍처(Core Architecture): 시스템 상세도, 컴포넌트 구성도, 상호작용 설계서 및 실례, 아키텍처 변경에 관한 의견서를 제시한다.

- 구조적 비전(Architectural Vision): 전체 구조의 방향과 목적을 정의하고 이에 적합한지 확인할 수 있는 기준을 마련한다. 중요한 작업이므로 문서로 가시화하고 프로젝트팀 전원이 공유할 수 있도록 한다. 예를 들면 비슷한 프로젝트 또는 소단위 프로젝트(sub-project)에 사용되고 공유되는 디자인 패턴을 적용한 사례를 제시한다.

- 인터페이스(Interface): 할당된 컴포넌트 단위로 인터페이스 설명과 트랜잭션의 타입을 명시한다. 상세기술서는 설계자가 직접 작성하여 리더에게 리뷰를 받아야 한다.

- 명세서 관리(Specification Control): 구조적 변경에 관해 마스터 팀은 문서를 통해 변경 사항을 명시하고 관리한다. 마스터 팀은 요구사항에서 산출물에 이르기까지 일관성 있는 정책을 유지해야 하며, 내부 및 외부적인 변화로 인한 명세서 변경을 염두에 둬야 한다.

개발 과정에서 마스터 설계팀은 공통적으로 지켜야 할 수칙들을 명시해야 한다. 예를 들면 에러 핸들링 정책, 코딩 가이드라인, 테스트 정책, 다른 라이브러리 사용, 멀티 스레드 정책 등이 있다.

<그림 6> 마스터 디자이너의 역할

[적용 시 고려할 점]

만약 두 개의 리더 마스터 팀이 있다면 혼동을 초래한다. 처음부터 마스터 팀 간에 분담을 정확하게 나눌 수 없고, 변경되는 요구사항에 두 팀이 동시에 적응하기에는 한계가 있다. 변경에 대비하기 위해 단일 마스터 팀을 두고, 분담하여 팀워크를 이뤄야 한다. 가장 효율적인 분담은 도메인별로 시스템을 구분하고 도메인 인터페이스를 명세한 것이다.

▪ 설계 문서 관리 패턴

설계 문서는 요구사항이 변경되거나 시스템 제약사항 때문에 수정될 수 있다. 요구사항이 변경되면 관련 문서와 산출물이 변경되어야 하므로 변경에 쉽게 대비할 수 있는 설계 문서 관리가 중요하다. 새롭게 일하게 된 설계자들은 기존 설계문서에서 변경된 부분을 말로 설명하거나 코드를 읽어가면서 변경된 부분을 찾는다. 이는 시간 낭비이며 변경 사항을 정확하게 파악할 수 없다. 정확한 변경 관리를 위해 문서를 전담으로 관리하는 팀원이 필요하다. <그림 7>과 같이 설계문서 관리를 위해서 각 주요 문서의 원본이 아닌 사본을 두고 모든 팀원들이 접근하거나 인쇄할 수 있도록 한다. 관리하는 팀원은 변경된 부분을 정확하게 표시해 두어야 하고, 적절하지 않거나 불명확한 명세는 삭제한다. 설계자가 변경 관리를 하는 것이 효율적이며, 설계자가 아니더라도 프로젝트의 전반적인 지식을 갖춘 팀원이 관리하는 것이 낫다. 또는 프로젝트의 전반적인 지식을 배울 수 있도록 다른 팀의 구성원이 해도 괜찮다. 단 설계자가 계속적으로 피드백을 주어야 한다.

<그림 7> 설계 문서 관리

[적용 시 고려할 점]

문서 관리를 위해서 버전을 체크하거나 온라인 관리 프로그램 또는 CVS 서버를 이용해 관리하는 것도 좋지만, 버전 관리에는 다음과 같은 단점이 있다.

- 주석을 사용해 변경된 부분을 누구나 알 수 있게 해야 한다. 그렇지 않다면 문서변경 관리에 문제가 생겨 어느 누군가가 잘못된 문서로 작업할 수 있다. 그래서 문서 작성자는 변경에 책임을 져야 한다. 하지만 사람이 직접 많은 문서를 관리하기에는 한계가 있으며 자동 시스템 또한 모든 변경에 적절한 주석을 달 수 없다. 아울러 문서 접근 제한과 버전 관리에는 기술적인 문제도 존재한다.

- 문서 수정은 항상 사본을 이용한다. 이는 마스터 권한에 관계없이 수정 삭제가 자유롭기 때문이다.

머지않아 좋은 문서 관리 도구를 이용한 변경 관리 방법이 다수 등장하게 될 것이다.

최선의 팀 구성 패턴은?

팀 패턴은 다양한 의견을 수렴하여 피드백을 주어 팀 구성원 모두가 적극 동참하고 리더가 쉽게 의사 결정을 할 수 있도록 돕는다. 위에서 제시한 팀 구성 패턴들이 완벽한 해답은 될 수 없지만 개인의 능력을 존중하고 커뮤니케이션을 활성화하여 올바른 길로 프로젝트를 이끌 수 있는 계기를 마련할 수 있길 바란다. 팀 구성을 위한 모든 경우를 예상할 수 없지만, 기준을 마련하고 이에 부합하도록 노력해야 한다. 환경과 갈등을 탓하기 이전에 내 위치에서 얼마나 역할을 잘 감당하고 있는지를 돌아보아야 한다.

다시 말해, 팀 구성에서 개인의 능력을 존중하고 각자의 자리에서 자신이 맡은 일을 충실히 수행할 때 생산성을 향상시킬 수 있다. 아무리 뛰어난 아키텍트와 리더가 있더라도 구성원이 따라주지 못한다면 일의 능률은 떨어진다. 고급 개발자, 중간급 개발자 그리고 초급 개발자로 골고루 팀을 구성하여 활발한 커뮤니케이션을 통해 지식을 공유하고 문제를 풀어가는 것이 최선의 팀 구성 패턴이다.

————————————-

참고자료

1, Charles Weir, Pattern for Designing in Teams, Object Designers Limited, june 1996

2, 손영수, 팀 생산성 향상을 위한 패턴이야기, arload.wordpress.com/2008/09/02/teamproductivity

3, Weinberg, G. (1971) The Psychology of Computer Programming, Van Nostrand Reinhold ISBN 0-442-20764-6

4, Belbin R. M (1981) Management Teams Butterworth-Heinemann ISBN 0-7506-0253-8

5, Bezier B (1984) Software Testing and Quality Assurance Van Nostrand Reinhold ISBN 0-442-21306-9

6, Coplein and Schmidt (editors 1994) Pattern Languages of Program Design, Addison Wesley ISBN 0-201-60734-4, Chapter 13 (Coplein) A GenerativeDevelopment-Process Pattern Language.

7, Cook S and Daniels J (1994) Designing Object Systems: Object-Oriented Modelling with Syntropy, Prentice Hall, ISBN 0-13-203860-9

8, Gilb T (1988) Principles of Software Engineering Management, Addison-Wesley ISBN 0-201-19246-2

9, Goldberg A and Rubin K (1995) Succeeding with Objects: Decision Frameworks for Project Management, Addison-Wesley. ISBN 0-201-62878-3

10, Lise B. Hvatum, Patterns to Enable Distributed Development, Sugar Land Technology, Houston, USA

———————————————-

복구 및 취소 메카니즘을 지원하기 위한 패턴이다.

취소 했을때 그 시점의 객체 정보를 불어와

바로 전 시점으로 돌아 갈 수 있다.

-동기: 자료 구조(리스트, 벡터등)로 자료를 저장하기에는 한계가 있구 많은 자료를 관리하는데 문제

-장점: 객체 사황을 리스트가 아닌 객체로 관리하여 관리하기 쉽다. 캡슐화를 지원

-단점: 많은 memento를 생성하면 비용 증가, 생산성 하락

좋아좋아^^