2007년 11월 13일
Agile Process, SCRUM!!! 호기심 탐구 결과.
애자일 개발 프로세스로는, XP(eXtreme Programming)가 가장 유명한데요.
XP말고도 스크럼이나 적응형 소프트웨어 개발 등의 많은 애자일 프로세스 기법들이 존재합니다.
XP외의 다른 애자일 프로세스는 접할 기회가 없었는데, 조동환씨를 통하여 에센스를 듣게 되었습니다.
그러면, 스크럼은 무엇일까요?
스크럼의 어원
스크럼이라는 이름은 럭비에서 나왔네요.
아래같은 공격진용의 8명이 공을 중심으로 둘러싸며 만들어지는 진용을 스크럼이라고 부릅니다.
스크럼의 탄생
스크럼의 생일은 1986년이고, 고향은 "Harvard Business Review"라는 잡지였습니다.
부모님은, 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로시고씨였으며,
태명은 "The New New Product Development Game"였습니다. (아래 상세 성명합니다.)
처음 목표는, 복사지/카메라/자동차등의 공업품의 개발이었으나,
1995년에 Ken Schwaber에 의하여 처음으로 소프트웨어 개발에 관련되기 시작했으며
ADM에 의하여, 스크럼이라는 이름으로 세상에 나오게 되었습니다.
IT개발의 불확실성...
스크럼은 특정 언어나 방법론에 의존적이지 않으며,
개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법입니다.
스크럼은 애자일 개발 프로세스의 하나인데요.
애자일 개발 프로세스는 폭포수 모델과 계획 기반 개발에 반하는 기법들의 모임을 이야기합니다.
<폭포수 모델 사진출처 : 모름>
이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만,
이로 인해서 많은 부작용도 생겼습니다.
가장 큰 부작용이, 계획대로 진행되지 않았을 경우에 나타나게 되었는데요.
결국,
- 납기일 전 철야
- 철야에도 불구하고 납기일 지연
- 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
- 결국 납기된 솔루션은 고객의 니즈를 충족하지 못하는
등등... 의 폐해를 낳게 되었습니다.
왜 이렇게 부작용을 낳게 되는 것일까???
공업의 정형적 프로세스 제어 모델에서는 동일한 입력에 대해서 동일한 결과를 기대할 수 있는데 반하여 IT의 개발은 경험적 프로세스 제어 모델을 가지게 되기 때문에 항상 불확실성을 수반할 수 밖에는 없습니다. 이러한 비극적인 부작용들은, 경험적 프로세스 제어모델의 IT개발을 정형적 프로세스 제어모델로 관리하여고 하는데 원인이 있습니다.
그렇다면 스크럼은?
스크럼(등의 애자일 프로세스)은, "계획은 변경된다.","개발은 미리 예상할 수 없다."는 사실을 솔찍하게 인정하면서 시작하게 됩니다. 스크럼의 몇가지 특징을 나열해 보면
- 솔루션에 포함될 기능/개선점에 대한 우선순위를 부여한다.
- 개발 주기는 30일정도로 조절하고 매 개발주기 마다 실제 동작가능한 결과를 제공해라
- 매 개발주기마다 적용될 기능이나 개선점의 리스트를 제공해라
- 매일 15분정도의 회의를 가져라
- 항상 팀 단위로 생각해라
- 원활한 커뮤니케이션을 위하여, 파티션이 없는 오픈스페이스를 유지해라
정도가 될것 입니다.
아래의 그림을 보시면 스크럼이 어떻게 흘러가는지 알 수 있을 것입니다.
가치있는 스크럼을 운영하려면???
이미 언급된 것 처럼, 스크럼은 애자일 개발 방법론 군에 포함됩니다.
이들은, "가치"를 전면에 내 세우면서 팀 문화를 공고히 하는 방법을 사용하는데요.
많이들 알고 계신 XP(eXtreme Programming)에서는 다음의 5가지 가치를 추구하고 있습니다.
스크럼이란, 자신의 과업과 관련된 것들을 비록 불리한 것 일지라도 숨기지 않고
용기를 가지고 실현될 수 있도록 전념하여 약속한 것을 실현시킴으로써,
존경받기 위한 방법론이라고 명확하게 이야기 하고 있습니다.
이것은, 스크럼이 태생적으로 프로젝트 관리 방법론이기 때문이랍니다.
스크럼의 프로젝트 관리는 어디에 기반하고 있나???
기존의 프로젝트 관리 방법론은, PMBOK(Project Management Body Of Knowledge)가 유명합니다.
PMBOK외에, PRINCE2(PRojects IN Controlled Environments)라는, 영국의 방법론도 유명한데요.
분명히, 이들의 방법론과 스크럼의 방법론에는 차이가 있습니다.
PMBOK와 PRINCE2는 차치하더라도, 스크럼은 어떠한 곳에 이론적 기반을 두고 있는 걸까요?
스크럼은, "지식창조기업(知識創造企業)"이라는 이름으로 소개된 일본의 조직론에 이론적 기반을 두고 있습니다. 지식창조기업에서는, 가정용 제빵기나 저가 복사기등을 획기적으로 개발한 일본 기업의 조직론을 소개합니다.
다음의 두가지가 획기적인 개발을 가능하게 했다고 설명하고 있네요..
여러 설명을 짧게 하느라 어려운 이야기가 되었습니다만, 3년전에 한참 붐이 있었던, "지식경영"에 기반하고 있는 것이 스크럼이라고 이해하셔도 무방할 것 같습니다.
스크럼은 어떻게 개발을 진행할까?
이런 저런 이야기를 위에서 나열했습니다만, 가장 궁금한것은 어떻게 진행하는 것인가 라는 것입니다.
스크럼은, 어떻게 진행하는 개발 방법론일까요? 먼저, 위의 그림을 다시 보겠습니다.
스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킵니다.
위의 그림은, 스크럼에 의한 개발 흐름을 나타낸 그림으로써, 내용은 아래와 같습니다.
1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. 제품 백 로그로부터 스플린트를 통해 구현되야할 목표를 선택한다.
3. 스플린트 목표를 보다 상세한 작업으로 모듈화한 스플린트 백 로그를 작성한 뒤 작업을 할당 한다.
4. 스플린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 미팅을 가진다.
5. 매회의 스플린트가 종료할 대마다, 스크럼 리뷰 미팅을 가지고, 개발된 제품을 평가한다.
6. 이후의 스플린트에 대비하여 제품 백로그의 내용과 우선순위를 재검토 한다.
아래 그림은, 제품 백로그에 대한 예시 템플릿입니다. 해당 도표는 조동환(티맥스 소프트)씨께서 번역중인 Agile Project Management with SCRUM의 베타번역판에서 가져왔으며, 조만간 "스크럼으로 애자일 프로젝트 관리하기"(가칭)라는 책으로 출간될 예정입니다.
제품 책임자는, 스플린트 골과 백로그등의 결정에 있어 중심이 되는 상위 관리자 입니다. 그렇다고 하여, 제품 책임자가 독단적으로 골을 결정하지는 않습니다. 고객과 관리자 및 팀원들이 모두 모여 정하게 됩니다.
이후, 개발 팀원들이 주도적으로 스플린트 골을 달성하기 위한 작업을 정해 나가게 됩니다. 보통, 각 작업들은 4시간(반나절)에서 16시간(이틀)정도 걸리도록 정해 집니다. 물론, 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행됩니다.
이와같은 자율적인 행위를 통해서 팀원들은 활발한 커뮤니케이션을 하게 되고 끈끈한 협업체계를 가지게 됩니다. 이러한 것을 자기조직화라고 볼 수 있겠는데요. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기조직화를 중요시 여기고 있습니다. 하지만, 이러한 부분 덕분에 애자일 프로세스는 전통적인 프로세스 개선과 마찰이 생기게 됩니다. 무질서해 보이기 때문이죠.
스플린트 골을 달성하기 위해 작성되고 각 골에 리스트업된 작업들의 집합이 스플린트 백 로그가 됩니다. 스플린트가 진행되는 동안, 스플린트 백 로그 작업의 진척상황을 팀원들과 공유함으로써 전체 작업 상황을 공유하게 됩니다.
아래 그림은, 스플린트 백 로그에 대한 예시 템플릿입니다. 해당 도표 또한, 조동환(티맥스 소프트)씨께서 번역중인 Agile Project Management with SCRUM의 베타번역판에서 가져왔습니다.
<그림 출처: 조동환씨의 Agile Project Management with SCRUM 베타번역판 내용 中 일부 발췌>
일일 스크럼 미팅은, 스플린트 기간중에 매일 같은 장소에서 같은 시간에 열리며 모든 팀원이 참가하는 회의입니다.
스크럼에서 무엇보다도 중요한 것은, 30일간의 스플린트 기간중에 개발에 전념할수 있는 환경을 제공해 주는 것입니다. 이를 위해서 스크럼 마스터는 외부의 압력 및 모든 장애 사항에 대해서 보호와 지원을 해줘야함은 물론이고, 스플린트 백 로그 작성 및 일일 스크럼 미팅에서 팀원 외의 사람들의 발제와 발언마저 막아줘야 합니다.
XP말고도 스크럼이나 적응형 소프트웨어 개발 등의 많은 애자일 프로세스 기법들이 존재합니다.
XP외의 다른 애자일 프로세스는 접할 기회가 없었는데, 조동환씨를 통하여 에센스를 듣게 되었습니다.
그러면, 스크럼은 무엇일까요?
스크럼의 어원
스크럼이라는 이름은 럭비에서 나왔네요.
아래같은 공격진용의 8명이 공을 중심으로 둘러싸며 만들어지는 진용을 스크럼이라고 부릅니다.
스크럼의 탄생
스크럼의 생일은 1986년이고, 고향은 "Harvard Business Review"라는 잡지였습니다.
부모님은, 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로시고씨였으며,
태명은 "The New New Product Development Game"였습니다. (아래 상세 성명합니다.)
처음 목표는, 복사지/카메라/자동차등의 공업품의 개발이었으나,
1995년에 Ken Schwaber에 의하여 처음으로 소프트웨어 개발에 관련되기 시작했으며
ADM에 의하여, 스크럼이라는 이름으로 세상에 나오게 되었습니다.
IT개발의 불확실성...
스크럼은 특정 언어나 방법론에 의존적이지 않으며,
개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법입니다.
스크럼은 애자일 개발 프로세스의 하나인데요.
애자일 개발 프로세스는 폭포수 모델과 계획 기반 개발에 반하는 기법들의 모임을 이야기합니다.
폭포수 모델과 계획 기반 개발 기법들은,
일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킵니다.
일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킵니다.
이로 인해서 많은 부작용도 생겼습니다.
가장 큰 부작용이, 계획대로 진행되지 않았을 경우에 나타나게 되었는데요.
결국,
- 납기일 전 철야
- 철야에도 불구하고 납기일 지연
- 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
- 결국 납기된 솔루션은 고객의 니즈를 충족하지 못하는
등등... 의 폐해를 낳게 되었습니다.
왜 이렇게 부작용을 낳게 되는 것일까???
공업의 정형적 프로세스 제어 모델에서는 동일한 입력에 대해서 동일한 결과를 기대할 수 있는데 반하여 IT의 개발은 경험적 프로세스 제어 모델을 가지게 되기 때문에 항상 불확실성을 수반할 수 밖에는 없습니다. 이러한 비극적인 부작용들은, 경험적 프로세스 제어모델의 IT개발을 정형적 프로세스 제어모델로 관리하여고 하는데 원인이 있습니다.
그렇다면 스크럼은?
스크럼(등의 애자일 프로세스)은, "계획은 변경된다.","개발은 미리 예상할 수 없다."는 사실을 솔찍하게 인정하면서 시작하게 됩니다. 스크럼의 몇가지 특징을 나열해 보면
- 솔루션에 포함될 기능/개선점에 대한 우선순위를 부여한다.
- 개발 주기는 30일정도로 조절하고 매 개발주기 마다 실제 동작가능한 결과를 제공해라
- 매 개발주기마다 적용될 기능이나 개선점의 리스트를 제공해라
- 매일 15분정도의 회의를 가져라
- 항상 팀 단위로 생각해라
- 원활한 커뮤니케이션을 위하여, 파티션이 없는 오픈스페이스를 유지해라
정도가 될것 입니다.
아래의 그림을 보시면 스크럼이 어떻게 흘러가는지 알 수 있을 것입니다.
<사진 : 스크럼의 개발 공정 (http://www.controlchaos.com/about/)>
가치있는 스크럼을 운영하려면???
이미 언급된 것 처럼, 스크럼은 애자일 개발 방법론 군에 포함됩니다.
이들은, "가치"를 전면에 내 세우면서 팀 문화를 공고히 하는 방법을 사용하는데요.
많이들 알고 계신 XP(eXtreme Programming)에서는 다음의 5가지 가치를 추구하고 있습니다.
- 의사소통 : 대화하고 함께 일하기
- 단순성 : 불필요하거나 덜 중요한 작업, 요구사항, 설계 제거
- 존중 : 같이 일하는 사람을 존중하기, 자신의 프로젝트를 존중하기
- 피드백 : 자주 빨리 보여주고 의견을 수렴
- 용기 : 의사소통,단순성,피드백을 수행할 용기
- 확약 : 약속한 것을 확실히 실현되는 것
- 전념 : 확약한 것의 실현에 전념하는 것
- 숨기지 않음 : 비록 자신에게 있어서 불리한 일에서도 숨기지 않는 것
- 존중 : 자신과 다른 사람에게 경의를 표하는 것
- 용기 : 확약해, 숨기지 않고, 경의를 표하기 위해서 용기를 가지는 것
스크럼이란, 자신의 과업과 관련된 것들을 비록 불리한 것 일지라도 숨기지 않고
용기를 가지고 실현될 수 있도록 전념하여 약속한 것을 실현시킴으로써,
존경받기 위한 방법론이라고 명확하게 이야기 하고 있습니다.
이것은, 스크럼이 태생적으로 프로젝트 관리 방법론이기 때문이랍니다.
스크럼의 프로젝트 관리는 어디에 기반하고 있나???
기존의 프로젝트 관리 방법론은, PMBOK(Project Management Body Of Knowledge)가 유명합니다.
PMBOK외에, PRINCE2(PRojects IN Controlled Environments)라는, 영국의 방법론도 유명한데요.
분명히, 이들의 방법론과 스크럼의 방법론에는 차이가 있습니다.
PMBOK와 PRINCE2는 차치하더라도, 스크럼은 어떠한 곳에 이론적 기반을 두고 있는 걸까요?
스크럼은, "지식창조기업(知識創造企業)"이라는 이름으로 소개된 일본의 조직론에 이론적 기반을 두고 있습니다. 지식창조기업에서는, 가정용 제빵기나 저가 복사기등을 획기적으로 개발한 일본 기업의 조직론을 소개합니다.
다음의 두가지가 획기적인 개발을 가능하게 했다고 설명하고 있네요..
- 지식 변환에 근거하는 지식 창조 프로세스
- 지식창조기업에서는, 암묵지와 형식지를 상호 변환할 수 있는 프로세스를 가지고 그에 따라 새로운 지식을 창출해 낸다. - 지식 창조 프로세스를 촉진시키는 5가지 요소
- 조직의 의도 : 지식 창조의 목표나 팀을 지탱하는 축
- 자율성 : 팀의 멤버에게 자유로운 행동을 인정하는 열린 환경(시스템)
- 역동적이고 창조적인 카오스 : 조직 내 외부 간의 역동적인 상호작용을 통한 지식창조 환경
- 잉여성 : 의도적으로 조직에 넘쳐나는 여분의 정보
- 최소 유효 다양성 : 복잡하고 다양한 환경에 기민하게 대응하기 위해서는 조직 구성원이 가져야 하는 다양성
여러 설명을 짧게 하느라 어려운 이야기가 되었습니다만, 3년전에 한참 붐이 있었던, "지식경영"에 기반하고 있는 것이 스크럼이라고 이해하셔도 무방할 것 같습니다.
지식은 단지 개인만이 창조할 수 있을 뿐이다.
스크럼은 어떻게 개발을 진행할까?
이런 저런 이야기를 위에서 나열했습니다만, 가장 궁금한것은 어떻게 진행하는 것인가 라는 것입니다.
스크럼은, 어떻게 진행하는 개발 방법론일까요? 먼저, 위의 그림을 다시 보겠습니다.
<사진 : 스크럼의 개발 공정 (http://www.controlchaos.com/about/)>
스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킵니다.
위의 그림은, 스크럼에 의한 개발 흐름을 나타낸 그림으로써, 내용은 아래와 같습니다.
- 제품 백로그 : 개발하려는 제품에 대한 요구사항 목록
- 스플린트 : 30일의 반복적인 개발 주기
- 스플린트 계획 미팅 : 스플린트 목표와 스플린트 백로그를 계획하는 미팅
- 스플린트 백로그 : 각각의 스플린트 목표에 도달하기 위해 필요한 작업 목록
- 일일 스크럼 미팅 : 매일 진행되는 진척상황 미팅
- 실행가능한 제품 개발 : 스플린트의 결과로써 나오게되는 실행가능한 제품
1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. 제품 백 로그로부터 스플린트를 통해 구현되야할 목표를 선택한다.
3. 스플린트 목표를 보다 상세한 작업으로 모듈화한 스플린트 백 로그를 작성한 뒤 작업을 할당 한다.
4. 스플린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 미팅을 가진다.
5. 매회의 스플린트가 종료할 대마다, 스크럼 리뷰 미팅을 가지고, 개발된 제품을 평가한다.
6. 이후의 스플린트에 대비하여 제품 백로그의 내용과 우선순위를 재검토 한다.
아래 그림은, 제품 백로그에 대한 예시 템플릿입니다. 해당 도표는 조동환(티맥스 소프트)씨께서 번역중인 Agile Project Management with SCRUM의 베타번역판에서 가져왔으며, 조만간 "스크럼으로 애자일 프로젝트 관리하기"(가칭)라는 책으로 출간될 예정입니다.
<그림 출처: 조동환씨의 Agile Project Management with SCRUM 베타번역판 내용 中 일부 발췌>
제품 책임자: 제품 백 로그를 정의해, 우선순위를 정해줍니다.스크럼 마스터는, 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 합니다.
스크럼 마스터: 프로젝트 관리자(코치)
제품 책임자는, 스플린트 골과 백로그등의 결정에 있어 중심이 되는 상위 관리자 입니다. 그렇다고 하여, 제품 책임자가 독단적으로 골을 결정하지는 않습니다. 고객과 관리자 및 팀원들이 모두 모여 정하게 됩니다.
이후, 개발 팀원들이 주도적으로 스플린트 골을 달성하기 위한 작업을 정해 나가게 됩니다. 보통, 각 작업들은 4시간(반나절)에서 16시간(이틀)정도 걸리도록 정해 집니다. 물론, 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행됩니다.
이와같은 자율적인 행위를 통해서 팀원들은 활발한 커뮤니케이션을 하게 되고 끈끈한 협업체계를 가지게 됩니다. 이러한 것을 자기조직화라고 볼 수 있겠는데요. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기조직화를 중요시 여기고 있습니다. 하지만, 이러한 부분 덕분에 애자일 프로세스는 전통적인 프로세스 개선과 마찰이 생기게 됩니다. 무질서해 보이기 때문이죠.
스플린트 골을 달성하기 위해 작성되고 각 골에 리스트업된 작업들의 집합이 스플린트 백 로그가 됩니다. 스플린트가 진행되는 동안, 스플린트 백 로그 작업의 진척상황을 팀원들과 공유함으로써 전체 작업 상황을 공유하게 됩니다.
아래 그림은, 스플린트 백 로그에 대한 예시 템플릿입니다. 해당 도표 또한, 조동환(티맥스 소프트)씨께서 번역중인 Agile Project Management with SCRUM의 베타번역판에서 가져왔습니다.
일일 스크럼 미팅은, 스플린트 기간중에 매일 같은 장소에서 같은 시간에 열리며 모든 팀원이 참가하는 회의입니다.
일일 스크럼 미팅에서 스크럼 마스터가 팀원에게 하는 질문일일 스크럼 미팅은, 팀원들간의 커뮤니케이션을 촉진시킴과 동시에 팀원 모두가 프로젝트의 상태를 공유하여 팀의 결속력을 다지는 효과를 줍니다. 스크럼 마스터는 장애/문제 사항을 해결해주도록 하고요. 일일 스크럼 미팅은, 스크럼의 지식창조 프로세스에 핵심적인 부분입니다.
1. 지난번 일일 스크럼 미팅에서부터 지금까지의 작업내용
2. 다음번 일일 스크럼 미팅때까지의 예정 작업내용
3. 작업을 하는데 있어서 장애/문제되는 사항
스크럼에서 무엇보다도 중요한 것은, 30일간의 스플린트 기간중에 개발에 전념할수 있는 환경을 제공해 주는 것입니다. 이를 위해서 스크럼 마스터는 외부의 압력 및 모든 장애 사항에 대해서 보호와 지원을 해줘야함은 물론이고, 스플린트 백 로그 작성 및 일일 스크럼 미팅에서 팀원 외의 사람들의 발제와 발언마저 막아줘야 합니다.
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
- 스크럼의 핵심, 코칭. by YUZI
- 한 실천자가 말하는 스크럼과 프로젝트 관리 by 조동환
- 애자일 by 황구
- 부록A: 규칙 by 조동환
- 애자일 프랙티스 by 어플로잇
# by | 2007/11/13 13:29 | 애자일 방법론 | 트랙백(3) | 핑백(5) | 덧글(6)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : 한 실천자가 말하는 스크럼과 프로젝트 관리
매일 스크럼을 활용하여 프로젝트를 운영해 나가면서 느끼게 되는 점들이 있습니다. 전반적인 관점에서 보면 스크럼을 제대로 적용하고 있느냐 나아가 스크럼이나 애자일프로세스를 사용하고 있느냐는 크게 문제가 아닐 수 있습니다. 프로젝트의 방향타를 잡고 있는 선장과 그 배를 실제로 움직이는 선원들이 얼마나 하나로 뭉쳐져 있느냐, 일을 통해 얼마나 즐거움을 느끼느냐(일하는 분위기가 즐거운 것일수도 있지만 매일매일 발전하는 스스로를 볼 때 느끼는 자부......more
제목 : 스크럼(Scrum) 회의 - 컨퍼런스콜
스크럼(Scrum) 회의 - 컨퍼런스콜 애자일(Agile) 법론 중에 가장 가벼워 보이는 극단적인 방법론으로 스크럼(Scrum)이 있습니다. 단순함과 실천의 용이함 때문에 이 방법을 꼭 적용해 봐야겠다 맘을 먹고 있었는......more
제목 : 우리 팀에 스크럼을 적용했어요 - 1편
은근 슬쩍 시작하기 나와 아주 친한 연구원(L씨)는 니코틴 충전시간을 활용하여 현재 우리 팀의 문제점에 대해 고민하였다. 우리 팀은 전형적인 한국의 개발팀과 대동소이했다. BMT 준비로 인한 잦은 밤샘 빈번히 변경되는 요구사항 유지보수 지원으로 인한 신규 프로젝트 지연 그와중에 알게된 해결책 중의 하나가 스크럼이었다. 방법은 매우 단순 했다. (스크럼에 대한 자세한 설명은 구글신 혹은 네이버횽에게 여쭤보시길^^;;) 우리는 금방이라도 팀에 적용......more
... 애자일 프로세스(Agile Process)에는, XP(eXtreme Programming)말고도 스크럼(Scrum)이라는 것이 있습니다. 저는, 스크럼을 프로젝트 관리(Project Management) 기법으로 생각하는데요. 스크럼은, 팀원 ... more
... bsp; 로그인 http://me2day.net/ 암호 로그인 유지 미투 가입하고 새로운 친구를! ← 2008년 4월 1 1 Apr 2008 0 metoo 나도 이제 애자일방법론으로 일을 하게 되는구나. 잘 돼야 할텐데. 오후 5시 49분 스크럼 댓글 (0) 0 metoo 진중권씨가 경비행기를 모나보다. 이 글을 보니 경비행기 운전 같이 배우러 다니 ... more
... 프로젝트의 Deadline이 명확하지 못하다는 문제점이 있습니다. 설명을 들어보니, 스크럼(Scrum)을 도입하여 사용하고 있으며, 자세한 내용은 여기서 설명하는 것보다, 기존의 스크럼 관련글[링크] 를 참조하시는게 좋겠네요. 특별히 중요한 얘기는 없었으니까요. 강사는 Agile 프로젝트의 성공 요건은 Self-Organizing team (자기조직화)에 있다고 보더군 ... more
... ) Wordle - Beautiful Word Clouds (tags: visualization cloud design typography) YUZI, in Ma Mind : Agile Process, SCRUM!!! 호기심 탐구 결과. (tags: scrum agile development) Posted by gauloz Filed in Uncategorized Le ... more
... 거 같다 해서… VSTS 도 받고 TFS도 받고 실행은… 다음주에 짬내서 하면 되는데 얼마전부터 눈에 밟혔던 Scrum 이란게 뭔지 좀 찾다보니 Yuzi 님의 포스트가 눈에 띈다 스크럼에 대한 소개, 핵심 개발자 입장에서 본다면 고객의 요구사항은 항상 변할 수 있다는걸 언급해주는 것만으로도 고맙고 상호간의 소통을 중요시하는 개념이 특히나 맘에든다 그리고 팀장 입장에서 ... more
먼저 조동환씨께 연락드려서 의사를 여쭤보고 이메일로 답변을 드리겠습니다.
시간이 가능하시면, 오프라인으로 먼저 만나고 연락을 틔우는 것도 좋을 것 같습니다.
조동환씨께 물어보고, 주선해볼까요?
저작자는 YUZI로 적어 주시면 됩니다.