SookDev

🧩 애자일 방식

워터폴과 애자일

워터폴

요구분석 및 기획,설계 → 디자인→ 개발 → QA → 배포

미래에 일어날일을 예측하며 기획하고 문서작업을 거친 후 순차적으로 진행되는 정형화 된 접근방식이다.

그만큼 기술적인 위험요소가 적은 장점도 있다.

하지만 고객과 시장은 빠르게 변화하고 있고 이런 상황에서 미래를 완벽하게 예측하여 배포단계까지 가는것은 사실상 불가능하다.

고객은 개발이 완전히 끝난 후에야 “실체” 를 알 수 있어 시각적으로 확인 후 수정사항을 분명히 요청할것이다.

그럴경우 언제 작업했는지 기억조차 나지않는 코드로 돌아가 개발수정 작업을 해야하고, 심하면 기획단계까지 다시 돌아가야 하기 때문에 일정, 비용 모두 잃을 수 있다.

이러한 단점을 보완한 방식으로 나온것이 바로 “애자일” 방식이다.

애자일

요구분석 및 기획,설계 → 디자인→ 개발 → QA → 배포 ♾

“좋은것은 빠르게, 낭비는 없게”

를 모토로, 작업을 일정한 주기의 짧은 단위의 스프린트로 진행하고 프로토타입을 만들어나가는 사이클을 반복하는 개념이다. 철저한 아웃풋 중심이기 때문에 보고, 서류작업을 최소화 하여 빠르게 결과물을 가진 후 고객과 먼저 커뮤니케이션 한다.

빠르게 진행하는 식보다 미흡할수는 있으나 개발단에서 미처 생각하지 못한 부분에 대해 피드백을 받을 수 있다. 여기서 중요한것은 더 나은 대안이 나올수 있다는 태도를 가지는 것이다.

고객들은 이러한 프로토타입을 보고 피드백 및 수정 요청을 할 수 있으며 그만큼 유연하고 신속한 대처가 가능하기 때문에 요즘 기업들에서는 점차 애자일방식을 선호하고 있다.

애자일의 가치가 있는 조직운영방식

고객은 협상,계약의 대상이 아닌 협력의 대상

절차나 형식으로 인한 낭비를 없애고 빠른 결과물에 초점을 둔다.

유연하고 신속한 대처

자율성과 권한을 가진 조직 운영

애자일 용어 정리

🌞 스프린트

반복되는 개발주기, 짧게는 1~2주, 길게는 3~4주의 스프린트 단위로 쪼개어 작업하는 방식. 팀의 애자일 방법론 경험치에 따라 익숙하다면 2주, 역량이 낮다고 판단되면 4주를 주기로 한다.

스크럼과 칸반 차이점

스크럼과 칸반은 모두 애자일 방법론에 기반한 프로젝트 관리 방법입니다.

스크럼은 일정한 주기(주로 2주)의 스프린트를 통해 개발을 진행하고, 스프린트의 시작과 끝에 회의를 통해 전반적인 진행 상황을 확인하고 계획을 조정합니다. 각 스프린트는 프로덕트 백로그에서 선정된 일부 작업 항목을 포함하고 있습니다.

칸반은 스크럼보다 유연하고, 주요 작업 항목을 게시판 형태로 표시하고, 각 항목을 이동하면서 진행 상황을 파악합니다. 각 항목은 작업을 진행할 때마다 이동하며, 칸반 보드에서는 각 항목의 진행 상황을 한눈에 파악할 수 있습니다. 각 항목은 릴리즈 당시에 반드시 완료되어야 하는 작업이 아니라, 우선순위가 높은 작업부터 처리하는 것이 주요 목표입니다.

즉, 스크럼은 일정한 주기를 기반으로 작업 항목을 선정하고, 각 스프린트의 시작과 끝에 계획을 조정하며, 칸반은 우선순위가 높은 작업부터 처리하면서 진행 상황을 파악하는 방식입니다.

🌞 스크럼

스크럼은 정의된 테스트 목표를 달성하기 위해 업무를 결정하는 것으로, 스프린트의 작업결과 및 리뷰를 책임자와 팀원들끼리 나눈다.

