Codeit_프로세스 관리

---

프로세스 관리

---

개발자의 코드가 실제로 출시되기까지는 여러 단계를 거치게 된다.

(기획 → 개발 → 테스트 → 배포 → 유지/보수)

하나의 소프트웨어를 출시하기까지 다양한 사람들이 함께 일하게 된다.

 

여러 사람이 모여서 일을 하다 보니 의사소통에 문제가 생길 때도 있다.

그래서 사람들은 어떻게 일하는 게 가장 좋을지 고민을 하게 된다.

 

이런 협업 방식으로 가장 유명한 건

폭포수(Waterfall) 방식과 애자일(Agile) 방식이다.

 

폭포수(Waterfall) 방식

예전부터 사용되는 고전적인 방식이다.

각 단계를 완료하고 다음 단계로 넘어가는 것이다.

그래서 이해하기도 쉽고 관리하기도 쉽다.

 

코드잇_강의이미지_폭포수방식

 

어떻게 보면 굉장히 단순하고 직관적이다.

이 방식이 갖는 문제점은 만들고자 하는 게 복잡해질 경우 각 단계를 한 번에 완벽히 끝내기가 힘들 수 있다는 것이다.

예를 들어 기획에서 아무리 상세하게 문서에 모든 걸 기록해 준다고 해도

프로그램이 너무 복잡하면 의도한 대로 완벽히 전달되지 않을 수 있다는 것이다.

사실 프로그래밍은 하나씩 기틀을 만들고 쌓아가는 작업이다 보니

완성된 후에 결과물을 바꾸려면 실제 코드의 많은 부분을 갈아 엎어야 하는 상황도 충분히 올 수 있다.

 

애자일(Agile) 방식 

폭포수 방식의 문제를 해결하기 위해 애자일 이라는 방식이 시작되었다.

애자일(Agile)은 재빠른, 민첩한 이런 의미를 갖고 있는 단어 인데

잘못된 방향으로 너무 멀리 가긴 전에 재빨리 결과물을 만들어서 미리미리 확인하는 과정을 갖고

고칠 건 고치면서 진행하자는 것이다.

 

전체 프로그램을 한 방에 만들어버리는 대신

프로그램을 적당한 크기의 기능으로 나누고 

각 기능에 대해 문서가 아닌 실제 동작하는 소프트웨어로 확인하면서 서로 소통하는 것이다.

이렇게 했을 때 잘못된 방향으로 멀리 가버릴 일도 없고

기획자들도 자신이 상상한 것과 비슷한지 직접 써보면서 의견을 덧붙일 수 있다.

 

폭포수 방식이었을 때는 이미 개발이 완료된 이후에 여러 수정 사항, 변경 사항들이 생기면 개발자들은 다시 전체 코드를 뒤엎어야 하는 경우도 있었는데

애자일에서는 개발이 완료된 후에 발생할 수 있는 요청사항을 최대한 빨리 받아들여서 유연하게 대처 할 수 있다.

 

서비스든, 제품이든 복잡해지고 변화 주기도 짧아진 요즘

기능 변경에 유연한 애자일이 더 효율적이고 적합한 협업 방식인 경우가 많다.

그래서 최근에는 폭포수 방식보다 애자일 방식을 더 많이 선택해서 사용하고 있다.

애자일 방식은 팀 전체가 쉽게 도입할 수 있게 Scrum 이나 Kanban 같은 구체적인 실행 방법들도 생겨나고 있다.

 

코드잇_강의미이지_애자일과 폭포수 방식의 차이점

 

그러나 무조건 폭포수 방식 보다 애자일 방식이 더 좋다고 할 수 없다.

팀 구성원이나, 만들고자 하는 제품의 성격, 팀 문화 등에 따라 폭포수 방식이 더 어울릴 수도 있다.

폭포수 방식은 해당 프로세스의 날짜만 관리하면 되기 때문에 프로그램의 기획이나, 개발 등 각 단계가 그리 복잡하지 않다면

폭포수 방식도 좋은 선택일 수 있다.

 

애자일 방식은 동작하는 프로그램을 만들어서 소통하고 또 추가로 개발하고 이런 식으로 진행하다 보니 폭포수 방식보다 관리하기가 복잡해진다.

애자일 방식에서는 각 기능을 적당한 크기로 나눴고 각 기능에서도 만들고, 소통하고, 다시 만들고, 소통하고 여러단계를 거치면서 진행한다. 그래서 프로젝트가 복잡해 진다.

 

또한 이 둘을 상황에 맞게 섞어 쓰거나, 변형해서 쓰기도 한다.

 

코드잇_강의이미지