잡담

효율적인 업무 프로세스에 대한 연구 및 방식 제안

김진우 개발일지 2024. 12. 29. 15:48

Abstract

소프트웨어 개발 프로젝트에서는 협업이 매우 중요하다. 국내외 수많은 개발팀과 팀원들은 규모에 상관없이 문서와 다양한 협업 도구를 이용해 서로 소통한다. 소프트웨어 개발 분야는 다른 분야와 비교해서 자동화 툴과 협업 플랫폼이 비교적 다양한 편이다. 이 연구의 목적은 중복된 툴 사용과 낮은 숙련도 때문에 생산성이 떨어지는 것을 방지하기 위해 기존에 사용중인 여러 방법론을 찾아보고 개발팀 성격에 맞는 방식을 제안하는 것이다. 실제 인증 기관의 도움을 받는 것은 현실적으로 불가능하지만 팀의 상황에 맞게 어떻게 변형해 팀에 어떤 프로세스를 적용할지 고민하는게 핵심이다. 최적의 프로세스를 적용하고, 더 나아가 이 문서가 CMMI의 능력 성숙도 5레벨 조직을 목표로 나아가는 팀이 되는데 밑거름이 되는 연구가 되길 희망한다.

참고 문헌

  • [논문1] CMMI의 정략적 프로젝트 관리에 기반한 S/W 개발 프로세스 개선에 관한 연구
  • [논문2] CMMI를 이용한 소규모 조직의 업무프로세스 개선

CMMI

CMMI에 대한 이해

레벨 1 - 초기

초기 수준은 조직의 프로세스 개선 여정의 시작점이다. 이 단계에서 프로세스는 임시방편적이고 잘못 정의되며 예측할 수 없어 일관되지 않은 결과를 초래하는 경우가 많다. 이 수준의 초점은 주로 조직의 프로세스 기능을 이해하고 프로젝트 실행에 필요한 기본 관행을 정의하는 데 있다.

 

레벨 1의 프로세스 영역:

  • 프로세스 관리(OPM): 프로젝트를 감독하고 제어하기 위한 기본 프로세스 관리 인프라를 구축하고 유지한다.

레벨 2 - 관리

관리 수준은 정의된 프로세스를 사용하여 프로젝트를 계획하고 실행하는 프로세스 성숙도에서 중요한 단계를 나타낸다.
반복 가능하고 여러 프로젝트에 일관되게 적용할 수 있는 제도화된 프로세스를 확립하는 데 중점을 둔다.

 

레벨 2의 프로세스 영역:

  • 요구사항 관리(REQM): 프로젝트 라이프사이클 전체에서 요구사항을 도출, 문서화 및 관리한다.
  • 프로젝트 기획(PP): 범위, 리소스, 일정 및 위험을 고려하여 포괄적인 프로젝트 계획을 개발하고 유지한다.
  • 프로젝트 모니터링 및 제어(PMC): 계획에 따라 프로젝트 진행 및 성과를 추적하고 편차를 식별하고 해결한다.
  • 공급자 계약 관리(SAM): 상품 및 서비스의 품질과 적시 제공을 보장하기 위해 공급업체 관계 및 계약을 관리한다.

레벨 3 - 정의됨

정의된 수준에서 조직은 조직 전체에서 일관되게 준수되는 잘 정립된 표준 프로세스 세트를 가지고 있다. 프로세스 표준화 및 문서화에 중점을 두어 프로세스 개선 문화를 촉진하고 특정 프로젝트 요구 사항을 충족하도록 프로세스를 조정한다.

 

레벨 3의 프로세스 영역:

  • OPF(조직 프로세스 초점): 조직의 목표와 목표에 부합하는 표준 프로세스 프레임워크를 정의하고 유지한다.
  • 조직 프로세스 정의(OPD): 자세한 프로세스 문서 및 프로세스 자산을 개발하고 유지 관리한다.
  • 조직 교육(OT): 인력이 정의된 프로세스를 능숙하게 사용할 수 있도록 교육 및 리소스를 제공한다.
  • 통합 프로젝트 관리(IPM): 프로젝트 계획 및 실행 활동을 통합하여 프로젝트 목표를 효과적으로 달성한다.

레벨 4 - 양적 관리

