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

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total128,101
Today109
Yesterday102

James Grenning의 TDD and Refactoring Workshop 참가

 

몇주전 사내 역량강화센터 분들의 도움으로 매우 귀한 교육에 참가하였습니다.

TDD에 대해서는 오래전 부터 관심을 갖고 실무에 적용해보려 하였지만, 지속적으로 유지하지는 못했었습니다.ㅠㅠ

이번에 하던 업무가 정리되던 타이밍에 맞춰서 좋은 교육이 소개 되어 바로 참석하였는데, 이것은 실로 엄청난 경험이었습니다!!

사실 제가 영어 실력이 많이 딸려서, 한마디 한마디 모두 새기진 못했지만, 우리에게는 정말 잘 통하는 언어가 있었습니다. 그가 준비한 코드들과 시연하면서 보여준 코딩 모습들은 모두 저에게 큰 인사이트를 보여주었습니다.

 

 

 

그가 발표한 내용 중 가장 흥미로운 그림은 위의 그림과 같이 무수히 많은 공으로 저글링을 하는 것이었습니다.

현재 우리는 많은 공으로 저글링 하는 것처럼 많은 문제를 모두 다 노출시킨뒤에 해결하고 있다는 것입니다.

저도 그렇게 하고 있었겠지만, 생각만해도 끔찍합니다.ㅠㅠ

TDD는 한번에 하나의 문제만 해결하는데 집중하도록 하고 있습니다.

 

Uncle Bob's Three Rules of TDD

1. Write no production code, except to pass a failing test

2. Write only enough of a test to demonstrate a failure

3. Write only enough production code to pass a test

 

궁금 했던 것들에 대한 해답을 찾다.


제가 궁금했던 부분은 세가지 정도 였습니다.

첫번째는 테스트 코드에 대한 관리 이슈입니다. 프로젝트가 성장하다보면 테스트 코드의 비중도 높아지게 됩니다.

프로덕트 코드가 리팩토링 되면 테스트 코드에도 영향을 줄 수 있습니다. 테스트 코드의 원저작자가 없다면 문제가 될 수도 있습니다. 특히나 요즘처럼 자신의 코드가 아니면 Owner-ship을 전혀 가지지 않는 개발 문화에서는 더욱 문제가 됩니다.

James는 항상 테스트 코드를 깨끗하게 유지하라고 하였습니다. 리팩토링의 대상이 프로덕트 코드만이 아닌 테스트 코드도 포함된다고 하였습니다. 그리고 중요한것 중에 하나는 테스트 코드를 너무 많이 만들면 안되는 것입니다.

Unit Test 30개 + Integration Test 10개로 되는 것을 Integration Test로만 Cover하려다 보면 테스트 코드는 수백개가 넘어도 모자를 것입니다. TDD를 하다보면 자연 스럽게 Unit Test와 Integration Test의 조합을 구성하게 되며, 따라서 적은 테스트로도 높은 Test Coverage를 만들어 낼수 있습니다.


두번째는 TDD를 소개하다보면 "오버헤드가 크다, 작업이 너무 느려진다"라는 질문을 많이 받는데, 그때마다 정확히 설득하지 못했었습니다. 이는 기존의 개발 방법 대비 작업이 느려지게 느끼는 것일 뿐입니다 라고 James는 말하였습니다. Debugging이란 작업은 매우 Unpredictable 한데 비해 개발자는 Debugging 이전에 개발 완료라고 느끼는 경우가 많다는 것이죠. 아래 그림 처럼 Debugging 이전까지는 기존 개발 방법이 빠르게 느껴지지만, 코드가 버그 없이 완성되는 것은 TDD가 빠릅니다.



 

세번째는 TDD Step의 크기가 궁금했습니다. 책에서처럼 너무 작은 단위로 하다보면 살짝 멍청해보였습니다. TDD의 적용 방법은 어떤 작업이냐 혹은 작업자가 그 작업에 대한 경험이 얼마나 있는가에 따라서 달라질 수 있습니다. TDD에서 말하는 Small Step은 어떤 상황에서도 TDD를 적용할 수 있게 하는 기본적인 스킬 입니다. 처음에는 Small Step으로 계속 연습하는 것이 좋을 것 같습니다. 익숙해 진다면 Step의 크기를 자유자재로 조절할 수 있다고 합니다.


결국 제가 깨달은것은, "나는 TDD에 대해서 진정 아는 것이 없었구나!" 라는 것이었습니다.

매우 슬펐지만 반대로 무척 기뻤습니다.^^


James의 Workshop을 따라해보면 나도 우리 동료과 TDD를 할수 있지 않을까?


James는 Dojo 시스템을 이용하여 본인이 준비한 코드들과 인스트럭션으로 Group Activity를 진행하도록 하였습니다.

또한 Group Activity는 랜덤하게 2인 단위로 Pair Programming을 유도하였습니다.

Workshop참가자들이 대부분 애자일 개발에 이미 익숙한 사람이 많았고 적극적인 사람들이었기 때문 일수도 있지만, 참가자들 대부분이 매우 몰입해서 Workshop에 임하였다는 것이 매우 흥미로웠습니다.


그래서 따라해보기로 했습니다. 무작정 팀내 공지를 하였고 (약 50여명) 무작정 대회의실을 잡고, 무작정 날짜를 잡았습니다. 회비도 유례없이 미리 선불로 받았습니다. (2만원 - 뒷풀이 비용)

팀내 워크샵 당일까지 약 16명이 등록을 하였고, 모두 참석하여 약 2시간 동안 진행하였습니다. 참가자들의 직위는 책임연구원부터 연구원까지 다양하였습니다. 

 

