알라딘MGG와이드바


애자일 실천법 세미나 2010 후기 개발 이야기

정리 형식 #

  • 관련있는 내용은 합쳐서 정리했습니다.
  • 패널 토론은 익명성이 필요할 수 있어 발표자 이름을 적지 않았습니다(요청하시면 따로 정리해 드립니다).
  • 개인적인 생각이 섞여 있을 수 있고, 기억나는대로 정리한거라, 여기 적혀있는 내용이 발표내용과 100 % 일치한다고 생각하시면 안 됩니다.
  • 오늘은 양복 입은 분들이 많이 오셨더군요. HP 에서 했기 때문일까요? 여의도에서 했기 때문일까요?
  • 개인적으로 생각지 못한 몇 분을 만날 수 있어서 좋았습니다. 언제 좀 더 길게 얘기 나눠 보아요.
  • [http]#asp2010 도 확인해 보아요.

HP 관련 세미나 #

  • 애자일 정착 실패 원인
    • 개발자가 unittest 와 시스템 테스트를 혼동
    • "스프린트 내" 정기적인 회귀 테스트가 없다.
    • (외국의 경우) 지역적으로 떨어져 있는 팀끼리 조율이 어렵다. 설계는 미국에서, QA 는 유럽에서, 코딩은 인도에서 등..
    • 시스템 테스트가 연기되는 waterfall 처럼 경우가 많다.
    • 조직를 변화시키기가 어렵다(QA 팀이 개발 초기부터 투입되려면 개발팀과 QA 팀과의 연계를 어떻게 할지 조직 구성면으로도 생각해 봐야함)
  • HP 에서 쓰고 있는 거라고 함. [http]Mylyn beta version : eclipse 와 연계 가능. 하지만, 공개 버전 없다는데?
  • Agile 에서 성능 테스트가 어려운 이유
    • 애자일을 한다고 해서 품질이 보장되는 건 아님
    • 가시성 및 진행 현황 확인이 어렵다(서비스 수준 목표 : Service Level Objectives. ?SLOs) -> 하지만 스크럼이라면 어떨까?
    • 표준화가 어렵다(다양한 툴을 쓰고 있다는 의미인 듯)
    • 개발자가 QA 도 해야 함(멀티 플레이어가 되어야 함)
  • 한국에서 실패하는 프로젝트는 없다. 다만, 연장될 뿐이다.
  • 팀별로 별도의 성능 테스트용 머신을 마련하자 -> 꽤 당연해 보이는 얘기인데, 이것도 안 되는 회사가 있는 듯?
  • 개발팀과 QA 팀
    • 개발팀 > QA 팀 : 장점 - 튜닝 속도가 빠르다. 단점 - 인력 + 시스템 비용, 경험 필요
    • 개발팀 = QA 팀 : 기본 테스트는 개발팀에서, 전체 통합 시스템은 QA 팀이. 협업이 잘 안 될 수도
    • 개발팀 < QA 팀 : 단점 - (QA 팀이 빡빡하게 굴면, 혹은 다른 QA 가 밀렸다는 이유로) 개발 속도에 영향을 미칠 수 있음
  • 설계 3개월, 코딩 3개월, 테스트 4개월, 배포 & 유지보수 6개월 프로젝트에서, 1달부터 코딩합시다 했더니 개발자들이 싫어하더라. 그나마 설계하는 3개월동안 놀 수 있는게 그것도 못 하게 한다고.
  • 전반적인 관객 반응
    • 실제로 Mylyn 이나 다른 HP 솔루션이 실행되는 걸 보고 싶다.
    • 과연 HP 가 Agile 과 어떤 상관관계가 있는지 잘 와 닿지 않는다.

