Workshop 6th day

의견 충돌이 발생한다면?

limited consensus로 투표하기

- 의사결정시: Yes, No, 견딜수 있다(내키지는 않지만 따라갈 수 있다).

결정이 늘어지는 이유는 그 것이 "중요한 결정"이라고 생각하기 때문이다.

-> "가벼운" 결정으로 바꾸기

e.g. 웹서비스에 social network기능을 넣을지 말지에 대한 결정
                                    :: -> 'social network를 가장 간단하게 만들어서 그 결과로 평가해보자.' 로 바꿔본다.

agile은 '학습'을 중요하게 생각한다.
- 즉, 일단 해보자는 방향으로.
- 줄일 수 있을만큼 간단하게 만들어서 실험을 해보기.
  - social network를 만들자 vs. game을 만들자

-> 둘다 조그맣게 만들어서 실험해보기

* 실험을 해라.

사람들은 실험하지 않고 논쟁을 한다.

논쟁에서는 학습할 수 없고 결정이 나지도 않는다.

실험을 해서 많은 것을 배워라.

함께 이야기 하기

발언이 한 쪽으로 몰리고, 이야기를 하지 않는 사람이 생긴다면?

창의성이 부족할 때에는 구조(structure)를 집어넣어라.

백지에서는 창의성이 나오지 않는다.

도구 사용하기(약속 정하기)
- talking head: 이걸 잡아야 발언을 할 수 있다.
- timer: timer를 맞추고 시한폭탄처럼 들고 말하기. 시간이 다되면 하던 말도 중단한다.

작은 그룹 만들기
- 이야기를 안하는 사람들은 그룹이 작아질수록 이야기를 많이 하게 된다.
- 그룹을 나누어 이야기를 한 후 합쳐보자.

TDD의 starting point 잡기

김밥을 분해하는 방법

+-----|----|-----------|--+
                                    |     |    |           |  |         이렇게 자르면 크기는 다 다르다.
                                    +-----|----|-----------|--+         그러나 각 조각의 내용물은 모두 같다.
                                    
                                    
                                    
                                    〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓           
                                    〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓           구성요소별로 분해가 가능.
                                    〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓            - 당근, 단무지, 계란, ...

위의 예제처럼 숫자야구를 분해해보면,

  3 1 2 3            1 2            size를 줄여 test하기 (김밥 자르기)
                                      2 1 4 5      ->    2 1            -> 크기를 줄여도 있을 건 다 있다.
                                     
                                    
                                    
                                      배열1 -------□---------           김밥을 분해하는 것과 같은 것
                                      배열2 -------□---------

=> 문제를 이렇게 두 가지로 나누어 생각해 볼 수 있다.

뭐가 더 좋을지는 문제마다 다르다.

return 값의 의미를 생각해보기. (왜 이런 return이 나오는지..)
- return 값이 true && true때 각 true의 의미나, 왜 && 조건이 되었는지 등등..

김경수님의 luhn 알고리즘 TDD예제: 예제보기
- luhn 알고리즘을 어떻게 TDD로 짰는지 살펴본다.

지식이나 이해도가 다른 사람들끼리 액션플랜 정하기

논쟁하여 설득하려고 하지 마라.
일을 하면서 이해시키는 것이 좋다.
TO DO list를 만든다.

- assert test 해보기

- 함수가 되는지 test하기

- ...

이런 것들을 해보면서 코드로 이해하는 것이 좋다.

직접해보면서 communication하는 것이 좋다.

가능하다면 소수로 시작. 사람이 많으면 거기서 오는 overhead가 있다.
- 그것이 힘들 때:

- 나랑 pair할 사람들과의 계획은 대충, 동떨어진 사람들과의 계획은 좀 자세히.

- 잘 모르는 사람들이 할 수 있는 수준의 일부터 하게 한다.

-> 견습생이 단추다는 일부터 하는 것처럼

- 혹은 모르는 것은 찾아와 물어보게 하고 일단 일을 시킨다.

-> 첫 세션에서는 비효율적으로 일했을 수도 있지만, pair를 자주 바꾸면 지식이 전파된다.

변화를 유지하는 방법

변화하는 것은 쉽다.

변화를 유지하려면?
- Commitment (공약)

- 다른 사람에게 말하기

Accountability

- 다른 사람에서 설명이 가능해야한다.

-> 블로그에 적는다던지...

Community

- 공유한다.

곰돌이와 코딩하기

일전의 연구내용 중,

코딩을 할 때 옆자리에 곰돌이를 앉혀놓고 하게 했다.
                                    모르는 것이 있으면 곰돌이와 먼저 상의하고, 그 후 찾아오게 했다.
                                    실험자의 70%는 곰돌이와의 대화에서 문제를 해결했다고 한다.

페어가 좋다는 이야기. 곰돌이와 즐프하세요~>_<

Agile Development for Bioinformatics (bioxp) 2008

Contents