진척률 98.1%의 전설을 아시나요. 프로젝트 초반에는 10%, 20% 순조롭게 가던 진척률이 프로젝트 막판에는 98.1%, 98.2% 이런 식으로 진척률이 진행됩니다.
도대체 0.1% 진척향상이 뭘 의미하고 이렇게 되는 이유가 뭘까요? 제가 경험한 바로는 프로젝트 막판에 더 열심히 일(야근, 밤샘)을 하던데... 갑자기 생산성이 급락하는 이유가 뭘까요?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

애자일 추정에서 많이 사용하는 플래닝 포커 사용법을 소개합니다. 애자일에서 추정은 매우 중요합니다. 추정은 단지 계획을 세우기 위해서만 이루어지는 활동은 아닙니다. 플래닝 포커를 이용한 추정을 통해 어떤 효과가 있는지 알아보도록 하겠습니다.

플래닝 포커 구성

---

점수(0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, 무한대, 커피)가 표기된 4벌의 카드로 구성되어 있습니다. 점수는 많이 사용하는 피보나치 수열을 이용합니다.


플래닝 포커

---

1. 모든 사람들은 카드를 한 벌씩 나누어 가집니다.
모든 팀원들이 같이 추정을 합니다. PM이나 스크럼 마스터 혼자 추정하는 것은 의미 없습니다. 모든 팀원이 같이 추정함으로써 작업에 대한 이해를 공유할 수 있습니다. 기억하십세요. 이해하기 전에는 추정할 수 없습니다.



2. 추정할 작업을 가장 잘 이해하는 사람이 작업에 대해 설명합니다.
보통 제품 소유자 (Product Owner)나 고객이 작업에 대해 추정이 가능한 만큼만 설명합니다. 대략적인 기능의 목적과 내용을 설명합니다.



3. 다른 사람들은 추정을 위해 필요한 질문을 하고 의논을 합니다.
추정하는 사람들은 구현하기 위해 확인할 내용을 질문합니다. 주로 제품 소유자나 고객이 답을 하겠지만 누구라도 질문에 대한 답을 할 수 있습니다.

팀원1: 이 작업의 키워드 검색기능의 범위가 어떻게 되나요? 자연어 검색도 되어야 하나요?
고객: 자연어 검색까지는 필요하지 않습니다. 키워드로 제목과 본문내용이 검색되는 수준이면            충분합니다.
팀원2: 검색을 위해 검색엔진 구현이 필요한 부분일까요?
팀원3: 우리는 이미 사용할 수 있는 검색엔진이 있습니다. 검색엔진 구입이나 구현은 필요없어요.

4. 질문이 끝나면 각자 자신이 추정한 점수를 보이지 않게 내려 놓습니다. 그리고 동시에 카드를 뒤집어 확인합니다.
모든 팀원들이 각자 자기가 이해한 수준에서 작업의 규모를 결정합니다. 다른 사람의 눈치를 볼 필요는 없습니다.



5. 모두 같은 점수가 나오면 그 점수로 작업의 점수를 결정합니다.
한 번에 동일한 점수가 나오지 않는 경우도 많습니다. 그런 경우 다음 단계로 이동합니다.



6. 가장 낮은 점수 또는 가장 높은 점수를 제시한 사람부터 그 점수를 제시한 이유를 설명합니다.
예를 들어 모두 3점을 제시했는데 누군가 1점을 제시했다면 다른 사람이 모르는 중요한 정보를 알고 있을 가능성이 있습니다. 반대의 경우 아무도 모르는 작업의 위험을 알고 있는 사람이 있을 수도 있습니다.



7. 모든 사람이 자신이 제시한 점수에 대해 논의한 후 다시 점수를 제시합니다.
모든 사람이 자신의 점수를 제시한 이유를 논의함으로써 작업에 대한 이해를 공유할 수 있습니다. 이 때 제품 소유자나 고객이 작업에 대한 중요한 의사결정을 내릴 수도 있습니다. 이 대 작업카드에 그 내용을 기입해 둘 수 있습니다.

