스크럼 Scrum
국내도서>컴퓨터/인터넷
저자 : 켄 슈와버,마이크 비들 / 박일,김기웅 역
출판 : 인사이트 2008.10.01
상세보기

   프로그래밍에서 가장 중요한 것은?
 

  적게는 2~3명, 많게는 300명 이상의 공동작업으로 이루어지는 현재 소프트웨어 프로젝트에서 프로그래밍을 할 때, 가장 중요한 것을 꼽으라면, 단연 "커뮤니케이션 능력" 을 들 것이다. 프로그래밍이란 것이, "언어" 를 이용하여 "창작"을 하는 과정이기 때문에, 일종의 공동 문집을 만들어 나가는 과정이다. 한권의 문집이 군더더기 없는 글의 집합이 되려면 글 한 편 한 편이 올바라야 하지만, 무엇보다 무엇을 위한 문집인지, 어떻게 통일성을 갖는 한 권의 책을 만들어 낼 것인지 의사를 결정하고, 결정된 내용을 모두 함께 따르는 것이 중요하다. 교정은 누가 볼 것이고, 부족한 내용은 누가 보충할 것인지, 퇴고는 어느 방향으로 할 것인지 등을 결정하고, 지시하고, 지시에 따르는 것이 필요하다. 대규모 프로젝트 또한 이와 동일해서, 수백명의 똑똑한 개발자들이 모인 상황에서 가장 중요한 것은 한방향으로 의샇소통을 하는 것이다.

  그럼에도 불구하고, 현실에서는 여전히 군대식 의사소통이 만연해 있는 것이 사실이다. 욕설과 함께 설명이 생략된 일정 제시와, 앞뒤 안재고 무조건 "예 알겠습니다" 를 복명복창하는 중간 관리자들, 그리고 내용은 묻지 않고 무조건 수정하라고 문제를 재지정하는 팀 리더들과 조금이라도 다른 팀과 얽히면 문제를 토스하기에 바쁜 실무자들. 마지막으로 뭘 해야 할지 알지 못하고 헤메고 있는 신입 사원까지. 하나의 개발팀이 제대로 돌아가는 것은 기적에 가깝다.

   우리, 이제 계급장을 떼고 스크럼을 해보자 
 

  특히, 긱(Gig)들이 모여있다는 프로그래머 집단 사이에도 엄청난 권위주의가 팽배해 있다는 것은 정말 신기한 일이다. 군대를 안다녀온 여자들 까지도, 선배라는 타이틀과 함께 목에 힘 딱 주고, 너는 내가 시키는 일이나 해라. 니가 뭘 아냐. 난 니가 대학에서 찌질대고 있을 때, 이 코드를 혼자 다 짰다. 는 식으로 업무지시를 하는 일도 흔하고, 문제를 토스하는 와중에서도 어느쪽이 짬이 높냐가 최종 목적지를 결정짓는 일도 흔하다. 믿기지 않겠지만, 대한민국의 대부분의 조직은 이렇게 경직되어 있고, 이런 문화 자체가 개발자의 창의성을 죽이고, 더 나아가 팀의 생산성을 극도로 떨어뜨린다. 모두 같이 밤을 새고 있지만, 그 사람들이 하고 있는 일이 유럽 필드에서 날아올 메일 한통이라는 사실은 종종 내가 무엇을 위해 이짓을 하고 있나 하는 생각을 들게 한다. 좀더 나아가, 실제로 일은 컴퓨터가 하고 있는데, 사람들이 그 뒤에서 결과를 던져주기만을 두 세시간씩 기다리는 일도 흔하다.

  스크럼의 가장 큰 장점은 각자 어제 한 일, 오늘 할 일, 일을 하는데 막히는 점을 자주 만나 이야기 함으로써 서로의 진행상황을 공유하며, 관리자들에게는 할 일을, 개발자들에게는 해야 할 일을 명확히 한다는 점이다. 무엇보다 상명 하복이 아닌 자유로운 대화는 개발자 한 사람 한 사람의 존엄성을 높여줄 수 있다. 조직을 숨쉬게 만들 수 있다.

  이제 우리 스크럼을 해보자. 되도 않는 직급이니 경력이니 입사 기수 같은거 던져 버리고, 프로그래머 대 프로그래머로 대화하며 일을 해보자. 우리에게 필요한 것은 막무가내식 지시가 아니라 서로의 생각을 공유할 수 있는 통로이다.




Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  새로운 프로젝트가 시작되면서 협력업체의 도움을 받기로 했다. 인력이 부족하다는 판단에서 상부에서 결정한 것이지만, 맨먼스 미신의 신봉자로써, 이번에도 결과는 별로 좋지 않을 것으로 생각된다. 내가 직접 하는 것보다 더 일이 빨리 될 것 같지도 않고, 오히려 커뮤니케이션에 문제만 있을 것 같은데... 위에서 시키는 일이라 어쩔 수는 없다. 

  사실, 협력업체분이 제대로 준비되지 않은 상태에서 일을 시작하는 것과, 평소에 하던 일을 하던 사람이 투입되서 일을 하는 것은 속도와 효율에 차이가 클 수 밖에 없다. 작업결과에 대한 머지는 결국 내일이 될 것이고... 나중에 정말 급한 문제가 생기면 또 내가 수정하게 될 것이고... 인력을 이런식으로 투입한다고 더 효율이 올라가지 않는 다는건 이미 수없이 많은 프로젝트에서 증명된 명제 아닌가. 이러니 IT가 아니고 제조업이라고 자꾸 투덜대는 일이 생긱는거다.

  위에서 야근 시키면 열라 짜증내던 난데, 이젠 야근을 강요하고 강제하는 입장이 되버리는 거다. 참 불합리한건데, 장비 하나 제대로 갖추지 못해서 일 시키는데만 일주일 가까이 딜레이가 된거다. 시뮬레이터도 없어서, 다운 받아가면서 확인하면 작업이 얼마나 비효율 적인지 알면서도 "몇일 까지 하라고 팍팍 쫘요" 라고 위에서 날 쪼는데, 참. 이건 아닌데...  그러잖아도 "하청은 IT의 막장"이라는 말이 나오는데, 미안하게도 거기에 내가 일조하게 된 것 같아 기분이 좋지 않다.

  언젠가는, 나도 과장이되고 (잘하면) 부장이 되서 개발에서 손 떼고 인력관리에 집중하라는 압박을 받을 텐데, 벌써부터 걱정이된다. "우리팀은 애자일 방식으로 8시간 근무 철저히 준수하고, 매일 스크럼 하고 코딩은 반드시 패어로 합니다" 라고 말하고 팀을 운영한다면, 위에서는 "왜 니네팀은 다른 팀 다 남아있는데 집에 가냐?" 는 질문을 받을테고 밑에 사람들한테는 "일하기도 바빠 죽겠는데 무슨 놈의 스크럼이냐"  혹은 "둘이 나눠 짜도 다 못하는데 언제 둘이 같이 짜고 있냐" 같은 말을 들을 것 같아서 그렇다. 그럼 난 뭐라고 둘러대야 하지?

  아니면, 그냥 내 선배들이 그랬던 것 처럼 나도 짜증나는 또 한명의 과장이 되는 것이 필연인가... (바둑에서 말하는 필연 말이다. 이 행마를 진행할 수 밖에 없는 필연적 국면같은...)

  아 이런일 하기 정말 싫은데... 정말 싫은데... 그냥 내가 야근하고 말지. 이건 정말 아니다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.10 13:07 신고
    댓글 주소 수정/삭제 댓글
    사실 야근을 직접 하는것 보다도 시키게 되는 입장이 더 난감하죠. 물론 좀 지나면 내성이 생깁니다만 ㅎㅎ
    뭐랄까..한국 IT는 오히려 다른곳보다 더 경직된 곳이 아닐까 싶어요.
    하드웨어는 최신기술을 만지고 있지만 소프트웨어와 시스템 자체는 예전껄 고집하죠.


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2020/04   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Total : 317,428
Today : 23 Yesterday : 40