DAY 19 (p.402-431 전자책기준)

9장.실용주의 프로젝트

📚 오늘 TIL 3줄 요약

• 모든 기능을 갖춘 팀을 조직하라
• 빌드나 릴리즈, 테스트, 서류 작업, 반복작업, 일상작업은 자동화하기
  (버전관리, 테스트, 전체 자동화)
• 타인의 코드를 존중해라
  
  
  

📚기억하고 싶은 내용

실용주의 팀

• 50명은 팀이 아니라 큰 무리다. 팀이 커질수록 의사소통, 효율성이 떨어진다
• 작고 안정적인 팀을 유지하라(10~12명 이하)

깨진 창문을 없애라

• 품질에 무심한 팀에 배치된다면 자질구례하게 반복되는 문제를 고치느라 열정을 소비할 것이다.
• 팀은 깨진 창문을 용납하지 않아야 하고 이 철학을 이해하는 개발자를 지원하며 그렇지 못한 개발자들은 이해하도록 독려해야한다
• 품질은 팀원 모두가 각자 기여할 때 보장되는 것. 나중에 덧붙이는 것이 아니다

삶은 개구리

• 방심하면 냄비 속 서서히 변하는 환경을 모르는 개구리처럼 삶아진다
• 모든 사람이 적극적으로 전체 환경 변화에 신경써 파악하고 있어라
• 요구사항에 대한 수치관리 - burndown번다운차트 보다 burnup번업차트 가 더 낫다

여러분의 지식 포트폴리오를 계획하라

기능개발 외에도 해야 할일들이 있다

• 구형 시스템 유지 보수
• 프로세스 회고와 개선
  무엇이 잘되고 잘 안되는지 확인해서 계획을 세우고 고쳐라.
• 새로운 기술 탐험
  후보 기술로 프로토타입을 만들어 보고 신중하게 조사해
  새로운 것(기술, 프레임워크, 라이브러리)을 시도해보고
  결과를 분석하는 업무를 일정표에 추가하라
• 학습 및 기술 갈고 닦기
  팀원들을 전도할 계획을 세워. 스터디 시간잡기
• 실현하려면 계획하라

팀의 존재를 소통하라

훌륭한 프로젝트팀 :

• 사람들이 이 팀과의 회의를 기대한다
• 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스,
  깔끔 정확 일관적인 문서 + 유머감각까지,,,?!
• 원팀으로 소통하게하는 비결 :
  프로젝트명 짓기 (착시 효과, 애완용 쥐, 만화 캐릭터, 신화 도시 등)
  팀의 정체성 확립하게 됨

반복하지 말라

• 연통형, 사일로형 시스템 - 공유되는 것이 거의 없고 중복된 기능은 아주 많은 안좋은 시스템
• 즉각적이고 매끄러운 좋은 의사소통을 한다
• DRY 지키려면 서로 관심을 유지하라

팀 예광탄

• 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 점직적, 반복적으로 전체에 걸친 단일 기능을 개발할 것을 추천한다
• 그러려면 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다
  프론트엔드, UI/UX, 서버, DBA, QA 등 함께 일하는 것
• 그러면 기능의 아주 조그만 부분을 아주 빠르게 개발할 수 있다
• 의사소통과 즉각적인 피드백 받을 수 있다.
• 모든 기능을 갖춘 팀을 조직하라

자동화

• 일관성, 정확성을 보장할 수 있게 된다
• 에디터, IDE의 자동 코드 스타일
• 지속적 빌드로 자동 테스트
• 도구 제작 역량을 팀 내에 갖추어서 개발과 배포를 자동화하는 도구 만들어라

멈춰야 할 때를 알라

• 프로젝트가 가치를 만들어 내기 딱 좋을 만큼의 구조를 제공하라
• 덧칠하려는 욕구 참기
  
  
  

코코넛만으로는 부족하다

• 화물 숭배 cargo cult
  형식만 흉내냈을 뿐, 내용은 빠져있는 것
  ex) 섬 주민들이 코코넛으로 만든 모조 공항
• 예시
  스크럼을 사용한다는 팀이 있음
  스탠드업 미팅은 1주일 1번/ 반복주기 4주단위인데 6~8주로 늘어지는 경우 잦음
  애자일 일정 관리 도구 사용하니 문제 없다고 주장.
  그들은 피상적인 결과물에만 투자. '스탠드업', '반복주기' 그 이름만 갖다 쓰고 있을 뿐 진정한 마법을 불러일으키지 못했다

맥락의 중요성

• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라
• 동일한 시장, 제약 조건, 전문성, 조직 크기, 경영진, 문화, 사용자층과 요구 사항은 다 다르니 각자 맥락에 맞는 개발 방법, 테스트 기법, 프레임워크 등을 사용해야 한다
• 사업 방향이 선회하고 계속 번성함에따라 또 다른 방식을 사용하는 것이 비결이다.