팀원1: 로그인을 하지 않은 상태에서 장바구니의 내용을 다시 접속할 때 기억하려면 특별한 장치가 필요합니다. 이를 위해서는 이틀의 시간이 더 필요합니다.
고객: 아 그렇다면 로그인을 한 상태에서만 장바구니 내용을 보관하도록 하죠.

8. 모두 동일한 점수를 제시할 때까지 반복합니다.
이런 과정을 통해 모두의 점수가 합의될때까지 반복합니다. 익숙해지면 보통 2~3회 반복으로 점수가 합의됩니다. 이러한 과정을 통해 작업의 내용을 더 구체화되고 공유됩니다. 이러한 의논을 통해 반드시 확인할 내용이 나오면 카드 뒷면에 테스트케이스로 기록해 둡니다.




플래닝 포커 Q&A

---

Q. 점수의 기준 어떻게 되나요?
A. 점수의 기준은 팀마다 다를 수 있습니다. 보통은 이상적인 작업시간(하루 8시간)을 기준으로 1점을 잡습니다.
    즉 다른 방해없이 집중해서 하루 8시간 작업에 투자하여 3일이 걸린다면 3점을 잡습니다.
    중요한 점은 점수 기준에 대한 일관성을 확보해야 한다는 점입니다.

Q. 그렇다면 2점은 반드시 이틀에 끝내야 하나요.
A. 이상적인 작업시간이라는 것을 기억하세요. 이상적인 팀에서 아무 방해없이 종일 몰입해서 한다면 2점은 이틀     에 끝나는게 맞겠지요. 그러나 그렇지 않은 경우가 많습니다. 2점이 3일 걸릴수도 있습니다. 그만큼 팀의 작업     집중도가 떨어지는 것이고 이는 팀의 속도에 반영됩니다. 자연스러운 현상입니다.
    점점 팀의 작업 집중도를 높여 속도를 높일 방법을 지속적으로 찾아보세요.

Q. 도저히 합의에 이르지 못할 때는 어떤 방법이 있나요?
A. 작업이 너무 애매해서 점수합의가 어려울 경우 지금까지 추정한 카드를 점수별로 분류하여 추정하려는 작업이     어느 작업과 가장 유사한 규모인지 비교해 보고 비슷한 작업의 점수로 결정합니다. 이를 삼각측량이라고 합니     다. 1, 2 점으로 너무 논쟁하지 마세요. 추정은 반복적이며 앞으로 재추정할 수 있는 기회는 많이 있습니다. 겨     우 1, 2 점이라고요.

Q. 개인의 역량에 따라 점수가 달라집니다.
A. 고참이 하면 1점인데 신참이 하면 3점인 작업이 있을 경우 고민됩니다. 누가하면 얼마나 걸릴지가 아니라 우리     팀이 하면 얼마나 걸릴지 추정해야 합니다. 즉 평균적인 속도로 추정하는 것이 좋습니다. 이런 경우 너무 고민     하지 말고 2점을 주세요.
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

많은 경우 프로젝트 실패의 원인을 요구사항 변경관리 실패에서 찾습니다. 그래서 프로젝트 초반 철저한 분석을 통해 요구사항을 확정하고 철저한 요구사항 변경프로세스로 함부로 요구사항변경을 하지 못하게 하는 경우 프로젝트가 성공하는지 생각해 보았습니다. 사실 이런 프로젝트가 현실에서 발견하기 어렵기 때문에 아래와 같이 사고실험을 해 봅니다.
(이미지출처)

어떤 프로젝트가...

---

6개월동안 모든 프로젝트 이해관계자가 정확한 일정관리와 빈틈없는 요구사항 관리로 프로젝트를 제때에 끝냈습니다. 프로젝트에 참여한 사람들의 회고입니다.

개발자

내게 주어진 업무를 정확하고 깔끔하게 제때 모두 끝냈것 같아. 자 봐 이렇게 완벽한 테스트케이스가 걸린 소스코드를 찾아보기란 쉽지 않을 거야. 게다가 소스코드는 누가 봐도 읽기 쉽게 깔끔하게 작성되었어. 내가 만든 소스코드 중 제일 맘에 들어.

설계자

