My scribbling

 

- 진행자 (Erik: PM 에 더 가까운 컨설턴트. 커뮤니케이션 전문가, Lars : CTO )
- 이번 세션의 목표 : 대형 프로젝트에 몸 담았던 엔지니어 간 의견 교환 및 토론으로 문제의 핵심 및 풀이 과정을 만들어 가는 것
-배경 지식 : 참가자들은 agile 방법론에 대한 개념을 모두 이해하고 있고 우리가 말하고자 하는 대상은 offshoring으로프로젝트를 수행하는 large scale프로젝트 임. 현재까지 agile 방식으로 offshore  프로젝트를 수행하는 것은쉽지 않은 경우가 대부분이었는데 그 주된 이유는 offshore 하는 방식은 드는 비용이 싸지만 때문이지만 더 많은 기술적인성숙도를 요구함.

- 토론을 위한GR(ground rule)
 (1) Be constructive no whining.
 (2) Engagement will be rewarded
 (3) it is ok to have unpopular opinions

- 토론 방식 gold fish bowl discussion(금붕어 어항 방식) : 의자를 놓고 의견을 말할때는 반드시 나와서 panel 처럼 행동하고 말해야 함. 제자리에 앉은 채로는 panel에게 질문하는 것만 허용됨

- 참가 패널들 정보 예
 (1) Removing Process (Finland) waterfall process 를 하나하나씩 제거해가는 프로세스 방식을 주도하는 컨설턴트
 (2) 80명의 사람이 7년간 agile 방식으로 offshore 를 수행했음
 (3) 300 명 이상의 offshore & agile 프로젝트를 위한 컨설턴트