만병통치약은 아무 병도 못 고친다

• 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해라
• 인기 있는 방법론 하나만 보지말고 다른 것들도 봐라

  예)
  스크럼은 몇 가지 프로젝트 관리 실천 방법을 정의하는데,
  팀 차원의 기술적 요소나 리더십 차원의 포트폴리오/관리방식에 대해선
  별다른 지침이 없다. 그렇다면?

진짜 목표

진짜 목표는 "스크럼/애자일/린/칸반/XP 을 한다"가 아니라
작동하는 소프트웨어 제공으로 사용자가 즉각적으로 사용할 수 있게 되는 것

• 폭포수
  수개월/년 단위 반복주기
• 스크럼
  고정된 짧은 반복주기
• 지속적 배포

• 출시 간격 몇년=>몇달=>몇주 로 줄여보라 *필요시마다 출시가능하게
• 4주 단위 스프린트 =>2주=>1주로 줄여보라
• 1분씩 배포가 아니라 사용자가 필요할때, 사업적 의미있을때마다 배포하는 것
• 사용자에게 필요할 때 제공하라
• 버전 관리 시스템의 기능 브랜치가 아니라, 주main브랜치 혹은 트렁크trunk에서 개발해야한다
• 기능 스위치 기법 활용
  사용자에게 선택적으로 시범적 기능 공개할 때 사용

<초심자>
프로젝트 관리: 스크럼 / XP의 기술 실천 방법

<숙련자>
칸반, 린 기법

• 이 말을 다 받지는 말고, 조사해서 시도해봐라. 지나치지는 않도록.
  
  
  

실용주의 시작 도구

(과거) 시동거는 설명서 2장 => (현대) 자동 시동 장치까지

• 빌드나 릴리즈, 테스트, 서류 작업, 반복작업, 일상작업은 자동화하기

버전 관리로 운용하라

• 버전관리 시스템으로 빌드, 테스트, 릴리스를 운용하라

가차없고 지속적인 테스트

• 일찍, 자주, 자동으로 테스트하라
• 단위 테스트를 많이 작성한다
• 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다
• 단위 테스트
  : 하나의 모듈을 테스트하는 코드
  사용하는 모든 모듈의 단위 테스트가 반드시 통과해야 한다
• 통합 테스트 integration test
  주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다
  전체 서브시스템들이 모두 계약을 제대로 지키는지 테스트하는 것.
  시스템에서 버그가 많은 부분이 모듈을 통합하는 부분인 경우가 많다
  단위테스트의 확장.
• 유효성 평가 및 검증 Validation and Verification
  UI, 프로토타입 갖춰지면, 정말 사용자들이 필요한 것인지, 기능적 요구 사항 충족하는지 테스트해봐야 한다
• 성능 테스트 = 스트레스 테스트
  소프트웨어가 실세계 조건에서 성능 요구 사항들을 준수하는지 자문하라
  예상 사용자 수, 접속 수, 초당 트랜잭션 숫자를 염두에 두고, 감당 가능한가?
  부하를 시뮬레이션하기 위한 특화된 데트스용 하드웨어나 소프트웨어 필요할수도 있다

테스트를 테스트하기

• 버그를 심어 놓고 테스트를 테스트하라
• 소스트리에서 별도 브랜치 생성 - 고의로 버그 심고 - 테스트가 버그 잡는지 검증하기
• 넷플릭스의 카오스 멍키 같은 도구로 고의로 서비스에 지장 일으키고 여러분 애플리케이션의 회복 능력을 테스트하라

철저한 테스트

• 철저한 테스트했는진 알 수 없다
• 커버리지 분석 도구
  테스트 중 코드를 지켜보며 어느 줄이 실행안되는지 알려준다.
  하지만 100% 기대하지는 말라
• 코드 커버리지만 올리지 말고 상태 조합을 테스트하라

속성 기반 테스트

• 테스트하려는 코드의 계약과 불변식에 따라 테스트 데이터를 생성하는 속성 기반 테스트 기법을 사용하라

그물 조이기

• 같은 버그는 한 번만 잡아라. 앞으론 만나서는 안된다

전체 자동화

• rsync와 ssh 넣은 셸 스크립트
• Ansible, Puppet, Chef, Salt 기능 갖춘 패키지
• 수작업 절차를 사용하지 말라
• 딱 이거 하나만....이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨트리는 것이다
  
  
  

사용자를 기쁘게 하라

