카테고리 보관물: ASP

ASP 개발을 효율적으로 하는 방법 – 시간관리일지

이번에는 시간 관리 일지에 관하여 말씀 드리겠습니다.

이 내용은 월간 마이크로소프트웨어에 소개된 내용과 PSP(Personal Software Process)에 관련한 책을 참고하여 작성한 것입니다.

프로젝트를 시작하기 전이나 진행하는 중간에 “언제쯤 완료될까요?” 라는 질문을 많이 받게 됩니다. 그런데 막연하게 어느 정도 걸릴 것 같다는 이야기만 할 수 있지 구체적으로 몇일이 소요된다고 대답하기 어렵습니다. 프로젝트 일정이라는 것은 있지만 어떠한 기준으로 책정이 된 것인지 알 수 없는 경우가 대부분 입니다. 또 항상 일정이라는 것이 진행을 하다보면 작업할 수 있는 시간이 턱없이 부족하게 됩니다.

어떤 업무나 프로젝트의 실제 작업시간을 정확히 알 수 없는 여러 가지 이유가 존재합니다. 회의가 필요이상으로 많다거나 전화업무가 너무 많다거나 해서 시간을 빼앗기는 경우가 적지않게 발생합니다.

그 중에 가장 큰 이유가 단위업무를 마치는데 필요한 시간을 정확히 알지 못해 전체적인 프로젝트의 소요시간을 측정할 수 없는데 있습니다.

저도 업무를 진행하다 보면 이 정도의 작업량이면 어느 정도의 기간이 필요한지 정확하게 이야기 하기 어려웠습니다.

PSP 에서 제시한 방법이 여러가지가 있는데 책을 보면 뒷부분에서는 ‘정말 복잡하게 관리하는 구나’ 라는 생각이 들 정도로 기재하는 사항이 많아지게 됩니다. 개인적으로는 그렇게 까지 적용하기는 무리인 것 같아 대강의 시간을 파악할 수 있는 시간관리일지를 간략하게 정리하여 기록해 보기로 하였습니다.

일자별로 단위업무를 기재하고 시작하는 시간과 종료하는 시간을 기록하고 순수하게 걸린 시간을 계산합니다. 이 때 시작한 작업과 관계없는 일에 소요된 시간을 따로 기록합니다. 예를 들어 갑자기 손님이 오셨다거나 다른 동료의 질문에 답한 시간등을 기록하여 전체 시간에서 빼줍니다. 그러면 순수하게 작업한 시간을 알 수 있습니다. 현재 진행하고 있는 프로젝트에 적용해 보시기 바랍니다. 아마 놀라운 결과를 보시게 될 겁니다. 저의 경우에는 실제 업무에 집중하는 시간이 생각보다 적어 많이 놀랐었습니다. 대부분 한가지 일에만 몰두할 수 있는 환경이 되지않아 생각보다 많은 시간을 빼앗기게 된다는 것을 알 수 있습니다.

이런식으로 하루하루 자료를 쌓아가다 보면 ‘이정도 난이도의 작업은 내가 하면 이 정도 시간이 필요하겠구나’ 라는 판단이 서게 됩니다. 여기에 업무외에 발생하는 시간을 더하여 프로젝트를 진행하는데 어느 정도 정확한 시간을 알 수 있게 됩니다.

처음에는 귀찮기도 하고 기록하는 것도 잊어버리곤 하는데 하루하루 쌓아가다 보면 훌륭한 자료가 됩니다. 엑셀로 되어 있는 샘플파일을 참고 하시면 이해가 되실 겁니다. 여기에서 인터럽트 시간은 작업외에 소요된 시간을 기재하시면 됩니다. C는 완료된 단위작업 수, U는 완료되지 않은 단위작업 수 입니다. 아래의 도서를 참조하시면 더 많은 관리 방법을 접해보실 수 있습니다.

제가 참조한 도서는 퍼스널 소프트웨어 프로세스(psp)입문:introduction to the Personal Software Process 피어슨에듀케이션코리아 Watts S. Humphrey 입니다.

꼭 한번 읽어 보시기 바랍니다.

다운로드 : 시간기록일지