James가 했던 내용, Group Activity를 그대로 진행하였습니다.

제가 기억 나는데로~ 물론 애드립이 난무하긴 했지만, 초반에 시작할때 성공적인 S/W에 대해서 공유도 하고, 본인이 개발시에 좋아하는 것과 싫어하는 것도 공유하였습니다.

대부분 디버깅과 테스트를 싫어하시더라구요...ㅎㅎㅎ 디버깅은 우리의 적이죠..

제가 30분 정도 TDD로 Circular Queue를 만드는 과정을 데모로 보여드리고, 랜덤하게 2명씩 짝 지어서 30분간 Pair Programming으로 TDD로 Circular Queue를 끝까지 만들어 보도록 하였습니다.

Small Step과 한번에 하나의 테스트 케이스를 계속 강조했습니다.

아래 사진에 맨 앞에 두분이 책임 말년인데 정말 열심히하시더라구요~ 워크샵 끝나고도 자발적으로 며칠 더 진행하셨습니다. Thread-Safe 까지 검증하는 테스트 케이스를 만드셨더라구요..ㅎㅎ 대박..

 

 


어라 이거 효과가 있네요?^^ (회고)

 

매우 간소하게 James 따라하기 워크샵을 진행하고 나서, 간단하게 회고를 진행하였습니다.

질문은 두가지 였습니다.

TDD에 대한 긍정적인 느낌

TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정


 

먼저 TDD에 대한 긍정적인 느낌에 대해서는 아래와 같이 답해주셨습니다. (작성한 그대로 옮겼습니다.)

생각보다 재미있고 긍정적인 회고 내용이 많았습니다. 제가 말로만 설득할때와는 전혀 다른 반응입니다!

특히 Pair Programming에 대한 긍정적인 느낌은 매우 인상적이었습니다^^

 

- 새로운 개발 방법을 알게 되어서 좋았음. 비록 처음 익히기는 어렵겠지만 익숙해지만 Error를 사전에 예방할 수 있어서 개발시에 많은 도움이 될 것 같음

- Pair Programming 해보니 상대방이 나와 다르게 생각하는 부분을 알게된다. 처음부터 복잡하게 이것저것 다 생각하지 않고, 하나하나 순서대로 해서 좋다.

- 구멍이 없는 프로그램을 만들 수 있을 것 같다. 프로그래밍 개발시에 다른 함수를 추가하면서 기존 함수를 - 고칠 때 기존 함수에 대한 Test가 누적되어서 테스트가 보장됨.

- 쉽게 따라 할 수 있어서 좋았습니다.

- 잠들어가는 나의 뇌를 깨울수 있는 흥미있는 Programming 접근방법

- 반복적인 테스트 Set을 구축/확장하기 용이하다

- Code를 꼼꼼히 생각하며 짤수 있다.

- Test Case 자체가 Application이기 때문에 Caller 입장에서 구현할 수 있음.

- 재밌다(신기) ㅋㅋ 한번 업무에 활용해보고 싶다.

- 코딩이랑 테스트랑 같이하니 시간 절약은 될듯. 그러나 테스트가 명확해야 함.

- 잘하면 좋은 방법론이 될 듯하다.

- 계속해서 코딩단계부터 예외사항을 고려하게 된다.

 

두번째는 TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정입니다.

역시 업무 속도가 느려질것 같다는 걱정이 많습니다. 위에서 설명한 것처럼 실제로는 느리지 않다는게 핵심이죠

레거시 코드에 대해서 걱정하시는 분도 있습니다. 레거시 코드는 저도 무지 걱정됩니다.^^; 따로 다루어야 할 내용입니다.

 

- 내가 만드는 Test case에 hole이 분명! 있을거다. TDD하고도 이모양이냐는 비난?

- Project 파일에 junit을 어떻게 추가하는지? 코드의 규모가 커졌을 때는?

- 개발 시간이 많이 걸리고 알고리즘이 핵심인 SW에는 적용이 제한적일 것 같음. Step이 커질때 실수 할 수 있지 않을까?

- TDD에 익숙해지기 까지 업무속도가 느려질 것 같다. TDD를 이해하는 협업하는 분위기가 아니라면 좀 힘들듯...

- 코딩 및 설계과정에서 테스트 내용을 명확히 짚고 가야 할 거 같음

- 처음 하는 것이라 시간이 많이 걸릴것 같다. 보통 처음 설계부터 하는 개발이 아는 경우 어떻게 적용?

- 초반에 시간이 많이 걸림. 확실한 test case를 만드는데 어려움 있을듯

- 어느 단위 (어느 레벨)에서부터 적용할지 의문이 생김

- 일정이 촉박하면 이런거 다 무시하고 닥치는 데로 코딩하는 마음이 생길 수 있다.

- 개발 속도가 느리다.

- TDD를 익힐 때까지 기존의 습관을 고쳐야 할 것 같음. Test case를 정하기가 어려움.

- 아직 익숙치가 않아서 그럴지 모르지만 시간이 많이 걸릴것 같다. 내가 뽑은 테스트 케이스 외에 여러가지 다른 케이스가 있을 것 같다. 시간에 쫒겨 개발시에 이걸 적용할 수 있을지

 

생각보다 반응이 너무 좋아서 2부를 진행해보려고 합니다.

2부에는 Test 하기 좋은 클래스 설계하기 및 Mock Object 사용해보기로 진행해보려구요