애자일 도입 성공 요인 분석 #

  • [http]발표 관련 김창준님 자료
  • 업계 종사 분야의 변화.
    • 애자일을 사용하고 있다는 SI 개발자가 많이 늘었다.
    • 보수적인 제품 개발자일 수록(보안, 금융) 애자일 적용 빈도가 낮다.
  • 애자일 도입이 프로젝트 성공에 도움을 주었는가?
    • 26% 매우 그렇다, 54% 그렇다, 8% 전혀 그렇지 않다(50명 기준)
  • 애자일 실천법과의 상관관계(는 김창준님 PT 참고)
    • CI(지속적인 통합)가 크게 중요하지 않다고 생각했었는데, 다른 요소들과의 연관고리가 많다.
    • 다른 실천법을 할 수 있게 해 주는 enabler 역할을 CI 가 한다.
    • 그 이유 중 하나는, 따로 브랜치 나눠서 작업하고 있으면 그 사람 작업이 내 일이 아닌 거 같아서 관심이 안 생기지만, 매일 통합된다면 그 사람 작업이 내 일에 영향을 미치기 때문
  • 성공 기여도 분석
    • 고객 참여가 리팩토링, 자동화 테스트 붙이기, 코드 공동 소유보다 2 배 이상 성공 요인이 높다.
    • 하지만, 가장 고객 참여는 가장 어려운 일이기도 하다.
    • 성숙도가 낮은 개발팀에서 성공에 영향을 준 실천법은 고객 참여밖에 없었다. 그만큼 중요.
  • 초보 개발팀과 고수 개발팀의 차이점
    • 초보팀은 쉬운 거 부터 하려 한다. 처음에는 재미있고 분위기도 좋지만, 결국 미뤄놨던 어려운 부분 때문에 프로젝트가 실패한다.
    • 고수팀은 가장 어려우면서 핵심적인 작업(되느냐 안 되느냐가 프로젝트 성패를 좌우하는)을 먼저 한다.
  • 팀에 뛰어난 애자일 코치가 있는가? 가 중요하더라.

core of testing in agile #

  • 애자일 성명서에서는 '개인 & 소통' 이 '프로세스 & 툴' 보다 중요하다고 하지만, 단기간에 성과를 내려면 '프로세스 & 툴'이 중요하다.
  • context driven approach 가 나오면서 애자일과 탐색적 테스팅이라는 게 나왔다.
    • 그래도 전통적인 test 는 여전히 필요하다.
  • 스크럼의 닭과 돼지 일화
    • 지금 드는 생각인데, 자식(달걀)에 대한 부모(닭)의 사랑을 무시하는 건가 :)

L사 도입 사례 #

  • [http]발표자료 - 애자일 도입 사례 - Agile Practices Seminar 발표 (링크 깨졌네요)
  • 새로 연결한 링크입니다. 아마 이 발표자료였던 걸로 기억합니다.
  • 새로운 & 변경되는 기능에만 단위테스트 적용
  • 계획 : 한 팀을 잡아서 2일 전일 교육, 3개월 정도 on-site 코칭
  • 결과
    • HW 개발 환경등의 이유로 mock 을 사용
    • 교육을 1시간씩 15번 나눠서 했더니 반응이 더 좋더라. feedback 받을 수 있는 기회가 훨씬 많기 때문.
  • 아예 모듈 하나를 선택해서 '애자일 코칭' 팀이 직접 애자일스럽게 개발하기로 했음
    • 의도 : (입코딩만 하는 코치가 아닌) 우리도 같이 삽질하겠다.
    • 400+ 단위 테스트, 100% (statement) 코드 커버리지, 1 초안에 끝나는 회귀 테스트, 회사 전체 표준으로 사용됨
  • 교훈
    • 작업은 좋았으나, 확산은 어렵더라. 그래도, 몇 명이 애자일을 좋아하게 되었다.
    • TDD, 단위 테스트는 쉽지 않더라. 여전히 NAH 현상(Not Applicable Here : 거기에서는 어떨지 몰라도, 여기에서는 안 될꺼야) 이 있더라.
  • Scrum 도입 시작
    • 윗분들이 많이 도와주셨음.
    • 개발팀을 믿자. 뭔가 '이런 거 없나요? 이럴 때 어떻게 할 수 있나요?' 할 때 방법을 알려주면 좋아하면서 잘 하시더라.
    • 하지만, top-down 방식이 되면서 변질되는 감이 없잖아 있다. scrum, agile 에 대한 감이 없는 분이 위에 있을 경우에는 자신의 입맛에 맞는 방식으로 생각하고 이용하려고 한다.
    • [http]WPPM(퍼포먼스 매니지먼트 캠페인), visual planning
  • Agile, Scrum 하면서 드는 생각 : 가장 중요한 건 오히려 '설계'구나.

