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. You will face your fears, all of them, about yourself and other people. You will stop making progress and start making products.

회사에서 무슨 껀수만 있으면 새로운 Process를 만드는 것이 유행처럼 되어 가는 것이 두렵다. 뭐든지 필요한 Process가 없어서 문제가 생기는 거라고 생각하는 사람들이 자리를 차지하고 있어 정작 그 Process를 따라야 하는 개발자들은 죽어난다.

Progress가 아니라 Product을 만들어라. 결국 본질에 충실해야 한다는 말. 그 분들은 혹시 Progress도 Product도 아닌 Process를 만드는 것이 목표라고 착각하고 있는 것은 아닐까?

출처 : [This is not like That](http://agileanarchy.wordpress.com/2009/12/18/this-is-not-like-that/)

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](http://www.infoq.com/news/2008/12/Agile-Benefits-Individuals)

Things에 적은 “할 일 목록”에는 늘 “새로운 거 한 가지 배우기”가 있다.

오늘 난 개발자로써 뭘 배웠을까?

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

> 미루는 사람들은 완벽주의자다. 다만, 완벽하게 일을 해내지 못할 따름이다

심하게 공감하는 말. 의식적으로 일을 미루지 않으려고 하는데 자꾸 하고 싶은 일을 먼저 하게 된다. -_-

그럴 때마다 “어차피 해야 할 일이면 빨리 즐겁게 해 버리자” 라고 되뇐다.

via [へ( ̄∇ ̄へ) (っ ̄∇ ̄)っ :: 더는 미적거리고 싶지 않은 사람들을 위하여 – 난 더는 미루지 않을 거야!](http://kc99.tistory.com/478)

덩치에 맞는 옷을 입자.

개발에 그렇게 많은 문서가 필요 없다는 글. 정말로 업데이트할 수 있을 정도의 핵심 문서만 만들어야 한다는 글.
저작권법때문에 인용글 삭제

via [소프트웨어 개발의 극과 극](http://allofsoftware.net/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9D%98-%EA%B7%B9%EA%B3%BC-%EA%B7%B9)

100% 동감. 매 단계마다 몇 가지의 문서를 만들어내야 하고, 그런 과제 몇 개를 동시에 진행하면서 문서의 품질을 기대한다는 것 자체가 무리한 요구 아닌가? 창피하지만 우린 그런 문서 쓰는 거 교육 받은 적도 없다고. -_-

Waterfall과 Agile? 현실은?

> 이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다

via [Waterfall과 Agile :: All of Software](http://allofsoftware.net/entry/Waterfall)

정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데.
왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까?

최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

내가 우물한 개구리이거나(상당부분 그렇긴 하지만) 혹은 현실은 인터넷에서 떠드는 소프트웨어 공학과는 아직 거리가 있거나.

Time Tracker

[Downloads: TimeEdition is a Simple and Stylish Time Tracker](http://lifehacker.com/5147529/timeedition-is-a-simple-and-stylish-time-tracker)

만약에 내가 하는 일이 외부 인터럽트에 의해 중단되는 경우가 적다면 유용할 듯하다.
근데 전화, 메신저, 긴급 메일등의 인터럽트로 점철된 현실은…

그래도 Bakcpack에서 제공하는 journal 의 기능과 더불과 과거를 회고하는데 도움이 되겠다. 매년 시간이 지나도 뭘 했는지 전혀 기억이 없는 요즘의 나를 위한 툴인 듯.

gCal/iCal/Outlook등으로도 업로드가 된단다.

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

지난 주까지 개발자들이 BT를 마치고 부서내 검증팀에 패키지가 넘어갔다.
조마조마 했는데 본격적인(?) 시험 첫날 점수가 38점. 달랑 13가지 시험했는데 그 중에 8개가 NOK 판정을 받았다.

문제점 나온 걸 보니 참 답답하다.
다행히(?) 많은 문제들이 H/W 케이블 이슈로 보이고, 아직 정리되지 못한 DB data 초기값 오류로 보인다. 후자의 경우에도 참 할 말은 많지만 일단 접고.
그 외에 눈에 띄는 문제는 역시나 제대로 시험하지 않은 경우에 발생한 문제다.

부서내 검증랩이 생긴 지 근 1년이 되었다. 그들도 이제 몇 차례(10번은 넘은 듯) 시험을 하면서 나름대로의 노하우가 생겨서 흔히 개발자들이 간과하기 쉬운 경우도 꼭 시험할 것이다. 이번에도 개발자들이 제대로 확인하지 않은 내용들이 우수수 걸리고 있다.

이번에도 어리숙한 친구들이 딱 걸렸다. 당최 이해가 안되는 것은 늘 하는 가장 기본적인 설정에서 동작하는 것을 확인했다고 테스트 다했다고 하는 마음이다.

사실 늘 하던 경우를 위해 코드를 수정해 가면 이 과제를 할 이유는 없다. 이 과제에서 바뀐 내용이 무엇이고, 그 변경된 내용을 확인하려면 어떤 경우를 테스트해야 하는 지를 고민했어야 한다. 구체적으로 못 챙긴 내 잘못도 크지만 실은 각 파트별 PA에게 몇 번을 반복해서 했던 말이다.

> 변경사항에 대해 확인하고, 그 내용이 구현되었는 지, Test case에 추가되었는 지 확인해라

사람들은 말한다. PA 한 번 쯤은 해 봐야 한다고. 나도 평생 개발자로 남고 싶은 심정이지만 그래도 딱 1번 쯤은 해 볼 필요가 있다고 생각한다. 그래야 남의 입장이 되어 보고, 개발자들을 이끌고 과제를 진행하는 역할도 해봐야 얼마나 담당자들이 허술하게 생각하는지를 알 수 있다.
이런 경험을 한번 해 봐야 내 담당 블럭을 책임 질 때도 좀 더 신경쓰게 될 것이다.
그리고 얼마나 사람들에게 일을 하게 만드는 것이 어려운 지.
얼마나 사람들이 Block Test(Unit Test)을 허술하게 하는 지,
얼마나 사람들이 남에 대해서 배려하지 않는 지, 이런 점을 보완하기 위해 “뭔가”가 필요하다는 것을 알게 된다. 아니 알게 되었다.

자 그럼 이제 어떻게 해야 할까?

사실 이런 점을 개선하기에 하나의 과제만을 담당하는 PA(Project Assistant?)는 적당한 배역이 아니다. 개발자를 챙기는 매니저들이 신경을 써 줘야 하는데 매니저들 대부분이 PA를 겸직하고 있어 그 들 역시 신경을 쓸 겨를이 없다. 하지만 개발자들에게 있어 PA는 그저 시어머니 같은 역할 일 뿐이다. 일정을 재촉하고, 문제점 해결을 종용하는 역할만을 하니. 사실 담당자들에게 있어 어떤 과제를 (더) 한다는 것은 큰 의미가 없다. 그거 귀찮은 일 하나가 늘었다는 것 외에 어떤 의미가 있겠는 가.

그래서 결국 개발자들의 자질을 높이고, 개발자가 만들어내는 코드의 품질을 높이기 위해서는 매니저나 선배들이 관심을 가지고 좋은 습관을 들이도록 잔소리도 하고, 좋은 본보기를 보여줘야 한다.

써 놓고 보니 내 주변의 현실의 정확히 정 반대의 이야기를 쓰고 있다.

그나저나 오늘 받은 숙제를 내일 아침 가자 마자 확인하려고 할 텐데

> 점수가 너무 낮다. 근본 문제가 뭐고, 해결 책이 뭐냐?

Scrum

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

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

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

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

[Agile software with Scrum development](http://image.yes24.com/momo/TopCate66/MidCate07/6567075.jpg)

관련 포스트.
[(프로젝트 초기의) 때 이른 고통](http://younghoe.info/980)

Zen To Done(ZTD)

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

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

일전에도 GTD 관련 링크로 알려져 있는 [Zen Habits](http://zenhabits.net/)를 몇 번 방문하기 했었는데.

궁금하니 시간 날때마다 살펴봐야겠다. 친절하게 한글로 정리해 주신 [곳](http://kr.geek2live.org/tag/ZTD )도 있으니.

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

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

Rephrasing 하려고 했다가 그냥 도비호님 [포스트](http://dobiho.com/?p=1084)에 적은 댓글을 그냥 옮겨왔다.

> 분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다.
>
> 그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.
>
> 그래서 부서내 게시판을 하나 만들어서 내가 아닌 남의 프로그램에 대해 아쉬운 점이 있으면 적는 건 어떨까 하는 생각을 했습니다. 그리고 주기적으로 각 부서장들이 모여서 리뷰를 해서 정말 코드 수정까지 반영할 만한 가치가 것을 뽑아서 다음 번 패치때 추가하는 겁니다.
>
> 근데 아직 제대로 제안은 못했습니다. 제 생각에는 그럴 듯한데 말이죠.

* [개밥 먹기](http://en.wikipedia.org/wiki/Eating_one%27s_own_dog_food)란 자신이 만든 프로그램을 직접 사용하는 것을 의미한다. 내가 만든 걸 내가 사용해 봐야 당연히 소비자가 느낄 수 있는 불편함이나 아쉬운 점을 먼저 느낄 수 있을 것이다.