Best Practice

Best Practice

Agile 프로세스

1. 판단 근거 애자일 프로세스 선택 이유 SETB는 다양한 고객사의 디지털 전환을 돕는 소프트웨어를 개발하는 회사로, 고객의 요구사항이 명확한 경우가 많습니다. 그렇다면 워터폴 방식이 적합지 않나 싶을 수 있습니다. 그러나 다음과 같은 이유로 워터폴 방식보다는 애자일 프로세스가 더 적합하다고 판단했습니다.
2. 요구사항과 구현 간의 간극:
   • 고객이 제안한 요구사항과 실제 구현 결과물 간에 차이가 있을 가능성이 큼
   • SETB는 아날로그 제품을 디지털 소프트웨어로 전환하기 때문에 그 간극이 더 클 수밖에 없음
   • 따라서 초기 요구사항이 명확하더라도 세부적인 개발 과정에서 고객의 기대와 실제 요구는 달라질 수 있음
3. MVP 접근법의 필요성:
   • 고객의 요구사항을 기반으로 MVP(Minimum Viable Product)를 제작하고, 이를 고객에게 시연하며 피드백을 받는 방식이 적합
   • 피드백을 바탕으로 소프트웨어를 점진적으로 개선하는 애자일 프로세스가 이러한 상황에 유리

고객의 요구사항

• 고객은 Space-Invaders 게임을 ‘뱀서라이크’ 장르로 개발할 것을 요청
• 요구사항은 구체적이었지만, 개발 과정에서 다음과 같은 세부사항들이 추가적으로 결정되어야 했음
  • 적들의 생성 방식
  • 함선의 다양한 특성(공격 방법, 속성 등)
  • 스테이지 종료 기준(레벨 단위, 시간제 등) 이러한 추가적인 세부사항은 프로젝트 초기 계획 단계에서 정확히 파악하기 어려웠으며, 애자일 프로세스를 통해 고객과 긴밀히 협력하며 해결해야 했음

2. 실행 결과 애자일 프로세스 활용 사례

• 초기 스프린트에서 ‘뱀서라이크’의 핵심 요소를 구현한 후, 고객에게 시연하며 요구사항을 수집하고 빌드업하는 방식으로 진행했음
• 고객 피드백 예시:
  • “아이템이 있었으면 좋겠어요.”
    • 이동속도, 발사 속도, 총알 속도 올리는 아이템 제작 -> “사거리를 늘리는 아이템도 있었으면 좋겠어요.”
• 이러한 피드백은 개발 과정에서 고객과 소통했기에 반영될 수 있었음

구체적인 애자일 프로세스 선택: Scrum과 Kanban 비교

Scrum의 한계

1. Scrum Master와 Product Owner 역할 부담:
   • 해당 역할의 경험자 부재로 이러한 역할을 맡는 것에 부담을 느꼈음
2. 유휴 시간 문제:
   • 스크럼은 스프린트가 시작될 때 Product Backlog에서 가져오고 스프린트 중간에 변경하지 않는 Push 시스템
   • 계획한 작업이 모두 완료된 경우 남은 시간 동안 발생하는 비효율성이 있었음

Kanban의 한계

1. 동기부여 부족:
   • 구체적인 데드라인이 없어 작업 속도가 느려질 가능성이 있었음
2. 목표 부족:
   • 공동의 목표 설정이 어려워 프로젝트 관리가 어려워졌음

Scrumban 프로세스 도입

계획

1. 수평적 팀 구조:
   • 리더와 팀원으로만 구성되며, 역할 분배를 최소화했음
   • 백로그 정제와 스프린트 계획에 모든 팀원이 참여
2. 1주 단위 스프린트:
   • 매주 월요일에 스프린트 시작 및 종료
   • 스프린트 회고, 계획, 백로그 정제를 한꺼번에 진행하여 미팅의 흐름을 이어감
