1. RTC planning을 이용한 스토리보딩 작업
- one-day workshop을 하면서 프로젝터로 쏘면서, 백로그나 릴리즈 계획에 스토리를 만들어서 넣어야 겠죠.
- 먼저 divide-and-conquer를 위해서, 인사관리 시스템 영역별로 팀을 나누고 각 팀별로 스토리를 만든 후,
각 팀별 백로그에 결과를 넣고 나중에 프로젝트 백로그로 옮겨서 취합하는 방법도 생각해 볼 수 있겠죠.
2. 스토리 보딩을 하면서 혹은 끝나면... estimation 작업을 해야겠죠.. story points를 기준을 만들고 점수를 매기면서.. 백지장도 맞들면 낫다.. 염두에 두고...평균값, 중앙값, 최빈값 뭐 어떤 식으로 든지.. 합의된 complexity metric이 나오면....
3. release planning을 해야 겠죠... 어떤 스토리를 어느 release에 하자... 너무 큰 스토리는 epic으로 보내고 다시 쪼개는 작업도 해야 할 거 구요...
4. release 1에 대한 구체적인 작업을 할려면 스토리를 task로 쪼개야 겠죠.. 개발자, 개발기간 estimation 등등...
그리고 팀별로 iteration planning을 세우는 거죠... release 1은 몇개의 iteration으로 갈 건지... iteration별로 어떤 task를 개발한건지... 최초의 iteration은 learning curve도 있고 하니..목표를 작게 잡고 개발 프로세스에 익숙해 지고 개발 도구에 익숙해 지는 것을 고려합니다. team의 velocity는 iteration 2 ~ iteration 3를 거치면서 각 팀은 하나의 iteration에서 어느정도 man-day를 처리할 수 있는 지 계속 측정해 나가야 겠죠...
5. 본격적으로 iteration을 수행하겟죠.. 각 팀별로 scrum 미팅을 할 수도 있고, stand meeting을 할 수도 있고, 팀에 맞게 매일 또는 지정된 요일에 미팅을 하면서 communication하겠죠...
글로 쓰는 게 낫겠습니다. 프로세스란게.. 사람마다 뷰가 달라서... ㅎㅎ
아~ 이부분은 묵언으로 태클걸기가 힘든 부분이 많켔네요^^
완벽함을 추구하는 풍차님에겐 용납못할 사안이 많이 생기것는데요^^
두리뭉실한 저야 단타적인 관점으로 쭈욱 밀고 나갈건데^^
나중에 제 버젼 나올때쯤이면 이 제품 수명 다하는거 아닌지 몰러^^
Tracking and Planning with Rational Team Concert
http://www.youtube.com/watch?v=j6BsoiKDat0
이거 보시면 도움이 될런지 모르겠습니다.

오예~~ 찾아가는 서비스군요^^
조그만 중소업체에서 인사관리 시스템을 개발한다는 시나리오로
언제 아름프로님이 작업한거랑 비스무리하게 스토리보드부터
작업항목 사용법
그리고 change set 관련 부분도 좀 낑가서^^
그리고 간단한 보고서~~
빌드시스템을 아우르는 걸 한번 시연하시겠어요?
힘들다면 짬짬이 시간 나시는데로 올려주시면 되고요~~
아직 모르는거 투성이라 어디부터 건드려야 간지러운지도 모르겠는지라 ㅋㅋ
그래도 밤새지는 마세요~~
그리고 완성도 떨어져도 괜찬으니 만드는 족족 올려주시고요^^
아싸~~ 오늘도 풍차님 거는데 성공^^