sosa0sa.com

지난 주까지 개발자들이 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는 그저 시어머니 같은 역할 일 뿐이다. 일정을 재촉하고, 문제점 해결을 종용하는 역할만을 하니. 사실 담당자들에게 있어 어떤 과제를 (더) 한다는 것은 큰 의미가 없다. 그거 귀찮은 일 하나가 늘었다는 것 외에 어떤 의미가 있겠는 가.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

하루 8시간, 주 40시간이라는 범위로, 시간을 한정 지어 버리면… 프로젝트에서 가장 소중한 자원은 바로 시간이 됩니다. 일종의 40시간이라는 벼랑끝 전술을 사용하면, 주어진 시간 안에서 최대한의 성과를 내놓으려고, 팀이 자연스럽게 노력하게 되기 때문입니다.

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

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

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

팀장의 최대 미덕은 “칼퇴근의 강요”라는 제 생각에 조금 더 확신을 주는 글이네요.

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

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

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

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

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

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

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

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

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

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

아쉽다.

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

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

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

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