정량적으로 관리되는 수준에는 프로세스의 정량적 이해 및 제어가 포함된다. 이 수준의 조직은 통계 및 기타 양적 기법을 사용하여 프로세스를 사전 예방적으로 관리하고 개선한다.

 

레벨 4의 프로세스 영역:

  • 양적 프로젝트 관리(QPM): 정량적 데이터를 m수집하고 분석하여 프로젝트 관리에 대한 현명한 결정을 내린다.
  • 조직 프로세스 성과(OPP): 프로세스 성능 데이터를 수집하고 분석하여 프로세스 개선 사항을 식별한다.

레벨 5 - 최적화

최적화 수준은 가장 높은 수준의 프로세스 성숙도를 나타낸다. 이 수준의 조직은 성과 데이터에 대한 철저한 이해와 혁신적인 아이디어를 바탕으로 프로세스를 지속적으로 개선한다.

레벨 5의 프로세스 영역:

  • 조직 혁신 및 배포(OID): 전반적인 조직 성과를 향상시키기 위해 혁신적인 프로세스 개선 사항을 식별하고 통합한다.
  • 원인 분석 및 해결(CAR): 결함 및 기타 문제의 근본 원인을 식별하여 재발을 방지하고 전반적인 프로세스 성능을 개선한다.

적용 논의

[논문2]에 따르면 CMMI는 모델 자체에서 요구하는 실천사항이 많아 소규모 조직에 그대로 적용하는데 어려움이 있다.
하지만 정량적으로 조직 내 환경과 작업물을 평가하고 개선하는 방법을 소규모 조직에 어울리는 방식으로 개선한다면 발전의 여지가 있다.

[논문2]의 2.전투실험소 능력 현황에서 실험실의 능력을 구성하는 요소를 분류했던 것처럼 우리 팀의 능력을 구성하는 요소를 분류하면 아래와 같다.

카테고리 보유역량
People 팀원 목록 중 프로그래머
tools and equipment Unity, git, Notion, GitBook
process 온보딩, 오프보딩 프로세스 적용 및 관련 안내문서 제공
메신저 공지를 통해 지속적인 프로세스 개선 및 문서 안내
관행적인 Github 활용 프로세스 적용 논의 중
관행적인 Trello 활용 프로세스 적용 논의 중
   
  • 온보딩, 오프보딩, 안내문서와 메신저 공지는 레벨1 초기 단계의 프로세스 관리에 해당
  • Github와 Trello 활용 프로세스는 레벨2 관리 단계의 프로젝트 모니터링 및 제어에 해당하나 완전히 정착하지 못함

[논문1]의 표 1. CMMI의 능력 성숙도 Level의 5단계에 따라 팀의 상황을 평가해보자면 소프트웨어 프로세스 성숙도 5단계 중 가장 낮은 1단계에 해당하며, 2단계로 나아가는 상황이다. 현재 갖춰진 프로세스는 프로젝트 합류와 소스코드 형상관리에 중점을 두고 있다. 하지만 기획, 개발, 아트 팀 사이의 정형화된 협업 프로세스는 없는 것으로 파악된다. 완전한 2단계로 나아가기 위해서는 요구사항 관리(REQM), 프로젝트 기획(PP), 프로젝트 모니터링 및 제어(PMC)를 만족하는 프로세스가 필요하다.

구체적인 프로세스 적용 제안

Github를 활용한 레벨 2의 조건을 만족하는 프로세스를 제안한다.

요구사항 관리(REQM)

프로젝트 라이프사이클 전체에서 요구사항을 도출, 문서화 및 관리한다.

소규모 개발팀에 맞게 구체적으로 예시를 들자면 아래와 같다.

  • 기획안 공유 및 기획문서 버전 관리
  • 기확안으로부터 요구사항 도출
  • 수정사항 관리 및 문서 반영
  • 작업물 공유

