블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total128,101
Today109
Yesterday102
오늘 가산에 있는 LG전자 MC연구소에서 Agile Gathering이라는 제목으로 세미나가 있었습니다. 
여차저차 허락을 받고 점심도 안먹고 가산으로 넘어갔습니다. 

리더쉽은 자신이 선택하는 것

첫번째 시간은 애자일 컨설팅의 김창준 대표님이 애자일 적용(혹은 반대)를 위한 조직에서의 리더쉽에 대한 내용으로 워크샾을 진행하셨습니다. 워크샾은 시뮬레이션 형태로 진행되었습니다. 참석자들중 몇분은 관찰자의 역할을 맡고 나머지는 한 회사의 구성원(사장,이사,팀장,사원)이 되어 시장(market)의 요구사항에 맞는 시제품을 개발하는 것이었습니다. 처음에는 어색했지만 나중에는 완전히 몰입해서 정말 제품을 만들어야 한다는 중압감이 생겼습니다+_+! 
약 1시간 넘게 시뮬레이션을 진행한뒤에 피쉬보울 방법으로 회고를 진행하였습니다. 그중에서 가장 인상에 남았던 것은 김대표님이 말씀해주신 매니저와 리더의 다른점, 리더쉽의 본질, 리더쉽의 4가지 유형이었습니다.
매니저는 조직에서 정할 수 있지만 리더는 정해줄 수 없다. 리더는 지휘 여하를 막론(경영진에서 신입사원에 이르기까지)하고 누구나 될 수 있다. 단지 우리는 리더가 되는 것(혹은 리더쉽을 발휘하는 것)을 선택하는 것이다. 단지 안할뿐..
리더쉽은 모든 사람이 창의적으로 문제해결에 기여할 수 있게 환경을 개선하는 것이다. 이에는 4개지 유형이 있다.
motivation leadership, organization leadership, innovation-idea leadership, jig leadership...
애자일에 관심있다고 하는 사람들이 모여서 회사 제품 개발 시뮬레이션을 해도 잘 안되기는 마찬가지였습니다.
중요한건 자신이 현재 상황에서 리더쉽을 발휘할 것인지 아닌지를 선택하는 것입니다.
(다들 가만히 있는데 먼저 나서서 행동을 취하는 것도 리더쉽 입니다. (jig leadership))

짝프로그래밍, 잘하면 고효율~ 못하면 가문의 역적

두번째 시간은 LG CNS의 채수원 과장님이 짝프로그래밍에 대해서 발표해주셨습니다. driver-navigator 라는 패턴을 이용하여 짝프로그래밍 도입하는 것에 대해서 말씀해 주셨습니다. 물론 짝프로그래밍의 장단점, 사례도 말씀해 주셨습니다.
개인적으로 짝프로그래밍을 좋아하지만 사용가능한 분야 혹은 짝이 한정되어있다고 생각합니다. 
정말 필요한 경우에, 고효율이 예상되는 경우에만 사용하는 것이 바람직하다고 생각합니다.

스크럼 vs 칸반

세번째 시간은 LG전자의 MC연구소에 계시는 분이(이름이 기억..안..나..요;;..ㅠㅠ) 스크럼과 칸반에 대해서 아주 이해하기 쉽게 설명해 주셨습니다. 칸반은 아주 심플하게 다음의 3가지를 만족하면 됩니다.
  • Visual Card : 비쥬얼은 필수!
  • Limit Work-In-Progress : 한 스텝에서 동시에 진행될 수 있는 백로그를 제한
  • Measure Lead-time : 지속적으로 리드타임을 측정하여 최소가 될수 있도록 함
특히 칸반은 수시로 인터럽트(QA, 유지보수등)가 발생하는 개발팀에서 유용하게 사용되어 어질수 있다고 생각했습니다. 
즉, 스크럼과 칸반을 개발팀의 업무 특성에 따라 적절히 조합해서 사용한다면 좋을 것 같습니다.

회고

