BackLinks of UserStory

• 1002/Journal
        * To Do List 에 대해서 Layering 이 필요하다 - 전체지도 : 부분지도 랄까. XP 라면 UserStory : EngineeringTask 를 이야기할 수도 있겠지. EngineeringTask 수준의 경우 Index Card 가 더 편하긴 한데, 보관해야 할일이 생길때 문제다. (특히 2-3일로 나누어서 하는 작업의 경우) 이건 다이어리 중간중간에 껴놓는 방법으로 해결예정. (구멍 3개짜리 다이어리용 인덱스카드는 없을까. -_a 평소엔 보관하다 필요하면 뜯어서 쓰고; 포스트잇이 더 나을까.)
• AcceptanceTest
       AcceptanceTest는 UserStory들에 의해서 만들어진다. Iteration 동안 IterationPlanning 회의때 선택되어진 UserStory들은 AcceptanceTest들로 전환되어진다. Customer는 해당 UserStory가 정확히 구현되었을때에 대한 시나리오를 구체화시킨다. 하나의 시나리오는 하나나 그 이상의 AcceptanceTest들을 가진다. 이 AcceptanceTest들은 해당 기능이 제대로 작동함을 보장한다.
       UserStory는 해당 UserStory의 AcceptanceTest를 Pass 하기 전까지는 수행되었다고 생각할 수 없다. 이는 새로운 AcceptanceTest들은 각 Iteration 때 만들어져야 함을 뜻한다.
• ExtremeProgramming
       초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
       그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki:EnginneringTask 를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 UserStory 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.
       그리하여 각 Wiki:EngineeringTask 들이 구현되고, 궁극적으로 UserStory 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)
        * UserStory: 사용자 관점에서 시스템의 행위에 대한 간략한 서술
        * ThePlanningGame: 개발자는 UserStory들에 대해서 구현, 예측, 지시들에 대해 토론한다.
• HowTo/StartProject
       [UserStory]
• MineFinder
        * 인덱스 카드 & 필기구 - CRC 를 쓰건 UserStory를 쓰건..~ 단,
• NSISIde
        * UserStory 의 작성과 EngineeringTask 부분 작성시에 애매모호하게 쓴 부분과 잊어먹고 고려하지 않은 부분이 있었다. (이는 훗날 뒤통수를 친다. -_-;) 너무 복잡해서도 안되겠지만, 중요한 사항들에 대해 잊어서도 안될것이다.
• PairProgramming
        * Pair 의 진행을 이끌어가는 것 - 프로그래밍의 흐름이라고 해야 할까. 디자인을 어느정도 선정도로 맞추고 어떠한 문제를 풀 것인가에 대한 약간의 선이 필요할 것 같다. 이 경우에는 초반 디자인이 허술했었다는 약점이 있었다. '전체적인 관점에서 무엇무엇을 하면 프로그램이 완성될 것이다' 라는 것. UserStory 만 생각하고 EnginneringTask 를 간과한 것이 큰 문제였다. (그때 EnginneringTask 에 대한 개념이 없었었다는. 어디서 함부로 주워만 지식. --; 사고를 하자 사고를. -_-)
• ProjectPrometheus/EngineeringTask
       === UserStory ===
