지난해 10, 미국의 북동부 지역은 어딜 가나 아셀라(Acela) 광고 천지였다.아셀라란 암트랙(Amtrak) 워싱턴-보스턴간 노선에서 운행할 새로운 초고속열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도  정도의 물량 공세라면  새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다.


글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해  기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한달 앞두고  제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는말이 떠오른다. “대단한 홍보 효과야! 이럴  시장에 물건만   있었으면얼마나 좋았을까!”


남성호르몬이 철철 넘치는 게임 업체들은 자사 웹사이트에 제품 개발이 완료되는 대로 새로운 게임이 출시될 것이라고 떠들어대기를 좋아한다. 스케줄?스케줄 같은  필요하지 않다. 그들은 나는 게임 개발자들이니까! 하지만,대부분의 평범한 소프트웨어 업체들에게는 스케줄이 필요하다. 로터스의 경우가  좋은 예로, 로터스사가 처음 123 버전 3.0 개발을 완료했을   소프트웨어는  당시만 해도 아직 보급 대수가많지 않던 80286 기종의 컴퓨터를 필요로 했다. 로터스는 제품 출시를 16개월이나 미뤘고  기간 동안 8086 기종의 메모리 한계인 640K 맞춰 제품의 용량을 줄였다. 수정된 제품이 완성되었을 때엔 이미 엑셀을 시판중인 마이크로소프트사가 시장에서 16개월 정도 앞서나가고 있었으며,  무슨 가혹한 운명의 장난인지, 8086 기종은 이미 시장에서 폐물 취급을 받고 있었다!


 글을 쓰고 있는 지금도 넷스케이프의 인터넷 브라우저 5.0 경쟁사에 비해 거의 2가까이뒤쳐져있다. 개발된 코드를 모두 폐기하고 처음부터 코딩을 다시 시작하는 치명적인 실수를 저질렀기 때문이다. 애시톤-테이트, 로터스, 애플사의 MacOS 등도 똑같은 실수를 저지르는 바람에 소프트웨어 역사의휴지통(Recycle-bin) 속으로 내던져지는 신세가 되고 말았다.  사이 넷스케이프사의  브라우저의 시장점유율은 80%대에서 20%대로 곤두박질쳤지만 회사는 아무것도   없었다. 주력 소프트웨어 제품이 산산조각으로 분해되어 있는 상태에서는 달리 손을   있는 방도가 없었기 때문이다.  한번의 잘못된 결정이 넷스케이프를 자폭시킨 핵폭탄이  셈이었다. ( 자세한내용은 Jamie Zawinski  world-famous tantrum 참조한다).


그래서, 스케줄관리가필요한것이다. 거의 모든 프로그래머들이 하기 싫어하는 일이 바로 스케줄 관리다. 필자의 경험에 따르면, 대다수의 프로그래머들은어떻게 해서든 스케줄 같은  아예 짜지 않고 버텨 보려고 든다. 스케줄을 짜는 극소수의 프로그래머들도 대부분 상사가 하라고 하니까 억지로 하고 있을,  스케줄대로 프로젝트가 진행되리라고 믿는 사람은  상사 밖에 없다. 상사는 스케줄을 믿는 한편으로, “기한 내에 완료되는 소프트웨어 프로젝트는 없다고도 믿으며 , UFO 존재도 믿는 사람이다.

그렇다면,  아무도 스케줄을 만들려 하지 않을까? 주된 이유는  가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고,  번째이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체  그런 수고를 해야 한단 말인가? 스케줄이란 애당초 지켜지는 법이 없고 시간이 지날수록 현실과의 괴리는점점  커지기만 하는데,  하러 그런 헛수고를 한단 말인가?


여기, 정확하게지켜지는스케줄을만드는간단하고손쉬운방법이있다.


1) 엑셀프로그램을사용하라. MS Project 같은 거창한 프로그램을 사용하려들지 말라. MS Project 사용자가 종속성의 문제를 해결하기 위해 많은 시간을 할애할 것이라는 가정하에 만들어진 프로그램이다. 종속성이란,  가지 작업을 진행해야 하는 상황에서 하나의 선행 작업이 먼저 완료된 후에만 다음 작업을 시작할  있는 경우를 말한다. 소프트웨어 프로젝트의 경우, 작업들간의종속성은 너무나 당연한 것이기 때문에 굳이 수고스럽게 종속성을 추적할 필요가 없다.

MS Project 사용하는 경우에 생길  있는  다른 문제는  프로그램을 사용하다 보면 자꾸 스케줄 균형 조정 기능을 실행하고 싶어진다는 것이다. 스케줄 균형 조정에는 불가피하게 모든 작업을 재조정하여 다른 사람에게 재할당하는 과정이 포함되는데, 소프트웨어 프로젝트의 경우 이런 재조정은 말이되지 않는다. 프로그래머들간의 호환이 불가능하기 때문이다. 가령, 리타가 작업한 코드의 버그를 존이 수정하려면 리타 자신이 수정할 때보다 시간이 일곱배는  걸린다. , UI 담당 프로그래머에게 WinSock 관련된 문제를 해결하라고 시키면, WinSock 프로그래밍에 익숙해지는 데에만 일주일은 걸릴 것이다. 결론은 MS Project 소프트웨어 개발 프로젝트보다는 건축 공사 프로젝트에 적합한 프로그램이라는 것이다.


2) 단순하게만들라. 필자가 이용하는 스케줄 포맷은 너무나 단순해서 한번만봐도 기억할  있을 정도다. (컬럼) 개수는 일곱 개면 된다.