회고에 참석하지 못했습니다.ㅠㅠ 반성중.. 
김창준님이 진행하신 시뮬레이션에 대해서 좀더 자세한 설명이 있었으면 했습니다. (왜 손을 잡는지, 감옥의 역할은 무엇인지 등..)
색다른 경험이었고 즐거웠습니다. 근데 뭘 했다고 이렇게 졸립죠...ㅠㅠ;;
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.07.08 06:46 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    감옥은 게임내 규칙을 위반해서 였던것 같습니다. 게임중 서기외에는 쓰면 안되는데 썼기 때문에..xper에서 했던 게임 기준입니다.

    • 2010.07.08 09:07 신고 윤청하  댓글주소  수정/삭제

      예 맞습니다^^ 이번에는 링크(손잡기)가 끊어진 상태에서 말을 했을 경우에 감옥에 갔습니다.
      궁금했던것은 이러한 룰이 있는 이유가 궁금했습니다~^^ 감사합니다~

  2. 2010.07.09 13:02 신고 한주영  댓글주소  수정/삭제  댓글쓰기

    안녕하세요, Agile Gathering 에 참석하셨었네요.(wiki링크보고 따라왔습니다) 저는 아내 출산 때문에 참석하지 못해서 아쉬워요 ㅠ.ㅠ 블로그를 살펴보니 Agile에 관심이 많으신 것 같습니다. 앞으로는 좀더 작은 규모의 모임을 더 자주 가지는 쪽으로 진행했으면 하는데 앞으로 자주 뵐수 있으면 좋겠습니다 :)

    • 2010.07.12 13:09 신고 윤청하  댓글주소  수정/삭제

      반갑습니다^^ 이제 겨우 애자일에 대해 느낌을 갖게 되었습니다~
      아직 신규사원이라 매번은 힘들겠지만 항상 관심 갖도록 하겠습니다~^^

cooperation vs. collaboration

오늘 회사에서 신규 입사자에 대한 연구소장님 간담회가 있었습니다. 신규 입사자들을 모아놓고 1시간 30분 가량 강연을 하셨습니다.
강연중 cooperation과 collaboration의 구분을 명확히 하셨고 우리는 collaboration을 잘 해야 한다고 강조하셨습니다.
사실 cooperation과 collaboration은 사전적인 의미는 대충 비슷합니다.
피자 vs 파전

저는 cooperation과 collaboration을 피자와 파전에 비유해볼까 합니다.
cooperation은 피자와 비슷합니다. 큰 원형 조각을 미리 정확하게 조각내어 놓습니다. 크기를 동일하게 하려고 해보지만 크기가 제각각입니다. 그리고 보통 시키기 전에 먹을 인원 및 개인의 취향을 고려하여 미리 모두 주문합니다. 그리고 각자 할당된 조각 만큼을 먹습니다
collaboration은 파전과 비슷합니다. 일단 시켜봅니다. 그리고 각자 알아서 먹고 싶은 만큼 조각내서 먹습니다. 젓가락으로 잘 안떼어질때는 서로 도와주기도 합니다. 먹다가 맛있으면 더 시켜서 먹습니다.
팀에서 공동작업을 할때 어떻게 하십니까? 
일만 나눠놓고 서로 독립적으로 작업하십니까? 전체 작업을 시시각각 때에 맞춰 공동작업 하십니까?
cooperation을 하십니까? 아니면 collaboration을 하십니까?
전 경험이 짧지만 제가 경험했던 리더 분들은 대부분 cooperation을 주로 사용하셨습니다. 관리하기 편하기 때문이죠. 
그리고 동료분들도 독립적인 작업을 좋아하셨습니다. 일하기 편하기 때문이죠.
하지만 고객을 만족시키는 소프트웨어 개발을 위해서는 collaboration을 통한 짧은 주기의 피드백은 반드시 필요합니다.

짝 프로그래밍과 협업

