AGILE Framework - 스크럼(SCRUM) Basics (2)

미리 일러두는 말: 본 포스팅은 LinkedIn 에서 제공하는 [Agile Methodology] Scrum 과정을 참고하여 정리한 내용임을 알려드립니다.

스크럼을 수행하기 위한 준비

지난 “AGILE Framework - 스크럼(SCRUM) Basics (1)” 포스팅을 통해 우리는 스크럼의 유래, 그것이 갖는 의의, 팀 구성을 위한 작업에 대해 알아보았습니다. 이번 “스크럼 Basics (2)” 포스팅에서는 스크럼의 구성요소를 어떻게 프로젝트에 안착시키는지, 어떻게 프로젝트의 A to Z를 계획하는 지 알아보겠습니다.

프로젝트 비전(Vision) 세팅

프로젝트를 수행함에 있어 가장 선행되어야할 일은 아마도 프로젝트가 목표하는 바, 즉 ‘비전(Vision)’을 세우는 작업일 것입니다. ‘프로젝트 비전’은 곧 프로젝트의 지향점 혹은 방향, 프로젝트가 종료된 이후 우리가 어떤 제품을 얻을 수 있는지에 대한 구체적 이미지라고 표현할 수 있습니다. 이렇게 최우선적으로 프로젝트가 나아가야 하는 바를 세움으로써 프로젝트에 참가하는 구성원(스크럼 팀) 모두는 공통의 목표를 향해 함께 나아도록 하는 일종의 가이드를 얻게 됩니다.

쉬운 말로 비전 세우기

프로젝트 비전은 앞서 말했듯 프로젝트의 가이드로 기능합니다. 이 프로젝트 비전을 세우는 일은 스크럼 팀의 Product Owner가 맡습니다. 이는 스크럼 팀원 중 Product Owner가 프로젝트의 목적을 가장 잘 아는 사람이기 때문입니다. 당연한 말이지만 프로젝트 Owner인 고객이 필요로 하는 것을 정확하게 파악해야만 흔들리지 않고 명확한 ‘프로젝트 가이드’를 세울 수 있고, 이에 최적인 팀원이 바로 Product Owner인거죠.

본격적인 설명에 앞서 간단한 예를 하나 들어보겠습니다. 여러분이 [배달서비스 모바일 앱]을 만드는 프로젝트에 참여하고 있다고 가정해 봅시다. 배달서비스 모바일 앱을 활용할 고객들은 직접 가지 않고도 자신이 좋아하는 맛집에서 자신이 원하는 음식을 주문하고 또 신속하게 전달 받기를 바랍니다. 이런 고객의 요구사항을 조합해 풀어서 표현해 보면 우리 프로젝트의 비전은 “많은 시간을 들이지 않아도 다양한 음식을 바로 결제하고 배달 받아 즐길 수 있도록 하여 바쁜 현대인들이 편리함과 만족감을 얻도록 하는 모바일 앱” 이라고 정리할 수 있겠습니다. 멀리 돌아 왔지만.. 극단적으로 쉽게 말하면.. 그냥 ‘배X’이나 ‘요X요’가 되겠네요;;

이렇게 프로젝트 비전은 스크럼 팀원으로 하여금 프로젝트의 방향을 제시해 주고 최종적으로 목표하는 바를 묘사해 주는 개념입니다. 이는 프로젝트 초기에 프로젝트의 목표를 명확히 하고 프로젝트 중간중간 팀이 어려움에 부딪히거나 목표 의식이 흐려질 때 팀을 모으는 구심점 역할을 하게 됩니다. 따라서 프로젝트 비전은 문장이나 이미지가 간단하고 표현이 명확할 수록 좋습니다. 반대로 사람에 따라 달리 해석될 소지가 있거나 모호하게 표현되어선 안되며, 특히 프로젝트 중간에 변경될 수 없음을 꼭 명심하시기 바랍니다.

Minimal Viable Product(MVP)