3. Kanban 보드와 WIP 제한:
   • Jira를 사용해 백로그 관리
   • Kanban 보드는 ‘할 일 - 진행 중 - PR - 완료’로 구성
   • 진행 중 열의 작업 수를 ‘팀원 수 + 1’로 제한하여 집중력을 높이고, hotfix 여유 공간을 확보
4. Kanhan의 Pull System 사용
   • Kanban과 같이 스프린트 중간에도 Product Backlog에서 Sprint Backlog로 항목 가져오기 가능
   • 스프린트가 일찍 끝나 남는 유휴 시간을 줄이기 위함

실제 적용 결과

1. 수평적 팀 구조

   • 팀원 전체가 백로그 정제 과정에 참여하여, 사용자 요구사항을 구현하는 다양한 아이디어 도출
     • 예시) 함선이 상하좌우로 움직이면 좋겠다, 게임 앤딩 화면이 있으면 좋겠다 등

2. 밀도있는 미팅의 부담

   • 여러 미팅이 하루에 이루어지다보니 집중이 분산되었음
   • 스프린트 회고를 플래닝 하루 전으로 분리하여 각 미팅에 집중하게 됨
   • 또한, 미팅에 Time Box가 없는 경우 내용이 꼬리를 물고 이어지기 쉬웠음
     • 해당 미팅이 아닌 다른 미팅에서 다룰 내용에 대해 자세히 이야기 하는 경우도 있었음

3. Jira를 통한 Kanban 보드를 사용할 때 GitHub과 연결되어있지 않으면 Github PR을 관리하고, 추가로 Jira의 Issue까지 관리해야했음. 작업이 과중되고, 실제 Issue의 진행상황과 동기화되지 않는 경우가 있었음

4. Pull 시스템이 무의미 했음

   • 각자 스프린트 플래닝 단계에서 맡은 이슈를 해결하면 이후 자율적으로 Product Backlog에서 항목을 가져와 작업하는 것을 기대했음
   • 하지만, 각자 자신의 작업을 스프린트 기간에 맞춰 끝내는 현상이 발생함

5. PO(Product Owner)의 부재

   • 사용자의 요구사항을 실제 구현하는 단계에서, 각자의 구현 아이디어가 다를 수 있음
   • 백로그 정제 및 스프린트 플래닝 단계에서 사용자 요구사항을 명확하게 하고 구현 방안을 구체화하는 것으로 어느정도 해결이 가능하지만, 서로간의 의견이 대립되는 경우 이를 중제할 사람이 없었음
   • 서로 다른 생각으로 개발을 시작하다 완성된 경우, 이의 타협점을 볼 때 소모되는 토의와 수정 비용이 있었음
   • 따라서 고객과 밀접하게 소통하고, Product의 개발 방향을 잡는 역할을 하는 사람이 필요했다고 느껴졌음

6. 소통의 중요성

   • 서로의 작업 상황은 칸반 보드만으로 공유하기 어려웠음
   • 해당 이슈를 얼마나 진행했는지, 어떤 어려움이 있는지는 말하지 않으면 알 수 없음
   • 어려움을 겪고 있었는데, 이를 발화하며 도움이 될만한 사람들을 연결해 금방 해결한 적이 있음
     • 대각선 이동시 속도가 빠른 문제 -> 소수점 픽셀 이동 해결방법 공유

7. 최종 제안 SETB에 적합한 Scrumban 프로세스

8. 애자일 프로세스 채택:

   • 고객 요구사항이 명확하더라도, 소프트웨어 개발 과정에서 발생하는 세부 결정사항과 변경사항은 발생할 수밖에 없음
   • MVP 접근법을 통해 고객과의 협력 및 피드백 기반 개발이 가능