XP에서 제안하는 베스트 프랙티스 중에 하나인 짝 프로그래밍은 cooperation과 collaboration의 밸런스를 맞춰주는것 같습니다.
십여명의 팀원이 모두 collaboration을 한다면 결정 시간 지연, 배가 산으로 가는 현상 등등의 부작용이 있을수 있습니다.
cooperation을 하되 그 단위를 짝(pair, 2명)으로 함으로써 collaboration이 가질 수 있는 장점을 높일 수 있습니다.
2명이서 진행하는 collaboration은 오버헤드가 적고 신속한 피드백으로 좋은 품질의 코드를 유지할 수 있습니다.
그래서 저는 짝 프로그래밍을 강추합니다.^^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.03.14 19:21 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    좋은 분위기에서는 collaboration이 좋겠지만 나쁜 상황에서는 cooperation이 나을수도 있을거 같습니다. ^^

  2. 2010.03.16 11:23 신고 YUZI  댓글주소  수정/삭제  댓글쓰기

    청하씨. 옮겨가서 즐거워 보이네요.
    좋아좋아. 직장 적응 끝나면 술이나 한잔 합시다.

  3. 2010.03.16 19:31 신고 moova  댓글주소  수정/삭제  댓글쓰기

    재미있는 비유네요. 역시 술 좋아하는 분들은 창의력이 있단 말입니다.~ㅎㅎ.
    실용주의이야기타고 들어왔습니다. 종종 놀러올께요~^^

  4. 2010.03.18 13:45  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  5. 2010.03.18 14:08 신고 PatternLoader  댓글주소  수정/삭제  댓글쓰기

    아주 재미난 비유네요..
    파전 괜찮은 아이디어 입니다.
    서로 한팀이라는 생각이 강하게 있어야 가능한거죠!!
    그런 팀을 만들기 위해서는 정말 조직을 잘 관리하는 위 사람의 의지가 중요하다고 생각합니다.

    그리고 분배도 기분 나쁘지 않게 적절히 균형을 잡는것도 중요하구요. :)

    • 2010.03.18 18:54 신고 윤청하  댓글주소  수정/삭제

      저도 한 사람의 슈퍼맨보다 팀웍을 선호합니다^^ 팀웍을 위해서는 리더의 역할 가장 중요하구요.
      예전에 같이 일했던 팀장님은 분배를 할때 개발자의 상황이나 기존 잔업량 등등을 고려하지 않고 막 던지셨었죠.. (지금도 그렇게 하고 계신다고ㅋㅋㅋ)
      그때 정말 힘들었습니다.ㅠㅠ

  6. 2010.07.30 17:29 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    재밌는글 잘 읽었습니다^^;
    제품많고 인력부족한 중소기업에서 짝프로그래밍을 비현실적으로 보더군요.
    저도 짝프로그래밍 해보고 싶지만,, 대부분의 시간을 리뷰도 없이 혼자 코딩하다보니 고민이 많네요 ;;

    • 2010.08.01 22:30 신고 윤청하  댓글주소  수정/삭제

      짝프로그래밍은 여유있을때 해도 비효율적인 경우가 많습니다.
      정말 짝을 잘 지어서 계획적으로 진행해야 합니다.
      단, 효율적으로 돌아가기 시작하면 생산성및 품질은 매우 좋아지는 것 같습니다.^^

저는 스크럼, 테스트 주도 개발, 짝프로그래밍, XP의 원칙과 가치 등을 처음 접했을 때 큰 영감을 받았던 기억이 있습니다.
이런 것을 팀에 도입한다면 한단계 발전하는 팀이 될 수 있을 거라는 확신이 들었습니다.
고민했던 생각들을 실천하고 주변사람을 선동하는데 익숙한 저는 바로 실행에 옮겼습니다.
우리는 XXX 문제들이 있기 때문에 YYY를 도입해서 해결해야 합니다.
그리고 우리는 YYY를 도입했습니다.