프로젝트 비전이 이렇게 최종 목표를 향한 가이드라면 프로젝트 중간 중간에 우리가 옳은 방향으로 나아가고 있는지는 어떻게 알아 볼 수 있을까요? 바로 ‘최소 시연 제품(Minimal Viable Product, MVP)’를 통해 확인할 수 있습니다. MVP는 말 그대로 ‘시연이 가능한 최소 단위의 제품’으로 스크럼으로 진행되는 프로젝트 도중 프로토 타입의 제품으로써 고객에게 ‘앞으로 이러한 모습으로 제품이 갖춰질 겁니다.’라는 메세지를 줄 수 있습니다. 언뜻보면 프로젝트가 제대로 진행되고 있는지를 확인하는 체크 포인트란 측면에서 MVP가 폭포수 방식의 마일스톤(Milestone)와 비슷한 게 아닌가 느껴질 수 있습니다. 하지만 마일스톤과 달리 스크럼의 MVP는 제품의 일부이면서 ‘프로토 타입 제품’이기 때문에 그 자체로 시연 가능하다는 장점을 갖는 데에서 차별점을 갖습니다.

즉, 스크럼 팀은 프로젝트 비전과 (아래에 설명할) 사용자 스토리에 따라 제품을 개발하게 되는데, 두개 이상 복수의 스프린트를 통해 시제품을 개발하고 최종 사용자(고객)에게 시연합니다. 시제품 시연을 하고 동시에 고객으로부터 피드백을 받음으로써 스크럼 팀은 자신들이 개발한 중간 결과물이 프로젝트 비전에서 벗어나지 않았는지 체크하게 되는 것이죠.

더욱 중요한 것은 MVP를 무엇으로 할지 지정하고 시연 시점을 정하며 실제로 시연하는 행위 자체가 프로젝트 비전에 어긋나지 않는지 체크할 기회를 갖는 것은 물론 다음과 같은 또다른 이점을 가질 수 있습니다.

• 첫째, 고객에게 제품이 어떤 모습을 갖게 될 것인지 미리 보여주고 그에 대한 피드백을 받아 숨어 있을지 모를 일감을 미리 발견할 수 있습니다. 특히 MVP가 보여주는 모습이 고객이 생각했던 바와 다르다면 어떤 모습으로 바꼈으면 좋겠다는 피드백을 내놓을 기회를 제공하는 것이죠. 프로젝트 전체 관점에서 볼 때 이른 수정에 따른 노력과 비용이 늦은 수정의 노력과 비용보다 훨씬 적게 소요된다는 건 주지의 사실입니다. 빠른 피드백에 따른 신속한 수정의 기회로써 MVP는 상당한 이점을 갖게 됩니다.
• 둘째, 스크럼이 예정된 일정 상 차질없이 진행되고 있는지를 확인 받을 수 있습니다. MVP가 시연될 만큼의 품질을 확보하려면 복수의 스프린트(최소 4주)동안 스크럼 팀 구성원 각자가 맡은 업무를 잘 수행해야 합니다. 이는 곧 MVP 시연으로 폭포수 모델의 마일스톤이 갖는 의미를 충분히 대신한다는 것을 의미하고 자연스레 스크럼 팀이 보여주는 퍼포먼스가 프로젝트 일정을 준수하는데 부족함이 없음을 보여주게 되는 것이죠.
• 셋째, 궁극적으로 최종 사용자(고객)에게 스크럼 팀과 프로젝트에 대한 신뢰도를 제고 시킵니다. 위에 언급했듯 MVP 사연을 통하여 스크럼 팀은 고객에게 자신들이 프로젝트 일정에 따라 착실히 일감을 수행해 나간다는 확신을 주고, 프로젝트 비전에 따른 즉, 고객이 원하는 모습으로 구현되어 나가는 시제품을 보여줌으로써 처음엔 불투명했던 제품에 대한 ‘안개’를 조금씩 걷어낸다는 점에서 스크럼 팀에 대한 고객의 신뢰도를 높일 수 있게 되는 것이죠. 궁극적으로 실제 구현된 제품을 눈으로 확인함으로써 고객은 보다 명확한 제품 이미지를 예상할 수 있게 되고, 스크럼과 Agile 방법론에 대한 지지(Support)를 보내게 되는 선순환을 이뤄 낼 수 있습니다.

이렇게 MVP는 프로젝트 비전이 잘 지켜지는지 점검하는 것 외에도 상당한 이점을 갖습니다. 따라서 프로젝트 기간이 충분히 길다면 일정 기간마다 1차, 2차, 3차(혹은 그 이상의) MVP를 시연하면서 자칫 느슨해 질 수 있는 스크럼 팀의 분위기를 다잡고 고객과 교감하는 기회로 적극 활용하는 것을 추천합니다.

비전 분해하기(사용자 스토리 작성을 위한 준비)