9. Scrum 프로세스:

   • 팀이 수평적인 구조이고, 비록 경험자가 없더라도 제품 개발 과정을 결정하고 책임지는 사람이 필요하다고 느꼈음
     • 서로의 구현 아이디어가 달라 수정하는 비용, 여러가지 구현 방법중에 고민하고 선택하는 비용을 줄일 수 있음
   • 데일리 스크럼
     • 자신의 할 일을 발화하는 것만으로도 책임감이 생겨 작업 동기부여가 됨(벼락치기 예방)
     • 겪고 있는 어려움을 공유함으로써 해결책을 모색할 수 있음
     • 서로 기능이 의존적인 경우, 상대방의 진행 상황을 살펴보며 내 작업에 반영할 수 있음

10. 프로세스 최적화:

    • PO가 작업 분할 시 최소한의 변경 범위를 명시하고, 방향성을 설정
    • 회고와 계획 미팅을 분리하여 집중도를 높이고 피로를 감소
    • 브랜치에서의 작업은 최대한 자주 팀 저장소에 Push하여 서로의 작업 사항을 공유
    • Jira와 GitHub 연동을 통해 Kanban보드 관리 최적화
      • 이슈를 In progress로 옮기면 -> 브랜치 생성
      • 브랜치 PR을 열면 -> PR로 이동
      • Merge가 되면 -> 완료로 이동

코드 리뷰

코드 리뷰를 진행한 이유

높은 품질의 결과물의 내기 위해 코드 리뷰를 진행하기로 함 코드 리뷰를 진행한 이유

1. 혼자서는 놓칠 수 있는 부분을 리뷰를 통해 고칠 수 있음
2. 팀원들간의 코드 공유가 되어 프로덕트 이해도 향상
   1. 이는 다양한 아이디어, 작업 속도 향상으로 이어짐

초기 코드 리뷰 방식

GitHub PR을 활용

• 하나의 Jira Issue를 브랜치로 생성하여 작업한 뒤, PR을 통해 merge하는 GitHub Flow에 적합하다고 판단

GitHub PR을 열면, 최소 한 명의 팀원 승인이 있어야 main으로 merge 가능

실행 결과

1. 리뷰 책임감 부재
   • 코드 리뷰 승인이 늦어지는 상황(2일 이상 소요)으로 인해 작업 흐름에 지장이 발생
2. 코드 리뷰 항목의 명확성 부족
   • 단순히 코드 양식과 같은 사소한 부분만 지적되거나, 코드 리뷰 중 새로운 기능 추가 요청이 발생하는 등 코드 품질 향상에 집중하지 못했음

개선 사항

코드 리뷰 항목 구체화

1. 중점 논의 항목 설정
   • 코드 재사용성, 가독성, 효율성, 버그 여부에 대한 논의에 초점을 맞췄음
   • 자동화 가능한 코드 양식 문제는 PR 생성 전에 처리하도록 규정
2. 자동화 도구 활용
   • GoogleStyle 기반으로 IntelliJ Reformat Code 기능을 사용해 팀의 코드 스타일을 통일
     • Indent를 기존 2에서 4로 변경
     • 한 줄 주석의 경우 길이를 제한하지 않도록 수정
   • IntelliJ Commit Checks를 통해 코드 정렬이 자동으로 적용되도록 설정하여 작업 누락 가능성을 방지 담당 리뷰어 시스템 도입

• 각 스프린트마다 담당 리뷰어를 지정하여 리뷰 요청과 수행 과정을 명확히 했음
• 리뷰 요청 후 24시간 내 리뷰 완료 규칙을 도입
결과: 모든 코드 리뷰가 24시간 이내에 완료되었으며, 작업 흐름이 원활해졌음

전체 코드 공유 방식 개선

1. 시행착오
   • 모든 PR에 대해 팀원 전원이 코멘트를 남기는 방식: 리뷰 내용이 실질적인 이해를 바탕으로 작성된 것인지 확인하기 어려웠음
   • 3명씩 그룹화하여 실시간으로 코드 리뷰를 진행: 코드 이해도는 높아졌으나, 반복적인 미팅으로 인해 높은 비용(시간 및 노력)이 발생