***** 서두를 떼는 organizer의 의견 *****
- 대형 agile프로젝트 팀을 구성하는 방법은 보통 작은 팀에서 그 규모를 점점 불려 커다란 agile 팀을 이룬다. 하지만 이는 커뮤니케이션 측면에서 risky 하다.
-Communication의 발전사 : Communication 은 P2P 에서 시작하여 public speaking(빠른 피트백작은 그룹) -> Runes(적는 게 어렵기 때문에 작성자가 매우 생각하고 고민하며 작업) -> Letters& books (feed back 이 어려움) -> telephone (즉각적feed back 이지만 기본적으로는P2P 방식 ->, TV (oneside communication임 ->  email (싸고 효과적인feedback) -> messaging. (only 20% is real communication)

***** panel 의견 *****
 - communication
 (1) 개발의 생산성을 높이기 위하여, 항상 개발자들간 대화하는 환경을 만드는 것이 중요하다. 하지만 개발자들은 혼자 일하는 방식에 익숙하기 때문에 팀간의 대화속에 소프트웨어를 생산하는 방식이 보통 맞지 않는다.
 (2)프로젝트의 생산성과 효율성을 극대화 하기 위해서는 pair programming 을 하며 환경을 noisy 하게 만드는것이 중요한데 이를 위하여는 먼저 personal intimacy(개인간 친화력) 를 높여야 한다. 이것은 pair 끼리점심을 먹거나 커피를 마시는 등의 일로 간주해야 하는 다른 시간에 일어난다.
 (3) 우리에게 중요한 것은 커뮤니케이션의양이 아니다. 커뮤니케이션의 질이 얼마나 높은 가가 중요하다  pair 중 한 명이 집중력이 없어 계속해서 다른 이야기를 하고일에 집중하지 않으면, 그리고 이런 사람들이 다수 존재하면  프로젝트의 전체적인 효율을 줄이게 된다, 이는 프로젝트 전체로 볼때 프로젝트의 분위기를 파괴하는 일이다.
 (4) 이를 위하여는 엄격한 GR(ground rule) 을 세우는 것이중요하다. 쓸데 없는 시간을 줄이기 위해  커피를 마시는 시간까지 일을 하는 시간이다 라는 느낌을 주는 것이 필요하다. 예를들어 커피 자판기 앞에 web cam 을 설치한다. 이 화면은 프로젝트 팀의 사무실에서 볼 수 있도록 항상 on 상태로 두고,프로젝트 팀원들은 이 web cam 앞에서 장난도 치고 좋은 아이디어를 낼 수 도 있지만 이러한 행위가 관리가 아닌커뮤니케이션을 증진 시킬 수 있는 하나의 방법이라는 공감대를 형성하고 좀더 건설적인 대화가 오게 만들수도 있다
 (5) email 로 서로 통신하는 방법은 지극히 P2P인 방법이므로 전체 커뮤니케이션을 저해한다. 전체 mailing list 를 만들어 email 을 보낼때는 항상 전체 메일링 리스트를 이용하게 하는 방법이 좋다
 (6) email 은 관리도 어렵고 보내는 양이 많아질 수 있다. wiki 를 사용하여 전체 커뮤니케이션을 하는 것이 보다 효율적이다
 (7)아까 얘기했던 내용에 대해 첨가하고 싶다. 우리가 오해하는 부분이 있는데, 내 경험에서 보면 사실 pair programming 은 그 집중력이 없고 전체 프로젝트에 파괴적인 영향을주는 사람에게 더 도움이 된다. 둘이 대화하며 일하기 때문에 항상 현재하는 일에 집중하고 개개인을 보다 건설적인 대화로 이끌어줄 수 있다.

 - distributed system with customers
 (8) 시차가 틀린 여러 국가에팀들이 존재하고 이들이 서로 커뮤니케이션해야 하는 내가 있는 프로젝트 는 고객이 onsite 에 상주할 수 없다. 프로젝트내에는 고객 또한 고객의 일이 있기 때문에 고객이 직접 on site 에 있지 않고  이고객과 직접 연락하고 아이디어를 전달 할 수 있는 contact point 를 팀마다 둔다.
 (9) 그러면 미스커뮤니케이션의 가능성이 매우 크질 않은가?
 (10) 물론 미스커뮤니케이션이 존재 할 수 있다. 이는 contact point 가 되는 사람이 보다 자주 고객과 접촉하여 진행 상황이나 화면 interface 를 보여주고  검토한다.

 (11)이런 다국적 off shore 프로젝트의 경우 wiki 의 사용은 극대화 된다. 시차가 워낙 크기 때문에  전화 사용 자체가불가능 할 때, wiki 를 사용하면 모든 이들이 쉽게 원하는 글을 올릴 수 있고 중요한 issue 들을 공유할 수 있다.  내경험으로 재밌는것은  wiki 를 사용하면 프로젝트 내 contributor 가 한 명씩 생기게 된다. 이들은 프로젝트의issue 깔끔하게 정리하고  다른 사람들로부터 고마움을 느끼게 해주는 사람들이다
 (12) 고객과의 접촉 시 한번에 너무많은 요구사항을 받으려는 것은 오히려 해가 된다. 고객의 요구사항은 언제든 변화할 수 있으므로  일단 개괄적인 요구사항을 듣고고객이 당장 어떤 기능이 필요해 질 때 자세한 얘기를 들으면 보다 완벽한 story 를 작성할 수 있다. 개괄적인 요구사항만들은 내용은 우선순위를 뒤로 미루고 다른 story 를 먼저 수행하는 방법을 택할 수 있다
 (13) 그렇다면 performance 같은 non-functional(기능 요구사항 외 성능) 한 요구사항은 어떻게 다뤄야 하는가?
 (14)non-functional 한 요구사항은 내가 있는 프로젝트에서는 이렇게 다룬다. 이는 고객과 대화하는 방법 중 하나이다. 첫번째 스토리를 수행 할 때는 이러한 문제가 issue 화 되지 않을 수 있지만. 8번째 9 번째 스토리가 되면  데이터가많아지고 복잡도가 높아져 이런저런 문제가 발생할 수 있고, 이는 자연스러운 일 일 수 있다. 이러한 상황이 발생하면, 놀래지말고 같이 해결하자. 먼저 문제점이 있을 수 있다는 것을 주지시킬때 고객의 반응은 굉장히 틀리다.
 (15) non-funcitonal 요구사항은 크게 아키텍쳐에 대한 것과 테스트에 대한 것이다. 이는 반드시 고객과 조율하고 넘어가야 한다
 (!6)대형 agile 프로젝트는 여러팀이 일할때 dependency problem 이 발생한다. 어떤 co-work이 일어나고 어떤일이 진행되어야 하는지  정해져 있지 않은 상황이면 특히 더한데, 이를 위하여 어떻게 agile 팀을 발전시키는지가 중요하다. 먼저 소수의 core team 을 만들고 core team 팀원간의 애자일적 커뮤니케이션 체계를 만들고 core team 을여러 팀으로 나누고  애자일 방식으로 이 팀의 크기를 점점 늘린다. 그렇게 하면 완벽한 대형 프로젝트를 위한 애자일 팀이 생긴다.

 - quality and productivity
 (17)보통 CI 의 개념을 사람들이 헷갈리는데 Continuous integration 은 Continuous build 와 틀리다.CB는 그저 컴파일을 수행하는 것이고  CI 는 컴퍼넌트간의 긴밀한 결합이고 문제가 발생하지 않게 만드는 것을 뜻한다.
 (18) 나도 그렇게 생각한다. 대형 프로젝트의 CI는 매일 수행하게 되면 그만큼 커다란 비용이 발생한다. 그러므로 매일 CI를 하는 것이 아니라  어느정도의 조율이 필요하다.
 (19) 시차가 틀린 나라간 off shore 프로젝트의 경우는 어떻게 nightly build 를 하는가? 불가능하지 않은가?
 (20) 이런 경우 daily build 를 수행한다. 굳이 nigtly build 를 수행할 필요는없다.

 (21) A 팀과 B 팀이 있을때 A 팀의 긴급한 수정이 B 팀에 영향을 주리라는 것을 예상할 수 없을 수 있다. 예를 들어 프로젝트 frame work 를 바꾸는 경우 그렇다
 (22) 그건 말이 안된다. framework를 수정하는 것은 팀간 커뮤니케이션이 반드시 선행되어야 한다. 그게 아니라면 잘못된 프로세스이다
 (23) 나도 그렇게 생각한다. 다른 팀에 이야기하지 않고 framework 를 수정하는 것은 프로젝트 전체를 파괴하는 행위이다
 (24) 내가 좀 극단적인 예를 들었다. 그렇다면 frame work 이 아니고 interface 가 변경되었다고 생각해보자
 (이 부분에 이러한 상황을 이해하지 못하는 눈빛을 보내는 여러 사람들을 보았습니다. 난 익숙한데... - -)
 (25) pull 과 push 의 문제가 발생하는 상황인데, 어떤 변화가 또 다른 변화를 야기할 가능성이 있을때 서로 반드시 커뮤니케이션을 해야 한다 그게 룰이다.

이 글들은 더 생각나는게 있을때마다 업데이트를 하겠습니다