이제 이제 프로젝트 비전을 컴포넌트 단위로 나누는 방법을 알아 보도록 하죠. 프로젝트 비전은 하나의 문장이자 개념이기 때문에 실제 제품을 개발하기 위해서는 이를 테마별로 나누어 접근해야 합니다. 위에 예로 들었던 프로젝트 비전은 간단히 ‘편리한 배달서비스 앱’이었습니다. 이는 다시 아래와 같은 몇 개의 테마로 나누어 볼 수 있습니다.

이들 테마들은 큰 기능 단위라고 보면 되겠죠? 그럼 이를 다시 작은 기능 단위로 쪼개어 볼 수 있을 겁니다. 첫번째 테마인 사용자 프로파일을 예로 들어 쪼개어 보면 아래와 같은 기능들이 도출됩니다.

이렇게 프로젝트 비전에 나타난 테마로 나누고 이를 다시 개별 기능 단위로 쪼개는 과정을 통해 우리는 프로젝트 비전을 수행해야하는 일감의 단위로 내릴 수 있게 됩니다. 스크럼에서는 이러한 일감을 사용자 스토리(User Story) 라고 표현하는데 이 것이 우리가 프로젝트를 진행하는 실제 일감의 단위라고 생각하면 됩니다. 이 사용자 스토리를 일감의 단위로 생각하고 이들의 집합, 즉 테마를 스크럼에서는 ‘에픽(Epic)’ 이라고 표현하고 반대로 사용자 스토리를 이루는 하위 작업들은 ‘태스크(Task)’라고 표현하게 됩니다. 자, 그럼 다음 세션에서 이 사용자 스토리를 작성하는 방법에 대해 자세히 살펴보도록 하겠습니다.

사용자 스토리 작성하기

사용자 스토리(User Story)는 프로젝트 기간 동안 스크럼 팀이 수행하고 완료해 나가야 하는 일감의 단위라고 앞선 세션에서 살펴보았습니다. 이 사용자 스토리는 다음과 같이 정의할 수 있습니다.

사용자 스토리(User Story)는 고객이 원하는 가치를 구현할 수 있는 세부적인 일감들의 묶음으로써, 스크럼 팀이 스스로 정한 ‘일정한 시간’ 내에 완료할 수 있을만한 업무량 단위로 충분히 세분화되어야 한다. 이러한 사용자 스토리는 Product Owner(PO)에 의해 작성되고 역시 PO가 우선순위를 결정하여 각 스프린트에 배치할 수 있으며, 추후에 필요에 따라 우선순위와 배치를 조정할 수 있다. 주의할 점은 사용자 스토리는 소프트웨어 공학 용어가 아닌 일반적인 용어를 사용하여 누구나 이해할 수 있는 수준으로 작성되어야 한다는 것이다.

사용자 스토리 예시

그럼 사용자 스토리를 한번 작성해 볼까요? 위에 들었던 모바일 앱의 기능 중에 ‘사용자 프로파일(Profile)’을 예로 들어보겠습니다. 사용자 프로파일에는 사용자의 이름, 이메일 주소, 연락 가능한 전화번호, 패스워드 등이 포함될 겁니다. 이를 차례로 사용자 스토리로 표현해 보면 다음과 같은 모습이 될 수 있는데, 특히 위 정의 말미에 언급되었듯 누구나 이해할 수 있는 용어를 사용해야 한다는 점에 유의하면서 작성해 보겠습니다.

• 이름: 고객 이름을 포착해 저장한다.
• 이메일 주소: 고객 이메일 주소를 포착해 저장한다.
• 연락가능 전화번호: 고객 전화번호를 포착해 저장한다.
• 패스워드: 고객 패스워드를 포착해 저장한다.

사용자 스토리의 특성

1. 쉬운 용어로 표현하자. 예시를 보면 아시겠지만, IT 분야의 용어지만 보편적으로 사용되고 이해하기 쉬운 용어를 사용하여 표현했습니다. 왜 그래야만 할까요. 이는 스크럼 팀에 참여하는 구성원들이 모두 동일한 수준으로 사용자 스토리를 이해해야 하기 때문입니다. Product Owner만 해도 IT 기술요소에 익숙하기보다 그렇지 않은 경우가 더 많을 뿐더러, 실제로 스크럼 팀에 참여하는 다른 팀원들 사이에도 기술요소에 대한 이해의 수준이 천차만별입니다. 더욱이 사용자 스토리는 스크럼 팀에 속하지 않으면서 프로젝트에 가장 큰 영향을 미치는 고객이 볼 때도 동일한 수준으로 이해할 수 있도록 해야 합니다. 따라서 사용자 스토리는 최대한 쉽고 대중적인 용어를 활용하여 표현해야만 합니다.