새로운 것을 도입하는 것이 끝은 아니다.
스크럼은 정말 쉬워보였습니다. 그래서 우리는 스크럼을 가장 먼저 도입하기로 하였습니다.
약 1년간의 스크럼을 해보면서 느낀 것은 새로운 프로세스와 방법을 도입하는 것은 단순한 액션에 불과하다는 것이었습니다.
새로운 것이 정착하기 위해서 우리는 기존의 것을 포기해야 했습니다. 
적게는 수년에서 많게는 십수년의 경력동안 유지했던 자신만의 틀을 깨야 했습니다.

  • 매일매일 자신의 일정과 업무 진행 상황을 모든 팀원에게 솔직하게 공개해야 했습니다.
  • 팀장님은 외부와의 업무 상황 및 요구사항의 출처 및 발생 이유에 대해서 모두 공유해야 했습니다.
  • 특정 개발자만 처리할 수 있는 소스코드가 없어져야 했습니다.
  • 우리 팀의 상황을 타 팀(영업, 마케팅, QA 등)에게 여과 없이 공개해야 했습니다.
이 외에도 여러가지가 있습니다. 하나하나의 틀을 팀원 각자가 깨나가야 했습니다. 정말 어려웠습니다.

틀을 깬다는 것은 안해봤던 일을 시도해보고 새로운 틀을 만드는 것이다.
기존의 틀이 개발 생산성에 문제가 된다면 과감하게 깰수 있어야 합니다. 단, 단순한 현상이 아닌 핵심이 되는 원인을 깨야 합니다.
그리고 새로운 틀을 만들 수 있어야 합니다. 그 틀이 멋진 선배들이 만들어 놓은 것이라면 자신에게 맞게 고칠 줄도 알아야 합니다.
새로운 기술, 새로운 방법, 새로운 환경이 매일 차고 넘치기 때문에 소프트웨어 엔지니어라면 항상 틀을 깰수 있어야 합니다.
이미 아는 기술, 써봐던 방법, 경험했던 환경이 아니라고 해서 할 수 없다고 말씀하시는 분은 진정한 소프트웨어 엔지니어가 되기 힘들것입니다.
저는 그 틀을 깨는 경험들을 공유하고 싶습니다.^^ 같이 깨보실래요?ㅋㅋ
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.02.22 10:50 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    그래서 기업에서 스크럼을 도입하면 많은 관리자들이 회사를 나간다고 합니다. 대략 30%정도. :-)

  2. 2010.02.27 10:19 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    고인물은 썩는다.라는 말이 생각나네....
    물이 흘러가는 방향이야 자신의 생각대로 가는거라지만...
    물이 고여 썩어버린다면.....쩝..


토요일 오후 2시, 명동 LG CNS 본사 2층 대회의실에서 xper 10월 정기모임이 진행되었다.
나는 청하 쥬니어 탄생 준비로 미뤄왔던 xper 정기모임에 처음으로 참가하였다.

LG CNS 건물 1층에서 어떻게 들어가야 할지 방황하던 다른 두분과 함께 모임 장소에 도착했을때에는 10명 정도 되는 분들이 자리에 계셨으며, 발표를 위한 셋팅 준비를 하고 계셨다.
일단 조촐하게 그룹을 만들어서 자기소개를 진행하고, 이런 저런 얘기를 나누었다.
처음 참석하는 모임이고 오프라인으로 아는 분들이 한명도 없어서 내심 긴장했는데, 편안한 분위기 속에서 진행되었고, 다른 분들도 딱히 서로 잘 아는 것 같지 않아서 좋았다^^;;;

