Agile Korea Conference 2018 'Agile Transformation 을 위한 기업들의 노력'

백미진 님께서 번역하신 User Story Mapping – Written by Jeff Patton 소개 모습

이번 세션의 경우, S프로젝트라는 구체적인 예시를 가지고 진행했던 세션이었습니다. 대규모 프로젝트라는 상황하에서 직접 PM을 하시면서 겪었던 과정을 경험기반 사례와 Lessons & Learned 로 진행하셔서 강연 내용을 쉽게 이해할 수 있었습니다. 강연의 시작은 참가자들의 프로젝트 속 담당업무 분포를 가볍게 확인해 보고, 다같이 “땅콩버터 샌드위치 제조방법 작성 실험” 동영상을 보았습니다.

땅콩버터 샌드위치 제조방법 작성 실험

요구사항 정의의 어려움에 대한 예시로 동영상 (https://youtu.be/cDA3_5982h8)을 보여주었습니다. 내용은 아빠가 딸, 아들에게 “땅콩버터 샌드위치 만드는 설명서(Instruction)를 작성해 주세요.” 라고 요구사항을 전달했고, 딸과 아들이 각자 땅콩버터 샌드위치 만드는 설명서(Instruction)를 작성해 왔습니다. 아이들이 가져온 설명서대로 아빠가 땅콩버터 샌드위치를 직접 만들어 보는 실험이었습니다. 결론은 우측 사진처럼 엉뚱한 결과물이 나왔습니다. 백미진 님은 동영상을 통해 요구사항 정의가 얼마나 어려운지를 전달하고자 한 것 같습니다. 특히 요구사항을 『문서(글)로 표현하는 것에 대한 어려움』을 설명하셨는데, 사람마다 경험, 백그라운드, 사고 방식 등이 모두 다르기 때문에 각자 표현하는 방법, 받아들이는 방법이 다르고, 따라서 많은 사람들이 문서만을 보고, 거기에 표현된 요구사항의 목표를 공통적으로 인식하기가 어렵다는 것을 설명해 주셨습니다.

세션 참가자들의 Pain Point 사전 정의 - Persona기반

백미진 님은 강연 진행의 효과를 높이기 위해, 강연에 앞서 세션참가자들의 페르소나(Persona)를 선정하고, 그들의 페인-포인트(Pain Point)와 프로젝트 상황까지 설정을 하였습니다. 강연 시작 전에 타겟(Target)을 정하여 시작함으로써 강연 진행의 중심을 잡아갈 수 있었고, 청중들의 눈높이를 맞추고, 집중도를 높였다고 생각합니다.

프로젝트 상황

(사전 주어진 정보는 아래와 같음)

S Project 정보
- 인원: 상근 20명, 비상근 140명 (대략적인 인원)
- 기간: 2년 (연구소 선행 개발)
- 특징
   1. 프로토타입 프로젝트가 작년에 있었고, 그 멤버 중 일부가 상근 멤버에 포함됨.
(즉, 경험인력이 전체 프로젝트 인력 대비 적음.)
   2. 대규모 프로젝트
   3. 하드웨어 포함
   4. Cross-Functional Team (요구사항 ~ 테스트 까지 프로젝트 팀에서 모두 진행 가능)

인셉션 단계

인셉션 단계의 경우, 아래와 같이 진행을 하였다고 합니다.

인셉션 워크샵
1. S 프로젝트 전체 목표설정하기
2. 전체 목표 달성을 위한 각 파트별 목표 설정하기

S프로젝트는 규모가 컸었던 만큼 먼저 프로젝트의 큰 그림에 대해서 전체 구성원들의 눈높이를 맞추는 워크샵을 진행했습니다. 워크샵 진행을 통해 상근 멤버 20명과 비상근 멤버 140명이 같은 눈높이, 같은 출발선 상에서 프로젝트를 진행할 수 있게 되었다고 합니다. 그리고, 총 프로젝트 기간 2년이었기 때문에 1년을 상반기, 하반기로 나누어 총 4번으로 세분화(Breakdown)하여, 반기(6개월)별로 일주일짜리 워크샵을 진행했다고 합니다. 사실 SI 프로젝트의 경우, 일주일이라면 많은 업무를 진행할 수 있는 기간으로 매우 귀중한 시간입니다. 그럼에도 PM의 입장에서 160여명의 인력이 하나의 목표를 가지고 갈 수 있는 것이 더 중요하다고 생각했고, 프로젝트의 성공을 위해서 이 시간이 결코 아깝지 않았다고 합니다.
위의 Persona에서 보시면 아시겠지만, 프로젝트 시작단계에서 구성원들(PL, 스크럼마스터, 개발자) 각자 다른 생각을 가지고 있었는데, 이러한 과정을 통해서 구성원 모두가 “너와 나"가 아닌, “우리" 즉, 강연 제목처럼 “네 프로젝트가 내 프로젝트가 되는 여정”이 되어간다고 필자는 생각했습니다. 특히, 워크샵을 진행할 때에는 상근/비상근으로 프로젝트 구성원들이 떨어져 있다고 하여 온라인으로 진행하는 것보다 오프라인으로 진행하는 것이 효과가 높다고 하셨습니다.

마일스톤 플래닝 단계

프로젝트의 마일스톤은 MVP → 기본기능(Must have) → 있으면 좋을 것(Nice to have)를 기준으로 나누었고, MVP(Minimum Valuable/Viable Product)에 대한 설명을 자동차가 만들어지기 전에 스케이트보드, 킥보드가 탄생했던 과정을 “헨릭 크니버그(Henrik kniberg)"의 그림을 보면서 설명을 해 주셨습니다.
또한, 요구사항에 대한 해석의 기준이 역할자, 지역별(상근/비상근), 개인생각 등 모두 다르기 때문에 하나로 합쳐지는 과정이 매우 중요하고, 이 과정을 위해서 유저스토리의 중요성도 함께 언급해 주셨습니다.

* [참고] 유저스토리란
- 제품의 기능을 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것
- 특징
1. 제품 기능에 대한 설명을 설계/개발자의 입장이 아닌 그 제품을 사용하는 사용자(또는 고객)관점에서 서술해야 함
2. 해당 기능이 구현되었을 때, 사용자에게 어떤 가치(Value)를 주는지에 대한 명확한 설명도 있어야 함
3. 완료에 대한 조건이 명확하게 제시되어야 함

- 효과
1. 기능명세 위주가 아닌 사용자의 행동을 위주로 서술하기 때문에 이해하기 쉬움
2. 유저 스토리간 우선순위 선정 시, 사용자가치가 최우선이 되어 의사결정의 기준이 됨

프로젝트 진행과정 - 오프라인 Wall-Board

대규모 프로젝트였던 만큼 프로젝트 관리 툴로 Jira 와 Confluence 를 사용하였지만, 프로젝트 현장에는 팀원 전체가 함께 볼 수 있는 보드(위 사진)를 마련해두어 프로젝트의 진행상태를 공유했다고 합니다. 오프라인 Wall-Board를 소통의 수단으로 활용하라는 조언을 아끼지 않았습니다.

S프로젝트의 Lesson & Learned

1. 고정된 팀
- 전체 팀원이 목표를 공감하는 것이 중요
2. 오프라인 월보드(Wall Board)
- 온라인 보드(Jira, Confluence) 외에 오프라인은 팀원이 바로 확인 가능하여 효과가 좋음
3. 솔루션을 만드는 사람들만 알 수 있는 것
- 요구사항이 구현될 때의 개선포인트, Value 도출이 중요
4. 숲과 나무를 한 번에
- 요구사항을 쪼개기(Epic – Story)
- Visualization: 진행 사항(시작/끝)이 보여야 함
5. 2주 스프린트
- 리듬
- 약속(Commitment): 할 일을 스스로 계획 & 완료해야 함(만약, 못하면, 동료/프로젝트에 피해)
- 데모의 중요성

마무리: 네 프로젝트가 내 프로젝트가 되기 위한 필수요건들

강연을 마무리하시면서 모든 것에 대한 왕도, 100% 해결책은 없다고 강조하셨습니다. 프로젝트가 성공하기 위해서는 “네 프로젝트, 내 프로젝트"로 나누어지는 것이 아닌 “우리 = 네 = 내" 가 되어야 하고, 이를 위해서는 위의 사진에서 보듯이 “투명하게 드러내기", “커뮤니케이션(소통)”, “도움이 필요한 곳이 없는지 자주 들여다보기" 의 활동이 필요하다고 강조해 주셨습니다. 또한, 프로젝트는 개발만이 전체가 아니고, 매니지먼트(Management)를 어떻게 잘 해야 하는지에 대한 부분을 언급해주시며 강연을 마쳤습니다.

삼성SDS에서 애자일을 10년동안 하고 있는 신황규 님의 강연은 “대기업에서의 애자일 전환(Agile Transformation)이란” 주제로 시작되었습니다. 기존에 있던 도시 전체를 바꾸는 것과 비교를 해주시며, 대기업에서의 애자일전환은 너무나 어려운 일이라는 것을 설명해 주셨죠. 예를 들어 도시재개발의 경우, 도시의 건물들을 모두 없애고, 교통/정비/기반시설부터 구축하고, 이후 신도시로 바뀌게 되는 과정을 거치게 됩니다. 이 과정 중 특히, 기존도시 철거과정에서 ‘철거를 반대하는 집단들과의 갈등을 풀어가는 것’이 가장 어려운데, 대기업에서의 애자일 전환이라는 과정이 이와 유사한 단계라고 하셨죠.

전세계 애자일 적용기업의 분포

이 화면을 보면서 필자가 느꼈던 것은 한국에서의 애자일을 적용하는 기업이 소수에 불과하다는 것을 한눈에 알 수 있었습니다. 눈여겨볼 사실은 전세계적으로는 아시아권이 애자일 적용이 적은 편인데, ‘중국/일본’은 같은 아시아권임에도 애자일을 도입하는 회사/사람들이 많다는 점이었습니다. 절대적인 비교 기준은 될 수 없지만, CSM(Certified Scrum Master) 및 CSP(Certified Scrum Professional) 의 숫자도 중국, 일본의 경우 한국과 비교했을 때, 월등히 높습니다. 인구수를 무시할 수 없는 부분이지만 애자일코치 활동을 하는 필자로써는 주변국들의 동향에 경각심을 느끼게 되었습니다.

애자일 전환 방식

Key Note 에서 Ahmed Sidky가 말했던 것처럼 애자일 전환 대상이 5가지(Leadership, Strategy, Structure, Process, People)가 있다고 하셨습니다. 전환방식은 위의 사진처럼 Process-Led, Culture-Led, Team-Led 3가지가 있는데, 신황규 님도 최초에 애자일 전환을 시도할 때에는 좌측 그림과 같이 “Process”를 먼저 변경하는 시도를 했었다고 합니다. 또한, 당시에 애자일 프로세스를 삼성SDS의 개발방법론 등에 적용하면서 삼성SDS에 서서히 퍼져 나갔다고 합니다.

현재 삼성SDS의 애자일 전환 방식은 Team-Led Transformation 방법인데, 실리콘밸리에서 개발 경험이 있는 인력들이 디자인 씽킹 / 린 / 애자일 개발 방법으로 솔루션을 만들어 가면서 다른 팀에 영향을 주는 방식이라고 합니다. 이 팀의 인력들은 애자일 마인드셋에 대한 트레이닝도 받고, 실제로 제품도 개발하면서 팀 자체가 애자일 전환이 되었다고 합니다. 바로 이 팀이 ACT그룹(Agile Core Team)입니다. ACT그룹은 다른 팀에 영향(Bubble)을 주었고, 좋은 영향을 받아 조직의 변화(Transformation)가 이루어지게 되는 효과가 있다고 설명을 해 주셨습니다. 또한, ACT그룹과 같은 조직이 구성되기 위해서는 강한 스폰서도 필요했다고 합니다. 즉, 조직적인 전환을 위해서는 하나의 팀의 노력뿐만 아니라 경영진의 강한 Leadership이 없었다면, ACT라는 팀이 탄생하지 못할 수도 있었을 것이라고 이야기했습니다.

애자일 전환 10년의 스토리

삼성SDS의 애자일 역사는 ‘06년도부터 시작이 되었다고 합니다. 그 당시 아무것도 없는 상태에서 PM(Project Manager)들로부터 애자일에 대한 신뢰를 얻을 수 있었고, 그로 인해 ‘07년에 몇몇 개발자들이 XP프랙티스 활용하여 개발하면서 애자일을 하는 인력들이 조금씩 늘어나기 시작했다고 합니다. ‘08년도에는 작은 조직에 Scrum기법 적용하기 시작했고, ‘09년도에는 대형 프로젝트에 애자일을 적용하여 진행하기에 이르렀습니다.
위의 사진에서처럼 ‘10년에는 전사적으로 애자일 전환을 하기 위해 SDS 사내 방법론에도 애자일방법론(SDS Generic Agile)이 제정되었습니다. 방법론이 제정되었다고 해서 SDS 가 애자일 전환이 되었다는 것은 아니고, 이러한 과정 하나하나를 진행해 나가는 것이 삼성SDS의 애자일이라고 강조하셨습니다.
이것이 끝이 아니고, 매년 애자일 전파를 위하여 애자일 에반젤리스트 양성, 교육, 문화 전파, 기획-개발 간의 원활한 소통을 위하여 User Story 기반 요구사항 정의 등의 과정을 만들어가고 있습니다. SDS는 긴 여정으로 인하여 조금씩 애자일 회사로 전환을 하고 있다고 설명하셨습니다. 또한, ‘18년에도 전사의 애자일 전환(Agile Transformation)을 위하여 지속적인 노력을 하고 있다고 합니다.

현재 ACT(Agile Core Team)가 하는 업무 영역

중요한 것은 격변하는 시대적인 흐름에 삼성SDS가 경쟁력 향상을 위해서는 회사의 모든 조직들이 지속적인 개선에 대한 공감하고 있으며, 이를 위해 회사가 다방면의 노력을 하고 있기 때문에 “삼성SDS는 애자일을 하는 회사” 라는 말씀을 하시면서 강연을 마무리하였습니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.