내가 설계한 의도대로 구현까지 모두 완벽히 된 것 같아. 내가 설계한 업무에 논리적인 결함이나 빈틈이 없잖아. 게다가 업무가 어떻게 확장되든 충분히 대응할 수 있다고 봐. 하하. 이렇게 완결한 설계와 다양한 디자인 패턴을 적용한 경우는 처음이야. 다른 프로젝트에 참고자료로 쓰여도 손색이 없을거야.

아키텍트

고객이 요구한 보안이나 성능에 대한 요구사항은 충분히 만족시킨 것 같아. 고객이 예상한 사용자의 2배도 견디는 걸. 좀 사용하기 까다롭기는 하지만 시스템 접근에 대한 인증/인가도 충분해. 보안쪽이 뚫리기는 쉽지 않을거야. 만족해. 진짜 만족해

프로젝트 관리자

역시 철저한 일정관리와 요구사항 변경관리가 프로젝트 관리의 핵심이었어. 처음 계약한 대로 요구사항을 on-time에 모두 완결했어. 역시 프로젝트 관리가 내 적성인가봐. 회사에서도 이번 프로젝트로 수익이 좋게 나왔다고 좋아하는 걸...

고객

다행하게도 프로젝트는 비용넘지 않고 제 때 끝났네. 처음 그린 그림대로 잘 나온 것 같고. 그런데 처음 그린 그림대로 만들고 나니 뭔가 업무가 어색하게 돌아가네. 이런 이런 이건 현실과 좀 맞지 않은 부분이네.
그건 그렇고 오픈 한 지 한달이 넘는데 사용하는 사람이 거의 없네. 이거 핵심업무인데도 말이야. 뭐라고! 아직도 엑셀로 처리하고 있다고? 후~

모두가 각기 자신의 업무를 성공적으로 수행했고 프로젝트에 관여한 사람 모두 만족한 프로젝트입니다. 다만 고객만 좀 찜찜해 하는군요.
성공한 프로젝트 맞나요? 애매하니까 다수결로 성공했다고 치죠. -.-; 뭐가 문제인가요?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

세상이 계획대로 흘러가면 좋겠지만 항상 그렇지는 않습니다. 항상 제일 바쁠 때 일이 생기고 항상 급할 때 장애물이 발견됩니다. 우리 부서는 제품도 개발하고 제품 시연도 해야하고 특히 기술 지원도 해야 합니다.
제품 개발이야 정확한 추정에 따른 계획으로 진행되지만 기술지원 같은 것은 예상치 못한 때 발생합니다. 스크럼에서 팀원들이 업무에 집중할 수 없도록 방해하는 이런 것들을 퉁쳐서
"잡음(noise)"라고 하죠. (이미지출처)


내 인생의 방해물 노이즈

---

이처럼 계획을 망치는 잡음을 줄이는 책임은 스크럼마스터가 주로 담당합니다. 즉 스크럼마스터가 얼마나 업무 잡음을 줄이는가에 따라 프로젝트 계획(스프린트)들의 성공여부가 결정되는 경우가 많습니다.
스크럼마스터나 팀의 역량 그리고 상황에 따라 이런 잡음을 막느냐 못 막느냐가 결정되는데 역량이 부족한 팀일 경우 아래 그림과 같이 일정의 상당부분을 계획된 작업보다는 그 때 그 때 발생하는 작업에 주로 사용합니다.




잡음은 계획을 아주 쉽게 무너뜨린다.

---

갑자기 발생하는 급한 업무가 발생하면 그 일정에 해당 업무에 대한 Todo(백로그)를 넣습니다. 그럼 그 계획(스프린트)에서 새로 발생한 업무량(스토리점수)만큼 우선순위가 낮은 업무를 제거하거나 연기해야 합니다.
이런 계획 조정이 빈번하게 발생하면 아무리 철저하게 계획(스프린트)을 관리하는 조직일지라도 어느 순간 계획은 계획일 뿐 계획대로 움직이지 않게 됩니다.


이런 상황이 되면 팀원들은 목표를 잃게 되고 그날 그날, 그냥 그냥 일하게 됩니다. 그냥 그냥 열심히...