또한 이러한 워크샵 형태로 스터디를 진행할 예정입니다. 그리고 내년에 제가 참가하는 프로젝트에서는 TDD를 매우 적극적으로 장려하고 적용할 생각입니다. 물론 현재 프로젝트에도 개인적으로 적용을 해봤구요. 정말 흥미 진진한 2013년이 될것 같습니다.

 

James 덕분에 동료들이랑 정말 좋은 경험 하고 있네요!

James가 이 글을 보진 못하겠지만 정말 감사하다고 말씀드리고 싶어요..!^^

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

댓글을 달아 주세요

  1. 2012.12.21 06:55 신고 한주영  댓글주소  수정/삭제  댓글쓰기

    멋지네요. 2시간이라는 짧은 시간에 이런 훌륭한 워크샵을 진행하신 건 정말 대단해요. 두번째 워크샵은 서초 전체로 오픈하면 어떨까요. 저도 참석해서 학생이든 보조든 동참하고 싶어요. 사전 참가비 2만원 유지하고. ㅎㅎ 저도 예전에 파싱 세미나 개설하면서 사전에 참가비 입금을 받았는데 저희 교육팀장님이 딴지 거셔서 되돌려드린적이 있어요. 하지만 좋은 시도 같아요. 주요 내용을 번역해서 제임스에게 알려줘도 좋을 것 같아요.

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

      댓글 주셔서 감사합니다.^^ 뒷풀이 비용으로 받는 2만원은 별거 아닐수 있지만 참여자의 관심도가 달라지는것 같아요..ㅎㅎ
      서초 전체 오픈은 좋은 생각입니다! 그런데 일단 소규모로 준비하고 검증을 해보고 진행해 보는 것이 어떨까 싶어요~ 팀내에서 진행하는건 1월 둘째주에 바로 진행해 보고 반응을 보려구요^^

  2. 2012.12.24 18:22 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    오.. 오랜만의 글이네. 잘 지내지? TDD Workshop 재밌었겠다.

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

      웅..ㅋㅋ 올만에 썼엉.. 이거 쓰는데도 일주일정도 걸린거 같앙..
      요즘 회사외의 시간중에 내시간이 거의 없당..ㅋㅋㅋ
      TDD 잼있엉.. 내년에는 꼭 실무에서의 Small Success를 만들어보려궁..^^

  3. 2012.12.26 15:37 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    자식 있는 사람이 회사 외에 내 시간이 어딨어. 나도 애기 보느라 힘들당 ㅎㅎ
    우리 회사에서는 이제 겨우 단위 테스트랑 일일빌드 적용하는 걸음마 단계라 TDD는 좀 더 있다 봐야 할 듯 ㅎㅎ

    • 2012.12.26 16:26 신고 윤청하  댓글주소  수정/삭제

      단위테스트라는게 말그대로 Unit Test를 말하는거야? 아님 CppUnit, JUnit과 같은 Unit Test Framework을 쓴다는 것이야?
      보통 TDD를 안하고 Unit Test를 한다는 것을 보면 Unit Test Framework을 써서 Integration Test 이상을 하거든... 그냥 궁금해서^^

  4. 2013.01.02 15:55 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    말 그대로 Unit Test를 하고 있어. TDD는 개발 방식까지 포괄하는 개념이라 적용하지 않고 Unit Test만 먼저 적용하고 있지.

  5. 2013.01.11 14:09 신고 지나가다가  댓글주소  수정/삭제  댓글쓰기

    xper 그룹 이메일 보고 들어왔습니다. 알차게 부럽네요~ 역시 뭐니뭐니해도 실천이죠! TDD 이야기보다 실무에 적용하는 이야기가 더 와 닿아 글 남깁니다. 개발 초년생 입니다. 올바른 개발 문화의 예를 앞으로도 많이 만나게 해주세요! 화이팅!

프로젝트 초반, 그리고 설계

상위설계(High Level Design)는 일반적으로 프로젝트 초반에 작성됩니다. 상위설계는 해당 프로젝트의 결과물의 근간이 되기 때문에 매우 중요하며 크게 변하는 경우는 드뭅니다. 어디까지나 상위설계이기 때문이죠. 뜬구름 잡는 얘기일 수도 있기 때문에 기술적으로 아주 세세하게 알지 못해도 작성할수 있는 경우가 있습니다. 하지만 상세설계(Low Level Design)에 접어들게 되면 구체적으로 많은 선택을 해야합니다. 골치 아프죠.
많은 경우에 어느 수준까지 작성해야 할지 갈피를 못잡고 방황하다가 적당히 보고 수준의 문서를 작성하고 구현에 들어갑니다. 결국 구현 따로 상세설계 따로인 결과물이 탄생하게 됩니다.

유지보수와 스파게티 코드 양산

유지보수중 스파게티 코드를 양산하게 되는 경우중 하나는 소스코드만 가지고 문제 해결을 할수 밖에 없는 경우 입니다. 아마 대부분의 경우가 이러할꺼라 생각됩니다. 근본적으로 문제를 해결하고 싶지만 근본적인 원인을 찾는데 도움이 될수 있는 큰 그림을 볼 수 있는 단서가 유지보수 단계에까지 남아있는 경우가 드물죠. 결국 기존 소스를 분석하다 지쳐서 땜빵코드를 삽입할수 밖에 없는 경지에 이릅니다. 제가 아는 대부분의 개발자는 땜빵코드를 삽입하는 것에 대해 부정적이지만 어쩔수 없이 하는 경우가 많습니다. 물론 저를 포함해서..


파일럿 프로젝트로 시작하는 '동작하는' 프로젝트

