실용주의 프로젝트 (9장)

TIL (Today I Learned) 날짜

2022.5.31 (화)

오늘 읽은 범위

9장. 실용주의 프로젝트

책에서 기억하고 싶은 내용을 써보세요.

• 소프트 웨어 개발 방법론의 목표 = 함께 일하는 것을 돕는 것
• 실용주의 팀은 작다. 구성원은 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로를 잘 알고, 진화하며, 의존해야 한다. -> 작고 안정적인 팀을 유지하라.
• 깨진 창문을 없애라
  • 팀 전체가 깨진 창문을 용납해서는 안된다. 사소한 결점도 반드시 해결해서 제품의 품질에 책임을 져야 한다. 
  • 이 철학에 공감하는 개발자를 지원하고, 그렇지 못한 개발자들은 이해하도록 독려해야 한다. 
• 환경 변화를 감시해라
  • 범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다. 
  • 새 요구사항에 대한 수치를 관리하라. 
  • 단지 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다. 
• 지식 포트폴리오를 계획하라
  • 지식과 기술에 시간과 에너지를 투자하라. 
  • 팀을 진정으로 개선하고 혁신하고 싶다며 계획을 세워야 한다. 실천하려면 계획하라.
  • 시간이 나면 할게요 = 영원히 하지 않겠다는 의미! 
  • 할 일을 백로그로 관리하든 다른 도구를 사용하든 간에 기능 개발 외에도 해야 할 일을 계획하자. 
  • 지식 포트폴리오 리스트 
    • 구형 시스템 유지 보수 
    • 프로세스 회고 및 개선 : 지속적인 개선이 일어나려면 무엇이 잘 되고 무엇이 잘 되지 않았는지 확인한 다음 변화를 추구해야 한다. 계획을 세우고 고쳐라.
    • 새로운 기술 탐험 : 우리 프로젝트에 적합한지, 후보 기술로 프로토타입을 만들어보고 신중하게 조사하라. 새로운 것을 시도해 보고 결과를 분석하는 업무를 일정표에 추가하라.
    • 학습 및 기술 갈고 닦기 : 개인적으로 배우고 역량을 키워라. 팀원들을 전도할 계획을 세워라. 많은 기술이 팀 전체로 퍼졌을 때 더 효과적이다. 스터디 추천! 
•  팀의 존재를 소통하라
• 훌륭한 팀의 증거 : 다른 팀에서 개발팀과 회의하는 걸 기대한다. 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문이다. 이들이 생상해 내는 문서는 깔끔하고 정확하며 일관적이다. 팀은 한 목소리로 이야기한다. 
• 반복하지 말라
  • 좋은 의사소통 = 매끄럽고 즉각적인 의사소통
  • 팀 내에서 편하게 질문하기
  • 진행 상황이나 문제, 통찰 및 새롭게 알게 된 점을 공유하기 
  • 동료가 뭘 하고 있는지 서로 알고 있기
• 팀 예광탄
  • 프로젝트 진행할 때 팀은 다양한 과제를 해결해야 한다.
    • 요구 사항 이해하기
    • 아키텍처 설계하기
    • 프론트엔드와 서버 코드 작성
    • 테스트 돌리기 
  • 따라서 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다. 
  • 프런트엔드, UI/UX, 서버,  DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다. 
• 자동화
  • 코드 스타일은 에디터가  자동으로! 
  • 지속적인 빌드가 자동으로 테스트 실행하기
  • 자동화 배포
  • 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라. 
• 멈춰야 할 때를 알라
  • 팀원이 각자의 방식대로 빛나게 하라.
  • 팀원들을 지원하기에, 그리고 프로젝트가 가치를 만들어 내기 딱 좋을 만큼의 구조를 제공하라.
• 피상적인 흉내로는 부족하다. 
  • 맥락이 중요하다. 맥락을 고려하자
  • 특정 개발 방법, 프레임워크, 테스트 기법이 우리의 맥락 안에서도 유효한가
  • 우리 팀에 적합한 방식인가? 우리와 같은 시장, 제약 조건, 전문성과 조직 크기, 경영진, 문화를 보유하고 있을 때도 효과적인가? 
  • 작은 아이디어 하나를 시험해보자. 잘 맞는 것 같은 좋은 부분만 유지하고 나머지는 버리면 된다. 
  • 방식은 변하는 법! 
