productivity

Stop making progress and start making products.

Is Scrum dangerous that way? Absolutely. If you are doing Scrum well it will require you to change your life. You will have to give away your belief that having a checklist makes things run smoothly. You will have to stop chasing the perfect process and, instead, start cultivating your ability to trust the resourcefulness of others. You will cease using line items checked off on a plan as your measure of value.

InfoQ: How Agile Benefits the Individual

“…Most importantly, I still feel I’m growing as a developer. I honestly believe the best thing a developer can do in their career is to always be learning. Everything else will follow. " InfoQ: How Agile Benefits the Individual Things에 적은 “할 일 목록"에는 늘 “새로운 거 한 가지 배우기"가 있다. 오늘 난 개발자로써 뭘 배웠을까?

(펌) 난 더는 미루지 않을 거야!

미루는 사람들은 완벽주의자다. 다만, 완벽하게 일을 해내지 못할 따름이다 심하게 공감하는 말. 의식적으로 일을 미루지 않으려고 하는데 자꾸 하고 싶은 일을 먼저 하게 된다. -_- 그럴 때마다 “어차피 해야 할 일이면 빨리 즐겁게 해 버리자” 라고 되뇐다. via へ( ̄∇ ̄へ) (っ ̄∇ ̄)っ :: 더는 미적거리고 싶지 않은 사람들을 위하여 - 난 더는 미루지 않을 거야!

덩치에 맞는 옷을 입자.

개발에 그렇게 많은 문서가 필요 없다는 글. 정말로 업데이트할 수 있을 정도의 핵심 문서만 만들어야 한다는 글. 저작권법때문에 인용글 삭제 via 소프트웨어 개발의 극과 극 100% 동감. 매 단계마다 몇 가지의 문서를 만들어내야 하고, 그런 과제 몇 개를 동시에 진행하면서 문서의 품질을 기대한다는 것 자체가 무리한 요구 아닌가? 창피하지만 우린 그런 문서 쓰는 거 교육 받은 적도 없다고. -_-

Waterfall과 Agile? 현실은?

이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다 via Waterfall과 Agile :: All of Software 정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데. 왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까? 최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

Time Tracker

Downloads: TimeEdition is a Simple and Stylish Time Tracker 만약에 내가 하는 일이 외부 인터럽트에 의해 중단되는 경우가 적다면 유용할 듯하다. 근데 전화, 메신저, 긴급 메일등의 인터럽트로 점철된 현실은… 그래도 Bakcpack에서 제공하는 journal 의 기능과 더불과 과거를 회고하는데 도움이 되겠다. 매년 시간이 지나도 뭘 했는지 전혀 기억이 없는 요즘의 나를 위한 툴인 듯. gCal/iCal/Outlook등으로도 업로드가 된단다.

Test 되지 않은 것은 분명히 문제가 있다.

지난 주까지 개발자들이 BT를 마치고 부서내 검증팀에 패키지가 넘어갔다. 조마조마 했는데 본격적인(?) 시험 첫날 점수가 38점. 달랑 13가지 시험했는데 그 중에 8개가 NOK 판정을 받았다. 문제점 나온 걸 보니 참 답답하다. 다행히(?) 많은 문제들이 H/W 케이블 이슈로 보이고, 아직 정리되지 못한 DB data 초기값 오류로 보인다. 후자의 경우에도 참 할 말은 많지만 일단 접고. 그 외에 눈에 띄는 문제는 역시나 제대로 시험하지 않은 경우에 발생한 문제다. 부서내 검증랩이 생긴 지 근 1년이 되었다.

Scrum

Agile 방법론에서 가장 유명한 것은 XP이지만 그 외에는 Scrum도 있다. Scrum은 MS에서 사용해서 유명한 듯하다. MS에서 나온 몇 권의 책도 있고, 이번에 Scrum 책 한권이 번역되어 나왔다. 아직 읽어보지는 못했지만 정진호 님의 글을 읽다가 손뼉을 치고 싶을 만큼 “맞아 맞아"를 외치게 한 문장 하나. 프로젝트의 일정이 점점 꼬이고 제어할 수 없는 상태에 빠지는 것은 숨어 있던 문제가 나중에 드러나기 때문입니다. Scrum은 숨어있는 문제를 빨리 드러나게 해 준다고 하는데 도대체 어떻게 하길래 그럴 수 있을까?

탁구 팀 vs. 배구 팀

탁구 같은 팀이라. 분명 같은 팀일텐데 문제나 이슈를 마치 탁구공을 넘기듯 상대방에게 넘긴다. 제 문제는 아니네요. 전 문제 없어요. 전 잘 처리했어요 A 담당자가 봐야해요. 배구 팀은 그렇지 않다. 하나의 문제에 대해 서로 같이 확인한다.(어찌 보면 탁구 팀처럼 공을 남에게 떠넘기는 것처럼 보일 수 있지만 ㅎㅎ) 점수를 얻기 위해 공을 받고, 토스하고, 스파이크를 때리 듯 서로 같은 목적을 가지고 함께 노력한다. 얼마나 아름다운 모습인가… 보면 볼 수록 우리 팀은 탁구 팀이다.

Zen To Done(ZTD)

GTD도 아직 실천을 못하고 있는데 ZTD(Zen To Done)라는 게 있다는 걸 알았다. ZTD가 GTD의 고급(?) 버전은 아니고 GTD의 실천 과정에서 만나게 되는 문제점을 해결하려는 노력이라고 한다. 일전에도 GTD 관련 링크로 알려져 있는 Zen Habits를 몇 번 방문하기 했었는데. 궁금하니 시간 날때마다 살펴봐야겠다. 친절하게 한글로 정리해 주신 곳도 있으니.