애자일 & 스크럼 프로젝트 관리

애자일과 스크럼은 소프트웨어 업계에서 정말 많이 나오는 프로젝트 관리 방법들입니다.

먼저 애자일 스크럼 이전의 전통적 프로젝트 수행 방식에는 어떤 한계가 있었는지 살펴보겠습니다. 

전통적인 수행 방식은 크게 규격화된 틀조차 없이 제조업에서 일하는 문화로 진행되었으며 이러한 수행 방식에는 다음과 같은 한계들이 존재하였습니다. 

1. 프로젝트 초기에 구체적인 요구사항을 도출하기 어렵다. 

분석, 설계, 구현, 테스트를 순차적으로 진행하는 폭포수 개발 방식은 분석단계에서 충분한 시간 투자를 진행하여 요구사항을 구체화시키지 않는다면 다음 단계로 못 나아가는 한계가 존재하였습니다. 이렇기에 일정 예측도 불가능하였습니다.

왜 도출이 어려운거냐? 라고 질문이 생긴다면 프로젝트 초반에는 concept과 같은 상세한 요구사항을 모두 커버하지 못한 채로 나아가기 때문이며 더더욱 높은 기술이 필요한 R&D와 같은 경우 더더욱 어려운 이야기가 됩니다. 

2. 프로젝트 중간에 발생한 요구사항의 변경을 반영하기 어렵다.

초기를 지나서 갑작스럽게 요구사항들이 발생할수있습니다. 엔지니어들은 당연히 고객의 요구사항을 정확히 파악하려고 노력하나 고객의 입장에서는 완성된 결과를 보면서 이해가 쉬울 수 있습니다. 그러나 이는 엔지니어와 고객 사이에서 상상하는 게 100% 일치하는 게 불가능하여 피드백은 어느 정도 진행이 된 후에 나오게 됩니다. 때문에 이 시점에서는 일정이 딜레이 되면서 추가 비용들이 발생하게 됩니다. 

3. 프로젝트 과정 중 중간 산출물들을 많이 요구함.

진행 과정이 잘 진행되고 있는지 중간에 관리가 이루어져야만 합니다. 이에 따라서 타당성을 따지고 세심한 작업을 수행하기도 합니다. 하지만 한다고 하여도 체킹을 하는 전문가가 부재할수도 있으며 테스트를 요구했을 때 필요한 문서 산출물들을 만드는데 시간이 많이 걸리기도 합니다.

4. 프로젝트 관리자 중심의 명령 및 통제 방식의 문제

기존의 방식은 관리자만 업무를 계획하고 통제하여 팀원에게 업무를 분배하는 역할을 수행합니다. 이에 따라서 밑의 직원들은 위에서 분배된 역할을 수행할 뿐이며 주체성이 낮아지는 문제가 발생할수있습니다. 

 

애자일 (Agile)

90년대 중반부터 활성화된 IT 비지니스의 시작을 계기로 빠르게 생태계가 발전하면서 프로젝트를 수행하는 접근 방식도 다르게 됩니다. 

애자일의 의미는 기민이라는 의미입니다. 때문에 속도감 있게 신속한 반복 작업을 통해서 실제 작동 가능한 소프트웨어를 개발하고 제공하기 위한 프로젝트 접근 방법입니다. 구체적으로는 작은 구성 요소를 신속하게 제작하여서 고객의 만족도를 개선하는 방법이며 때문에 정기적으로 고객과 직접 만나서 요구사항을 듣고 협업을 진행합니다. 신속한 접근 방법이기 때문에 변화를 적극 수용하며 대처에 유용한 방법입니다. 일련의 규정은 아니며 팀 안에서 일어나는 협업과 워크플로우를 바라보는 하나의 관점이나 가치체계입니다. 

1990년대 중반부터 지금까지 다양한 애자일 개발 방법들이 제안되었습니다.

• DSDM (Dynamic Systems Development Methods, 1994)
• Scrum (scrum, 1995)
• 크리스털 방법론 (Crystal Clear, 1996)
• XP (Extreme Programming, 1996)
• FDD (Feature Driven Development, 1997)
• ASD (Adaptive Software Development, 2000)
• 린 (Lean SW Development, 2003)
• 칸반 (SW Kanban, 2006)
• 린 스타트업 (Lean Startup, 2011)

 

그리고 애자일 전문가 17명이 모서 하나의 공통적 개발 철학을 정리하였으며 이것이 애자일 소프트웨어 개발 선언문 (Manifesto for Agile Software Development)입니다. 애자일 선언문은 다양한 애자일 개발 방법의 근본원리를 기술한 문서입니다. 간단히 요약하면 다음과 같은 4개의 가치를 내세우고 있습니다.

• 개인과 개인간의 상호작용이 프로세스 및 툴보다 우선
• 작동하는 소프트웨어가 포괄적인 문서보다 우선
• 고객과의 협업이 계약 협상보다 우선
• 변화에 대응하는 것이 계획을 따른 것보다 우선됨

 

애자일 소프트웨어 개발 선언문의 가치 문장 4개에 기술된 개발 철학을 실제 제품에 적용시 키이 위해서 12가지의 구체적인 지침을 만들었습니다. 