• 개발자의 목표는 사용자를 기쁘게 하는 것이다. 그저 코드만 내놓지 마라
• 우리는 문제 해결사다
• 고객 잔존율, 데이터 품질, 절감한 비용 등 성공 척도가 의미있는 사업 가치다.

• 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야한다
• 결정내릴 때 어떤 선택이 사용자 기대에 가까운지 생각하라
• 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라. '요구 사항'은 사실 기술로 무엇을 할 수 있는지 추측한 것일 뿐. 요구 사항을 바꾸면 목표에 더 가까워진다는 것으로 보여줄 수 있다면 바꾸자고 제안하라
• 프로젝트 진행 중에도 계속 사용자의 기대에 대해서 생각하라

• 도메인에 대한 지식이 늘어남에 따라,
  근본적인 사업 문제를 해결하기 위해 맡지 않은 다른 부분에 대해서도 더 좋은 제안을 할 수 있게 된다
  
  
  

오만과 편견

• 자신의 작품에 서명하라
• 타인의 코드를 존중해라
• 자신의 코드만 좋게 보고 동료의 코드는 깎아내리는 편견prejudice 갖지마라
• "남에게 대접 받고자 하는 대로 너희도 남에게 대접하라"
• 익명성은 위험하다
• xp에서는 코드의 공동 소유권을 제안한다
  (하지만 이는 익명성의 위험을 예방하기 위해 짝 프로그래밍과 같은 추가 실천 사항을 필요로한다)

🎤소감

프로젝트에 임할 팀원들의 방향성과 어느 것이 바람직한지 알게됐다. 수작업을 금지하여 코드에 깨진 창문을 절대 만들지 말아야 한다는 것과 환경을 수시로 살펴야 된다는 것에 명심하게 됐다. 그리고 지식 포트폴리오로 지속적인 발전을 잡고 팀원들도 전도?!하는 것이 효율적인 것을 보고, 앞으로 계속해서 배움만이 남았다고 느꼈다.
빌드, 테스트, 반복작업 등을 자동화하고 버전관리 시스템을 잘 사용해봐야겠다. 그런데 아직 단위, 통합 테스트에 대해 방법을 잘 모르겠다. 하지만 훗날을 위해선 꼭 필요하다는 것이 절실히 느껴졌다.
그리고 마지막으로 사용자를 기쁘게 하는 것이 목표이고, 우리가 문제 해결사라는 것이 기쁘게? 와닿았다. 지금은 너무 한참 뉴비,,이지만,, 작은 문제부터 시작해서 언젠간 중요한 문제까지 다룰 수 있는 해결사가 되고 싶다. 좋은 협업자와 팀원이 되기 위해서 오늘 배운 것들을 기억하고 적용해봐야지..

벌써 마지막 9장까지 읽었는데, 데이브와 앤디 선생님이 인도해주시는 길잡이를 보게 된 기분이다. 뉴비로써 앞으로 헤쳐나가야 할 관문들이 많지만,,, 고인물의 뒤를 따라가면 그래도 덜 고생하겠지(?!)

<맨먼스 미신>에서 프레더릭 브룩스는
"프로그래머의 작업은 시인과 마찬가지로 순수한 사고의 산물에 가깝다. 허공 위에 공기로 만든 성을 상상의 힘으로 짓는다."라고 말했다.
우리는 백지에서 시작하여 우리가 상상할 수 있는 거의 무엇이든 만들어 낼 수 있다. 그리고 우리가 만드는 것이 세상을 바꿀 수 있다.
- 맺는말 중 p.407 (p.431 전자책)

위에 맺는말이 내가 프로그래밍을 시작한 동기를 잘 설명해주는 글이라고 생각했다. 국어국문학과에서 프로그래머가 되기로 결심하는데에는 비슷한 점이 있었다. 바로 무언가를 만들어내는 창조적 활동이라는 점이다. 그것을 표현해내는 방식이 글에서 코드로 바뀐 것이다. 그리고 책에서도 시인과 프로그래머 작업의 유사성을 말해주고 있어서 새로웠고, 직업 동기에 대해서 다시 한 번 되새길 수 있었다.

마지막으로 개발서적을 읽어본 것이 처음인데, 정말 이 책에서 한 개발자의 인생이 담겨있었다. 그동안 책을 너무 멀리한 것에 반성하고, 개발서적을 꾸준히 읽어나가야겠다. 지금 안하면 고생은 미래의 내가 하니깐. 그리고 개발 외적으로도 균형잡힌 미래를 그려가야지.

🤷‍♂️궁금한 내용, 잘 이해되지 않는 내용은?

• 프레더릭 브룩스의 <맨먼스 미신> 읽으라는데 뭐지
• 기능 스위치 기법 p.415
• 트렁크 trunk
• 스크럼, 애자일, 린, 칸반, xp

🎇the end...🎇