본문 바로가기

PM의 일

애자일과 워터폴

애자일과 워터폴의 차이는 무엇인가?

 

 애자일과 워터폴 수업을 들으며, 이해가 되었던 부분을 위주로 질문을 던지고 답하면서 정리해 보았다. 결과 애자일과 워터폴이 일하는 과정에서 직면하는 문제와 일하는 방법이 드라마틱한 차이를 보이지는 않을 같다고 생각했다(프로덕트 자체가 너무 불확실하다는 점에서 그러하기도 하고, 애자일과 워터폴이 짬뽕되서 그럴 수도 있고..).

 

  다만, 구성원들끼리 문제에 어떻게 반응하고 해결할 지를 고민하는 철학과 문화가 다르다는 생각이 들었다. 가령, 개발자와 디자이너가 프로덕트를 어느 수준으로 이해하고 있고, 따라서 어디까지를 자신의 역할로 생각하는 , 실수와 실패를 어떻게 받아들이는 등등이 애자일과 워터폴의 차이라고 생각한다. 실제로 애자일 선언을 보면 개인과 상호작용”, “작동하는 소프트웨어”, “고객과 협력”, “변화에 대응 핵심 문구이다.

 

 

 

 

 

아래는 혼자 질문에 답해본 내용이다.

 

1.     기획은 어차피 번복되는 아닌가? 워터폴을 linear, 애자일을 circular 하다고 잘라 말할 있는 건가? 

 

  1) 워터폴 방식을 따른다고 하더라도, 계획은 자체로 계획이니까 완벽할 수는 없다. 하다 보면 빵꾸가 보이기 마련이다. 그래서 워터폴 방식으로 일할 때도 개발 단계까지 가서 기획을 번복하고, 추가 요청을 때가 있을 것이다. 다만 차이는 뒤늦게 빠진 부분을 발견했을 , 얼마나 얼마나 쉽게 뒤에 단계로 돌아갈 있느냐인 같다. ( 물론 워터폴은 사전에 정의된 과제, 혹은 scope 자체는 변경하지 못하는 같다. )

  2) 워터폴에서는 실수가 생겨도, 이미 개발된 기능이 무거워서 기술적으로 돌아 가지 못하는 문제가 있을 같다. 하지만 그보다는 개발자와 디자이너에게 부탁하는 것이 두려울 같기도 하다.  

  3) 반면 애자일은 기획 번복이 생기더라도 기능이 가벼우니 쉽게 고칠 있고(아닌가..), 디자이너와 개발자도 같이 기획에 임했기 때문에 함께 헤쳐나간다는 생각이 있지 않을까? 그런 점에서 애자일 조직은 MVP 프로덕트 자체에 대한 실패를 용인하는 문화도 있겠지만, 서로의 실수도 봐주고 보완해주는 학습 문화가 조성되어 있을 같다.

 

2.     애자일이 빠를까?

 

 1) 사실 수직적 의사결정이 빠를 때도 많다. 예를 들어 워터폴 방식에서는 기획자가 디자이너에게 배너 사이즈까지 정해주고, 개발자에게 넘긴다고 하면 이게 빠를 수도 있다.

 2) 하지만, 워터폴의 경우 일단 기획자가 혼자서 머리를 싸매고 기획을 하다 보니 기획자 눈에는 보이지 않는 곳이 생기기 쉬울 같다.

 3) 반면에, 디자이너와 개발자와 소통하며 기획할 때는 사람들의 눈으로 빠진 곳을 쉽게 발견해서 미리 실수를 방지할 있을 같다.  

 4) 그런 점에서 역할에 구애받지 않고 각자 의견을 적극적으로 개진할 좋은 의견이 나올 수도 있고, 실수도 미리 방지하고, 그러면 길게 봤을  빨리 좋은 프로덕트에 도달할 있을 같다.

 

3.     애자일이 개발자 중심 방법론이라는걸까?

 

 1) 실제로 애자일을 검색하면 agile software development 나온다. 실제로 애자일 선언도 개발자들이 했다.

 2) 워터폴에서 완전히 잘못된 설계가 내려왔고, 구현해야 한다는 이야기를 들었을 , 워터폴에서 가장 고통받는 사람이 개발자였을 같다. 물론 워터폴에서도 기획 단계에서 개발자와 의논 한다고는 하지만, 앞에서도 말했듯이 커뮤니케이션 수준이 다를 같다.    

 3) , 최소 기능 중심으로 빠르게 시제품을 낸다는 점에서 개발자 중심 방법론이라는 말이 나온 것이 아닐까 추측해 본다.

 

(하지만 프로덕트는 기능의 집합이 아니라고 했는데, MVP 단계에선 아직 프로덕트가 기능의 집합인 걸까? MVP가 꼭 퀄리티가 낮다는 말이 아니라고 했는데, 이건 무슨 말일까? 그게 가능한 건가?) 

 

 

출처:

https://brunch.co.kr/@hrbulletin/5

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

http://blog.rightbrain.co.kr/?p=5832

'PM의 일' 카테고리의 다른 글

개발 지식  (0) 2020.10.20
지난 6주 돌아보기  (0) 2020.10.19
Product Market fit  (0) 2020.09.18
W2 전략과 고객  (0) 2020.09.15
나는 왜 PM이 되고 싶을까  (0) 2020.09.07