1. 소프트웨어 개발을 수행하는 최우선 목표는 빠르고 지속적이며 가치있는 소프트웨어를 전달하여 고객을 만족시키는 것
2. 애자일 프로세스는 고객의 경쟁력을 위해서라면 비록 개발 후반일지라도 요구사항의 변경을 환영함
3. 동작하는 소프트웨어를 2주일에서 2개월까지 짧은 간격으로 자주 전달하라
4. 요구사항을 내는 고객과 개발자는 전체 프로젝트에서 매일 함께 일해야한다
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하고 그들에게 필요한 환경과 자원을 제공하고, 일을 잘 끝낼 수 있도록 신뢰하라
6. 개발팀 내부에서 정보를 전하는 가장 효율적인 방법은 서로가 얼굴을 마주 보면서 대화하는 것이다
7. 작동하는 소프트웨어는 진척의 주된 척도다
8. 애자일 프로세스는 지속 가능한 개발을 장려하며 스폰서, 개발자, 사용자는 일정한 개발 속도를 계속 유지해야 한다
9. 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다
10. 간단함, 즉 하지 않은 일의 양을 최대화하는 기술이 필수적이다
11. 최고의 아키텍처, 요구사항, 설게는 자기 조직화된 팀에서 창발 한다
12. 정기적으로 어떤 방법이 팀에 더 효과적일지 숙고하며 이에 따라 팀의 행동을 조율하고 조정한다

반복적이고 유기적인 움직임을 통해서 애자일은 변화에 능동적으로 대응하지만 위에서 언급한 전통적인 방식은 단방향으로 진행됩니다. 때문에 Waterfall 폭포처럼 위에서 아래로만 흐르게 되는 형태와 유사하여서 Waterfall 방식이라고도 부릅니다. 다만 각각의 방식이 힘을 발휘할 수 있는 영역은 나뉘어있으며 예를 들어 되돌리기 어려운 작업 (자동차, 건축...)이라면 Waterfall이 적합할 수 있습니다. 

 

다만 이렇게 좋은 방법같이 보이는 애자일 방식이라도 다음과 같은 단점이 존재합니다.

• 팀원 간에 광범위한 기술을 보유해야만 한다
• 계획이 덜 정확할 수 있음
• 문서가 무시될 수 있음
• 초기 계획된 결과보다 최종 출력은 크게 다를 수가 있음
• 개발팀의 프로젝트에 쏟는 시간의 증가로 인한 개발자의 시간 약속의 감소

반응형

 

스크럼 (Scrum)

스크럼은 애자일 방법 중에서 오늘날 가장 대중적이며 영향력이 큰 업무를 수행하는 데 사용되는 애자일 프레임워크입니다. 애자일방법을 어떻게 실행할 것인가라는 물음에서 나온 도구로서 스크럼과 칸반이 있습니다. 스크럼은 sprint라는 개념을 이용하며 칸반은 Work in progress를 제안하며 애자일 방법을 실행합니다. 

*스프린트: 반복적인 개발 주기 (Iteration, 보통 1~4주의 기간으로 선정). 해당 기간 동안 팀원들은 전력질주를 한다는 의미에서 스프린트라고 작명

 

스크럼에서 추구 가치는 다음과 같습니다. 

• 용기 - 옳은 일을 하기 위해서 팀원 간의 갈등과 도전을 위한 용기를 가질 것
• 집중 - 할 일에 온전히 집중하는 것
• 약속 - 팀의 목표 달성과 개개인의 목표달성을 위한 헌신
• 존중 - 개개 안이 가진 경력과 경험의 장단점을 존중하는 것
• 투명성과 개방성 - 프로젝트의 모든 내용을 투명하게 공개하는 것

 

해당 가치들을 이행하기 위해서 아래와 같은 특징들을 가지고 있습니다.

• 설루션에 포함될 기능 및 개선점에 대한 우선순위를 부여할 것
• 개발 주기는 1~4주이며 실제 동작할 수 있는 결과를 제공할 것
• 매일 15분 정도의 Scrum meeting을 가질 것 (공유하는 자리이며 보고하는 자리가 아님)
• 항상 팀을 우선으로 생각할 것
• 원활한 의사소통을 위해서 구분 없는 열린 공간과 마음을 유지할 것

 

플래닝 세션 미팅을 진행하면서 해야 할 리스트인 Backlog를 작성합니다. 이에 따라서 Product Backlog도 있을 것이며 한 곳에 명확하게 문서화하여서 정리합니다. 그 후 스프린트를 진행하면서 백로그 항목들을 수행합니다. 일일 스크럼 스탠드업 미팅을 수행하고 스크럼 팀과 논의할 계획을 세웁니다. 업무에 대해 보고하고 우선순위를 지정하는 시간이기도 합니다. 스프린트가 끝난다면 회고 과정을 통해서 공유와 다음 스프린트에 개선점을 반영합니다. 완료가 되었다는 의미가 무엇인지 다시 생각하면서 완벽이란 없으며 가까워질 뿐임을 상기하면서 정의한 완료에 도달했는가를 체크합니다.

완료의 예는 다음과 같습니다.

• 제품의 출시가 준비되었는가?
• 테스트를 거쳐서 베타 환경에서 출시될 준비가 되었는가?
• 수락 테스트를 거쳐서 모든 사용자에게 출시될 준비가 되었는가?