달력

12022  이전 다음

  •  
  •  
  •  
  •  
  •  
  •  
  • 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
  • 31
  •  
  •  
  •  
  •  
  •  

[서적]'엔터프라이즈급 애자일 방법론'이라, 개발조직의 확장

낙서장 2008. 11. 25. 02:40
간만에 책을 하나 다 읽었습니다. 작년 Working Effectively With Legacy Code 원서의 마법에 걸려서 지난 일 년간 처음 잡아서 끝까지 시원하게 읽은 책이 없는 듯 합니다.
채수원님이 진행하는 작은 모임에 10월 18일 작게 발표에 대한 답례로 받은 책입니다. "엔터프라이즈급 애자일 방법론(Scaling Software Agility)"

1부와 2부는 소프트웨어 공학에 대해서 깔끔하게 군더더기 없이 정리가 되었습니다. 그간 읽었던 소프트웨어 공학 관련 내용들에 대해서 잘 정리할 수 있었습니다. 책에서 인상적인 부분은 3부였습니다. BMC라는 글로벌 회사와 같은 광역 조직에 애자일을 접목시킨 경험을 잘 정리해 놓았습니다.

가장 마음에 남는 것은 개발 조직 외의 다른 영업 조직, 마케팅 조직과의 릴리스 이슈에 대한 접근법입니다. 그리고 저는 한참 남은 지위인 의사결정권 계층인 경영회의의 애자일 적용 방식에 대한 가이드입니다.

개발팀은 회사에서 손발과 같은 위치인 경우가 많습니다. 그 회사의 서비스 전략은 개발팀 외적인 팀에서 만들어지는 경우가 비일비재합니다. 때문에 머리가 나쁘면 손발이 고생한다고 개발팀에서 일어나는 많은 이슈들이 다른 연관부서의 전략적 헛점 때문에 발생하는 경우도 많습니다. 가장 빈번하게 예를 드는 것이 전산화로 업무 혁신을 이루겠다고 하면서 프로젝트를 열었지만 조직 내의 업무 프로세스를 정의하지 않고 멍 때리는 경우가 될 것입니다. 이런 경우 프로젝트는 네버엔딩스토리가 됩니다. 월급 밀리지 않는다고 평생 짤리지 않는다고 좋아할 일은 아닙니다.

개발자도 봐야하지만 소프트웨어 프로젝트 연관된 사람들은 다 읽었으면 좋겠습니다. 특히나 CEO, CIO, CTO, CFO 이런 분들이랑 전략기획, 사업부 같은 전략적으로 고민을 많이 하는 팀들에게 권하고 싶은 책입니다.

손발이 아무리 이뻐봐야 머리가 비면 소용없습니다. 회사의 비즈니스는 조직 전체의 유기적이고 경량으로 빠르게 전달되는 의사결정의 속도에 달려있습니다. 지금 필요한 것은 뭐일까요. 커뮤니케이션 스피드입니다.

저작자표시비영리변경금지
Posted by kenu허광남
TAG agile, communication, scaling, scaling software agility, System, 개발팀, 애자일, 조직, 팀문화
트랙백0 | 댓글10

댓글을 달아 주세요

  1. 용식  댓글주소 수정/삭제 댓글쓰기 2008.11.25 15:20 신고

    네이버 블로그에서 알게된 블로그 지인께서 번역하신 책이네요..
    미국에서 박사과정 밟고 계시던데..
    저한테는 내용이 많이 어렵지 않을까하는 고민이..^^;;

  2. [짱가™]  댓글주소 수정/삭제 댓글쓰기 2008.11.25 17:33 신고

    저도 이 책의 번역자 중에 한분을 알고 있어서.... 참 재미있게 읽어보았습니다. ^^

  3. evilimp  댓글주소 수정/삭제 댓글쓰기 2008.11.25 20:54

    앗...저도-_- 역자분을 아는데....
    용식님이 아시는 분과 동일한 분을....;;;;;;

  4. bliss  댓글주소 수정/삭제 댓글쓰기 2008.11.26 00:31

    스피드레이서 짤방은 뭔가요? 머리크기가 왜케 차이가 나는거지? -0-;;

    여튼 이곳저곳에서 이 책 너무 좋다고 다들 얘기해주셔서
    요즘처럼 지치고 황량하며 상처받은 영혼에 크나큰 위로가 됩니다요. ㅎㅎ
    고생한 보람도 느껴져서 나름 뿌듯하구요.

    땡큐. 케누님.
    그나저나 프로필 사진 쩜 바꾸세요. ^^

    오늘 알려주신 쿨아이리스는 짱이었슴다.. --b
    건스옵빠들을 한눈에~ 아훙.

E-Commerce Dev Day 2007 행사를 마치고

