scrum add 3 - andstudy/forge GitHub Wiki

'매스이펙트'로 살펴보는 스크럼 개발론

• 바이오웨어 고든 왈튼(Gordon Walton), KGC 2007 강연

• 발표내용 정리

  • 스크럼의 핵심은 팀원들의 주인의식, 팀원들은 서로에게 헌신적이어야 함
  • 스크럼의 가장 큰 문제는 경영진을 설득하는 것
    • 경영진은 맥주 살 돈을 가지고 샴페인을 사기도 한다.
    • 현재 가용 리소르를 가지고 언제까지 이걸 완수하라는 주문
    • 경영진의 도전과제 : 스크럼을 통해서 투자한 만큼의 결과가 나오게 하는 것

• Q&A

  • 스크럼에서는 팀의 공동 주인의식이 필요하다. 이럴 때 각 직업군 사이에서 의견 충돌이 잦아질 텐데 어떻게 조율해야 하나?

    • 창의적인 긴장. 주인의식을 가져야 최고의 결과물이 나올 수 있으므로 긴장도 필요함.
    • 한 사람이 결과물을 책임지지 않고 팀이 결과물을 책임진다.
    • 팀의 문제로 보고 팀의 성공을 위한 해결책을 찾음

  • 20명이 안 되는 인원들이 4~5개의 스크럼을 진행하는데 여러 스크럼에 중복 참여하는 인원이 있다. 이럴 경우 혼란이 발생한다는데..

    • 특별한 스킬이 있어서 다른 팀이 모두 필요로 할 지라도 두 개를 넘는 스크럼에 참여하지 않는 것이 좋다.

  • 참여 스크럼이 적을 때는 인력의 낭비가 발생한다. 이걸 막는 방법은?

    • 스크럼의 운영에서 스프린트보다 백로그가 더 커야함
    • 스크럼 팀의 구성원은 최소한 두 분야의 스킬을 보유해야 함. 최대한 그렇게 함.

  • MMORPG의 경우 복합적인 유저 스토리를 가져야 하는 경우가 있는데 서로 관계성을 가지게 되는 경우가 있다. 이때 하나가 전체 프로세스에 영향을 줄 경우가 발생하는데 어떻게 해결?

    • 필요한 업무 프로세스에 최적의 스크럼 팀을 운영하는 것을 중요시함
    • 백로그가 달라지면 팀원도 달라지고 프로덕트 오너도 달라질 수 있음
    • 처음에 상호 의존성을 최대한 낮추는 방식으로 스크럼을 잘 짜야 함

게임 개발에 Scrum을 도입하다 (Game Development Enters the Scrum)

• High Moon Studios, Clinton Keith, 2005년 Game Daily와 인터뷰, 번역 김기웅님

• 제품 개발에 있어서 애자일 접근법의 핵심

  • 기존의 방법론의 문제점은 프로젝트가 끝날 때까지 게임이 어떤 형태가 될지 알 수 없음
  • 다음에 해야 할 것을 끊임없이 계획함으로써, 게임을 반복적으로 개발하고, 결과에 대응

• 스크럼은 매일의 실제 업무 능률이 어느 정도인가를 보여주는 경험적인 시스템

  • Sprint가 제품 가치의 증가를 위한 것이지, 완료된 과업의 숫자를 말하는 것이 아님

• 스크럼 적용에 가장 어려운 부분

  • 명령하고 통제하는 관리 문화로부터, 팀의 주인 정신을 강조하는 주기적인 문화로 전환시키는 것
    • 팀장 : 팀원들에게 한 번에 30일 동안 스스로 자신들의 목표와 과업에 대한 통제권을 부여
    • 팀원 : 스크럼이 요구하는 헌신과 주인 정신의 수준과 관련해서 책임감을 갖는다는 것

스크럼 적용 사례

• 마이에트 엔터테인먼트, 남기룡님

• 도입 (2006.11 ~ )

  • 스크럼 팀원 10명 (프로그래머만)
  • 스프린트 기간 : 한달
  • 디렉터가 고객의 역할을 담당
  • 적용 사항
    • 스프린트 계획 회의, 일일 스크럼, 매주 월요일(Iteration) 스토리 검토 및 짧은 시연, 스프린트 검토
  • 어려운 점
    • 리더를 포함 팀원 모두 애자일 개발에 미숙
    • 추정치 산출이 쉽지 않음
    • 스크럼 팀이 프로그래머로만 구성되어 제한이 많다. 기획자, 아티스트의 참여 부재
    • 고객 역할자의 스토리 완료에 대한 평가가 미약함
    • 완료된 스토리를 재작업하는 일이 빈번함
    • 팀원들의 참여 의지
    • 소통의 문제

• 중간(2007. 5 ~)

  • 작업 관리 프로세스는 어느 정도 정착
    • 스크럼 일일 회의에 디렉터, 아트디렉터, 그래픽팀 팀장이 참여. 업무 흐름이 좋아짐
    • 유닛 테스트 도입, 짝 프로그래밍 실시, 일일 회의 지각시 벌칙, 위키로 버그 리스트 관리
  • 일정을 맞추는 것이 쉽지 않음
    • 작업 시간 추정이 여전히 힘들고, 생각지 못한 일이나 중간 변경이 예상보다 많음
    • 일정을 맞추기 위해 초과 근무하는 경우가 발생
  • 개인적인 관리 비용을 줄이려고 노력
    • 자동화할 수 있는 것은 최대한 자동화

• 최근

  • 스크럼 상황
    • 아침 일일 회의 등 잘 운영되고 있음
    • 스프린트 주기를 2주로
    • 좀 더 타이트한 느낌이고 일정 추정도 훨씬 수월함
    • 추정 능력도 조금씩 좋아지고 있음
    • 팀원들끼리 의견을 많이 나누니까 훨씬 현실적으로 추정하게 되는 것 같음
  • 유닛 테스트 적용 확대
    • 여전히 버그는 많지만, 주로 테스트 코드가 없는 부분에서 나옴
  • 가장 큰 도움이 되었던 것
    • 아침 일일 회의, 빌드 및 테스트 자동화, 유닛 테스트 만들기
  • 아쉬운 점
    • 스프린트 마지막 평가
    • 결과가 좋지 않아도 다음에 잘 하면 되지
    • 긴 회의 시간
    • 스프린트 처음 추정(4시간), 스프린트 마지막 평가(1~2시간), 첫 이터레이션 정리(1시간), 매일 아침(10분), 오후(5분)
    • 새로 들어온 팀원에게 팀의 개발 문화나 테스트 코드 작성 등을 이해시키는데 어려움

• 스크럼 마스터 뿐만 아니라 팀원들의 참여 의지 및 주인정신도 중요

• 방법론은 방법론일 뿐

  • 스크럼이라는 틀을 그대로 적용하기 보다는 팀에 맞는, 팀에 필요한 부분만을 취하여 적용하는게 효과적일듯...