Workshop 2nd day

살리고 철학

개발에 가장 많은 cost를 차지하는 것이 maintenance - 버그를 고치거나 기능을 추가하거나.

버그
- 버그를 찾아서 고칠때까지의 기간을 추정하기가 힘듦. variance가 있기 때문.
- cost: 버그를 고치는데 걸리는 시간에 exponential 하게 비례하여 증가
- 버그를 줄이는게 개발기간을 줄이는 방법이 될 수 있음.
버그를 줄이기 위해선 - 자주 확인하는게 중요.
- 자주확인하면 할 수록 오버헤드가 있을 수 있다.

이 코스트를 줄이기 위해서는: "작동하는 상태에서 작동하는 상태로 가는 것."

	working	not working
working	제일 안전
not working		제일 위험

w->w 인 경우에는 계속 돌아가는 상태이므로 어느지점에서 틀렸는지 scan할 region이 줄어듦. 개발자의 입장에서는 스트레스가 없음. 편안히 개발 가능.
nw -> w 인 경우, w -> nw 인 경우는 잠시 거칠 수 있음.
nw->nw: 작동 안하는 프로그램을 계속 만지고 있는경우......

- 한번 컴파일하면 에러작렬;, 에러 안나면 더 불안하고......................OTL

- 나중에 조삼모사가 아니라 조삼모'천'이 될 수 있다.

소프트웨어도 추가(additive)가 아닌 분화(differentiation)가 되는 것이 좋다.

손가락이 엄마 뱃속에서 엄지->검지 순으로 차례대로 자라는 것이 아니라 한꺼번에 서서히 자라나는 것처럼.

부담이 커지면 일을 미루게 된다.

사용자 요구 분석

ex) 인터넷 서점

가로축: 어떤 role(목적)이 있는가?
세로축: task / function (인터넷 서점에서 하는 행동들)

		Role
		제목만 훑어보는 사람	선물하려고 하는 사람	원하는 책(전공서,...)을 알고 사려고 하는 사람	한가지 책을 대량구매하는 사람	특정 주제로 책을 찾아보는 사람	책 수집가	이벤트 서적을 찾는 사람	가격비교 (실제 서점과 인터넷 서점)	누적된 포인트	상품권이 생겨서 그냥 들어와본 사람	구매후기만 읽는 사람
Task / Function
	로그인
	검색
	책 구입
	회원가입/탈퇴
	장바구니에 책을 담기
	구매후기 작성
	쿠폰 다운로드
	표지 이미지/ 책일부내용 보기
	책 구입취소

task별로 공통적인 것들끼리 묶어서 클러스터링

- role에 거의 해당되는 것들은 가장 나중으로 내림. ('검색' 같은 것)

- 클러스터링 된 애들을 포괄하는 큰 이름 짓기

세로(task/function) 클러스터링

- 들어가기 (로그인, 회원가입/탈퇴)

- 구매 (쿠폰다운, 책 결제, 구입취소)

- 제품상세 (책 이미지/내용, 장바구니)

- 구매후기작성

- 검색

가로(role) 클러스터링

- (원하는 책, 대량구매, 책소장, 도서상품권/포인트)

- (선물하려는 사람, 특정주제)

- (후기)

- (가격비교)

- (제목)

- 이벤트

위의 클러스터링을 통해 insight를 얻을 수 있다.

고객 타겟을 얻을 수 있고, 그 고객들이 하는 행동들도 알아볼 수 있다.

사용자 스토리

사용자에게 가치를 줄 수 있는 방향으로 적는 요구 분석서.

form: <내가 ~로써 ~을 하기위해 이것을 한다.>
                                    e.g. 나는 원하는 책을 정확히 아는 사람으로써 책을 구매하기 위해 검색을 한다.

사용자의 관점에서 요구분석 수행
내용을 적어놓는 카드가 하나의 대화수단이 되는 것.
CCC (Card, Conversation, Confirm)
사용자로써 이 사이트를 쓸 때 할 수 있는 모든 행동들

카드에 모두 적은 후에는,

가로: 시간축
                                    세로: 빈도 (더 많이 쓰냐 적게 쓰냐) Jason 05:57, 5 August 2008 (UTC)

에 따라 배치한다.

-> 기능 리스트가 된다. 구체적 설계는 아니지만 전체적으로 사용자 관점에서 해야할 일을 알 수 있다.

-> 사용자를 위해 어떤 기능을 먼저 개발해야 하는지를 알 수 있다.

