Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Copy of 스크럼 기반 Agile 프로젝트 실습

교육 내용 발표
by

Cho Tom

on 20 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Copy of 스크럼 기반 Agile 프로젝트 실습

Q & A Photo based on: 'horizon' by pierreyves @ flickr Why?
애자일 개발 절차 애자일 소개
특정한 개발방법론이 아니다 소프트웨어 개발 생산성과 품질 향상을 위하여 개발자의 잠재력 발휘와 개발팀의 협업 최적화를 최우선시 한다

소프트웨어 개발 팀원들을 고무하는, 협력적 개발 접근 방법

“Agile”이란 개발과정에서의 시스템의 변경사항을 유연하게 또는 기민하게 대응할 수 있도록 방법론을 제공한다는 것을 의미함.



실패한 메타포 소프트웨어 개발과 유사한 직종- 작가

작가의 부인이 전혀 이해할 수 없는 것은 작가가 창밖을 응시하고 있을 때 작가가 일하고 있다는 점이다 애자일 선언 프로세스나 도구에 앞서 개인과 상호 협력을

포괄적인 문서화에 앞서 작동하는 소프트웨어를

계약 협상에 앞서 고객과의 협력을

계획 준수에 앞서 변화에 대한 대응을 애자일 방법론의 핵심 가치

용기,자신감
단순성
의사소통
피드백
존중
자발적 헌신
집중 고객 참여 -> 계약 협상에 앞서 고객과의 협력
프로세스보다 사람 -> 프로세스나 도구에 앞서 개인과 상호 협력
변경을 포용 -> 계획 준수에 앞서 변화에 대한 대응
단순함을 유지 ->
소프트웨어 중심->포괄적인 문서화에 앞서 작동하는 소프트 웨어
반복적 릴리스 -> 애자일과 전통적인 개발 방법론의 다른 차이점, 특징
애자일 개발 절차 스크럼 소개 스크럼의 진행 스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 아래는 스크럼 진행시 나타나는 중요 요소이다.

제품 백로그(Product Backlog) 개발할 제품에 대한 요구 사항 목록

스프린트(Sprint) 30일의 반복적인 개발 주기

스프린트 계획 회의(Sprint Planning Meeting) 스프린트 목표와 스프린트 백로그를 계획하는 회의

스프린트 백로그(Sprint Backlog) 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

일일 스크럼 회의(Daily Scrum Meeting) 날마다 진행되는 진척 상황 미팅

실행 가능한 제품(shippable product) 개발 스프린트의 결과로써 나오는 실행 가능한 제품 1.제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.

2.제품 백로그로부터 스프린트를 통해 구현되야할 목표를 선택한다.

3.스프린트 목표를 보다 상세한 작업으로 모듈화한 스프린트 백로그를 작성한 뒤 작업을 할당한다.

4.스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.

5.매회의 스프린트가 종료할 때마다, 스크럼 리뷰 미팅을 가지고, 개발된 제품을 평가한다.

6.이후의 스프린트에 대비하여 제품 백로그의 내용과 우선순위를 재검토 한다.
스크럼 구성원 제품 책임자 Product owner
스크럼 마스터 Scrum master
스크럼 팀 Scrum team 사용자
고객
관리자 스프린트 관리 스크럼 보드 스프린트의 진행 소멸 차트 닭들은 닥치시고 스크럼에 관한 최초의 기술 이 프로세스는 대채로 관리자가 프로젝트 팀에게 대략적인 목표 를 부여하는 것으로 시작된다. 드물기는 하지만 명확한 제품 컨셉이나 세부적인 업무계획을 나누어 주기도 한다. 요컨대 프로젝트 팀은 극한의 자유를 갖고 있지만 그와 동시에 목표로 형상화된 극한의 도전에 직면하게 된다. 이도전으로 인해서 기존의 지식은 무용지물이 되고 팀은 무정보 상태에 빠지게 된다. 따라서 팀은 자력으로 생존하고 역동적인 조직으로 거듭날 방도를 찾아야 한다

