we talk about some cases of trouble shooting and how it can impact to java performance. Also, we introduce some kind of tools for checking matters efficiently and approaching easy to user.
we talk about some cases of trouble shooting and how it can impact to java performance. Also, we introduce some kind of tools for checking matters efficiently and approaching easy to user.
"린과 애자일 개발"이라는 책에 대한 리뷰.
본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다.
처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.
하얀 눈 위에 발자국은 반갑고 친구와 같은 느낌이었던 것 같습니다. 애자일 적용에 첫발을
내딛으려는 팀에게 도움이 되었으면 좋겠네요.
경기원, LG CNS
애자일을 통해 내가 하고 있는 무엇인가를 더 낫게 만들려는 욕심 있는 분들께 추천합니다.
신황규, 삼성SDS
현실을 부정하지 말고 일단 작게 시작하세요.
관찰하고 적응하세요. 특정 방법에 얽매이지 말고 애자일 선언문을 기억하세요. :-D
심우곤, LG전자
어제보다 나은 오늘을 만드는데 도움이 되었으면 좋겠습니다.
이승룡, 삼성SDS
애자일을 적용하려는 팀에 도움이 되었으면 좋겠어요!
채수원, NHN
여러분들이 애자일과 더 친해졌으면 합니다.
황상철, NHN
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay Kim
Noel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
"린과 애자일 개발"이라는 책에 대한 리뷰.
본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다.
처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.
하얀 눈 위에 발자국은 반갑고 친구와 같은 느낌이었던 것 같습니다. 애자일 적용에 첫발을
내딛으려는 팀에게 도움이 되었으면 좋겠네요.
경기원, LG CNS
애자일을 통해 내가 하고 있는 무엇인가를 더 낫게 만들려는 욕심 있는 분들께 추천합니다.
신황규, 삼성SDS
현실을 부정하지 말고 일단 작게 시작하세요.
관찰하고 적응하세요. 특정 방법에 얽매이지 말고 애자일 선언문을 기억하세요. :-D
심우곤, LG전자
어제보다 나은 오늘을 만드는데 도움이 되었으면 좋겠습니다.
이승룡, 삼성SDS
애자일을 적용하려는 팀에 도움이 되었으면 좋겠어요!
채수원, NHN
여러분들이 애자일과 더 친해졌으면 합니다.
황상철, NHN
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay Kim
Noel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
The better ways of developing software
Software Development Methodology
Agile
Scrum Methodology
eXtreme Programming(XP)
Waterfall
Kanban
When to Use Scrum
When to Use Kanban
2. 핵심 내용
} 예제를 활용한 명세 개요 및 이점
} 주요 프로세스 패턴 및 핵심 실천법
} 리빙 도큐멘테이션 (Living Documentation)
} 예제를 활용한 명세와 스크럼
} 명세 워크숍 (Specification Workshop)
} 변화의 시작
} 정리
} 자주 묻는 질문
} Q&A
22
4. 목마른 자들이 우물을 찾는다
44
} 요구 사항 분석이 제대로 이뤄지지
않아 재작업에 많은 시간을 허비한다
} 협업 시 업무 공유가 되지 않아 누락
되는 것들이 많다
} 기능이 많고 점점 복잡해져서 변경이
두렵다
} 문서는 있지만 유명무실, 사람과
코드를 통해 도메인 지식을 습득해야
한다
} 효과적입 업무 배치가 불가능하다
} 테스트가 보틀넥이 된다
} 아무런 문제없이 출시하기 위해 기도
한다
5. 현실
- 기존 방식의 문제 -
55
} 각자 자신의 업무와 목적(목표)를 생각하고 일한다.
} 때론 요구사항 또는 명세만으로 모두가 이해하기엔 충분하지 않다.
} 자신의 역할에 따른 기대와 사고방식.
} 정보 공유 및 이해에 따른 병목현상.
} 모두 이해하기 힘든 표현(용어 등)으로 인해 가시성이 부족하다.
} 명세가 확정될 때까지 개발(또는 관련작업)은 한정적으로 진행되거나 대기한다.
} 명세를 정의하는데 있어 현장의 정보가 필요하다.
} 명세가 testable하지 않을 경우 개발, QA과정에서 커뮤니케이션, 개발, 테스트
비용이 추가로 발생된다.
} 최악의 경우 누락 또는 잘못 구현되어 불필요한 재작업이 발생된다.
} 상호 신뢰 및 팀워크 저하
} 결국 개인, 팀, 서비스 모두의 경쟁력이 악화된다
6. 열쇠는 Specification by Example
- 예제를 활용한 명세-
66
} 성공적인 팀에게서 배우기
} 협업을 통해 명세를 작성하고,
} 올바른 방식으로 테스트하는
습관을 가지고 있으며,
} 이를 통해 큰 효과를 봤다
0 1 2 0
7. 예제를 활용한 명세
- 성공적인 팀의 올바른 소프트웨어 인도 방법 -
77
} 고코 아지치(Gojko Adzic)
} 개발자, 아키텍트, 기술 책임자, 컨설턴트
} 예제를 활용한 명세 실천법을 적용할 수
있게 돕는 일을 해오고있다
} 예제를 활용한 명세와 관련된 여러
오픈소스 프로젝트에 공헌하고 있다
} UK Agile Testing User Group 운영
8. 88
i E A f nl E
d o S em
c c p a A bG
( - . ) ) - k j
11. 1111
애자일 인수 테스트 Agile acceptance testing
인수 테스트 주도 개발 AcceptanceTest-Driven
Development
예제 주도 개발 Example-Driven Development
스토리 테스트 Story testing
행위 주도 개발 Behavior-Driven Development
예제를 활용한 명세 Specification by Example
20. 협업을 통해 명세 만들기
- 왜 협업을 통해 명세를 작성해야 하는가? -
2020
} 명세를 함께 구체화함으로써 지식과 경험을 공유할 수 있다
} 명세에 대해 주인의식을 갖게 됨으로써 모든 사람들이 개발
프로세스에 더 주도적으로 참여하게 된다
} 무엇이 완료돼야 하는가 모두 이해한다
} 다양한 관점에서의 명세 검증을 보장한다
} 이해하기 쉬운 명세와 유지보수하기 쉬운 테스트를 만들 수
있다
23. 협업을 통해 명세 만들기
- 인기있는 협업 모델 -
2323
} 대규모 명세 워크숍
} 예제를 활용한 명세를 처음 시작할 경우
} 전체 팀원이 참여
24. 협업을 통해 명세 만들기
- 인기있는 협업 모델 -
2424
} 3 Amigos
} 도메인에 대해 많은 설명이 필요한 경우
} 개발자, 테스터, 비즈니스 분석가 대표자
참여
} 도메인에 대한 비슷한 수준으로 이해하고
이를 바탕으로 보다 효율적인 워크숍을
진행
할 수 있다
} 짝 작성
} 도메인에 대한 이해도가 높은 경우
} 개발자, 비즈니스 분석(또는 테스터) 참여
협업을 통한
명세
27. 예제를 활용해 설명하기
2727
} 예제는 명확하게 작성
} 완전한 구조로 작성
} 현실적으로 작성
} 이해하기 쉽게 작성
} 비기능의 경우 정밀한 요구사항을 작성
피드백 활동
피드백 활동은 어떤 그룹의 구성원들이 명세를 동일하게 이해하고 있는지 확인하는 좋은 방법이다.
하나의 스토리에 대해 토론을 진행한 후 누군가가 특별한 경우를 제시하면 그 사람은 워크숍의
다른 참가자에게 시스템이 어떻게 작동해야 할지 쓰게 한다. 답변이 모두 일치하면 모든 사람이
명세를 같은 방식으로 이해하고 있는 것이다. 사람들의 답변이 일치하지 않으면 다른 결과에 대해
그 이유를 설명하는 것이 좋다. 토론을 통해 오해의 원인을 파악할 수 있다.
28. 명세 정제하기
2929
} 명세는 도메인 언어로 작성해야 한다
} How가 아닌 What에 집중하자
} 예제는 명확하고 테스트할 수 있어야 한다
} 흐름 위주의 설명을 피하라
} 명세는 SW 설계가 아닌 비즈니스 기능에 대한 것이어야 한다
} 명세는 설명이 필요없을 만큼 자명해야 한다
} 명세는 한 곳에 집중해야 한다
29. 명세의 변경없이 검증 자동화하기
3030
} 성공적인 팀에서는 주요 예제를 최대한 활용하기 위해 정보의
변경없이 검증을 자동화 한다
} 자동화 계층에서 테스트는 How를 구현하고, 명세는 What을
정의한다
} 테스트가 명세이고 명세가 곧 테스트다
32. 자주 검증하기
3333
} 왜? 잦은 검증을 통해 명세의 신뢰성을 유지한다
} 지속적인 검증을 위한 두 가지 과제는 빠른 피드백과 안정성이다
} 격리된 환경을 준비하고 더 신뢰할 수 있게 배포를 완전히
자동화한다
} 피드백을 더 빨리 얻을 수 있는 방법을 찾아라
} 빠르고 느린 테스트를 분리한다
} 오랫동안 실행되는 실행 가능한 명세 팩을 더 작은 팩으로 나눈다
} 실패하는 테스트를 그냥 비활성화해서는 안 된다
} 문제를 해결하든지
} 철저하게 모니터링할 수 있는 우선순위가 낮은 회귀 이슈에 대한 팩으로
옮긴다
35. 리빙 도큐멘테이션
3636
} 비즈니스 명세 변경사항이
지속적으로 반영되는 현행된,
갱신된 문서이다
} 시스템 기능에 대해 신뢰할 수 있는
정보를 제공하므로 유용하고
의미있는 문서이다
} 실행 가능한 문서로써 자동화된
테스트(예제이면서 명세)이다
36. Living Documentation
리빙 도큐멘테이션
- 성공을 위한 필수 조건 -
3737
} 리빙 도큐멘테이션은 누구나 쉽게 활용할 수 있고 시스템의 기능을 파악할
수 있는 믿을 만한 수단이다
} 개발자는 목표로, 테스터는 테스트 업무로 그리고 비즈니스 분석가는
기능을 변경했을 때 어떤 영향이 있는지 파악하는 출발점으로 삼을 수 있다
} 리빙 도큐멘테이션은 개발 프로세스에서 소스코드만큼 중요한 산출물이다
shared understanding testing
38. 핵심 이점
4141
} 예제를 포함한 명세
} 추상적인 요구사항에 대한 상세한 설명
} 새로운 요구사항에 대한 발굴 : 공동 발견
} 공통 이해 및 도메인 지식의 공유
} 리빙 도큐멘테이션
} 명세에 대한 자동화된 검증
} 사람이(누구나) 읽을 수 있는 비즈니스 회귀 테스트
} 믿을 만한 문서 : 구현에 대한 신뢰
39. 예제를 활용한 명세와 스크럼 사례
42
Specification by Example
40. 43
} 반복점진 개발 방법론 – Agile 방법론 중의 하나
} “솔루션을 제공하지 않는다. 자신을 잘 볼 수 있도록 피드백 루프를 제공할 뿐”
스크럼
44. Whole Team / R & R
4747
} UX
} Interaction &Visual Design
} 기능 및 명세 관리
} 사업
} 서비스 운영
} 계약 및 홍보
} 요구사항 수집 및 요청
} 요구사항 우선순위 관리
} 개발
} 요구사항 충족한 개발
} 품질, 성능 보장한 개발
} 일정 내 개발 완료
} Agile Coach
} 애자일 코칭
} 협업 퍼실리테이팅
45. } 프로젝트 멤버가 처음 만나 서로에 대
해 이해를 넓히는 시간이다.
} 애자일과 스크럼, 일하면서 각자 성취
하고 싶은것들, 힘들었던 것들에 대해
이야기를 나누며 팀웍을 다지고 좀더
친밀해지는 시간을 갖고 있다.
팀 빌딩 – 팀에 대해 알기
46. } 프로젝트 멤버가 처음 만나 서로에 대해 이
해를 넓히는 시간이다.
} 애자일과 스크럼, 일하면서 각자 성취하고
싶은것들, 힘들었던 것들에 대해 이야기를
나누며 팀웍을 다지고 좀더 친밀해지는 시
간을 갖고 있다.
팀 빌딩 – 팀에 대해 알기
47. 프로젝트와 제품에 대해 알기
} “프로젝트에 대한 제반 지식과 목표 공유”
} 프로젝트의 비전, 범위, 자원, 이해당사자,
리스크 등에 대해 토론하면서 프로젝트
에 대한 공통의 이해를 키워 간다
48. 프로젝트와 제품에 대해 알기
} “프로젝트에 대한 제반 지식과 목표 공유”
} 프로젝트의 비전, 범위, 자원, 이해당사자,
리스크 등에 대해 토론하면서 프로젝트
에 대한 공통의 이해를 키워 간다
50. } 기능 수집 워크샵
} 워크샵을 통해 팀 모두 제품의 기능에 대해
아이디어를 수집하고 정제하고 있다.
} 이를통해, PO가 원하는 것을 팀이 제대로 이
해하고 서로간의 커뮤니케이션의 갭을 줄일
수 있다.
} “해에서 구름있는 곳까지 내려오는 시간”
목표에서 범위 도출하기
51. } 협업을 통해 팀은 기능/리스크/Spike와 이들의 우선순위에 대해 동등한 지식과 책임
감, Ownership을 갖게됨
} 이해를 돕기위해 Low-fi wireframe 등을 동시 작성함
목표에서 범위 도출하기
57. 초기 스팩 작성
} PO는 우선순위가 높은 기능 부터 기능
을 구체화하여 초기 스펙 문서를 작성
함
} “구름에서 산꼭대기 정도 도착”
58. 점진적으로 스팩 발전 시키기
} 기본 시나리오에서 대안 시나리오까지 스팩의 내용을 점차적으로 발전시킴
59. 점진적으로 스팩 발전 시키기
} 기본 시나리오에서 대안 시나리오까지 스팩의 내용을 점차적으로 발전시킴
60. 주기적인 백로그 Refinement 수행
} 팀은 초기 스팩을 기반으로 토론하고 PBI생성
} 팀은 주기적으로 변경된 스팩을 기반으로 토론하고 PBI생성 (스프린트에서 최소 1번)
} 팀 모두 혹은 3 Amigos가 모여 작성
} 협의되고 좀더 정제된 스팩 문서 생성
} 개발할 수 있는 단위로 좀더 작게 PBI 생성
} “팀이 산꼭대기에서 산 허리까지 내려옴”
61. 주기적인 백로그 Refinement 수행
} 팀은 초기 스팩을 기반으로 토론하고 PBI생성
} 팀은 주기적으로 변경된 스팩을 기반으로 토론하고 PBI생성 (스프린트에서 최소 1번)
65. 스프린트 - 지속적인 피드백
“이 부분은 의도와 다르게 구현됬어요. 변경 부탁드려요”
“생각보다 사용이 어렵네요. 대신에 이렇게 하면 어떨까요?”
“이 기능은 직접 써보니 유용하네요. 좀 더 강화할 방안을 찾아 봐야 겠네요”
“기능 구현하느라 오늘도 야근을 하셨군요.
불필요한 작업 없도록 좀 더 치열하게 우선순위 고민을 하겠습니다.”
(1) 매일 새벽 자동 빌드
uxdev po
(3) 설치, 사용(2) 모든 팀원에게
매일매일 제품 전달 (4) 기능 피드백,
기능 인수,
버그 리포트
66. 스프린트 – 효과적인 의사소통
6969
} TODO > 개발중 > 개발완료 > 인수완료
} 협의된 인수 조건에 따라 개발완료된 Task를 인수완료로 지정하여 명확하게 업무 진행
67. 스프린트 리뷰 / 회고
7070
} 2주 마다 동작하는 제품을 만들고 데모를 수행
} 데모를 통해 얻은 지식들을 이 후의 계획에 반영하고, 작전을 다시 짠다
70. Lesson Learned
1. “만들어 봐야 알 수 있다”
2. “가능한 작게 시작하는 게 좋다”
3. “목표와 의도에 대한 공감대가 정말 중요하다”
4. “한 팀으로 움직이는 것은 필수적이다”
5. “가능한 모든 결정은 팀 안에서 이뤄진다”
6. “계속해서 계획을 조정하고 검증할 수 있는 방법을 만들어야 한다”
7. “좋은 팀은 협업 프로세스를 꾸준히 개선한다”
73. 취지 및 목적
7676
} 열린 토론을 통해 모두가 함께 검토하고 똑같이 이해할 수 있는 완벽한 기회
} 도메인지식 공유
} 공감대 형성
} 문제와 해결책에 대한 공유와 함께 이해 조성
} 이후 발생될 수 있는 불필요한 비용을 사전에 차단
} 구성원 모두가 이해할 수 있는 명세 작성
} 모두가 이해할 수 있는 용어와 표현을 통해 가시성 확보.(Ubiquitous Language)
} 의도하지 않았던 스펙(또는 개발)을 미연에 방지
} 명세는 testable하게 작성하여 기능 구현 및 테스트에 용이하도록 작성
} 실제 실행가능하고, 기능이 검증된 스펙(또는 개발)을 지속적으로 배포
} 스펙 변경 등 변화에 안전하고 기민한 대응 가능
} 팀워크 향상
} 프로세스/프랙티스와 같은 방법론 보다는 실행하는 사람이 중요
} 상호 신뢰를 기반으로 같은 목표를 가지고 서비스를 만들어감
74. 진행 순서
7777
} 개요 및 취지 발표
} specification workshop
} 기획 설계 방향 리뷰 : UX
} Agenda 선정 및 리뷰 : UX
} 토론(question & answer) : 공동
} User Story & 용어집 작성 : 공동
} 향후 논의 과제 및 회고
} 향후 개선 사항 및 Agenda 선정
} 첫 번째 specification workshop 에 대한 소감
75. Team / R&R
7878
} UX팀
} 서비스 기획
} 기능 및 명세 관리
} 관리팀
} 서비스 운영
} 요구사항 수집 및 요청
} 운영이슈 관리
} 사업팀
} 계약 및 홍보
} FGI(Focus Group Interview)
} QA팀
} 품질, 성능 검증
} 개발팀
} 요수사항 충족한 개발
} 품질, 성능 보장한 개발
} 일정 내 개발 완료
} PM
} 프로젝트 관리 총괄
76. 주의사항
7979
} 명세 워크숍은 회의를 위한 시간이 아니다
} 명세 워크숍은 발표를 위한 시간이 아니다
} 명세 워크숍은 설계를 위한 시간이 아니다
80. 회고
83
} 공감된 이해와 목표를 기반으로 한 커뮤니케이션의 중요성을 알게 되었습니다
} 적극적인 의견 전달과 함께 공감할 수 있는 자리여서 너무 좋았습니다
} 이러한 노력과 과정들로 인해 확실히 좋아지고 있고 가능성을 보게 되었습니다
} 모든 구성원 분들과 함께했다는 것만으로 가슴 떨리는 자리였습니다
} 함께 만든 User Story 만으로 명세를 이해할 수 있다는 것이 큰 소득입니다
} 앞으로 각자 업무를 하는데 있어 도움이 될 거라 봅니다
} 이런 좋은 취지와 성과를 시도하는데 만족하지 말고 정례화 할 수 있도록 함께
노력합시다
85. 사람들을 참여 시키기
} 모든 이해관계자의 R&R을 존중하고 공동의 목표를 달성하기 위한 전향적인
자세갖기
} 효과적이고 효율적인 의사소통을 강조하기
} 전문용어의 사용 자제하기
} 연합팀의 시너지 홍보와 경영진의 지원 확보하기
} 인수 테스트를 더 잘할 수 있는 방법으로 예제를 활용한 명세를 홍보하기
} 테스트 자동화를 최종 목표로 잡지 않기
} 도구에 집착하지 않기
8888
86. 프로세스 변경 시작하기
} 문제 인식에서 부터 출발
} 의사소통 오류로 인한 재작업 및 중복 업무
} 시스템을 이해하기 위해 코드를 살펴보면서 낭비되는 시간
} 동일한 테스트를 손으로 일일이 수행하는 과정에서 반복되는 시간 낭비
} 반복 점진 개발을 예제를 활용한 명세를 가능하게하는 원동력으로 활용
} 제품 품질 향상을 위한 자극제로서 예제를 활용한 명세 핵심 실천법 활용
} 테스트 주도 개발을 디딤돌로 활용
} 개발과 별도로 테스트를 자동화한 팀은 자동화된 실행 가능한 명세 도입
} 프로젝트 초기에 자동화 비용을 계획에 반영
8989
87. 팀을 업무 흐름과 이터레이션으로 협업하도록
통합하는 방법
} 긴밀한 협력
} 테스터는 명세에 대한 예제를 추가하여 보다 명확한 완료 기준을 제공한다
} 합의된 명세를 기반으로 테스트를 활용하여 높은 품질을 달성한다
} 스토리는 짝으로 완성한다
} 개발자가 스토리를 개발하고 관련 테스트가 모두 통과하면,
} 비즈니스 분석가는 탐색적 테스트를 수행한다
} 스토리 챔피언
} 스토리 총괄자로 스토리와 관련된 지식 공유와 이슈를 해결을 담당한다
} 짝이 계속 바뀌더라도 작업을 계속해서 진행할 수 있다
9090
88. 경고 신호
} 자주 변경되는 실행 가능한 명세에 유의하라
} 검증이 실패했는데 명세를 바꿔야 한다면 제대로 작성되지 않은 것이다
} 비즈니스 규칙은 구현보다 더 안정적이어야 한다
} 부메랑에 유의하라
} 완결됐다고 생각했지만 재작업이 필요한 경우,
} 모호한 요구사항과 명세의 기능 차이를 명확하게 드러내야 한다
} 대비성 코드에 유의하라
} 명세를 구현하기 위한 최소한의 일을 한다
} 산탄총 수술에 유의하라
} 제품 코드 하나를 수정하는데 다수의 실행 가능한 명세를 수정해야 하는 경우이며,
} 장기적인 유지보수 비용을 줄이데 있어 핵심은 산탄총 수술에 유의하는 것이다
9191
89. 기대 효과
9292
} 개발
} 토론을 통해 이해의 격차가 해소될 때까지 예제를 제안하고 해결한다
} 비즈니스 분석가와 논의를 통해 특별한 경우에 대해서도 이해하고 있는지 확인하고 보완한다
} 테스트를 살아있는 명세이자 문서로 활용할 수 있다
} QA
} 사람들이 반복적으로 실수하는 부분에 대해 토론하고 구체적인 예제를 제안하여 해결한다
} 자동화 테스트는 동일한 실수를 방지하는 데 도움이되고 보다 심도 깊은 검증을 할 수 있는 기회
비용으로 활용한다
} 테스트에 대해 처음부터 참여하여 품질 기반을 구축할 수 있다
} 비즈니스 분석가
} 목표에서 범위를 도출하는 데 있어 다양하고 유용한 정보를 수집하고 활용할 수 있다
} 토론을 통해 특별한 경우에 대해서도 이해할 수 있어 완성도 높은 요구사항을 도출할 수 있다
} 리빙 도큐멘테이션은 비즈니스에 대한 검증이자 요구사항의 출발점이 될 수 있다
96. 결론
} 예제를 활용한 명세는 명세를 적기에 공급하는 좋은 방법이고 짧은
이터레이션이나 흐름 기반 개발의 성공을 위한 핵심 요소이다
} 길고 지루한 문서보다 효과적이고 효율적인 의사소통을 강조한다
} 올바른 시스템 명세를 작성하려면 테스터, 분석가, 개발자가 함께 일할
수 있는 연합팀을 만들어야 한다
} 예제를 활용한 명세는 클린코드와 같이 지속적인 관심과 애정이
필요하다
} 예제를 활용한 명세는 비용이 아닌 성공적인 투자이자 경쟁력이다
9999