앞에서도 말씀드렸지만 상세설계를 어느 수준까지 작성해야할지 고민되는 경우가 많습니다. 저는 이를 해결하기 위해 프로젝트 초반에 파일럿 프로젝트를 진행합니다. 어떤 레퍼런스를 쓰던 일단 원하는 결과물을 얻기 위해 이것 저것 시도해보며 최종적으로 해당 기능들을 간신히 수행하는(하지만 있을건 다있는) '동작하는' 소스코드를 만들어 냅니다. 그리고 이것을 통해 프로젝트를 본격적으로 시작할때부터 '동작하는' 소스코드를 가지고 시작할 수 있게 합니다. 그리고 현재 수준에서 껍데기(Front-End) 바로 아래부분(Top)부터 추상화(Abstraction)을 통한 인터페이스 추출(Interface Extraction) 작업을 시작합니다. 추출된 인터페이스를 정리하면 매우 간단한(Class가 몇개 안되는) Class Diagram과 Sequence Diagram을 그릴수 있습니다. 이것이 상세설계서의 0.01 버전이 될수 있겠습니다. 이를 바탕으로 리팩토링을 하게 되면 인터페이스 추출이 완료된 상위 클래스를 제외하고는 나머지는 뚱땡이 클래스가 되어있겠죠. 이제 시작입니다.

Top-Down으로 진행되는 리팩토링, 그리고 지속적인 설계

리팩토링을 Top-Down으로 하게 되면 소스코드의 리팩토링 단위가 커지게 되므로 보통은 추천하지 않습니다. 하지만 설계는 Top-Down으로 할수록 깔끔해집니다.(제 의견입니다.) 가장 상위(Top)부터 시작하여 단계적으로 하위(Bottom)까지 진행되는 인터페이스 추출은 리팩토링을 지속적으로 하도록 유도합니다. 그리고 리팩토링된 소스코드는 항상 '동작하는' 상태여야 합니다. 그리고 결과물인 소스코드와 UML 문서는 최소 1명의 팀원과 리뷰를 합니다. 반복하다보면 뚱땡이 클래스들이 점점 분리되여 계층적인 클래스 구조를 만들게 될겁니다. 고럼 다음과 같은 프로세스가 만들어 집니다.


주기는 짧을 수록 좋다

저는 위의 주기를 하루에 최소 한번 할수 있도록 개발 계획을 수립합니다. (작은 마일스톤으로 쪼개는 방법은 다음에 써보도록 하겠습니다.) 그나마 주기가 짧아야 리팩토링 단위와 정리해야할 UML 문서의 단위가 작아집니다.

결과적으로 얻을 수 있는건..
  1. 항상 '동작하는' 소스코드
  2. 항상 정확하게 현재 소스코드를 큰 그림으로 파악(Static and Dynamic!)할 수 있는 딸랑 2종류의 UML Diagram
  3. 새로운 기능 넣기 전에 UML Diagram 으로 검토하는 습관...
  4. 바쁜 이슈처리 상황에서 근본적으로 문제해결을 할 수 있는 여유..
  5. 객체지향적 설계 능력?ㅡㅡ;;
그런데 결국은 뭐라도 해봐야..뭐가 다른지 압니다.

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

댓글을 달아 주세요

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

    지속적인 설계라는 표현 맘에 드네요. ^^

  2. 2013.04.08 03:57 신고 longchamp  댓글주소  수정/삭제  댓글쓰기

    http://mih.freerunso.com/

지난주에 현업과는 관련이 없어 보이는 NHN에서 주관하는 개발자 컨퍼런스에 참석하였습니다.
업무에 직접적인 관련이 없다보니 영감이 늦게 밀려드는가 봅니다. 이제서야 회고를 해봅니다. (발표 내용에 대한 후기는 없답니다.ㅋ)

NHN은 어디로 가고 있나?

Deview가 끝나고 난 느낌은 "NHN은 이렇게 잘 하고 있구나" 정도였습니다. 솔직히 그 이상도 이하도 아니었습니다.
후기 경품이 탐이 났지만 딱히 쓸말이 없었습니다. 싸이트 가면 동영상이 모두 공개 되어있는데 후기를 쓰자니 거시기 했습니다.
그러던중 문득 이런 생각이 들었습니다. 왜 키노트 스피치를 좀 지루할 정도로 구구절절히 길게 하였을까? 
제가 추측한 이유는 NHN이 가고 있는 목표에 대해서 진심으로 구구절절히 공유하고 싶었기 때문입니다.
키노트 스피치가 끝난 후에 지인중 한분이 그러더군요. "그냥 애자일 한다고 하면 되지 않나?"
분명 NHN에서 하고 있는 활동들은 애자일스러웠습니다. 하지만 애자일이 NHN의 목표가 아니기 때문에 궂이 애자일을 한다고 할 필요가 없었던 것이라고 생각합니다.
이러한 관점으로 Deview의 강연들을 생각해보니 NHN이 가고자 하는 곳이 어디인지가 보이더군요.^^ 
그곳이 어디인지 제가 자세히 기술할수는 없지만 분명한건 NHN 내부 개발자만을 위한 천국은 아닐겁니다.

궂이 애자일 조직이라고 표현할 필요가 없다.