제어할 수 있는 영역을 점점 넓히자.

---

잡음이 계획에 나쁘기는 하지만 중요하지 않다는 것은 아닙니다. 대부분 급하고 중요하기 때문에(그렇지 않은 경우도 많이 있고 ㅜㅜ) 계획을 무시하고 먼저하게 됩니다.

우선 자기 팀이 일정한 기간동안의 계획(스프린트)중에 어느 정도 계획 외의 작업(잡음)에 시간을 쓰지는 대략적으로 계산합니다. 만일 2/3는 일정에 있는 작업보다 그 때 그 때 발생하는 업무를 처리하는데 쓰인다면 계획의 2/3는 아무 이름이 없는 작은 작업으로 만듭니다. 스크럼 용어를 빌리자면 스프린트의 백로그 중 2/3를 이름 없는 백로그로 만듭니다. 예를 들어 팀이 한 스프린트당 30점을 수행한다면 이름없는 백로그를 2점짜리 10장을 만들어 20점을 할당합니다. 10점에 대해서만 계획에 의한 백로그를 할당합니다.



이 이름 없는 작업(백로그)로는 어떤 일도 할 수 있습니다. 즉 작업수행에 있어 백지수표와 같은 거죠. 계획대로 수행하다가 잡음에 의한 업무가 발행하면 이름 없는 작업카드를 이용하여 처리합니다. 그리고 가능한 10점은 계획대로 수행합니다.
그 다음 스프린트에서는 계획된 10점을 15점으로 그 다음은 20점으로 계획대로 진행하는 업무비중을 넓힙니다. 즉 백지수표 양을 점점 줄입니다.

이런 식으로 할 경우 최소한의 목표를 달성할 수 있어 팀은 목표를 잃지 않게 되며 점점 성과를 나타내게 됩니다. 그러면 이상하게도 급한 일은 줄어들고 많은 일들이 그 팀이 제어할 수 있는 영역에 속하게 됩니다.


중요도와 긴급도

---

아래 표는 시간관리에서 종종 볼 수 있는 표입니다. 모든 일들을 중요한 일과 긴급한 일로 구분하면 아래 표에 다 넣을 수 있습니다.



시간관리의 노하우는 II 영역의 일에 집중하는 것입니다. 그렇게 한다면 오히려 제일 중요한 것 같았던 I 영역이 줄어들면서 작업을 쫓아가는 인생에서 벗어나 중요한 일들을 미리 미리 준비하는 인생으로 전환하는 거죠~
이런 방법과 유사하다고 생각하면 됩니다.


응용...

---

소프트웨어 결함의 출몰은 계획을 망치기도 합니다. 결함이 발견되면 즉시 처리해야 가장 효율적입니다. 발견된 시기가 결함에 대한 정보가 가장 많고 고치기도 쉽습니다. 미루면 결함은 숨거나 잊혀지곤 하죠. 그리고 나중에 우리를 심하게 괴롭힙니다.
그래서 우리는 위의 방법을 응용하여 계획 중에도 결함이 발생되면 즉시 처리할 수 있는 방법을 사용합니다. 결함카드라는 방법을 이용합니다. (결함카드)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

새로운 형태의 작업들을 수행하게 되었습니다. 팀원들이 이제 추정에 익숙해 웬만한 작업들은 2~3번의 플래닝포커로 상당히 정확한 추정치를 내놓습니다. 그러나 세상은 그리 간단하지 않은가 봅니다. 추정에 대해 좀처럼 의견일치를 보이지 않습니다.
(이미지출처)


상황

---

제품 리뉴얼 작업을 진행하고 있는데 작업 개수가 상당합니다. 기능이나 난이도는 잘 알고 있는 내용이라 추정을 빨리 끝내고 싶습니다. 그런데 이 모든 작업을 하나하나 논의를 거쳐 모두 추정하기를 어렵습니다.

그리고 작업의 형태로 아직 정확하지 않습니다. 어떤 이는 각 작업이 상당히 쉽게 끝날 것이라고 예상하고 어떤 이는 시간 걸리는 작업이 많다고 주장합니다.


