- Topic 49 : 프로젝트 참여인원이 복수가 되었을때 실용적으로 각 부분을 위임하는 법
- Topic 50 : 팀에게 잘 맞는 방법론을 사용하고 있는가
- Topic 51 : 안정적인 소프트웨어를 지속적으로 생산해내는 방법
- Topic 52 : 사용자를 기쁘게하는 방법
- Topic 53 : 자신의 작업에 자부심을 가져라
Topic 49 : 실용주의 팀
실용주의 팀은 작아야한다. 구성원은 대략 10~12명이고, 구성의 변경이 적어야한다. 서로를 신뢰하고 의존할 수 있어야한다.
작고 안정적인 팀을 유지하라
원하는 바를 실현할 수 있는 환경에 실용주의 개발자 그룹이 만들어진다면, 자신들에게 맞는 역학을 금방 만들고 또 다듬어 낼 것이다
깨진 창문을 없애라
자질구레하게 계속되는 문제를 고치는데 열정을 유지하기 힘들다
팀 전체가 깨진 창문을 용납해서는 안된다. 반드시 제품의 품질에 책임을 져야한다.
삶은 개구리
팀은 개인보다 더 삶은 개구리가 되기 쉽다. 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 범위의 확장, 일정 단축, 추가기능 등 기존에 인지하던 것과 다른 것들을 늘 깨어서 의식해야한다.
변화를 거부하지 않아도 된다. 단지 그 변화를 인식하고는 있어라
여러분의 지식 포트폴리오를 계획하라.
성공을 원하는 팀이면 자신들의 지식과 기술에 투자해야한다. 이때는 계획을 세워서 해야하는데, 시간이 남으면 하겠다는 안하겠다는 말과 같다. 계획을 세울 때 기능개발로만 몽땅 채우지말라. 대신에 아래 것들을 고려하라
- 구형 시스템 유지보수
- 프로세스 회고와 개선
- 새로운 기술 탐험 : 다들 쓰니까 쓴다는 이유보단 팀에 잘 맞는 것이 뭘지 조사하라
- 학습 및 기술 갈고 닦기
팀의 존재를 소통하라
팀이라는 것 역시 더 큰 조직의 일부이다. 외부사람들에게 과묵한 프로젝트팀이야말로 최악이다. 나머지 팀들과 의사소통하라.
반복하지 말라
팀원 간의 중복된 일을 없애기는 어렵다. 좋은 의사소통을 통해 이 문제를 피할 수 있다. 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야한다. 질문을 하기위해 회의를 기다려야하면 의사소통이 어려워진다.
DRY를 지키려면 서로 관심을 유지하라
팀 예광탄
시스템의 끝에서 끝까지 전체에 걸쳐있는 단일 기능을 개발하라. 이 작업을 맡은 모든 구성원이 함께 일하는 것이 편안하고 익숙해야한다.
자동화
일상적으로 반복되는 일을 자동화하라. 수작업으로 하는 것보다 훨씬 일관적이고 정확하다
멈춰야 할 때를 알라
각 팀원이 자신의 방식대로 빛나게 하라. 프로젝트의 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라
Topic 50 : 코코넛만으로는 부족하다
화물 숭배에 빠지지 말라
맥락의 중요성
특정한 개발 방법이나 프레임워크를 굳이 사용하는 이유가 무엇인가? 유명해서인가? 아니면 현재 프로젝트 또는 팀에 잘 맞아서인가?
유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라
유명한 팀들이 성공한 방식을 따라하기보다는 맥락을 보고 잘 맞는 것을 사용하라.
잘 맞는 방법론이더라도 다 정확히 따라야할 필요는 없다. 좋은 것만 취하고 안맞는 것은 버려라
진짜 목표
진짜 목표는 “에자일을 한다”, “린을 한다” 가 아니라 사용자에게 작동하는 소프트웨어를 제공하는 것이다.
CICD가 불가능한 목표라고 생각하는 팀은 많다. 하지만 모든 목표가 그렇듯 계속 올바른 방향을 바라보는 것이 중요하다. 제품 출시 주기를 조금씩 줄여나가라. 최종적으로는 필요할때마다, 사업적으로 의미 있을때마다 배포하는 것이 목표이다.
사용자에게 필요할 때 제공하라
이런 지속적 개발을 위해선 feature 브랜치가 아니라 main 또는 trunk 브랜치에서 개발해야한다. 그리고 사용자에게 시범적 기능을 제공할 때는 ‘기능 스위치’ 같은 기법을 활용하라
Topic 51 : 실용주의 시작 도구
생각없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다
- 엘프리드 노스 화이트헤드
프로젝트에서 거듭 발생하는 일상적인 작업은 모두 자동화해야한다. 수작업은 운에 맡기는 것이고, 반복 가능성도 보장 받지 못하다. 그 작업의 절차를 여러 사람이 서로 다르게 해석할 여지가 있으면 더욱 그렇다
여기에는 아래와 같은 프로젝트를 견고하게 만들어주는 도구들이 있다.
- 버전관리
- 프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야한다. 이렇게하면 빌드 장비를 일시적으로 쓰고 버릴 수 있다.
- 배포 설정도 버전관리 하에 있으므로 서비스 릴리즈도 자동으로 처리된다.
- 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
- 회귀 테스트
- 일찍, 자주, 자동으로 테스트하라.
- 테스트는 코드가 완성되었다는 확신을 줄 수도 있다.
- 테스트 환경은 실제 환경과 최대한 비슷하게 설정해야한다. 두 환경의 차이에서 버그가 생긴다.
- 테스트의 몇가지 주요 유형
- 단위테스트
- 통합테스트 : 시스템에서 버그가 제일 많이 나오는 것이 모듈을 통합하는 부분이다.
- 유효성 평가 및 검증 : 시스템의 기능적 요구사항을 충족하는지 테스트해야한다. 잘못된 문제를 푸는 것은 아닌지, 최종 사용자의 접근 방식이 개발자의 테스트 데이터와 어떻게 다른지에 대해 관심을 가져라.
- 성능 테스트
- 테스트를 테스트하라 : 버그를 심어놓고 테스트가 정상적으로 동작하는지 확인하라
- 철저한 테스트 : 코드 커버리지만 올리지 말고 상태 조합을 테스트하라
- 속성 기반 테스트 : 컴퓨터가 상태를 생성하도록 하여 예상치 못한 상태를 테스트하여라
- 버그는 한번만 잡아라
- 인간 테스터가 버그를 찾았다면 더이상 인간 테스터가 그 버그를 만나선 안된다.
- 해당 버그를 자동화 테스트에 포함시켜라
- 전체 자동화
- 수작업 절차를 사용하지 말라.
- ‘하나만’ 이라는 생각으로 수작업 절차를 추가하면 커다란 창문을 깨는 것이다
Topic 52 : 사용자를 기쁘게 하라
소프트웨어 프로젝트 자체가 아니라, 사용자가 실제로 기대하는 것에 진짜 의미가 있다. 소프트웨어는 이런 목적을 달성하기위한 수단일 뿐이다.
이런 숨겨져있는 프로젝트 배후의 가치에 대해 사용자가 기대하는 바의 일부가 드러났다면, 이런 기대를 어떻게 충족시킬 수 있을지 고민하라
- 모든 팀 구성원이 이러한 기대를 이해해야한다
- 결정을 내릴때 어떤 것이 기대를 충족시킬 수 있는지 생각하라
- 이런 기대를 염두에 두고 요구사항을 비판적으로 분석하라. 요구사항을 바꾸는 것도 제안하라
- 프로젝트 진행 중에도 계속 사용자의 기대에 대해 생각하라
사용자를 기쁘게하라. 그저 코드만 내놓지 말라
Topic 53 : 오만과 편견
실용주의 프로그래머는 책임을 회피하지 않는다. 자신의 코드만 좋게보지말고 동료들의 코드를 깎아 내리지 말라. 경계심 때문에 자신의 코드를 방어하지 말라. 같은 맥락에서 다른 사람의 코드를 존중해야 한다.
자신이 만든 코드에 서명을 할 수 있어야하고, 품질을 보증할 수 있어야한다.
맺은말
소프트웨어는 의도치 않게 디스토피아를 만들어낼 수 있다. 코드를 작성할 때마다 두가지 질문을 던져라
- 사용자를 보호했는가?
- 나라면 이것을 쓸까?
어떤 창의적인 발상은 윤리적 행위의 경계선을 달리기 시작할 때가 있다. 자신이 그런 프로젝트에 참가했다면, 그 프로젝트의 후원자와 같은 책임이 있다.
후기
이번 장은 프로젝트 전체적인 관점에서의 실용주의 팁들을 던진 장이다. 말단 개발자인 나로서는 실천하기 어려운 것들도 많지만, 몇가지는 머리 속에 새겨뒀다가 제안을 할 수 있을 거 같다.
- Topic 49 : 팀을 실용적으로 운용하는 방법에 대해 알려주었다
- 작고 안정적인 팀이 서로를 신뢰할 수 있어야한다.
- 깨진 창문을 용납하지 말라
- 변화를 인식하라
- 팀 내부에서는 편안하고 빠른 소통이 이뤄질 수 있도록하고, 팀 외부 사람과도 소통을 잘하라
- 예광탄, 자동화를 통해 팀 생산력을 올릴 수 있다
- Topic 50 : 어떤 방법론, 프레임워크에 매몰되지말고 팀에 잘맞는 것을 취사선택하라. 프로젝트의 진짜 목표에 집중하라
- Topic 51 : 버전관리, 회귀 테스트, 자동화라는 도구를 통해 프로젝트를 단단하게 만들 수 있다
- Topic 52 : 언제나 사용자의 기대를 충족하는 것을 1순위로 생각하라
- Topic 53 : 자신의 작성한 코드의 품질을 보증할 수 있어야한다.
topic 50, 52, 53은 태도에 대한 얘기로 본다. 이부분은 머릿속에 기억하여 항상 실천하려는 자세를 취할 수 있다.
topic 49, 51 에서도 기억하면 팀 또는 프로젝트에 개선할 부분을 더 잘 찾을 수 있을 거 같다.