웹 2007. 12. 8. 18:32
사용자 삽입 이미지
먼저 얘기를 꺼낸 것은 올 초여름으로 기억됩니다. 바캠프서울과 난상토론회, 그리고 데브데이나 데브나이트를 참여하면서 외부와의 소통이 얼마나 가치있는지 알았습니다. 팀브랜드를 높이는 데 좋은 방법이구나 생각되었습니다.
이러한 행사를 통해서 얻어지는 긍정적인 효과는 여러가지가 있겠지만, 열린 팀이라는 생각과 꿈을 꾸고 실행해 볼 수 있는 환상을 심어주기에 충분합니다. 사실 회사 생활은 밖으로 보여지는 것 보다 많은 일들이 내부에서 일어나게 됩니다. 이러한 소문이 나게 되면 신규인력 채용 등에서 좋은 영향을 더하게 되죠. 그리고 유명무실이 되지 않기 위해서 내부의 인력에 대한 역량을 강화하려는 자극제가 됩니다.

가을, 팀장님의 본격적인 실행지시가 내려졌고, 예산도 타내고, 장소도 알아보는 등 대략 2~3개월의 준비기간을 거쳤습니다. 내부 강사의 세션 준비도 쉽지는 않았습니다. 높은 팀장님의 수준에 맞춰서 다들 10여 번 정도 수정 발표하면서 발표내용을 다듬어 갔고, 그 수준은 다른 세미나 못지 않는 내용들이 되어갔습니다.

행사 운영팀으로 또 조직되어서 저녁 간식거리로 무엇이 좋을까 고민도 하고, 안내는 어떻게 할 것인가, 뒷풀이 장소의 좌석 배치는 어떻게 할 것인가, 사진은 누가 찍을 것인가, 등 수십여가지의 경우의 수를 다 고려해서 준비했습니다. 정말 고생들 많이 하셨지요.

등록페이지를 직접 만들어서 접수를 받고, 120명이 차기를 기대했었습니다. 다행히 등록 개시 4일만에 넘긴 것으로 기억합니다.

행사 당일 많은 분들이 와 주셨습니다. 아는 분들이 대략 25% 자리를 차지 하신 것 같더군요. 이 분들이 제가 썰렁한 농담을 해도 웃어주신 것으로 생각됩니다. 정말 고마워요. ^^
19시 10분에 정확히 시작해서 21시 15분에 모든 강의가 마쳐졌고, 뒷풀이 장소에서는 11시를 쉽게 넘겼습니다. 초대 강사였던 mepay님은 간만의 서울 행차로 선배 호출에 인사만 하고 헤어졌습니다. 강의시간이 짧아서 워밍업만하시다가 막바지에 속얘기가 나오시려했는데, 강의 하신 분이나 들으시는 분들에게 짧은 시간 때문에 누를 끼친 것 같아 미안했었습니다.

행사 마치고 야후!코리아의 정진호님이 번역서를 제가 선물로 주고 가셨습니다. Flickr Mashup 책인데, 많이 땡깁니다. ㅎㅎ

행사를 잘 마친 듯 해서 다행입니다.

그래서 기분 좋습니다. 자기 자리에서 열심히, 즐겁게 수고했던 우리 팀원들이 자랑스럽습니다. (아부 조금 섞어서) 소팀장님 좋은 기회 만들어 주셔서 감사합니다.

베스트 팀, 우리도 그거 할 수 있습니다.
Posted by kenu허광남
TAG devday, e-commerce, flickr, Mashup, mepay, Programmer, 개발자, 개발팀, 야후!코리아, 정진호, 팀문화, 팀브랜드
트랙백2 | 댓글2

댓글을 달아 주세요

  1. 정진호  댓글주소 수정/삭제 댓글쓰기 2007.12.09 01:45

    짧지만 유익하고 즐거운 시간이었습니다.
    이런 행사를 준비하는 데 얼마나 큰 노력과 희생이 숨어있는지는
    해본 사람만이 알겠죠. :)
    2008년에는 더 멋진 행사로 성장해기를 빌께요.

20대 80 사이에는 연관성이 있습니다.

낙서장 2007. 9. 4. 01:28

파레토의 법칙이라고 하죠. 우월한 20% 그렇지 못한 80%
하지만 20%는 80%가 사라지면 다시 4:16 으로 나뉘어집니다. 세포분열이죠. 거기서 다시 우열이 만들어지죠.

20:80 원칙에서 20과 80 사이에는 부정할 수 없는 연결고리가 있습니다.
프로젝트에서 진보적인 20과 보수적인 80 사이의 연결고리를 잘 이어야 원만한 프로젝트로 이끌 수 있겠지요.
팀을 최고로 이끌기 위해서는 외부에서 인정하는 사회적 가치와 내부에서 동의하는 상향 타협점을 위한 노력이 있어야 합니다.

