애자일(Agile)이란?

애자일의 등장 배경

초기 소프트웨어의 개발 방법은 계획 중심의 프로세스(SW 개발의 역사)

* 초기에 SW를 주로 개발했던 분야는 '군사'쪽의 대형 프로젝트이다.

* 즉, 계획 중심의 프로세스로 SW 개발이 진행됬다.

- 이 계획 중심의 프로세스는 '건축(도시 계획)' 에서의 방법을 본딴 것이다.

* 당시에는 이런 프로세스를 하는 것이 적합해보이는 프로젝트가 대부분이었다.

하지만, 지금은 달라졌다. 높아진 SW 개발의 불확실성

* 90년대를 지나면서 SW분야가 젋어지고 SW의 사용자(end user)들이 '일반 대중을'로 바뀌기 시작했다.

* 또한 비지니스 싸이클이 짧아지면서 사람들의 욕구와 트렌드도 빨리 바뀌게 되었다.

- 비지니스 싸이클 : 제품이 나오고 , 사용하고, 또 다른 제품으로 넘어가서 사용하고, 또 새로운 제품이 나오는 식의 싸이클, 

예를 들어 사용하는 핸드폰의 수명이 1~2년 정도로 바뀐것.

* 이러한 변화에 따라 SW 개발의 불확실성이 높아졌다.

새로운 SW 개발 방법의 등장

* SW 개발의 불확실성이 높아짐에 따라 예전의 전통적인 개발 방법이 맞지 않다는 것을 느낀 사람들은 각자 자신만의 SW 개발 방법을 만들어서 사용하고 있었다.

- 왜 전통적인 개발방법이 맞지 않다는것을 느꼇나? : 

-- 창의성이나 혁신을 계획하는 것이 이상하다고 생각했다.

-- 예를들어, 보수적인 회사에서 자기들이 생각하기에 미리 계획한 혁신적인 일이 다른 사람들이 보기에는 뻔히 예상하는, 그냥 그 회사같은 것을 해놨네. 라고 생각이 든다. 왜나하면 혁신은 계획에서 나오는 것이 아니기 때문이다.

* 즉, '경량 방법론 주의자(lightweight methodologies) 들은 해보면서 고쳐나가는 방식의 방법론을 사용하게 되었다.

- 규칙이 적고 가볍게 대응을 잘하는 방법

* 그렇다면 이 방법은 주먹구구식과 뭐가 다른가? : 

- 밑에서 더 자세히 설명하겠지만, 이 방법을 아주 잘하는 단계에 이르면 겉에서 보기엔 미리 큰 그림을 만들어 놓고 하는것처럼 보인다.

- 예를 들어, 즉흥연기를 잘하는 단계에 이르면 겉에서 보기엔 대본대로 하는 것이 아니냐는 생각을 한다.

새로운 SW 개발 방법의 선언

* 2001년도에 경량 방법론 주의자 17명이 만났다.

- 17명 각각이 방법론을 만들어 쓰고 있었다.

- 각가이 방법론에서 서로 간에 추구하는 관점의 공통점을 추려서 '애자인 SW 개발 선언문'을 만들었다.

- http://agilemanifesto.org/

- 이 사람들의 뿌리는 스몰토크(Smalltalk)라는 객체지향 프로그래밍 언어라는 프로그래밍 언어의 문화에서 나왔다.

(c언어의 문화와는 다르다.)

-- 스몰토크란? : 동적 형, 반영을 지원하는 객체 지향 프로그래밍 언어

- 이때부터 애자일이라는 용어에 의미가 생겼다.

애자일 프로세스 모델의 이해

애자일의 사전적 의미는 '날렵한', '민첩한'으로, 애자일 프로세스 모델은 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론을 말한다.

폭포수 모델처럼 계획을 기반으로 하는 프로세스 중심의 전통적인 모델은 산출을 위주의 거대하고 무거운 방법론에 해당한다. 이러한 방법론은 요구사항의 변화에 유연하게 대처하기 어렵다는 큰 문제점이 있다. 따라서 가볍고 비교적 변화를 수용하기 쉬운 방법론이 필요하게 됐는데 이것이 익스트림 프로그래밍(XP : eXtreme Programming), 스크럼(scrum), 크리스털(crystal)과 같은 방법론들이다.

애자일은 가벼운 프로세스 방법론의 공통적인 특성을 정의하는 말이다.

* 이 선언문의 나열식 내용을 느낌대로 나름의 정리를 하자면, '협력'과 '피드백'이라는 두 단어로 정리를 할 수 있다.

* 즉, 한 마디로 '협력과 피드백을 자주. 일찍. 더 잘하는것.' 이다.

* 비지니스 담당자(현업)와 개발자의 상시 협업

