2006/11/07 23:02
Dev 노트
(혹시 있을지 모를, 앞의 내용이 궁금한 방문객을 위한 링크^^;;;)
일단 스펙이 잡혔다고 생각된다면, 물론, 충분히 수요자와의 피드백을 거친 다음에, 그다음 할 일은 일정을 잡아보는것이다.
과연 이 프로젝트를 수행하는데 얼만큼의 시간을 쏟을 것인가를 계획하는 것이다. 정확할 필요는 없다. 그러나 허무맹랑해서도 안된다. 도저히 시킬수 없는, 단지 상급자(보통은 팀장이나 부서장, 혹은 PM)의 기분을 좋게 하기 위해서라던가 당장 회의의 스트레스에서 벗어나고 싶은 맘으로 "질러"버리면 크게 후회할 일이 반드시 생긴다. 그런 스케줄은 없느니만 못하다.
소프트웨어 개발이라는게(역시 하드웨어도 마찬가지이지만..) 물흐르듯 부드럽게 진행되어야 한다.
"자.. 11월 7일 오후 3:45분경에 스펙을 완료했으니까 3:46부터는 스케줄을 잡아보는거야."
이런 식으로 진행할수 없다는 말이다. 그게 가능하더라도 그렇게 해서는 안된다.
스펙을 잡는 과정, 특히 기능명세를 구체화하는 회의를 마치고 고객이 돌아간 뒤에 개발 담당자만 모여서 기술명세를 작성해 가는 과정에서 명세가 구체화 되어 갈수록 스케줄도 나오고, 프로젝트 수행을 위한 설계도 가닥이 잡히고 업무분담도 윤곽이 드러나게 된다. 물론 "DVD대여점 고객관리 프로그램"을 만들어야 한다는게 유일한 명세서인 단계에서는 도무지 스케줄이나, UI와 로직, 데이터 스키마라던지, 필요한 인력이 몇이나 되는지와 같은 설계는 감이 잡히지 않는다.
스펙이 잡힌 후에 스케줄 잡는 작업을 착수해야 한다고 말하는 것은 이런 것이다. 딱히 경계가 있는 것은 아니라는걸 잊지 말자. (하지만 정말 많은 사람들이 모르는건지 잊은건지.. 경계를 그으려고 한다.)
이전의 포스팅에서 "완벽한 명세서를 만든다면 개발프로젝트는 50%이상완료되었다고보아도 좋다."
라고말했다. "완벽한 명세서"가 만들어 졌다면 이미 스케줄링도 되었을 것이고 지금까지 생각할 수 있었던 최대한의 가능성을 검토한 설계와 각 요소를 개발할 담당자까지 정해졌을 것이기 때문에 한 말이다.그럼, 명세 구체화 과정에서 스케줄은 어떻게 잡아가야 할까..
대체로 개발 프로젝트는 기술명세를 구체화하는 동안 스케줄과 설계가 나온다. 고객의 Needs(요구와 약간 개념이 다르다)를 모두 수용하기 위한 기능명세를 다듬는 과정에서는 스케줄이나 설계가 잘 보이지 않는다. 그렇다고 기능명세를 소흘히 해서는 안된다. 기능명세의 내용을 펼쳐 놓고 만드는 것이 기능명세가 되는 것이다. (적어도 지금 하는 일과 개발자 명함을 파자마자 했던 일을 제외한 내가 참여했던 모든 프로젝트는 그랬다.)
기술명세를 구체화 할때는 개발자들 사이에 이런 대화들이 오간다.
도대체 머리속에 적당한 예가 떠오르지 않아서 맨날 울궈먹는 DVD대여점-_-으로 또 써보긴 했지만, 대충 분위기가 저렇다는 것이다. (보통 DVD대여점 프로그램을 짤때는 저렇게까지 모여앉아 의논하지 않는다;; 하는게 바람직 하지만..) 하여튼 점점 설계의 윤곽이 드러난다. 이렇게 윤곽이 나올때쯤 되면, 이 부분을 구현하는데는 어느정도 걸리겠다 하는것을 알수 있고, 그걸 모두 합치면 전체 일정이 나오는 것이다.
각 부분의 일정을 생각할 때 빼놓지 말아야 하는 것이 테스트와 디버그 시간이다. 이건 다분히 경험적인 수치일 수밖에 없지만, 그 경험적 수치가 현실성이 있게 하기 위해서 소위 말하는 유닛 테스트를 가능하게 하는 설계를 하는 것이다. 유닛테스트와 같은 TDD(Test-Driven Development)이야기는 다음기회에...;;
이렇게 잡혀진 설계의 개요와 스케줄은 매우 현실성이 있다.
자, 이제 얼만큼의 시간이면 프로젝트를 완수할 수 있다고 팀장님께 보고하러 갈 시간이다.
가기전에 다시 한번 생각해 보자. 각 요소 결합 후의 디버그 시간을 빼뜨리지는 않았는지.. 안빠뜨렸다면 그 앞에 하루나 이틀정도, 프로젝트 규모에 따라, 덧붙이자. 바로 프로토타이핑할 시간이다^^
아마도 지금까지의 과정을 개발을 전혀 모르는 기획부서가 혼자하도록 내버려둔 회사도 많을 것이다. 주변에 보이는 소위 성공한 벤처들은 이 과정을 개발을 약간 해본적이 있거나 개발에 관한 지식은 좀 있는 기획부서에서 했기 때문에 남들보다 뛰어났던 것이다.
이제 최고가 되자.
덧. 쓰다보니 정작 필요한 말은 빼먹게 되는거 같은데.. 책쓰는것도 아닌데 뭐;;;
일단 스펙이 잡혔다고 생각된다면, 물론, 충분히 수요자와의 피드백을 거친 다음에, 그다음 할 일은 일정을 잡아보는것이다.
과연 이 프로젝트를 수행하는데 얼만큼의 시간을 쏟을 것인가를 계획하는 것이다. 정확할 필요는 없다. 그러나 허무맹랑해서도 안된다. 도저히 시킬수 없는, 단지 상급자(보통은 팀장이나 부서장, 혹은 PM)의 기분을 좋게 하기 위해서라던가 당장 회의의 스트레스에서 벗어나고 싶은 맘으로 "질러"버리면 크게 후회할 일이 반드시 생긴다. 그런 스케줄은 없느니만 못하다.
소프트웨어 개발이라는게(역시 하드웨어도 마찬가지이지만..) 물흐르듯 부드럽게 진행되어야 한다.
"자.. 11월 7일 오후 3:45분경에 스펙을 완료했으니까 3:46부터는 스케줄을 잡아보는거야."
이런 식으로 진행할수 없다는 말이다. 그게 가능하더라도 그렇게 해서는 안된다.
스펙을 잡는 과정, 특히 기능명세를 구체화하는 회의를 마치고 고객이 돌아간 뒤에 개발 담당자만 모여서 기술명세를 작성해 가는 과정에서 명세가 구체화 되어 갈수록 스케줄도 나오고, 프로젝트 수행을 위한 설계도 가닥이 잡히고 업무분담도 윤곽이 드러나게 된다. 물론 "DVD대여점 고객관리 프로그램"을 만들어야 한다는게 유일한 명세서인 단계에서는 도무지 스케줄이나, UI와 로직, 데이터 스키마라던지, 필요한 인력이 몇이나 되는지와 같은 설계는 감이 잡히지 않는다.
스펙이 잡힌 후에 스케줄 잡는 작업을 착수해야 한다고 말하는 것은 이런 것이다. 딱히 경계가 있는 것은 아니라는걸 잊지 말자. (하지만 정말 많은 사람들이 모르는건지 잊은건지.. 경계를 그으려고 한다.)
이전의 포스팅에서 "완벽한 명세서를 만든다면 개발프로젝트는 50%이상완료되었다고보아도 좋다."
라고말했다. "완벽한 명세서"가 만들어 졌다면 이미 스케줄링도 되었을 것이고 지금까지 생각할 수 있었던 최대한의 가능성을 검토한 설계와 각 요소를 개발할 담당자까지 정해졌을 것이기 때문에 한 말이다.그럼, 명세 구체화 과정에서 스케줄은 어떻게 잡아가야 할까..
대체로 개발 프로젝트는 기술명세를 구체화하는 동안 스케줄과 설계가 나온다. 고객의 Needs(요구와 약간 개념이 다르다)를 모두 수용하기 위한 기능명세를 다듬는 과정에서는 스케줄이나 설계가 잘 보이지 않는다. 그렇다고 기능명세를 소흘히 해서는 안된다. 기능명세의 내용을 펼쳐 놓고 만드는 것이 기능명세가 되는 것이다. (적어도 지금 하는 일과 개발자 명함을 파자마자 했던 일을 제외한 내가 참여했던 모든 프로젝트는 그랬다.)
기술명세를 구체화 할때는 개발자들 사이에 이런 대화들이 오간다.
"UI부터 시작할까? 아니면 스키마부터?"
"UI라니? 어떤 환경에서 돌아가는지 정해진거야? 윈도우인지 리눅스인지 맥인지.. 모르잖아?"
"UI와 스키마가 얼마나 분리될 수 있는지부터 생각해 보는건 어때?"
"UI-로직-스키마를 완전 분리하는게 버전업하기 좋지.."
...
"고객 정보란게 도대체 어떤 필드들을 갖는 레코드라고 할 수 있을까?"
"단일한 레코드로 표현되긴 하는거야? 아닐것 같은데.."
"RDBMS로 해결할수 있을것 같다."
...
".Net을 쓰면 맥 환경에서는 안돌아 가잖아?"
"맥에서 돌리겠다는건 억지라구.."
"윈도우 환경이라고 .Net FW를 항상 설치한다고 생각하는거야? 차라리 MFC가 개발하기 빠르지"
...
"UI와 로직 단의 인터페이스는 어떻게 할꺼야?"
"웹서비스랑 웹 애플리케이션으로 만들어서 브라우저 쓰라고 해버릴까?"
...
"고객 레코드는 CClient class로 만들면 되겠어. 구성은 이 그림처럼.."
"DVD타이틀은 CMedia class로 만들면 되고.."
"이 Object를 담을 수 있는 스키마를 생각해 보자.."
...
도대체 머리속에 적당한 예가 떠오르지 않아서 맨날 울궈먹는 DVD대여점-_-으로 또 써보긴 했지만, 대충 분위기가 저렇다는 것이다. (보통 DVD대여점 프로그램을 짤때는 저렇게까지 모여앉아 의논하지 않는다;; 하는게 바람직 하지만..) 하여튼 점점 설계의 윤곽이 드러난다. 이렇게 윤곽이 나올때쯤 되면, 이 부분을 구현하는데는 어느정도 걸리겠다 하는것을 알수 있고, 그걸 모두 합치면 전체 일정이 나오는 것이다.
각 부분의 일정을 생각할 때 빼놓지 말아야 하는 것이 테스트와 디버그 시간이다. 이건 다분히 경험적인 수치일 수밖에 없지만, 그 경험적 수치가 현실성이 있게 하기 위해서 소위 말하는 유닛 테스트를 가능하게 하는 설계를 하는 것이다. 유닛테스트와 같은 TDD(Test-Driven Development)이야기는 다음기회에...;;
이렇게 잡혀진 설계의 개요와 스케줄은 매우 현실성이 있다.
자, 이제 얼만큼의 시간이면 프로젝트를 완수할 수 있다고 팀장님께 보고하러 갈 시간이다.
가기전에 다시 한번 생각해 보자. 각 요소 결합 후의 디버그 시간을 빼뜨리지는 않았는지.. 안빠뜨렸다면 그 앞에 하루나 이틀정도, 프로젝트 규모에 따라, 덧붙이자. 바로 프로토타이핑할 시간이다^^
아마도 지금까지의 과정을 개발을 전혀 모르는 기획부서가 혼자하도록 내버려둔 회사도 많을 것이다. 주변에 보이는 소위 성공한 벤처들은 이 과정을 개발을 약간 해본적이 있거나 개발에 관한 지식은 좀 있는 기획부서에서 했기 때문에 남들보다 뛰어났던 것이다.
이제 최고가 되자.
덧. 쓰다보니 정작 필요한 말은 빼먹게 되는거 같은데.. 책쓰는것도 아닌데 뭐;;;
