[프로젝트 방법론] 애자일[Agile] 방법론

미국의 선진 소프트웨어 회사의 경우, 애자일 방식을 95% 이상 사용하고 있다.
Agile, DevOps는 기술이라기 보다는 문화라고 보는 것이 낫다.
현재의 기술에 만족하면 가까운 미래에 뒤쳐지는 성향이 있다.
Agile, MSA, DevOps, Cloud Native 등등에 대해 알아보자

 

Agile 프로젝트의 역할자

1. SO 역할자

- 약자 : Solution Owner

- 역할 : 스크럼 팀 리딩 & 스크럼 마스터

1. 고객 접점에서 모든 비즈니스 요건 정리

2. 스크럼의 각종 Ceremony 리딩

3. 스크럼 팀 설계, 구축의 Cadence를 유지

 

Q. SO는 무슨 역할을 하는가?

- SO는 전통적인 애자일에는 존재하지 않는 역할

- SO Scrum Master의 역할과 PO(고객)의 일을 서포트하는 역할

1. 고객의 업무 정의 (기존 파트리더(PL), 분석설계자와 비슷한 역할)

2. 스크럼 팀 리딩 (스크럼 팀이란 개발팀을 의미)

- Daily Stand-up 리딩, Sprint Planning 리딩, Sprint Review 리딩

3. 요구사항을 이끌어 내고, UserStory로 만드는 것이다.

- UserStory는 요구사항과 비슷하지만, 좀더 쉽게 접근하고, 쉽게 이야기하는 주제이다.

- UserStory를 기반으로, 2주만에 데모를 만들어낼 수 있다. 

 

Q. Daily Stand-up에서는 무슨 얘기를 나누는가?

- 어제한 일, 오늘할 일, Blocker(개발 장벽)를 공유하고 나누는 가운데 이슈를 미리 파악할 수 있다.

- 일일보고 형식으로 만들지 말고, 투명하게 공유할 수 있는 자리로 만드는 것이 중요하다.

- 재밌는 일이나, 업무적인 이슈 뿐만 아니라, 사건 사고들도 나누면서 서로 친밀하게 지내는 분위기를 형성하는 것이 성공 포인트이다.

 

Q. SO에게 요구되는 역량은?

- 중요한 역량은 커뮤니케이션 역량이다.

개발자는 개발을 편하게 할수 있도록

고객과는 잘 협의할 수 있도록

고객의 요구사항을 잘 이끌어내고, 고객이 원하는 방향을 오너십을 가지고 이끄는 것이 중요하다.

업무적으로는 분석설계 역량 또한 필요하다.

애자일로 프로젝트를 진행하려면, 기존 워터풀 방식에 익숙한  산출물과 관련해서, 잘 사전타협하는 것이 필요하다.

 

2. PO 역할자

- 약자 : Product Owner (고객)

 

3. SE 역할자

- 약자 : Solution Engineer

- 역할 : S/W 설계 및 구축 수행

1. Modern Web 전문가

2. 데이터부터 화면까지 Full-Stack 개발

3. 업무 구현 및 테스트코드 개발

 

"나는 FULL-STACK 엔지니어다"

- SE의 경우 BACKLOG를 파악하고, Sprint Planning 시간 때에, Backlog의 비즈니스, 제약사항, 기술을 함께 모여 검토하고 공감대를 형성

- 소프트웨어 설계 & 구축

- 개발자들은 본인이 개발할 USER STORY를 선택하게 되는데, USERSTORY의 서버 사이드를 맡을지, 클라이언트 사이드를 맡을지 알 우 없다. 

- SE의 경우, 개발에 필요한 주요 기술 구현 계획 수, 기술 제약을 해결해나가는 SA를 포함한다.

 

Q. 기존 방식과의 차이점

- PL이 개발자에게 할당하는 방식에서, 본인이 개발하기를 원하는 UserStory를 결정

- 스크림 미팅 내에서 개발을 저해하는 요소인 Blocker를 공유

- 개발, 데모, 회고 반복

 

Q. 기존과 Cloud Native의 차이점

- Container나 Server-less Architecture를 사용하여, 어플리케이션을 개발하고, 빌드/배포를 자동

- 품질을 유지하면서, 빌드/배포를 자동화하면서 품질을 지키려면 테스트 자동화 코드를 작성해야할 필요성이 있다.

- 개발과 배포를 도와주는 도구, git은 중앙 관리식 svn과 다르게, 분산 관리로써 빠르게 개발하는데 용이하다.(원격저장소에 영향을 받지 않음)

- 기능이 완료되면 코드리뷰를 받아, 조기에 품질확보가 가능

- 최신 기술 스탭에 대한 React, Typescript, Serverless, SpringBoot, AWS 제공 기능 학습, MSA에 대한 이해또한 선행되어야 한다.

 

4. SA 역할자

- 약자 : Solution Architect

- 역할 : Scrum Team 기술파트리더, 개발의 Core 역할을 담당한다.

1. 'Sprint#0' 전인 'Discover' 단계부터 참여하여, As-Is를 파악하고, To-Be Architecture를 수립

2. 개발 프레임워크 선정