스프린트를 멈추고...

---

직접 수행해보고 속도를 측정하기로 합니다. 일단 스프린트를 멈춥니다. 그리고 충분한 양의 백로그를 만들어 놓습니다. 그리고 대략적인 우선순위로 백로그를 길게 상황판에 늘어놓습니다.
이제부터 복불복 시작입니다. 모두 백로그 카드를 집어들고 하나씩 공략합니다. 한 카드를 완료한 사람은 무조건 우선순위에 따라 다음 카드를 수행합니다. 고르지 않습니다. 그냥 복불복 게임입니다. 고를 경우 쉬운 것부터 수행하는 경향이 있어 속도가 실제보다 더 빠르게 측정됩니다.
이렇게 그냥 일주일동안 해봅니다. 이제 새로운 작업에 대한 대략적인 속도가 나왔습니다.
그렇습니다. 그냥 일단 해보는 겁니다.



고민하지 말자.

---

어떤 하나의 사건에 대해 갑론을박하는 경우 회의를 통해 허송세월 보내지 말고 될 수 있으면 직접 해보면 됩니다. 모든 일이 그렇지는 않겠지만 이 상황과 같이 머리 싸매고 따지는 것 보다는 직접 해보는 것이 이득인 경우가 많습니다.

이렇게 해서 우리는 일주일 스프린트는 멈추었지만 새로운 형태의 작업에 대한 제법 정확한 추정치와 속도를 얻었습니다. 물론 일주일 동안 상당량의 백로그도 끝냈지요.


머리가 안되면 몸이 고생?

---

물론 그런 경우도 있겠습니다만... 저는 몸 고생(?)하지 않으려고 회의만 주구장창하는 경우를 더 많이 보았습니다. 결국은 이상한 결론에 도달하거나 시간에 쫓겨 수 많은 밤샘으로 더 몸을 혹사시키는 경우도 많습니다.

새로운 형태의 도전을 위해 이것 저것 생각하다가 결국 시간에 쫓겨 못하거나 포기하는 경우가 종종 있습니다. 일단 그림을 그리기 위해 도화지(편집기)에  점(코드)을 하나 찍으세요. 우리에게는 수정할 기회가 있습니다.

후~ 써놓고 보니 저 자신에게 하는 이야기를 썼습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

한국소프트웨어기술진흥협회에서 애자일 강의를 했습니다. 이제 기술과 관련된 강의는 그만 하고 오직! 애자일 강의만 하려고 합니다. 우리 회사 강사들이 하는 강의의 특징이 실습을 많이 한다는 것이라 애자일 강의도 실습을 위주로 기획하려고 했습니다.
(이미지출처)


애자일 실습이라니...

---

애자일로 실습을 하려니 참 난감하더군요. 소프트웨어 쪽은 아무리 말로 강의하는 것보다는 하나라도 직접 돌려보는 것이 효과가 좋습니다. 방법론(저는 애자일을 방법론으로 보지는 않습니다만)도 마찬가지입니다. 아무리 책을 보거나 들어도 직접 그 방법대로 일을 해보지 않으면 뜬 구름 잡는 소리 같습니다.

그런데... 강의시간은 4시간 5일.. 이 시간동안 애자일 프로젝트를 하나 할 수도 없고...
그래서 생각한 것이 게임입니다. 칸반게임을 보고 힌트를 얻은 것이죠. 칸반게임이 훌륭한 애자일 실습도구이기는 하나 실제 우리가 작업하는 방식(스크럼)과 차이가 나고 이 게임을 하더라도 애자일과 연관성을 찾지 못하는 경우가 있는 것 같습니다.


게임을 통한 실습

---

게임을 통해서 프로젝트를 실습하는 것이 얼마나 효과가 있을지 의문을 품는 사람들도 있습니다. 물론 직접 이 방법으로 일해 보는 것보다는 못하겠지만 나름 효과가 있습니다.


강의를 하기 전 게임을 기획하고 사내에서 2차례 진행해 보았습니다. 게임(실습) 후 회고를 통해 나온 의견 중 애자일을 전혀 모르는 신입사원들도 아~ 이런 거였구나하고 감을 잡는 것 같습니다. 음.. 좀 기대되네요.


