[5월 14~15일 목,금] 초반부터 부스터에 연기난다.

--- To Think

- Subversion commit comment 통일할 필요가 있다.

 . Commit 단위도 결정해 주면 좋다.
 . Branch 전략은 infoQ의 글을 따르하기로 했다. ( http://www.infoq.com/articles/agile-version-control ) <- 매우 훌륭하다!


* 한 주 마감을 하면서 팀원들과 짧은 회고를 하였다. 처음엔 다소 어색해 했지만, 나름 적응을 잘 하는 것 같다. (Pair Programming 에대해서는 다들 굉장히 긍정적으로 이야기 했다.)

* 결국 개발자 한 분은 오시지 않아서 새로 찾기로 하였다. :(



Agile Lessons to be considered #1

- 실제 팀 속도(Team Velocity)

스 토리 점수를 추정하고 Iteration (혹은 Sprint)에서 처리할 양을 결정하며, 그에 대한 실제 팀 속도(Team Velocity)를 측정하려면 유용한 정보가 축적될 수 있을 정도로 팀이 유지되어야 하는데 그렇지 못하고 개발팀이 해체되는 경우가 많다.

- 분석설계자와 개발자의 투입 시기가 다른경우 분석설계자와 개발자를 최대한 가깝게 두라!

- 정확한 팀 속도 측정

정확한 팀 속도를 측정하려면 일 평균 근무 시간이 (적절한 수준에서) 일정해야 한다. 자칫하다간 9 to 9 (혹은 그 이상)의 일정을 소비했을때의 속도가 팀 속도가 되어버릴수 있다.

- 팀이 독립된 작업 공간을 얻지 못하면 잃는 것은 무엇인가?

- My Project is SCRUM, so it does Agile~!??

 좀더 협력적이고, 좀더 즐겁고, 좀더 생산적인 팀을 만드는게 중요하지, 스크럼이 중요한것이 아니다. 특정 Agile 의 특정 Practice 를 적용하지 못했다고 해서 Not Agile 이라고 할 필요는 없다.

- 대시보드 Task 의 onGoing (혹은 in production) 에 숫자 제한을 둘 필요가 있다.

 . KanBan 을 생각하자. (http://en.wikipedia.org/wiki/Kanban , http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html ), 키워드는 도요타, 간판.
 . Be Focus !!!

- 대시보드에 색을 적절히 사용해 본다.

작업자로 구분할 것인가? 아니면 업무영역이나 목표 Product 로 할 것인가?

- 어쩌면 회고가 최고의 Agile 기법이 될 수도 있다.

팀 내의 문제를 찾고 반성하고 개선해 나간다. 모두가 전력을 다해서!

Agile 툴 목록(클릭)

- Source Control 을 이용한다.

 . 하나의 Story가 Done 이 되어 Test 를 마치면 Releasable 이라고 간주한다.
 . Tag를 찍던, 아니면 Branch를 따던 해 보자. (Done branch)
 . Sprint 2 에 발생하게 될 Sprint 1의 버그 수정에 어떻게 대비할 것인가? (현재 Trunk를 이용해서 sprint release 의 버전을 올린다.)