S사 도입 사례 #

  • [http]발표자료
  • 애자일을 도입하려고 하는 이유를 아는 게 중요하다
  • 성공사례를 만들어라. 외부 레퍼런스(높은 분도 알만한 큰 회사)가 없어서 회사 내부에 레퍼런스를 만들기로 했다.
    • PM 한 분을 5 번 찾아가 애자일 써 보자고 설득.
    • 창준님에게도 6 번 찾아가 코칭을 부탁.
    • 덕분에 성공 사례 만들 수 있었음
  • PM day 때, 해당 개발 PM 분이 애자일이 성공적이었다고 잘 소개를 해 주셔서 많이 얘기가 되었고, 사장실에까지 보고됨.
    • 특히 scrum 은 현황판, daily meeting 같이 매니저가 좋아할만한 부분(개발자를 쪼기 쉬운)이 많아서 설득하기 쉬움.
  • 문서는 반드시 필요
    • 조직에 확산시키려면 문서화가 꼭 필요하다.
    • 그대로 따라할 수 있는 manual, 잘 했는지를 확인할 수 있는 check list 등을 만들어준다.
    • 레퍼런스 프로젝트할 때 사소한 것도 사진을 남겨서 30여장짜리 PT 를 만들어 여러 팀에 배포했다.
  • 혼자서는 아무것도 못한다.
    • 특히 윗사람을 설득해야 한다. 관리층 지원없이는 진행 안 된다.
    • 신입사원 교육과정에도 agile 이 포함되었다.
  • 측정
    • 뭐든지 측정할 수 있어야 한다. --> 이 부분은 다음에 다시 posting
    • 외국 컨퍼런스 가 봐도 유명한 컨설턴트들도 측정 부분은 어떻게 해야 할지 아직 잘 모르더라.
  • 기술자 & 관리자가 함께 사는 세상
    • scrum, xp, lean dev.
    • 사람들 의식이 좋아진다. 다만, 피부로 느껴지는 효과가 사라질 쯤에는 약발이 떨어진다.
    • TDD 는 힘들어서, 테스트 코드를 자동으로 만들어 주는 툴을 만들어 배포하고 있다.
  • 애자일이 무엇인가
    • '수술은 성공했습니다. 하지만, 환자는 죽었습니다.'
    • 프로젝트가 성공해야지, 애자일이 성공한 게 무슨 소용이냐.
    • 지금은 공인 스크럼마스터 트레이너인 Clinton Keith 가 GDC 에서 scrum 을 얘기했을 때 가장 많이 공격받은 부분

