User Story 란? ¶
사용자의 요구사항에 대한 간략한 기술. XP의 다른 과정들이 그렇듯이 (이건 아마도 XP 방식으로 진행하는 팀들의 특징인듯. -_-a Case Tool 보다는 간단한 카드와 펜을 선호함.~) 보통 인덱스 카드에 기술을 한다.
Story Estimation ¶
- man-hour 의 계산
- Story Point 의 계산
- Task Point 의 계산
EngineeringTask란 해당 Story를 구현하기 위해 실질적으로 해야 할 일들에 대한 서술이다. UserStory 의 각 항목이 비교적 사용자 관점에서의 서술이라 한다면, EngineeringTask는구현해야 하는 Developer들 관점에서의 서술이다. UserStory 들을 작성한 뒤에는
EngineeringTask를 결정하고, estimate (해당 작업에 대해 얼마나 걸릴 것인가에 대한 예측)한 Story Point 와 Task Point 를 기준으로 적절히 계산해 나간다.매 Iteration (개발주기)를 진행할 때마다 실제로 진행한 Story들을 계산, 다음 estimation에 이용하게 된다.
Estimation 이 어려운 경우 ¶
estimate 를 하기 힘든 경우는 두가지가 있다. 하나는 해당 Story 가 애매한 경우이고 하나는 해당 Story의 구현이 전혀 생소한 부분인 경우이다. 해당 Story 가 애매한 경우에는, 주로 Story에서 해야 할일이 많은 경우이다. 해당 Story를 작은 Story들로 나누어서 생각해본다. 구현이 전혀 생소한 부분에 대해서는 SpikeSolution을 해본뒤 estimation 하는 방법이 있다.
Thread ¶
3학년 2학기때 배운 UP(Unified Process)의 Use Case 를 보는 듯하다.
Use Case 에 대해서 문서를 작성하고..그 다음으로 System Sequence Diagram을 만드는데.
시스템과 사용자간의 어떤 행위들을 하는가른 간단히 순서적으로 적는것이지.
개발 방법론이란 것이 어떻게 보면 다 그렇고 그런거 같아.
- 구근
Use Case 에 대해서 문서를 작성하고..그 다음으로 System Sequence Diagram을 만드는데.
시스템과 사용자간의 어떤 행위들을 하는가른 간단히 순서적으로 적는것이지.
개발 방법론이란 것이 어떻게 보면 다 그렇고 그런거 같아.
- 구근물은 물이고 산은 산이다에서 물은 물이 아니고 산은 산이 아니다로 가고 난 후에야 비로소 다시 물은 물이고 산은 산이다로 올 수가 있죠. 항상 초월적으로 모두 다 같다 혹은 모두 다 다르다는 식으로 말하는 태도는 공부를 하고있는 학생으로서는 상당히 위험하지 않을까 하는 우려를 해봅니다. UserStoryAndUseCaseComparison에 양자의 유사점, 차이점에 대한 논의가 있습니다. 참고로 Use Case의 대가라고 불리우는 코번은 다음과 같은 말을 합니다.
UserStoryAndUseCaseComparison에 양자의 유사점, 차이점에 대한 논의가 있습니다. 참고로 Use Case의 대가라고 불리우는 코번은 다음과 같은 말을 합니다.After several years of debating this question and seeing both in use, I now think they have nothing in common other than their first three letters.
--김창준