2. 중복을 피하고, 협의를 거쳐 고객가치를 높이자. 또한 좋은 사용자 스토리는 독립적(Independent)이고 협의 가능(Negotiable)해야 하며, 가치를 창출(Valuable) 할 수 있는 일감을 표현해야 합니다. 같은 일감을 두, 세번 중첩해 표현할 필요가 없겠죠. 그리고 사용자 스토리 사이의 중요도 혹은 내용이 바뀔 경우를 대비하여 PO와 SM 간 협의를 통해 조정이 가능해야 합니다. 또한 고객에게 쓸모 없는 일감을 수행할 필요도 없습니다. 프로젝트 비전을 실현하기에 필수적인 일감을 수행하기에도 프로젝트 기간은 빠듯하기 때문이죠.

3. 일감의 크기를 재서 큰 일감은 충분히 쪼개자. 그리고 좋은 사용자 스토리는 그 작업량이 측정 가능(Estimable)하고, 충분히 작아야(Small) 합니다. 사용자 스토리는 대중적인 용어를 활용하여 쉽게 풀어서 작성하기 때문에 각각의 업무량을 객관적으로 표기하기 어렵습니다. 이를 해결하기 위헤 스크럼에서는 ‘스토리 포인트(Story Point)’라는 단위를 적용하여 사용자 스토리를 측정 가능한 것으로 표시합니다. 이러한 스토리 포인트는 스크럼 팀이 하루나 이틀 정도의 기간 내에 완료할 수 있을 정도로 작아야 합니다. 만약 스토리 포인트가 하나의 사용자 스토리에 너무 많이 몰릴 경우 스프린트 진행 자체를 지연시킬 수 있으니 적절하게 나누어 배분해야 합니다. (스토리 포인트에 대해서는 아래 별도의 세션을 통해 좀 더 자세히 살펴보겠습니다.)

4. 개발 후에는 확인해 보자. 마지막으로 좋은 사용자 스토리는 개발 후 테스트가 가능해야(Testable) 합니다. 사용자 스토리는 소스의 개발이 완료된 뒤 PO와의 확인을 거치기 전까지 충분히 테스트할 수 있어야 합니다. 즉, 위의 예시처럼 ‘~를 저장한다.’ 라는 기능을 지칭하는 단어가 포함되어 있어 실제 데이터들이 DB에 저장이 되는지 등을 판단의 기준으로 제시해야 함을 의미합니다.

사용자 스토리의 완료 기준

사용자 스토리는 Product Owner(PO)에 의해 작성되고 우선순위가 결정되어 각 스프린트에 적절히 배치되어야 하며 필요한 경우 추가되거나 그 우선순위가 조정될 수 있습니다. 그렇다고 PO 마음대로 이리저리 휘둘러도 괜찮다는 뜻은 아니겠죠?

이런 불상사를 방지하기 위해 프로젝트 초기에 작성되거나 중간에 추가될 사용자 스트리는 프로젝트 관계자 중 누가 보아도 그 필요성이 인정되어야 합니다. 즉, 사용자 스토리는 가능한 최대한 명료하게 표현하여 팀원들이 접했을 때 해당 스토리가 완료됐을 때 어떠한 제품이나 기능이 구현되는 지 알 수 있어야 합니다.

더불어 사용자 스토리는 스크럼 팀의 일감을 의미하므로 그 시작과 끝이 명료해야 합니다. 이를 위하여 스크럼 팀은 사용자 스토리의 ‘완료(Done)’ 정의을 미리 수립해야 합니다. 즉, 스프린트가 종료되고 다음 스프린트를 진행하려면 해당 스프린트에 할당된 사용자 스토리가 PO에 의하여 모두 완료되어야 하는데, 만약 완료의 기준이 명확하지 않으면 팀 전체가 스토리가 완결됐는지 아닌지에 대해 혼란을 겪을 수 밖에 없습니다. 더 큰 문제는 제때 정리하지 못한 사용자 스토리로 인해 스프린트가 완전히 마무리되지 않은 상태로 다음 스프린트 기간이 도래하고 이런 상황이 지속된다면 프로젝트 전체가 지연되고 결국 프로젝트 실패로 이어 질 수 있다는 점입니다. 그렇기 때문에 사용자 스토리의 완료 기준을 반드시 명확하게 정의하고 이를 스크럼 팀원들과 투명하게 공유함으로써 사용자 스토리 완료 여부의 모호함으로 인한 스프린트 지연 가능성을 사전에 없애야 합니다.

