범위 : [9장 실용주의 프로젝트]
태그 - TIL, nomadcoder, 개발자북클럽, 노개북, 서평, 책
실용주의 프로젝트
Topic 49 실용주의 팀
제멋대로이고 독립적인 사람들이 모인 팀에서도 실용주의 기법을 적용할 수 있을까 ? 대답은 "그렇다!"이다. 개인이 혼자 실용주의를 따라도 이점이 있지만, 그 개인이 실용주의 팀에서 일한다면 그 잇점이 몇배로 더 커진다.
실용주의 팀은 작다. 구성원은 10~12명, 한 부서의 50명은 그저 비내리는 날 버스 정거장에 비를 피하는 낯선사람들일 뿐이다. 구성원이 추가되거나, 빠지는일은 드물어야 하며, 모두가 서로 잘 알고, 신뢰하며, 의존해야한다.
깨진창문을 없애라
팀전체가 깨진창문을 용납하지 않아야한다. 사소한 결점을 아무도 고치지않고 놔두어서는 안되고, 반드시 제품의 품질에 책임을 져야한다.
품질은 팀원 모두 제각기 기여할때만 보장된다. 품질은 제품에 포함된 것이지 나중에 덧붙이는것은 아니다.
삶은개구리
팀은 개인보다 삶은 개구리가 되기쉽다. 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청반경 사항을 팀 리더가 이미 동의했겠거니 하고 여긴다. 아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다.
-
모든 사람이 적극적으로 환경변화를 감시할것
(범위확장, 일정단축, 추가기능, 새로운 환경 등)
-
새 요구사항에 대한 수치를 관리할것
(변화하는 와중에 파악하고 있어야함)
지식포트폴리오를 계획하라
"시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다."는 것이다. 할 일을 백로그로 관리하든 업무 목록이나 업무 흐름 도구를 사용하든 간에 기능 개발로만 몽땅 채우지는 말라. 새로운 기능을 만드는 것 외에도 해야할 일들이 있다.
- 구형 시스템 유지보수
- 프로세스회고와 개선
- 새로운 기술 탐험
- 학습 및 기술 갈고 닦기
팀의 존재를 소통하라
외부사람들에게 무뚝뚝하고 과묵해보이는 프로젝트팀은 최악이다. 그런팀의 회의는 아무런 체계가 없고 침묵만 가득하다. 이메일과 프로젝트 문서는 엉망진창이다. 문서마다 생김새가 제각각이고, 서로다른 용어를 사용한다.
훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 팀이 하나로 의사소통 잘되게 도와주는 간단한 마케팅 비결이 있다. 프로젝트를 시작할때 이름을 지어주는것이다. 유별난 이름이면 더 좋겠다. 바보같이 들리겠지만 팀은 정체성 확립의 기반을 얻을 것이고, 기억할만한 뭔가를 얻을것이다.
반복하지말라
좋은의사소통으로 문제를 피하는 것이 핵심이다. "좋은" 이란 즉각적이고 매끄러운것 을 말한다. 팀동료에게 질문하고 즉각적으로 답변을 받을수 있어야한다. 매끄럽다는 것은 질문하기, 진행상황이나 문제, 통찰 및 새롭게 알게된 사실을 공유하기, 또 동료가 뭘 하고 있는지 알고 있기 쉽고 거추장스러운 단계가적다는 뜻이다. DRY를 지키려면 서로 관심을 유지해야한다.
팀예광탄
몇몇 방법론은 팀 내에 오만가지 역할과 직함을 만들라고 하거나, 아예 완전히 특수조직을 만들라한다. 이런 접근방식의 문제는 '관문'과 '인수인계'를 추가한다는 것이다. 이렇게 되면 팀에서 배포까지 흐름이 순조롭게 이어지는 대신 업무가 중단되는 인위적인 관문이 생긴다.
인계가 완료될때까지 기다려야한다. 승인이며 문서 작업은 또 어딘가의 방식을 따르는 이들은 이른것을 낭비라고 부르며 없애기위해 적극적으로 노력한다.
처음엔 작고 제한적인 기능밖에 만들지 못하더라도 시스템의 끝에서 끝까지 전체에 걸쳐있는 단일 기능을 개발할 것을 추천한다. 처음에는 아무리 작고 제한적인 기능밖에 만들지 못하더라도 그렇다. 예광탄 접근 방법을 사용하면 기능의 아주 조그만 부분을 아주 빠르게 개발할 수 있다. 또 잘 소통하고 결과물을 만들어내 즉각적인 피드백을 받을 수도 있다. 우리의 팀프로세스를 빠르고 쉽게 바꾸고 조율할 수 있는 환경이 만들어진다. 코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어야한다.
Topic 50 코코넛만으로는 부족하다
화물 숭배? 눈에 잘띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나있기를 소망하는것을 말한다.
맥락의 중요성
유행하는 것이 아니라 실제로 잘 맞는 것을 사용해라
"잘맞는 것"을 어떻게 알 수 있을까 ? 가장 근본적인 실용주의 기법을 적용하면된다. 작은팀 하나에서 아이디어를 시험해 본다고 할때, 잘 맞는것은 좋은 부분만 유지하고 나머지는 낭비나 비용뿐이므로 버려야한다. 앞으로 성장하고 수년이 지나면 회사들도 성숙하고 사업방향을 선회하고 계속번창함에 따라 이들 역시 또 다른 방식을 사용하고 있을것이다. 이것이 회사들이 성공한 진짜 비결이다.
만병통치약은 아무도 못고친다.
우리에게 필요한 것은 암기가 아니다. 기존 규칙 너머를 보고 개선의 여지를 찾아내는 능력이 필요하다.
어떤 특정한 방법론에서 가장 좋은 부분만 가져다가 적절히 조절하여 사용해야한다. 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다. 그러니 인기있는 방법론 하나만 쫒지 말고 다른것들로도 눈길을 돌려야 한다. 진짜 목표로, 작동하는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는것이다. 몇달, 몇년후가 아닌 바로 지금.
진짜목표
지속적 배포가 이상적이지만 도달 불가능한 목표라고 생각하는 팀이나 조직이많다. 특히 배포를 몇달 내지 몇주에 한번 제한하는 프로세스를 따르고 있다면 더욱 그럴것이다. 하지만 모든 목표가그렇듯 계속 올바른 방향을 바라보는 것이 중요하다. 몇달에서 몇주, 4주단위에서 2주로, 2주에서 1주로 줄여보자. 그리고 하루로 마지막 필요할때마다 출시하는것을 목표하라.끊임없이 배포한다는 뜻은 아니다. 사용자가 필요로 할때마다 사업적으로 배포가 의미있을때마다 배포하는것이다.
사용자가 필요할때 제공하라
Topic 51 실용주의 시작도구
생각없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.
-앨프리드 노스 화이트헤드
예전 처음 포드 자동차가 출시되었을때 시동거는 설명서가 있었는데 무려 두장이 넘었다. 하지만 지금은 시동과정 전체가 '자동'이다.
이렇듯 어떤 작업이던 간에 일상적인 작업은 모두 자동화 해야한다. 그래서 지원되는 모든 컴퓨터에서 반복수행할 수 있어야 한다.
게다가 프로젝트내의 일관성을 확보하고 싶다면, 수작업은 일관성을 운에 맡기지만 자동화된 작업은 그렇지가 않다.
버전관리
프로젝트를 빌드하는데 필요한 모든것을 버전관리하에 두어야한다. 이는 프로젝트 전체 관점에서 보면 더욱 중요하다. 그렇게되면 빌드장비를 일시적으로 쓰고 없앨수 있다. 배포 설정역시 버전관리 시스템 안에 있으므로 실제 서비스에 릴리스하는 것도 자동으로 처리된다. 이것이 매우 중요하다. 프로젝트 차원에서는 버전관리 시스템이 빌드와 릴리스 프로세스를 운용한다.
가차없고 지속적인 테스트
개발자들은 지금 당장 버그를 찾아 나서도록 자신을 몰아세우지만, 덕분에 나중에 다른 사람이 자기 버그를 발견하게되는 딱한 상황을 피할 수 있다. 버그 찾기는 '그물낚시'와 비슷하다. 잔챙이를 잡기위해 촘촘한 그물을 쓰기도하고 식인상어를 잡기위해 크고 성긴 그물을 쓰기도한다. 때때로 고기가 용케 도망가기도 하지만 그렇게 되면 '미끌미끌'한 결함들을 더 많이 잡기위해 구멍난 곳을 있는대로 찾아다니며 막아야 한다.
일찍 테스트하고, 자주테스트해라. 자동으로 테스트해라.
코드를 작성하자마자 테스트해야한다. 작은 잔챙이들은 꽤 빨리 자라나 사람을 잡아먹는 거대한 상어가 되는 고약한 성질이 있다. 상어를 잡긴 힘들다. 그래서 단위별로 테스트를 작성한다. 아주많이..
사실 훌륭한 프로젝트에는 제품코드보다 테스트 코드가 더 많을 수 있다. 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다.
모든 테스트가 끝날 때 까지는 코딩이 끝난게 아니다.
"진짜 상황 테스트"를 목표로 하는것도 중요하다. 즉 테스트 환경은 실제 환경과 최대한 비슷해야한다. 두 환경의 차이에서 버그가 번식한다.
단위테스트
다음 단계로 넘어가기전 우리가 사용하는 모든 모듈의 단위 테스트를 반드시 통과해야한다. 일단 관련 모듈이 모두 각각 개별 테스트를 통과하고 나면 다음단계로 넘어갈 준비가 된것이다. 모든 모듈 시스템 전체에 걸쳐 어떻게 사용되고 상호작용하는지 테스트해야한다.
(책 396~399 Page, 뷰어기준 421 ~ 424 Page )
- 통합테스트
- 유효성평가 및 검증
- 성능 테스트
- 테스트를 테스트하기
- 철저한 테스트
- 속성기반 테스트
그물 조이기
버그가 기존 테스트를 빠져나갔더라면, 다음번 그물에 반드시 잡히도록 새 테스트를 추가해야한다. 인간테스터가 버그를 만나서는 안된다. 그 순간 이후로는 무조건 매번, 예외없이, 아무리 사소해도, 개발자가 "그런상황은 절대 또 일어날리 없습니다" 라고 불평하더라도 해당버그를 확인 할 수있게 자동테스트를 수정해야한다.
게다가 우린 자동화 테스트가 우리르대신해 찾아 줄 수 있는 버그까지 쫒아다닐 시간이 없다. 우리는 새 코드를 (새 버그도)작성하는데 시간을 쏟아야한다.
전체 자동화
아무리 종이로된 메뉴얼이 잘 되어있더라도 개발자의 컴퓨터는 조금씩 다르게 설정되었다. 동일한 코드를 실항하는데도 애플리케이션의 동작은 개발자마도 미묘한차이를 보인다.
사람들은 컴퓨터처럼 같은 일을 반복할 수 없을 뿐더라 그런것을 기대해서도 안된다. 셀 스크립트나 프로그램은 동일한 명령을 매번 똑같은 순서로 수행한다. 또한, 버전관리 시스템에 들어있을 것이므로 시간이 지남에 따라 그 빌드 , 릴리스 절차가 어떻게변했는지도 조사할 수 있다.
모든것이 자동화에 의존한다. 그렇지않다면 임의의 클라우드 서버에 프로젝트를 빌드할 수도 없고 수작업 단계가 끼어있다면 자동배포를 할 수가 없다. "이거 하나만.." 이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨뜨리는 것이다.
Topic 52 사용자를 기쁘게 하라
개발자로서의 우리의 목표는 사용자를 기쁘게 하는것이다.
작동하는 소프트웨어를 제때 제공하는 것만으로는 부족하다. 그것만으로 사용자를 기쁘게 할 수없다. 사용자가 진짜로 원하는 것은 코드가 아니다. 그들에겐 자신의 목적과 예산에 맞추어 풀어야 하는 사업상의 문제가 있다. 그리고 팀과 일하면서 문제를 풀어낼 수 있으리라 믿는다.
어떻게 사용자들이 우리에게 기대할수있는것을 밝혀 낼 수 있을까 ?
이 프로젝트가 끝나고 한달 후에 우리가 성공했는지 어떻게 알 수 있을까요 ?
사용자가 기대하는 바의 일부가 수면위로 올라왔다면, 비로소 이런 기대를 어떻게 충족 시킬수 있을지 고민을 할 수 있다.
- 모든 팀구성원 사용자가 기대하는 바를 완전히 이해한다
- 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각해보자
- 이런 기대를 염두에 두고 사용자 요구사항을 비판적으로 분석하자. '요구사항'은 사실 기술로 무엇을 할 수 있을지 추측한 것 일 뿐이다. 실제로는 비전문가의 구현계획이었던 것이다.
- 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하자.
우리는 "소프트웨어 엔지니어" 혹은 "소프트웨어 개발자" 직함이겠지만 실제로 우리의 직함은 "문제 해결사"이다. 이것이 바로 실용주의 프로그래머의 본질이다.
Topic 53 오만과 편견
너는 지금까지 우리를 충분히 즐겁게 해 주었단다.
-제인오스틴(오만과 편견)
실용주의 프로그래머는 책임을 회피하지않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는것을 기뻐한다. 설계 혹은 코드를 맡는다면 자신이 보기에 자랑스러운 작품을 만들어 낼 것이다. 옛 장인들은 자신의 작품에 서명하는것을 자랑스러워 하는것 처럼 말이다. 우리도 그래야한다.
하지만 프로젝트는 서로 팀으로 이루어지며 이 규칙이 말썽을 일으킬 수도 있다. 어떤 프로젝트에서는 코드소유권 이라는 발상 때문에 협력에 차질이 빚어질 수도 있다. 자신의 영토를 지키려고 하는것 처럼 공통 기반 프로젝트에 협력을 꺼릴 수도있고 종래엔 작은 영토들로 조각나 버릴수도 있다. 이렇듯 자신의 코드만 좋게보고 동료의 코드는 깎아 내리는 '편견'을 갖게된다.
이것은 우리가 원하는 바가 아니다. 경계심 때문에 우리의 코드를 서로 참견하는 사람으로부터 방어하려고 해서는 안된다. 같은 맥락에서 타인의 코드 역시 존중해야한다. 이 팁의 효과를 보려먼 개발자 사이 '상호존중'이라는 기반이 꼭 필요하다.
