애자일(Agile) - 할 거면 제대로...
언젠가 나도 해보고 싶은 Agile(애자일)
진행 중인 프로젝트는 폭포수 방법론을 사용하고 있다. 일정을 잡고 단계별 검수하고 이후 작업자에게 전달하는 마지막이 되어서야 Product를 확인할 수 있는 방법론을 적용하여 진행 중이다.
그런데 해당 프로젝트에서 커뮤니케이션 솔루션으로 Atlassian의 JIRA와 Confluence를 사용하는데. 누군가는 Agile을 근간으로 진행하는 프로젝트라고 얘길 하기도 하다.
물론 Atlassian은 Agility 한 프로젝트 진행을 위해 JIRA를 만들긴 하였다. 하지만 솔루션 사용만으로 Agile 방법론을 적용했다고 얘기할 순 없다.
- Atlassian JIRA : https://www.atlassian.com/software/jira
- Atlassian Confluence : https://www.atlassian.com/software/confluence
그동안 다양한 프로젝트에서 Agile 방법론을 사용해보자는 고객의 의견들이 많았지만 사용의 한계가 있고 일반적인 기존 구축 프로젝트에서의 사용은 어려움이 따른다.
잘 알고 적절하게 써야 프로젝트 진행에 도움이 된다.
스쿼드, 트라이브, 챕터 방식을 사용해서 조직을 구성하는 것이 애자일의 중요한 요소가 아니라, 이런 모습을 찾으려고 계속 실험하고 시도하는 여정 자체가 애자일이다. - Odd-e KOREA 조승빈 코치
1. 사전적인 의미
Agile의 사전적 의미2. Agile 방법론이란?
정해진 계획만 따르기보다, 개발 주기 혹은 소프트웨어 개발 환경에 따라
유연하게 대처하는 소프트웨어 개발 방법론
3. Agile 방법론의 탄생 배경
전통적인 계획 중심 방법론 - 폭포수 방법론
폭포수 방법론의 규정된 프로세스대표적인 예 : 폭포수 방법론
명확한 요건에 따라 규정된 프로세스로 프로젝트 진행
프로젝트 진행 과정의 변수 발생의 대응의 어려움 있음
소프트웨어 개발 프로젝트에는 많은 변수로 인해 어려움이 따름
이런 변수를 반복적인 프로세스를 통해 해소할 수 있는 방법론이 나왔다.
전통적인 계획 중심 방법론 - 나선형 모델 방법론
나선형 모델의 적응적 프로세스대표적인 예 : 나선형 모델
프로젝트의 위험을 최소화하기 위해 목표 시스템의 기능을 프로토타입으로 나누어 점증적인 방식으로 개발함
다양한 요구의 변화를 수용할 수 있음
점검과 조정을 통해 위험을 낮춤
이상적인 방법이나 모델 자체가 복잡하여 비용이 많이 들고 프로젝트 관리가 어렵다
반복적인 프로세스를 진행 함으로써 변경에 대한 요건을 해소할 수는 있었으나 이 방법론을 사용하게 되면 많은 비용과 프로젝트 관리의 복잡도가 높아졌다.
전통적인 계획 중심 방법론 - Rational Unified Process
Rational Unified Process의 반복 점증적 프로세스대표적인 예 : Rational Unified Process
목표 시스템을 여러 번에 나누어 출시
폭포수 모델의 경직성을 보완하기 위해 개발됨
주로 기본 기능/우선순위가 높은 기능을 우선 개발하여 출시 고객과 시장의 피드백을 받아 다음번 출시 주기에 반영함
Rotional Unified Process는 애자일 방법론의 근간이 되었다.
4. Agile 방법론
Agile Process
적응적인 프로세스와 반복 점증적인 프로세스를 사용하는 Agile Process기존 프로세스와 애자일 프로세스의 차이점
짧은 주기, 반복 출시출시 주기를 짧게 한다. (다양한 요구 변화에 유연하게 대응) 일반적으로 2주~ 4주의 반복 주기를 권장함 (출시 주기는 짧을수록 좋다)
고객과 팀, 팀원 간의 소통, 협력을 극대화하는 실천법을 제공
고객의 가치를 생성하는데 중점을 둠
Agile 방법론의 장점
최소 기능 제품을 만들어 진화시키는 애자일 방법론작은 사이클을 반복하여 최소 기능 제품(MVP : Minimum Viable Product)을 진화시켜 나가는 것
- 함께 읽으면 좋은 글 : MVP는 제품이 아니라 프로세스다 https://brunch.co.kr/@suhyunbae/60
Agile의 역사
애자일의 역사
애자일의 역사애자일 방법론의 종류
스크럼
프로젝트 관리 기법, 추정 및 조정 기반의 경험적 관리 기법
최초 : The New New Product Development Game, HBR, 1986 (Hirotaka Takeuchi and Ikujiro Nonaka)
적용 : Ken Schwaber, jeff Sutherland, Mike Beedle, Mike Cohn, 1995
익스트림 프로그램 (XP)
소프트웨어 개발 방식
Kent Beck, Ward Cunningham, Ron Jeffries, 1999
그밖에
DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum), FDD, DSDM, Crystal Clear, 린 등
애자일 방법론의 종류 - 01
애자일 방법론의 종류 - 02애자일 소프트웨어 개발 선언
2001년 2월 17명의 경량 방법론 지지자들이 모여 공동으로 추구하는 가치 천명
4 문장으로 구성된 선언문 발표
애자일 선언문
I. 프로세스와 도구보다 개개인과 상호 소통
II. 포괄적인 문서화 보다 제대로 동작하는 소프트웨어가 더 중요하다.
III. 계약 협상보다 고객과의 협력이 더 중요하다.
Ⅳ. 세워진 계획을 따르기보다는 변화의 대응이 더 중요하다.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있음
이 작업을 통해 우리는 다음을 가치 있게 여기게 됨
프로세스나 툴보다는 개인과 상화 작용을 더 우선시하고, 복잡한 문서화보다는 동작하는 소프트웨어에 더 집중하여야 하며, 계약과 협상보다는 고객과의 협업이 더 우선이 되어야 한다. 계획대로 수행하는 방식보다 상황에 따른 변화에 민첩하게 진행되어야 한다.
애자일의 오해
1. 스케줄을 쥐어짜서 하는 프로젝트 방법론이다.
활력과 생산성을 고려하여 지속 가능한 속도를 파악하여 안정적인 성과를 내도록 적용하여야 한다.
* 하루 5시간의 집중도 있는 업무는 피하는 것을 권장함
2. 문서는 작성하지 않아도 된다.
프로젝트 진행에 필요한 양질의 문서 제작 등은 최대한 활용하여 커뮤니케이션의 용도로 사용할 수 있어야 한다.
3. 짧은 출시 주기로 인한 막장 코드
애자일은 코드 품질을 가장 중요하게 생각한다.
코딩 표준, 코드 리뷰, 리펙토링, 짝 프로그래밍, TDD 등과 같은 엔지니어링 실천법을 제공하여야 한다.
4. 설계나 계획 안 하기
프로젝트 진행에 필요한 설계 문서와 계획은 필수로 진행하여야 한다.
5. 애자일은 대형 프로젝트에서는 안돼
DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum)등은 대형 프로젝트에서 사용하는 애자일 프로세스이다.
* SAFe는 미국 정부를 비롯하여 애자일을 하는 회사의 50% 이상이 활용할 정도로 큰 인기를 얻고 있는 애자일 프로세스
애자일 사용 현황
스크럼이란?
미식축구나 럭비에서, 쌍방의 팀에서 세 명 이상의 선수가 공을 에워싸고 서로 어깨를 맞대어 버티는 공격 태세. 반칙이 있을 때 심판의 명령에 따라 짜는 것으로, 쌍방의 전위로써 짜는 세트 스크럼과 편을 가리지 않고 짜는 루스 스크럼의 두 가지가 있다.
스크럼(Scrum)은 프로젝트 관리를 위한 상호, 점진적 개발 방법론이며, 애자일(Agile) 소프트웨어 공학 중의 하나입니다. 스크럼은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다. - 위키백과
스크럼 프레임워크
1. 제품 기능 목록 작성
개발할 제품에 대한 요구 사항 목록(기능 목록)을 작성한다.
사용자의 요구사항 목록이라고도 할 수 있으며 결정된 제품 기능 목록은 확정된 것이 아니라 개발 중이라도 수정이 가능하지만 웬만하면 한 번의 주기가 끝나기 전까지는 수정하지 않는다.
2. 스프린트 계획 회의
각 스프린트 목표에 도달하기 위해서 필요한 작업 목록이다. 각 주기에서 개발할 작업 목록을 의미하며 세부적으로 어떤 것을 구현해야 하는지 작업자는 누구인지 작업 시간은 어느 정도인지를 세우게 된다.
3. 스프린트 수행
스크럼 모델에서 스프린트의 뜻은 반복적인 개발 주기를 의미한다. 스프린트 주기가 결정되면 배정된 작업을 중간에 멈추지 않고 전력 질주하여 끝내야 한다 그러기 위해서는 결정된 스프린트의 목표와 내용이 개발 도중에 바뀌지 않아야 하며 바꾸게 된다면 그 누구도 팀원들의 동의 없이 바꿀 수 없다는 원칙이 있다.
4. 일일 스크럼 회의
스프린트 기간에 하는 회의로 여러 특징을 가지고 있으며 대표적으로 짧게 한다, 진행 상황을 체크한다, 모든 팀원이 참석한다, 어제 한일을 이야기한다, 오늘 할 일을 이야기한다 문제점 및 어려움을 이야기한다 등이 있다.
5. 제품 완성 및 스프린트 검토 회의 및 회고
모든 스프린트 주기가 끝나면 제품이 완성이 된다. 그 최종 제품이 나오게 되면 검토 회의를 통해 처음 계획했던 대로 제품이 만들어졌는지 시연을 통해 피드백을 받고 나서 회고를 진행하여 필요한 개선점은 무엇이고 팀이 정한 규칙과 표준을 잘 준수했는지 검토한다 여기서 팀의 단점을 찾기보단 강점을 찾아 더 극대화하는데 중점을 둔다.
스크럼 역할 및 책임
스크럼 팀 규모
스크럼에서 권장되는 개발 팀 크기는 6 +/- 3입니다. 즉, 스크럼 마스터와 제품 소유자를 포함하지 않는 3 ~ 9 명의 구성원입니다
스크럼 팀 역할
Scrum Team제품 책임자 : 고객 / 이해 관계자 목소리
제품 책임자는 제품 백 로그 항목이 투명하고 명확하게 표현되고 팀의 모든 구성원이 항목에 대해 동일한 이해를 갖도록 합니다.
제품의 특성과 기능을 정의, 출시 일자와 내용을 결정
제품의 수익성(ROI)에 대한 책임
시장 가치에 따라 구현할 특성과 기능에 우선순위 부여
제품 백로그에서 특성 및 기능, 우선순위 변경 가능
작업 결과에 대한 승인 또는 거부 결정
비즈니스 부서와 커뮤니케이션
스크럼 마스터 : 일상적인 개발 활동을 수행하기 위해 개발 팀과 제품 소유자를 촉진 / 코칭하는 책임자
스크럼 마스터는 스크럼 팀과 스크럼 팀 외부의 다른 사람들이 스크럼 가치, 원칙 및 관행을 이해하도록 돕는 프로세스 리더입니다.
팀이 완전히 생산적이고 기능적이 되도록 보장
모든 역할과 기능에 걸쳐 밀접하게 협력하고 장애를 제거
외부의 간섭과 방해로부터 팀을 보호
스크럼 프로세스가 준수되도록 보장
일일 스크럼, 스프린트 계획 및 리뷰 회의에 참석
스크럼 팀 : 프런트 엔드 개발자, 백엔드 개발자, Dev-Ops, QA 전문가, 비즈니스 분석가, DBA 등과 같은 전문 기술을 가진 사람들로 구성
팀 구성원을 추가 / 제거하는 것은 전적으로 스크럼 팀의 결정입니다. 새로운 기술 세트가 필요한 경우 팀은 팀 내에서 해당 전문 지식을 구축하거나 팀에 새 구성원을 추가하도록 선택할 수 있습니다.
프로젝트의 결과를 위해 각자의 역할을 수행
교차 기능적, 자율적 조직화
적극적인 협동을 통하여 최선의 결과 도축
일반적으로 5~9명으로 구성
상근, 동일 장소 배치 권장
개발 기능 목록(제품 백로그) 작성
스크럼에서 작성하는 기초적인 요구사항
중요사항 : 우선순위, 요구사항의 명세
의미 있는 요구사항 모두 기제
스프린트 계획 회의를 통해 합의하에 실제 구현 가능한 것만 선정하여 스프린트 백로그로 전달됩니다
일반적인 프로젝트의 요구사항 정의서와 같은 의미로 개발 기능 목록 및 스프린트 백로그 등으로 불림
스프린트 계획
제품 백로그, 팀의 역량, 비즈니스 상황, 기술적인 사항, 현재 프로젝트의 상황을 확인함
모든 이해 관계자 참여하여 회의 진행
스프린트 목표와 스프린트 백로그 작성함
스프린트의 목표를 설정하고 목표 달성을 위한 작업 내용을 결정함
팀 능력 추정
휴일이나 외근, 업무 이외의 시간은 제외되어야 함
팀의 가용 시간 확인
각 팀원이 이번 스프린트 동안 작업할 수 있는 가용 시간을 확인 후 공유
스프린트 백 로그 작성
각 아이템에 대한 테스크 작성
담당자 배정 및 작업 예상 시간 작성
제품 백로그의 일부사항(협의된)이 상세 테스크로 작성
스프린트 일일 업데이트
계획에 따라 테스크를 실행
투명하게 관리하기 위해 일일 스탠드업 회의를 진행함
이슈사항 팀 공유
장애요소 등 파악 대응 방안 마련
스프린트 추적 - 번다운
계획대로 이루어지는지를 추적
작업 차트를 활용하여 진행 추이를 확인
테스크 보드 (칸반 보드)
계획 테스크, 진행 테스크, 완료 테스크로 구분
추가적인 내용 구분 가능
모든 테스크를 포스트잇 등으로 작성 필요
작업 내용/작업시간 등 표기
모든 TO-DO List 가 Complete 되도록 진행
작업 진행 현황을 가시적으로 공유할 수 있음
애자일 하게 일한다 (Agility)
애자일은 개발 방법론이며 일하는 방식이고,
조직문화이자 가치관이다.
스크럼과 칸반은 애자일 가치관을
잘 활용한 가장 대표적인 협업 방식
애자일 도입 체크사항
“애자일은 해결해야 할 문제가 복잡하고, 변화가 잦고, 불확실성이 높은 상황일 때 성과를 촉진한다.”
5. 애자일 사용 현황
국내 현황
먼저 실행, 빠르게 적용하고 개선, 사용자의 반응을 확인하고 개선
사용자 검증 없이 8개월간 공들여 개발했던 '카카오 플레이스'가 시장에서 외면받는 모습을 보며, 2주 만에 개발했다는 당근마켓 앱. 대신 빠르게 론칭 한 뒤에, 사용자들의 반응을 살펴가며 일주일에도 몇 번씩 업데이트해나갔다는 이 사실이 진짜 말로만 듣던 애자일이 뭔지 제대로 보여준 것 같아요. 유사 앱도 너무 많아지고, 유저들의 니즈도 너무도 다양해진 요즘, 처음부터 완벽하고 모두를 만족시킬 수 있는 서비스를 출시한다는 건 사실상 불가능에 가깝다고 생각하기 때문에 이제 애자일은 필수적인 요소로 자리 잡았다고 생각합니다.
신속한 실행 과정, 개선은 더 빠르게
우리는 완벽한 준비가 성공을 담보한다고 생각하지 않습니다.
방향이 정해지면 문제 해결에 집중하며, 모두 같은 곳을 바라보며 빠르게 실행합니다. 신속한 실행 과정에서 빠른 성공을 학습하여, 작은 실패는 더 빠르게 개선합니다.
일주일 만에 실제로 작동하는 MVP
지금까지 진행했던 프로젝트 중 가장 기억에 남는 것을 소개해주세요?
합류한 지 얼마 안 되었을 때 만들었던 ‘내 부동산 시세 조회‘ 서비스가 기억에 남는데요. 기획이 끝나자마자 디자인이 이틀 만에 나오고, 개발은 2~3일 만에 끝나서 일주일 만에 실제로 작동하는 MVP(Minimum Viable Product : 사업 가설을 테스트해보기 위해 최소한의 노력과 개발 기간으로 만드는 제품 버전)가 출시되었습니다.
국외 현황
우리는 구성원에게 많은 책임과 신뢰를 제공합니다. 하지만 그 실패로부터 배워야 합니다. 동일한 실수를 두 번 반복하면 충분히 성장하지 못하고 있다는 징후일 수 있습니다. - 스포티파이 HR 비즈니스 파트너 요한 셀그렌
Scaling Agile @ Spotify
스쿼드(Squad)
스포티파이는 스쿼드(Squad)라 불리는 단위 조직으로 출발한다. 스쿼드는 6~12명으로 구성된 자기 완결적 조직으로 마치 미니 스타트업과 같다. 설계부터 개발과 테스트에 필요한 모든 기술과 도구를 갖추도록 조직된다. 각 스쿼드는 장기/단기 미션이 있으며, 동시에 사용자 경험의 서로 다른 부분에 대해 하나씩 책임을 맡고 있다. 하나의 미션과 서비스의 특정 부분을 오랫동안 맡아 진행하기 때문에 해당 영역의 전문가 그룹으로 성장한다. 자신들의 일하는 방식을 스스로 결정할 수 있으며, 독립된 사무 공간과 라운지 등의 작업 공간도 제공된다.
트라이브(Tribe)와 얼라이언스(Alliance)
음악 플레이어, 모바일 서비스, 백엔드 인프라와 같이 연관된 분야의 스쿼드가 모여 트라이브가 조직된다. 스쿼드가 자율성을 가지고 일하듯, 트라이브 또한 운영에 관한 실험적 자율성을 지닌다. 트라이브는 이상적으로 40여 명 수준의 규모를 권장하고, 최대 150명이 넘지 않도록 설계된다. 조직이 커지면 필연적으로 생기는 제약과 규칙, 관료주의와 정치, 불필요한 계층을 통한 낭비를 막기 위한 방안이다. 부족의 규모를 넘어서 속도가 느려지고 마찰이 증가하면, 밀접하게 연결된 임무를 가진 두 개 이상의 트라이브를 지원하는 동맹, 즉 얼라이언스가 형성된다.
챕터(Chapter)
챕터는 같은 트라이브 내에서 비슷한 기술과 유사한 역량 분야에서 일하는 사람들의 모임이다. 각 챕터는 정기적으로 모여 그들의 전문 분야와 구체적인 도전과제에 대해 논의한다. 이를 통해 지식을 공유하고 서로의 발전을 돕는다. 흔히 스포티파이에는 관리자가 없다는 일반적인 오해가 있다. 하지만 챕터 리드(Chapter lead)가 챕터 멤버에 대한 일종의 라인 매니저로 구성원 개발, 급여 설정 등과 같은 관리자의 책임을 진다. 전통적인 관리자와 차이가 있다면 챕터 리드는 전문적 관리자에 국한되지 않고, 자신이 혹한 스쿼드의 일원으로 업무를 수행할 책임이 있다는 것이다.
길드(Guild)
길드는 오픈 커뮤니티로서 누구나 가입과 탈퇴가 가능하다. 관심에 따라 여러 길드에 가입할 수도 있다. 2012년 도입 시 길드의 원래 목적은 트라이브 간에 전문성을 융합하기 위한 것이었으나 이제는 그 이상으로 발전하여 공통 관심사를 지닌 구성원의 이해 공동체가 되었다. 자바 길드, C++ 길드, 또는 안드로이드 길드와 같은 업무 관련 길드가 있을 뿐 아니라 공예, 양조장, 사진 길드와 같은 취미 관련 길드도 있다. 챕터는 트라이브 내에서 조직되고 운영되지만, 길드는 일반적으로 전체 조직을 가로지른다. 동일한 범위의 지식과 도구, 코드 및 관행을 공유하고자 한다면 누구나 모일 수 있다.
- 함께 읽으면 좋은 글 : Spotity의 Squad 팀 모델은 실패했다. https://news.hada.io/topic?id=2191
애자일 조직에서 리더가 해야 할 일
첫 번째
구성원들을 참여시키고 그들의 상호작용을 촉진한다.
두 번째
구성원들이 시스템을 개선할 수 있도록 한다.
세 번째
모든 고객이 행복할 수 있도록 돕는다.
출처 및 참조
- 애자일(Agile) 소프트웨어 개발 강의 : https://tacademy.skplanet.com/frontMain.action
- State of Agile : https://stateofagile.com
- Spotify Scaling : https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
맺음말
내용 참조를 많이 했습니다.
아직도 애자일에 대한 질문이 많고 배움이 부족하다는 걸 느낍니다.
그래도 여기저기 뒤져보는 재미는 있네요!
언젠간 애자일을 온전히 할 수 있는 프로젝트, 서비스를 해보고 싶습니다.
