프로세스 개선이 현업에서 정착되려면
• 신정호
이 글은 프로젝트 프로세스의 개선에 관련된 이야기 입니다. 그리고 몇 달전 프로젝트에서 프로세스 구상하고 적용했던 경험들을 이야기하려 합니다. 만약 누군가가 우리팀이 겪은 것과 비슷한 상황에 처해 있다면 이 이야기가 조금이나마 도움이 될 것이라고 기대합니다.
그럼, 가벼운 이야기부터 시작해 보겠습니다.
어느 겨울 군부대에서 이등병이 차가운 물로 걸레를 빨고 있었습니다. 그 모습을 대대장이 우연히 보게 되었고 대대장은 안타까워하며 이등병에게 취사장에 가서 따뜻한 물을 얻어다가 빨래를 하라고 합니다.
이등병은 대대장의 말만 믿고 기쁜 마음으로 취사장으로 뛰어가 따뜻한 물을 달라고 합니다. 하지만 이등병의 예상과는 다르게 취사장에 있던 선임들은 군기가 빠졌다는 구박만하고 이등병을 쫓아 버립니다.
호되게 구박만 당한 이등병은 아무런 소득없이 다시 차가운 물로 빨래를 하게 되었습니다.
그리고 얼마되지 않아 이번에는 중대장이 지나가며 손에 동상 걸릴지 모르니 취사장에서 따뜻한 물을 얻어다가 빨래를 하라고 합니다. 하지만 구박 당할것이 뻔하기 때문에 이등병은 영혼없는 대답만하고 취사장으로 더 이상 가지 않습니다.
그리고 이번에는 행정보급관이 지나가며 이등병에게 자기가 세수를 해야하니 따뜻한 물을 떠오라고 합니다. 당연히 이등병은 어렵지 않게 취사장에 가서 따뜻한 물을 얻어와 행정보급관에게 가져다 줍니다.
행정보급관은 이등병이 떠온 따뜻한 물로 세수를 하지않고 오히려 이등병에게 따뜻한 물을 건냅니다.
“따뜻한 물이 얼마되지 않지만, 이걸로 손을 녹이면서 빨래를 하게”
대대장과 중대장 모두 이등병의 어려운 현상을 보고 “취사장의 따뜻한 물”이라는 해결책을 제시했지만 실질적인 도움이 되지 못합니다. 하지만, 행정보급관은 경험에서 나오는 상황 판단과 해결방법을 제시함으로서 이등병에게 실질적인 도움을 주고 있습니다.
현업에서 코드품질 개선이나 개발조직의 프로세스 개선이 쉽게 정착되지 않는 이유는 앞선 예시와 같이 개선 방법으로 제시한 내용이 실질적이고 빠르게 피부에 와닿지 않기 때문입니다.
한때 만능키 처럼 여겨졌던 애자일은 오히려 요즘에는 금기어로 통용될 만큼 부정적으로 생각하는 시람들을 쉽게 만날 수 있습니다. 왜냐하면 만능키라고 믿었던 애자일은 구성원들에게 더 많은 신경을 쓰게 하고, 더 많은 커뮤니케이션의 비용을 발생시키며 결국 구성원들을 더 많이 피곤하게 만들었기 때문입니다. 더욱 큰 이유는 도입을 해도 사람과 환경 모두 이전과 크게 달라지질 않은 결과 때문일 것 입니다. 곳곳에서 생겨나는 회의적인 의견들은 다른 프로젝트에도 영향을 미치고 긍정적인 애자일 프렉티스들 조차도 쉽게 얼어붙게 만들어 버리곤 합니다.
만약 애자일을 성공적으로 도입하고 지속적인 문화로 안착 시키려면 “애자일은 애자일이라는 단어를 버리고 시작”해야 합니다. 어쩌면 이렇게 이야기 하는 것이 앞선 군인 예화의 등장 인물 중 대대장과 같은 해결책을 말하고 있다고 생각할 수 있습니다. 하지만 지난 수 년의 경험에서 비춰보면, 스크럼이나 칸반 방법론을 도입하여 프로젝트를 수행하면서 개별 요소의 적용범위나 이해관계가 명확한 적이 한번도 없었습니다. 더군다나 같은 패턴으로 진행되었던 프로젝트도 전무합니다.
“조직변화 , 경쟁사 변화로 인한 마감일 변경, 정책의 변경이 일어났지만 일정은 고정인 상황, 구성원 퇴사, 도메인에 대한 이해 부족, 기술에 대한 난해함”등 이유는 차고 넘칩니다.
그래서 누군가 신규 프로젝트를 진행하는데, 처음부터 “우린 스크럼 프로세스로 진행하겠습니다” 라고 선포하려 한다면 신발벗고 나서서 말리고 싶은 심정입니다. 물론 리딩을 하는 사람은 당연히 애자일을 도입하는 목적과 범위, 그리고 구체적인 프로세스를 알아야 하지만, 모든 구성원이 처음부터 스크럼을 강제로 알게 만들 필요는 없습니다. 이런 프렉티스를 모르거나 회의적인 의견을 가진 구성원에게는 오히려 일거리만 더 늘었다고 생각할 수 있고, 진행중에 프랙티스가 잘 지켜지질 않은 순간이 생기면 비판의 목소리로 커져 갈 수 있기 때문입니다.
처음에는 조직에 맞게 프렉티스 중 몇 개만 가볍게 도입하는 것이 좋은 방법입니다. 관련된 용어도 정의할 필요가 없습니다. 특히 개발 속도 추정, 에픽/스토리/테스크에 대한 구분점을 명확하게 하려는 시도는 굉장한 혼란과 피로감을 줄 수 있고 일정만 잡아먹게 되는 원흉이 될 가능성이 큽니다. (칸반에서 이슈의 크기를 비슷하게 만들려는 노력 역시 멘붕의 주범이기도 합니다.)
초반에는 아침에 가볍게 모이는 습관을 만들고 기능 구현이 완료되면 리뷰를 하는 정도의 회의로 시작하는 것이 효과적일 것 입니다. 그리고 어느정도의 시간이 지나면 구현하거나 수행해야할 일의 단위를 파악하고 나누는 시간을 구현전에 할 수 있도록 독려하는 것이 필요합니다.
특히 자연스럽게 구성원들 프로세스 개선의 주제에 대한 논의를 할 수 있다면 이 시그널을 바탕으로 점진적으로 프로세스를 도입하는 로드맵을 다 함께 논의하면 됩니다.
또한 프로젝트가 명확한 기준점이 생기고 리듬있게 프로젝트가 진행된다고 판단되면 일을 하는데 집중을 할 수 있도록 부가적인 회의나 추정에는 시간을 적게 쓸 수 있도록 변화시켜야 합니다.
조직의 상황이 빠르게 이슈등을 쳐야 하는 상황에 직면에 있다면 이슈를 만들고 관리하는 시간을 줄이는 전략을 선택해서 이슈 트레킹 자체도 간소화 시킬 수 있다면 충분히 간소화 시키는 것도 방법입니다.
시작, 을지문덕 프로젝트
이제, 조금 더 구체적으로 이야기 해보도록 하겠습니다. 우아한 형제들에서는 새로운 서비스를 위해 TFT가 만들어졌습니다. 이 TFT는 2017년 3월 31일, 아직 우리에겐 생소한 “배민라이더스” 라는 서비스를 세상에 탄생 시켰습니다. 배민라이더스 서비스를 만들면서 정말 많은 이야기 소재가 있는데, 그중에서 이번 주제에 맞게 프로세스 중심으로 이야기를 풀어보도록 하겠습니다.
먼저 프로젝트를 시작하면서 세웠던 유일한 원칙이 있었습니다.
“현실을 직시하며 프로세스를 만들어 간다.”
이것은 어떤 이유든지 변하지 않는 유일한 원칙이였고, 이 원칙 아래에서 모든 프로세스의 전략이 구상되었습니다.
공감 중심의 프로세스
흔히 TFT는 서로 다른팀의 특정 인원들이 모여 하나의 팀이 만들어지곤 합니다. 이렇게 팀을 만드는 가장 큰 이유는 의사결정을 빠르게 내리기 위해서 입니다. 그리고 TFT가 구성되면 소요 일정을 빠르게 결정하거나 그 전부터 고정되어 있는 경우가 대부분 입니다. 이렇게 정해진 일정은 규모산정이 잘못되는 경우가 많으며, 규모산정과는 별개로 일정이 수립되는 경우도 있기 때문에, 결국 구현에 필요한 시간은 절대적으로 부족하게 됩니다.
저희도 전략적인 일정이 있는 상태에서 TFT는 시작되었고 서로 다른팀의 인원들(기획자, 디자이너, 서버개발자 , 클라이언트 개발자)이 모여서 한팀을 이루게 되었습니다. 손발이 척척 맞아도 일정안에 구현을 할 수 있을지 불투명한 판인데, 구성원 중 서로를 처음 보는 사람도 있었습니다. 이런 현실은 업무 조율에 있어 난항이 일어날 것이라고 쉽게 예상할 수 있었으며 이를 해결하는 것이 급선무 였습니다. 이 문제가 해결되지 않은 상태에서는 프로세스 수립은 먼나라 이야기였습니다. 그래서 커뮤니케이션의 문제를 빠르게 해결하려 노력했습니다.
보통 커뮤니케이션 문제의 원인은 서로 다른 업무의 행태에 대한 이해가 없고, 처해있는 상황에 대한 공감이 부족하기 때문에 발생한다고 생각했습니다. 예를 들면 “기획의 정책이 어떤 과정을 거쳐 발생했는지, 구현의 난제는 무엇인지, 표현의 한계가 무엇인지, 연동하는 주요 사항과 예외 사항은 무엇인지, 구현의 경중이 무엇이고, 본질은 무엇인지”등 입니다. 이런 오해 요소들은 프로젝트 진행하는 내내 곳곳에 산재되어 있었습니다.
그래서 이런 문제를 해결하기 위해서 다음과 같은 행동과 자의적,타의적 환경이 만들어져서 프로젝트은 진행되었습니다.
- 하나의 공간과 밀접한 공간을 사용하여 이런 협의들이 투명하게 드러나고 빠르게 논의될 수 있도록 한다.
- 구성원들의 관심도가 떨어지지 않게 하기 위해서 구성원 모두가 매일 짧은 스텐딩 회의를 한다.
- 되도록 의사 결정을 유보하지 않는다.
- 매일 저녁 기획/품질 파트가 모여 불완전한 정책과 요구사항을 바로잡는다.
- 물어보는 사람은 물어보는 것을 주저하지 않고, 만약 질문을 받는 사람이 바쁜 상황이라면 미안해 하지 말고 거절할 수 있어야 한다.
물론 단점이 있었습니다.
- 하나의 공간에 많은 사람이 상주하면서 공기가 나빠지고, 감기가 쉽게 전염될 수 있는 환경이 조성되는 점 (정색을 동반한 격리 조치)
- 의사결정과 회의에 시간이 많이 빼앗긴 다는점 (소는 누가 키우나!)
1번의 문제 해결은 다른 곳에 있는 대형 공기 청정기를 반 강제로 가져 왔었고, 2번의 문제 해결은 2번째 스프린트 중반부터 자연스럽게 해결 되기 시작했습니다.
이렇게 행동과 환경의 변화를 통해 구성원들은 빠르게 공감대를 형성하게 되었고 서로의 입장과 처해 있는 상황을 이해하게 되었습니다.
회색영역 최소화 중심의 프로세스
앞서 가장 중요한 문제의 해결은 서로 다른 지식과 상황 그리고 일의 종류를 가진 구성원들이 서로 이해하고 공감하는 것이였다면, 두번째 난관은 각 파트간의 책임지지 않는 영역을 좁히는 것이였습니다.
프로젝트를 진행하면서 책임지지 않는 영역이 발생하는 부분은 다음과 같았습니다.
- 정책 및 요구사항의 수립 후 구현이나 테스트에서 빠져있는 영역
- 디자인에서 표현 안된 영역
- 클라이언트와 서버간 요청 데이터 설계와 실 구현의 상황 차이에서 오는 변경 영역
먼저, “정책 및 요구사항의 수립 후 구현이나 테스트에서 빠져있는 영역”을 해결하기 위해서는 품질 책임자가 프로젝트 막바지에 투입되어 테스트를 수행하는 것이 아니라 프로젝트 초반부터 투입되어 품질을 보다 자세하게 챙겨가는 것이였습니다. 이 결정은 시간이 지나면 지날수록 프로젝트에 지대한 영향을 주었으며, 프로젝트 일정의 반환점을 도는 시점에는 전략에 하나의 큰 축으로 자리잡게 되는 매우 중요한 결정이였습니다. 이 글에서 품질책임자와 그들이 프로젝트에서 진행했던 규격화된 액티비티들을 자세하게 다룰수는 없지만, 프로젝트 초반의 품질책임자가 투입되는 것은 매우 현명한 선택이였다고 회고되고 있습니다.
다음으로 “디자인에서 표현 안된 영역”은 다시 두가지 관점으로 나뉘는데, “요구사항을 포함한 디자인이 도출되었는가”와“어플리케이션으로 구현되어야하는 상황이 모두 디자인 되었는가”입니다. 이를 해결하기 위해 기획 업무를 재정의 하였습니다. 먼저 제품을 큰 덩어리로 분할하여 기획하고 기존에 PPT로 와이어 프레임을 그리던 업무를 하지 않았습니다. 정책과 요구사항을 텍스트로 상세히 남기는 작업에 집중하고 텍스트로 전달되지 않는 의견은 박스와 화살표로 서비스 흐름을 표시하여 좀 더 의견을 명확하게 전달하는데 집중하였습니다. 이런 문서는 품질과 디자이너와 공유되고, 다시 개발자와 공유 되었습니다. 그리고 빠짐이 생기는 부분을 품질과 기획이 챙기면서 의사소통을 진행하게 만들었습니다.
마지막으로 “클라이언트와 서버간 요청 데이터 설계와 실 구현의 상황 차이에서 오는 변경 영역”은 앞선 정책 및 요구사항 리뷰시에 대략적인 의견을 교류하였습니다. 그리고 프로젝트 초반에는 Restful에서 요청과 응답에 대한 패턴을 인지시킬 수 있도록 관련 문서를 정의하였습니다. 이후 클라이언트와 서버간의 패턴의 인지가 성숙되고, 코드에서 리포팅되는 프레임워크를 사용하면서 이와 관련 문서는 더이상 쓸모가 없어졌다고 판단되었기에 폐기하였습니다.
물론 이런 변화와 수고에도 불구하고 회색영역이 완전히 사라지는 마법은 없었습니다. 하지만 3가지가 구성원들의 업무와 습관적 프렉티스로 완전히 녹아들게되고 회색 영역은 빠르게 줄어들었습니다.
주기적이고 짧은 완료 중심의 프로세스
신규 프로젝트가 얼마나 걸릴 것인가에 대한 생각은 다들 다를 수 있습니다. 그리고 각자 자신이 경험을 바탕으로 일정 추정을 하곤 합니다. 추정이라는 뜻은 원래 “추측하여 정한다”라는 불명확성을 내포하고 있기 때문에, 정확한 수치를 원하는 것은 본래 불가능한 일 입니다.
PO, PM, 기능 구현 담당자는 모두 다른 관점을 가지고 있습니다. 이런 시각차이를 줄이는 방법은 초반 규모산정으로 대립각을 세우기보다 프로젝트를 진행하면서 우리의 현 상황을 투명하게 보여주고 이를 바탕으로 합당한 규모 산정을 이룰 수 있도록 하는 것이 효과적일 것입니다. 그러려면 많은 책에서 언급되어진 것처럼 지속적으로 산출물을 보여주고 이를 수치화하여 정량적인 판단을 내리게 하는 것입니다. “지속적으로 산출물을 보여준다”라는 것은 알겠는데, 어떤 방식으로 보여줘야 하는지는 정형화되어 있지 않는 것이 현실입니다.
물론 테스트가 가능한 단위가 짧은 완성의 주기라고 정의 할 수 있습니다. 하지만 이것은 저희 프로젝트에는 맞지 않은 정의였습니다. 프로젝트는 출시일이 굳어져 있었고 테스트가 가능한 단위의 짧은 완성은 불가능했습니다. 왜냐하면 전체를 테스트가 가능한 기능 단위로 나누었을때 출시일을 훌쩍 넘어버리는 일정으로 파악 되었기 때문입니다. 즉, 몇 개의 기능을 테스트가 가능한 짧은 완성 주기로 구성한다면 일부의 모습만 완성되기에 전체의 모습을 볼 수 없게 되고 합당한 규모 재산정을 할 수 없음을 의미하는 것이였습니다.
결국 짧은 완성은 “테스트 가능한 기능 단위의 완성”이 아닌 “소비자 입장에서 전체를 파악할 수 있는 수준의 시나리오”라는 목표로 짧은 완성을 정의하여 스프린트를 구성하였습니다.
총 7번의 스프린트로 나뉘어 진행되었고, 평균 50% 정도의 구현이 진행 되었습니다.
그리고 7번의 회고 중 5번의 시연과 2번의 외부 공유를 통해 진행 상황을 가시화 하였습니다. 프로젝트는 지라를 통해 파트별 이슈가 관리되었고, 전체 백로그와 이슈관리는 한 사람이 진행하였습니다. 서로 다른 파트의 이슈를 하나의 현황판으로 관리하고 파트별 스프린트를 어떻게 나누어서 동시 다발적으로 진행했는지에 대한 내용은 이번에 다루는 주제 범위를 넘어서기 때문에 기회가 되면 다음에 다뤄보도록 하겠습니다.
물론 이런 방법으로 나뉘어진 스프린트는 몇가지 우려 사항이 있었습니다.
- 개발자는 본인이 어디까지 구현했는지 기억을 할 수 없기 때문에 나중에 혼란이 더 가중될 것이다.
- 각 기능별 테스트를 할 수 있는 수준이 안되기 때문에 명확한 기능 구현에 소요되는 시간 산정이 불 가능 할 것이다.
하지만 이 두 가지는 뒤에서 설명할 “테스트 케이스 중심 프로세스”를 통해 많은 부분 해결되었습니다. 또한 부족한 일정으로 진행하는 프로젝트에서 출시일을 맞춰서 제품을 출시하는 것에 대해 잠깐 짚고 넘어가야 할 것 같습니다.
부족한 일정으로 진행하는 프로젝트에서 출시일을 맞춰서 제품을 출시하는 것은 많은 사람들의 이해와 설득의 과정을 겪습니다. 이는 프로젝트의 많은 기능들 중에 포기하거나 완벽하지 않은 상태로 출시되는 것을 허용하겠다는 것을 의미하기 때문이죠.
그리고 흔히들 기능의 포기나 완벽하지 않은채로 출시한다는 것을 안일하게 제품을 만들어 출시하겠다는 것과 동일시 합니다. 이 생각은 잘못된 생각입니다.
제품의 출시일이라는 것은 제품을 만드는 것만 영향을 미치는 것이 아니라, 제품과 관련된 마케팅이나 제품과 연동되어 있는 다른 시스템의 영향 그리고 출시일과 맞춰져 있는 사업적 리스크까지 포함하는 일정이기에 결코 단순하지 않습니다. 그렇기 때문에 “제품의 출시가 늦어졌을때 리스크”와 “불완벽한 제품 요소의 리스크”를 비교해서 최선책과 차선책을 결정해야 하는 문제이고 안일함이라는 자세의 문제와는 다른 주제입니다.
주제와는 다소 멀리왔기에 다시 프로세스의 이야기로 돌아오겠습니다. 다음 주제를 들어가기에 앞서 여태까지 내용을 정리해보면 공감을 바탕으로 회색영역을 없애고 이후 짧은 주기의 완성본을 만들면서 스프린트를 진행하는 경험을 공유하였습니다. 그리고 다음은 불 확실하게 구현된 제품을 확실하게 만드는 것을 어떻게 보장할 것인가에 대한 문제를 해결하는 경험을 공유하겠습니다.
테스트 케이스 중심의 프로세스
테스트 케이스 중심의 프로세스라고 말하는 것은 코드 단위 테스트를 작성하는 프로세스를 말하는 것이 아닙니다. 메뉴얼 테스트를 하기위해 작성하는 테스트 케이스 문서를 중심으로 프로세스를 진행하는 것을 말합니다.
어떻게 보면 문서를 중심으로 개발을 하는 것이 시대에 역행하는 듯한 느낌을 받으며, 폭포수 개발 방식을 연상케 하기도 합니다. 하지만 어떤 프로세스든지 절대적인 장점이나 단점을 가지고 있다고 생각하지 않습니다. 이 프로세스는 불확실하게 구현된 제품의 상황과 대략적인 전체 시나리오를 돌아본 프로젝트 상황에서는 최선의 방법이였습니다. 이 프로세스의 가장 중요한 것은 구성원 모두가 테스트 케이스를 가장 중요하게 여기게 만드는 것이였습니다.
앞서 이야기 한 것 처럼 이런 테스트 중심의 프로세스를 TFT 초반부터 적용하지 않았습니다. 전체 구현체가 50% 정도 구현되었을때 이 프로세스를 적용하였습니다.
프로젝트 초기에는 품질책임자의 역할이 명확하지 않았기 때문에 할 일에 대한 규정을 하기가 매우 어려웠습니다. 하지만 품질 책임자는 기획,디자인,개발에서 발견되지 못한 부분의 의견을 이야기하고, 유사 제품을 테스트하면서 일어났던 오류나 정책의 모순점을 개선할 수 있는 방향을 스스로 제안하면서 많은 이들이 이 제안과 가이드에 도움을 받게 됩니다. 그리고 품질책임자가 테스트케이스를 작성함에 있어서 메뉴얼테스트를 하는 담당자를 위한 테스트케이스가 아닌 모두가 보고 활용할 수 있는 테스트 케이스를 만들게 되었고 이는 프로젝트 중반에 위기에 처해있던 프로젝트를 구하는데 큰 도움을 주는 프로세스로 자리매김하게 됩니다.
품질 책임자의 업무에 대해서 좀 더 자세히 이야기 해보면, 품질 책임자는 우선 정책 및 요구사항이 도출되면 이에 대한 검토를 기획자와 함께 진행합니다. 그리고 요구사항들이 디자인 될 시점에도 어김없이 검토를 진행합니다. 이런 검토를 바탕으로 요구사항이 정상적으로 구현되었는지에 대한 체크리스트와 정상이 아닌 예외사항에 대한 체크리스트를 문서화 합니다. 체크리스트는 관련 그룹과의 주기적인 리뷰를 통해 확실한 가이드로 자리를 잡게 만듭니다.
이렇게 완성된 체크리스트는 다음과 같은 효과를 보였습니다.
- 메뉴얼 테스트를 프로젝트 그룹에 속한 누구든지 수행할 수 있습니다. 이는 품질의 안정성을 높이는 결과를 만듭니다.
- 기능의 구현 현황과 상태를 명확하게 파악 할 수 있습니다.
- 개발자가 이 문서를 통해 개발을 진행하면 일부가 미 구현된 상태에서 시간이 지나더라도 다시 그 구현체를 구현하게 될때 불확실성이 크게 줄어들게 됩니다.
결국 테스트 케이스 중심의 개발이 진행되었고, 테스트 케이스를 바탕으로 기획자와 품질 담당자들이 기능의 단위 테스트를 진행 하였습니다.
결국 제품의 출시일을 앞두고 품질 담당자들의 전수 테스트와 알파 테스트의 결과 크리티컬한 이슈나 소소한 버그 수정 이슈 발생률이 적었습니다.
프로세스의 개선은 말로만 하지 말고 행동으로 보여주어야 하며, 끈기있게 물고 늘어져야 한다.
프로젝트는 전수테스트와 알파 테스트를 거치고 안정적으로 출시되었습니다. 수 많은 일들과 에피소드를 남기고 프로젝트는 이제 종료를 앞두고 있습니다.
제품을 만들기 위해 프로젝트는 존재하고 효율적인 프로젝트를 위해 프로세스는 존재합니다. 때로는 프로세스를 위해 프로젝트의 목적을 다른 방향으로 변경하는 상황이 발생합니다. 이것은 특정 프로세스에 매몰되거나 지적 충족을 우선시하는 생각에서 흔히 발생합니다. 이와같은 매몰됨과 편협한 생각은 누구나 할 수 있고 프로젝트의 시작서부터 끝까지 항상 발생하기 때문에 늘 경계해야 합니다.
여기서 다룬 내용을 다시한번 상기 해 보겠습니다. 프로세스 개선이 현업에서 정착 되려면 프로젝트의 상황에 따른 프로세스를 만들어야 한다는 대전제는 변함없어야 합니다. 그리고 서로 다른 파트의 공감대를 형성하는 것, 이들의 업무 중 공간이 발생되는 회색 영역을 최소한으로 만들고, 규모 산정에 오해가 있다면 짧은 주기의 완성본을 이해 관계자에게 제공함으로서 오해를 줄여서 규모 산정을 명확하게 만듦니다. 더불어 테스트 케이스 중심의 프로세스는 매우 안정적인 제품을 출시하는데 도움이 됩니다.
그리고 중요한 요소 중에 하나는 프로세스라는 것을 사람들에게 인지시키려면 순간적인 학습을 통해서 인지시키는 것이 아니라 반복적 실천을 중심으로 자연스럽게 내재화 될 수 있도록 환경과 작은 행동 범위 단위를 만들어 내는 것입니다.
이 글을 읽고 독자분들에게 프로젝트 프로세스에 대한 아이디어가 떠오르길 기대하고 바랍니다.
부족한 글을 끝까지 읽어 주셔서 감사합니다.