첫번째 발표, "존재하기와 발전하기 - 변신철"
우리의 일상은 엉망진창이다.
TDD는 명료하며, 현재 엉망진창이라는 것을 확실히 알려준다.
짝프로그래밍은 같이 바라보는 것이다. "너 봤니? 나도 봤어" 같이 하면서 성공하게 되면 하이파이브를 하게 되고 매우 신나게 된다.
비난 받지 않는 회고를 진행하였다. 팀원들은 비난받지 않을 권리와 경청해야할 의무를 가진다.
비난 받지 않기 때문에 개인적인 일까지 회고한다. "웹서핑 시간이 많아졌어요. 이유는 핸드폰을 사야해서..ㅋ"
애자일은 우리를 우리(짐승을 가두어 기르는 곳)에 가둔다. 화를 낼수 없다.
혁명은 실천법(practice)나 개발 프로세스로 쉽게 얻을 수 있는 것이 아니다. 노력하고 힘들어져야 변화할 수 있다.
소통하기 어려운 팀원이 있었다. 드디어 소통하게 되었다. 그것은 내가 힘들어지고 바뀌게 되어서 된일이었다.
애자일이 실천법으로만 설명되지 않았으면 좋겠다.
변할만 할때 변화한다. 은탄환(silver bullet)은 없다.
애자일은 사람과 관련된 일이다. 켄트백왈 "프로그래밍은 사람이 하고 사람에 의해 사람을 위한 것이다.(맞나?^^)"
TDD가 가장 쉬었다는 변신철님, TDD를 실무에 적용하기로 마음먹고 실천한지 몇개월이 지났지만, 아직도 TDD를 자주 빼먹는 나로써는 매우 공감할 수 없는 표현이었다.ㅠㅠ
변신철님은 TDD를 통해 프로젝트를 성공적으로 이끄셨다고 한다. 개발 플래폼에서 완료된 프로그램을 상용 플래폼으로 이식할 때에 작업이 한번에 이루어졌으며, 그 후 3년간 개정 없이 상용 서비스 중이라고 한다. 일어나서 박수라고 치고 싶었다.ㅠㅠ

질문/답변 시간에 나왔던 내용들..
애자일 팀을 구분할 수 있는 특징은 무엇인가요?
-  야근을 안한다.(진심으로 부럽다ㅠㅠ) 팀장이 소리치지 않는다. 벽에 무언가 많이 붙어있다.
요구사항, 품질, 팀의 밸런스는 어떻게 조절하나요?
- 품질이 가장 높은 우선순위를 가진다. 잦은 릴리즈 주기로 높은 품질을 제공했더니 고객이 스스로 요구사항을 줄였다.
- 팀장이 고객 옆에서 계속 질문하며 일한다. (질문은 정확히 기억나지 않음)

휴식시간에 있었던 김창준님의 부연설명 (어떤 내용에 대한 부연설명이었는지 까먹었음ㅠㅠ)
위험을 어떻게든 줄여서 애자일을 조직에 적용하려 한다면, 성공하기 어렵다. 책임을 지고(위험을 감수하고) 애자일을 적용해야 성공할 수 있다. (노출, 다치기 쉬운, vulnerable)
어떻게든 쉽게, 위험 없이 애자일을 적용하려고 했던 내 지난날을 반성했다ㅠㅠ

두번째 발표, "캐빈문화 소개, 즐거운 일터 만들기 - 김종욱"
캐빈문화란, 다음 뷰 서비스를 개발하기 위해 기획자, 개발자, 디자이너 등이 한군데 모여 팀을 이룬 것이다. (장소가 옥상이라 캐빈이라 지은듯.. 창문 밖으로 한라산이 보인답니다ㅠㅠ부러우면 지는거다..)
우리는 포스트잇으로 테스크 관리를 한다.
각 테스크는 추정시간이 따로 없으며, 4시간단위로 쪼갠다. (갯수로 파악한다 - 한눈에 파악될듯..)
현재 프로젝트 상황은 포스트잇을 백로그/ToDo/Doing/Done/협의중 으로 분류하여 화이트보드에 붙여서 표현한다.
백로그로 파악되지 않는 일상 업무를 양지로 끌어올리기 위해 노력했다.
주간회고를 통해 구성원들이 더 많은 고민을 하게 만들었으며, 더 많이 공개하도록 하였다. (도움, 칭찬, 격려, 비폭력대화, 성향별대화)
도반(불교, 함께 도를 닦는 벗)을 얻는 것이 중요하다.
애자일 문화를 다른 팀까지 전파시키는데에는 조직적인 한계가 있다. (새로운 회사를 차리는게 빠를수 있다.)
직군은 할일을 제한시키며 많은 시도를 하기 힘들게 한다. 직군 파괴를 해야한다.
여유(다음의 ctime)를 주어서 더 많은 시도를 할수 있도록 해야 한다.
업무를 포스트잇과 화이트 보드로 하는 것은 현재 우리팀이 하고 있는것과 다르지 않았다. (기분 좋았다^^)
직군 파괴는 정말 괜찮은 아이디어 같았다. 현재 우리 회사도 직군을 더 세분화 시키려고만 하고 있다.ㅠㅠ