사용자 스토리의 크기 측정하기 - 스토리 포인트(Story Point)

사용자 스토리는 많은 사람이 동일한 수준으로 이해할 수 있도록 대중적이고 쉬운 표현을 활용해야 하기 때문에 소프트웨어 공학적으로는 불분명한 측면을 갖고 있습니다. 이러한 모호함은 사용자 스토리를 정량적으로 표현하는 것으로 해결할 수 있는데 이를 위해 제시된 개념이 ‘스토리 포인트(Story Point)’입니다.

스토리 포인트는 일종의 시간에 대비되는 점수 개념으로써 반나절(4시간) 혹은 하루(8시간) 단위의 시간을 각각 1 포인트, 2포인트와 같은 정량적 단위로 환산하는 방식을 취합니다. 이는 상대적인 개념으로써 어디에서나 통용되는 절대적인 개념은 아니므로 스크럼 팀에서 스스로 그 기준을 지정합니다. 예를 들어 스크럼 팀원 중 중급 레벨의 개발자가 4시간 작업해야 완료할 수 있을만한 업무량을 1포인트라고 설정했을 때, 만약 사용자 스토리 A가 하루 반나절 (12시간)정도의 작업이 필요하다면 이 스토리A는 3포인트가 되는 방식입니다. 같은 맥락으로 사용자 스토리 B가 중급 개발자가 24시간 정도 작업해야한다면 스토리 B는 6포인트인거죠.

이렇게 스토리 포인트는 상대적인 개념이지만 스크럼 팀으로 하여금 사용자 스토리별로 얼마의 시간이 소요될지 특정 할 수 있게 해주고 팀원들의 수준에 맞추어 스프린트에 적당한 분량의 사용자 스토리를 배치할 수 있는 ‘가늠자’ 역할을 합니다. 예를 들어 프로젝트 초기에 PO가 작성한 사용자 스토리들의 스토리 포인트와 작업들의 우선순위를 고려하여 각 차수의 스프린트에 배치할 수 있고, 한 두차례의 스프린트를 거친 후 작업량이 적당한지 검토해보고 스토리 포인트에 따른 사용자 스토리 배치를 그대로 유지하거나 조정 할 수 있습니다.

위의 이미지를 볼까요? 사용자 프로파일 에픽이 1월 초 부터 2월 중순까지 진행되고 2월 중순부터는 주문 에픽으로 넘어가는 것을 볼 수 있습니다. 조금 더 자세히 보자면 각 스프린트에 10 ~ 11 정도의 스토리 포인트를 갖는 사용자 스토리들을 배치한 걸 나타낸 것을 알 수 있습니다. 이로 미루어 볼 때 우리 스크럼 팀은 약 2주간의 스프린트 동안 10포인트의 작업량을 처리할 수 있다는 가정하고 있다는 걸 알 수 있습니다. 또한 한 스프린트에 A, B, C / D, E, F 처럼 순차적으로 스토리를 배치한 것이 아니라 뒤섞어 배치했음을 볼 때, Product Owner가 사용자 스토리의 우선순위와 스토리 포인트 배분(작업량 배분)을 고려하여 스프린트에 분산 해 놓은 것도 알 수 있습니다.

로드맵과 릴리즈 계획 세우기

로드맵(Roadmap) 세우기

‘로드맵(Roadmap)’은 사용자 스토리의 집합(테마)을 일컫는 에픽을 프로젝트 기간 내 일련의 시간 순으로 배치해 놓은 개념적 혹은 물리적 이미지를 말합니다. 아래 이미지를 보면, 1월 ~ 6월까지 진행되는 프로젝트가 있고 전체 4개의 에픽(테마)가 진행됩니다. 우선 1월 초 부터 2월 중순까지 1번 사용자 프로파일 에픽을, 2월 중순 부터 3월 말까지는 2번 주문 에픽을 개발합니다 그리고 다음 4월 초 부터 5월 중순까지 결제 에픽, 5월 중순부터 6월 말까지 개발하는 배송 에픽을 마지막으로 모바일 앱 개발 프로젝트가 종료되겠군요.

