일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Database
- write by GPT-4
- JVM
- python
- 소프트웨어공학
- write by chatGPT
- android
- GPT-4's answer
- 코틀린
- 데이터베이스
- jpa
- 인프라
- 자바
- 고전역학
- chatGPT's answer
- kotlin
- Java
- flet
- spring integration
- 시스템
- 유닉스
- 역학
- oracle
- spring data jpa
- 파이썬
- 리눅스
- 웹 크롤링
- 자바네트워크
- 자바암호
- NIO
- Today
- Total
기억을 지배하는 기록
User Stories Applied : Chapter 7 좋은 스토리를 위한 지침 본문
User Stories Applied : Chapter 7 좋은 스토리를 위한 지침
Andrew's Akashic Records 2018. 4. 18. 13:37목적 스토리로 시작하라
대규모 프로젝트, 특히 사용자 역할이 많고 다양한 프로젝트는 스토리 식별에 있어 막막한 경우가 있다. 이럴 때는 한번에 하나씩 사용자 역할을 선택하여 그 사용자가 새 시스템을 사용하는 주 목적을 식별하는 것이 가장 효과적이다.
케이크 자르듯 나누어라
큰 스토리를 만났을 때에는 그것을 작은 스토리 조각으로 나눌 수 있다는 사실을 명심하자. 기술적인 측면에서 스토리를 나누려고 하지 말고 나누어진 스토리가 시작부터 끝까지의 기능을 제공하도록 나눈다.
제약사항 기록하기
비기능 요구사항을 정의하는 방법으로 제약사항을 기록하는 것이 좋다. 첫 이터레이션부터 제약 사항들을 테스트로 작성해 두어야 한다.
스토리의 크기는 시간 축에 맞추어라
다음 진행할 이터레이션에 대해서는 일정을 계획할 수 있는 수준으로 작은 스토리를 작성하며, 훨씬 나중에 처리할 스토리는 정확하지 않더라도 더 크게 작성하도록 한다.
스토리에 사용자 역할을 포함하라
사용자 역할을 식별해 냈다면, 스토리를 작성할 때 사용자 역할을 적극 이용하도록 한다.
능동태로 작성하라
사용자 스토리는 능동태로 작성하는 것이 읽거나 이해하기 쉽다.
고객이 작성하라
고객에게는 이터레이션을 시작할 때 스토리의 우선순위를 매겨야 하는 책임이 있기 때문에 고객은 반드시 각 스토리를 이해하고 있어야 한다. 이를 위해서라도 고객이 직접 스토리 카드를 작성하는 것이 좋다.
목적을 잊지 말라
스토리 카드의 주 목적은 구현할 기능을 논의하기 위한 단서 역할이라는 점을 잊지 말아야 한다. 단서는 간결해야 하며, 카드에는 나중에 대화를 재개하기 위해 기억하면 될 정도의 세부사항만을 써넣으면 된다.
'오래된글 > 소프트웨어공학' 카테고리의 다른 글
User Stories Applied : Chapter 9 이터레이션 계획 (0) | 2018.04.18 |
---|---|
User Stories Applied : Chapter 8 릴리즈 계획 (0) | 2018.04.18 |
User Stories Applied : Chapter 6 사용자 스토리 인수 테스트 (0) | 2018.04.18 |
User Stories Applied : Chapter 5 대리 사용자와 일하기 (0) | 2018.04.18 |
User Stories Applied : Chapter 4 스토리 수집하기 (0) | 2018.04.18 |