[독서]애자일 & 스크럼 프로젝트 관리

저자 : 이재왕, 출판사 : 길벗

"애자일 & 스크럼 프로젝트 관리"를 읽고

 최근 진행 중인 프로젝트에서 애자일 모델을 처음 사용해보기로 했다. 전통적인 폭포수, 프로토타입 모델 방식의 프로젝트 진행만 해오다가 새로운 방법론을 통한 프로젝트를 참여하게 되어 낯설었다. 하지만 이미 해외에서는 많은 글로벌 기업들이 프로젝트 진행 또는 유지보수성 프로젝트에서 애자일을 사용하고 있으며, 한국의 대기업들도 추세에 따라 전통적 폭포수 방식의 프로젝트 관리에서 애자일 방식으로 변화하는 중이다. 단, 급작스런 변화는 개발자, 관리자로 하여금 혼란을 줄 수 있기 때문에 바텀업 방식으로 점진적으로 수용하고 있다고한다. 그렇다면 이렇게 애자일이 각광 받는 이유는 무엇일까?

 애자일에 앞서 SI프로젝트와 현재의 실태에 대해서 아래와 같이 정리 해보았다.

1. 장기적인 야근 : 2018-07-01부로 많은 기업들이 주 근무시간 52시간 때문에 예전보다는 야근이 많이 줄어 든것 같긴하다... 장기적인 야근은 개발자를 피폐하게 하며, 의욕을 감소 시키고, 프로젝트의 완성보다 프로젝트가 언제 끝날까 하고 마냥 끝나기만 기다리게 만든다. 야근은 IT업계에서 꼬리표처럼 붙어 다닌다. (다른 업계도 상당수 그렇다고 생각하지만...) 하지만 일주일에 한두번이 아닌 장기화 된다면, 개인 뿐만 아니라 팀 전체에도 악영향을 끼치게 된다.
2. 제조업과 소프트웨어산업 : 제조업은 보통 반복되는 공정처리가 많다. (제조업에 종사해보지 않아서 자세힌 모르겠다...) 소프트웨어산업은 창의 활동을 전제로 하는 지식노동이다. 하지만 한국의 SI산업은 제조업과 같이 흘러간다. 제조업의 원가절감을 소프트웨어 산업에서도 실행하려고한다. 소프트웨어 산업은 기술이 빠르게 변하고, 유지보다는 혁신에 가치를 두어야 하기 때문에 제조업과 같게 생각하고 접근하는 방식은 잘못 되었다.
   
3. 프로젝트 Risk : 대한민국의 IT산업에서 개발 프로젝트는 대부분 SI 성격을 띈다. 즉, 고객과 발주자, 개발자가 존재하고 그들간 커뮤니케이션을 통해 프로젝트를 진행하게 된다. 커뮤니케이션이 원활히 되지 못하면 프로젝트는 Risk를 가지게 되고, Risk가 커진다면 프로젝트가 실패 할 수도 있다. 플젝의 가장 큰 risk는 요구사항의 불확실이며 이는 일정관리 실패, 프로젝트 실패로 이어질 수 있다.
4. 관리자의 명령 통제방식 : 전통적인 폭포수 모델은 관리자의 명령통제 방식으로 팀원간 소통을 감소 시킨다. SI에선 대부분 폭포수 모델을 기용하고 있으며, 발주사 > 관리자 > 개발자 형식의 갑읍병 관계는 커뮤니케이션에 불리함이 있다.
5. 과잉 생산 : 제조업에서 시장의 추세를 모르고 과잉 생산을 하게되면 회사에 손해를 끼치게 될것이다. 소프트웨어산업도 똑같다. 무조건 기능을 많이 넣고 결과물을 내려고 하면 과잉 생산이 되는 것이며, 불필요한 작업을 하게 되는 것일 수도 있다.
6. 금을 도금하다 : 말 그대로 불필요한 작업이다. 예를 들면 웹 페이지 화면에서 불필요하며 개인에 따라 틀릴 수 있는 기호차이에 입각한 기능을 추가하려한다.
7. 멀티태스킹 하는 개발자 : 이는 중소기업에서 흔히 보이는 현상이다. 수많은 SI프로젝트를 개발하는 주체는 대개 중소기업일 것이다. 인원이 모자르기 때문에 한명의 개발자는 여러 프로젝트 참여 또는 유지보수성 일을 함께 병행할 수 있다. 모든 일에는 업무전환시간이 존재하며 이는 프로젝트 일정에 영향을 끼치는 불필요한 시간 소모를 야기시킨다.
8. 많은 개발 산출물 : 개발산출물이 너무 많이 요구 된다면 이 또한 시간소모일 수 있다. 당장 불필요한 산출물은 프로젝트진행단계에서 빼도 문제될 건 없다.
   

 애자일은 위의 실태를 완화 할 수 있다고 말한다. 그리고 애자일의 특징은 아래와 같이 정리해보았다.

1. 계획에 따르기보다는 변화에 대응하는 것에 가치를 둔다.
2. 프로세스 도구보다는 커뮤니케이션에 가치를 둔다.
3. 스프린트(애자일 스크럼 프로젝트에서 2주간의 기간)의 핵심 중 하나는 동작하는 소프트웨어를 각 스프린트 마다 Demo하는 것이다. 이는 결함을 줄이는 것에 의의가 있다. 결함은 잠복기간이 긴 버그이다.
   
4. 팀원간 신뢰를 바탕으로 진행해야한다. 또한 팀원에게 자율성을 부여하고 책임감을 가지게 하는 것이다.
   
5. 전통적인 개발방법에서 요구사항이 끝난 후 개발을 착수하는 구조는 설계, 분석 단계에서 시간을 너무 많이 소요한다.
6. 백로그(애자일에서 할일 목록 리스트)는 상호 독립적이고 변경 가능하며, 테스트 가능해야한다.
7. 에픽은 "사용자 로그인 기능"
8. 스토리는 "사용자는 ID, PASSWORD를 입력하여 로그인 할 수 있다."
9. 회의에서 공수에 대한 논의는 경험자와 함께 하는것이 좋다.
10. 상사의 피드백은 자신감을 실어준다.

 이 책을 초반, 중반은 전통적 폭포수 모델의 문제점과 과거 소프트웨어 산업의 문제점, 야근 등을 재미있게 풀어 썼고, 애자일의 장점은 설명한다. 그리고 후반은 애자일의 적용방안을 상세히 설명한다.