애자일 선언문에서는 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둔다고 명시하고 있다. 그렇다면 문서화따윈 과감히 건너뛰고 바로 코딩부터 하는것이 올바른 것일까?
InfoQ에 이러한 질문에 대해 심도있게 다룬 기사가 올라왔기에 내용을 소개하고자 한다.
모델링을 포함한 문서화는 팀 규모의 확대와 더불어 기하급수적으로 증가하는 커뮤니케이션 비용을 해소하기 위해 매우 중요한 요소이다. 애자일 개발에 있어서 이상적인 설계와 모델링이란 의식공유를 위한 커뮤니케이션의 일부로서의 존재해야 한다. 또한 오버헤드를 제거하기 위해 문서와 코드는 중복된 정보를 다루지 않아야 한다. 코드로 표현 가능한것은 코드로 표현하고, 코드안에 포함되기 어려운 정보들을 문서화의 대상으로 삼아야 한다.
대표적인 애자일 개발 프로세스중 하나인 스크럼 프로세스에서는 특별히 설계에대한 언급이 없다. 그럼 스크럼은 설계가 없이 개발이 이루어지는 것일까?
설계는 모든 소프트웨어 개발에서 끊임없이 이루어진다. 그것이 머리속에서든 화이트보드 상에서든 수백페이지 짜리 문서든지간에 말이다.
문서화는 애자일에 대치 되는가?
애자일 선언에서는 대화(커뮤니케이션)가 문서화보다 가치 있다고 명시하고 있다. 이상적인 문서화는 이러한 커뮤니케이션의 토대가 될 수 있어야 한다. 개개인의 머리속에 존재하는 개념들을 공유하는데 도움이 되어야 한다. 그리고 그러한 공유를 위해 가장 효과적인 방법이 바로 모델링이다.
UML로 대표되는모델링은 문장만으로 구성 할 수 없는 많은 정보들을 알기쉽고 간략하게 표현 할 수 있게 해 준다. 설계서의 목적은 커뮤니케이션의 토대가 되는것이지 납품 명세서의 목록을 채우기 형식적인 작업이 되어서는 안된다.
모델은 프로젝트 기간동안 지속적으로 갱신이 이루어지는 "유지모델"과 커뮤니케이션을 지원하기 위해 임시적으로 사용되는 "임시모델"로 나누어 관리 한다. "유지모델"은 프로젝트의 진행과 더불어 축척된 지식을 피드백하여 끊임없이 업데이트 되어야 하며, 화이트보드위에 그려진 클래스 다이어그램과 같이 그때 그때의 커뮤니케이션을 위해 작성되는 "임시모델"은
목적(그때 그때의 팀원간의 의식공유)이 달성에만 사용한다.
저자인 히라나베 캔지씨는 다음과 같은 세가지 형태의 모델을 유지모델로서 제안하고 있다.
- 팀이 전체 시스템 구조의 개략적 인 아이디어를 얻기위한 시스템 " 아키텍처 "
- 팀이 문제 도메인에서 사용되는 개념의 이해를 도와 줄 " 도메인 모델 "
- 시스템의 일반 사용자를 이해하고 그들이 시스템에서 유용함을 얻는 방법에 대한 " 키 유즈 케이스 "
이 기사에서는 또한 팀의 규모확대와 더불어 어떻게 모델을 기반으로한 커뮤니케이션 프레임웍을 확대해 나가는지에 대해 매우 구체적으로 설명하고 있다.
간단히 요약하자면 타이거팀이라고 하는 이른바 초기 맴버들을 중심으로 전체적인 밑그림을 그리고 이 타이거팀의 맴버들이 주축이 되어 각 서브팀으로 설계에 대한 의식공유를 이끌어 나간다. 이때 중요한것은 서브팀에서 구체화된 모델은 다시 타이거팀으로 피드백하여 유지모델을 지속적으로 업데이트 해 나간다는 점이다.
저자는 설계의 의도와 이해를 공유하는데 유용한 팁으로 모델링 워크샾을 필요한 만큼 충분히 열고 벽이에 유지모델을 인쇄해 걸어놓고(또는 화이트보드에 프로젝트로 모델을 영사해 놓고) 그 모델위에 필기로 지식을 추가해 나가는 것을 추천하고 있다.
간단히 요약하자면 타이거팀이라고 하는 이른바 초기 맴버들을 중심으로 전체적인 밑그림을 그리고 이 타이거팀의 맴버들이 주축이 되어 각 서브팀으로 설계에 대한 의식공유를 이끌어 나간다. 이때 중요한것은 서브팀에서 구체화된 모델은 다시 타이거팀으로 피드백하여 유지모델을 지속적으로 업데이트 해 나간다는 점이다.
저자는 설계의 의도와 이해를 공유하는데 유용한 팁으로 모델링 워크샾을 필요한 만큼 충분히 열고 벽이에 유지모델을 인쇄해 걸어놓고(또는 화이트보드에 프로젝트로 모델을 영사해 놓고) 그 모델위에 필기로 지식을 추가해 나가는 것을 추천하고 있다.
마지막으로 모델링에 대한 지식을 효과적으로 전파하는 데에는 사람에서 사람으로 지식을 전달해 나가야 한다. 단순히 문서만을 서브팀에 전달해서는 효율도 낮을 뿐더러 설계 의도가 충분히 전달되지 않는 경우가 많다. 가장 이상적인 방법은 타이거팀의 맴버가 서브팀의 일원이 되어 함께 코드작업까지 진행하며 모델과 아키텍쳐 지식을 전달하는 것 이다.
저자는 기사 말미에 모델링에 대해서 몇가지 유용한 팁을 제안하고 있다.
모쪼록 시간을 내서라도 꼭 원문을 읽어두길 바라며 영어에 대한 압박을 느끼는 분이라면 일본어판의 구글 번역 링크를 참고하기 바란다.(매끄럽지는 않지만 내용을 이해하는데 큰 문제는 없을것이다.)
전술 한 아이디어와 경험을 바탕으로 당신의 일일 모델링 작업 또는 모델링 워크숍에서 사용할 수있는 몇 가지 팁을 여기에 소개합니다.
- 리버스 및 모델 : 많은 UML 도구는 저스트 인 타임 방식으로 코드를 시각화하는 "리버스 엔지니어링"기능을 제공하며 일부 툴은 로컬 소스코드에서 리버스 하는 기능 뿐만 아니라 Github 저장소에서 소스를 직접 읽어오는 기능도 가지고 있습니다.
- 인쇄 및 필기 : 위에서 언급 한 것처럼 좋은 인터랙티브 모델링 워크숍은 벽 (또는 테이블)에 붙인 커다란 종이 사용하여 팀원들과 상호 작용을함으로써 촉진됩니다. 인쇄 한 큰 종이에 직접 내용과 의견을 써주세요.
- 화이트 보드에 프로젝터를 비추고 직접 작성 : 워크샵에서 사용할 수있는 또 다른 모델링 공유 방법은 화이트 보드에 비친 영상에 대해 직접 필기를 하는 것 입니다. 프로젝트에서 화이트 보드에 "유지 모델"을 비추고 그 위에 코멘트 또는 내용을 직접 씁니다.
- 회고 : 나는 "유지 모델"간단한 버전을 제안했지만, 그것은 당신의 문제에는 맞지 않을지도 모릅니다. 그래서 처음에는 나의 제안 또는 당신이 생각한 간단한 "유지 모델"에서 시작하십시오. 그리고 각 스프린트마다 당신의 모델에 대해 회고하고, 어떤 모델이 잘 움직이고 있는지, 어떤 모델이 필요한지 또는 필요없는 것인지에 대해 검토합니다. 당신만의 "유지 모델"을 찾아 내십시오.
- 마인드 맵 모델링 : UML 및 기타 소프트웨어 엔지니어링 다이어그램은 사용자와 토론, 계획, 그리고 기타 여러가지 경우에 생각처럼 잘 작동하지 않지만, 시도 자체는 중요한 의미를 지닙니다. UML과 더불어 마인드맵을 만들어 사용하십시오. "Mind Map과 UML을 사용한 애자일 모델링"대한 자세한 내용은 사용자와 함께 만든 "사용자 스토리 탐구"샘플 을 참조하십시오.
끝으로 애자일 모델링에 대해 업계의 거장인 Martin Fowler씨와 Jack Reeves씨의 명문을 소개합니다.
- Martin Fowler, 2004, "Is Design Dead?"
- Martin Fowler, 1997, "The Almighty Thud"
- Jack Reeves 1992 "What is Software Design?"
애자일 모델링의 개념은 "Agile Modeling"책에서 처음 설명되어 있습니다. 그리고 "실천 UML"제 3 판에서 다시이 주제를 다룹니다.모델링 워크숍 아이디어는 주로 Craig Larman과 Bas Vodde 책에서 영감을 받았습니다.
- Craig Larman and Bas Vodde, 2010, "Practices for Scaling Lean & Agile Development"
- 아래 내용은 다운로드 할 수 있습니다 Chapter 8 from "Practices for Scaling Lean & Agile Development : Large, Multisite, and Offshore Product Development with Large-Scale Scrum"
"유지 모델"과 "임시 모델"아이디어는 여기서 가지고 왔습니다.같은 문제를 다루고있는 또 다른 InfoQ 기사입니다. 아직 2 부를 계속 기다리고 있습니다.민첩한 개발 및 아키텍처에 대해 더 넓게 다루고있는 기사
모쪼록 시간을 내서라도 꼭 원문을 읽어두길 바라며 영어에 대한 압박을 느끼는 분이라면 일본어판의 구글 번역 링크를 참고하기 바란다.(매끄럽지는 않지만 내용을 이해하는데 큰 문제는 없을것이다.)
일본어판 InfoQ 기사 구글번역 링크
민첩한 시대의 모델링 : Agile 팀 확대를 위해 코드의 다음에 무엇을 유지해야 하는가이 글을 쓴 히라나베 캔지씨는 UML, ERM, Mindmap과 리버스엔지니어링을 지원하는 소프트웨어 디자인 툴인 Astah를 만든 Change Vision社의 CEO이다. Astah는 뛰어난 기능과 합리적인 가격으로 일본에서는 이미 보편적인 설계툴 로 자리잡은지 오래이다. 만약 무상으로 사용 가능한 UML설계툴을 알아보고 있다면 Astah Community를 고려해 볼 것 을 추천한다.
댓글 없음:
댓글 쓰기