개발자가 여러 명인 경우에는 개발자별로 시트를 각기 따로 만들 수도 있고,아니면  작업을 담당하는 개발자의 이름으로 컬럼을 만들 수도 있다.


3) 하나의기능은여러개의작업으로분해하라. 여기서, 기능이란 프로그램에추가되는 맞춤법 검사 기능 같은 것을 말한다. 실제로 맞춤법 검사 기능을 추가하려면, 프로그래머는 여러 단계의 작업을 수행하게 된다. 스케줄을  가장 중요한 부분은 바로 이와 같은 구체적인 작업들의 목록을 만드는 것이다.따라서 다음 규칙을 명심해야 한다.


4) 코딩을직접담당할프로그래머만이스케줄을만들있다. 관리자가 임의로만든 스케줄을 프로그래머에게 던져주고는 따르라고 말하는 프로젝트는 실패할  밖에 없다. 코딩을 직접 담당할 프로그래머만이  기능을 구현하기 위해 어떤 작업들이 필요한가를 구체적으로 예측할  있고  작업에 어느 정도의 시간이 소요될 것인가도 추정할  있다.


5) 작업단위를세분화하라. 실효성 있는 스케줄을 만들기 위해 반드시 유념해야  부분이다. 작업량은 날짜가 아니라 시간 단위로 계산해야 한다. ( ,또는   단위로 작업 기간이 계산되어 있는 스케줄은 처음부터 지킬 생각으로 만든 스케줄이 아니다). ‘작업 단위를  잘게 쪼개면  정밀한 스케줄이나오겠지 정도로 생각하는 독자가 있을지도 모른다. 천만의 말씀! 대략적인작업 개요를 바탕으로 스케줄을 세워보고, 다시 작업 단위를 보다 세분화하여스케줄을 세워보면, 단순히  정밀한 스케줄이 얻어지는 것이 아니라 전혀다른결과 나온다. 완전히 다른 수치가 나오는 것이다. 어째서 이런 일이 생기는 걸까?


작업 단위를 세분화하기 위해서는 실제 코딩 과정에서 구체적으로 어떤 일들을 수행하게  것인가를 생각해보지 않으면  된다. 서브루틴을 저작하고,이러저러한 대화상자들을 만들고, wawa 파일을 읽어내고 등등.  같은 각각의 단계에 소요되는 시간을 추정하는 것은 어렵지 않다. 프로그래머라면 서브루틴을 저작하고 대화상자를 만들고 wawa 파일을 읽어내는 작업들은 모두해봤을 것이기 때문이다.


만일 어떤 스케줄이 적당히 얼버무린  덩어리 작업들로만 (가령, “문법검사 기능 구현하기 ) 채워져 있다면, 이는 프로그래머가 구체적으로 어떤일들을 하게  것인가에 대해 제대로 생각해보지 않았다는 증거다. 그리고,어떤 일들을 하게  것인지 제대로 생각해보지 않았다면, 거기에 어느 정도의시간이 소요될 것인지도   없다.


개별 작업에는 어림잡아 2시간에서 많게는 16시간 정도까지가 소요된다. 스케줄에 40시간(1주일)짜리 작업이 포함되어 있다면, 작업 단위를 충분히 세분화하지 않았다는 이야기다.


스케줄을   작업 단위를 세분화해야 하는  다른 이유는 그런 과정을 통해 해당 기능을 머리 속으로 설계해보게 된다는 것이다. 만일 인터넷 통합이라는  떨리는 기능에 대한 스케줄을 수립하면서 무턱대고 3주일을 배정했다면  프로젝트는 실패할  밖에 없다. 구체적으로 어떤서브루틴들을만들어내야것인가 생각해내다 보면,  기능을 명확하게규정하게 된다.  같은단계에서 미리 계획을 세워봄으로써 소프트웨어 프로젝트와 관련된 불안정성을 크게 줄일  있다.

 

6) 최초추정시간과현재추정시간을지속적으로추적하라. 어떤 작업을 처음스케줄에 추가할 때는  작업에 어느 정도의 시간이 소요될 것인가를 추산한,  결과를 Orig Est (최초 추정시간) 컬럼과 Curr Est (현재 추정시간) 컬럼에 모두 입력한다. 


시간이 흐름에 따라, 작업 진도가 당초의 예정보다 지연 (혹은 단축)되면, 현재 추정시간 컬럼을 필요에 따라 업데이트할  있다.  같은방식으로 관리하다 보면, 특정 작업에 필요한 시간을 보다 정확하게 추정하는방법을 스스로 터득할  있다. 


대부분의 프로그래머들은 각각의 작업에 어느정도의 시간이 소요되는지  모른다. 그래도 걱정할 필요는 없다. 스케줄을지속적으로 관리하고 그에 따라 업데이트하는 , 결국 스케줄과 프로젝트 완료 시기는 일치하게 된다. (최종 납기를 맞추기 위해 일부 기능이나 항목을 잘라버려야만 하는 경우도 생길  있지만, 그와 같은 추려내기가 필요한 시점이언제인가를 일관되게 보여준다는 점에서 스케줄의 정확성은 여전히 유지될것이다). 필자의 경험으로  , 대부분의 프로그래머들은 일년 정도만 연습하면 스케줄 짜는  도사가 된다.


작업이 완료되면, 현재 추정시간 컬럼과 Elapsed (경과시간) 컬럼의 값이 똑같아지고 Remain (잔여시간) 컬럼의 값은 0 된다.


