[Agile] 초심자를 위한 Agile기본

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.

 

 이번 내용에서는 애자일 개발, 개발 중에서도 가장 많이 채용되고 있는 스크럼 개발 프래임 워크와 툴 등의 공유해보고자 한다.

 

프로젝트

---

프로젝트란 아래의 그림대로, 명확히 정의되어 있는 목표를 달성하기 위한 계획, 수행하기 위한 관리 환경이다.

 

애자일 개발이란

---

 애자일(Agile)이란 재빠르다, 기민한, 머리 회전이 빠른 의미이다.
 애자일 개발은 시스템이나 소프트 개발에 있어서의 한 방법으로 커다란 단위로 시스템을 구분하는 것이 아닌, 작은 단위로 테스트나 구현을 반복해나가는 개발 방법으로, “만들면서 생각해보자”는 방법이다.

 

 

애자일 개발의 역사

---

 프로젝트 관리 방법은 제2차세계 대전중에 생성된 관리 프로세스라고 알려져있다. 1940년대에는 프로젝트 관리 방법론 “waterfall”의 기초가 작성되어 있다.
 워터폴 개발에서는 개발 현장에서 자주 사용되는 방법으로,  개발 순서를 1개씩 확인해가면서 공정을 진행해나가는 방법이다. 개발을 각 공정으로 나눠서 진행하지만, 다음의 페이스로 나아가면 나중에서 돌아올 수 없기도 하다. “요건이나 사양” 에서 “디자인” “개발” “통합” “테스트” “릴리즈”까지의 각각의 공정마다 정해진 기술자가 담당하여 폭포와 같이 위에서 아래로 흐르는 형식이다.

 2001년 소프트웨어 및 프로젝트의 전문가 그룹이 애자일 마니페스트를 만들어 이것을 애자일이라는 공통 의식이 됐다. 아래의 그래프는 Standish그룹의 레포트에서 애자일과 워터폴의 달성확률의 보고이다.

 이 그래프를 보면 Successful의 비율이 워터폴의 14%에 대해서 애자일은 42%와 같은 세배가 되어 있다. 기존의 프로젝트는 성공하고 있지만, 스코프의 거대화가 직면하여 그 금액과 시간의 낭비가 발생하고 있다. 따라서 새로운 관리 프로세스의 작성가 필요해져서 애자일의 출범하게 된 계기가 된 것 같다.

 애자일 개발은 워터폴 개발과 달리 위 이미지와 같이 커다란 단위로 시스템을 구분하는 것이 아닌, 작은 단위로 구현과 테스트를 반복하여, 개발을 진행해나가는 방법이므로, 규모가 커다란 프로젝트에서 자주 사용되고 있다. 애자일형 개발에서는 개발 멤버가 시스템에 있어서 우선 순위를 붙여 짧은 기간에 납품을 목표로 움직인다. 시스템의 우선순위를 정하기 위해서는 미팅을 매일하여 팀내에 부드럽게 연계하는 스크럼이라는 방법이 주로 사용된다.

 

 

애자일 개발의 12가지 원리

---

아래의 주요 특징을 이해한 후에 애자일 개발을 하면 보다 효율적이라고 생각된다.

• 고객 만족
  • 짧은 기간 그리고 계속 납품하는 것을 우선하여 고객을 만족 시킨다.
  • 개발의 어떤 단계에서도 변경을 환영한다.
  • 동작중의 소프트웨어를 빈번히 납품한다.
• 품질
  • 움직이는 소프트웨어야 말로 진보에서 가장 중요시된다.
  • 기술적으로 우수한 유연성과 확장성이 있는 설계가 되도록 주의한다.
  • 심플함이 요구되며 무의미한 양은 최대한 줄인다.
• 팀워크
  • 비즈니스쪽과 개발자는 매일 같이 일한다.
  • 의욕이 가득한 사람들로 프로젝트를 구성하여 신뢰할 수 있다.
  • 더욱 효과적인  Face to Face로 말한다.
