이번 프로젝트는 구현 자체에 대한 내용은 얼마 되지 않습니다. 때문에 사용자 스토리 역시 간단한 수준으로 작성되었습니다. 문제가 되는 부분은 GTD 에 대한 내용을 완벽하게 숙지하지 못하고 있다는데 있었습니다. GTD에 대한 서적이 외국같은 경우는 출판되었으며 우리나라에는 공병호 박사님이 '끝도 없는 일 깔끔하게 해치우기'라는 이름을 번역하셨지만 절판이라 쉽게 찾을수가 없었습니다. 그래서 고민을 하던중 해당 책에 대한 서평을 접하게 되었습니다.
시나리오의 내용은 아래와 같습니다.
리뷰 중에 제가 구현하고자 하는 부분을 추출했습니다.
그 프로세스는 대략 다음과 같다. 일거리를 "모두" 수집한다. 수집 후, 먼저 버릴 것과, 보류할 것, 그리고 참고할 부분은 실행 할 수 없는 부분으로, 그리고 실행 할 수 있는 부분은, 그 다음 행동에 따라 다단계 프로젝트화 관리를 하거나, 2분 안에 해결될 일은 직접 그 자리에서 끝내고, 나머지는 위임 또는 연기를 하는 프로세스이다.
그리고 추출한 내용으로 아래와 같은 화면을 그렸습니다.
화면은 다시 '참고할 것'과 실행할 수 없는 것에 대한 중복이 불필요하다고 느껴 결국 아래와 같은 화면으로 합치도록 설계를 변경하였습니다.
사실 위의 리뷰를 보고 어떤 설계를 도출해 내는가에 대한 이견은 많이 있을수 있습니다. 하지만 개인적 경험에 비춰서 생각해 보면 과거에는 어느것이 더 옳고 바른 설계인가를 두고 고민만 하다가 흥미를 잃어버린 경우가 많았던 기억이 있습니다. 가장 좋은 방법은 충분한 고민과 올바른 설계로 프로젝트를 마무리 짓는 것이겠지만 그것이 아니라면 중도에 멈추는것 보다는 설계가 조금은 빈약하더라도 끝까지 진행하여 마무리 짓는 것이 성공여부를 떠나서 결과적으로 더 많은 경험이 되지 않을까 생각해 봅니다.
도출된 설계로 기능 목록을 작성하였습니다.
박재성님께서 집필하신 '자바 프로젝트 필수 유틸리트' 중에 재미있는 것중 하나는 사용자 스토리를 만들고 기능 목록을 도출하고, 그 기능에 대해서 스토리 포인트를 부과하고, 집계된 점수로 순서를 정하고, 마일스톤을 정하는 방식이었습니다. '좋아 보이는 것은 따라하는' 것을 즐기는 지라 역시나 저도 해 봤습니다. Trac에 마일스톤을 정하기 위해서라도 말이죠.
포인트를 주면서 재미있었던 점은 혼자였다는 겁니다. 점수를 줄려면 다른 생각을 가진 여러사람이 차별화된 점수를 부여해야 의미가 있을텐데 말이죠. 저는 일단 혼자서 기획자, 개발자의 입장에서 생각을 해볼려고 노력했습니다. 기획자 점수를 줄때는 '난 개발을 잘 모르는 기획자다. 기획자다' 라고 스스로에게 마인드 컨트롤을 하면서 점수를 부여했습니다. 제 생각에 기획자는 뭔가 화면에 바로 확인할수 있는 것들에 대해서 포인트를 많이 주고 개발자는 하나씩 차근차근 개발하는데 점수를 더 많이 주지 않을까 하는 생각이 들었습니다. 때문에 점수 역시 그러한 것들을 가정하고 부여했습니다. 중간에 점수가 바뀐 부분은 기획자와 개발자의 포인트가 달랐지만 합계가 같을때 서로 협의하에 점수를 교환한 것에 대한 흔적입니다. 나름대로 사실적인 점수 부여를 했다랄까요? :-)
결과적으로 아래와 같은 분류(plan, to-do, ex-list, ex-do)와 마일스톤이 도출되었습니다.
조그마한 프로젝트를 4개의 분류로 나누과 각 분류에 마일스톤을 부여하는것이 좀 번거러울수 있지만 지금 하고 있는 프로젝트는 '번거러움이 많은' 배보다 배꼽이 더 큰 프로젝트 입니다. ^^ 다음엔 간단한 DB 스키마 설계를 진행할까 합니다.