3. SO와 함께 고객의 요구사항을 상세화 & MVP(Minimum Viable Product, 최소한의 핵심 기능만을 탑제한 제품)를 설계

4. 개발 표준 수립 & 로컬 개발환경 구성

5. 다음 Sprint에 대한 Backlog Refinement 수행, 스프린트마다 반복 수행

 

5. SQE 역할자

- 약자 : Solution Quality Engineer

- 역할 : 테스트 코드 개발 및 자동화 테스트 구축

1. SE의 역량을 기반으로 테스팅 역량까지 보유

2. 시스템 전반의 테스트 전략 수립

3. 테스트코드 직접 개발 및 테스트 코드 리뷰

4. 자동화 테스트

 

"나는 솔루션의 품질을 확보한다"

자동화테스트 환경 구축

개발된 소스에대한 코드 리뷰, 결함관리

프로젝트마다 개발환경이랑 기술셋이 다양한데, 적합한 테스트 도구 및 전략을 선정

 

테스트의 종류

자동화 및 수작업 : 기능테스트, 사례스토리 테스트, 프로토타입 시뮬레이션

자동화 : 단위테스트, 컴포넌트 테스트

-> SQE가 하는 일, 테스트 자동화

수작업 : 탐색적 테스팅, 시나리오, 사용성 테스팅, 사용자 승인 테스팅, 알파/베타

도구 : 성능 & 부하 테스팅, 보안 테스팅

 

Unit Test > API Test > Journey Test > Manual/Exploratory 

개발반영이 있을때마다 테스트 자동화 수행

 

일정하고 지속적인 배포를 위해 테스트 자동화가 필요하다.

스프린트마다 이전 단계에 대한 회귀테스트가 진행되어야하는데, 수동으로하기에는 무리가 있다.

 

Code Static 분석툴 : ESLint, Prettier
Unit Test 도구 : Mocha, Chai, SINON.JS, Jest

Code Review 도구 : BitBucket, Enzyme&React Testing Library

Module Test 도구

Health Check 도구 : Cypress.io

Smoke Test 도구 : Postman

 

Q. Smoke Test란?

배포 전 테스트 프로세스 중 스모크 테스트에 대해 알아봅시다.

유래 :전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트에서 유래합니다.

시스템의 안정성 및 주요 기능이 제대로 작동하는지 확인하고, 모든 버그를 찾는 것이 아니라 제품의 안정성을 유지하기 위해 테스트 전에 한번 확인하는 것을 이야기합니다.
스모크 테스트는 비용이 큰 품질조직의 테스트에 앞서서 프로그램의 중요한 기능이 잘 작동하는지 확인하기 위해 소프트웨어 빌드 후에 수행되는 소프트웨어 테스팅입니다.

 

테스트가 자동화되지 않으면, Merge하기가 쉽지 않다.

매뉴얼 테스트만 해야 확인할 수 있는 결함들 또한 존재한다.

테스트마다 어떤 테스트가 유리할지를 효율성을 고려해서, 선택해서 수행해야한다.(수동 vs 자동)

 

UI Dependency나 임시 기능은 테스트 코드를 작성할 경우, 나중에 유지보수할 때 테스트코드까지 바꿔야하므로, 충분히 고려해서 작성해야 한다.

 

6. CDS 역할자

- 약자 : Cloud DevOps & Security

- 역할 : 클라우드 아키텍처, IaC 개발, CICD 파이프라인 설계구축(기존 TA와 비슷)

1. Infra Architect? Data Architect? Software Architect? Network 전문가역할 수행

2. 공용 클라우드 및 OSS 전문가

3. IaC(Infra as Code) 코드 작성 및 형상 관리 활용 가능

4. Git(Bitbucker, Gitlab, Github), CI/CD Tool(Jecnkins, CircleCI, Gitlab), Cloud Native 기술(AWS Lambda, Google Cloud Function)

 

"나는 Cloud Native 아키텍처를 만든다."

클라우드 위에 데브옵스를 구현

Container 기술 : OS 레벨의 가상화, Docker 도구, Kubernate

CDS는 Cloud 상에서 DevOps 환경을 구축해나간다.

 

DevOps란?

회사에서 개발을 하다보면 개발만 한다고 되는것이아니다. 프로젝트를 빌드하고 배포하고 테스트하는 운영 업무도 같이 해야 한다. 보통 회사에서는 이 두개의 일을 하는 조직을 나눠서 관리하게 된다. 그런데 하나의 서비스를 두개의 팀에서 관리하다보면 비효율적인 부분들도 많고 서로 의사소통하기에도 좋지 않다.
개발자는 계속해서 새로운것을 도입하고 싶어하지만, Ops들은 안정성을 최우선으로 여긴다. 그래서 등장한것이 DevOps이다. 이 DevOps라는 개념은 소프트웨어 개발 방법론 중 하나이다.
개발자들과 Ops들을 서로 잘 융합시키고 의사소통이 원할하게 하기 위한 개발 방법론이다.

DevOps의 특징

1. Cross Functional Team