* 개발 도중 주기적인 중간 산출물(프로토타입 등)을 통한 의사소통

* 고객 피드백 기반의 더 많은 릴리즈

* 요구사항 변경에 대한 유연한 대처

애자일의 핵심(협력과 피드백)

1. 애자일의 핵심 - 협력

SW 프로젝트가 망하는 경우는 기술 외적인 것도 크다. 따라서 특히 SW개발의 불확실성이 높을때는 '협력'을 잘 해야 한다.

1-1. 내부적 협력

* 내부적 협력 : SW 개발에 참여하는 사람들의 협력을 말한다. 특히, 직무 혁할을 넘어선 협력을 의미한다.

* 좋은 일은 곱하기

- 혼자 얻은 좋은 통찰을 협력을 통해 다른 사람도 같이 얻을 수 있다.

- 예상하지 못했던 기회를 잡을 수 있다.

- 예를 들어, 어떤 사람이 개발을 하다가 2개의 속도로 개발 할 수 있다는 것을 발견했다.

협력이 약한 문화에서는 그 사람만 좋은 보상과 칭찬을 받게 되고, 그 사람 코드가 다른 사람들의 코드와 너무 이질적이어서 시스템에 문제가 발생할 수도 있다. 하지만 협력이 강한 문화에서는 그것을 다른 사람들과 공유하여 모두 같이 빠르게 개발 할 수 있고 더 나은 발전점을 찾을 수 있다. 즉, 팀 전체의 개선이 일어난다.

1-2. 외부적 협력 : 추가작성 계획

2. 애자일의 핵심 - 피드백

* 피드백은 학습의 가장 큰 전제조건이다. 내가 어떻게 했는가를 확인하면서 학습해야 한다.

* 또한 SW 개발의 불확실성이 높을수록 학습이 중요해진다. 왜냐하면 모르는 것이 많기 때문에 더 빨리 배워나가야하기 때문이다.

* 일을 잘하는 사람은 feedback seeking이 뛰어나다. 즉, 이런 사람들은 더 자주 더 많은 사람들에게 피드백을 구한다.

2-1. 내부적 피드백

내가 만든 것이 어떻게 됐는지 확인해보는 것

2-2. 외부적 피드백 

내가 만든 것을 고객이나 다른 부서가 사용해보고 그것을 통해 또 다른 것을 배우는 것

SW 개발의 불확실성과 사업적 가치가 있는 프로젝트

SW 개발의 불확실성

* 애자일에서는 불확실성이 중요하다.

* 불확실성이 높을 때 일을 하면 '우리가 생각하던 것과는 다르네.'라는 상황이 오게 된다. 이때,

- 전통적인 방법론을 사용했을 때는 '그때 계획을 세울 때 더 잘 세울걸. 그때 이런 리스크까지 생각해놨어야 했는데.'라고 생각하면서도 계획대로 그냥 진행한다.

- 애자일 방법론을 사용했을 때는 '생각대로 안됐네. 계획이 틀어질 수 밖에 없는게 정상이지. 그럼 빨리 수정하자.'라고 생각하면서 계획을 변경한다.

* 비지니스 가치(사업적 가치)가 클수록 불확실성도 커진다.

사업적 가치가 있는 프로젝트란?

* 이미 충분한 지식을 가지고 있고 가지고 있는 지식을 활용한 프로젝트의 경우는 대부분 사업적 가치가 떨어진다.

* 레드오션(Read Ocean)에 뛰어들면 그만큼 경쟁자가 많고 경쟁이 치열해진다.

- 레드오션 : 이미 잘 알려져 잇는 시장, 즉 현재 존재하는 모든 산업

* 그렇다면 사업적 가치가 있는 경우는 어떤 경우일까?

- 우리도 잘 모르는 부분이 있는 것을 하는 것, 즉 학습을 하면서 할 수 있는 것이 사업적으로 가치가 크다.

- 예를 들어, 카카오뱅크도 이미 다 아는 것을 가지고 하지 않았을 것이다. 분명히 새로운 시도를 했고 이 때문에 가치가 있는 것이다.

- 따라서 사업적으로 가치가 있기 위해서는 배우면서 해야한다.(학습)

학습이란?

* 우리가 생각하는 학습은 너무 정형화되어 있다.

* 책을 읽는다 = 학습한다?

* 학습에 있어서 독서는 몇 퍼센트를 차지할까를 생각해보자.

* 학습은 실험, 질문, 검색 등이 모두 포함된다.

References

애자일 키워드 - 김창준, 강재영 진행

http://agilemanifesto.org/

http://www.agilesherpas.com/what-is-agile-marketing/

https://triad-city-beat.com/the-weekender-4/

https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html