2. 최적화된 방식
   • 코드 리뷰는 담당 리뷰어와 1:1로 원격 동기식 방식으로 진행하도록 변경
   • 매 스프린트마다 한 번씩 오프라인에서 전체 팀원이 모여 주요 PR에 대해 설명하는 시간을 가지며 코드 공유를 강화

최종 제안

1. 자동화 도구 활용
   • 코드 스타일 통일 및 PR 생성 전 자동화 가능한 작업을 도구로 처리해 코드 리뷰의 본질인 품질 향상에 집중
2. 효율적인 담당 리뷰어 시스템 운영
   • 리뷰어를 명확히 지정하고, 리뷰 요청 및 수행 기한을 지속적으로 준수하여 코드 리뷰 과정을 체계적으로 유지
3. 효율적인 코드 공유 방법 도입
   • 실시간 코드 리뷰는 담당 리뷰어와의 1:1 방식으로 진행하여 비용을 최소화
   • 전체 코드 공유는 매 스프린트마다 오프라인에서 주요 PR에 대해 팀 단위로 논의하는 시간을 확보함으로써 팀원 간 이해도를 높임

Git Workflow 및 Build/Test 자동화 제안

GitHub Workflow 문제점

• 간단한 수정사항 반영의 어려움
  • 볼륨 조절이나 수치 조정과 같은 코드의 기능 추가나 로직 변경이 아닌 변경사항은 반영이 어려웠음
  • 이런 변경사항을 새로 이슈를 발행하고 브랜치를 생성하여 운영하는 것이 부담스러웠음 해결 방안

1. 작업 분류 및 관리 체계 개선
   • 새로운 기능 추가는 Jira Issue로 관리하고 리뷰 과정을 거침
   • 간단한 수정사항이나 버그 수정은 GitHub Issue로 따로 관리
     • GitHub Issue 템플릿을 활용하여 요구사항 명확화
     • 여기서 생성한 브랜치는 리뷰 없이 PR을 통해 바로 merge 가능
2. 코드 품질 보장 방안
   • 간단한 수정사항도 최소한의 품질을 보장하기 위해 Build 및 Test 자동화 시스템 구축 결론

• 새로운 기능 추가는 Jira Issue를 통해 진행하고 반드시 리뷰를 거친 후 merge
• 개선사항 및 버그 수정은 GitHub Issue를 통해 진행하며 리뷰 없이 PR로 merge
  • 단, 자동화된 Build 및 Test를 통과해야 merge 가능

Build 및 Test 자동화 문제점

• 모든 PR을 로컬 환경에서 Build하고 Test 코드를 실행하는 작업은 비효율적이고 반복적임 해결 방안

1. Build Tool 선택
   • Java의 Build Tool 중 Gradle을 선택
     • Maven은 전통적이고 안정적이지만, Gradle은 최신 트렌드와 잘 맞음
     • SETB가 새로운 기술을 빠르게 도입하는 조직 특성을 고려하여 Gradle을 선택
2. 자동화 도구 활용
   • GitHub Actions를 사용하여 Build 및 Testing 자동화
   • PR 생성 시 Gradle Build 및 JUnit5 테스트를 실행하도록 설정
   • 테스트와 Build를 통과해야만 merge 가능하도록 시스템 구축 실행 결과

• PR 생성 시 자동으로 Build 및 Test가 실행되며, 실패 시 merge 불가
• 코드 품질을 유지하면서도 반복 작업을 줄여 팀의 생산성이 향상됨 최종 제안

1. Git Workflow
   • 간단한 수정사항은 GitHub Issue로 관리하고 리뷰 없이 PR을 통해 빠르게 반영
   • 새로운 기능 추가는 Jira Issue로 관리하고 리뷰를 통해 품질 검증
2. Build 및 Test 자동화
   • Gradle과 JUnit5를 기반으로 GitHub Actions에서 Build 및 Test 자동화
   • PR 생성 시 자동화된 검증 단계를 통과해야 merge 가능