어디까지나 개인의 경험에 의한 일반화이므로, 모든 외국계 회사가 이렇지는 않다는 점 이해 부탁드립니다.
강산이 바뀌었다
10년 전과 지금의 직장 풍경은 많이 다르다.
일하는 방법론과, 일하는 동료의 마음가짐이 과거와 비교할때 한참 다르며, 코로나로 더욱 가속되었다.
나 어디? 넌 누구? 강산은 한번 바꼈다.
오늘은 IT프로젝트 방법론과 전체 사이클에 대해 이야기해볼까 한다.
실무적으로도 가장 핫한 프로젝트 방식은 "애자일 프로젝트 방법론" 으로,
과거부터 전통적인 "위터풀 프로젝트 방법론" 과 함께 많이들 사용한다.
위터폴 프로젝트 관리
프로젝트 마감기한과 큰 범위가 정해져있고, 리소스를 최대한 투입하여 기간 내 마무리 한다.
분석 설계가 완료되면 비지니스 팀에게 Sign-off를 받고 이후 변경이 불가능하거나 아주 최소화한다.
구현할 기능에 포커스를 두고 일 덩어리를 만든다.
프로젝트 사이클 기간이 길어 장거리 질주가 많고, 기한에 맞춰 완료할 인력 관리가 필요하다.
보통 분석 - 설계 - 개발 - 이행 - 유지보수 같은 단계를 가지고 프로젝트 매니져 또는 프로젝트 리더라는 포지션이 존재한다.
개발 요구사항이 프로젝트 초반 확정되므로, 개발 목표의 변경을 자주 하지 않고 프로젝트 실행이 비교적 수월하다.
프로젝트 전체 과정에 대한 예산과 인력자원이 초기 확정되므로, 결과와 리스크 관리가 휠씬 용이하다.
개발이 순차적으로 진행되므로 선행 관계가 중요하며, 앞 단계가 완료되야 후행 단계가 진행가능하므로 개발 속도 및 유연성이 떨어지는 편이다.
위터폴은 말그대로 목표설정 후, '폭포수' 처럼 내리꽂는 방식이다.
애자일 프로젝트 관리
SPRINT (스프린트) 라고 하는 짧은 업무 사이클를 가지고, 단거리 질주로 제품을 완성한다. 보통 1-2주 단위로 스프린트 사이클을 돌린다.
각 스프린트마다 처리량과 속도를 체크하여, 현재 프로젝트 팀으로 얼마만큼의 업무를 소화할 수 있는지 측정한다.
스프린트가 짧기 때문에, 제품 품질에 초점을 맞추고 결함을 위터폴보다 빠르게 발견할 수 있다.
여러 작은 단위의 팀들이 각자의 작업을 할당받고 처리한다.
마감기한을 대부분 설정하지 않고, 측정된 처리 속도를 기반으로 '현재 속도 기준으로 1달 뒤에는 완성 가능하다' 예측을 하고 마감 기한을 맞춰 팀이 야근하도록 강요하지 않는다.
Project manager(프로젝트 매니저)가 존재하지 않고, Product Owner(프로덕트 오너)가 존재한다.
애자일의 기본 단위는 STORY(스토리)로 작은 스토리가 뭉쳐 EPIC(에픽)을 이룬다. 또한 스토리를 쪼개어 세부 작업으로 나눌 때 TASK(태스크)를 사용한다. TASK를 더 나누고 싶으면 SUB TASK(서브 태스크) 이용도 가능하다. 예를 들어 '주방 업무' 를 테마로 설정하면
EPIC : 주방 담당자는 편리한 설거지를 할 수 있다
STORY : 주방 담당자는 새로운 식기 세척기를 이용하여 편리하게 설거지를 할 수 있다.
TASK 1 : 식기 세척기 조사/제품 결정
SUB TASK 1 : LG 식기세척기 탑3 조사 (누가 : 엄마)
SUB TASK 2 : 삼성 식기세척기 탑3 조사 (누가 : 아빠)
TASK 2: 식기 세척기 구매/설치
이런 느낌으로 말이다.
결과만 보면, 위터폴이든 애자일이든 '식기 세척기를 구매하여 설거지를 편하게 한다' 로 귀결되는거 아닌가? 싶지만 그 과정이 상당히 다르며, 실제 결과 또한 다를 수 있다.
보통 미팅은 스프린트 단위로 Sprint Planning, Daily stand-up, Sprint Review 미팅이 존재하며,매일 매일 미팅을 한다고 해도 과언이 아닐만큼 팀원의 daily 처리업무량을 신경 쓰고 관리한다.
Sprint Planning : 아직 할당되지 않은 작업업무를 살펴보고 (BACKLOG라고 하는 리스트에 쌓여있다), 어느 스프린트에 할당할지 계획한다. 예를 들어, 현재 팀 처리속도로 볼때 3개 까지 처리가 가능하다면 SPRINT 1에 3개를 할당하고, 다음 SPRINT 2에 나머지 작업을 할당하는 식으로 말이다.
Stand-Up : 스프린트에 설정된 작업들 처리에 문제는 없는지, 어느정도 상태가 진행되고 있는지, 처리속도에 영향을 주는 이슈는 없는지를 팀원들과 짧게 공유한다. 15분 정도.
Sprint Review : 끝난 스프린트에 대해 리뷰를 하고, 계획에 맞게 잘 처리했다면 축하를, 계획가 다른 느린 처리속도를 보였다면 개선해야될 점은 어떤게 있는지를 팀원들과 의견 공유 및 방법을 찾는다. 이 미팅은 누군가를 혼내기 위함이 아니라, 팀으로서 같이 어떻게 하면 빠르게 일을 처리할 수 있고 서로에게 모두 좋게 개선할 수 있는지를 이야기하는 자리이다.
이 사이클을 반복적으로 해나가는 것을 SCRUM(스크럼)이라 한다.
스크럼 = 애자일로 생각하기도 하는데, 엄밀하게 말하면 스크럼 < 애자일로, 스크럼은 애자일을 대표하는 도구중 하나이다. 외국어를 생각하면 '영어'가 바로 머리속에 떠오르는 것 처럼, 영어는 실제 모든 외국어를 커버하지 않지만 가장 강력한 언어중 하나이듯, 스크럼도 애자일 프로젝트 방법론 중 가장 강력한 도구 중 하나인것이다.
스크럼 외 다른 도구인 칸반, 하이브리드 형식이 있다.
칸반
소프트웨어 개발 도구 중 하나로, 애자일을 대표하는 방식 중 하나이다.
칸반은 일본어로는 우리가 아는 '간판'이며, 간판에 주렁주렁 모든 것들을 걸고 전시하는 거라고 생각하면 된다.
칸반 보드에 프로젝트에서 관리하는 모든 이슈를 로깅하고, 진행 과정을 한눈에 파악하여 한쪽으로 지나친 업무 쏠림을 방지하고 발란스를 가지려고 한다.
개발자들에게 과도한 부하를 주지 않기 위해 만든 거라 보면 된다.
상태는 보통 TO-DO, IN progress, Done으로 나눠지고 각 팀원들이 각자 할 태스크를 가져가고 진행 상태에 맞춰 상태를 쉽게 바꿀 수 있다.
가장 대표적인 툴 중 하나인 JIRA - KABAN BOARD
스크럼 방식의 역할 (ROLE)
Product owner (PO) : 제품의 오너쉽을 가지는 사람으로, 현재 개발중인 제품에 대한 중요 결정 및 그 방향에 대해 기획을 하고 고민하는 사람이다. 보통 비지니스 팀이 맡는다.
Scrum Master (SM) : 팀원들의 귀를 기울이고, 스크럼이 잘 동작하고 있는지 계속적으로 모니터링 하고 팀원을 교육시킨다. 스크럼에 대한 문제나 이슈가 생겼을 때 해결을 하는 주체 또한 SM이다. 보통 IT팀이 맡는다.
Team member : 스크럼에 설정된 태스크를 하는 멤버들. 비지니스와 IT팀이 통합된 멤버
애자일 방법론은 역할의 상/하가 존재하지 않고, 모두 각자의 역할을 맡아 하면 된다.
그러면 현실 세계의 프로젝트 관리는 어떻게 이뤄지고 있을까?
위에 이야기한 저런 이상적인 방식으로 되고 있을까????????????????????????????????????????????
댓글