개발 이론, 생각, 컨퍼런스/애자일

[Clean Agile : Back to Basics] 4장 : 팀 실천 방법

mystic-agit 2023. 8. 2. 11:39

애자일 프로세스의 "팀 실천 방법"

  • 익스트림 프로그래밍에서 가운데 반경의 프로세스 

 

(1) 메타포 (Metaphor)

  • 팀 내에서 효과적으로 의사소통 하려면 개념을 나타내는 어휘와 용어를 명확하게 정의하여 일관되게 사용해야 함
  • 개발자간 뿐만 아니라 고객, 관리자간에도 서로 이해할 수 있어야 함
  • “도메인 주도 설계” 방법
    • 해결하려는 문제 도메인의 모델을 모든 사람(프로그래머, QA, 관리자, 고객, 사용자)이 동의하는 어휘와 언어(유비쿼터스 언어)로 표현해야 함
    • 도메인 : 실제 세계에서 사건이 발생하는 집합
      • ex : 옷 쇼핑몰
        • 손님들이 주문하는 도메인
        • 점주가 옷을 관리하는 도메인
        • 쇼핑몰이 월세 등 관리비를 관리하는 도메인
    • 개발 코드에도 그 어휘가 반영될 수 있게 작명 (모듈, 클래스, 메서드 등)

 

(2) 지속 가능한 속도 (Sustainable Pace)

  • 개인
    • 나 자신 최선의 페이스(지치지 않고 오래 유지할 수 있는)의 하루당 업무량과 속도를 인지하고 진행
      • 지나치게 많이 하면 건강 등의 문제로 좌초될 수 있다.
      • 수면, 운동 등의 건강관리도 중요하다.
  • 팀
    • 팀원들과 함께할 수 있는 최선의 페이스를 찾고 개인의 범위안에서 적용
    • 혼자 앞서 더 많이 일한다고(초과 근무, 야간 근무) 공을 세울 수 있는 경우는 극히 드물다.
      • 오히려 잘못된 결정으로 수정을 위한 추가 근무를 하는 모습이 비춰질 수 있다.
      • 꼭 필요한 경우에만 추가 근무를 하자.
  • 개발은 눈앞에 보이는 목표점에서 끝나지 않는다.
    • 지속적인 유지보수와 개발을 위해 끝없는 마라톤을 한다 생각하고 뛰어야 한다.

 

(3) 공동 소유 (Collective Ownership)

  • 구성원 전부가 모든 코드를 소유하고 어느 부분이든 개발할 수 있어야 한다.
    • 팀 인원이 지식을 고루 공유할 수 있다.
    • 의사 소통을 원활하게 이루고, 보다 좋은 결정을 내릴 경우가 높아진다.
  • 특정 인원이나 그룹이 코드를 소유하지 않는다.
  • 넓게 알되 전문적인 부분은 키울 수 있도록 한다.

 

(4) 지속적 통합 (Continuous Integration)

  • 팀에서 정한 가능한 작은 시간 주기로 코드를 체크인 하고 주 브랜치에 통합하여 빌드가 성공하도록 유지한다.
    • 단위 테스트와 인수 테스트는 계속 통과해야한다.
    • 기능 브랜치가 통합되지 않은 채 남아있어선 안된다.
    • 배포 시 동작하면 안되는 기능은 토글로 비활성화 시킨다.
  • 지속적 통합을 위해선 혼자 개발하기 보단 짝 프로그래밍을 통해 개발하자
    • 단독적인 코드 스타일로 인한 리스크 발생을 줄일 수 있다.
    • 변경 사항 공유가 쉽다.
    • 문제 발생 시 협업하여 해결하는데 비용을 줄일 수 있다.
  • 무엇보다 가장 중요한건 체크인된 상태에서의 빌드는 절대 문제가 발생하면 안된다.
    • 빌드를 위해 잠시 예외처리해둔 혹은 꼼수를 둔 로직이나 코드는 지양한다.

 

(5) 스탠드업 미팅

  • 스탠드업 미팅 룰
    • 미팅 참석은 필수가 아님, 한 명쯤은 빠져도 무관
    • 꼭 매일할 필요 없음, 팀에 맞는 일정으로 진행
    • 10분이 넘지 않도록 함, 팀의 규모와 상관 없이
    • 회의 방식은 아래 내용으로 고정, 아래 질문을 모든 사람이 30초 정도 안에 답을 하고 다시 업무를 진행한다.
      • (a) 지난 스탠드업 미팅 이후 무엇을 했는가?
      • (b) 다음 스탠드업 미팅까지 무엇을 할 것인가?
      • (c) 어떤 장애물이 있는가?
  • 장점
    • 불필요한 회의 시간을 최소화
    • 팀의 방향성을 환기
    • 각 팀원의 진행률을 대략적으로 인지
    • 미팅 이후 필요한 정보 공유 가능
  • 스탠드업 미팅에선 개발자만 발언한다.
    • 관리자나 기타 인원이 들을 수는 있지만 끼어들지 않는다.
    • “저자 의견”
      • 누가 말을 하던 상관 없다.
      • 주어진 시간만 넘기지 않으면 된다.
    • “나의 의견”
      • 아마도 개발 과정에서 갑작스런 요구사항이 끼어들어 미팅이 회의로 확대되는 경우를 방지하기 위함
      • 저자 의견처럼 룰에 방해되지 않는다면 문제 없을 것 같다.
  • 끝으로 감사의 인사를 하기
    • 긍정 에너지를 만들고 서로 좀더 위하는 분위기가 도움이 될 것으로 보인다.