협업을 장려하는 많은 IT시스템이 있지만, 그것과 아울러 함께 일하는 동료간의 공명이 있어야 하겠지요. 어울림입니다.


그것을 고민하고 삽니다.

Posted by kenu허광남
TAG 20대80법칙, Teamwork, 공명, 소통, 어울림, 팀문화, 팀웍, 파레토법칙
트랙백0 | 댓글0

댓글을 달아 주세요

개발표준이 사용되기 힘든 이유

낙서장 2007. 6. 16. 16:09
어제 모임에서 재미있는 얘기를 들었습니다. 프로젝트의 공통 모듈팀을 없애야 코드들이 깨끗해질 수 있다고 합니다.
개발자 중에 똑똑한 사람들이 주로 들어가는 공통팀입니다. 이 팀의 코드들은 예술적이고 환상적입니다. 아키텍트가 될만하고 아파치 등의 오픈소스 커뮤니티 활동도 열심히 합니다. 신기술은 모두 꿰차고 있고, 정말 훌륭한 개발자들이 모이는 팀이 주로 공통팀입니다.

하지만 프로젝트에서 비즈니스 로직과 프리젠테이션 레이어의 삽질(HTML 태그 미아)을 하고 있는 일반 평범한 개발자들은 이런 좋은 코드들을 잘 모릅니다. 그렇게 똑똑하지 않고, 그렇게 부지런하지 않고, 그렇게 개발에 재미를 붙이고 있지 않은 경우가 많습니다. 그냥 먹고 살기 위해서 프로젝트에 들어와 일하는 중입니다.

여기서 괴리가 발생합니다. 공통으로 짜놓은 것이 있지만 찾기 귀찮습니다. 샘플이라고 있기는 하지만 이렇게 짜나 내가 원하는 방식으로 짜나 그 시간이 그 시간입니다. 납기가 코앞입니다. 자기가 익숙한 대로 코딩을 합니다. 공통을 적용하려 하니 이런 경우는 안 된다고 합니다. 금방 안된다고 합니다. 또 자기가 익숙한 대로 코딩을 합니다.

어제 들은 바로는 구글은 개발방법론이 없다고 합니다. 오히려 개발 방법론이 교복이나 유니폼처럼 속박하는 것이 아닐까. 창의력 말살이라고 할까요. 많은 개발자들이 일할 때 필요한 것은 과연 무엇을까요. 그렇다고 아무런 제약도 없이 풀어놓고 개발하라고 한다면 코드 저장소는 돼지우리처럼 될 것 같네요. 진퇴양난입니다.

사용자 삽입 이미지
단 한 가지 희망이 있다면, 소통입니다. 커뮤니케이션. 문화가 발전하는 곳은 커뮤니케이션의 제약이 없는 곳입니다. 원하는 자원을 가져다 쓸 수 있고, 원하는 요구사항을 정확히 들어서 알 권리가 있고, 원하는 바를 다른 사람에게 이해시킬 자유가 있습니다. 개발팀내에서의 소통은 마지막 희망입니다. 옆 동료가 개발하는 것이 무엇인지 공유하고, 막힌 곳을 혼자 고민하는 것이 아니라 짝 프로그래밍 등을 통해서 공유하면서 풀어가는 문화.

개발팀엔 개발 방법론, 개발 표준이 필요한 것이라기 보다 개발팀 문화가 필요합니다.


Posted by kenu허광남
TAG 개발표준, 팀문화, 프로그래머
트랙백2 | 댓글12