그 이후 카드들을 사용자가 이 행동을 함으로써 가치가 있는 단위로 묶는다.

그 후 얼마동안 개발될 것인지 추정하기
- 스토리 포인트:
  - 각각의 스토리들을 기간이 아닌 사이즈(일의 양)로 계산. 사이즈가 작을 수록 추정하기가 쉽다.
  - 피보나치 수열을 사용(1, 2, 3, 5, 8, 13, 20, 무한대) - '20, 무한대'는 변형
    - e.g. 로그인: 1, 회원가입: 2
  - 게임을 통해하는 방법
    - 어떤 일에대해 동시에 사이즈를 외친다. 가장 높은 사이즈와 낮은 사이즈를 부른 사람이 왜 그렇게 생각했는지 의견을 듣는다. 어떤 기능을 추가/삭제 하려고 했는지 설명을 듣게 됨으로써 동시에 프로그램 설계도 가능해진다.
- 보통 2주 정도 걸릴 것이다- 라고 추정하면 한달 반이 걸린다고 한다. 그러나 이 일이 다른일에 비해 얼마정도 더 걸릴 것이다- 라고 상대적으로 추정하는 것은 거의 정확하다고 한다.
- 추정의 목적: the destination is not as important as the conversation occured between the people.

agile의 중요원칙 -> 중요한 일을 먼저한다. -> 그렇게 함으로써 중요한 가치들을 얻을 수 있다.

전통적인 방식	agile
가치 \| \| / \| / \| ㅡㅡㅡㅡㅡㅡㅡㅡ/ +-----------------------> 시간	가치 \| \| /ㅡㅡㅡㅡㅡㅡㅡㅡㅡ \| / \| / +-----------------------> 시간

outside in s/w development
- 대부분 s/w개발시 개발자 입장에서 하게됨.
- agile은 기본적으로 사용자 입장에서 개발을 하는 것.
- 나를 위해 개발할 때: 생각을 많이 함. 뭐가 필요하지, 왜 만드는 걸까, 해내야 하는 일이 뭘까...
- outside in 방법을 쓴다면 나를 위해 개발할 때의 1/10의 노력으로 90%이상의 가치를 얻을 수 있다. 그것을 발견하는 방법은 outside in 으로 생각해보는 것.
- 늘 하던대로, 개발 중심으로 생각을 한다면 '개발계획을 지키는 것'이 목표가 됨.
- 개발을 할때 고객이 이런 실수를 왜 하게될까? 이런것도 생각해보고...

릴리즈 플래닝 (release planning)

- 릴리즈 할 때까지의 일들을 사용자스토리로 적어본다.

- 팀원이 각자 할 일이 아니더라도, 전체적으로 어떤 일들이 이루어지고 있는지를 이해할 수 있다.

iteration planning

한 이터레이션동안 몇 point의 일을 할 수 있을지 정한다. 최대 그 포인트만큼 되도록 각 카드를 그룹짓는다. 가장 중요하고 효과가 큰것부터.

e.g. 한 이터레이션(예: 2주 혹은 한달)동안 13point의 일을 할 수 있다고 한다면, 각 카드의 포인트를 더해서 최대 13이 넘지 않도록 일을 분리한다.

한 이터레이션(2주)동안 5, 3, 3 point의 3가지 일을 한다고 하자. 2주후에 3포인트 일 한가지만 100% 완료되었다면, 우리의 일하는 속도는 3포인트가 된다.

그렇게 되면 다음 iteration에 할 수 있는 일은 최대 3point의 일밖에 못하는 것.

13점이 넘는 일은 13점이하가 되도록 다시 쪼개야 한다.

릴리즈 플래닝을 한 후 iteration을 정하면 다 뒤섞이는데?
- 릴리즈를 하면 일의 흐름을 알 수 있고, 그 것을 기반으로 일정기간동안 어떠어떠한 것을 묶어 개발하면 좋겠다- 라는 식의 슬라이싱을 하게 되는 것.

즉, 사용자 관점인 릴리즈 플래닝을 기반으로 하여, 개발자 입장에서 iteration으로 일을 슬라이싱하는 것.

그 후 정말 그 기간동안 나눠진 일을 할 수 있을까 생각해 본다.

e.g. 한달 동안 '사용자 히스토리 남기기', '확장된 network를 여러형태로 저장하기' 를 개발할 수 있을까?