• ProjectPrometheus/Journey
        * UserStory 정리 & Engineering Task 재정의
        * ["ProjectPrometheus/UserStory"]
       CRC가 잘 추출되지 않을때는 차라리 UserStory를 따라가면서 클래스를 만들고, 거기에서 다시 CRC를 생각해 보는 방법이 시간 절약에 현명할 것이라고 생각된다. 객체 지향 의 프로그래밍을 추구해온 결과, Scenario나, UserStory를 따라가며 코딩하면서 수많은 클래스들이 책임에 따라서 생겨나는 것을 보면서 자연 스러움과, 약간 의아함 마져 들었다.
       왜냐면, 데블스 캠프 금요일 시간이 끝나고 나서 7층에서 석천이와 UserStory를 따라가며 만들어진 RandomWalk2 CRC의 모습에서는 단 3개만의 클래스만이 존재하였다. 하지만, UserStory를 따라가면서 소스 수준의 코딩을 하면 더 많은 클래스로 분화할것을 기대한다. 즉, 코딩을 하면 어쩔수없이 Layer의 최 하위까지 내려갈수 밖에 없으리라고 본다. 자 그럼 문제는 레이어 일것이다. 다행히 현재 코딩된 부분은 전부 logic의 부분으로 취급하고 있지만, logic 내에서 다시 레이어로 나뉘어서 외부에서 접근할수 있는 인자와 없는 인자로 나뉘어 져야 할것이다. 여기서 잠시 기억되는 말
        * UserStory 와 사용자 시나리오를 혼용해서 쓴 것 같은데, UserStory Page 를 참조.
        * UserStory 와 Scenario 일부러 혼용해서 썼다. 실제로 우리는 둘다 이용했다고 생각하기 때문에 특별히 구분할 생각을 안했음 --상민
        * '일부러' 인가. 구현부분이 '무엇을 하고 있나' 에 대해 '이 Story를 하고 있다' 라고는 이야기할 수 있어도, 우리가 실제 coding 할때 이용한건 User Scenario 에 맞춘것임. UserStory 는 말 그대로 'Target' 일 뿐이라 생각하는데. 어떻게 '이용' 했지? --["1002"]
        1. 월요일에 작성한 통합된 UserStory와 Scenario를 기반으로 완전한 Requiment 를 작성하고, MVC, WebProgramming을 감안하지 않는 CRC 접근을 했다.
        * 한일 : 요구정의 정리, UserStory와 Scenario 혼용, 확인 부족한 스펙 부분 발견, 개발환경 정의
        * Requirement 를 받았다. Requirement 를 받기전에 너무 준비를 소홀히 했다라고 생각한다. Requirement 를 받는대에도 미리 계획을 세웠어야 했는데. 차라리 전에 이용하던 UserStory 작성 -> 대강의 EngineeringTask 궁리 -> EngineeringTask 에서 공통으로 겹치는 부분 / 큰 부분 나누기 -> Estimate 결과 작성 이라도 시도해볼걸 이란 생각이 든다. Requirement Process 에 대해서 꼭 비격식적이더라도 구조적인 방법을 생각해볼 필요가 있단 생각이 들었다. (너무 허둥지둥했던 것을 생각하면.)
• ProjectPrometheus/UserStory
       === UserStory ===
       === Requirement 받은 사항 (UserStory 식을 재정의 함) ===
       ["ProjectPrometheus"]{{{~cpp /UserStory}}}
• User Stories
       See UserStory , Xper:UserStory
• UserStory
       Wiki:EngineeringTask 란 해당 Story를 구현하기 위해 실질적으로 해야 할 일들에 대한 서술이다. UserStory 의 각 항목이 비교적 사용자 관점에서의 서술이라 한다면, Wiki:EngineeringTask는 구현해야 하는 Developer들 관점에서의 서술이다.
       UserStory 들을 작성한 뒤에는 Wiki:EngineeringTask 를 결정하고, estimate (해당 작업에 대해 얼마나 걸릴 것인가에 대한 예측)한 Story Point 와 Task Point 를 기준으로 적절히 계산해 나간다.
       물은 물이고 산은 산이다에서 물은 물이 아니고 산은 산이 아니다로 가고 난 후에야 비로소 다시 물은 물이고 산은 산이다로 올 수가 있죠. 항상 초월적으로 모두 다 같다 혹은 모두 다 다르다는 식으로 말하는 태도는 공부를 하고있는 학생으로서는 상당히 위험하지 않을까 하는 우려를 해봅니다. Wiki:UserStoryAndUseCaseComparison 에 양자의 유사점, 차이점에 대한 논의가 있습니다. 참고로 Use Case의 대가라고 불리우는 코번은 다음과 같은 말을 합니다.
• XpQuestion
       === UserStory 는 어떤 것 부터 실행할까? ===
       === UserStory, Engineering Task 의 의존성 문제 ===
• XpWeek/20041221
        === 고객 역할놀이 - UserStory 작성 150m ===
        === 개발자 역할놀이 - UserStory 측정 15m ===
        === 고객 역할놀이 - UserStory 나누기 15m ===
       UserStory와 서버, 클라이언트 프로그램의 진행 방향이 정해졌다. 네트워크 관련 개발과 TDD 진행이 재밌게 이루어졌으면 좋겠다. -- 재선
• XpWeek/ToDo
        [[HTML(<strike>)]] 고객 - UserStory 작성[[HTML(</strike>)]]
        [[HTML(<strike>)]] 개발자 - UserStory 측정[[HTML(</strike>)]]
        [[HTML(<strike>)]] 고객 - UserStory 나누기[[HTML(</strike>)]]
        [[HTML(<strike>)]] 고객 - UserStory 우선순위 매기기 [[HTML(</strike>)]]
        ==== 고객 - UserStory 작성 ====
        ==== 개발자 - UserStory 측정 ====
        ==== 고객 - UserStory 나누기 ====
        ==== 고객 - UserStory 우선순위 매기기 ====

You can also click here to search title.