7) 경과시간을매일업데이트하라. 물론, 스톱워치를 들여다보며 코딩을 진행할 필요는 없다. 퇴근하기 직전에, 혹은 회사에서 밤을 새워가며 일하는 경우라면 책상 밑에 기어들어가 잠깐 눈을 붙이기 직전에, 하루에 한번만 경과시간을 업데이트하면 된다. 8시간 동안 근무했다고 가정하고 (하하!), 그날 진행한작업들에 대한 경과시간 필드에 8시간을 쪼개서 입력한다.


 잔여시간 컬럼의값은 엑셀이 자동으로 계산해  것이다.


그와 동시에, 현재 추정시간 컬럼도 업데이트하여 변화된 현실을 반영한다. 스케줄을매일업데이트하는걸리는시간은고작2정도밖에되지않는다. 그래서  방법을 손쉬운 스케줄 관리법이라고 부르는 것이다. 빠르고 간편하기 때문에.


8) 휴가기간과휴일등도항목에포함시켜라. 1 정도 진행되는 스케줄이라면, 사이에 프로그래머들의 휴가일수가 대개 10일에서 15 정도 포함될 것이다. 스케줄의 기능 컬럼에는 휴가, 휴일  기타 시간을 잡아먹는 모든 것들에대한 항목이 전부 포함되어야 한다. 잔여시간 컬럼의 값을 모두 더한  이를40(1주일)으로 나누면, 휴가  모든 요소를 포함하여 작업 기간이   주일이나 남아있는지를 산출할  있고 제품 출시 일자도 계산할  있다.


9) 디버깅시간도고려하라! 디버깅은 소요시간을 추정하기가 가장 어려운 항목이다. 가장 최근에 작업했던 프로젝트를 떠올려보라. 아마도 코딩 단계에서소요된 시간의 100% 내지 200% 해당하는 시간이 디버깅에 소요되었을 것이다. 스케줄의 기능 컬럼에는 반드시 디버깅 항목이 포함되어야 하며, 아마도가장 값이  항목이  것이다.


스케줄 업데이트 방법은 다음과 같다. 가령, 어떤 개발자가 wawa 파일을 코딩한다고 하자. 처음 스케줄을   예상했던 최초 추정시간은 16시간이었지만,현재까지 이미 20시간이 소요되었고 앞으로도 10시간 정도는  걸릴 것으로예상된다.  경우, 개발자는 현재 추정시간 컬럼에 30 입력하고 경과시간컬럼에 20 입력하면 된다.


주요 작업 단계가 완료된 , 모든 항목들의 값들을 더해보니 상당한 수치가나왔다. 이론상으로 제품 납기를 맞추자면 몇몇 기능을 잘라내 버려야 한다.이렇게 시간에 쫓길  프로그래머들이 가장 먼저 잘라낼  있는 기능이 바로디버깅 항목이다. 다행히도, 처음 스케줄을   디버깅 항목에 많은 시간을할당해 두었으니까.


원칙적으로, 개발자들은 코딩과 동시에 디버깅을 병행해야 한다. 절대로, 수정할  있는 버그를 뒤로 미뤄둔  새로운 코딩에 착수해서는  된다. 미해결버그의 수는 가능한  최소한으로 유지해야 한다.  이유는  가지다.


1) 버그는 코딩 직후에 곧바로 수정하는 것이 가장 수월하다.  달쯤 지난 후에 버그를 수정하려고 하면, 정확한 코딩 방식을 기억하지 못하기 때문에 버그수정도  어려워지고 시간도  많이 걸릴  있다.


2) 버그 수정은 과학적 연구와 비슷해서, 언제 새로운 과학적 사실을 발견할 있을지 정확히 예측하기 어려운 것처럼 언제 버그를 해결할  있을지 정확히 예측하는 것도 쉽지 않다. 수정해야  버그가  개나  개뿐이라면 제품출시 시기를 예측하는 것은 어렵지 않겠지만, 미해결 버그가 수백 개나 수천개쯤 되는 경우에는 이것들을 언제 전부 수정할  있을지 예측하기란 불가능하다.


그렇다면, 개발자가 코딩 과정에서 버그를 발견할 때마다 곧바로 버그를 수정하는데  디버깅 스케줄을 따로 만들어야 하는가? 프로그래머가 모든 버그를그때그때 수정한다 하더라도, 작업 단계가 완료되면 불가피하게 버그 수정 과정이 필요하다. 테스트 (내부 테스트  베타 테스트) 단계에서 정말로 어려운버그들이 발견되기 때문이다.


10) 통합시간도고려하라. 여러 명의 프로그래머가 함께 작업하는 경우, 프로그래머들 간에 서로 일치되지 않아 조정이 필요한 부분이 생기게 마련이다. 가령, 유사한 기능의 대화상자를  명의 프로그래머가 서로 다른 방식으로 구현할 수도 있다. , 여러 명의 프로그래머들이 각자 마음대로 추가한 메뉴 항목이나 키보드 단축키, 툴바 등을 누군가는 전체적으로 정리하고 통일시켜야만한다.  사람이 코드에 체크인하는 순간 컴파일러 에러가 발생할 수도 있다. 모든 것들을 수정할 시간이 필요하며, 이는 별도의 기능 항목으로 스케줄에포함시켜야 한다.


11) 여분의시간을포함시켜라. 시간은  모자라게 마련이다. 스케줄을  고려해야  여분의 시간(버퍼)  가지 종류가 있다. 첫째는 당초 추정했던것보다 시간이  많이 걸리는 작업을 고려한 버퍼이고, 둘째는 관리자가wawa 구현이 너무나도 중요해서 다음 버전으로 미룰  없다고 결정하는 경우 등과 같이, 계획에 없이 갑자기 추가된 작업을 고려한 버퍼다.