실제 개발할 때는 한 이터레이션이 끝난 후 이후 iteration 계획을 수정할 수 있다.

iteration 회고

To do (할 일)
                                    doing (하는 일)
                                    done (한 일)

로 섹션을 나누어 카드를 붙인다.

실제 그 카드의 일을 끝내기 위해 해야하는 모든 작업들의 단위를 포스트잍 같은 데에 적어서 카드 아래에 붙인다.
- 이 작업은 하루안에 끝낼 수 있는 단위별로 나누어 붙인다. (일을 하면서도 추가적으로 붙일 수도 있고 뺄 수도 있다.)
한 이터레이션 동안의 일들을 넣었다 뺐다 하면 안된다. 그냥 정해진 일을 끝까지 해보기.
interrupt 칸을 둔다. 그래서 priority가 높은 다른 일이 생겨서 일을 못하는 경우, 어떤 일 때문에 몇시간을 썼는지 일이 생길 때마다 포스트잍에 써서 붙인다.
burn-down chart
- 그래프를 그린다. 가로축에 한 iteration기간, 세로축에 전체시간을 두고 하루의 일이 끝나면 그 시간만큼 줄여가면서 그래프를 그린다.
- e.g. 전체 이터레이션 시간이 200시간이고 오늘 20시간의 일을 했다면 180으로 줄이기. 점점 감소하는 그래프가 그려진다.
이것을 기반으로 stand-up meeting을 진행한다. (시간을 짧게 하기 위해 다함께 일어서서 회의) 이슈거리는 따로 회의 시간을 잡도록 하고, 이 때에는 다음의 세가지만 이야기 한다.

1) 전날, 스탠드업미팅에서 지금까지 내가 한일
                                    2) 내가 지금 스탠드업미팅부터 다음 스탠드업 미팅까지 할일
                                    3) 내가 작업하는데 있어 어려운 일.

이야기 하면서 각 포스트잍마다 일의 담당자, 얼마나 시간이 걸릴지 (최대 6시간) 적고, 실제 끝날 때 실제 끝난 시간을 적고, (끝낸 시간 * 인원수)를 해서 적는다.

각 작업이 모두 끝나면 포스트잍들을 모아서 카드에 붙여서 done에 놓는다.
작업이 끝나지 않아서 남게된 경우, 회고를 할 때 왜 그렇게 되었는지 근본적인 원인을 알아낸다.

니가 일을 제대로 하지 않아서야, 가 아니라 왜 그렇게 되었는지를 파헤치기.

five-whies: 다섯번 질문하기

왜 일을 제대로 못했을까? -> 담당자가 아팠다. 
                                    왜 아팠을까? -> 일이 많았다.
                                    왜 많았을까? -> 관리를 혼자 하고 있었다. 
                                    왜 혼자 할까? -> 혼자할 수 있을꺼라고 생각했으니까. 
                                      => 해결책: 관리자를 2명을 두자.

이런방식

이러한 플래닝들에 익숙해지면 점점 플래닝 시간이 줄어들게 된다.

원격지 작업인 경우

릴리즈 플래닝은 함께 하고, 이터레이션 플래닝은 따로 하는 방법.
위키같은 것을 이용해서 플래닝들을 공유하는 방법. 이슈트래커 같은 tool들을 이용하곤 한다.
- 위키 같은 것은 업데이트가 되어도 사람들이 확인을 안하는 경우가 많지만, 보드 같은 것을 이용해서 카드 등을 붙여놓고 일을 진행한다면, 언제나 확인가능하다는 점 등 훨씬 좋다.

원격지 pair하기

스카이프 등을 이용
- 각자 헤드폰을 쓰고 음성통화
윈도우즈 넷미팅
- 화면공유 & 여러명이 컨트롤 가능
경험이 있으면 쉽다.
일정기간은 모여서 개발한 후 원격개발하는 방법을 사용하기도 한다.
가끔 한번씩이라도 만날 기회가 있으면 더 좋다.

다른 전공자와 pair할때

어떤 부분은 꼭 개발해야하고, 어떤부분은 할 필요가 없는 일인가를 알 수 있다.

즉, 개발의 적합한 지점을 찾아낼 수 있다.

의사소통 모델

전통적 모델

- 활과 화살 모델

agile

- 삼투압적 의사소통

- 내가 흘린 정보가 널리널리 퍼져나간다!

Agile Development for Bioinformatics (bioxp) 2008

Contents