아래는 기획안을 공유하고 구체적인 요구사항을 도출하며 수정된 내용을 지속적으로 업데이트하는 프로세스다.

  1. 기획자는 Todo에 카드를 만들고 기획안을 공유한다. 프로젝트 탭에 프로젝트 목록을 보면 TO-DO list를 찾을 수 있다.

  1. 카드를 클릭해 창을 열고 Assignees에 기획 담당자 본인과 개발, 아트 담당자를 추가한다.

  1. Draft 상태의 카드를 적절한 Repository의 Issue로 전환한다.

  1. 담당자들은 공유된 기획안을 보고 구체적인 요구사항을 도출한다. 도출한 요구사항은 Comment에 정리한다. 구체적으로 어떤 기능이 필요한지, 어떤 아트 리소스가 필요한지 작성한다. 이 과정에서 아트, 개발 담당자들의 여러 의견이 공유될 수 있다.

  1. 개발 담당자는 개발을 시작하기 전 반드시 이슈에서 브랜치를 설정한다. 브랜치 생성 규칙은 해당 레포 위키 참조. 만약 위키가 없거나 브랜치 생성 규칙이 별도로 존재하지 않는다면 기본적으로 github-flow를 따른다.
  2. 공유할 파일은 이슈에 반드시 업로드되어야 한다.
    만약 다른 플랫폼을 통해 파일을 공유받았으면, 파일을 찾기 쉽게 이슈에 업로드를 해야한다.
  3. 이슈가 발생하면 코멘트에 관련 내용을 업데이트한다.

Trello 활용은?

Github-Trello 연동 자동화 툴을 찾아봤는데, 유로라서 논의가 필요할 것 같다. Trello에서 지원하는 기능 중 개발에 필요한 모든 기능은 이미 Github에도 Project 탭과 Issue 탭을 통해 모두 지원하기 때문에 유료 결제가 꺼려진다면 Trello는 사용하지 않는 방향으로 가는 것도 고려해봐야 한다. 수동으로 연동하는 것은 누락 위험성 때문에 고려하지 않는다.

프로젝트 기획(PP)

범위, 리소스, 일정 및 위험을 고려하여 포괄적인 프로젝트 계획을 개발하고 유지한다.

소규모 개발팀에 맞게 구체적으로 예시를 들자면 아래와 같다.

  • 주기적인 개발 목표 설정
  • 주기적인 테스트 빌드 공개
  • 구현 검증

이것은 마일스톤과 릴리즈 페이지를 활용한 방법으로 프로세스를 제안한다.

  1. PM이 마일스톤을 생성하고 팀 전체적인 목표를 설정한다.

  1. # 요구사항 관리(REQM) 프로세스에서 마일스톤에 맞는 이슈 카드를 생성하고 개발을 진행한다. 이슈 카드에서는 마일스톤을 설정해준다.

  1. 완료한 작업은 Done으로 옮긴다. 옮겨진 이슈는 자동으로 Close된다.

  1. Close 된 이슈에 따라 마일스톤의 진행도를 확인할 수 있다.

  1. 완료된 마일스톤은 Close 처리한다. 단, 마일스톤의 Close 처리는 릴리즈와 함께 진행하는 것을 권장한다.

프로젝트 모니터링 및 제어(PMC) 프로세스

계획에 따라 프로젝트 진행 및 성과를 추적하고 편차를 식별하고 해결한다.

소규모 개발팀에 맞게 구체적으로 예시를 들자면 리소스 제작과 개발을 포함한 Feature 일정 관리다.

로드맵 탭에 Data fields를 위처럼 Start Date와 End Date로 설정하면, 카드에서 설정한 시작 날짜와 종료 날짜를 확인할 수 있다.

이슈 카드에서 날짜를 설정할 수 있다.

프로젝트를 진행하다보면 리소스 제작과 개발 일정, 제작된 리소스를 적용해 Feature를 완성하는 일정을 별개로 관리하는 상황이 생길 수 있다.
그럴 때는 아래처럼 새로운 카드를 추가해 링크를 연결하고 일정을 관리할 수 있다.

공급자 계약 관리(SAM) 프로세스

상품 및 서비스의 품질과 적시 제공을 보장하기 위해 공급업체 관계 및 계약을 관리한다.

이것을 소규모 팀에 맞게 구체적인 예시를 들자면 R&R이다. 이슈카드 생성할 때 Assignees 설정하는 것으로 관리할 수 있다.

결론

Github를 활용해 개발 프로세스를 제안했다. 얼마나 잘 작동하는지 실험이 필요한 한계가 있으나, 시행착오를 통해 개발 프로세스가 잘 정착하고 긍정적인 효과를 얻기를 희망한다.