애자일 게임 프레임워크 (AGF)

---

칸반게임과는 달리 여러 팀이 스프린트를 진행하며 어느 팀이 최고의 고객가치를 얻는 지 경쟁을 합니다.
이 게임의 특징은 게임을 진행하면서 토론을 통해 규칙을 정하는 것입니다.


위 그림에서 story card는 그 팀이 해결해야할 사용자스토리이고 주사위를 던저 나오는 수만큼 story card에 부여된 작업시간을 수행하여 작업을 완료하는 식입니다. 이 때 매번 이벤트 카드를 집어야 하며 이 이벤트에 따라 수행해야 하는데 대부분 이벤트는 출장, 결함발생 같이 작업수행에 마이너스 요인을 주는 것들입니다.
이 이벤트를 해결할 수 있는 것이 Agile Practice인데 그 팀이 해당 이벤트를 처리할 practice를 가지고 있다면 이벤트에 의한 패널티를 무시하고 작업을 진행할 수 있습니다.
practice 카드는 단위테스트, 스크럼미팅, CI, 현장고객상주 같은 애자일 practice를 27가지를 준비합니다.

칸반게임과 유사하나 룰을 정하는 방법이 조금 다릅니다. 한 팀에서 이벤트가 발생하고 자신이 가진 practice로 해당 이벤트를 해결할 수 있다고 다른 팀을 설득해야 합니다. 모두 동의하면 그 때 규칙이 정해지고 다음부터는 다른 팀에도 해당 이벤트에 대해 동일한 규칙을 적용합니다.
이 설득과정이 토론과정이 되고 어떤 practice가 유용한지 각 practice가 어떤 효과가 있는지 알게 됩니다.

practice카드는 처음에 3장씩만 고르게 하고 중간 중간 토론을 잘하는 팀이나 이벤트에 대해 좋은 의견을 내놓은 팀에게 practice 카드를 줍니다.

게임의 핵심은 스토리카드로 어떻게 릴리즈/스프린트 계획을 잘 세우고, 어떤 practice 카드를 선택하고 그리고 어떻게 다른 팀을 설득하느냐에 달려있습니다.


게임을 진행하고

---

처음 계획은 3번의 스프린트를 진행하려고 했는데 너무 토론이 뜨거워 1번의 스프린트 밖에 진행하지 못했습니다. 생각보다 더 열심히 게임에 동참하고 재미있게 토론을 하였습니다.


많은 분들이 스크럼에 대한 것과 practice에 대해 실질적인 감을 잡았다고 말씀하셨습니다. (감사합니다.)
그리고 이렇게 붙은 열정(?)이 식기 전에 빨리 회사에 가서 적용하겠다고 하시는 분도 계셨습니다. (성공하세요. ^^)

역시 무엇이든지 열심히 하는 것보다는 재미있게 하는 것이 더 효과가 있다는 것을 다시 한번 증명하는 기회였습니다.

다음 링크로 가시면 실습과 스크럼에 대해 회고한 자료가 있습니다. 회사 자료라 여기에 넣기가 좀. ^^

http://vizend.tistory.com/36
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

간만에 블로그에 들어와봅니다. 2011년이 되면서 새로운 사업들 때문에 바쁘다는 이유로 내 블로그에는 정제된 글만 올리겠다는 욕심으로 벌써 반년이 후딱 지나갔네요.

그런 욕심 버리고 일단 아무 글이나 올려봐야겠습니다. 이 글은 고객에게 받은 agile 질문을 답한 글인데 다음 링크에서 볼 수 있습니다.



Agile에 대한 12가지 질문들

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지금 우리는 복불복 스프린트를 진행하고 있습니다. 가끔은 이런 스프린트가 생기기도 하네요. 상황은 다음과 같습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

우리팀에서 일일회의를 시작한지도 4년 가까이 되어가고 있습니다. 그동안 잠시 외부 프로젝트 나갔다가 오기도 했고 같이 일하던 팀원들도 교체되기도 했습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.