그동안 6회에 걸쳐 모자란 실력이지만 ASP로 작업하면서 느꼈던 부분과 제가 가지고 있는 노하우를 적어 보았습니다. 뛰어난 실력을 가지신 분들이 보면 장난에 불과하겠지만 어려움을 겪고 계시는 초보분들에게는 도움이 될 수 있는 내용이라고 생각합니다. 많은 분량은 아니지만 생각보다 시간이 많이 걸렸습니다. 이 정도의 글을 쓰는데에도 많은 시간이 걸리는데 두꺼운 책을 쓰시는 분들을 생각하면 정말 대단하신 분들이라는 생각이 저절로 듭니다. 아무쪼록 저의 글이 많은분들께 도움이 되었으면 하는 바람입니다. 조만간 다른 주제로 찾아 뵙겠습니다.

 

ASP 개발을 효율적으로 하는 방법 – 라이브러리 구축

이번에는 자신 혹은 소속한 회사의 라이브러리 구축에 관하여 말씀 드리겠습니다.

개발을 진행해 나가다 보면 중복되어 사용되거나 자주는 사용하지 않는데 꼭 필요한 기능이 있습니다. 이런 경우 미리미리 함수로 작업해 놓고 include로 추가하여 사용하는 것이 여러모로 편리합니다.

바쁘고 귀찮아서 그냥 복사하여 붙여넣기를 하는 경우가 많이 있습니다. 그 순간은 시간을 절약할 수 있을지 몰라도 개발이 완료되고 난 후에 유지보수에 들어가게 되면 정말 많은 시간이 소요될 수 있습니다. 프로그램 안에서는 중복되는 부분을 최소화 해야 합니다. 만일 동일한 소스 코드가 여기저기 분산되어 있다면 고치는 것도 일이고 실수라도 하게 되면 정말 찾아내기도 어렵습니다. 누가 그런식으로 작업하느냐고 반문하실 분도 계시겠지만 제가 유지보수를 하면서 느꼈던 부분입니다.

저의 경우에는 골프장 관련하여 프로젝트를 진행한 적이 있었는데 일자에 관련된 기능을 많이 사용하게 되었습니다. 일자에 관련하여 필요할 것으로 생각되는 기능을 미리 함수로 구현해 두었습니다. 물론 프로젝트가 진행되다 보면 수정이 가해지기는 하지만 미리 준비하지 않고 진행하는 것보다는 유리합니다. 그리고 꼭 특정한 프로젝트에서 사용할 목적으로 라이브러리를 구축하는 것보다 널리 사용할 수 있도록 구축하는 것이 좋습니다.

처음에는 시간이 걸리고 귀찮은 작업이 될 수도 있지만 어느 정도 라이브러리가 구축이 되고 공유하여 사용하면 개발 시간이 단축됩니다. 그에 따라 좀더 생산적인 부분에 많은 시간을 투자할 수 있는 여유가 생기게 됩니다.

여러 가지 프로젝트를 진행하다 보면 잘 모르거나 막히는 부분이 생기게 됩니다. 그런 경우에 개발자 모임 사이트나 여러 사이트의 자료를 참고하는 경우가 많습니다. 그런데 어느 정도 시간이 지나 다른 프로젝트에서 예전에 찾아보았던 자료가 필요한 경우가 있습니다. 분명히 어디에서 본 기억이 나는데 이상하게도 찾기가 어렵습니다. 기억을 더듬어 자료를 다시 찾느라 아까운 시간을 소비하게 됩니다. 이런 경우를 대비하여 유용한 정보나 예제 코드등을 지식사전 형태로 관리하면 본인은 물론이고 사내의 다른 개발자들과 그 정보를 공유한다면 많은 시간을 절약할 수 있습니다. 별것 아닌 것 같기도 하지만 저의 경우에는 많은 시간을 절약할 수 있었습니다. 간단한 텍스트 파일로 알아볼 수 있도록 파일이름을 길게 지어 참고 자료라는 폴더에 저장해 놓고 참고하고 계속 추가하여 그 내용을 늘렸습니다. 그 결과 인터넷 게시판을 뒤지는 시간을 많이 줄일 수 있었고 좀 더 생산적인 일을 하는데 전념할 수 있었습니다. 평소에 불편하거나 개선했으면 하는 것을 스스로 해 보시기 바랍니다. 처음에는 좀 어렵겠지만 어느 정도 정리가 되면 소중한 시간을 많이 절약할 수 있으실 겁니다.

다음에는 시간 관리 일지에 관하여 말씀드리겠습니다.