• 프로젝트 관리
  • 지속 가능하도록 일정 페이스를  계속해서 가져가는 것
  • 최적의 아키텍처, 요구, 설계를 위해 자기 조직적인 팀을 만드는 것
  • 팀이 더욱 효율적이 되도록 정기적으로 되짚어보는 시간을 가지면서 더욱 최적의 방법을 찾아 조정해나가는 것

 

애자일 개발을 선택하는 이유

---

 워터폴은 필요 조건이 위에 있고 리소스와 시간이 아래로 삼각형으로 되어 있다. 예를 들어 아마존 EC사이트와 같은 것을 만들고 싶을 때 필요한 조건은 정해져 있으나 리소스와 시간이 정해지지 않아 끝이 애매해져 개발이 늦어지는 경우가 있다.
애자일은 리소스와 시간이 정해져 있으므로 아마존EC 사이트와 같은 것을 만들고 싶을 때, 모든 기능을 포함하지 않고, 고객와 상담하여 우선 순위가 높은 기능만을 구현한다. 불필요한 기능을 만들지 않으므로 고객 만족도를 달성할 수 있다.

워터폴과 애자일의 차이

워터폴	애자일
요구나 사양의 변경은 개발전	요구나 사양의 변경은 개발 기간중에도 괜찮음
전공정이 끝난 후에 서비스 제공	기능 구현 후에 서비스 제공 가능
거대한 문서가 필수	문서는 필요에 따라
E메일의 커뮤니케이션	대면을 선호
개발 공정에 따라 부정기적이고 긴 미팅	정기적으로 결장된 미팅에만 참가
상세한 상품 설명	데모로 보여줌
최종 단계까지 견적내기 쉬움	변경등을 수용하므로 견적내기 어려움

고객이 애자일을 선택하는 이유

• 유연성이 있다.
• 리소스와 시간을 낭비하지 않고 고품질의 제품을 개발 할 수 있다.

개발 팀이 애자일을 선택하는 이유

• 의사결정력이 높아진다.
• 자기계발이 높아진다.

관리자가 애자일을 선택하는 이유

• 고품질의 제품을 만들 수 있다.
• 시간과 비용대비 효과적이다.

간부가 애자일을 선택하는 이유

• 투자대비 이득이 높다.

 

 

애자일 개발의 프레임워크

---

 애자일 개발의 프레임 워크으로 자주 사용되는 것이 “스크럼”프레임 워크이다. 다른 것도 이것 저것 있지만, 따로 따로 쓰는 경우, 합쳐서 쓰는 경우도 있다.

 

스크럼

 스크럼에서는 1주에서 4주 사이클로 소프트웨어 만들면서 개발을 진행한다. 아래의 그름은 스크럼에 의한 개발의 흐름을 표시한 것이다. 스크럼의 각 용어가 의미하는 바는 다음과 같다.

• 프로덕트 백 로그 : 개발대상의 소프트웨어에 대한 요구의 백 로드
• 스프린트 : 1주에서 4주간의 사이클 반복
• 스프린트미팅 : 스크럼의 개발 목표(스프린트 목표)와 스프린트 백 로그를 설정하는 미팅
• 스프린트 백 로그 : 스프린트 목표 달성에 필요한 태스크 리스트
• 데일리 스크럼 : 매일 진행을 확인하는 미팅
• 실행 가능한 프로덕트의 인크리먼트 : 스크립트의 결과로서 작성된 실행 가능한 소프트웨어
• 스프린트 리뷰 : 고객에게 보여주거, 프로젝트 오너에게 보여주어 피드백을 받는자리
• 스프린트 로스팩티브 : 반성회(KPT)를 한다.

 

린(Lean)

 시간이나 리소스를 불필요하게 낭비하는 일이 없는 저스트인 타임 프로세스이다. ”필요한 것을 필요한 시간에 필요한 만큼” 공급한다. Lean은 스크럼과 비슷하고 동일한 것을 반복하는 제조 세계에 반해 스크럼은 항상 변화해가는 소프트웨어 세계를 생각하면 구분하기 쉽다.

 

