 |
|
난이도 : 초급 Gary Pollice, 교수, Worcester Polytechnic Institute
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 10 월 07 일 Rational Edge에서: 소프트웨어 개발에서 정의된 프로세스를 따를 때 생기는 가치는 확고부동합니다. 하지만 어떤 프로세스를 선택해야 합니까? 얼마나 복잡합니까? 팀 크기는 어떤가요? Gary Pollice 교수는 기업 내부에서 필요한 다양한 프로세스에 대한 고려를 통해 이런 질문에 대답합니다.
이번 달 Theory and Practice에 실을 요량으로 '테스트에서 모형 객체를 활용하고 생성하는 방법'에 대한 컬럼을 집필하기 시작했다. 애자일 방법론과 기법에 대해 매년 열리는 애자일 공동체 컨퍼런스인 Agile 2006에 참석하기 전이었다. 이런, "아! 또 다른 애자일 기사군"이라고 말하는 소리가 여기까지 들린다. 애자일이 내 의도가 아님을 분명히 말하겠다. 여러 사람과 함께 한 컨퍼런스 발표와 토론은 일반적인 프로세스와 소프트웨어 개발에서 프로세스의 역할을 생각해보게 만들었다.
물론 이 컨퍼런스에 참석한 사람은 소프트웨어를 제대로 만들 은총알을 찾는 데 진짜로 관심이 많았다. 컨퍼런스 토론이 조직 내에서 특정 성공 수준에 집중되어 있으며, 이런 수준은 회사 크기, 소프트웨어 개발 팀 크기, 성공을 달성하기 위해 사용된 프로세스 범위와 관련이 있다는 생각이 떠오르기 시작했다. 이 모든 내용을 분류하려고 시도했으며, 여러 가지 생각을 거쳐 소프트웨어 개발에서 프로세스의 역할에 대해 도움이 되는 방법을 찾아내었다고 생각한다.
작은 조직이 전사적인 조직으로 변해가는 모습을 본 신참 입장에서는 사물은 변하며 프로세스도 역시 변해야만 한다. 애자일 공동체는 애자일의 근본 원칙이 작업 방법을 개선해 작업 에 반영하는 데 있다는 사실을 재빨리 간파했다. 하지만 이런 원칙은 RUP나 다른 현대적인 방법론에서도 다르지 않다. 그렇다면 "프로세스가 중요한가?"라는 질문이 떠오른다.
"프로세스가 중요한가"라는 질문은 수사학적으로 들린다. 특히 학자 경력을 추구하기 위해 Rational 조직을 떠나기 전까지 내부에서 통용된 내 별명인 "RUP 옹고집"이 말했다면 특히 더 심하다. 실제로 질문은 어느 정도 수사학적이다. 물론 프로세스는 중요하다! 어떤 경우에는 선택한 프로세스가 프로젝트 팀을 압도하는 바람에 팀이 고객을 만족시키지 못하도록 만들 때도 있으니 중요하긴 중요하다. 고객 만족과 품질을 동일하게 여긴다면, 프로세스는 잠재적으로 품질에 부정적인 영향을 미칠 수 있다.
아마도 더 나은 질문은 "특정 프로세스가 중요한가?"로 보인다. 직전 컬럼에서 프로젝트에 프로세스를 맞추는 작업의 중요성을 논했으며1, 프로젝트에 적합한 프로세스를 골라서 다듬어야 할 필요성은 이제 소프트웨어 개발에서 우수 사례로 받아들여진다. 또한 조직이나 프로세스 팀을 효과적으로 지원하는 유일한 프로세스는 없다. 많은 프로세스가 있을 뿐이다. 잘 정의되었거나 그렇지 않거나 거의 모든 프로세스가 팀 성공을 도와주는 사례를 상상할 수 있다.
특정 상황에 적용 가능한 프로세스 수에 영향을 미치는 요인은 두 가지라고 본다. 팀 크기와 더 큰 공동체 맥락에서 프로세스 범위다. 이런 요소를 검토하고 더 큰 조직에서 찾을 수 있는 다중 프로세스를 도입할 때 필요한 프로세스 인터페이스를 살펴보겠다.
정의
세부 내역으로 들어가기에 앞서 "프로세스"라는 개념을 같은 식으로 바라보고 있는지 확인하는 단계가 필요하다. 내가 좋아하는 정보 출처인 사전으로 돌아가 여기에서 프로세스 정의를 찾아보자. "결과를 낳는 행동, 변화, 기능의 연속"2. 내 생각에 이런 정의는 간단 명료하면서도 프로세스의 핵심을 꿰뚫는다. 프로세스는 우리가 작업을 완료하기 위해 밟아야 하는 일련의 단계다. 작업 계획 방법을 기록한 매뉴얼도 아니며 맹목적으로 따라야 하는 그저 그런 규칙 집합도 아니다. 프로세스는 문서로 작성됐거나 공식적으로 정의됐거나 그렇지 않거나에 무관하게 우리가 해야 할 일을 담고 있다.
팀 크기와 의사 소통
효율적인 프로세스는 효율적인 의사 소통을 지원하며, 효율적인 의사 소통은 프로젝트 팀 크기와 직접적인 관련이 있다. 이는 크기가 다양한 프로젝트 팀에서 작업한 어느 누구에게도 새로운 소식이 아니다.
좀 더 정확한 증거를 좋아하는 독자를 위해, 팀 크기에 따라 가능한 의사 소통 채널 개수를 고려해보자. A, B라는 두 사람이 참여하는 프로젝트에는 의사 소통 채널이 하나다3. 프로젝트에 C라는 사람을 추가하면, A-B, B-A, C-A로 의사 소통 채널이 셋이 된다. 팀에 D가 참여하면 의사 소통 채널이 여섯 개가 되며, E가 참여하면 열 개가 된다. 열 명으로 구성된 팀에는 의사 소통 채널이 45개 존재한다. 많은 가능성이 있기에 구두로 정보를 동기화하고 전달하는 것은 어렵고 실수를 유발하기 쉽다.
의사 소통 채널 수를 결정하는 공식은 n개 항목에서 순서에 무관하게 선택한 두 항목으로 이뤄진 두 쌍의 개수를 구하는 조합 공식이다. 공식은 다음과 같다.4
쌍을 살펴보면 다음과 같이 줄일 수 있다.
이 공식에서 중요한 특징은 그림 1에 나타나 있다. 증가 비율이 선형이 아님을 확인할 수 있다. 팀이 커짐에 따라, 어떤 의사 소통 채널을 어떻게 열어야 할지를 결정해서 의사 소통 채널을 공식화하는 방법을 찾아야 한다.
그림 1: 팀 크기가 의사 소통에 미치는 영향: 팀이 점점 더 커질수록 의사 소통 연결 개수는 비선형으로 증가한다.
팀 크기는 단순히 의사 소통 채널 수를 넘어 다른 곳에도 영향을 미친다. 팀 크기는 팀 프로세스의 모든 부분에 영향을 준다. 작은 프로젝트에서 두 사람이 함께 일하면 작업을 할당하고 원시 코드를 관리하고 작업 내용을 문서로 기록하는 몇 가지 메커니즘을 채택할 것이다. 두 사람에게는 각자 작업을 어떻게 할지 말해주는 지침이 정말 필요하지 않다. 대부분 개인적으로나 전자적으로 하루에 여러 번 의견을 나누는 선에서 끝난다. 물론 이게 바로 의사 소통이다. 하지만 여기서 두 사람에게는 의사 소통을 방해하는 외부 소음을 접할 기회가 거의 없다. 두 사람만 있으므로 도구를 사용해 만든 UML(Unified Modeling Language) 다이어그램이나 상세한 유스 케이스 설명 같은 영구적으로 보관할 수 있는 형태로 의사 소통을 바꿀 필요가 없다. 어떤 "경량' 프로세스도 두 사람에게는 잘 통한다5.
의사 소통 문제는 팀 크기가 커질 때 나타난다. 이런 문제 중 하나는 작업 할당이다. 두 명이나 세 명은 누가 무엇을 하는지 어떤 목적으로 하는지를 쉽게 추적할 수 있고, 발생할지도 모르는 다른 설계 쟁점에 대해 누구와 이야기해아 할지도 안다. 이런 상황은 20명짜리 팀에서는 완전히 달라진다. 어딘가에는 사람들이 노력을 집중할 방향을 제시하기 위해 사용할 수 있는 중앙집중식 작업 목록이 필요하다. 스크럼(Scrum)이나 XP(eXtreme Programming) 같은 애자일 방법론에도 이런 목록이 있다. 스크럼에서는 이를 백로그라고 부르며, XP에서는 과업 파악 메커니즘으로 스토리 카드를 사용한다.
프로세스를 메커니즘 표준화 도구로 여긴다면 프로세스에 대한 요구는 팀 크기가 증가할수록 늘어난다. 각 팀원이 자신의 과업을 제각각 결정한다면, 특히 이런 과업이 다른 팀원에게 영향을 미친다면, 팀 효율을 떨어뜨리고 뭔가 잘못되게 만들 가능성이 너무나도 높다.
내가 참여했던 과거 예를 들어 이런 문제점을 보여주겠다.
새로운 제품을 만들어내기 위해 개발자 15명으로 구성된 제품 팀에서 일하고 있었다. 이 팀은 구체적인 컴포넌트를 책임진 좀 더 작은 팀으로 나뉘었다. 컴포넌트 중 하나는 내가 만든 컴포넌트를 비롯하여 다른 모든 사람이 만든 컴포넌트가 의존하는 핵심 구성 요소였다. 나는 보통 코드에 작은 변경을 가한 다음에 앞으로 나가기 전에 새로운 코드를 테스트하는 방법으로 작업한다.6 이 프로젝트에서 다음과 같은 패턴이 반복되어 나타났다. 변경을 가한 다음에 빌드를 하려면 종종 컴파일 오류와 링크 오류가 생겼다. 물론 내 코드는 아니었다. 다른 모듈로 눈길을 돌려 버그를 추적하기 위해 체크인 로그를 살펴보면 Mary7가 내 마지막 빌드와 현재 빌드 사이에 변경을 가해서 빌드를 망가뜨렸다. 그 때마다 Mary에게 변경을 가했는지 물어보면 Mary는 잘못된 코드를 체크인했다고 시인했다. 그러면 코드를 테스트했냐고 물어봤다. Mary의 대답은 항상 다음과 같았다. "아뇨. 간단한 변경일 뿐이잖아요?" 그렇다면 코드를 컴파일을 하긴 했느냐고 물어봤다. 다시 한번 Mary는 "딱 한줄만 바꿨어요. 빌드할 필요가 없어요"라고 대답했다.
명백히, Mary가 채택한 개인적인 프로세스는 다른 사람에게 영향을 미쳤다. 내 프로세스는 Mary의 프로세서와 상당히 달랐다. 컴파일과 테스트 전에 어떤 코드도 체크인하지 않는다는 규칙과 같이 팀을 위한 간단한 규칙을 확립하면, 팀의 시간과 노력을 절약했을 것이다. 15개나 되는 개인 프로세스를 받아들이기로 했다면 프로젝트가 어떤 모양이 될지 상상해보라. 불행하게도 팀은 개발자가 모든 프로세스를 정의할 필요가 있다고 결정했다. 이런 프로세스는 생산적이지 못하며 쓸모없는 활동에 우리의 시간 대다수를 사용하는 프로세스의 대척점에 위치하고 있다.
앞서 든 예에서 배운 교훈은 아주 단순하게 보인다. 하지만 이런 단순한 교훈은 팀 크기가 커지면서 동의해야만 하는 프로세스가 중요한 이유를 효과적으로 보여준다. 팀 크기에 적합한 프로세스를 선택하자. Alistair Cockburn은 자신이 집필한 Agile Software Development8에서 이런 문제를 멋지게 기술한다. Cockburn은 프로젝트 크기를 설명하면서, 만들어진 제품 크기와 개발 팀 크기 모두가 프로세스 설정을 위한 매개 변수 중 하나로 고려되어야 한다고 설명한다. 의사 소통 문제와 함께 팀 크기가 프로젝트 크기에 직접적으로 비례하므로 나는 선도 지표로 팀 크기에 초점을 맞춘다.
프로세스의 범위와 목적
프로세스 선택 개수에 영향을 미치는 두 번째 주요 요인으로 프로세스 범위를 든다. 프로세스 시작부터 끝까지 개발 활동을 다루는 프로세스인지 아닌지를 말하려는 의도가 아니다. 여기서 범위는 전체 조직이나 공동체에 프로세스가 미치는 영향력을 의미한다.
목적에 따라 그룹으로 묶는 방식이 자연스럽게 보이는 몇 가지 범위가 존재한다.
우선 가장 작은 범위는 개인적인 프로세스 범위다. 우리 모두에게는 자기 경력을 만들어온 개인 프로세스가 있다. emacs 편집기에서 작업하며 emacs 내부에서 모든 일을 처리하는 걸 좋아하는 훌륭한 개발자를 생각할지도 모르겠다. 아니면 좀 더 시각적인 개발 환경에서 수 많은 통합 도구를 다루는 사람을 생각할지도 모르겠다. 몇몇 프로그래머는 프로그램 작성에 앞서 의사 코드를 작성한다. 다른 사람은 바로 코드 작성으로 뛰어든다. 핵심은 우리 각자에 적합한 개인적인 프로세스가 존재한다는 사실이다. 최소한 개발자 수만큼 개인적인 프로세스가 존재할 것이다.
두 번째 프로세스 범위는 직접 접해 있는 팀 프로세스다. 직접 접해 있는 팀은 개인보다 더 큰 최소 단위로 제품을 만들고 제품 일부분을 만들어내기 위해 협력한다. 이 범위에서, 프로세스는 모든 개인에게 영향을 미칠 뿐만 아니라, 개별 개발자의 개인적인 프로세스를 지배한다. 각 개인은 개인적인 프로세스를 팀 프로세스에 일치하도록 조정할 필요가 있다. 훌륭한 팀 프로세스는 개인적인 프로세스에 변경을 최소한으로 요구한다.
세 번째 프로세스 범위라는 사다리를 구성하는 가로대는 프로젝트 범위다. 프로젝트 범위는 단일 프로젝트, 제품, 제품라인에 영향을 미친다. 이런 과정은 시스템 엔지니어링 제품에 흔하다. 소프트웨어와 하드웨어를 병렬로 개발해 동기화해야 하기 때문이다. 대부분 이런 프로젝트는 "진짜" 소프트웨어 프로젝트가 겪는 급격한 변경 사항을 피할지도 모르겠다. 과금 시스템은 전용 하드웨어와 병렬로 개발하지 않으며, 특정 하드웨어 구현에 의존한다.
네 번째이자 마지막은 전사적인 프로세스 범위다. 대규모 조직에는 동시에 여러 단계에서 벌어지는 여러 프로젝트가 있다. 조직은 비용 관리, 자원 최적화, 회사 목표에 기여하는 프로젝트 보증에 대해 노력해야 한다. 대규모 조직에서 한 가지 중요한 비즈니스 활동은 포트폴리오 관리로, 회사가 프로젝트 포트폴리오를 귀중한 자산으로 관리하도록 만들어준다. 프로젝트 포트폴리오 관리 규율은 다른 회사 자산과 마찬가지로 포트폴리오라는 자산을 효과적으로 관리할 필요성으로부터 생긴다. 포트폴리오 관리는 프로젝트 전 범위에 걸쳐 실질적인 프로세스 구현을 요구한다.
독자들이 생각하는 다른 프로세스 범위가 있을지도 모르겠다. 이런 네 가지만 해도 우리 목적에 충분하며, 이 기사 나머지에서는 네 가지 계층을 사용하겠다.
이제 조직에서 프로세스 사용에 영향을 미치는 팀 크기와 프로세스 범위라는 두 가지 주요 요인을 설명했으므로, 조직을 들었다 놓았다 하는 팀 동역학이 미치는 영향을 고려해보자.
범위 내에서 프로세스 목표 변경
다음에 관찰한 내용이 여러분에게는 당연하게 보일지 모르겠다. 하지만 내 경력에서 상당한 기간 동안 명백하지 않은 내용이었다. 프로세스 범위가 바뀌면, 프로세스를 유지할 이유도 바뀐다. 이게 바로 전략과 전술 사이에 생기는 차이점이라는 생각이 들었다.
개인적인 프로세스는 시간이 지남에 따라 개발자가 작업 스타일을 맞추기 위한 진화가 일어난다. 프로세스 목표는 개발자가 고품질 코드를 생성하도록 도와주는 데 있다. 모든 코드를 테스트했는지 확신할 때, 고품질 코드가 만들어지는 이유는 이런 과정에서 내 자신이 더 나은 개발자로 올라서기 때문이다. 다시 말해 이렇게 해야 완성된 제품이 더 좋기 때문이다. 설계 패턴을 배우고 설계 과정의 일부로 적용할 때, 내 코드는 더욱 견고해진다. 내가 추구하는 개인적인 프로세스는 아주 혁신적이다.
팀 프로세스는 확실히 팀이 고품질 제품을 만들게 도와주도록 설계되어야 한다. 하지만 팀에서 다른 덕목도 기대한다. 일반적으로 상태 보고(서면이나 기타 등등), 개발자 효율 평가, 의사 소통 메커니즘 등이 여기에 속한다.
프로젝트 프로세스는 좀 더 전략적이다. 프로젝트 프로세스는 시장, 회사 전략에 대한 좀 더 많은 정보와 프로젝트가 여기에 기여하는 방법과 관련이 있다. 이런 프로세스 유형은 개인적인 프로세스에 거의 영향을 미치지 않는다. 미치더라도 보통 부정적인 영향을 준다. 여기에 대해 좀 더 설명하겠다. 프로젝트 단계에서, 프로세스는 완료된 제품이 출시 준비가 되었는지, 제품을 위한 문서가 사용자에게 적합한지를 결정하는 문제에 초점을 맞춘다. 이런 정보는 다른 프로젝트 팀이 제공해야 한다. 프로젝트 프로세스는 정보가 담고 있는 내용과 정보를 표현하는 형식에 몇 가지 제약을 가할지도 모르지만, 각 팀은 정보를 생성하는 방법을 결정할 능력을 갖추고 있어야 한다.
하지만 누군가에게 유용할지도 모르는 정보를 만들어낼 경우에 개별 개발자는 작성하는 모든 함수에 대해 세부 설명을 제공하도록 프로젝트 프로세스가 규정했다고 가정하자. 이는 확실히 개발자 생산성과 사기에 부정적인 영향을 미칠 것이다. 이는 또한 우리가 피하려고 그렇게 노력한 엄청나게 많은 쓸모없는 문서 작업을 요구한다. 실제로 이런 문서 작업이 필요하다면, 프로젝트 프로세스는 단순히 팀에 문서 작성이 필요하다고 말한 다음에9, 문서를 만들어내는 방법을 팀이 결정하도록 놓아두기만 하면 된다.
마지막으로 전사적인 프로세스는 개인적인 세부 내역을 신경쓰지 않는다. 이는 완벽하게 전략적이다. 전사적인 프로세스는 회사가 총체적으로 생존하기 위한 토대다. 개인적인 수준보다 전사적인 수준에서 계획 과정에 더 많은 노력을 기울여야 하며, 모두 이런 방식을 기대하고 있다.
계층을 살펴보고 프로세스 목적에서도 차이점을 살펴볼 때, 프로세스를 선택하고 어울리게 만드는 방법을 이해하기 시작한다.
먼저, 소프트웨어와 마찬가지로 프로세스에는 아키텍처가 있는 듯이 보인다. 다양한 프로세스 유형을 층층이 쌓는 방식은 프로세스를 조직화하는 가장 효과적인 방법이다. 계층을 사용하면, 그림 2에 제시한 좀 더 큰 조직을 위한 4단계 프로세스 설정을 쉽게 상상할 수 있다. 각 층은 상위 층에 있는 프로세스에 기여한다. 더 높은 층은 목표를 달성하기 위해 더 낮은 프로세스에서 필요한 (최소) 정보량을 정의한다. 각 단계는 바로 위나 바로 아래 단계와 통신할 뿐이라는 사실에 주목하자. 이는 또한 각 프로세스는 바로 아래에 위치한 프로세스에 직접적인 영향을 즉각 미친다는 사실을 암시한다. 예를 들어, 기업은 매년 예산을 계획하기 위한 정보가 필요하다. 기업은 각 프로젝트에서 예산 정보를 제공받기를 기대한다. 프로젝트를 진행하려면 팀에서 관련된 정보를 얻어 회사가 필요한 형태로 통합할 필요가 있다.10 팀은 개발자가 원하는 새로운 도구를 물어서 조사하는 경우와 같이 자료 수집을 위해 개인 개발자 욕구를 의사 소통으로 풀어야 한다.
그림 2: 프로세스는 계층화되어 있다.
조직이 그림 2처럼 계층화된 프로세스를 보유하고 있다면, 조직은 계층화된 소프트웨어 아키텍처에서 볼 수 있는 똑같은 이익을 실현할 것이다. 우리에게는 전체 프로세스 시스템을 개정하지 않고서도 새로운 프로세스로 옛 프로세스를 "교체"할 능력이 있다.
범위와 크기는 연관이 있지만 둘은 프로세스 선택에 다른 방법으로 영향을 미친다. 조직 내부에서 범위에 어울리게 프로세스를 선택하는 작업은 일반적으로 개인, 그룹, 조직 내 상위 관리층이 수행한다. 팀 크기에 어울리게 프로세스를 선택하는 절차는 일반적으로 개인, 그룹, 프로세스를 사용할 팀이 수행한다. 그림 2에서 하위 두 층은 개선된 품질, 더 빠른 개발과 같이 팀원이 제공하는 전술 가치를 위해 팀원이 선택한 프로세스를 표현한다. 상위 두 층은 전략과 통제 목적으로 관리자가 선택한 프로세스를 표현하며, 하위 층에 영향을 미친다.
프로세스 층에는 적절한 인터페이스가 필요하다
직전에 살펴봤던 내용에 따라 프로세스를 고려하면 프로세스 인터페이스 개념이 나온다. 그림 2를 자세히 들여다보면, 상위 단계 프로세스는 하위 단계 프로세스에 제약을 강제한다. 이는 소프트웨어 설계에서 다른 클래스가 제공하는 메서드를 호출하는 클래스와 어느 정도 유사성이 있다. 의존성을 최소로 줄이기를 원하기 때문에 둘 사이에 인터페이스를 만든다. 프로세스 층 사이에 이런 인터페이스를 만들면, 지금부터 상위 단계에 적절한 인터페이스만 제공한다면 하위 단계 프로세스가 발전하고 바뀌도록 놓아둘 수 있다. 이는 더 큰 범위에서 프로세스를 위한 정보를 다듬고 형식을 바꿔주는 어댑터를 요구할지도 모른다.
간단하지만 현실적인 예를 살펴보자. 팀 프로세스가 규정한 단위 테스트 없이 어떤 코드도 체크인하지 못하도록 요구한다고 가정하자. 이는 팀 프로세스(코드를 체크인하는 단계)와 개인적인 프로세스(테스트를 반드시 수행해야 하는 단계) 사이에 인터페이스를 나타낸다. 코드 구현 전에 개인이 테스트를 작성할지, 코드 구현이 끝난 다음에 테스트를 작성할지가 중요한가? 프로세스 인터페이스 계약에 따르면 그렇지 않다. 단지 코드는 테스트와 함께 움직여야 한다는 사실만 요구한다. 개발자에게는 최고로 적합한 작업 방법을 선택할 자유가 있다.
여기 고차원 예제가 있다. 프로젝트 프로세스가 RUP 중심 유스 케이스에 기반을 두고 진행 상황을 추적하지만, 팀은 XP 중심 사용자 스토리를 사용해 진행 상황을 추적하도록 결정했다고 상상해보자. 보고할 시점에서, 사용자 스토리를 유스 케이스에 어울리게 만들고 유스 케이스에 기반을 두고 보고할 시점에서 어댑터 활동이 필요하다.11 확실히 불필요한 부하라고 주장할지는 모르겠지만, 사용자 스토리를 사용할 때 개발 팀이 좀 더 효율적으로 일할 수 있다면 유스 케이스로만 작업을 강제하는 경우와 비교해 이 정도 부하는 가치가 있다. 좀 더 상위 단계 프로세스를 변경할 수는 없다. 클라이언트, 고객이 버티고 있으며, 보고 요구 사항이 무엇인지 결정되어 있기 때문이다.
제대로 설계된 프로세스 인터페이스는 하위 단계 프로세스에 대해 최소 요구 사항만 지시해야 한다. 요구 사항이 너무 엄격하다면, 하위 단계 프로세스는 과업을 효율적으로 수행하는 대신 프로세스에 빠져 옴짝달싹 못하게 된다.
마이크로 프로세스는 협력을 추구해야 한다
지금까지 토론한 내용을 살펴보면, 다양한 단계에서 프로세스에 대해 언급했다. 마치 프로세스는 목표 단계에서 엔티티 요구를 완벽하게 충족하는 잘 정의된 엔티티이며, 팀 프로세스는 팀이 수행하는 모든 작업을 망라하는 단일 프로세스인양 취급했다. 이는 환상이다. 단일 프로세스는 존재하지 않으며, 수많은 좀 더 작은 프로세스가 맞물려 돌아가며 해당 단계에서 겉으로는 통합된 프로세스를 형성한다. 이런 마이크로 프로세스 몇 가지는 서로에게 의존하며 몇 가지는 상호 작용한다. 마이크로 프로세스가 부드럽게 상호작용을 해야하므로 마이크로 프로세스 선택은 해당 단계에서 다른 마이크로 프로세스에 의존한다.
몇 가지 마이크로 프로세스 예제는 내가 의미한 바를 설명한다.
- 팀을 위한 원시 코드 관리(SCM, Source Code Management) 실천: 에를 들어, 다른 사람이 검토하고 코드(그리고 테스트)가 올바르다고 동의하지 않으면 어떤 파일도 체크인이 불가능하다.12
- 상태 카테고리, 경향, 문제 추적과 같은 표준을 설정하는 결함 추적 프로세스는 일반적으로 프로젝트나 전사적 프로세스다. 결함 대응 방식을 정의하는 표준은 프로젝트나 팀 프로세스에 위임해야 한다.
- 코딩 표준과 이름 관례는 일반적으로 프로젝트나 전사적 단계에서 결정해야 한다.
- 작업 할당 관례는 팀마다 다르다. 각 팀마다 합의한 관례에 따라 누가 무엇을 할지 결정하는 다양한 방법이 존재한다.
모든 마이크로 프로세스는 서로서로를 지원해야 하며, 프로세스 인터페이스에 따라 상위 단계에 존재하는 프로세스를 지원해야 한다. 프로세스 단계 사이에 맺어진 관계는 그림 3에서 보듯이 조직 내 두 단계 프로세스로 설명할 수 있다.
그림 3: 프로젝트와 팀이라는 두 단계와 각 단계에서 함께 협력해야 하는 마이크로 프로세스 사이의 관계
그림 3에서 마이크로 프로세스 사이에 SCM 프로세스와 상태 보고 프로세스라는 인터페이스가 둘 있다. 팀 프로세스 사이에서 모든 기어가 제대로 맞물려 돌아가며, 두 단계를 연결하면서 돌아가는 프로세스가 제대로 맞물려 돌아가게 만드는 방법도 찾으면 프로세스는 제대로 동작한다.
내 생각에, 이런 모습은 프로세스 공학이 추구하는 진짜 기술을 보여준다. 최대한 낮은 프로세스 단계에서 엔티티에 자유를 부여하는 방법으로 단계 사이에 필요한 동기화를 제한하며 만드는 능력 말이다.
이 모든 사항을 합치면 뭐가 될까?
지금까지 말한 내용이 애자일 2006과 개막 연설과 어떤 관련이 있는가? 지금까지 팀 크기와 프로세스 단계에 대한 사고 방식을 설명하면서, 컨퍼런스에 참여한 애자일 공동체가 주로 팀 단계 프로세스를 살펴보리라고 가정할 수 있다. 물론 생각이 있는 몇몇 리더는 다르게 주장할지도 모르겠다. 초기에 언급했던 바와 같이 좀 더 작은 조직이 전사적인 조작으로 자라나면 애자일 방법론이 전사적이거나 프로젝트 단계에서 충분하지 않다는 사실을 자각하며 프로세스를 반드시 변경해야 한다.
나를 불안하게 만드는 요인이자 "애자일을 가르치지 않는" 이유 중 하나는 사람들이 단지 한 가지 접근법만 손에 쥐고 있으면 세상에 대해 보는 시각이 좁아지기 때문이다. 사람들은 단지 현재 환경이 허용하는 범위까지만 보려고 한다. 애자일 컨퍼런스에서, 나는 관리자가 참견을 그만두고 각자 작업하도록 놓아두면 상황이 훨씬 더 나아지지 않겠느냐는 말을 듣곤 한다. 여기서 관리 사슬 위로 올라갈수록 좀 더 실수가 많아지고 올바른 결정을 내릴 만한 제대로 된 사람을 찾기가 어렵다는 느낌을 받았다. 하지만 상위 단계에 있는 관리자는 종종 회사를 창립했거나 회사에서 좀 더 전략적인 임무를 맡아 승진한 사람이라는 사실이 중요하다. 활동 영역이 다르며, 개발팀과 가치도 다르다. 개발자는 회사가 이익을 내려면 이런 사람들이 뭔가 올바른 일을 해야 한다는 사실을 자각할 필요가 있다. 형편 없는 리더십에도 불구하고 제대로 이익을 내는 회사는 너무나도 많다!
개발자가 단순히 팀 프로세스를 넘어 더 많은 사항을 이해하고 일반적인 비즈니스 프로세스에 대해 배우기 시작해야 한다고 믿는다. 여기서 두 가지 긍정적인 결과를 얻는다. 첫 번째로 상위 단계 프로세스와 현 단계 프로세스를 연결하는 인터페이스를 어떻게 하면 개선할지를 알게 된다. 두 번째로 회사의 좀 더 전략적인 노력을 감사하게 여기며 개발팀이 좀 더 높은 목표에 기여할 수 있는 바를 찾는다. 이런 지식은 회사에 대한 개발팀 가치를 드높인다. 낮은 단계 프로세스로 일하는 새로운 신입 사원을 고용할 때, 큰 그림을 이해하고 있다면 신입 사원들이 회사와 호흡이 맞는지를 재빨리 파악하는 과정에 도움이 된다. 작업 과정에 선호하는 방식이 개인 프로세스와 불일치하는 바람에 여러분이나 회사나 함께 일하는 과정에서 득이 없다는 사실을 고백해도 죄책감을 느낄 필요가 없다. 오히려 인사 고과나 퇴직자 면담에서 밝혀지는 경우보다 최대한 빨리 밝혀지는 편이 좋다.
프로세스는 중요하지만 프로세스가 하나만 존재하지는 않는다. 회사 내부에는 여러 프로세스가 여러 단계에 걸쳐 있다. 프로세스가 함께 일하기 위해 필요한 방법이라는 이해는 아주 중요한 깨달음이지만, 너무나 자주 무시된다. 실제 프로세스가 요구하는 바를 이해할 때, 현재 따르고 있는 구체적인 프로세스 작은 그림 하나는 다른 프로세스와 제대로 어울려 돌아가는 큰 그림에 비해 그리 중요하지 않다는 사실도 이해할 것이다.
참고
1 Gary Pollice, "Matching project and process," The Rational Edge, 2004년 5월: http://www.ibm.com/developerworks/rational/library/4720.html
2 http://www.yourdictionary.com에서 발췌
3 의사 소통 채널과 링크에 대해 말할 때, 단지 직접적인 개발 팀원에 대한 이야기만 하며, 팀 외부에서 벌어지는 의사 소통 링크는 제외한다. 설명을 단순하게 만들 목적으로 이런 제한을 가한다.
4 표기법에 익숙하지 않은 사람을 위해 설명하자면, n!은 1부터 n까지 모든 정수곱이다. 따라서 4! = 4 x 3 x 2 x 1 = 24다.
5 여기서 "경량"이라는 단어를 사용함으로써, 의미상 어두운 영역에 들어서고 있다는 사실을 알고 있다. 독자들이 현재 맥락에서 시간 낭비를 초래하는 부언 설명없이 이 단어를 그냥 사용하도록 내버려두리라 믿는다.
6 오늘날 나는 일반적으로 테스트 케이스를 먼저 작성한다. 하지만 이야기 흐름에 중요한 내용은 아니다.
7 가명이다.
8 Alistair Cockburn, Agile Software Development. Addison-Wesley 2001, ISBN 0201699699.
9 원시 코드와 문서를 고객에게 제공해야 한다는 계약 조건 하에서 소프트웨어를 개발 중인 상황일지도 모른다. 심지어 이런 문서 수준도 심하다고 여길지 모른다.
10 개발자들은 어댑터 설계 패턴에서 유사성을 떠올릴 것이다.
11 RUP는 IBM Rational Unified Process이며 XP는 eXtreme Programming이며, 둘 다 소프트웨어 개발 프로세스다. 물론 RUP는 초대규모 프로젝트까지 확장 가능하다.
12 개인은 짝 프로그램이나 사후 검토를 통해 이런 요구 사항을 충족할 수 있다.
필자소개 | 
| | Gary Pollice는 메사추세스 주 우스터에 있는 우스터 폴리테크닉 대학에서 교수를 맡고 있다. Pollice는 소프트웨어 공학, 설계, 테스팅을 비롯해 다른 전산 과목을 가르치며, 학생들 프로젝트도 직접 챙긴다. 학계에 오기 전에, Pollice는 비즈니스 응용 프로그램부터 컴파일러와 각종 도구에 이르기까지 35년 동안 소프트웨어를 다방면으로 개발해왔다. 마지막으로 업계에 몸담은 곳은 IBM® Rational® 소프트웨어로, "RUP 옹고집"로 알려져 있으며, 원래 Rational Suite 팀 일원이기도 했다. Pollice는 Addison Wesley 출판사가 2004년도에 출간한 Software Development for Small Teams: A RUP-Centric Approach 주요 저자이기도 하다. Pollice는 수학 학사와 전산학 석사를 취득했다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