패널 토론 #

  • 참석자 : [http]박영록, 변신철, [http]황상철, 권원일, 최승준, [http]김기웅, [http]남기룡, [http]박일, [http]심우곤, [http]한주영, [http]민신현, [http]김창준
  • 짝 프로그래밍 설득
    • 싫은 사람끼리는 시너지를 낼 수 없다.
    • 왜 못하냐? 심지어 pair documenting 도 할 수 있다. 왜 안 하려고 하는지 확인해야 한다. 비용(노력, 기계)이 많이 들기 때문이라면, 비용을 마련하자.
    • pair table 도 만들어서 권장해 봤지만, 강요하는 걸로 느끼더라. 특히, junior 같은 경우 senior 가 뒤에서 보고만 있어도 긴장해서 제대로 일 못하더라. 수영을 예로 들면, 코치가 지켜보는 부분에서는 긴장되서 자세가 망가지더라.
    • 반대로, senior 가 디버깅이나 설계를 할 때 junior 를 데려와서 의견을 물어보는 방식으로 짝 프로그래밍을 했더니 도움이 되더라.(나는 반대로 얘기했음)
    • 이 부분은 팀의 분위기나 서로 얼마나 친한가, 잘 맞는가에 따라서 적용해야 할 듯.
    • 굳이 싫다면 안 시키되, 대신 (doxygen 주석은 꼭 달아라) 같은 minimum 은 제시한다.
    • 짝 프로그래밍은 지식 전파 방법으로 최고다. "너가 우리 팀에서 잘 하니까, 누구 좀 도와주면 좋겠다" 라고 훈련을 부탁했고 책임감을 느끼게 했다.
      • "너가 잘 하니까" 라고 그 사람을 인정해 주는 부분이 중요하다.
  • 레거시 코드에서 단위 테스트 붙이기
    • 직급 높은 분과 얘기할때는 오히려 70% 이상 커버리지가 나와야 효과가 있다고 목표치를 높게 부른다(이렇게 해야 급하게 성과를 확인하려는 걸 막을 수 있다).
    • 개발팀에는 '고쳐야 하는 부분' 부터 조금씩 해 봅시다 라고 얘기해서 안심시킨다.
    • 레거시 코드는 잘 돌아가는 코드인데, 여기에 테스트하겠다고 리팩토링하는 것은 비용이 너무 크다. 10% 만이라도 커버리지가 나올 수 있다면 충분한 가치가 있다.
    • xUnit 테스트 패턴 책을 사 보자.
  • 애자일을 잘 모르는 고객을 어떻게 설득
    • 적극적으로 중간 결과를 보여줬더니, '이거 작업 끝났나 보네' 하면서 요구사항을 더 쏟아내더라. 심지어 고객을 영업팀이 만났을 경우에는 영업 따 내겠다고 고객이랑 맞장구 치면서 요구사항이 더 생길 수 있다.
    • 반대로 좋은 고객을 만난 경우에는 중간 결과물을 보여줬더니 '이건 써 보니까 없어도 되겠네요' 라고 하면서 요구사항을 없애주었다. 결국 어떤 고객이냐에 따라 다른 전략이 필요할 듯.
    • 사실 고객은 항상 우리 편이다. 갑을병정에서 정으로 일하다 보면 을,병과 의사소통 하게 되는데, 사실 진짜 고객인 갑과 얘기할 때는 오히려 말이 잘 통할 때가 있더라.
    • 애자일이 SI 에는 적합하지 않다고 생각한다. 입장 바꿔 내가 고객이라면 내 마음대로 하고 싶을 거 같다.
    • 악성 프로젝트가 인간성을 갉아먹는다.
    • 중간 결과물을 UCC 로 만들어줬더니 높은 분들까지 보시더라.
  • 과중한 업무와 야근 때문에 애자일이고 뭐고 못 하겠다.
    • 아무리 시간이 없어도 작은 시간을 쪼개어 뭔가를 할 수 있다.
    • '베터리가 닳는 긴장감' 을 느끼고 싶어서, 지하철에서 노트북으로 코딩을 하기도 하고, 앨리베이터에서 할 수 있는 일도 있다. 그리고 늘 포스트잇을 들고 다니면서 모든 일을 애자일하게 하려고 한다. 12년간 [http]유치원에서 문서를 같이 쓸 수 있는 환경을 만들어 왔는데, 쉽게 할 수 있는 환경을 먼저 만들어 주는 게 중요하다.
    • "내가 올바르다고 믿는 게 있다면, 목숨걸고 꼭 그렇게 행동하자"
    • 테스팅을 예로 들면, [http]Pairwise Testing 같이 테스트에 필요한 조합을 만들어 주는 툴을 사용하면 작업 효율을 높힐 수 있다.
    • 일이 잘 안 되면 동료와 같이 산책한 후 돌아와서 코드를 같이 본다.
    • 가방에 보드마커, 포스트 잇을 가지고 다닌다. 내가 익숙해야 다른 사람에게 권할 수 있다. 어떻게 하면 틈을 만들 수 있을지 고민한다. 빵을 자비로 사 들고가 daily meeting 을 유도한다거나, 개발중인 게임으로 사내 대회를 열어 자연스럽게 sprint release 회고를 할 수 있게 한다.