스크럼의 가장 큰 특징은 스프린트 기간내에 계획된 작업 외에 다른 작업들은 진행중인 스프린트에 포함시키지 않고 오로지 계획된 이슈들만 작업을 진행한다는 것이다.

스크럼 진행상황

비전 설정

팀의 목표. 우리 팀 또는 회사가 3-5년 뒤에 어떻게 돼있을지 목표를 세운다.

로드맵 설정

팀의 비전 달성을 위한 연간 계획.

프로덕트 백로그 정리

로드맵을 실행하기 위해 3개월 간 해야 할 일을 정리한다.

릴리즈 플래닝

프로덕트 백로그를 실행하기 위한 일정을 계획하는 것이다.

일주일~한달동안 어떻게 일을 할지에 대해 이야기하는 것이다. 프로덕트 백로그에서 이번 스프린트에서 할 일을 정하면 그게 스프린트 백로그가 된다.

데일리 스크럼

매일매일 모든 팀원이 모여서 일의 진척도, 문제상황 등을 공유하는 짧은 회의이다. 데일리 스크럼을 통해 스프린트가 올바른 방향성으로 나아가고 있는지 검토 할 수 있다. 매일 진행하고 효율성을 위해 진행하다 보니 비교적 짧은시간이 요구된다. 같은시간, 같은장소, 10분내외의 시간 안에서 진행한다.

스프린트 종료후 결과물을 살펴보고 다음 스프린트는 어떻게 진행할지 이야기 하는 것이다. 스프린트 리뷰에서는 모든 이해관계자들이 모인다고 하는데, 소규모 팀에서는 사실상 리뷰와 회고를 동시에 진행하면 된다.

회고 : 팀원들끼리 어떻게 일했는지, 어떻게 하면 더 잘할 수 있는지 이야기 한다.

ex) 보통 다음과같은 항목에 대해 데일리스크럼을 진행한다.

어제는 어떤 작업을 하였나

오늘은 어떤 작업을 할 예정인가

이슈, 어려움이 있었나

🌞 백로그

제품이 요구하는 기능과 그 기능을 개발하는 우선순위를 관리하는 목록기존의 워터폴형식에서 미래를 추상적으로 예측하는 대신, 특정 기간동안 목표와 필요 작업을 백로그로 명시하고 스프린트가 끝나는 시점에는 팀원 간 피드백을 가질 수도 있다.

🧩 JIRA software

애자일 프로젝트 최적화 툴, JIRA

왜 JIRA 를 사용하는가?

애자일 팀을 위한 프로젝트 관리로 효율적인 태스크 계획 및 추적을 제공한다. (개발자 관점으로 작성)

지라에서 제공하는 에픽과 스토리 혹은 태스크로 조직 내에서 팀과 효과적인 커뮤니케이션을 기대할 수 있다.

스프린트 단위로 끊어가기에 좋은 업무 툴

백로그에서 프로젝트 단위로 스프린트 업무를 지정할 수 있다.

각 팀별로 회의를 거쳐 담당자, 중요도(우선순위), 맡을 업무에 대한 시간을 설정하여 태스크관리 용이

보드에서 할일, 진행중, 완료 세 단계로 나누어 업무분할

git - 브랜치에 커밋메세지를 이슈 키에 맞게 작성하면 연동이 되어 다른 사람들도 쉽게 확인가능

슬랙 이용시, 연동이 가능하다.

로드맵으로 주기,월,주 별로 스프린트를 볼 수 있다.

회의록은 컨플루언서에서 작성하여 연동 가능

Initiative

이니셔티브는 공통의 목표를 추구하는 에픽의 모음

여러 팀의 에픽을 수집하여 에픽 자체보다 훨씬 더 광범위하고 큰 목표를 달성하는 개념이다.

에픽은 한 달 또는 한 분기에 완료할 수 있지만 이니셔티브는 종종 여러 분기에서 1년 사이로 잡는다.