가끔 애자일을 짝 프로그래밍이나 테스트 주도개발, 스크럼등의 Best Practice로 여기시는 분들이 많습니다.
혹은 갓 입사한 회사나 팀에서 애자일을 모른다고, 애자일 팀이 아니라고 실망하는 신입 개발자분들도 있습니다.
수단과 목표가 약간 혼동되는 부분이라고 생각합니다. 애자일도 목표는 아니라고 생각합니다.
꼭 개발조직에 애자일이나 RUP, Waterfall, CMMI 등의 정체성이 명시적으로 존재해야 할까요? 그런건 정치판에서도 지겨운데...
우리가 원하는건 애자일 조직이 아니라 행복하게 개발할 수 있는 매우 효율적인 개발 조직일겁니다. (정확히 말하면 제가 원하는 것입니다^^)
물론 조직에 맞는 애자일스런 Practice를 만들어나가면 좀더 빠르게 그런 조직을 만들수 있을것입니다.
제가 말하고 싶은건 뭘 하면 애자일이고 안하면 애자일이 아니다 이런게 중요한게 아니다라는 것입니다.^^;;
개인적으로 '애자일'이란 표현보다 '실용적인'이란 표현이 더 좋습니다.ㅋ
이런 점에서 NHN의 발표에서 '애자일'이란 용어를 쓰지 않은 것은 현명한 선택이었다고 생각합니다.

기대되는 NHN의 행보

얼마전까지만 해도 NHN은 뒤뚱거리는 거대한 한국의 포털 기업으로만 생각했었습니다. 개발에 열정을 가졌던 친구가 NHN의 신입사원으로 입사한 후에 개발의 열정이 식어버린... 그냥 포털 대기업으로만 생각했었습니다.
하지만 Deview를 보면서 생각이 조금 바뀌었습니다. 열악한 한국의 개발 환경을 불평, 불만만 하는 사람들이 변화될 수 있도록 기여하는 기업이 되고 있다고 생각합니다. (우리 회사도 그런 기업이 될겁니다!^^)

스스로 바뀌어야 환경도 바뀝니다.^^

이상 짧은 회고였습니다;... 회고라기 보다는 주저리주저리 떠든;;ㅋ



NHN Deview 2010 동영상 다시 보기 및 자료 : http://deview.naver.com/2010/courses.nhn
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.12.13 11:32 신고 ryuhayoung  댓글주소  수정/삭제  댓글쓰기

    청하 안녕~ ㅎㅎㅎ

  2. 2011.02.16 17:01 신고 arload  댓글주소  수정/삭제  댓글쓰기

    모든 일원이 만족하면서, 개선해 나가고 있따. 나아지고 있다는 느낌. 성장하고 있다는 느낌을 주기는 정말 어려운거 같아요.
    이러한 시도는 정말 감탄할만 하죠. 애자일이 만능이 아니라. 조직도 만족하고, 조직 구성원도 만족하는 것.. 그게 정말 이상인거 같습니다. 다른이의 이상과 저희들의 이상은 다르니깐요.. :)

  3. 2011.02.18 20:21 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로의 자세를 바꾸면 그 다른 이상들이 하나로 모여질수 있다고 생각해요^^

  4. 2011.11.24 21:44 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    "행복하게 개발할 수 있는 매우 효율적인 조직".. 저도 그런 조직을 꿈꾸는 1인입니다...^^;
    하지만 노력하는 만큼 잘 안되서 요즘은 지처가고 있는 중이랍니다...
    사람들의 마인드를 바꾸기가 쉽지 않더군요.. 제가 괜히 엄한데와서 하소연하는군요 >.<

    • 2011.11.25 15:51 신고 윤청하  댓글주소  수정/삭제

      반갑습니다! 윤청하입니다.^^
      저도 한때 지쳐있었는데, 요즘은 200%이상 활력소를 찾았습니다.
      제 경우엔 남을 보다가 제 자신에게 포커스를 바꿔보니 즐거워지고 생산성도 매우 높아졌습니다.
      그렇게 지내다 보면 남들이 호기심을 갖게 되더라구요. 어떻게 하면 저렇게 즐겁게 하나...
      이제 시작인거죠!

      고민은 나눌수록 잘 풀리는거 같습니다. 잘부탁드려요~

얼마전에 "창의적인 아이디어는 어디에서 오는가?" 라는 주제로 강연을 들은적이 있습니다.
강연자분의 결론은 다음과 같았습니다.
창의적인 아이디어는 새로운 것이 아니라 기존에 있던 것을 새롭게 보는 것이다.
창의적인 아이디어를 얻기 위해서는 내가 보고 경험한 것들을 새롭게 볼줄 알아야 하며, 
다른 사람의 말과 행동을 새롭게 볼줄 알아야 한다.
강연을 듣고 저는 다음과 같은 생각을 했습니다. 
항상 주위의 모든것에 호기심을 갖고 관찰하여 필요한 경우 내것으로 만들수 있어야 창조적인 인재가 될수 있다
결국 매우 상투적인(cliche) 결론이었습니다. 하지만 다시 생각해보니 개발자들에게 매우 필요한 능력일것 같다는 생각을 했습니다.

창의적인 개발자는 어떤 능력이 필요한가?

저는 다른 개발자들이 만들어 놓은 결과물을 분석하고 이해할줄 알며, 가져다 사용할 수도 있고 필요한 경우 개선될 수 있도록 기여할 수 있는 개발자가 창의적인 개발자라고 생각합니다.  혼자 모든 것을 만들어 내는 것 보다는 다수의 사람이 같이 만들어 내는 것이 더 창의적인 결과물이 될수 있기 때문입니다.
세계적인 오픈소스에 기여하지 않더라도 같은 회사내, 같은 연구소내, 같은 팀내의 다른 개발자들의 결과물들이 같이 공유하며 개선되고 성장 할 수 있다면 그 조직은 창의적인 개발 조직이라고 할수 있을 것입니다.
이러한 것들이 가능하려면 조직 내에 소스코드 오픈 문화, 개발자간의 신뢰 문화등이 밑바닥에 깔려 있어야 할 것입니다.
어렵지만 할 수 있지 않을까요? 전 애자일이 창조적인 조직을 위한 은탄환이라고 생각하지 않습니다. 
하지만 시도해볼만한 것임은 확실하다고 생각합니다.^^

