Category Archives: productivity - Page 2

Scrum

Agile 방법론에서 가장 유명한 것은 XP이지만 그 외에는 Scrum도 있다. Scrum은 MS에서 사용해서 유명한 듯하다. MS에서 나온 몇 권의 책도 있고,

이번에 Scrum 책 한권이 번역되어 나왔다. 아직 읽어보지는 못했지만 정진호 님의 글을 읽다가 손뼉을 치고 싶을 만큼 “맞아 맞아”를 외치게 한 문장 하나.

프로젝트의 일정이 점점 꼬이고 제어할 수 없는 상태에 빠지는 것은 숨어 있던 문제가 나중에 드러나기 때문입니다.

Scrum은 숨어있는 문제를 빨리 드러나게 해 준다고 하는데 도대체 어떻게 하길래 그럴 수 있을까? 궁금하다.

Agile software with Scrum development

관련 포스트. (프로젝트 초기의) 때 이른 고통

Zen To Done(ZTD)

GTD도 아직 실천을 못하고 있는데 ZTD(Zen To Done)라는 게 있다는 걸 알았다.

ZTD가 GTD의 고급(?) 버전은 아니고 GTD의 실천 과정에서 만나게 되는 문제점을 해결하려는 노력이라고 한다.

일전에도 GTD 관련 링크로 알려져 있는 Zen Habits를 몇 번 방문하기 했었는데.

궁금하니 시간 날때마다 살펴봐야겠다. 친절하게 한글로 정리해 주신 도 있으니.

개밥 먹기(Eating one’s own dog food)

얼마 전에 했던 생각인데 아직 파트장등에게 제대로 제안을 해 보지는 못한 아이디어 하나.

Rephrasing 하려고 했다가 그냥 도비호님 포스트에 적은 댓글을 그냥 옮겨왔다.

분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다.

그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.

그래서 부서내 게시판을 하나 만들어서 내가 아닌 남의 프로그램에 대해 아쉬운 점이 있으면 적는 건 어떨까 하는 생각을 했습니다. 그리고 주기적으로 각 부서장들이 모여서 리뷰를 해서 정말 코드 수정까지 반영할 만한 가치가 것을 뽑아서 다음 번 패치때 추가하는 겁니다.

근데 아직 제대로 제안은 못했습니다. 제 생각에는 그럴 듯한데 말이죠.

  • 개밥 먹기란 자신이 만든 프로그램을 직접 사용하는 것을 의미한다. 내가 만든 걸 내가 사용해 봐야 당연히 소비자가 느낄 수 있는 불편함이나 아쉬운 점을 먼저 느낄 수 있을 것이다.

(펌) 랜디 포시의 시간 경영법

공병호의 시간 경영법 메일 중

  • 시간은 명쾌하게 관리되어야 한다. 마치 돈처럼.
  • 계획은 늘 바뀔 수 있지만, 단 분명할 때만 바꿔라
  • 스스로에게 물어라. 옳은 일에 시간을 쓰고 있는가?
  • 전화를 사용하기 전 다시 생각해봐라
  • 위임하라
  • 제대로 쉬어라

이 중에서도 “옳은 일에 시간을 쓰고 있는가?”가 가장 핵심이 아닐까 싶다. 지금도 시간을 “죽이고” 있는건 아닌 지 반성해 보자.

시간이 가장 소중한 자원

출처 : 내가 애자일을 좋아하는 이유, 그리고 황금률

저작권법때문에 인용문 삭제

늘 시간이 없다고 하는 사람들에게 아예 일할 수 있는 시간을 제한해 버린다면 어떨까?

시간이 없다고 아우성 치다가 ‘시간을 너무 조금밖에 안 줘서 일을 못 끝냈어요?”라고 하는 사람/시기도 있겠지만, 그래도 주어진 짧은 시간내에 일을 마무리 하기 위해 다양한 시도를 하는 사람/시기도 있을 것이다.

만일 후자처럼만 된다면 모두에게 win/win이 아닐까? 인건비가 사실 제품 원가에 많은 비중을 차지할테니 자연스럽게 그 비용이 줄 거고, 개개인도 좀 더 가족과 함께 지내는 생활이 많아져 좋아질 것이고. 그렇지 않을까? 내가 너무 이상적인가?

저작권법때문에 인용문 삭제

윗 글에 대한 댓글 중 인상에 남는 것. 팀장님은 팀장 역할의 미덕을 뭐라고 생각하실까?

저 말에 대해서는 해석차이가 있을 수 있겠지만, 적어도 난 일을 덜하고, 칼퇴근하겠다는 것보다는 좀 더 근무시간에 집중해서 필요한 일을 하고, 불필요한 일은 최대한 줄여서 칼퇴근을 지키겠다는 말로 해석한다.

소통의 문제는 여기에도

요즘 “소통의 부재”가 유행이다.

그런데 그 “소통의 부재”가 청와대와 국민 사이에만 있는 것은 아닐 것이다.

회사 내의 “소통의 부재”는 참 많은 생각을 하게 한다.

Agile에서 적극 추천하고 있는 “Stand-up meeting”을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다.

하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다.

늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나.

피드백? 그런 거 별로 없다.

게다가 대장이 해주는 이야기는 대부분 진행 중인 과제의 “문제점”인 경우가 많아 듣기에 썩 좋은 이야기는 아니다. 타산지석으로 삼으면 좋겠지만 아쉽게도 전달하는 사람은 항상 “저런 저런 문제가 있었다. 우리는 이게 문제다”가 논지이기 때문에 과히 듣기 좋지는 않다. 맞는 이야기겠지만 비슷한 톤으로 비슷한 논지의 이야기를 주 5일 듣는다고 생각해 보자. 끔찍하지 않은가? 이건 마치 예전 5공때 9시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.

아쉽다.

같은 이야기를 하더라도 조금만 다른 투로 친근하게, 때로는 능글맞게, 그리고 피드백을 쉽게 할 수 있는 분위기를 만들면서 한다면 좋겠는지.

그런 분위기를 만드는 게 쉽지는 않겠지만 노력을 안하는 듯 하니.

여기도 “소통”의 문제가 심각하다.

“소통”이 없으니 “팀 웍”을 꿈도 꾸지 못하고, 남이 뭐 하는 지 알 수도 없다.

log activity with launchy

  1. make a directory named c:scratch

  2. create a python script log.py and save the same directory import time
    import sys

    now = time.localtime(time.time())
    tim=time.strftime(“%Y/%m/%d %H:%M:%S”, now)

    fp = open(“c:scratchmyLog.txt”, “a”)
    message = ” “.join(sys.argv[1:])
    print >>fp, tim+” “+message

    fp.close()

  3. register that directory and *.py in launchy category and rescan

  4. Restart launchy

  5. invoke launchy and type “log” and type tab

  6. jot down log message and enter

Reference http://benkraal.wordpress.com/2007/05/16/launchy-append-text-to-a-file-from-anywhere/