프로젝트 어떻게 빠르게 죽일수 없을까?

출처: http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=28&no=126&page=1

제목이 좀 도발적이죠?

이글의 실제 내용 "Quick-Kill Project Management"와 제목을 연관시키려다 보니 이렇게 되었네요.

얼마전 여기 Devpia에 링크되어있는 "노땅엔지니어의 노트"에서 본것 같은데, 우리 나라의 낮은 개발자 처우, 너무 과도한 프로젝트와 빡빡한 일정 이런것 어떻게 바꿔야 하지 않겠는가 하는 글을 읽은 적이 있었습니다.

물론 처우 개선 할것은 해야하지만 현실이 쉽게 바뀌지 않는다면 우리 자신이 이런 상황을 타개해 나가야 하지 않을까요?

"Quick-Kill Project Management"이라는 기사를 인터넷에서 읽고 과중한 프로젝트 압박은 비단 우리 나라에만 있는것은 아닐성 싶었습니다.

필요는 발명의 어머니라고 하지 않았던가. 이 지구상의 수많은 사람들중 어떤 한 사람이라도 같은 고민을 하고 있을겁니다. 그리고 운 좋으면 해결책까지 이미 가지고 있고요. 요즘 뭐 개발 하라고 하면 인터넷에 비슷한 소스 있나 먼저 찾아보는 이유도 다 이런 범주에 속하겠죠.

이글은 말그대로 성공적인 프로젝트 수행을 위한 빠른 프로젝트 관리 기법을 소개한 글입니다. 개발 5년차가 넘어가서 이제 프로젝트 관리까지 담당을 해야하는 개발자겸 책임자에게 도움이 될것 같아 이렇게 올립니다.

꼭 기법을 배우지 않더라고 글 중간중간에 닥치는 상황과 고민이 어쩜 나하고 같지 하는 공감을 불러 일으키리라 봅입니다.

영문 원문을 바로 읽으시려는 분은 http://www.ddj.com/architect/189401902 로 가시면 됩니다.

이곳에 있는 것을 좀 서투른 영어지만 성심껏 번역했습니다.

번역본 word 파일이 필요하시면 제 블러그에서 가시면 있습니다.

자!! 이 부분부터 번역한 글입니다.

__________________________________________________________________________________________

빠른 처리(Quick-Kill) 프로젝트 관리

 극히 불가능한 일정에 직면했을 때 조차 현명하게 소프트웨어를 개발 하기

 저자:  Andrew Stellman and Jennifer Greene

작성일: 30, 2006년 6월 30