Kanban

 시각화하여 무엇이 실행되고 있는지를 파악해서 도중에 생긴 태스크가 있어도 파악이 가능하다.
간판은 따로 사용하는 것보다 스크럼에 합쳐서 시각화하는 방법이다.

 

 

Extreme Programming

• 팀 전체 계획 : 모든 멤버가 계획에 참가
• 코딩 스탠다드 개발 : 코딩 표준으로 일관성을 유지한다.
• 페어 프로그래밍 : 두 명에서 작업한다.
• 코드의 리팩토링 : 설계를 빈번히 개선하여 효율을 개선한다.
• 심플한 디자인 : 심플한 디자인쪽이 비용대비 성과가 높다.
• 소규모 릴리즈 : 고객에게 빈번히 기능을 제공하여 피드백을 받는다.

스크럼 + XP

 이 프레임워크가 많은 기업에서 사용되고 있다. 스프린트에서 개발하고 있을 때, 페어 프로그래밍으로 개발하여 품질을 높인다. 스크럼과 XP는 다르지 않고 함께 합쳐서 사용하는 프레임워크이다.

 

스크럼 + Kanban

 이 프레임 워크도 동일하게 스크럼으로 개발하고 있을 대, 간판이 있으면 누가 어떤 태스크를 실시하고 있는지 파악하기 쉬우므로 한눈에 확인이 가능하다. Scrumban도 함께 사용하는 프레임 워크이다.

 

Hybrid

요건 정의와 시스템 테스트, 릴리즈만을 남기고, 개발을 애자일로 한다.

 

 

스크럼의 이상적인 개발 환경과 툴

---

물리적인 환경

• 함께 움직인다.
• 가능하다면 프로젝트 룸이나 포트를 준비
• 스페이스가 한정된 경우, 큐브에서 분단 패널을 삭제한다.
• 가동성, 와이어리스
• 사용 툴 : 화이트 보드, 게시판, 마커, 포스트잇
• 일에 방해되거나 산만한 것은 모조리 뺀다.

커뮤니케이션 방법

• Face to Face로 매일 스크럼 회의에 참가한다.
• 팀 멤버나 프로덕트 오너와 커뮤니케이션을 취하는 것을 목표로 아래의 내용을 명확히 한다.
  • 목표
  • 우선순위
  • 작업 완료
  • 완료할 필요가 있는 작업

 

커뮤니케이션 툴

• Zoom과 같은 비디오 회의 툴
• Slack과 같은 인스턴스 메시지
• 문서, 파일 공유(GoogleDrive)
• 정보 공유(Jira, Trello)

 

스프린트 고정의 kanban 보드, 화이트 보드, 및 프로젝트나 제품의 상세를 표시할 다른 어떠한 툴

 

스크럼의 역할

---

 역할은 아래와 같은 두 개의 팀으로 나눠져 있다.

 

프로젝트팀

애자일 멘토

멘토는 매일 필요하지 않고 맨 처음 애자일을 도입했을 때에만 필요하다

스택홀더(이해관계자)

자사 서비스의 경우는 사장 혹은 대표등이 된다.

외주 서비스의 경우 외주처의 고객이 스택홀더가 된다.

 

스크럼 팀

 스크럼 팀에는 3개의 역할이있다. 이역할은 매우 중요하며, 프로덕트 오너, 개발 팀, 스크럼 마스터라는 세 가지 역할이 있다. 이 세계를 모두 포함해 스크럼 팀이라고 부른다.

프로덕트 오너

 프로덕트 백 로그를 관리하고, 우선 순위를 정하는 프로적트의 책임자이다. 구체적으로는 비즈니스, 고객, 시장의 요건을 파악한 후, 그에 맞게 개발 팀이 할 작업 우선순위를 결정하는 것이 주된 일이다. 유능한 프로덕트 소유자는 아래와 같은 일을 한다.

