개발 문화 : 스프린트, 데일리미팅, 페어프로그래밍

Agile Framework

• 어떻게 (how) 애자일하게 일 할 수 있는지에 대한 프레임워크 (가장 대중적)
• Best practice (모범 사례) 의 집합

Scrum

• 팀 구조가 functional 하게 되어 있어서 전통적인 Scrum 방식은 적용이 어려움
• 비지니스 과제에 대해서 팀간의 디펜던시가 매우 많아서 플래닝이 쉽지 않음

팀 운영 방식

• 민첩하게 대응하는 방식이 아니라 리소스를 효율적으로 관리하기 위한 방식으로 팀이 운영되고 있음
• 1인 1작업 (개인 작업)
• 인입 순서대로 업무를 할당받음
• 팀내에서 협업이 많지 않고 타팀과의 협업이 많음
  
  • ex) 개발자1 - 주문개발자1 - 프론트개발자1 - 앱개발자1 - 기획자1 - QA담당자1
• 장점 : 개발에 온전히 집중이 가능
• 단점 : 신규개발건이 들어올 경우 대기 시간이 길어서 민첩하게 대응하기 어려움

 

더 좋은 팀

• 민첩한 대응
• 팀내 협업을 통한 시너지 창출 (리스크 감소, 서로에게 배우기)

핵심 마인드셋

• 공유
• 협업
• 피드백

 

적용

• Practice
  
  • 데일리 스크럼
  • 스프린트
  • 페어 프로그래밍
  • 코드리뷰
• 각각의 Practice 에 대한 목적과 의도를 이해하지 않으면 형식적이 될 소지가 있음.

데일리 스크럼

• 목적
  
  • 각자가 진행하고 있는 일에 대한 공유 및 피드백
• 돌아가면서 3가지를 이야기함
  
  • 어제 한 일
  • 오늘 할 일
  • 방해요소
• 단순 공유만 한다고 하면 DR 만으로도 충분함
• 팀장에게 보고하기 위한 자리가 아님
• 그라운드 룰
  
  • 출근시간 정각 시작. (지각자가 있어도 상관없이 진행함)
  • 가급적 15분 이내에 마칠것
    
    • 한사람당 발언기회는 평균 2분 이내
  • 초반에는 경험자가 리딩하고 익숙해지면 일주일 단위로 돌아가면서 진행

 

스프린트

• 스크럼에서 사용하는 스프린트의 용어를 차용하긴 했지만 팀에서는 단순 개발단위로만 사용
• JIRA 의 스프린트 기능을 이용하고 일주일 단위로 어떤 일이 진행되는지에 대한 데이터를 쌓기 위한 단위
• 팀의 업무 진행상황을 시각화 할 수 있는 데이터
• 회고의 데이터로 쓰일 수 있음
• 리포트 내용
  
  • 해당 스프린트에 진행한 Task
  • 해당 스프린트에 완료한 Task
  • 해당 스프린트에 새로 유입된 Task
  • 해당 스프린트에 홀딩된 Task
  • 해당 스프린트에 연기된 Task

 

페어 프로그래밍

• 2명의 개발자가 하나의 화면과 하나의 키보드로 개발을 진행하는 것
  
  • 역할
    
    • 드라이버 : 코드 작성
    • 네비게이터 : 옆에서 피드백 및 전략 제시
• 장점
  
  • 코드 작성과 리뷰가 동시에 이루어짐
  • 지식이 공유됨
  • 문제해결 방법을 배울수 있음
  • 대화를 통한 빠른 해결
  • 잘못된 시작과 재작업을 줄일 수 있음
  • 툴의 사용법을 공유할 수 있음
• 단점
  
  • 피로도와 체력 소진이 높음. (높은 집중력 때문에)
  • 케미에 따라 생산성 차이가 있음
  • 성숙한 사람만 가능 (으하하)
  • 일반적으로 10~20%의 시간이 더 소요
• 언제 하나?
  
  • 새로운 기술을 적용할 때
  • 팀원의 실력을 상향 평준화 할려고 할 때
  • 신입 개발자를 팀내에 빠르게 적극하려고 할 때
  • 업무 난이도가 높고 실수하기 쉬운 문제를 해결해야 할 때
  • 해결하기 어려운 버그를 처리해야 할 때
  • 코드의 품질과 안정성이 중요하다고 판단될 때
  • 팀원의 기술력이 뛰어나고 작업이 익숙한 Task 라면 개별로 작업이 하는것이 더 나을 수 있음.
• 가이드
  
  • 50분 코딩, 10분 휴식의 싸이클
  • 번갈아가면서 함 (네비게이터,  드라이버)
  • 하루 최대 4시간까지만
  • 서로 존중하기
  • 인내심 있게 기다리기
  • 딴짓하지 말기 (집중하기)
  • 키보드 빼앗지 말기
  • 시작전에 샤워하고 양치하기
  • 모르는 것은 바로 물어보기
  • 대화를 논쟁으로 생각하지 말기 (승자와 패자가 있는 것이 아님)

 

코드리뷰

• 온라인으로 잘 진행하고 있음.
• 온라인 리뷰는 코드를 짠 의도를 정확하게 판단하기 어려움
• 조금 더 디테일하게 코드에 대한 피드백을 받고 싶다면 별도 미팅을 잡아서 팀원들을 초대하기
• 큰 프로젝트 일 경우에는 (코드량이 많은) 관련 비지니스에 대한 설명도 진행하면서 코드리뷰 진행할것