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

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total120,782
Today108
Yesterday128
현재 제가 속한 팀은 아직 애자일 프랙티스를 전파하기에는 이른 시기입니다. 
고민 끝에 (사실 실제 고민은 몇초?;) 점진적 설계와 구현을 해보는것은 어떻겠냐고 같이 일하시는 윗분께 건의했습니다.
길지않은 토론 끝에 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 책의 앞에보면 회고부터 시작하라고 이야기 합니다. 저도 동의합니다. 회고를 통해 먼저 무엇인 좋고 나쁜지를 찾아보시는것도 좋은 방법일듯..

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

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

티스토리 툴바