혹시라도 휴가, 휴일, 디버깅, 통합 시간  버퍼 항목 등을 모두 더한 값이 실제 작업 시간을 모두 더한 값보다  크다는 사실을 알고는 놀랄 수도 있다. 이런 사실에 놀라는 독자라면 아마 프로그래밍 경력이 아직 그리 길지 않은 개발자일 것이다. 책임질 자신이 있거든, 이런 항목들을 빼버려도 좋다.


12) 절대로관리자가프로그래머에게스케줄단축을요구해서는된다. 풋내기 소프트웨어 관리자 중에는 프로그래머들에게 빡빡한” (비현실적으로 짧은) 스케줄을 던져주는 방법으로 그들을 자극하여 작업을 보다 빨리 진행시킬  있다고 생각하는 사람들이 많다. 필자의 생각으로는 이런 식의 자극은멍청한 짓일 뿐이다. 필자의 경우, 스케줄에 뒤쳐지면 오히려 좌절감이 생기고의욕이 저하되며, 스케줄보다 진도가 빠를  활기도 생기고 생산성도 높아진다. 관리자는 스케줄을 심리전의 도구로 이용해서는  된다.


그럼에도 불구하고, 관리자가 스케줄 단축을 요구하는 경우에는 이렇게 대처하라. 릭의추정시간이라는 새로운 컬럼을 하나  추가한다 (물론, 프로그래머의 이름이 릭이라고 가정하고.) 프로그래머 자신이 예상하는 추정시간을 컬럼에 입력한다. 관리자가 원하는 새로운 스케줄은 현재추정시간 컬럼에 업데이트 한다. 관리자의 추정시간은 무시하고 작업을 진행하라. 프로젝트가 완료된 후에 누구의 스케줄이  현실적이었는지 비교해 보라. 필자의 경험에 따르면, “누구 스케줄이  맞는지 한번 볼까요?” 라고 관리자를 위협하는것만으로도 놀랄만한 효과가 있다. 자칫하면 프로그래머들과 얼마나 느릿느릿 일할 있는지 두고 보자는 식의 내기를 하는 꼴이 되고 만다는 사실을 관리자도깨닫게  테니까!


 풋내기 관리자들은 프로그래머의 스케줄을 단축하려고 노력하는가?


프로젝트가 처음 시작되면, 기술 관리자들은 비즈니스 담당자들과 회의를 하고는 그들이  3개월 정도 소요될 것으로 생각하는, 하지만 실제로는 9개월이 걸리는 제품 기능들이 적힌 목록을 만들어 온다. 어떤 작업들을 수행해야하는가를 구체적으로 생각해 보지 않고 스케줄을 짜는 경우, 항상 실제로는3n 시간 이상 걸릴 일이n 시간 정도 걸릴만한 일인 것처럼 보이게 된다. 현실적인 스케줄을 짜다 보면, 모든 작업 시간을 전부 더하게 되고  프로젝트가당초 생각했던 것보다 훨씬 시간이 많이 걸릴 것이라는 사실을 깨닫게 된다.현실은 가혹한 것이다.


풋내기 관리자들은  같은 문제를 해결하기 위해, 사람들이 보다 빨리 일하도록 만들  있는 방안을 찾아내려 애쓴다. 하지만, 이런 식의 접근은 그다지 현실적인 방법이 아니다. 작업 인원을  늘릴 수는 있겠지만, 그렇더라도 신입프로그래머들이 작업에 익숙해질 때까지 상당한 시간이 필요하기 때문에  정도는 작업 효율이 50% 정도 밖에 되지 않을 것이다 (게다가, 그들에게 일을 가르쳐야 하는 사람들의 작업 효율까지 떨어진다). 무엇보다, 소프트웨어업계에서 쓸만한 프로그래머를 새로 뽑자면 6개월 정도는 시간이 걸린다.


모든 에너지가 일년 안에 100% 소진될 만큼 팀원들을 쥐어짠다면 혹시 일시적으로 코드 산출량이 10% 정도 늘어날지도 모른다. 하지만, 별로 남는 장사는 아니다. 무엇보다, 이것은 배가 고프다고 종자용 옥수수까지 먹어치우는 것과 비슷한 꼴이다.


모든 사람들에게 아무리 피곤하더라도  참고 초인적으로 열심히 일해달라고 애원한다면 혹시 코드 산출량이 20% 정도 늘어날  있을지도 모른다. 하지만, 디버깅 시간은  배로 늘어날 것이다. 이야말로 숙명적으로 실패가 예정된 악수(惡手)   있다.


하지만, 아무리 해도 절대로 n 가지고 3n 이룰 수는 없다. 만일   있다고 믿는 회사가 있다면, 필자에게 이메일로  회사의 나스닥 상장기호를 일러주기 바란다. 필자가  상장기호를 반으로 줄여줄 테니까.


13) 스케줄은나무블록과같다. 집짓기 놀이용 나무 블록이  꾸러미 있는데이걸 주어진 상자에 전부 담을 수가 없다면, 방법은  가지다.    상자를구해오거나, 아니면 나무 블록 중에서  개는 포기하는 것이다. 6개월이면 제품을 완성할  있을 거라고 생각했었는데 작업을 진행하다 보니 12개월짜리스케줄이 됐다면, 제품 출시를 늦추든가 아니면 몇몇 기능을 포기해야 한다.나무 블록이 작아지게 만들 수는 없으니까. 만일 작아지게 만들  있는 것처럼 행동한다면, 이는 지금  앞에 보이는 것에 대해 스스로에게 거짓말을 함으로써 장래를 예측할  있는 기회마저 스스로 박탈하는 일이다.