개인 회고
  • 그동안 실패했던 TDD를 다시 제대로 적용해야겠다는 다짐을 하게 되었다.
  • 애자일 문화가 전파되기 위해서는 더 많은 도반이 필요함을 느꼈다.
  • 기존의 세분화된 조직에서 애자일 문화를 전파시키는데는 한계가 있다는 것은 아쉽다.
    정말 방법은 없는 것일까?
    내가 애자일 팀으로 이직을 하던지, 새로 회사를 차리던지 하는게 유일한 방법일까?
  • 애자일과 야근과의 관계를 명확히 알수 있어서 좋았다.^^
  • 변화하고 싶다면, xper 정기 모임을 추천한다! (xper 메일링 리스트)

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.24 23:47 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    위험을 어떻게든 줄여서 애자일을 조직에 적용하려 한다면, 성공하기 어렵다....라..
    뭔가 느껴지는 군요....ㅎ

    • 2009.10.25 17:24 신고 윤청하  댓글주소  수정/삭제

      본문에서 빼먹었는데, 캔트백이 한 말이랍니다. (캔트백 워크샾에서)
      중요한건 책임(responsibility)을 조직의 위에서 아래로 끌어 내리는 것이랍니다.
      변신철님의 팀이 야근을 안할수 있던 것도 그만큼의 책임을 지고 있다는 뜻이겠지요. 팀장부터 팀원까지 골고루..

  2. 2009.10.26 09:16 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    [추가] 변신철님 질문답변~
    TDD 진행시 테스트 케이스에 대한 검증은 어떻게 이루어 졌나요? (테스트 케이스 버그)
    - 팀원 마다 다른 테스크 케이스 순서를 갖도록 하는(테스트 케이스 독립성 테스트) 스크립트를 만들어 사용하였습니다.

  3. 2009.10.27 08:22 신고 박형근  댓글주소  수정/삭제  댓글쓰기

    모임에 못가서 내용이 궁금했었는데 후기 올려주셔서 감사합니다.
    처음 새로운것을 도입하는 사람은 참 어려운것이 많지요.
    이렇게 같은 고민을 하는 사람이 있다는 것만 알아도 든든해 지는것 같습니다.
    애자일 도입 꼭 성공하시고, 좋은 정보있으면 알려주세요~

  4. 2009.10.27 10:24 신고 정창용  댓글주소  수정/삭제  댓글쓰기

    후기 잘 읽었습니다.

  5. 2009.10.28 09:28 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    제 회고중에 김종욱 님께서 말씀하신 내용을 잘못 이해한게 있네요;;
    "기존의 세분화된 조직에서 애자일 문화를 전파시키는데는 한계가 있다는 것"
    에공..애자일 문화 전파의 한계가 아니라 조직의 문제를 애자일로 해결하는데 한계를 느꼈다는게 맞네요^^;;;

  6. 2009.11.05 10:14 신고 이평섭  댓글주소  수정/삭제  댓글쓰기

    덧글고맙습니다. 가끔씩 글을 올리곤 자주 살펴보지 않아서, 늦게 답글을 보았네요. ^^;
    천천히 느리게 배운다는 것이 생각나는 요즈음입니다.
    태어난 아기가 뒤집기를 하고, 배밀기를 하고, 기고, 잡고 서고, 아장 아장 걷고 모두 천천히 느리게 하는데요.
    아기에게 배워야 겠습니다.
    좋은 하루 되시구요.

티스토리 툴바