하나의 팀에 개발 부터 운영까지 모두 할 수 있는 사람들로 채우라는뜻이 아니라, 각 프로세스의(개발 ~ 배포 및 테스트까지) 담당자들을 하나의 팀으로 모으라는 뜻이다. 서비스 기획부터 개발 운영 테스트 배포등 모든 제품 개발 프로세스를 하나의 팀에서 할 수 있도록 해야 한다는것이 Cross Functional Team이다.

 

2. Widely Shared Metrics

한마디로, 팀원 모두가 알고있는 하나의 공유된 지표가 필요하다는것이다.
서비스를 개발만 하는게 아니라 서비스가 운영에서 잘 돌아가고 있는지, 사용자의 반응은 어떤지를 측정할 수 있는 기준이 필요하다는것이다. 그리고 이 지표를 기준으로 팀원들이 아 우리 서비스가 이정도로 잘돌아가고있구나, 아니면 아 이부분은 좀 부족하구나라는걸 인지할 수 있도록 해야한다.

 

3. Automating repetitive tasks

반복적인 일들은 자동화 하라는것이다. CI/CD를 이용해서 빌드-배포-테스트 프로세스를 자동화 해야한다. 반복작업에 투입되는 시간을 줄여야 좀 더 생산적으로 일할수 있고 좀 더 고도화된 서비스를 만들 여유와 시간을 벌 수 있을것이다. 고급인력들을 데려다 놓고 반복작업에 시간을 쏟게 하는것은 개인적으로나 회사 전체로보나 손해이다. 그리고 자동화 툴을 만드는 과정에서 시스템 전체에 대한 이해가 높아진다. 여러모로 장점이 많다.

 

4. Post Mortems

직역하자면 후처리라고 할 수 있다. 장애나 이슈가 있을때 그걸 혼자만 알지 말고 팀원들과 공유를 해야한다. 서비스를 운영만 하다보면 어떤 이슈가 있을때 이 이슈가 얼마나 큰 이슈인지를 파악하지 못할 때가 많다.

 

5. Regular Release

짧은 주기의 정기 배포를 통해서 빠르게 서비스의 기능을 개선하고 고객들의 VoC를 반영해 나가야한다.

 

CI/CD 파이프라인이란?

- 테스트, 정적분석, 빌드, 배포까지의 과정을 자동화하는 것을 의미

- Jenkins 라이브러리를 보면 이해가 되려나? (공용 코드 참조하여, 개발, 스테이징, 운영에 배포 자동화)

 

IaC를 사용하면?

- 기존에 썼던 좋은 Architecture를 재사용할 수 있음

 

7. XD 역할자

- 약자 : eXpreience Design

- 역할 : 사용자 분석, UX/UI 설계 및 디자인, Visual Design

사용자 관점에서의 업무분석 수행, 요구사항을 만족시키는 창의적인 디자인

 

"나는 사용자의 경험을 만든다"

사용성이 높고 목적이 있는 사용자경험을 만든다.

 

디자인 도구(Design Mockup)를 통해 디자인을 하고, 다른 역할자에게 전달

PM은 관리관점에서 요구사항 분석, PL은 구현관점에서 요구사항 분석

 

"프로세스맵 , IA Map(이벤트에 따른 흐름), WireFrame(레이아웃, 이벤트흐름), Mockup/ProtoType 산출물(interaction, animation)"

해당 산출물을 통해, 빠르게 MVP를 뽑아낼 수 있다.

"Full-Stack Designer이다." UI/UX와 비슷하다.

 

디자인 협업도구 : Figma, Sketch, Zeplin

 

AM 프로젝트의 진행

• Daily Stand-up : 이슈, 오늘 할 일
• SO : 고객의 요구사항을 UserStory로 정리하고, 애매모호한 부분은 고객과 소통합니다.
• SE : 구현, Pair Programming
• Backlog Refinement (매주 1~2번)
• Issue 있을 경우, Parking Lot
• Day10 :고객과 함께 Sprint Demo 수행
• Day10 :Sprint Retro 수행(팀원 서로 격려, 개선할 부분, 회고)
• Day10 :Sprint Planning(다음 스프린트 준비, Backlog Refinement를 거친 UserStory의 Description과 Acceptance Creteria를 이해하고, 상호 논의를 통해 User Story 업데이트)

 

AM 이란?

- Application Modernization(앱의 현대화)

- 대표적으로 MSA(Micro Service Architecture)가 있다.

 

재플랫폼(클라우드 중심)

재코딩(React UI)

재설계(MSA, Serverless)

 

협업툴(Wire Work, Wiki, Code), CI/CD Pipeline 툴, 커뮤니케이션툴(Slack, Slack 플러그인-Jenkins)

 

자발적 참여 & 지식공유의 문화

- Lunch & Learn

- OpenChapter Meeting (지식 공유)

- Sync Meeting (지식 공유나 궁금한 점)

 

예전에는 고객이 요구사항을 주고, 가끔씩 확인하는 방식이었다면, 이제는 고객이 프로젝트에 참여하는 방식이다.

Sprint 내에 추가 요건을 받지 않는다.

프로젝트의 전체 흐름을 파악해야되는 부담이 있다. 체험과 문화가 중요하다.