소프트웨어 개발 방법론 - 최근 트렌트의 변화

1. 팀 구성

• 기존에는 기술 분류에 따라 팀을 구성하였다 (Functioanl Team)

기술 분류에 따른 팀 (Functioanl Team)

• 최근 트렌트의 핵심은 빠른 기동성이기 때문에 이렇게 팀을 구성하면 속도 측면에서 불리할 수 밖에 없다
• 그래서 좀 개선된 모습은 다음과 같다

Cross functional Team (Product based)

• 한 팀에 모두 넣음
• 이런 식으로 구성하면 기동성을 그나마 높일 수 있다. 왜냐하면 MSA 구조이기 때문에 프론트보다 앱이 먼저 개발이 되면 앱을 먼저 릴리즈할 수 있기 때문이다.
• 하지만 한팀에서 진행을 하기 때문에 중앙집중적 관리가 필요하다는 단점이 있다. 결국 중앙에 dependency가 생기면서 속도를 많이 끌어올리지는 못하게 된다.

1-1. 최근 트렌드의 팀 구성

Cross functional Team (Feature based)

• 팀을 나눌 때 기능 단위로 나눔
  ex) 제품 검색, 제품 주문, ...
• 해당 기능만 릴리즈하면 되기 때문에 엄청난 기동성을 가져갈 수 있다
  ex) 스포티파이 같은 회사는 이런 구성을 사용하고 있다
• 단점으로는 코드베이스가 공유되기 때문에 코드가 한번 뭉게지면 전체가 흔들릴 수 있다.
• 그래서 이 팀 구성을 하기 위한 조건으로는 코드 베이스 플랫폼화가 잘 되어 있어야 할 수 있다

2. 스크럼 개발 방법론

1. Product Owner는 일종의 기획자라고 보면 된다
   (아키텍쳐 설계에서 사용자 스토리를 정의하는 역할을 한다, 원래 기본적으로 아키텍쳐 엔지니어는 User Story를 정의하지 않지만 어떻게 돌아가는지를 이해하는 것은 중요하다)
2. Backlog에 사용자 스토리 정리
3. 백로그에서 개발할 것들을 뽑아서 스프린트 백로그 작성
4. 스프린트는 개발 주기이다
   (4주가 제일 적당함, 그 이상은 집중력 저하/버그 수정 때문에 6주까지 가는 경우도 있긴 함/코드 리팩토링이던가 짧게 주기를 가져가서 2주 정도로 돌리는 경우도 있음)
5. 데일리 스크럼, 리뷰

• 스토리 그루밍: 기획, 개발, 아키텍쳐 모두 모여서 다음 스프린트에 들어갈 기능들(백로그)을 하나씩 흐름을 따라가보며 검토하는 것
• VOTING: 플래닝 포커(Planning Poker), 4-3에서 설명

2-1. 조직 구조

3. 정리

• 너무 애자일만 고집해서는 안된다. 예를 들어 금융 시스템을 만드는데 애자일을 도입해서 기능을 확확 바꾼다? 큰일난다. 규제가 너무 강하기 때문에... 그리고 금융 시스템은 dependency가 엄청 쎔. 이런건 오히려 옛날의 EA(Enterprise Architecture) 아키텍쳐 구조를 따라가는 것이 맞다

4. 실전 적용

4-1. 그루밍

• ”다음 스프린트에 들어가기 전에, PO가 다음 스프린트에 개발할 기능에 대해서대략적으로 리뷰를 하는 행위”. 스프린트 진행중 일어남

4-2. 사용자 스토리 작성

• 주요 기능을 사용자 관점에서 기술
  
  • "As a {user}, I want do {something}"
    "나는 {사용자로써}, {무엇}을 한다"
• 특징
  
  • 직관적으로 이해가 되어야 하며
  • 테스트가 가능해야 함
• 분류, 스토리, 설명 형태로 기술하는 것이 좋음

• 계속 업데이트를 해가야하기 때문에 잘 보관

4-3. 스토리 보팅(Voting)

• 사용자 스토리에 있는 기능들의 시간 분배를 잘하기 위해 사용. 예를 들어 10명이 개발한다고 할 때, 하루 8시간씩 4주면 총 1600시간을 활용할 수 있다. 하지만 회의 시간, 변경 사항 수정, 디버깅, 장애 대응 등을 생각해야하므로 한 50%만 잡아서 800시간을 잡고 이 시간을 사용자 스토리의 각 기능별로 어떻게 분배할 것인지를 결정해야 함
• 플래닝 포커 (PLANNING POKER)
  • 개발팀 전체가 모여서, 각각의 사용자 스토리에 대해서 개발 기간을 투표
  • 포인트의 의미는 알아서 정함. (EX 1포인트 = 1일)
  • 포인트는 0.5,1,2,3,5 단위로 띄워서 정의
  • 전체 팀원이 서로 설득 당할때 까지 계속 진행
  • 사용자 스토리에 대한 디테일은 PO에게 그 자리에서 질의
  • 점수가 가장 높은 사람과, 가장 낮은 사람의 의견을 듣고 다시 보팅
    
    • 가장 낮은 사람 (빠른 개발 방식을 알고 있을 수 있음)
    • 가장 높은 사람 (놓친 무언가를 알 수 있음)