Two Heads Are Better Than One.
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.09.13 09:43 신고 noforest  댓글주소  수정/삭제  댓글쓰기

    공감~

  2. 2011.02.25 10:36 신고 이장석  댓글주소  수정/삭제  댓글쓰기

    글 잘 보았습니다.
    좋은 하루 되십시오.

현재 제가 속한 팀은 아직 애자일 프랙티스를 전파하기에는 이른 시기입니다. 
고민 끝에 (사실 실제 고민은 몇초?;) 점진적 설계와 구현을 해보는것은 어떻겠냐고 같이 일하시는 윗분께 건의했습니다.
길지않은 토론 끝에 UML로 설계를 하고 이터레이션은 고정시키지 않는다는 전제하에 점진적 설계와 구현을 해보기로 했습니다.
제가 정한 한 이터레이션에서 해야할 일들은 다음과 같았습니다.
  1. 해당 이터레이션에서의 요구사항을 Use-case Diagram으로 작성 및 리뷰 (mandatory)
  2. Activity Diagram 및 Collaboration Diagram은 개인적으로 작성 (optional)
  3. 섬광탄 구현 (optional)
  4. Class Diagram 및 Sequence Diagram 작성 및 리뷰 (mandatory)
  5. 설계에 맞게 구현 (mandatory)
  6. 구현에 대한 짧은 회고 및 피드백으로 설계 수정후 구현 수정 - 반복 (mandatory)
  7. 데모 후 다음 이터레이션 (mandatory)

결과물은?
  • 프로젝트 기한 : 예상보다 1주일 정도 먼저 끝났음
  • 결과 바이너리 데모 : 원했던 기능 완료, 어느정도 안정화 됨
  • 설계 문서 : Use-case Diagram 1장, Class Diagram 3장, Sequence Diagram 3장 - 소스코드와 99% 일치