• 프로덕트 백 로그 작성과 관리
• 작업 부문 및 팀과 밀접히 연계해 전원이 프로덕트 백 로드의 작업 항목을 이해하도록 한다.
• 다음은 전달할 기능에 관해서 명확히 가이드라인을 팀에 전달한다.
• 전달 빈도가 높아져 쉽게 프로덕트 릴리즈 시기를 결정한다.

프로덕트 오너의 워크 플로우 1. 감찰  비즈니스, 고객, 시장의 요건 파악하여 프로덕트, 백로그를 작성하여 우선 순위를 결정한다. 2. 참가   스프린트, 플래닝에서 개발 팀과 스트럼 마스터가 함께 미팅하여 기간과 스프린트, 백 로그를 결정한다. 3. 질문에 답한다.  스프린트가 시작해도 개발자의 각각 질문에 대답하낟. 4. 출석  매일하는 데일리 스크럼에도 출석하여 진행 사항을 확인하고 질문에 대답한다. 5. 기능을 리뷰  스프린트가 끝났을때에 기대한 기능인지를 리뷰한다. 6. 참가/리뷰  자신이 소속된 팀의 스프린트 리뷰뿐만이 아니라 다른 팀의 스프린트 리뷰에도 참가하여 자신의 팀에 대해서 영향이 있는지를 확인하고 리뷰를한다. 7. 참가  스프린트 로스팩티브(반성회)에도 참가혀 KPT를 확인한다. 8. 기타 제품 비전을 위해 고객과 회의하는 등 다음의 백 로그를 검토한다. 프로젝트(기간과 희망)에 따라 프로덕트 오너가 여러 개의 스크럼 팀을 담당하는 경우도 있다. 커다란 프로덕트에서는 여러 명의 프로덕트 오너가 있으며 각각 프로덕트 공유회를 한다.

개발 팀

 프로덕트 백로그를 스프린트내에 실현하는 책임을 가지고 있다. 더욱 효과적인 스프린트 팀이란 밀접하며, 동일한 장소에 있어 항상 4~6인의 멤버로 구성되어 있다.

 팀 멤버는 다양한 스킬(엔지니어, 디자이너, 프로그래머, QA등)을 가지고 있다. 스크럼 팀은 각 스프린트의 계획을 진행한다.

 팀은 과거의 속도를 참고하여 그 인테그레이션에서 완료할 수 있는 작업량을 예측한다. 인테그레이을 길게 고정하여 개발 팀은 견저과 딜리버리 프로세스에 관해서 중요한 피드백을 얻을 수 있다. 그 결과 예측 정밀도가 더욱 높아지게 된다.

개발 팀의 워크 플로우 개발 팀의 스킬  T자형 스킬이 좋다고 알려져 있다. 하나의 스킬에 대해서 확실히 축(기능 분야, 전문 분야)가 있으며 폭 넓게 지식이 있는 인재이므로, 핵심 영역 외에도 일하는 것이 어느정도 가능하다. 예를 들어 프로그래머이지만 디자인이 되거나, 테스트까지 맡길 수 있는 것 과 같이 말이다. 개발 팀의 구성 Face to Face의 대면 커뮤니케이션 커뮤티케이션이 이상적이며, 전화 회의 시스템이다 적달힘 팀 규모 너무 적지나 너무 크지도 않은 효율적인 규모 보다 큰 개발 팀이 필요한 경우는 여러 개의 스크럼 팀을 만든다.

•  

스크럼 마스터

 스크럼 팀이 건전하게 스크럼을 실시할 수 있다는 점, 스크럼이 적합하지 않은 일 개발에 있어 스크럼 이외의 방법을 제안하는 책임을 가지고 있다.

 유능한 스트럼 마스터는 팀이 실행하고 있는 작업을 깊이 이해하고 있으며, 팀이 투명성과 딜리버리 플로우를 최적화하도록 지원할 수 있다. 스크럼 마스터는 주임 퍼실리레이터로서 스프린트 계획, 스탠드 업, 스프린트 리뷰, 스프린트의 반성에 있어서 필요한 자원(요원과 물류 양쪽으로)의 스케줄을 결정한다.

 