그 외 #

  • review되지 않은 코드는 repository에 merge되지 않도록 하는 시스템이 있다고([http]gerrit)
    • 하지만, 책임 분산이 될 수도 있고, 작업 능률을 분명 떨어뜨릴 수도 있지 않을까?

다른 후기 #


핑백

덧글

  • drvoss 2010/04/22 13:15 # 삭제 답글

    수술은 성공했습니다. 하지만, 환자는 죽었습니다. 아 이거, 너무 입맛에 짝달라 붙는 쩌는 비교인데요. 좋은 후기글 잘 봤습니다. ^^
  • 청하 2010/04/22 13:47 # 삭제 답글

    한줄한줄 새기면서 읽었습니다. 좋은 정리 감사드립니다.^^
  • 알콜코더 2010/04/22 14:53 # 삭제 답글

    오옷. 좋은 리뷰 감사합니다. ^^ 저도 갔으면 좋을것을.. 아쉽네요.. T^T
    (하는지도 몰랐어요..T^T)
  • 박PD 2010/04/22 16:01 # 답글

    drvoss, 청하, 알콜코더 : 고민하면서 직접 적용한 사례를 들으니 배울 게 많더군요.
  • 이동인 2010/04/22 17:31 # 삭제 답글

    오 정리가 정말 잘 되어 있습니다.
    같은 세미나를 들어도 받아들이는 정보의 양이 꽤 차이가 나는 군요.
    후기 잘 읽었습니다. 세미나를 다시한번 듣는 것 같아서 좋았습니다.
  • 박PD 2010/04/22 17:53 #

    동인님 후기를 트랙백 걸고 싶은데, 안 되네요. 링크로만 남깁니다. 좋은 후기 남겨주셔서 감사합니다.
  • WSID 2010/04/22 20:45 # 답글

    잠깐 머리를 식히기 위해 밸리를 돌다가 좋은 글을 읽었습니다.

    글 잘 보고 갑니다. ^^;;;
  • 박PD 2010/04/23 00:09 #

    감사합니다. :)
  • ohyecloudy 2010/04/23 00:57 # 답글

    우왕 형 나이스. 내가 직접 가서 들은 것 같네. 이런 발표 있으면 안 가고 술 먹으면서 형한테 캐내도 되겠다.
  • 박PD 2010/04/23 11:12 #

    너도 발표 보면서 너만의 생각을 얘기해줘야지 :)
  • Aiba 2010/04/23 14:58 # 답글

    오늘도 역시 좋은글 잘보았습니다~! 공감가는 내용이 너무많네요~
    퍼가도되나요? :)
  • 박PD 2010/04/23 20:34 #

    네, 퍼 가세요.
  • 레몬에이드 2010/04/23 15:50 # 삭제 답글

    직접 옆에서 듣는 것 같은 느낌이네요 ^^
    좋은 정리 잘 보았습니다

    박PD님 메모하시는거 저번에 뵈었을 때 이후로 언뜻 따라해보았는데
    아직은 멀었다는 생각이 드네요 ㅎ 제게 맞도록 좀더 다듬어 봐야겠습니다
  • 박PD 2010/04/23 20:34 #

    제가 나중에 보려고 정리하는 거라서요 :)
  • 장정화 2010/04/26 21:07 # 삭제 답글

    와우~ 대단하세요~ 어떻게 이렇게 정리가 완벽할 수가... 정말 그날 세미나에서 제가 듣고 기억한 거의 몇배는 되는 것 같아요~ 존경합니다 ^^*
  • 박PD 2010/04/27 09:37 #

    안녕하세요. 정화님이 준비 잘 해 주셔서 좋은 자리 가질 수 있었습니다. 감사합니다. :)
  • 앨리 2012/04/02 14:58 # 삭제 답글

    L사 자료 링크 깨졌어요. 젤 궁금했는데.
  • 박PD 2012/04/05 09:29 #

    링크 복구했습니다. 알려주셔서 감사합니다.
댓글 입력 영역


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2