댓글을 달아 주세요

  1. dazzilove  댓글주소 수정/삭제 댓글쓰기 2007.06.17 18:57

    공통관련파일을 몇십개를 만들어놓아도..
    아주 잘 정리해서 하나의 파일로 만들어놓아도..
    전파가 되지 않으면 무용지물이나 마찬가지 이더라구요..
    오빠 말씀처럼 커뮤니케이션이 중요하고..
    이러한 문화가 형성될 필요가 있다고 생각합니다.
    만들어 놓은 문서 보고 하는것도 제대로 못하냐라는 어정쩡한 훈계보다는
    새로운 이슈사항이 나타날 때마다 인식할 수 있도록
    제대로 전파해주는것이 더 중요하다고...
    다찌는 매번 이야기를 하지만..
    아직 5년밖에 안된 햇병아리인지라.. 잘 안통하더군요. ^^;;

  2. 알 수 없는 사용자  댓글주소 수정/삭제 댓글쓰기 2007.06.18 11:18

    공감하는 글이라 트랙백 하나 날렸습니다. ^^ 좋은 하루 보내세요~

  3. 알 수 없는 사용자  댓글주소 수정/삭제 댓글쓰기 2007.06.18 15:48

    역시 좋은글 -_-)! 언제나 많은 생각을 하게 해주셔서 감사해요 형 ㅋ

  4. kenny  댓글주소 수정/삭제 댓글쓰기 2007.06.18 18:31

    "오히려 개발 방법론이 교복이나 유니폼처럼 속박하는 것이 아닐까."

    사실, 예전에 잠시 놀러갔을때 본 거지만.
    사촌동생이 다녔던 학교(음... 미국 교포 2.5세이니까, 당연히 미국학교에 다녔죠.)에서도, 교복 혹은 유니폼은 있더군요.
    다만, 우리랑 다른건, 유니폼이라는게, 특정 색상을 지정하고, 그에 해당하는 거라면 기성복을 입건 뭘 입견 상관 안하더군요.

    개발방법론이라는게 말 그대로 유니폼/교복과 같은게 아닐까 싶네요. 여기까지는 Rule. 나머지는 편한대로. 솔직히 공통화된 어떤 코드를 위해서 필요하지 않은 곳 까지 강제하고 있는 것도 사실이니까요.

    • kenu허광남  댓글주소 수정/삭제 2007.06.19 06:40 신고

      네 말 듣고 쓴 포스팅인데, 생각할 수 있게 해줘서 고맙네.
      술먹으면서 하루의 일과를 반성하면 좋은 개발팀이 되지 않을까나 생각해본다. ^^ 땡큐

  5. codikim  댓글주소 수정/삭제 댓글쓰기 2007.06.22 17:29

    저는 말그대로 먹기살기위해 프로그램 하고 있는 사람입니다.^^
    프로젝트에서 반드시 필요한 팀인데...
    전파의 중요성....
    표준이 늦게 나와 삽질을 하는 경우도 있긴 하지만 드문예라고 생각하구요...

    암튼 그놈의 납기가 항상문제가 되는것 같습니다.

    • kenu허광남  댓글주소 수정/삭제 2007.06.23 06:09 신고

      time to market 과 납기는 불가분의 관계인데, 지난 webappscon에서 공감가는 얘기가 나왔습니다.
      time to market 에 맞춰서 오픈한 프로젝트 치고 성공한 것 보기 힘들었다.

  6. Max  댓글주소 수정/삭제 댓글쓰기 2007.06.22 17:48

    제일 쉽게 다가설수 있는것이 커뮤니케이션입니다.
    하지만 제일 어려운것도 커뮤니케이션 인것 같아요.

    특정기술에 대해 종속적인 기술을 사용한다면 배우면되지만,
    특정문서를 읽어야 개발을 진행할수 있다면 하겠지만,
    커뮤니케이션이 원만하지 않는 집단과 일하는것은... 불행입니다.

    커뮤니케이션의 중요성을 인식했다면, 그것을 잘하기 위해서 노력도 해야 하겠죠?
    그노력도 않한다면 밥먹기가 힘들어 질지도....
    그런데 그것(노력하는것)도 만만치 않은것 같아요.
    고로 세상엔 쉬운게 없는것 같아요.

    개발팀문화를 만드는것도 쉬운일이 아니고, 커뮤니케이션 잘하는것도 쉬운일이 아니니
    결국 '노력하는 사람이 되어야 한다'라고 받아들여집니다. ^^

    노력하는것 조차 하기 힘들다면???

아~, 우리 팀을 사랑하나 보다.

낙서장 2007. 4. 9. 01:46

증거

1. 가장 오래 다니는 회사임. 하루하루가 신기록 2004년12월 이후 현재까지 계속

2. 내가 GS이숍 EC정보팀을 공공연하게 드러낸다.

3. 회사에서 OJT 교육할 때마다 "잘 오셨습니다." 라고 거리낌 없이 얘기한다.

4. 팀 내의 기술력에 대한 한 없는 신뢰가 있다. DB는 누구에게, Flash는 누구에게, flex는 누구에게, 업무A는 누구에게, 업무B는 누구에게, eclipse는 나에게 ㅎㅎ

5. 현업과 말이 통한다고 착각(?)하고 있다.

6. GS이숍과 GS이스토어 분위기는 다르지만 둘 다 좋다.

7. 어제도 ant 버전 1.7로 올리고 전체 메일 날렸다.

8. 팀 블로그 보고 입가에 미소가 번진다.

Posted by kenu허광남
TAG ec정보팀, GSeshop, 팀문화
트랙백0 | 댓글2

댓글을 달아 주세요

  1. bluesVM  댓글주소 수정/삭제 댓글쓰기 2007.04.09 02:39

    팀 분위기가 아주 좋은가보네요!
    블로그도 있고~

  2. 알 수 없는 사용자  댓글주소 수정/삭제 댓글쓰기 2007.04.26 12:26

    저도 팀블로그 보았는데 참 좋아 보이던데요^^
    좋은 사람과 함께 일한다는건 정말 행복한 것 같습니다.