우리가 조사한 몇몇 회사들에 따르면 이 프로세스는 엄청난 시행착오를 만들어 내는 경향이 있다.
그러나 이 시행 착오는 귀중한 학습 경험으로써 언제나 긍정적으로 받아들여 지게 됨
가장 중요한 사실은 이 혼란 스러운 프로세스가 기존의 순차적인 개발 프로세스 보다 훨씬 혁신적인 제품을 더 빨리 생산해 낸다는 점
또한 팀원들 간의 상호 작용을 통해서 각 개인의 지식을 폭 넓게 확장시킴으로써 팀원들은 능력을 갖춘 유능한 개발자로 성장하게 된다 방해 금지, 난입 금지, 잡상인 금지

제품 증분은 혼돈의 산물이다

스프린트를 완료 하기 위해 최선을 다한다

스프린트는 중단될 수 있다 애자일 개발 프로세스의 종류

•익스트림 프로그래밍(Extreem Programing, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

•스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

•크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.

•Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

•Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.

•익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.
제품 소유자 제품의 형태를 정의한다

릴리즈 날짜와 기능을 결정한다

제품의 수익에 대한 책임이 있다

시장의 가치에 따라 우선 순위를 결정한다

필요할떄마다 기능과 우선 순위를 조정한다

작업 결과를 승인/미승인으로 판단한다 스크럼 마스터 프로젝트의 표면상의 관리자이다

스크럼의 가치와 실행의 규정을 책임진다

장애물을 제거한다

팀의 전체 기능과 생산성을 확보 한다.

모든 역할과 활동들을 긴밀하게 협동하도록 하게 한다

외부의 방해에서 팀을 보호한다 스크럼의 성공을 책임진다
스크럼의 가치 실천법과 규칙들을 받아 들이로 실천하게 할 책임이 있다.
경영진에게는 팀의 입장을, 팀에게는 경영진의 입장을 대변한다.
팀리더, 프로젝트 리더 혹은 프로젝트 관리자가 스크럼 마스터 역할을 수행한다

여러가지 인성적 특성이 필요하다
팀에 필요한 것이 무엇인지 알고, 그것을 위해서 단호하게 행동해야 한다. 그러므로 누구나 스크럼 마스터로 적합한 것은 아니다

팀과 스프린트를 관리한다
스프린트 목표와 이전 일일 스크럼 회의에서의 예측을 바탕으로 예상 진도와 실제 진도를 비교한다.
팀의 속도를 측정하려고 노력한다.
스크럼팀과 스프린트를 계획, 진행한다.
관리자와 함께 진척도를 측정하고, 중요도가 낮은 백로그를 제거한다.

백로그를 관리한다
제품 소유자와 스크럼 팀과 함께 제품 백로그를 만든다
스프린트 백로그를 만든다 일일 스크럼 회의를 주관한다
일일 스크럼 회의에서 팀원이 하는 이야기를 주의 깊게 듣는다
해당 스프린트 동안 모든 일일 스크럼 회의를 주관하고 장애요소를 즉시 제거하고 결정이 신속하게 내려지도록 한다.

결정을 내린다
일일 스크럼 회의에서 어떤 결정을 내려야 할 필요가 있다면, 스크럼 마스터는 즉시 결정을 내릴 책임이 있다.
결정을 내리면 언제든지 나중에 번복할 수 있다.
아무 결정을 내리지 않는 것 보다 어떤 결정이든 내리는 것이 중요하다

"팀의 작업은 계속 되어야 한다. 최악의 결정은 틀린 결정이 아니라 느린 결정이다."

장애물 제거

스크럼 마스터는 장애물에 대한 챋임을 맡아 장애물 제거를 위해 모두와 함께 작업해야 하는 책임을 진다.
스크럼 마스터는 민첩하게 장애물을 제거하기 위해서 자신이 어느정도의 권한을 갖고 있는지 알고 있어야 한다
일일 스크럼 회의에서 나누는 대화를 주의 깊게 듣고 그 내용에 대해 고민해야 한다. 이를 통해 사람들이 모두 당연한 것으로 받아들이는 장애물을 찾아낼 수 있다.
세심한 관찰로 인한 장애물 제거는 팀을 생산적으로 변화 시킨다. 스크럼은 변화를 불러 일으 킨다 훨씬 높은 생산성
경쟁력있는 릴리즈를 꾸준히 내놓을수 있다
스스로 점진적으로 혁신할 수 있다.
조직의 생산성 증가를 위한 기회를 제공한다

"스크럼 마스터 중심의 장애물 제거는 담당하는 스크럼 팀의 생산성을 높이며 상황에 따라서는 조직(회사)의 생산성을 높일 수 있다" 장예물 예제 장애물 1
상황
소프트웨어의 라이브러리 구매 신청을 했으나 처리가 늦어져 4일 간이나 기다렸다. 이로 인해 이 기간동안 중요한 개발이 늦춰졌다
해결
스크럼 마스터는 즉시 연락해 필요한 라이브러리를 구매해서 장애물을 제거 했다

장애물 2
상황
새로운 개발자가 투입이 되었지만 1년 전 장비 스펙을 그대로 사용해서 구식의 사양 그대로 장비와 소프트웨어를 제공했다
개발자들은 좁은 15인치 모니터에 여러 윈도우를 열어 놓고 개발 하고 있었다.
타 회사 개발자는 두개의 워크스테이션을 동시에 사용하고 있었다.
이로 인하여 사무실 공간이 부족하게 되었고 개발자들은 의욕저하를 느끼고 있었다.
해결
스크럼 마스터는 근본원인을 찾아 납품 벤더와 계약을 변경하여 20인치 모니터로 교체했다.
또한 스크럼 마스터는 관리팀과 싸워 최신 사양으로 워크스테이션을 바꾸고 필요한 경우 직접 사양을 선택할 수 있게 하였다 장애물 3
상황
팀원들은 '동료 평가'보고서 때문에 일에 집중하지 못하고 있었다.
해결
스크럼 마스터는 경영진에 스프린트가 끝날때 까지 동료평가 작업을 미뤄 달라고 요청하고 팀을 다시 프로젝트 작업으로 끌고 왔다.

장애물 4
상황
스크럼 마스터는 팀원들이 일일 스크럼 회의를 할때, 커피 자판기를 이용하기 위해 잔돈을 세는 것을 자주 목격했다. 어떤 팀원들은 잔돈을 구하려고 근무시간에 편의점에 가는 것도 보았다.
해결
스크럼 마스터는 시설 관리 부서에 찾아가 팀원들에게 커피를 제공해 달라고 요구했다.
공짜 커피가 회사에 들어오고 팀원들은 스프린트에 집중할 수 있게됐다.
스크럼 팀

7(5 ~ 9) 명으로 구성된다

모든 팀원이 모든 역할 ( 분석/설계/구현/테스트)를 수행한다

공약을 지키기 위해 헌신하고 필요한 모든 권한을 가진다.

스크럼은 500명 이상의 사람이 참여한 프로젝트에서 사용된 적이 있다

팀의 크기 조정 요소
어플리케이션 형태
팀 크기
팀의 분산도
프로젝트 기술
일일 스크럼 회의 매일 15분 스탠드 미팅

3가지 질문에 대한 답
어제 무슨 일을 했는가
오늘 무슨 일을 할 것 인가
현재 무슨 문제가 있는가 의사 소통의 장
의사 소통을 향상 시키고 다른 불필요한 회의를 줄여주며 개발의 장애물을 식별/제거하고 신속한 의사 결정을 부각/ 촉진 시켜 모든 사람이 프로젝트를 충분히 이해하게 한다.

문제 해결의 장이 아니다
프로젝트 관계자는 모두 참석할 수 있다.
돼지만 발언권을 가진다.

"업무 보고"의 장이 아니다.

설계 변경이나 작업 회의가 아니다. 회의 범위를 제한해서 시간이 늘어나는 것을 방지 한다. 설계 변경이나 작업 회의는 필요시 따로 계획을 잡는다 스프린트 계획 팀원 모두가 참여한다

마인드 스토밍, 플래닝 포커 Etc.. 스프린트 검토 팀은 스프린트 동안 만든 것을 보여 준다

기본적인 데모 형태는 새로운 기능이나 아키텍처의 밑 부분을 보여주는 것이다.

무형식
2시간 정도 진행
쓸데없이 프리젠테이션 자료를 준비 하지 않는다

팀 전체가 참여 한다
스크럼 마스터
제품 소유자

고객 및 이해 관계자
산출물 스프린트 백로그, 소멸 차트, Etc.. Bye bye~ 스크럼 기반 애자일 프로젝트 실습 교육 발표 자료
Full transcript