4-4. 개발 범위 (일정 지정)

• 산출된 포인트로 개발 일정 지정 (2~4주)
• 버퍼 (회의, 문서, 배포, 오류 수정 등) 배정 필요 (1.5~2배)
• 4주가 넘는 일정은 우선순위에 따라 자름
• 스크럼 사이클을 돌려가며 지치지 않게 잘 관리해야 함
  ex) 팀이 6개이면 한팀당 스프린트 3개(3달)하고 한 스프린트 쉬게, 쉴 때는 리팩토링하던가 선행 개발 진행 → 3대1 정도 비율로 가져가니 효과가 좋았음

4-5. 스프린트 시작

• 사용자 스토리 기능 나온 것을 하나 하나 Jira에 등록
• 요건 UX 확인은 JIRA 로 핑퐁, UX 시안도 JIRA로 전달
• JIRA ISSUE 구조 정의
• 모든 커뮤니케이션 내용은 지라 코멘트에 등록하면서 기록을 남겨야 함

• 지라가 좋은게 STORY나 CHORE, TASK에 대해서 commit ID를 연동해서 프로덕션까지 추적성을 부여할 수 있다
• SUB-TASK는 EPIC, STORY,... 이런게 TASK이고 그 안에 들어감. 예를 들어 ISSUE에 AWS 계약이 아직 안됨이란게 있으면 SUB-TASK로는 AWS 미팅 몇월 몇일, 계약서 작성 몇월 몇일 이런 식이다
• EPIC은 카테고리라고 생각하면 됨

Lv1이 EPIC에 맵핑됨

• EPIC에 맵핑된 후 EPIC 밑에다가 사용자 스토리를 정의하기 전에 컴포넌트부터 정의를 해야함
• EPIC 밑에 사용자 스토리와 컴포넌트가 따로 들어가는 것이다. 즉 2차원 구조로 들어가는 느낌
• 컴포넌트는 제품 단위 또는 팀 단위로 분리하는 것이 좋음
• ex) IOS,안드로이드,웹
  ex)관리자 포탈

• Blocker의 경우 해결되지 않으면 프로젝트가 진행될 수 없는 경우
• Critical은 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우
• Major 꼭 개발해야 하는 경우
• Minor 개발은 해야 하나 없어도 상관 없는 경우
• Trivial 있으나 없으나 크게 상관 없는 경우
• 보통 Default가 Major

이슈 등록 예시

위에서 예시에서 1600pt 였으면 800pt만 넣어야 함

• 만약에 버그 생기고 이슈 생기고 하다보면 위 예시에서의 1600pt가 넘을 수도 있음
• 그러면 대표든 책임자든 찾아가서 이슈를 빼달라고 해서 1600pt를 넘지 않게 조정해야 됨
  (1600pt 넘어가면 야근을 해야되는건데 이런걸 말을 안하면 위에서는 모른다. 그니까 실적을 남기려면 안 빼줄 것 같더라도 말을 해야 됨, 존재감을 보여주자)

• 릴리즈 버전을 정의해놓고, 버전에 스토리를 맵핑
• 어느 기능이 어느 버전에 들어 가는지 추적 가능
• 어느 버그가 어느 버전에서 발생해서 어느 버전에서 수정이 가능한지 추적 가능
• 릴리즈가 꼭 제품을 출시한다는 의미는 아님. 중간 중간에 동기부여를 위한 마일스톤을 만드는 것의 의미가 더 크다. 사람은 지치기 마련이다

• 진행중인 스크럼 태스크의 상태를 칠판에 표시 해놓는 방식 (포스트잇)
• JIRA 애자일 보드로도 가능하지만, 가시성이 떨어짐
  (태스크 & 서브 태스크들이 많아서 잘 안보게됨. 또는 자기것만 보게됨)
  → JIRA를 쓰더라도 칸반보드는 별도 운영하는게 좋음
• 칸반 보드의 스타일은 팀과 개발 방식에 맞게 끊임없이 변화해야 함

• 약속한 시간에 스탠드업 미팅
• 칸반 보드를 보고 
• “어제 한일, 오늘 할일, 일처리에 장애 요인” 을 간단하게 이야기 함
• 끼어들거나 질문 금지… (마이크를 드는것도 좋음)
• 추가 회의가 필요하면 스크럼 미팅 끝나고 → 업무 보고 시간이 되면 안된다
• 생각보다 잘 안됨. (회의는 하지만 컨택스트 공유가 잘 안됨) → 될때까지…

• 코드 리뷰는 피어 리뷰 방식으로 진행
• 문제 발생시 피어와 커미터 양쪽 공동 책임
• Reviewboard,gitlab, …

• 매일 코드 커밋
• 코드 커밋시에 JIRA TICKET #를 적어 넣으면, JIRA 티켓에서 코드 변경 사항 추적이 용이함
• 깃이랑 JIRA 연동