예를들어, 로켓 우주선 회사가 올해 발사당 비용을 5% 줄이려 한다고 가정해 보겠습니다. 이것은 하나의 에픽이 그렇게 큰 목표를 달성할 수 없으므로 이니셔티브에 매우 적합합니다. 이니셔티브 내에는 “발사 단계 연료 소비 1% 감소”, “분기당 발사 횟수를 3회에서 4회로 증가”, “모든 온도 조절기를 71도에서 69도 #Dadmode로 낮추기”와 같은 에픽이 있습니다.

Epic

여러 개의 작은 작업으로 나눌 수 있는 대규모 작업. 배포는 Epic 단위로 정의한다.

팀의 진행 상황을 엔지니어링 책임자에게 보고한다면 에픽 단위로 말한다.

Task

이슈 등록 시 주로 사용하게 될 일감 정도로 볼수있다. 사용자입장보다 기술적인 측면에서 작성하는게 정석이다.

태스크는 최대한 작은 단위로 쪼개어서 개인에게 할당하도록 한다

개발 팀의 동료와 이야기를 나누고 있다면 스토리, 태스크 (이슈) 단위로 말한다.

Story

프로덕트 백로그에 작성되는 목록으로, 에픽 안에 포함된다.

형식은 (유저)가 (필요/욕구)를 위해서 (필요/욕구)를 원한다 이다.

형식은 조금씩 변화해도 되지만 유저 입장에서 작성되어야 한다

📢

JIRA에서는 Story와 Task를 같은 레벨로 구분하지만, 일반적으로 Story를 더 작게 나눈것을 Task라고 정의한다.

🧩 어떻게 적용시킬 것인가

⚠️

스퀘어스는 현재 노션과 레드마인 두가지 툴 섞어 사용중. 회의록은 노션에 페이지가 있긴하지만 관리가 잘 되고있는지에 대해 의문이 든다. 업무 진행상황은 API 요청사항페이지에서 작성드리면 백단에서 진행상황을 변경하는 방식으로, 프론트, 백 팀별로 나누어지지 않아 알아보기가 힘들다.

현재 내가 진행하고 있는 큐샵의 스프린트는 워터폴과 애자일의 콜라보레이션(?) 으로 이루어지고 있는것 같았다.

문서화가 된 기획이 없고 개발착수에 들어간것으로 봐서는 애자일같기도 하나,

2월 최종배포 라는 큰 일정을 가지고 그 안에서 개발하는 방식은 워터폴 같기도 하다.

이렇게 되면 큰 문제점은 방향성을 잃는다는 것이다.

애초 큐샵의 회원가입/로그인, 정보수정, 마이페이지를 맡게 되어 퍼블리싱까지 끝내놓은 상태이나 결론적으로 마이페이지만 배포하기로 하여 초기의 계획이 깨지게 되는것이다.

처음부터 다시 새롭게 시작한다고 결정함과 동시에 기획/디자인 + 프론트기능개발 + 백엔드 합의를 거쳐 기간설정을 했으면 서로의 상황도 알게되어 현실적으로 어떤 부분까지 작업이 가능한지, 어떤부분을 요청드려야 할지 쉽게 파악했을 것이다.

일정상 지금 당장 JIRA 를 도입 하기엔 어려움이 있을 수 있으나 이전 회사에서 JIRA의 효율성 높은 사용자경험을 했기 때문에 큐샵 뿐만 아니라 스퀘어스의 전 서비스에 도입하면 좋을것같다는 생각을 하였다.

현재는 사내 사이드프로젝트에서 JIRA를 우선적으로 도입 하기로 결정 했고 다음과 같은 운영방식으로 모색해 나갈 예정이다.

회의

매주 화요일마다 진행 (16:30~)

아직 몇 주 단위로 스프린트를 끊어갈지 회의하진 않았지만 사이드 프로젝트인 만큼 넉넉하게 3주 텀을 가지고 해도 좋을 것 같다. 하지만 이 모든건 역시 기획과 디자인이 나와야 컨펌할 수 있을것 같다.
페이지 별 디자인이 나온 후 각자 착수할 담당자, 개발시간을 측정하여 스프린트 기간을 맞추도록 한다.
일단 작업 / 스토리 / 버그 의 이슈 유형을 만들어 두었으나 스토리와 task 를 분리할 필요 없이 작업(Task) 나 버그 위주로 선택하면 될 듯 하다.