📋 목차.
2. 함께
.소프트웨어 관리자의 개선 우선수위
.협력을 통한 추상화
.신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
.하향식 접근의 함정
.전문가팀이 실패하는 이유
.구글이 밝힌 탁월한 팀의 비밀
.쾌속 학습팀
.프로젝트 확률론
✔️ 내용.
2. 함께
스터디를 진행할 때면 각각 파트를 분리하고 후에 합쳐서 보게 되는데 속을 들여다보면 협력은 거의 없다고 볼 수 있다.
이 장에서는 협력 방법을 배우고 수련하는 파트이다.
.소프트웨어 관리자의 개선 우선수위
조엘 테스트라는 것으로 '개발팀 평가 테스트'가 다음과 같이 있다.
1. 소스 컨트롤을 사용하는가?
2. 한 번에 빌드를 만들어낼 수 있는가?
3. 일일 빌드를 만드는가?
4. 버그 데이터베이스를 가지고 있는가?
5. 새로운 코드를 작성하기 전에 버그를 고치는가?
6. 최신 업데이트된 스케줄이 있는가?
7. 스펙(제품 명세)이 있는가?
8. 프로그래머가 조용한 작업환경에서 일하는가?
9. 돈이 되는 한 최고의 툴을 사용하는가?
10. 테스터가 있는가?
11. 채용 면접 때 후보가 코드를 짜게 해 보는가?
12. 복도 사용성 테스트(조직 내에서 복도에서 아무나 지나가는 사람을 잡아다가 하는 사용성 테스트, 무작위 사용성 테스트)를 하는가?
위 12가지 항목에 "예"라고 대답하면 "완벽하다"라고 조엘은 말한다. 하지만 각 질문의 맥락을 이해하지 못한 채 단순히 예라고 답하는 것을 목표로 노력하는 경우에는 책의 저자는 완벽하다 하지 않는다.
- 모든 항목에 "예"라고 답하는 것이 무조건 더 낫다고 동의하기 어렵다
가령 8번을 보면 조용한 공간에서 일해야 몰입이 가능하기 때문에 8번이 중요하다 한다. 하지만 애자일 콘퍼런스에서 <피플웨어> 저자들은 그룹 차원에서 몰입이 가능하며, 팀원들이 상시 대면 의사소통을 할 수 있는 공간이 생산성 향상에 많은 도움이 된다고 역설한 바 있다. 그래서 개발자 개개인에게 독립된 사무공간을 주는 방법 외, 팀 전체가 공유할 수 있는 '시끄러운' 공간을 주는 것도 생산성 향상에 도움이 된다 주장한다.
9번 을 보면 '돈이 허락하는 한에서의 최고의 툴'이 있다. 소프트웨어 툴의 경우 단순히 비싼 게 뭐냐를 기준으로 툴을 고르지는 않는다.
앞선 내용과 같이 다른 테스트 항목들도 단순히 "예"라고 해서 좋은 평가라 할 수 없다. 맥락에 따라 오히려 좋지 않을 수도 있다.
- 12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?
품질 전문가 제럴드 와인버그가 한 말을 살펴보면 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다 했다.
1. 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
2. 관찰하는 능력으로, 무엇이 벌어지고 있는지 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
3. 행동하는 능력으로, 어려운 대인 상황에서 적절하게 행동할 수 있어야 한다.
제럴드 와인버그가 쓴 책으로 품질 소프트웨어 관리(QSM) 이 있다. 이 책중 소프트웨어 개발 비용에 관한 내용으로 개발비용을 결정하는 요소가 무엇일까 하는 질문에 네 가지를 다음과 같이 두었다.
1. 도구 : 소프트웨어 개발에 사용하는 모든 종류의 도구. 컴퓨터, 모니터, 버그 트래커, 디버거, IDE, 하향/구조적 개발 기법 등
2. 사람 : 사람들의 능력과 경험
3. 시스템 : 제품 자체의 복잡도, 요구되는 신뢰성, DB 크기, 타깃(VM 등)의 변화 가능성, 스케줄 제약 등
4. 관리 : 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기 고취, 작업 조건/환경 개선, 자원 준비, 리스크 빠른 조치, 요구사항과 설계 스펙이 비준되게 돕는 것 등
위 항목들의 개선을 통해 영향을 얼마나 주는지 나타내면 다음과 같다.
도구를 개선했을 때는 3배가량의 비용 개선이 이뤄지지만 관리를 개선할 경우 64배 정도의 개선을 이뤄낼 수 있다.
하지만 관리자들이 선호하는 개선 노력은 역순이다. 일단 도구 개선부터 시작해서. 자기 자신(관리)을 바꾸는 것은 맨 나중으로 두게 된다.
다시 조엘 테스트를 보면 절반이 넘는 문항이 '도구' 분류에 들어간다. 조엘 테스트는 가장 만만하고 쉬운 것(자신에게서 가장 먼 것)부터 시작하는 관리자의 성향과 충돌하지 않는다. 이것이 필자가 조엘 테스트가 위험할 수 있다고 생각하는 이유이다.
소프트웨어 개발 관리자는 어떤 소스 컨트롤 툴을 사용할지 고심하는 것 외에도 자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 출발이 되지 않을까 한다.
.협력을 통한 추상화
자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고 대화를 해라. 같이 그림도 그려(시각화) 보고 함께 소스코드(짝 프로그래밍)를 편집해라.
- 커뮤니케이션과 협력
여태 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 소프트 스킬이었다. 이는 커뮤니케이션과 협력 능력 같은 것들이다. 일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다. 게다가 이 소프트 스킬에 더 오랜 시간을 들인다. 반면 설계나 코딩, 테스팅에 들이는 시간에는 통계적으로 큰 차이가 없다.
.신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다. 이러한 신뢰를 쌓는데 널리 사용하는 한 가지 방법은 투명성과 공유, 인터렉션이다. 자신이 한 작업물을 투명하게 서로 공유하고 그에 대해 피드백을 주고받으며 인터랙션을 하는 것이다. 조직에서 신뢰를 연구하는 사람들은 이런 것을 소통 신뢰라고 한다.
- 공유 조건별 신뢰도 변화 실험
하나 공유, 최고 공유, 복수 공유 3가지의 공유 조건이 있다.
하나 공유 : 한 가지 작업을 해서 공유
최고 공유 : 복수개 작업을 해서 본인이 가장 잘했다 하는 작업 공유
복수 공유 : 복수개 작업을 해서 모두 공유
위 공유 과정에서 하나 공유와 최고 공유는 서로 간의 신뢰가 감소하게 되는 결과가 나왔다. 이러한 공유는 기대감보다 불안감을 갖기 때문이다. 작품이 하나이기 때문에 '작업물 = 나'가 되기 때문이다.
- 복수 공유의 장점
복수 공유의 경우 말하는 사람이 여러 개의 작업물이 있기에 작업물에 대해 말하기도 편하고 듣는 사람도 좋다는 이야기와 좋지 않다는 이야기를 같이 들으니 마음이 좀 더 편하다.
놀라운 부분은 복수 공유를 통해 나온 결과물이 다른 두 가지 조건(하나 공유, 최고 공유) 보다 평가와 실적이 좋게 나왔다.
복수 공유는 신뢰도 높아지고 성과도 더 좋았다.
.객관성의 주관성
상대방에 대해 이해하고 있지 못하면 애자일 같은 새로운 개념을 전파하는데 성공률이 매우 낮다고 본다.
- 품질은 상대적이다
품질이란 누군가에게 가치가 되는 것이다.
- 제럴드 와인버그 (품질 전문가)
객관적 자료를 통해 설득을 진행하여도. "당신의 생각이 틀렸다"라는 암시가 강하게 있다면 설득은 어렵다.
- 감정을 배제할 수 없다.
우리는 의사결정을 하는 과정에서 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적인 부분이 배제된다면 의사결정을 제대로 할 수 없다.
논리적인 근거 자료를 수집하고 측정에 시간을 쏟는 사람들에게 "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보았나요?"를 먼저 조언을 드리고 싶다.
.하향식 접근의 함정
더 높은 품질을 얻기 위해서는 오르락내리락하는 게 중요하다. 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이다.
흔히 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 프로젝트 기간 내 얼마씩 배치할까로 고민하지 않고 어떻게 해야 첫 달, 아니 첫 주부터 분석, 설계 구현, 테스트, 전개를 모두 왔다 갔다 할 수 있을까를 고민해야 할 것이다.
.전문가팀이 실패하는 이유
팀 내에 개인 내 다양성이 높은 멤버가 없다면 전문가로 구성된 팀은 정보 공유가 잘 안 되어서 성과가 떨어질 수 있다.
정리하면
1. 전문가들 모아서 팀 만든다고 잘하는 것은 아니고
2. 오히려 성과가 떨어질 수 있고
3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.
.구글이 밝힌 탁월한 팀의 비밀
구글이 찾은 뛰어난 팀의 특징 중 중요한 부분 세 군데는 다음과 같다.
1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다.
3. 팀 토론 등 특별히 고안된 활동이 을 통해 심리적 안전감을 개선할 수 있었다.
여기서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말한다. 측정 도구로는 다음과 같다. 일부는 역질문이 포함되어 있다.
1. 내가 이 일에서 실수를 하면 그걸로 비난을 받는 경우가 많다.
2. 이 조직에서 남들에게 도움을 구하기가 어렵다.
3. 내 관리자는 내가 전에 한 번도 해보지 않은 걸 해내는 방법을 배우거나 혹은 새로운 일을 맡도록 격려하는 경우가 많다.
4. 내가 만약 다른 곳에서 더 나은 일을 구하려고 이 회사를 떠날 생각이 있다면 나는 그에 대해 내 관리자랑 이야기를 나눌 것이다.
5. 내가 나의 관리자에게 문제를 제기하면 그는 내가 해결책을 찾도록 도와주는 일에 그다지 관심을 보이지 않은 경우가 많다.
이 모든 것보다 중요한 것은 일상적으로 벌어지는 인터렉션에 변화를 가져야 한다. 이러한 것들로 신뢰를 쌓아가야 앞서 나온 '특별히 고안된 활동'을 시도할 수 있다.
팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터렉션을 보여주고 있는지 생각해보자.
.쾌속 학습팀
- 패러다임 전환, 죽느냐 사느냐
PHP에서 급변하기 Java로 변환하고자 하는 기술적 변화 순간은 언제든 찾아올 수 있다. 이름하여 패러다임의 전환. 더군다나 IT 업계에서는 이런 전환 주기가 특히 짧은 편인다. 개발자들에게 학습이라는 것, 더 나아가 빠른 학습이란 무엇일까
- 학습 환경의 차이
학습이 빠른 팀은 팀원을 뽑을 때부터 다르다. 선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라 (예로 디자이너를 뽑는데 개발자가 관여한다), 선발 기준도 달랐다. 단순 업무 수행 능력뿐 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았다.
또한 속도가 빠른 팀은 기술적 도전이라기보다는 조직적 도전으로 받아들인다. 개개인이 새로운 기술을 획득해야 한다 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.
마지막으로 속도가 빠른 팀은 심리적으로 보호가 되고 있다. 새로운 것을 제안하고 시도하는 데에 열려 있고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다.
- 현실에서 실천하기
우선 자신의 학습 환경을 만든다. 거기부터가 출발이다. 개별 기술 이상으로 일하는 방식에 대해 실험해 본다. 실험이 실패한다고 좌절하지 말고 학습과 일을 굳이 분리하지 말고 동체로 만들어라. 학습과 실행은 하나이다.
언제 시작할지 계획을 짜지 말고 당장 시작해라. 지금 당장 하지 않으면 장차 할 확률은 절반 이하로 떨어진다.
일단 30분만 업무 개선을 시도해 본다. 이 부분에 이르면 워드 커닝햄의 명언을 인용하지 않을 수 없다.
작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다.
- 워드 커닝햄
이 말의 힘을 느끼려면 정반대를 생각해 보아라. '크고 쓸모없는 설계를 가끔 생각해 본다면' 학습 속도를 높이는 데에 얼마나 도움이 될지.
그리고 학습 공동체를 구축하라. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아보아라. 그것이 쾌속 학습으로 가는 지름길이다.
.프로젝트 확률론
- 애자일 확률론
대다수의 관리자들은 각자에게 한 가지씩 일을 할당하는데. 이 경우에 병렬 진행이 최대화될 수 있다고 보기 때문이다. 하지만 이것이 최고의 코드로 가는 가장 빠른 지름길인가? 그렇지 않다고 본다.
여기서 선호하는 접근법은 관리자가 12명 모두에게 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것이다. 그 일들이 완료되면 3개를 더 만들어낸다. 사람들은 작업을 완료하기 위해 자기 조직화할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 '관심사의 섞임'을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문이다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법은 불리해진다.
애자일은 앞서의 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다. 애자일에서는 되도록 사람들이 섞이도록 하자.
애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는'확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾸는 경향이 있다. 좋은 일은 공유를 해서 한 사람만이라도 중요한 통찰이 있었다면 이걸 공유해서 '또는' 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서(짝 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 '그리고' 확률로 바꾸는 것이다.
📝 느낀점.
- 전반적으로 이번 장의 목표와 같이 '협력'에 대해서 어떤 식으로 접근해야 하는지 방법을 알게 되었다.
- 신뢰를 쌓고, 모든 것을 공유하고 상대방을 이해하고자 하자. 이를 통해 공동체를 구축해 애자일 적으로 접근해보자.
'Study > 함께자라기' 카테고리의 다른 글
| [Study][함께자라기 - 1] 3. 애자일 (0) | 2022.08.28 |
|---|---|
| [Study][함께자라기 - 1] 1. 자라기 (0) | 2022.08.28 |
| [Study][함께자라기 - 0] 계획 (0) | 2022.08.18 |