이와 같은 스케줄 관리를 통해 얻을  있는  다른 부수적 효과는 많은 기능들 중에서 일부를 포기하게끔 만든다는 것이다. 포기하게끔 만드는 것이  좋으냐고? 여기  가지의 기능이 있다고 가정하자. 하나는 진짜로 쓸모 있고 장차 제품을 빛내줄 기능이고 (예를 들면, 넷스케이프 2.0 테이블 기능),  다른 하나는 코딩하기도 아주 쉽고 프로그래머가 만들어보고 싶어하지만 쓸모는 별로 없는 기능이다 (예를 들면, BLINK 태그).


스케줄 없이 프로젝트를 진행할 경우, 프로그래머들은 쉽고 재미있는 기능 먼저 코딩하기 시작할 것이다. 그러다가 나중에 시간이 부족하게 되면,   없이 유용하고 중요한 기능을 포기하게 된다.


프로젝트를 개시하기 전에 미리 스케줄을 수립하는 경우, 무언가를 포기해야만 하는 상황이 되면, 쉽고 재미있는 기능을 포기하고 유용하고 중요한 기능을작업하게  것이다. 스케줄을 관리하다 보면, 버려야  기능들을 프로그래머들이 스스로 추려내게 되기 때문에, 보다 나은 기능들로 구성된 강력하고 좋은제품을 만들  있게 된다.


필자가 엑셀 5.0 개발 프로젝트에 참여했을 때의 일이다.  당시 우리 팀이 계획했던 기능들이 워낙 방대한 양이었기 때문에 스케줄을 맞출 수가 없게 되었다. 팀원들은 고민했다. 이를 어쩌나! 전부  너무나도 중요한 기능들인데. 매크로 편집 마법사는 절대로 포기할  없어!


시간이 촉박해지자 별다른 도리가 없었다. 제품 출시 기한을 맞추기 위해 우리팀은 자식 같은 기능들을 잘라내야 했다. 포기하게  기능들에 대해 모두 마음 아파했다. 아픔을 달래기 위해 팀원들은 스스로에게 이야기했다.  기능들을 포기하는 것이 아니라 그저 조금  중요한 기능들을 위해 엑셀 6.0 버전으로 잠시미뤄두는 것뿐이라고.


엑셀 5 거의  완성되어갈 무렵, 필자는 동료인Eric Michelman 함께엑셀 6 버전에 대한 스펙을 만들기 시작했다. 

 사람은 머리를 맞대고 앉아엑셀 5.0 스케줄을 조정하면서 엑셀 6”용으로 미뤄둔 기능들을 다시 살펴보았다. 


우리는  기능들이라는 것이 너무나 조악한것들 일색이라는  놀라지 않을  없었다. 쓸만한기능이라고는 하나도 없었다. 물론,  기능들은  다음,  다음 버전에서도제품화되지 않았다.

 스케줄을 맞추기 위해 필요한 기능들만 추려낸 것이야말로 우리 팀이   중에서 가장 잘한 일이었다. 

그렇게 하지 않았다면, 엑셀5.0 개발 기간은  배쯤 길어졌을 것이고 아무짝에도 쓸모없는 쓰레기 같은 기능들로 50% 채워졌을 것이다. (넷스케이프 5.0이나 모질라(Mozilla)경우에도 분명히 이와 같은 상황이 벌어졌을 것이다. 스케줄도 없고, 확정된기능 목록도 없고, 쓸만한 기능만 추려내는  아무도 원치 않고, 그러다 보니제품을 출시할  없게  것이다. 그들은 결국 IRC 클라이언트처럼 시간을 들일만한 가치라고는 없는 기능들만 잔뜩 들어있는 제품을 내놓게  것이다.)


부록: 엑셀을이용할알아두어야것들

엑셀이 소프트웨어 스케줄 관리에 편리한 제품이라고 주장하는 이유 중의 하나는 대부분의 엑셀 프로그래머들이 오로지 엑셀 하나만 가지고 스케줄을 관리한다는 사실이다 (what-if 시나리오 같은 것을 분석하는 사람은 별로 없다...프로그래머들한테 그런  기대하면  되지!)


목록공유: 파일/목록 공유 명령을 이용하면 팀원 모두가 한꺼번에 파일을 열어두고 편집할  있다.  전체가 지속적으로 스케줄을 업데이트해야 하기 때문에,  기능은 아주 유용하다.


자동필터: 자동 필터 기능은 가령, 특정 프로그래머가 자신에게 할당된 작업만 전부 골라서 보고 싶을  스케줄을 필터링하는  편리하다. ‘자동 정렬 기능과 함께 사용하면, 자신에게 할당될 모든 작업을 우선순위에 따라 순서대로조회할  있다.  자체로 효과적인 작업 계획서 되는 것이다. 끝내주지?


피벗테이블: 피벗 테이블 기능은 요약정보나 크로스테이블을 보고 싶을 매우 편리하다. 가령, 각각의 우선순위에 대해,  개발자에게 필요한 잔여시간을 보여주는 도표를 만들  있다. 피벗 테이블은 결코 어렵지 않다. 반드시 기능을 사용하는  익숙해져야 한다. 엑셀을 백만 배쯤 편리하게 써먹을 있기 때문이다.


작업일기능: 엑셀의 분석 툴팩에 포함된 작업일(Workday) 기능을 활용하면 스케줄에 해당하는 실제 달력상의 날짜를 손쉽게 확인할  있다.


