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
