주 48시간 근무? 제가 Extreme Programming(이하 XP)에 환상을 가진 이유는 XP 규칙중에 주 48시간 근무를 지켜라~ 라는 규칙이 있기 때문이었어요. 아름다운 규칙입니다. XP에서는 이 규칙을 통해 ‘진정한 생산성’ 이 무엇인지 알려주고 있습니다. 야근이 일상화 된 곳에서는 크게 바쁘지 않는 이상 어차피 야근할 것 일과시간에는 예를들면 인터넷 뉴스 보면서 이명박 정부 욕하며 천천히 일할것이고, 주어진 일을 빨리 완수할 수 있다 하더라도 일 끝내면 위에서 또 일거리 던져줄까봐 밤늦게까지 일부러 천천히 일하는 분위기는 야근이 일상화된 곳에서 종종 벌어지는 일입니다. (우리 회사는 이런 분위기가 아니라서 좋습니다~!) 주48시간 근무를 우리나라 현장에 적용하면 꼭 주48시간 근무를 지켜라~ 보다는 일과시간에 집중해서 일하고 되도록 업무에 피로와 지장을 주는 야근은 피하자~ 가 될 것 같습니다.
요즘 저는 고객 담당자와 직접 대면하는 파견지에 나왔고, 중요한 일을 해서 그런지 긴장감이 듭니다. 이 일은 이번주내로 끝내야 합니다. 그런데 일과 후에는 개인적인 부상 치료로 꼭 퇴근을 하는 상황에 있습니다. 그래서 일과 시간에는 딴 생각 하지 않고 저절로 일에 집중이 되는 것을 경험하고 있습니다.
지금이 아니라 다른때라도 '일과시간에 긴장감을 가지고 일하면서, 시간 제한을 두고 일과시간까지 꼭 끝내자~' 라고 다짐하면 주48시간 근무의 진정한 뜻을 비스무리~ 하게 실천할 수 있을 것입니다. 꼭 주48시간 보다는 그 속에 담긴 뜻을 실천해야 겠습니다. 그러나 언제나 말은 쉽고 실천은 어렵습니다.
TDD(Test Driven Development = 테스트 주도 개발) 흉내내기? 말 그대로 진짜 TDD가 아니라 흉내내기 입니다. 이번에 제가 맡은 모듈을 만지면서 상당히 중요하면서도 은근히 까다로운 로직처리를 해야 되는 부분이 새로 생겼습니다. 예를 들어 >, >= 이런 사소한 부등호만 실수해도 모듈 전체가 망가지는 민감한 부분이었습니다. 이런 민감한 로직이야말로 TDD로 천천히 정밀하게 로직을 만들어나가면 좋은 상황이었습니다.
그러나 제가 아는 TDD는(내가 정말 TDD를 해본건지 확실히 모르겠습니다. 왜냐면 독학했기 때문이죠.) 안정감있게 개발은 가능해도 개발 속도는 느렸다는 경험이 있었습니다.
지금 상황은 빨리 개발해야 했습니다. 그래서 '빨리 개발하자~'와 '정확하게 개발하자~'의 가운데 균형을 찾아서 일단 로직부터 빨리 만들고, 로직을 검증하는 테스트 코드를 대충 만들어서 검증한 다음에, 나중에 시간날 때 테스트 코드를 정밀하게 다듬는 식으로 개발을 진행했습니다.
어떤 소스는 굳이 테스트 코드를 만들지 못하기도 했는데 그렇더라도 이 로직은 이런저런 테스트 코드들이 필요하겠구나~ 라는 머릿속으로 가상으로 TDD한다는 생각을 가지고 개발을 했습니다.
제가 말하고 싶은 것은 꼭 반듯하게 벽돌 쌓듯이 정확하게 테스트 코드 만들고 프로그램 짜는 식의 TDD를 하지 못하더라도 머릿속에 가상으로 TDD 중심적으로 생각하며 프로그램을 짠다면 그래도 튼튼한 개발을 하는데 그냥 개발하는 것 보다는 도움이 되는 것 같다는 것을 이번에 경험했습니다.
출근을 위해 아침 6시에 꼭 일어나야겠다~ 라고 다짐하면 대부분 그 시간대에 일어날 수 있는 이유는 아침 6시라는 생각의 끈을 놓지 않고 잠을 자기 때문일 것입니다. 프로그래밍도 TDD 중심으로 개발하겠다는 생각의 끈을 놓지 않는다면 꼭 정확하게 TDD를 하지 않더라도 TDD의 효과를 볼 수 있지 않을까라는 생각을 해보았습니다.
> IBM developerWorks
Extreme Programming : 돌아온 "XP distilled", Part 1
Extreme Programming : "XP distilled", Part 2
Extreme Programming : Test-driven 프로그래밍
Extreme Programming : 다르게 생각하기
> 산골 블로그 developerWorks
2008/04/03 - [프로그래머/IBM developerWorks] - 개발자와 프로그래밍의 가치을 높여주는 JUnit
2008/03/09 - [프로그래머/IBM developerWorks] - 사람(개발자)을 위한 자동화 기술에 눈을 뜨다.
2008/04/09 - [프로그래머/칼럼 쓰기] - 에러 잡는 마음가짐
'프로젝트 > IBM DW블로거' 카테고리의 다른 글
| IBM developerWorks, KSUG의 OSGi 강좌1 (4) | 2008/07/31 |
|---|---|
| 자바 개발자의 이클립스 혜택 (12) | 2008/07/28 |
| Extreme Programming에 조금씩 가까이 가기 (8) | 2008/07/03 |
| 프로젝트 수행시 이해관계자의 활발한 참여가 중요한 이유 (8) | 2008/06/29 |
| 객체-관계 맵핑 사고의 고수를 꿈꾸다. (2) | 2008/06/28 |
| Apache Jmeter를 활용한 부하테스트 (8) | 2008/06/23 |
TAG DeveloperWorks,
extreme programming,
IBM,
ibm developerworks,
IT,
IT개발자,
개발자,
애자일,
자바,
프로그래머,
프로그래밍
댓글을 달아 주세요
흑~ 무플의 아픔을 엉아가 달래주마~ ^^
엉덩이도 달래주세요~ ^ ^
저도..??동참???
사회적 기업 열심히 하자고~! ^ ^
뭔 이야기인지 하나도 모르겠습니다;;;
근데 주 48시간이면 하루에 8시간인가요?
규칙이 단지 규칙이 아닐뿐이라서 좋네요
실제로 뭐 우리나라의 대기업 생산직의 경우는 잔업을 해야지 돈이 된다고 하고 있고..
사무직이 경우도 삼성이나 엘지같은 경우엔 심심하면 회의하고 프로젝트하고;;;
몇몇 다니는 지인들을 보니깐 굉장히 안타깝더군요..
(물론, 전 그런곳에 갈 능력조차 안됩니다만..)
뭐 돈을 많이 주니깐 뭐라 하지는 못하겠지만 어째든 4~5년 하면 지쳐서 다 나간답니다..;;
하긴, 그렇게 하니깐 그나마..세계적인 기업이 될 수 있겠지요.
제가 복지학과라서 외국의 노동법이나 이런것도 살짝 배우곤 하는데
독일이나 뭐 기타 유럽쪽의 선진국들의 법을 보자면 (지켜지는지는 모르겠구요)
정말 우리나라보다 몇십년씩 앞서가는 이유가 있구나라는 생각이 마구 든다지요.
오래 매달린다고 생산성이 절대 높아지는건 아니잖아요..
공부도 그렇구요;; 쉴땐 쉬고 할땐 열심히!!!
어느 직업이나 야근문제로 고생이네요..
고리타분한 얘기지만 말씀처럼 쉴땐 쉬고
할땐 열심히 해야겠어요~! ^ ^
daliot 2009/08/27 20:20 댓글주소 수정/삭제 댓글쓰기
켄트 벡이 한국에 옵니다. 관심이 있으실 것 같아 링크를 남깁니다.
http://www.sten.or.kr/bbs/board.php?bo_table=news&wr_id=1807
daliot 2009/08/30 17:09 댓글주소 수정/삭제 댓글쓰기
9월 4일 열리는 Kent Beck의 Responsive Design 세미나에 대한 호응이 너무 좋아서 정원이 이미 꽉차고 말았습니다. 9월 2일에도 같은 세미나를 하기 때문에 혹시라도 선착순에 밀리신 분이시라면 한번더 기회가 있다는 것을 알려 드립니다.
http://sten.or.kr/bbs/board.php?bo_table=news&wr_id=1822