회고
  • 기존의 관행을 깨보았음 (사실 작은 프로젝트라 큰 의미는 없음)
  • UML 설계를 통한 설계 리뷰 및 공유는 정말 괜찮았음
  • 이터레이션을 고정시키는 것에 대해서 반감이 있는 경우에는 살짝 빼도 무리가 없어보임
  • 기존의 관행과의 협상에서 줄건 주고 얻어올건 얻어와야 함 (이렇게 안하면 애자일이 아니다 라는 고정관념을 버려야함
  • 섬광탄 구현이 UML 설계에 많은 도움이 되었음

결론 : 
나는야 행복한 개발자~
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

쉬워 보이는 스크럼

작은 개발팀의 생산성과 품질에 대해서 고민해 본적이 있으신 분들이 스크럼에 대한 이야기를 들으면 적지 않은 분들이 상당한 영감을 받습니다. 그리고 바로 팀에 적용 할 수 있을 것 같은 뽐뿌를 받곤 하죠. 그중에 저도 포함되구요.
하지만 데일리 미팅이 그나마 만만할 뿐 프로덕트 백로그, 스프린트 미팅이나 회고, 백로그 추정등은 그렇게 녹록하지 않았습니다.

베스트 프랙티스 도입보다 더 중요한건 애자일 팀 만들기

스크럼의 구성요소들을 하나하나 뜯어보면 애자일 정신이 가득한 프랙티스들이 주류를 이룹니다.
즉, 애자일 개발팀이 아닌 팀에서 스크럼을 도입하려다 보면 데일리 미팅 정도야 하겠지만, 하나하나 적용시키다 보면 난관에 부딪힐때가 많습니다. 더 중요한것은 이러한 난관에 부딪힐때 해당 고민들을 팀원들과 풀려고 하는 것이 아니라 외부 모임(자신만의 세계, 개발자 친구나 개발자 포럼등)에서 풀려고 하는 것이죠. 즉, 적용하려는 리더 조차 애자일스럽지 못한 것입니다.

제 생각에는 갑작스럽게 스크럼을 바로 도입하는 것보다 애자일 개발팀이 되기 위해 하나씩 바꿔나가는 것이 좋다고 생각합니다.
애자일 개발팀으로써 살짝 자리를 잡은 뒤에 스크럼을 도입해보면 더욱 효과적일것 같습니다.
아래의 프로세스들이 팀에 살짝  정착되고 나서 스크럼을 도입한다면 더욱 효과적일것 같습니다.
  • 지속적인 피드백을 주고 받는 설계와 구현
  • 사용자 스토리를 이용한 요구사항 정리 
  • 업무 추정을 담당자에게 위임 
  • 빌드 자동화 / 일일 빌드 
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.08.19 11:45 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    헨릭의 Scrum & XP 책의 앞에보면 회고부터 시작하라고 이야기 합니다. 저도 동의합니다. 회고를 통해 먼저 무엇인 좋고 나쁜지를 찾아보시는것도 좋은 방법일듯..

오늘 가산에 있는 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 신고 윤청하  댓글주소  수정/삭제

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

새로운 개발팀

이전 개발팀에서 이메일을 이용한 코드리뷰를 시행한 적이 있습니다. (2010/02/26 - [Programming] - 이메일로 코드 리뷰 하기)
혹시나 해서 요즘에도 잘 되고 있나 여쭤보았지만 아직은 형식적인 단계라는 답변을 들었습니다.
이직을 하고 나서 저는 변화된 환경에 적응하기 위해 애자일 프랙티스를 언급하거나 제안하지 않았습니다. 
단지, 이전 업무에 대한 소개를 할 때 개발 프로세스 개선 활동에 대해 짧게 소개만 했습니다. 
(다행히도 입사 4개월 만에 애자일에 관심을 보이시는 관리자 분이 계십니다!^^~~ 이번에 애자일 세미나를 같이 들으러 감~)

프로세스에 녹아든 코드리뷰

경력으로 입사하였기에 빠르게 프로젝트에 투입되었습니다. 현재 개발팀의 소스코드는 svn으로 관리됩니다. (git로 넘어가는 추세..)
그런데 특이했던 점이, 자신의 home directory에 check-out된 소스에서 직접 작업하지 않고 export된 다른 복사본(working source)에서 작업을 하는 것이었습니다. 즉, commit과 update 절차는 다음과 같이 진행되었습니다.
  • commit 절차 : 복사본에서 작업 => svn 소스와 diff를 통한 merge => svn commit
  • update 절차 : svn update => 복사본 소스와 diff를 통한 merge => 복사본에서 검증
즉, 개인 작업물에 대해서 철저하게 분리하는 형태 입니다. 어찌보면 번거로워 보일수 있는 소스관리 프로세스 였습니다.
그런데, 작업이 진행되면 될수록 소스코드가 잘 정리되었으며, 믿음직하고 든든해 졌습니다. 
그것은 merge 과정에서 자신의 코드와 타인의 코드에 대해서 source code inspection이 암시적으로 행해졌기 때문입니다.
복사본에서 작업하기 때문에 개인용 테스트 로그가 svn 소스 트리에 등록되지 않은 것도 한 몫 했습니다.

프로세스(혹은 도구) 개선이 정답?

김창준님이 한국 developerWorks의 dW Column에 기고하신 "소프트웨어 관리자의 개선 우선순위"라는 글을 보면 다음과 같은 재미있는 연구 결과를볼 수 있습니다.

쉽게 말해, 도구 부분에서 상당한 개선을 이뤄내면 비용적으로 세 배 정도 개선을 얻을 수 있다. 이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용적으로 64배 정도의 개선을 얻을 수 있다는 뜻이다.

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 그러나 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다


제 경험을 보면 마치 프로세스(혹은 도구) 덕분에 큰 효과를 본것 처럼 보입니다. 하지만 근본적인 원인은 따로 있었습니다.

내 코드가 아닌 우리 팀의 코드

개발과정에서 개발팀의 관리자 분(개발에도 참여하심)과 개발 리더분은 지속적으로 소스코드를 리뷰하고 있었습니다.
라인단위로 의미없거나 논리적이지 못한 코드가 있다면 명확하게 해명을 해야 svn 소스 트리에 남을수 있었습니다.
로직이 불분명하다면 버그가 생길만한 케이스를 분석하거나 테스트 케이스를 만들어서 알려주십니다.
우리에게 누가 문제를 해결했고 누구의 소스에서 버그가 있었다는 것은 중요하지 않았습니다.
중요한건 우리 팀의 코드가 품질이 높아야 한다는 것이지요. (물론 납기일을 만족하면서...)
코드리뷰는 진짜로 해야 효과가 있는 것 같습니다.
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.07.05 22:35 신고 Eminency  댓글주소  수정/삭제  댓글쓰기

    완전히 git를 쓰면 굳이 SCM과 분리된 working copy에서 작업하지 않아도 될 거 같은데?
    그나저나 git라니 꽤 진보적이구만 ^^; git보단 mercurial이 훨씬 편한 거 같긴 하다만..;

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

    정말 동감가는 글입니다.^^;
    전 SVN에 커밋하기전에 코드리뷰를 해주고 싶은데 받아줄 사람이 없군요 ㅠ.ㅠ
    요즘 애자일,TDD에 관심이 많이 생기고 있는데 저와 관심분야가 비슷하신것같아요.
    자주 놀러오겠습니다^^;

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

      없다고 포기 하지 마시고 최소 한명이라도 자기 편을 만드시면 좋을 것 같아요^^
      자주 놀러오세요~~ 같이 나누면 나눌수록 좋은 수가 생기기 마련입니다.

3월 11일 늦은 8시에 강남 토즈에서 xper 주체로 Rebecca Wirfs-Brock 방한 기념 번개 모임이 있었습니다.
급하게 마련된 번개 모임에도 불구하고 30여명에 가까운 분들이 참석해주신 멋진 자리였습니다.
김창준님이 질문 및 답변에 대한 통역을 해주셨는데, 시간 관계상 필요에 의한 나름 인터렉티브한 통역을 하였습니다.
나름 열심히 정리했는데, 정리한 종이가 어디갔는지 안보이네요;; 좌절OTL
그래서 인상 깊었던것 두가지만 가지고 개인적인 소감을 정리해보겠습니다.

패턴과 프랑켄슈타인

사실 이 말은 김창준님이 크리스토퍼 알렉산더를 소개할때 짧게 언급하신 내용입니다.
패턴의 창시자라 불리우는 크리스토퍼 알렉산더가 최근 패턴을 관통할 수 있는 새로운 내용을 정리했다고 합니다.
이유인 즉슨, 패턴의 한계 때문이었습니다. 즉, 패턴을 중심으로 설계를 하다보니 프랑켄슈타인을 만들게 되었다는 것이죠.
짧게 지나친 내용이지만 개인적으로 프랑켄슈타인이란 비유가 인상깊었습니다. 
저는 패턴에 대해 많이 학습하지 못했지만, 패턴에서 커뮤니케이션 도구(어떠한 행동, 구조 등에 대해서 적절한 이름을 붙여놓은 것) 이상의 그 무언가를 발견하지는 못했었습니다.
즉, 패턴은 도구일 뿐 목적이 될 수 없다는 것을 같이 공감한것 같아서 기분이 좋았습니다.

크리스토퍼 알렉산더

이번에 처음 들은 이름입니다. 패턴의 창시자이자 그것의 한계를 지적하신 분입니다. 
그리고 Nature of Order 라는 새로운 것을 또 만드셨습니다. 패턴을 관통하는 것이라고 하셨는데 아직 이해 불가합니다ㅠㅠ
모임 시간에 언급된 내용들에 대한 정리는 김창준님이 깔끔하게 해주셔서 패스합니다.ㅋㅋ (모임 후기 링크)
두가지 내용이 언급되었었습니다. alternative repetition 과 level of scale 이었습니다.
불행히도 전 정확한 정의를 모릅니다. (이제 슬슬 Nature of Order 책을 사 봐야겠다는 생각이 드네요.) 
따라서 개인적인 소감만 쓰겠습니다^^

Alternative Repetition

저는 alternative repetition을 "조금씩 다른 형태를 지속적으로 반복하는 것"이라고 이해했습니다.
즉, 아키텍쳐를 설계시 추상화 설계와 구현 설계를 지속적으로 반복해야 좋은 결과물을 얻을 수 있을 것 같습니다.
전문가일 수록 반복 주기가 짧고 반복의 깊음와 얕음이 지속적으로 변할 겁니다.
사실 이 부분이 설계에서 가장 어려운 부분이 아닐까 싶네요. 
어디까지 구체적으로 해야 하는지 어느 정도 수준으로 추상화가 되어야 하는지.. 정말 어려운 선택인것 같습니다.
또한 정답이 없기 때문에 검증하기는 더더욱 어려운 것 같습니다.
레베카가 한국에 온 이유가 L모 전자 설계 교육때문에 왔다고 하는데, 설계에 대한 구체적인 교육이었다고 합니다.
정말 부러웠습니다. 전문가를 옆에 두고 실습을 하면서 맞는지 틀리는지 물어볼 수 있으니까요..^^

스크럼의 스프린트나 업무를 위한 학습을 하는 것도 비슷한 맥락에서 생각해 볼수 있지 않을까요?^^ 
Nature of Order같은 책은 정독하는데 시간도 오래걸릴 뿐만 아니라 실무에서 바로 적용하기도 어렵습니다.
반대로 안드로이드 프로그래밍같은 책은 읽는데 시간도 별로 안걸리고 실무에서 바로 적용할 수 있습니다.
학습을 하는 태도가 한쪽으로 치우친다면 초보자라 할 수 있겠습니다. 
분야를 막론하고 지속적으로 반복해야 전문가가 될 수 있을겁니다. (전 아직 초보ㅋㅋ)

골고루 먹자

결론이 좀 쌩뚱 맞습니다. 이해해 주시길 바랍니다^^;;
xper 모임을 많이 나오지는 않았지만 항상 보고 듣고 있었습니다. 이젠 좀더 구체적인 부분에서 학습을 공유하고 싶어졌습니다.
그래서 이번 주 부터 시작하기로 했습니다. 목표는 안드로이드 정복!ㅋㅋ (오래 준비했습니다~)
당연히 xper 모임도 충실히 참석할 겁니다^^

전 친구랑 한잔하러 끝나고 바로가서 못찍었습니다;;

레베카 옆에 앉아서 졸면서 적고 있는 청하^^

사진 찍어주신 최승준님께 감사드립니다^^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.03.18 13:42 신고 황상철  댓글주소  수정/삭제  댓글쓰기

    아 참석 못했던게 참 아쉽네요.

  2. 2010.03.18 14:19 신고 ohgyun  댓글주소  수정/삭제  댓글쓰기

    저도 그 책을 읽어보려고요.
    혼자 사려고 알아보니 배송비가 책 값보다 더 많이 나오더라고요. >_<
    제본을 맡겨볼까 하고 있답니다^^

  3. 2010.03.19 09:51 신고 ohgyun  댓글주소  수정/삭제  댓글쓰기

    ㅇㅇ 좋지요^^ 혹시 책 구입하기 힘드시면 말씀하세요~ 제본이 가능하면 한 권 같이 해드릴께요~ :)

  4. 2010.03.21 11:58 신고 PatternLoader  댓글주소  수정/삭제  댓글쓰기

    맞습니다. 패턴을 억지로 이용한 시스템을 쓸려다가, 망치는 경우가 흔합니다. Context와 SideEffect를 잘 고려해서 써야 하죠. 전 예전에 소프트웨어 설계 패턴을 많이 봤는데. 요즘은 사람에 관련된 패턴을 많이 보게 되네요.. :)
    이것도 마찬가지겠죠 :)

    • 2010.03.21 21:58 신고 윤청하  댓글주소  수정/삭제

      상황과 환경에 따라 잘 써야 하죠!^^ 스터디에는 참가하지 못하지만 영수님께서 정리를 너무 잘해놓으셔서..좋은 내용들을 쉽게 알수 있었습니다~
      감사합니다!

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 신고 윤청하  댓글주소  수정/삭제

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

티스토리 툴바