가치와 개념

1. 존경

• 팀 전체가 모든 성과와 실패에 대해서 책임을 가진다.
• 모든 팀 멤버에는 의사결정에 관련된 권리가 있다

2. 오픈 마인드

• 다른 사람의 의견을 수용한다.
• 전원이 관여하여 공통 정보에 액세스 할 수 있는 것을 확인한다

3. commitment

• 모든 멤버는 스프린트 목표만을 집중할 수 있도록 할 필요가 있다.
• 팀 전체로 스프린트 목표를 달성할 책임이 있다.

 

 

애자일 개발의 메리트와 디메리트

---

메리트

• 문서 작성을 최소한으로 할 수 있다.
  • 대면 커뮤니케이션을 통한 의사소통과 실제 움직이는 소프트웨어를 진행 관리 척도로 삼음으로써 작성되는 문서량을 줄일 수 있다.
• 기존 개발 방법과 비교하여 납기를 단축할 수 있다.
  • 상세한 사양이나 진행 관리 등의 상류 공정, 문서 작성의 수고가 줄어 든다.
• 재작업하는 양이 적어진다
  • 개발 대상을 최소화하고 있어 오류 발생에 따른 재작업이 줄어든다
• 고객 만족을 얻기 쉽다.
  • 사양 변경 및 기능 추가에 유연하게 대응할 수 있어 개발 도중에도 고객의 요구를 수용하기 쉬워진다.

 

디메리트

• 프로젝트의 방향성이 틀리기 쉽다.
  • 상세한 사양을 결정하지 않고 착수하므로, 고객의 니즈에 맞는 개선을 반복, 추가/변경하는 것이 메인으로 맨 처음 계획했던 것과 대폭 바뀌는 경우가 있다.
• 납기일의 연장이 발생하기 쉽다.
  • 팀 단위로 “개발 ~ 릴리즈”의 공정을 반복하므로 전체의 스케줄이나 진행 사항을 파악하기 어려우므로 납기 기간에 맞추지 못하는 경우가 있다.

 

 

애자일 개발에서 실패하지 않도록 하는 방법 네 가지

---

• 애자일 개발이 조직에 적합한지 확인한다.
  • 애자일 개발에 있어서 목적이 흐지부지 되어 버리면 나중에 문제가 발생한다. 요건이 조직(유저)를 위한 것인지, 비용대비 효과를 기대할 수 있는지 등을 확실히 할 필요가 있다.
• 애자일 개발 도입을 너무 서두르지 않는다.
  • 애자일 개발은 개발 도중 사양 변경에도 유연하게 대응할 수 있는 것이 큰 장점이다. 그러나 요청을 너무 많이 받아 들여 매번 변경이 일어난다면 개발팀의 부담이 상당히 커진다. 따라서 애자일 개발에 있어 요건 도입을 너무 서두리지 않는 것이 중요하다.
• 개발전에 단단히 계획을 짜둔다.
  • 애자일 개발은 세부 사항을 정하지 않고도 유연하게 개발을 진행할 수 있다. 그러나 새악 나는 대로 개발을 진행하더라도 결과적으로 그것이 조기에 적합한지 여부를 제대로 조사할 필요가 있다. 그렇기 때문에 기획만큼은 확실히 채워두는 것이 중요하다.
• 의사소통을 위한 문서를 만든다.
  • 개발에 있어서 협의 내용을 확실히 문서화 해 둘 필요가 있다. 이것은 어떤 문제가 생겼을 때 “말하지 않겠다”는 일이 일어나지 않도록 하기 위해서 이다. 유저와의 커뮤니케이션을 확실히 하고, 의사소통을 하는 것은 애자일 개발에 있어서 필수 불가결이다.  

---

참고자료
https://qiita.com/kyawphyonaing/items/8cd30ac818da2c7ce0e0