이렇게 로드맵은 앞선 스프린트 계획에 기초하여 전체 프로젝트의 수행 계획을 수립하는 작업입니다. 스크럼 팀에게 주어진 프로젝트 기간에 맞게 스크럼 팀이 완료해야 하는 사용자 스토리들을 모두 완료할 수 있는지 가늠할 수 있고, 만약 그렇지 못하다면 개발 작업을 시작하기 전에 계획안을 수정할 기회를 제공하게 됩니다.

릴리즈 계획 세우기

위와 같이 로드맵을 도출한 이후에는 제품 출시 계획이라고 할 수 있는 ‘릴리즈 계획(Release Plan)’을 세워야 합니다. 로드맵 단계를 한 단계 올려 제품의 ‘출시’를 계획하는 것인데, 이 릴리즈 계획은 프로젝트별로 한차례 혹은 수차례 이루어 질 수 있습니다. 다만, Agile의 장점과 취지를 효과적으로 살리기 위해서는 한차례 보다는 수차례의 릴리즈 계획을 세우는 것이 좋습니다. 예를 들어 1차 릴리즈 때는 스크럼 팀이 목표로 하는 제품에서 가장 중요한 파트를 출시하고, 이를 바탕으로 2차 릴리즈 때 부가적이거나 조금 덜 중요한 파트를 마저 출시하는 릴리즈 계획을 수립할 수 있습니다.

위 이미지를 살펴볼까요? 앞서 살펴보던 모바일 앱의 에픽들을 1~6월 사이의 기간에 편의 상 배치해 두었습니다. 이 때 중요성 측면에서 가장 중요하다고 판단한 ‘사용자 프로파일’ 에픽을 1~2월, 그 다음 ‘주문’ 에픽을 2월~3월에 진행하는 것으로 배치하고 이들 에픽들이 완료된 시점인 3월 말에 1차 릴리즈를 통해 절반의 제품을 고객에게 납품합니다. 그리고 ‘결제’에픽은 4월~5월, ‘배송’ 에픽을 5월~6월의 일정으로 마치면서 6월 말에 2차 릴리즈를 통해 나머지 절반의 제품을 마저 납품합니다.

이렇게 릴리즈 계획은 일종의 타임테이블로써 사전에 전체 프로젝트의 기간을 고려해 출시 시점을 기준으로 로드맵, 스프린트, 사용자 스토리 및 태스크 단위까지를 역순으로 구조화하도록 돕습니다. 특히 일감의 진행 일정을 이미지화 함으로써 고객과 스크럼 팀에게 프로젝트 중간 중간 우리가 어느 시점에 와 있고 어느 정도의 일감을 완수 했어야 하는지에 대한 기준을 제시해준다는 의의도 갖습니다.

마무리 - 스크럼 계획하기의 의미

지금까지 스크럼을 이끌어 갈 프로젝트 비전을 세우고 수행의 기본 단위인 사용자 스토리를 작성하는 것은 물론 프로젝트의 전체 계획을 수립하는 방법까지 알아보았습니다. 긴 설명을 거쳐 논의하고자 했던 내용은 스크럼이란 프로젝트를 릴리즈 계획에 따라 나눠 납품하게되는데 이 릴리즈 계획은 다시 로드맵으로 나눌 수 있고, 로드맵은 다시 스프린트와 그 스프린트를 통해 처리할 일감, 즉 사용자 스토리 순서로 단계별 세분화가 가능하다는 것입니다.

다시 말해, 스크럼은 Agile Framework 를 구체화하는 가장 널리 사용되는 모델로써 단계적이고 체계적인 Planning 방식을 취함으로써, 자칫 모호할 수 있는 Agile 방법론을 실용적이고도 즉시 활용가능한 프로젝트 수행 방법론으로 탈바꿈시킵니다.

자, 이제 잘 짜여진 계획을 손에 넣었으니 스크럼을 통해 실제로 프로젝트를 수행하는 방법을 알아볼 차례입니다. 그럼 다음 포스팅에서 다시 뵙겠습니다.

P.S. 포스팅에서 수정이 필요하거나 보완이 필요한 부분이 있다고 생각하시는 분은 아래 댓글로 의견 남겨 주시면 감사하겠습니다.

관련 글

AGILE Framework - 스크럼(SCRUM) Basics (1) https://engineering-skcc.github.io/culture/scrumbasics1/

AGILE Framework - 스크럼(SCRUM) Basics (3) https://engineering-skcc.github.io/culture/scrumbasics3/