• 특정 개발 방법론이 만병통치약은 아니다. 
  • 중요한 건 기존의 규칙 너머를 보고 개선의 여지를 찾아내는 능력이 필요하다.
  • 특정 방법론에서 가장 좋은 부분만 가져다가 조정해서 적용해야 한다. 
• 목표
  • 반복 주기 몇 달 -> 몇 주 -> 4주 -> 2주로 줄여 보라. 
  • 사용자에게 필요할 때 제공하라. 
  • 프로젝트 관리 방법 : 스크럼, 익스트림 프로그래밍 실천 방법, 칸반, 린 방법
  • 직접 이런 저런 방법을 조사한 뒤 시도해봐라. 그렇지만 지나치지 않도록 주의하라. 
• 실용주의 시작하려면? 도구 먼저! 
  • 일상적인 작업은 모두 자동화하기 : 빌드와 릴리스 과정 / 테스트나 프로젝트 서류 작업
    • 사용해야 하는 도구 리스트
      • 버전 관리 :
        • 커밋과 푸시로 빌드와 테스트, 배포 자동화하기.
        • 태그로 테스트 할지, 실제 서비스에 릴리스할지 지정해라.
      • 회귀 테스트
        • 코드를 작성하자마자 테스트해야 한다.  
        • 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. 
        • 테스트를 통과했다는 것은 그 코드가 '완성'되었다는 말과 같다. 
        • 테스트 환경은 실제 상황과 최대한 비슷해야 한다. 환경 차이에서 버그가 생긴다. 
        • 테스트 종류
          • 단위 테스트 : 하나의 모듈을 개별 테스트하는 코드
          • 통합 테스트 : 프로젝트 주요 시스템이 다른 부분과 제대로 작동하는지 테스트하는 코드
          • 유효성 평가 및 검증 : 프로토 타입 제작 후 해당 기능이 정말 사용자가 필요로 하는 것인지  체크
          • 성능 테스트 : 사용자 수나 접속 수, 초당 트랜잭션 숫자를 감당할 수 있는가
          • 테스트를 테스트하기 : 버그를 심어 놓고 테스트를 테스트하기
          • 속성 기반 테스트 
        • 버그는 한 번만 잡아라. 두 번 만나서는 안된다.
      • 전체 자동화 : 빌드 전체 자동화하기 (자동 배포)
• 개발자의 목표 = 사용자를 기쁘게 하는 것
  • 질문을 던져라
    • 이 프로젝트가 끝나고 한 달(일정 시간) 후에 우리가 성공했는지 어떻게 알 수 있을까요?
    • 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라
    • 이런 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라. 
    • 프로젝트의 목표에 가까워진다면 변경 사항을 제안하라. 
    • 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.
• 개발자는 문제해결사다. 우리는 문제를 해결한다.
• 실용주의 프로그래머는..
  • 책임을 회피하지 않는다.
  • 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다. 
  • 자신의 작품에 서명하라.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• '무엇이 그들을 성공적으로 만드는가?'에 대한 질문이 크게 와닿았다. 그들의 성공 비결에서 어떤 점을 우리 팀에 적용해서 시도해볼 수 있을까. 와 같은 질문이 실천으로 이어지는 방법을 찾아야겠다. 
• 프레데릭 브룩스 - 맨먼스 미신 읽기!
• 드디어 책을 다 읽었다. 처음 읽기 시작했을 때부터 좋은 멘토를 만난 것 같은 마음에 주변에 참 좋은 책이라고 추천했었다. 다 읽고 나니 든든한 느낌이 든다. 방향을 잃거나 지치고 힘들 때마다 다시 펼쳐봐야지 하는 생각이 들어서 그런 것 같다. 북클럽에 참여해서 좋은 책을 만났고 5월 의미 있게 마무리할 수 있어서 감사한 시간이었다.