출처 : 조엘 온 소프트웨어 한국어 블로그 (http://korean.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html)

Posted by 엘키 엘키

댓글을 달아 주세요

모든 사람들이 명세서 작업을 해야한다고 생각은 하지만, 아무도 명세서 작업을 하지 않습니다.

왜 명세서 작업을 하지 않을까요?

명세서 작업단계를 건너뛰면 시간을 절약할 수 있다고 말합니다.

이런 사람들은 명세서 작성 작업이 NASA에서 우주 왕복선을 만드는 공학도나 큰 규모의 보험회사 직원에게나 필요한 사치쯤으로 치부합니다.

명세서 작업을 하지 않는 관례는 소프트웨어 프로젝트에서 가장 크고 불필요한 위험 요인을 짊어지는 행동입니다. 이는 등에 옷가지만을 걸친 다음에 날기를 기대하며 모하비 사막을 건너려고 출발하는 것만큼이나 바보스럽습니다.

명세서 작업을 생략하고 바로 코드 작성으로 뛰어드는 프로그래머나 소프트웨어 개발자는 스스로를 허리춤에서 순식간에 총을 뽑는 멋진 총잡이라고 생각하는 경향이 있습니다.

하지만 결코 그렇지 않으며, 이런 개발자일수록 놀라 자빠질 정도로 생산성이 낮습니다.

즉, 형편 없는 코드를 작성하거나 조잡한 소프트웨어를 양산하며, 결국 전혀 쓸데없느 ㄴ거대한 위험을 자초해 프로젝트를 위협합니다.


기능 명세 - FUNCTIONAL SPECIFICATION

완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술합니다. 어떻게 구현했는지는 신경도 쓰지 않습니다. 기능에 대해 이야기하고, 화면, 메뉴, 대화상자와 같은 사용자 인터페이스 부품을 명세합니다.


기술 명세 - TECHNICAL SPECIFICATION

프로그램 내부 구현을 기술합니다. 자료구조와 관계형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룹니다.



 * 좋은 기능 명세에 대한 아이디어!


1. 면책 조항 

방어적인 내용 "이 명세는 완벽하지 않습니다." 시간이 흘러 명세가 완벽하게 되면 다음과 같이 면책 조항을 바꿀 수 있다. "제가 알기로는 이 명세는 거의 완벽합니다. 하지만 무언가 빠뜨렸을 경우에는 제게 말씀해주세요"


2. 저자

명세는 1명이 전담해서 작성해야만 합니다. 큰 제품일 경우라면, 여러 부문으로 쪼갠 다음에 각각을 개인에게 할당해서 독자적으로 명세하게 합니다. 어떤 회사는 명세에 이름을 넣어서 개인의 공로를 인정하는 관례를 이기적인 행동이나 팀워크를 해치는 일이라고 생각합니다.

하지만 이는 허튼 소리입니다. 사람들은 자신이 명세한 사항에 대해 책임감과 소유의식을 느껴야 합니다. 명세에서 무언가 잘못되면, 이를 수정할 책임이 있는 명세서 소유자를 지정해야 하며 이 사람 이름이 바로 명세서에 찍혀 있어야 합니다.


3. 시나리오

생생하고 현실적인 시나리오를 만들수록, 실 사용자나 가상으로 창조한 사용자 모두를 위한 제품을 더 잘 만들 수 있습니다.


4. 회피목표

팀 단위로 제품을 만들 때 없으면 못살겠다는 이유만으로 실제든 상상이든 간에 각자 좋아하는 상큼한 기능을 넣으려는 경향이 있습니다. 이렇게 불필요한 기능을 쳐내는 가장 좋은 방법으로 명세에 회피목표 항목을 추가합니다. 


5. 개괄

개괄은 명세를 위한 목차와 유사합니다. 개괄은 간단한 흐름도이거나 광범위한 아키텍쳐 관점에서 본 토론일 수도 있습니다. 모든 사람이 숲을 보기 위해 목차를 읽습니다. 이렇게 해야 나무도 의미가 있을 것입니다.


6. 세부사항

웹 타입 서비스를 설계할 때 세부사항을 정리하는  좋은 방법은, 모든 가능한 화면에 기준이 되는 이름을 붙인 다음, 너무나도 자세해 못 견딜 만큼 따분한 세부사항을 매 화면마다 기술하는 장을 제공하는 겁니다.

세부사항은 기능 명세에서 가장 중요한 핵심입니다.


7. 미해결 문제

명세 첫 버전에 미해결 문제를 남겨놓아도 나쁘지 않습니다. 문제점을 쉽게 찾을 수 있도록 특별한 스타일을 적용해서 표시를 하고, 적당한 대안이 있으면 이를 논의합니다. 프로그래머가 작업을 시작할 무렵에 이런 모든 미해결 사항들을 짚어놔야 합니다.

단순히 프로그래머가 모든 쉬운 작업부터 시작하도록 내 버려두고, 나중에 미 해결 문제를 푸는 방법이 옳다고 생각할지도 모르겠습니다. 하지만, 이는 잘못된 생각입니다. 프로그래머가 코드를 구현하려고 시도할 무렵에 나타나는 새로운 문제점과 씨름하는 과정에서 또 다른 문제점이 나타날 것이며, 당신이 미리 알고 있었으며, 예전에 끝냇어야 하는 미해결 문제 역시 그대로 남아 있을 것입니다. 설상 가상으로 난이도 높은 문제를 해결하는 과정이 코드를 작성하는 방법에도 상당한 영향을 미칠지도 모르겠습니다.


8. 방주 (SIDE NOTE)

명세를 작성하는 동안에 프로그래머, 테스터 , 마케팅팀원, 기술집필가와 같은 다양한 청중이 있음을 기억해야 합니다. 명세를 작성할 때 단지 특정 그룹에만 유용한 활자화한 사실을 고려하면 좋겠습니다. 예를 들어 프로그래머를 위해 기술적으로 유용한 몇가지 세부 사항을 기술하는 메시지를 '기술노트'항목으로 구분해서 기록할 수 있습니다. 마케팅 팀원은 이런 메시지를 무시하지만 프로그래머는 이런 메시지를 탐독합니다.


9. 명세는 지속적으로 개정해야 합니다.

주기적으로 개정하여 현실을 반영합니다. 명세는 항상 제품이 동작하는 원리를 최대로 반영하는 그림자 입니다. 명세는 단지 제품이 코드완료시점에서 굳어질 따름입니다.



 * 명세서 작성 팁


1. 재미있게 씁시다.

여러분이 작성한 명세가 유쾌하며 재미있고 읽기 쉽다는 이유로 당신을 얕보는 회사에 근무한다면, 어서 다른 회사를 찾는 게 낫습니다.


2. 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.

문서를 소개하려는 대상층을 감안하고, 단계마다 그 사람이 무엇을 이해하길 바라는지 먼저 상각해보세요. 문장마다 독자가 내용을 깊이 이해했을지, 문맥의 의미는 파악했는지 스스로 되물어보십시오. 그래야 명세를 읽는 높으신 분께서 수많은 기술 용어에 압도당해 처음부터 문서 읽기를 포기하거나 멈추지 않게 될 겁니다.


3. 최대한 단순하게 작성하라.

쉬운 문장으로 작성하는 방식은 왠지 프로답지 않다는 생각에, 형식적이며 현학적인 언어를 남발하지는 마세요. 가능한 가장 쉬운 언어를 사용해야 합니다. 실제화면 보다 명세서를 더 효과적으로 개선하는 방법은 없습니다. 그림은 천마디 말보다 낫습니다.


4. 여러차례에 걸쳐 검토하고 다시 읽어라.


5. 표준양식은 해롭다고 간주한다.

모든 명세는 일정한 형식을 갖춰야 한다라는 생각은 버리십시오.


-출처 - 조엘 온 소프트웨어 - 

Posted by 엘키 엘키

댓글을 달아 주세요



조엘 온 소프트웨어 (http://elky.tistory.com/52를 너무나도 재밌게 읽고, 2010년초에 사서 읽었지만 이제서야 서평을 남기게 되네요.


서평을 올리지만 않았다뿐, 요즘도 책은 나름 꾸준히 읽고 있었습니다.


롤하다 닷지하고 주로 읽었....쿨럭!



여하튼, MS에서 프로그램 매니저로 일했고, 포그 크릭을 운영중인 그의 시야는 여전히 놀라웠습니다.

유독 와닿는 몇가지 컬럼이 있었는데요, 


자바만 가르치는 위험한 대학과, 예일 대학 강연, 틀린 코드를 틀리게 보이도록 만들기가 바로 그것이었습니다.,



8. 자바만 가르치는 위험한 대학

우리나라 커리큘럼도 이렇게 변해가고 있다는 사실이 저는 매우 걱정됩니다.

자바가 좋은 언어냐 아니냐는 논점을 흐리기 때문에 배제한다고 봤을 때, 조엘씨가 얘기하신 "자바는 뛰어난 프로그래머와 고만고만한 프로그래머를 구별할 만큼 어려운 언어가 아니란 점이 문제라고 얘기하신 점에 공감합니다.

저는 분명히 C언어를 고르지 않았다면 자료구조를 직접 만들어내지 못했을 겁니다.


"이봐, 자바를 쓴다면, 자료구조를 직접 만들어낼 필요가 없다구"

라고 얘기하신다 해도, 저는 포인터와 재귀를 이해하지 못한다면, 이해 못할 분야가 너무나 많아 진다고 생각합니다.


프로그래밍을 중도 포기하는 사람이 너무 많아서 모두를 하향 평준화하려는건 아닐까요?

분명, C와 자바를 동시에 가르치던 시기에 프로그래밍을 포기하는 비율이 높았다는 것은 알고 있습니다.

그렇다고해서, 더 많은 것을 이해할 수 있는 기본이 될 C언어를 학교에서 가르치지 않는다면 어디에서 배우게 될까요?


모두가 자바에서 제공되는 것 이상은 무엇도 할 수 없는 현실이 되는 것은 누구도 원치 않을텐데 말이죠.



9. 예일 대학 강연

MS에서 일하셨던 분 답게, 윈도우에 대한 이야기를 꽤나 많이 하시는 편입니다.


The Art of unix Programming에 나올 법한 내용들과, 윈도우 개발 282 스토리에 나올법한 내용들을 많이 얘기하시는 편인데요,


역시나 윈도우의 개발 문화에 대한 단점 지적 부분은 들을 떄마다 큰 공감이 됩니다.


C언어를 배우며 모두가 거치는 코스인 CLI 프로그램에서, GUI 기반 프로그래밍을 접하고 난 뒤 겪는 혼돈, 그리고  그 문화가 낳은 재앙(?)들에 대해서 말이죠.

저도 아주 여실히 깨닳고 있습니다. 명령행 프로그램 (CLI)위에 GUI를 얹는 구조가 아닌, GUI 기반 프로그래밍이라니요...


이렇게 배워온 많은 것들이, 코드 재사용, 기능 재사용등을 막는 제약이 되고 있다는 사실이 안타깝습니다.

게다가, Run and fix나, 조작 순서가 조금만 달라져도 돌지 않는 프로그램 따위를 양산했기 떄문입니다.


물론 좋은 프로그래머인 여러분들은 그렇지 않으실거란건 알고 있습니다.


또 자동화된 테스트만으로 좋은 사용성과 버그를 모두 제거할 수 없다는 사실에 대한 얘기도 흥미롭습니다.
품질은 단순히 기술에 치우치지 않는다라... 저도 동의합니다. 이 의견에 동의하면서도 건망증이라도 걸린건지,  종종, 아니 꽤나 자주 품질=기술이란 의미로서 생각하곤 하지만 말이죠.


몇몇 분들이 울컥하실수도 있는 일이지만, 사내 소프트웨어 개발자가 되면 안되는 이유에 대해서도 공감합니다.

기업의 주력 업무에 일하지 못한다면 좋은 대우를 받기 어렵기 떄문이지요.



23. 틀린 코드를 틀리게 보이기


이건 그냥 조엘씨 의견 거의 그대로 붙여 쓰겠습니다.


일반 규칙 

* 함수를 짧게 유지하라

* 변수는 쓰기 직전에 정의하라.

* 매크로를 남발하여 자기만 아는 프로그래밍 언어를 만들지 마라.

* goto를 쓰지 마라.

* 중괄호로 묶이는 블록은 한 화면에 다 보이게 하라.


아무래도 C언어를 예로 든 만큼, 크게 와닿는군요.

매크로...음 국지적 사용만 하는데도 곤욕을 겪을때가 많아 공감합니다.


앱스 헝가리안과 시스템 헝가리안

잘못 퍼진 헝가리안 표기법에 대한 오해를 풀어주고 계십니다.

요새 자주 보게 되는 코드가 boost나, linux쪽 코드라 그런지 헝가리안 표기법이 별로 없는데,
일정 부분 헝가리안 표기법을 축소해서 사용하고 있는 중인지라, 잘못알고 있던 헝가리안 표기법에 대한 이해를 도와준 점이 좋더군요.


예외 때려부수기

예외가 정확히 프로그램이 원하는 동작을 보장할 거라는 확신을 갖기 어렵게 만든다는 이야기군요.

물론 저는 MS에서 일해본적은 없지만, 진입점마다 예외 처리 구문을 넣고 단순 실수를 잡는 식으로 커버리지를 높이는 방법으로 사용하고 있고,

return값 만으로 알리기 어려운 상황에서 코드의 흐름을 멈추는 용도로 쓰고 있다보니, 조엘씨가 얘기하시는 예외처리가 갖게되는 문제에 대해서 100% 공감할 순 없었습니다.


조각 코드만으로 이 코드가 완전 무결할 것이라는 확신을 갖기 어렵다는 점에서는 공감합니다.




이외에도 책에 실린 내용 하나하나가 내공과 통찰에서 뿜어 나오는 좋은 교훈이나, 때론 논쟁거리가 많습니다.

현재 운영중이신 포그 크릭이 얼마나 좋은 회사인지, 그리고 좋은 프로그램 회사의 오너가 왜 프로그래머여야 하는지 등 여러가지를 느낄 수 있게 해주는 분이라고 생각합니다.


전반적으로 언어의 제약이 없이, 좋은 내용이 가득합니다.

꼭 읽어보세요. 가능하다면, More Joel no Software보다, Joel on software 부터요.

Posted by 엘키 엘키

댓글을 달아 주세요



프로그램을 작성하다보면 예기치 못한 문제에 봉착할 때가 많습니다. 그런 문제를 덜 겪기 위해 다양한 개발 방법론을 접해보았고, 시도해 보았습니다.

그 중에서도 조엘의 이야기는 특별했습니다.
 
능률을 높이기 위한 복잡한 절차대신, 마인드와 작은 행동으로 그것들을 대신했습니다. 

방법론을 쉽사리 적용시키기 힘든 초보 프로그래머인 저에게도 조엘의 이야기는 쉽게 받아들이고, 쉽게 적용시킬수 있는 것들이었기에 더더욱 좋지 않았나 생각합니다.
 
무엇보다 조엘 테스트(http://elky.tistory.com/149)는 꼭 체크해보시기 바랍니다. 조엘 테스트 점수 높은 팀 치고 안좋은 팀이 없습니다.
 

또 일정 예측이란, 예측 자체에 부담을 가질 것이 아니라, 예측과 실제 소요시간과의 오차를 줄여가는 과정이라는 얘기도 아주 크게 도움이 됐습니다.

두고 두고 도움이 되는 내용은 여러 챕터로 이어지며 큰 비중으로 설명한, 손쉬운 기능 명세 작성법 입니다.


제가 지인이나, 프로그래밍 관련 책 추천을 요청받으면 꼭 권해드리는 서적이 몇권 있습니다.

그 중 하나가 실용주의 프로그래머 인데요, 조엘씨도 바로 그 책에서 얘기하는 실용주의 프로그래머들 중 한 분이라는 것을 자연스레 느낄 수 있었습니다.


그렇습니다. 이런 이야기를 듣고 싶었습니다.

조엘의 이야기가 모두 정답이진 않겠지만 조엘의 경험과 통찰력에서 나온 이야기 들은 한번쯤 시도해볼만한 가치가 있는 좋은 이야기들이었다고 생각이 드네요.

개인적으로 임백준씨의 저서들 이외에 IT 관련 서적중 가장 즐겁고, 빠르게 읽은 책이 아니었나 싶네요. (대체 뭐가 문제야는 IT 서적이라 보기 애매하므로 패스~)

 한국어판에만 있는 유쾌한 보너스는 꼭 읽어보시길 권합니다. 재밌는 내용이 많답니다.

Posted by 엘키 엘키

댓글을 달아 주세요

이전버튼 1 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today29
Total1,605,483

달력

 « |  » 2020.8
            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          

글 보관함