출처: Dr. Dobb's Journal(http://www.ddj.com/dept/architect/189401902)

 앤드류와 제니퍼는 “Applied Software Project Management (O'Reilly & Associates)” 책의 저자이다.

 당신이 다섯 명으로 이루어진 개발 팀 리더라고 하자. 한 프로젝트에 몇 주 동안 매달린 결과, 팀이 막 결과물을 내놓기 시작했다. 팀은 경력상으로 고참 설계자로부터 학교를 갓 졸업한 초보 프로그래머에 이르기까지 다양하게 구성되었다. 그때 당신의 상관이 당신을 불러 부사장이 전화로 자기를 씹어대며 어제까지 그 프로젝트가 끝났기를 바랬다고 말한다. 알려진 바와 같이 이 프로젝트는 확연히 드러나고 오랫동안 약속된 것이다. 고객은 이 소프트웨어로 처리할 일이 있고 이 소프트웨어는 매우 중요하다. 만약 이게 잘 안 돌면 당신은 옷 벗을 생각을 해야 한다.

 일전에 이런 종류의 높은 압박 속의 팀에 있었다면 그 프로젝트는 악몽이었을 것이다. 팀원들이 몇 날을 헤매고 있고 당신은 영웅 역할을 해야 해서 심각한 설계 오류를 고치기 위해 뛰어 들어가 주말 40시간 일을 한다. 고참 관리자와의 끝없는 회의와 결코 없어지지 않는 끈질긴 버그들과 야밤의 너무 많은 커피와 피자가 있다. 그리고 마침내 팀이 어떤걸 내놓자, 고객은 그것을 싫어한다. 그들이 버튼을 누를 때 마다 버그가 있고 그들이 기대했던 어떤 것도 그 소프트웨어 전체 기능 안에는 전혀 구현이 안된 것처럼 보인다.

 

빠른 처리(Quick-Kill)

요즈음 많은 팀들은 이런 상황에 놓여있고 개발 책임자는 심각한 도전에 직면해있다. 그는 직접적으로 그의 팀을 관리할 필요는 없지만 그 소프트웨어가 출시될 수 있게 하는데 책임이 있다. 팀은 그를 존중하고 그가 결정 하면 사람들은 보통 그를 따른다. 그렇지만 개발 책임자의 일은 관리가 아니라 개발에 있다. 그는 솔루션과 소프트웨어 설계와 코드를 작성하는데 대부분의 시간을 보낸다.

 이상적인 프로젝트 관리는 전담 프로젝트 관리자가 있거나 아주 많은 프로젝트 준비 시간을 필요로 한다. 하지만 당신이 팀을 이끌고 있고 올바른 프로젝트 관리를 위한 시간도 예산도 없다면 어떻게 하겠는가? 이런 자리에 있는 사람이 어떻게 시작해야 하는지 조차도 어려운 일이다. 이것이 “빠른 처리(Quick Kill)”의 탄생 배경이다 – 프로젝트에서 가장 큰 문제들만을 처리하기 위한 아주 범위를 좁힌 시스템. 다르게 말하면 프로젝트 책임자들에게 가장 적은 비용으로 큰 이익을 얻게 하는 행동 강령이다.

 빠른 처리(Quick-kill) 프로젝트 관리는 상관이 기대하고 고객이 필요로 하는 제품이 산출될 수 있게 돕는 세가지 기술로 구성된다.

• 비전과 범위 문서(Vision and scope document)

• 작업 세분화(Work breakdown structure)

• 코드 검토(Code review)

위의 각 기술을 실행하는 데는 시간이 얼마 걸리지 않고 팀이 대부분의 일반적이고 큰 비용을 치러야 하는 프로젝트의 큰 위험을 회피할 수 있게 한다. 이것들을 사용하여 책임자는 만족스러운 소프트웨어를 만들 수 있는 확률을 여러모로 높일 수 있다.

 

비전과 범위 문서: 최대 6시간

만약 팀이 어떤 소프트웨어를 만들고 있는지를 실제 이해하지 못하면 프로젝트 전 과정에 걸쳐 잘못된 결정들을 내릴 소지가 더 농후하다. 팀은 이러한 잘못된 결정들을 고치기 위해 귀중한 시간을 허비해야 하거나 만약 고치지 않고 남겨 프로젝트가 고객의 필요를 충족하지 못했을 때 고객에게 사정해야 할 상황에 놓이게 된다. 프로젝트 실제 범위에 대한 올바른 이해 없이 팀은 촉박하다는 것만을 보게 되고 그들이 채워야 하는 요구 사항에 대한 궤도를 잃게 된다. 프로그래머들은 큰 그림을 보지 못하고 그들이 해결 하고자 하는 일의 개별적인 문제만을 볼 수 있다. 그리고 이것은 프로젝트 실패와 지연을 야기시키는 가장 큰 단일 원인이다.

다행히도 팀이 이러한 문제를 회피하게 만드는 간단하고 실행에 옮기기 쉬운 것이 있다. 비전과 범위 문서를 작성하는 데는 하루가 안 걸리고 이는 팀이 몇 주의 재 작업과 잘못된 시작을 하지 않도록 하는데 도움이 된다.

비전과 범위 문서 작성의 첫 번째 단계는 프로젝트 관계자와 이야기 하는 것이다. 불행히도 누가 관계자인지 항상 분명한 것은 아니다. 프로젝트 책임자는 어떤 사람이 그 프로젝트에 의해 가장 영향을 받을 지를, 그것을 그가 사용하는 것을 계획했기 때문인지 또는 개발 되는 것에 대한 다소 책임이 있기 때문인지를 파악해야 한다. 바꾸어 말하면 책임자는 그 소프트웨어가 개발이 안되었다면 누가 가장 어려워질 건지를 찾아야 한다. 개발 책임자가 또는 가능하면 다른 팀 구성원들까지도 관계자들과 꼭 해야 할 일이다. 이러한 요구 사항을 수집하는 것은 관계자 한 사람당 한 시간이 안 걸릴 것이다.

비전과 범위 문서(표1)는 몇 페이지가 넘지 않게 간단해야 한다. 관계자들과 대화를 통해 팀이 수집한 모든 정보는 문제 서술 장(Problem Statement section)에 추가되어야 한다.

1. 문제 기술(Problem Statement) a. 프로젝트 배경(Project Background) b. 프로젝트 관계자(Stakeholders) c. 사용자(Users) 2. 솔루션의 비전(Vision of the Solution) a. 비전 서술(Vision Statement) b. 기능 목록(List of Features) c. 개발에서 제외된 기능(Features That Will Not Be Developed)

표 1: 비전과 범위 문서 윤곽

 프로젝트 배경 장은 그 프로젝트가 해결해야 할 문제를 요약한다. 문제의 간단한 이력과 어떻게 그 조직이 그 문제를 다루기 위한 소프트웨어 개발을 결정했는지에 대한 설명을 제공해야 한다.

 프로젝트 관계자 장에는 관계자들을 기술한다. 개개의 관계자는 이름, 직책 또는 역할(지원 부서 관리자, SCTO, 선임 관리자)에 의해 언급될 수 있다. 각 관계자의 요구 사항은 몇 문장으로서 기술된다. 사용자 장은 사용자들 목록을 포함하여 비슷하게 작성된다. 관계자들에 대해 했던 것 같이 각 사용자도 이름 또는 역할(고객지원 상담자, 통화 품질 감사, 가정에서 사용하는 웹 사용자)에 의해 언급될 수 있지만 만약 많은 사용자가 있다면 각 사용자를 지칭하는 것은 보통 비효율적이다. 각 사용자의 요구사항은 기술된다.

 사용자와 관계자의 요구 사항은 이 문서에서 가장 중요한 부분이다. 팀이 그 프로젝트를 이끄는 요구 사항을 이해하지 못하면 관계자들에게는 사소한 문제를 처리하기 위해 팀의 시간을 소모시키는 원인이 되는 지협적인 초점에 매달릴 수 있다. 잘못된 문제를 해결하는 거대한 소프트웨어를 만들기는 쉽다. 적절한 소프트웨어를 만들기 위한 단 한가지 방법은 일이 시작되기 전 왜 어떻게 소프트웨어가 만들어져야 하는지에 대해 프로젝트 참여자의 모든 사람의 이해와 동의를 구하는 것이다. 이것이 프로젝트 계획의 목적이다.

 비전과 범위 문서의 비전 부분은 소프트웨어의 최종 목적에 대한 설명을 일컫는다. 모든 소프트웨어는 특정 사용자와 관계자의 요구를 충족하기 위해 만들어진다. 팀은 그러한 요구 사항을 식별하고 비전 기술서(어떻게 그런 요구 사항이 충족될 것인지를 설명하는 비전 기술서)를 작성해야 한다. 비전 기술서 장의 최종 목표는 성취하기 위해 무엇이 프로젝트에 기대되는가를 기술하는 것이다. 프로젝트의 목적이 설명되어야 한다. 이 목적은 프로젝트에 소비되는 시간, 돈, 자원에 대한 필수 불가결한 이유와 합당한 타당성이 있어야 한다.

 "기능 목록"과 "개발에서 제외된 기능" 장들은 무엇이 구현되고 구현되지 않을 것인지에 대한 정확한 목록을 담아야 한다. 이 장들을 쓰기 전에 팀은 문서 나머지 부분을 작성해야 하고 충족시키고자 하는 요구사항에 대해 열린 회의를 해야 한다. 팀은 종종 확실해 보여서 어떤 기능을 도출하지만 실제 필요하지 않는 것으로 판명이 되는 것이 있다. 이와 같은 기능들은 "개발에서 제외된 기능"에 기술해야 된다.

 

작업 세분화 구성(Work breakdown structure):  2 시간

 만들 기능들에 대해 작업 들어가기 전에 책임자는 팀과 함께 각 기능을 구현하는데 얼마가 소요될 것인가 하는 추정 목록을 마쳐야 한다. 많은 개발자들은 추정을 크게 어려워한다. 다행히도 추정 단계를 보다 직관적이고 신뢰성 있게 만드는 다소의 지침들이 있다.

 추정 단계는 팀 구성원이 프로젝트의 모든 관점을 생각하게끔 하는 것으로 중요하다. 대부분 프로그래머들은 그들이 예측 했던 작업량보다 나중에 더 일이 많음을 알게 될 때 위축되게 된다. 만약 다른 팀 구성원이 그 일에 의존하고 있다면 전체 프로젝트에 혼선이 일 것이다. 올바르게 추정하는 것은 팀이 모든 현격하고 일반적인 실패를 회피할 수 있도록 한다. 프로젝트 추정은 끝마치기 위해 필요한 절차와 각 절차가 요구하는 처리가 몇 일(주, 달, 시간 등등) 걸릴 것인지를 팀이 미리 도출하게끔 만든다. 이러한 단계와 소요 시간을 구하기 위한 유일한 방법은 하지 않으면 프로젝트 후반에까지 남겨질지 모르는 많은 상세한 사항들을 한 팀으로써 모여 앉아서 생각하는 것이다.

 추정하기 위한 첫 번째 단계는 그 프로젝트를 최종 제품에 포함될 작업 목록으로 쪼개는 것이다. 이 목록을 “작업 세분화 구성(work breakdown structure: WBS)”라고 부른다. 프로젝트를 “작업 세부화 구성”으로 나누는 여러 방법이 있다. 책임 개발자는 팀원들과 이 작업 목록을 토의할 회의를 가져야 한다.

 가장 유용한 법칙은 어떤 프로젝트라도 10에서 20개의 작업으로 쪼갤 수 있다는 것이다. 예를 들어 우주선 프로젝트와 같이 큰 프로젝트의 작업들은 “항해 시스템 시험”과 같이 아주 클 것이고 간단한 계산기 작성 같은 작은 프로젝트는 “덧셈, 곱셈, 두수의 곱셈을 위한 산술 객체의 제작”과 같이 작업들이 작을 것이다. 팀원들과 작업 목록에 대해 회의는 한 시간이 안 걸려야 한다.

 일단 팀 구성원들이 “작업 세분화 구성”에 동의하면 각각에 대해 추정할 수 있도록 각 작업에 대한 토의를 시작할 수 있다. 프로그램 초기 단계에는 팀 구성원들이 추정에 필요한 모든 정보를 갖지 못했지만 어쨌든 수치를 뽑아내야 한다. 부족한 정보를 메우기 위해 할 일에 대한 가정 해야만 한다. 가정 했으므로 팀 구성원은 보다 정확한 추정을 나중에 추가하기 위한 정보에 대해서는 표시를 남길 수 있다.

가정은 추정에 있어 매우 중요한 요소이다. 만약 두 사람이 얼마나 걸릴 것인가에 대해 동의하지 않는다면 그 원인은 일의 세부적인 내역 또는 그것을 도출하기 위한 전략에 대해 서로 다른 가정을 했다고 할 수 있다. 달리 표현하면 이 의견 차이는 보통 그것을 끝내기 위해 들인 노력에 관한 것이 아니라 그 일 자체를 하기 위해 무엇이 필요한 것인가에 관계된다. 예를 들어 컴퓨터 시간을 설정하는 툴에 대한 비전(vision)과 범위(scope) 문서를 주면 두 개발자는 아주 다르게 추정할 수 있다. 한 개발자는 간단한 명령 입력 방식이라고 생각하는 반면 다른 개발자는 운영 체제의 제어판과 완벽하게 통합되는 사용자 인터페이스를 가져야 한다고 가정할 수 있다.

 책임자는 다른 프로그래머들이 이러한 가정들을 의논하게 하고 그들의 다른 견해에 관해 임시적인 결정을 하게 함으로써 그 작업에 대한 하나의 추정에 동의하도록 도울 수 있다. 책임자는 차례로 각 작업을 꺼내고 각 작업에 대해 팀이 얼마나 걸릴 것 인가를 결정하게 해야 한다. 의견 차이가 발생할 때 마다 가정하는데 있어 무언가를 놓치고 있는 것을 의미한다. 책임자는 그 가정들이 무엇인지를 정확히 밝히기 위해 나머지 팀 구성원과 같이 처리해야 한다. 이것들이 밝혀지면 기록해야 한다. 회의가 진행 될수록 더 많은 가정들이 쓰여지면 팀 구성원들은 그 프로젝트에 관해 더 많이 알게 된다. 그리고 어떤 소프트웨어를 만들어야 할지를 토의 할 것이다. 이것은 그 팀이 각 작업에 대한 추정들을 취합하게 돕는다.

 최종 “작업 세분화 구성”은 작업 목록과 각 작업에 대한 추정, 작업에 대한 가정한 목록으로 구성 되야 한다. “작업 세분화 구성”의 10에서 20개의 작업에 대한 가정과 추정을 도출하는데 대략 한 시간이 소요 되야 한다. “작업 세분화 구성”을 만들고 예측을 하는 총 시간은 보통 두 시간 정도이다. 보통의 다섯 사람이 하는 프로젝트의 기본 추정 시간으로서는 충분하다. 그렇지만 큰 프로젝트이면 팀을 나눌 필요가 있고 각 나뉜 팀은 두 시간씩의 추정 시간을 가질 수 있다.

 

코드 검토: 한 검토 건수당 2.5 시간

 코드 검토란 팀이 샘플 코드를 검사하고 거기에 오류가 있으면 고치는 것이다. 오류라고 하는 것은 프로그래머가 의도하는 대로 동작하지 않거나 잘못되지는 않았지만 개선될 수 있는 여지가 있는 것을 일컫는다. 예를 들자면 보다 가독성 있게 만들거나 성능이 향상될 수 있는 것이라 할 수 있다.

 코드 검토의 첫 번째 작업은 검토할 샘플 코드를 선택하는 것이다. 코드 전체 줄을 검토하는 것은 불가능 함으로 프로그래머는 검토할 코드 부분을 선택할 필요가 있다. 검토에 적당한 코드를 선택하면 보다 효율적인 검토작업이 된다. 대부분의 프로젝트에서 밝혀진 바로는 대부분의 오류는 비교적 작은 코드 조각에 집중되는 경향이 있다. 코드가 잘 선택되면 이 검토는 만약 남겨진다면 나중에 그것을 찾아 고치는 비용보다는 훨씬 적게 들게 된다.

 책임 개발자에게 검토를 위한 적당한 코드를 선택하는 일을 어렵지 않다. 좋은 검토 후보 코드는 이상한 알고리즘을 구현하거나 어려운 API 또는 객체 인터페이스를 사용한 것, 유지보수하기 위해 전문 기술이 요구되는 것, 새로운 기술을 수용한 것이 될 수 있다. 오류가 있으면 큰 재앙을 불러일으킬 위험이 큰 부분의 코드를 선택하는 것은 특히 유용하다. 보다 더 많은 오류가 있을 성 싶어서가 아니라 보다 많은 사람들이 전적으로 그것에 의존할 수 있기 때문이다. 소프트웨어 많은 부분에 큰 변경을 요구하는 큰 수정이 있으면 오류를 불러일으킬 위험이 높다. 이런 코드 또한 좋은 후보이다.

 검토를 준비하기 위해 책임자는 줄 번호가 있이 인쇄한 선택한 코드를 각 팀 구성원에게 배포한다. 팀 구성원 각자는 개별적으로 샘플 코드를 한 시간 반에 걸쳐 가능하면 실행도 해보면서 읽는다. 그들은 작성자가 하고자 한 의도대로 코드가 진짜 동작하는지 밝히기 위해 최선을 다해야 한다. 그들은 정확성, 유지보수, 신뢰성, 견고함, 보안, 확장성, 재 사용성, 효율성에 문제가 있는지 찾아야 한다. 이것 중 어떤 것이라도 오류로 간주된다. 각 팀은 최대한 많은 오류를 찍어내어 복사본에 표시한다.

 각자의 준비가 끝나면 팀 책임자는 검토회의를 위해 모두 모은다. 코드 검토는 책임 개발자가 큰소리로 최초의 코드 조각을 읽는 것으로 시작된다.  그는 말 그대로 코드에 쓰여진 명령을 읽는 것이 아니라 코드 조각의 목적에 대해 간단한 설명을 한다. 만약 책임자를 포함해서 누구라도 코드가 뭐 하기 위한 건지 이해하지 못하거나 그 해석에 동의하지 않으면 코드 작성자가 그 코드가 어떤 것을 이루기 위함이었는지 설명한다. 종종 팀 구성원이 동일한 것을 구현하기 위해 보다 좋은 제안을 할 수 있지만. 문제 제기한 사람에게 단순히 코드의 목적을 설명하는 정도이다.

 팀 구성원은 그 다음에 코드 조각에서 발견된 모든 오류에 대해 의논한다. 바로 이 지점에서 책임자가 회의 사회자로 나서야 한다. 만약 누구라도 오류를 발견하면 책임자는 그 시점에서 고칠 건지 여부를 결정한다. 책임자가 구성원들이 고칠 수 있다 판단되면 그렇게 한다. 그렇지 않으면 책임자는 코드 작성자가 나중에 고쳐야 할 문제점으로 기록한다. 어떤 경우든 책임자는 검토이력을 담는 스프레드 시트 한 행을 추가해 기록한다. 스프레드 시트에 한 오류당 한 행을 작성하며 각 행은 오류를 가지고 있는 줄 번호, 누가 발견했는지 어떻게 해결했는지 또는 아직 해결이 안된 문제라는 표시를 담는다.  사회자는 이 이력의 위 부분에 언제 회의가 있었고 어떤 조각의 코드를 검토했는지 적어야 한다.

 이 회의는 두 시간을 초과해서는 안 된다. 만약 이것보다 더 걸리면 다음 코드 검토에서는 더 간단한 샘플 코드를 선택해야 한다. 만약 회의가 끝나면 책임자는 나머지 팀원에게 검토 이력을 이메일로 보내고 해당 코드에 책임이 있는 사람에게 수정을 지시한다. 오류가 수정된 후 그는 수정된 코드를 검토하고 잘 고쳐졌는지 확인해야 한다.


출처 : http://retroreflex.com/121