티켓 주도 개발(ticket-driven development; TiDD)

이번 포스팅은 위키피디아 일본어판의  티켓 주도 개발 설명에 기초하여 작성되었음을 밝혀둔다.

티켓 주도 개발이란?

티켓 주도 개발(ticket-driven development; TiDD)이란 일본발 소프트웨어 개발 방식중 하나로 개발 과정 발생하는 테스크를 분할한 후에 이를 Track, Redmine과 같은 이슈 트래킹 시스템에 등록하여 관리해 나가는 개발 스타일을 지칭한다.  WBS(Working Breakdown Structure)를 기반으로 하는 기존의 폭포수 개발방식은 물론이고 XP나Scrum, Kanban과 같은 애자일 개발과도 궁합이 좋다.  같은 이니셜을 지니게 되는 테스트 주도 개발(TDD)과 구분하여 TiDD라는 약칭을 사용한다.

프로젝트 룰

기본적으로 티켓 주도 개발에 있어서 룰은 단 한가지다.

No Ticket, No Commit! (티켓 없이는 커밋도 없다!)

Subversion이나 Git를 이용하는 형상관리상, 커밋이란 개인이 관리하는 소스가 공동관리하에 들어간다는 것을 의미한다.  룰은 단순하지만 이슈트래커에 모든 테스크가 관리됨에 따라 개개인의 작업에 대한 파악이 간편해지고 성과물의 갱신이 반드시 티켓과 연관지어지게 됨에 따라 변경이유가 명확해지는것이 이 티켓 주도 개발의 매리트이다.

개발 사이클

티켓 주도 개발은 일반적으로 다음과 같은 PDCA(Plan/Do/Check/Action)사이클의 반복이다.

• 큰규모의 릴리즈 계획을 작성한다
• 작업을 작은 단위의 테스크로 분할하여 이슈 트래커에 등록한다.(티켓 등록)
• 이터레이션 단위로 테스크를 모아 이터레이셔계획을 작성한다.
• 테스크를 선택하여 실시한다.
• 결과물을 커밋하고 종료한다.(티켓 클로즈)
• 이터레이션에 포함된 모든 테스크가 종료되면 릴리즈를 실시한다.
• 릴리즈후에 작업에 대한 회고를 진행한다. 
• 다음 이터레이션계획에 고객의 요구사항과 회고의 내용을 반영한다.

이점

티켓 주도 개발의 이점은 다음과 같다.

• 언제나 누구든지 티켓을 참조하는것이 가능해져, 커뮤니케이션이 쉬워진다.
• 돌발적인 테스크 변경에도 티켓 속성의변경이 간단하므로 변화대응이 쉽다.
• 이터레이션 작업량을 일정하게 하는것으로 작업의 리듬을 만들어 나갈 수 있다.
• 티켓을 이터레이션 단위로 관리해 나가기 때문에,  빈번한 릴리즈를 가능하게 한다.
• 티켓이 소스코드,요건,테스트케이스와 연관지어지므로 상호 추적이 가능해진다.
• 이러한 티켓중심의 워크플로는 버그관리뿐만 아니라 요건관리를 포함해 소프트웨어 개발 전 과정에서 응용 가능하다.  
• 진척관리면에서 모든 작업 진행상황이 투명해 지므로 프로젝트 현황의 파악이 대단히 용이해진다.

성공을 위한 팁

끝으로 필자가 티켓 주도 개발에 참여하며 느낀점을 간단히 정리해 보았다.

• 무엇보다 팀원 개개인이 프로젝트의 주체로서 능동적으로 행동해 나간다는 의식이 TiDD 성공의 열쇠이다. 역으로 티켓 주도 개발의 큰 장점중 하나는 이러한 의식을 뿌리 내리게 하는데 도움을 준다는 점이다. 처음 도입시에는 여러가지 어려움이 많으므로 적절한 외부 코칭이나 기존에 시행하고 있는 팀과의 노하우 공유가 큰 도움이 된다.
• 티켓의 할당은 개개인이 선택하는것이 바람직하며 데일리 미팅등을 통해 팀원들과 진척사항을 공유해 나가야 한다. 
• 형상관리 시스템에 커밋시 특정 형식에 맞추어 번호를 기입하는 것 만으로도 이슈트래커가 티켓과 소스의 링크를 자동 생성해 주는 기능을 이용한다.

          Trac Links
          Redmine의 Subversion연동설정

• 최초 티켓 등록은 PM이나 팀 리더에 의해 이루어지 지지만 테스크 진행 결과 서브 테스크 분할이나 후속작업등이 필요하게 되는 경우에는 추가로 티켓을 발행한다.
• 티켓 분할은 일단위 작업이 될때까지 진행하는것을 권장한다.
• 타임 박싱 관리기법에 의해 릴리스 시기에 맞추지 못하게 된 우선순위가 낮은 티켓은 다음 릴리스로 이관한다.
• 이슈 트래커 툴의 선택에 있어서는 Trac과 Redmine을 추천하며 특히 Redmine의 경우 티켓간의 관계설정(전/후,부모/자식)이나 상태전이를 커스터마이징등의 기능들이 기본제공된다.
• 작업자들은 리팩터링이나 테스트케이스의 추가를 능동적으로 판단하여 티켓에 등록할 수 있어야 하고 PM과 우선순위와 일정등을 협의한다. (기술적 채무 관리에 크게 도움이 된다.)
• 프로젝트 관계자간에 적절한 정보공유와 커뮤니케이션이 이루어 질 수 있도록 위키와 게시판등을 병행하여 사용한다. 일반적으로 메일을 사용하는 경향이 있는데, 메일의 경우 보관이나 업데이트의 면에서 유지모델을 다루기엔 부적합하다. 
• Redmine의 경우 커뮤니케이션과 관련하여 풍부한 기능을 제공하고 있는데 모두 사용할 필요는 없다. 프로젝트의 규모와 성격, 팀 구성에 따라 적절하게 선택하여 사용한다.
• 태생이 일본이다 보니 TiDD와 관련된 노하우는 일본어로 된 정보가 풍부하다. 구글 번역기등을 이용하면 여러가지 실천적 노하우를 쉽게 찾아 볼 수 있다.

TiDD는 일본에서 다양한 소프트웨어 개발 프로젝트의 관리기법으로 선호되고 있으며 특히 빠른 릴리즈를 선호하는 모바일 어플리케이션 개발의 경우 보편적으로 사용되고 있다.

주석(comment)을 달지 말아야 하는 이유

일전에 애자일 개발에서의 문서화 작업에 대한 블로깅에서도 밝힌바와 같이 도큐멘테이션은 프로젝트의 목적(납품물)이 아닌 커뮤니케이션을 위한 수단이 되어야 한다. 올바른 문서화을 위한 원칙을 다시한번 간략히 살펴보자.

정보의 중복 금지: 같은 내용을 여러군데 적지 말라. 쓸데없는 노력이 들어갈 뿐만 아니라 결국에는 서로 다른 내용을 지닌 문서/코드를 보게될 것이다. 

코드에 포함 가능한 정보는 코드에 포함하라: 동일한 내용이 여러 장소에 적힐 수 있다면 코드가 우선시 되어야 한다. 코드에 표현하기 어려운 정보라면 그 다음 순위는 유지모델이 될 것이다.

라이프 사이클을 구분하여 사용하라: 프로젝트 내내 지속적으로 유지해야만 하는 유지모델과 특정 단계에서만 구성원들의 의식 통일을 위해 사용하는 임시모델을 구분하여 사용한다. 아키텍처 정의나 ER다이어그램과 같은 문서는 프로젝트가 끝난 후라 할 지라도 유지보수를 위해 여전히 유용한 반면, 특정 기능 구현을 위한 시퀀스 다이어그램이나 클래스 다이어그램과 같은 임시 모델은 회의를 진행하면서 화이트보드에 적은 내용을 디지털사진으로 남기는 것 만으로도 충분한 경우가 많다. 

주석을 달지 말아야 하는 이유

코드에 주석을 달지 말아야 하는 이유는 정보의 중복을 피하기 위해서입니다. 주석을 열심히 달기 보다는 읽기쉬운 코드를 만든는데 집중하세요. 메소드 내의 처리를 단일 기능 단위로 분할 하고 하고 각종 네이밍에 주의를 기울이십시오. 프로그램 사양에 대한 기술은 코드의 주석보다는 테스트 케이스의 Javadoc에 기대하는 동작을 기술하세요. 이렇게 작성된 Javadoc은 그 자체로서 훌륭한 상세설계서가 됩니다. - 나가사토(나가사토씨는 필자와 같은 Mamezou소속의 애자일 컨설턴트 이며 Disciplined Agile의 일본어판 번역을 비롯해 다수의 기술서적을 번역하였다.)

필자는 사실 테스트케이스의 Javadoc조차도 최소한의 내용만을 적는것이 좋다고 생각한다. 테스트 코드도 실행코드와 마찬가지로 코드 자체의 가독성을 최대화 하는것에 집중하는것이 좋다고 생각하기 때문이다.

잘 작성된 주석은 프로그램의 가독성을 매우 향상시킬 수 있는 반면, 잘못 작성된 주석은 프로그램의 가독성을 해칠 수 있다. 

코드 컴플리트(스티브 맥코넬, 2005)

주석을 달지 않는 코딩 유형은 자바의 코어 라이브러리 소스 코드를 비롯해 대부분의 오픈소스 코드에서 쉽게 확인 할 수 있다.

예제1) 스프링 소스코드

     @Override  
     public void initialize(  
             Servlet servlet, ServletRequest request, ServletResponse response,  
             String errorPageURL, boolean needsSession, int bufferSize, boolean autoFlush) {  
         throw new UnsupportedOperationException("Use appropriate constructor");  
     }  
     @Override  
     public void release() {  
     }  
     @Override  
     public void setAttribute(String name, Object value) {  
         Assert.notNull(name, "Attribute name must not be null");  
         if (value != null) {  
             this.attributes.put(name, value);  
         }  
         else {  
             this.attributes.remove(name);  
         }  
     }  
     @Override  
     public void setAttribute(String name, Object value, int scope) {  
         Assert.notNull(name, "Attribute name must not be null");  
         switch (scope) {  
             case PAGE_SCOPE:  
                 setAttribute(name, value);  
                 break;  
             case REQUEST_SCOPE:  
                 this.request.setAttribute(name, value);  
                 break;  
             case SESSION_SCOPE:  
                 this.request.getSession().setAttribute(name, value);  
                 break;  
             case APPLICATION_SCOPE:  
                 this.servletContext.setAttribute(name, value);  
                 break;  
             default:  
                 throw new IllegalArgumentException("Invalid scope: " + scope);  
         }  
     }  

예제로 제시한 코드는 주석이 필요 없을정도로 간결하다. 이번엔 테스트코드를 살펴보자.

예제2) 테스트코드

 /**  
  * Unit tests for the {@code MockPageContext} class.  
  *  
  * @author Rick Evans  
  */  
 public final class MockPageContextTests extends TestCase {  
     public void testSetAttributeWithNoScopeUsesPageScope() throws Exception {  
         String key = "foo";  
         String value = "bar";  
         MockPageContext ctx = new MockPageContext();  
         ctx.setAttribute(key, value);  
         assertEquals(value, ctx.getAttribute(key, PageContext.PAGE_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.APPLICATION_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.REQUEST_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.SESSION_SCOPE));  
     }  
     public void testRemoveAttributeWithNoScopeSpecifiedRemovesValueFromAllScopes() throws Exception {  
         String key = "foo";  
         String value = "bar";  
         MockPageContext ctx = new MockPageContext();  
         ctx.setAttribute(key, value, PageContext.APPLICATION_SCOPE);  
         ctx.removeAttribute(key);  
         assertNull(ctx.getAttribute(key, PageContext.PAGE_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.APPLICATION_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.REQUEST_SCOPE));  
         assertNull(ctx.getAttribute(key, PageContext.SESSION_SCOPE));  
     }  
 }  

테스트 코드 역시 매우 간결한 모습을 띄고 있다.
코드의 가독석을 높이는 가장 좋은 방법은 코드를 심플하게 유지 하면서 네이밍, 특히 변수의 네이밍에 신경을 써 주는것이 효과적이다.

변수명과 네이밍에 대한 내용은 코드 컴플리트에서 더할나위 없이 훌륭하게 다루어지고 있으므로 아직 읽어보지 않은 분이라면 꼭 읽어들 것을 추천한다.

젠킨스(Jenkins)를 이용한 지속적 통합(CI:Continuous Integration) (2) - 젠킨스씨가 있는 개발풍경

젠킨스(Jenkins)를 이용한 지속적 통합(CI:Continuous Integration)

(1) 미스터 젠킨스씨를 소개합니다

(2) 젠킨스씨가 있는 개발풍경

젠킨스에 대한 두번째 포스팅으로 오늘은 젠킨스가 실제 프로젝트에서 어떤 형태로 사용될 수 있는지 살펴 보고자 한다.

젠킨스씨가 있는 개발풍경

하루 24시간이 모자르신 젠킨스씨

형상관리 툴과의 연동

젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적 이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모두 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었는데 이를 nightly-build라 한다. Fire Fox와 같은 많은 오픈소스 프로젝트들은 정식 배포 버전과 별도로 nightly-build에서 생성된 바이너리를  함께 배포함으로서 오픈 베타테스트 또한 지속적으로 수행 할 수 있게  되었다.

젠킨스는 정기적인 빌드에서 한반 나아가 서브버전, Git와 같은 버전관리 툴과 연동하여 소스의 커밋을 감지하면 자동적으로  자동화 테스트가 포함된 빌드가 작동되도록 설정 할 수 있다.

Subversion Plugin   

Git Plugin

물론 개발도중의 프로젝트에서 커밋은 매우 빈번히 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라  큐잉되어 자신이 실행될 차례를 기다리게 된다.

코드의 변경과 함께 이뤄지는 이같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.

• 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
• 자동화 테스트 수행
• 정적 코드 분석에 의한 코딩 규약 준수여부 체크
• 프로파일링 툴을 이용한 소스 변경에 따른 성능변화 감시
• 결합 테스트 환경에대한 배포작업

이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이선과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.

각종 배치 작업의 간략화 

프로젝트 기간중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, 디플로이 작업과 같은 단순 작업에 시간과 노력을 빼았기는 경우가 빈번하다.
데이터베이스의 구축, 어플리케이션 서버에의 디플로이,  라이브러리 릴리즈와 같이 이전에 커맨드 라인 인터페이스로 실행되던 작업들이 젠킨스 덕분에 미려한 웹인터페이스로 손쉽게 가능해 지게 되었다.

젠킨스씨는 거들뿐

이와같이 다양한 작업들을 손쉽게 처리해 주지만 테스트를 만들고 빌드 전략을 세우는 등의 작업은 여전히 개발자의 몫으로 남아 있다. 젠킨스가 진정으로 프로젝트에 도움이 되기 위해서는 다음과 같은 작업이 반드시 함께 이루어 져야 한다.

Build 자동화의 확립: 빌드 툴의 경우 Java는 이미 Maven이 대세로 자리잡았다. 물론 Ant도 훌륭한 기능들을 많이 갖추고 있지만 플러그인의 편리함은 Maven을 따라잡지 못한다. 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 Jenkins를 사용하지 않을 이유가 하나도 없다.

자동화 테스트: 자동화 테스트야 말로 젠킨스를 사용해야 하는 이유중 으뜸이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git와 같은 버전관리 시스템관 연동하여 코드변경을 감지하고 자동화 테스트를 수행해 줌 으로서 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.
무엇보다 중요한것은 이러한 안전망이 제공해 주는 안심감이야 말로 개발자들이 악취나는 코드를 리팩토링을 통해 적극적으로 제거 할 수 있게 해 주는 든든한 버팀목이 된다는 점이다.

제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스씨를 만나게 된다.

테스트 커버리지: 젠킨스는 자동화 테스트 실시와 더불어 테스트 커버리지도 리포팅을 해 준다. 개인적으로 테스트 커버리지가 품질에 대해서 기여하는 부분에 대해서는 회의적인 입장이다. 결국 자동화 테스트의 작성 자체는 프로그램 사양에 대한 개발자 심도있는 고찰을 기반으로 하는데 커버리지 라고 하는 일괄적인 기준으로 제약을 가하게 되면 테스트가 본래의 의미를 잃어버린 커버리지를 달성하기 위한 테스트가 만들어지기 쉽기 때문이다.
젠킨스에서는 다양한 형태로 클러스터링을 지원하는데, 자동화 테스트가 충실하게 작성된 프로젝트라면 테스트에 상당한 컴퓨팅 파워가 투입되어야 하기 때문이다. 

코드 표준 준수여부 검사: 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수여부의 검사나 정적 분석을 통한 코드 품질  빌드 내부에서 수행하는 것으로서 기술적 부채의 감소에도 크게 기여한다.

빌드 파이프라인 구성: 2개 이상의 모듈로 구성되는 프로젝트의 경우 당연하게도 레이어드 아키텍처가 적용되어 있을터이고 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들자면 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다. 이러한 파이프라인의 구성은 선형뿐만 아니라 간단한 스크립트를 통해 매우 복잡한 제어 까지도 가능하다.

Build Pipeline Plugin을 이용하면 논리 구조를 가진 파이프라인도 웹 인터페이스를 통해 간단히 만들 수 있다.

책 이야기 - 실천 반복형 소프트웨어 개발

왜 반복형 개발인가?

 Disciplined Agile Delivery (DAD)를 비롯해 애자일 개발에 가장 큰 영향을 끼치고 있는 인물인 Scot Ambler는 2007년부터 자신의 웹 사이트에서 비 정기적으로(거의 1-2년에 한차례)프로젝트 성공에 대한 설문을 진행해 오고 있다. (2013년 투표는 2013년 12월1일 현재 진행중이며 결과가 나오면 살펴볼 기회를 가져보려 한다.)

아래 표는 가장 최근 이뤄진 2011년의 조사 결과이다.

 여기서 눈여겨 보아야 할 것은 성공률 1위가 애자일 개발이 아닌 반복형 개발이라는 점이다.
 반복형 개발은 순차 점증적 개발(Iterative and incremental development)과 동일한 의미 이며 폭포수 개발 방식과 마찬가지로 여러가지 수정모델이 존재하는데, Rational Unified Process로 흔히 불리우는 Unified Process가 대표적이며,  2위와 3위에 오른 애자일 소프트웨어 개발 프로세스들 또한 반복형 개발에 근간을 두고 있다.

반복형 개발 VS 애자일 개발 VS 폭포수 모델

 애자일 개발과 반복형 개발은 실상 프로젝트 내부에서 이뤄지는 작업의 내용면에서는 사실상 큰 차이가 없다고 보는데, 두가지 개발 방식에 대한 차이는 무엇을 하는가 보다는 무었을 지향하는가에 있기 때문이다.

 애자일 개발은 가치 지향적이다. 애자일 개발은 프로세스나 계약, 절차보다 완성된 소프트웨어가 지니는 가치를 가장 중심에 놓고 프로세스를 바라보는 관점을 지닌다. 
반복형 개발은 폭포수 개발과 마찬가지로 기본적으로는 절차 지향적이다. 인적 자원에 크게 의존 할 수 밖에 없는 소프트웨어 개발 프로젝트가 필연적으로 지니게 되는 불가시성을 최대한 배제하기 위해 반복적이며 점진적으로 계획하고 실행하는 방법을 택하고 있다. 
XP나 스크럼과 같은 애자일 개발 프로세스들은 기본적으로 반복형 개발을 기초로 하여 개발 프로세스들을 확립하였다. 짧은 개발주기, 지속적인 통합/배포, 그리고 회고를 통한 피드백이 그것이다. 

 엔터프라이즈 어플리케이션 개발에 있어서 애자일 개발이 지니는 최대의 약점은 고객으로 부터 듣는 질문중 가장 단순하면서도 가장 흔히 듣는 질문인 "그래서 얼마면 되는거요?"라는 질문에 답변하기가 까다롭다는 점이다. 특히나 대규모의 프로젝트에서 "일단 한번 해 보시면 얼마나 좋은지 아실껍니다." 라는 답변으로 고객을 안심시키기는 쉽지가 않다는 이야기 이다.

 그렇다고 견적내기 편하다는 이유로 폭포수 모델을 택하기엔 너무나도 많은 대가를 감수해야만 한다. 폭포수 모델이 오늘날 천덕꾸러기 신세를 면치 못하는 이유는 만들어 내야 하는 소프트웨어에 대한 복잡성이 검토를 통해 예측 가능한 법위를 넘어섰기 때문이다. 

 현대의 사회 시스템은 끊임없이 복잡한 방향으로 변화하고 있으며 이를 추상화 하여 다루는 소프트웨어도 함께 복잡성을 더해가고 있다.  이에 대해 반복형 개발은 끊임없이 완성된 소프트웨어를 만들어 내고 그에 대한 피드백을 통해 프로젝트를 통제해 나가는 방식을 취함으로서 이러한 복잡성에 대응해 나가고 있다.

 즉, 고객이 진정 원하는 소프트웨어의 사양은 완성된 소프트웨어를 직접 만져보기 전에는 확정하기 어렵다. 따라서 검토만으로 해결 할 수있다고 주장하는것은 너무나 천진 난만한 생각이며, 이에 대한 대가로 지불되는 것은 대부분의 개발 현장에서 개발자들의 땀과 눈물이 될 것이다.  

실천 반복형 소프트웨어 개발에서 다루는 내용

이제 본론인 책 이야기를 할 시간이다.

 저자인 쓰다씨는 현재 일본 마이크로소프트에서 테스트 전문가로 활동하고 있으며 필자가 소속된 豆蔵Mamezou의 OB이기도 하다.

저자는 이 책의 대상 독자에 대해 책 머리에 다음과 같이 밝히고 있다.

• 3~5년정도의 소프트웨어 개발 경험이 있는 분
• 프로젝트 팀을 리드하는 위치이며, 팀운영방침을 정해야 하는 분
• 지금부터 프로젝트팀을 리드하는 위치에 서게되는 분
• 프로젝트팀의 운영에 대해서 문제의식을 가지고 있는 분
• 개발중인 소프트웨어의 품질을 제어할 수 없어서 곤란을 겪고 있는 분
• 개발을 지원하는 툴을 도입하고 싶지만, 조직의 문화적 저항에 부딧혀 뜻을 이루지 못하는 분
• 툴을 도입하기는 하였으나 제대로 활용하는 방법을 알지 못하는 분
• 폭포수개발 프로세스에서 벗어나고 싶은 분
• 반복형 개발을 시험해 보고 싶지만, 몇번을 반복해도 끝이 나질 않아 실패한적이 있는 분

 이 책에서는 언어나 생산되는 소프트웨어에 관계없이 다양한 소프트웨어 개발 프로젝트에서 사용 가능한 범용적인 반복헝 개발의 원칙과 규율을 제시하고 있다.

 책에서 소개하는 원칙과 규울은 단순히 이론에 그치는것이 아니라 현재 나와있는 최적의 개발지원 환경들(빌드, 형상관리, 이슈트래킹, CI)이 개발 규모와 진행상황에 따라 어떻게 연동되어 운용 되어야 하는지를 구체적인 예제와 함께 설명하고 있다.

 개인적으로 이 책의 가장 맘에 드는 부분은 일방적으로 이러한 방식이 가장 좋습니다 라고 강요하는 식이 아니라 스스로 각자의 개발 현실에 맞는 프로세스를 찾아 나갈 수 있도록 다양한 힌트를 제시하고 있다는 점이다.

품질과 납기를 동시에 잡는 비장의 무기 - 타임박싱 관리 기법

 저자인 쓰다씨가 반복형 개발에서 특히 중요하게 생각하는 개념은 타임박싱기법 이다.
타임박싱이란 기간 안에 끝낼 수 있는 작업과 그렇지 못한 작업을 선별하여 다음 반복에 넘기는 프로젝트 관리 기법을 지칭하는 것으로 정해진 시간 속에서 개발 사이클을 반복해야 하는 반복형 개발에서 품질과 납기를 지켜내기 위해 매우 유용한 개념이라 할 수 있다.

타임박싱 기법에 대해서는 아래 포스팅에서 자세히 다루고 있다.

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

그래서 얼마면 되는거요?

 마지막으로 아까전에 했던 "그래서 얼마면 되는거요?"라는 고객의 질문에 대해서 필자는 다음과 같이 답변을 하고자 한다.

"반복형 개발이 더 싸지지는 않을지 모릅니다. 하지만 같은 비용의 폭포수 개발과 비교하자면 위험 요소들의 제어가 훨씬 쉬워지며, 무엇보다 좋은 품질의 소프트웨어를 생산하는것이 가능해 집니다."

 반복형 개발(또는 애자일 개발)은 개발자가 편해지자고 하는것이 아니다. 오히려 개발자는 폭포수형 개발에 비해 훨씬 많은 작업들을 수행 해야만 한다. 그렇기 때문에 빌드하고 에러를 체크하고 코드 품질을 유지하는 등의 작업들을 철저하게 자동화 해 나감으로서 사람만이 할 수 있는 창조적인 작업에 보다 많은 시간을 투자 하는것이 가능해지는 것이다.

 개발 현장에서 애자일 프로세스의 도입을 검토하고 있거나 이미 도입하였더라도 프로세스의 개선에 목말라 하는 모든 이들에게 이 책을 꼭 추천한다.

성공한 스타트업이 미국에서 많이 나오는 이유는?

패기, 도전정신... 이런 단어들이 예능방송 이외의 곳에서 들려오지 않게 된 지가 꽤 오래된듯 싶다.  이미 우리사회는 도전하지 않아도 먹고살만하기 때문일까? 그보다는 실패에서 감수해야 하는 댓가가 너무나도 크기에 젊은이들이 몸을 사리게 된 것은 아닐까 싶다.

클라우드 컴퓨팅의 등장으로 개인이 무한대의 컴퓨팅 파워를 손에 넣을 수 있는 시대가 왔다. 더 이상 돈 걱정 하지 않고 두뇌 하나로도 승부가 가능한 시대가 열린것이다. 인재의 질로 우수하기로는 세계에서 둘째가라면 서러운 대한민국에서 혁신적인 서비스들이 나오기 위해서는 무엇이 필요할까?

Quora에서 ”성공한 스타트업이 미국에서 많이 나오는 이유는?”이란 주제로 이루어진 논의가 있었는데, 상당히 심도있는 답변들이 올라왔기에 이 자리에서 소개한다.

대부분의 성공한 스타트업은 왜 미국에서 나오는 것일까요?
저와 제 친구들은 미국인은 아닙니다만 이전부터 왜 대부분의 성공한 스타트업이 미국에서 이루어졌는가에 데해서 자주 토론해 왔습니다.
미국은 다른나라들이 가지지 못한 무언가를 가지고 있는 것일까요? 문화? 커뮤니티? 얼리어답터? 투자자? 환경?

Robert Scoble - 저는 Rackspace의 창업에 대해 공부하고 있습니다.

저는 전세계를 돌면서 스타트업 기업들과 만남을 가져왔습니다. 미국이 다른 나라들과 차별되는 점은 다음과 같습니다.

1. 롤 모델에의 접근성 - 애플 본사에에서 한 CEO를 만난적이 있습니다 그는 우리에게 애플이 창사 당시부터 성장하는 모습을 보아 왔다고 했습니다. "애플이 할 수 있다면 누구라도 해 낼 수 있습니다." 그가 우리에게 전한 말 이며, 이것이 롤모델이 뒤로 갈 수록 중요해 지는 이유입니다.

2. 자본에의 접근성 - 에플은 창업을 하기위해 투자가 필요했습니다. 모든 창업이 그러하듯이 말이죠. 자기자본과 친구들나 가족의 돈으로 창업이 가능한 사람은 몇 명 되질 않습니다. 하지만 이곳에서는 롤 모델 덕분에 친구와 가족들의 돈을 빌리는것이 좀 더 쉽습니다. 만약 우리가 당신에게 만달러를 주어 창업을 하고(실제로 GoPro는 그 정도 자본으로 제가 사는 집에서 2백야드도 떨어지지 않은 곳에서 창업했습니다.) 어느날 수십억 달러의 회사가 되어 있을지도 모르는 일 입니다. 지구상에 몇명이나 그런 일이 가능할까요? 제가 알기론 그다지 많지 않습니다.

3. 비지니스 기반에의 접근성 - 창업을 하는데 도움이 되는 변호사가 필요 하십니까? 그들이 여기 있습니다. 사무실과 창업에 도움이 필요한가요? 창업에 즉시 사용 가능한 300개의 사무실들을 지금 보러 가 보세요. PR팀? 창업전에 상담 할 수 있는 맨토? 차 쓸 일이 밥먹들이 있다구요? 상장을 준비하는 방법을 아는 재무 담당자요? 그밖에 필요한것들이 다 미국에 있습니다. 아, 물론 다른 나라라고 위에 열거한 것들이 없는건 아닙니다. 하지만 샌프란시스코, 시에틀, 보스톤 ,뉴욕, LA만큼 풍부하진 않습니다.

4. 배급에 대한 접근성 - 당신의 새로운 서비스를 어떻게 사람들에게 전달할 생각입니까? 앱스토어는 어떤가요? 아마존, 애플, 구글, 마이크로소프트, 그리고 페이스북이 앱스토어를 제공하고 있습니다. 이젠 누구도 배급문제로 고민하지 않습니다. 검색엔진을 써 보는건 어떻습니까? 뉴욕이나 샌프란시스코에서는 보다 많은 사업제휴와 배급에 대한 기회를 얻을 수 있을것 입니다. 아시다 시피 대부분의 기술관련 언론이 센프란시스코와 뉴욕에 몰려있기 때문이지요.

5. 수익 창출에 대한 접근성 - 광고를 하고 싶으신가요? 뉴욕이 짱이지요. 세계 어느곳보다 미국은 부유한 시장입니다. (적어도 중국이 추월하기 전까지는) 다른 시장으로의 접근성도 좋은 관계로 월드 와이드 브랜드를 런칭하기도 수월합니다.

6. 인재에 대한 접근성 - 오늘날의 대부분의 기업들은 빅데이터 전문가를 필요로 합니다. 예를 들면 하둡을 이용한 클러스터 처리 같은거 말입니다. 당신의 지역에서 그 일을 할 수 있는 사람을 쉽게 구할 수 있나요? 아마 아닐껍니다. 하지만 샌프란시스코 근방이라면 쉬울껍니다. 구글을 비롯해 HP,  시스코, 선, 야후와 같은 수많은 IT기업들이 최고수준의 기술과 사업적 재능을 지닌 인재들이 끊임없이 배출되는 스텐포드 대학에서 시작했습니다.

7. 관리자에 대한 접근성 - 당신은 단 두명이 라면을 먹어가며 시작하는 기업이라 할 지라도 CEO의 역할은 가장 중요하며 사실상 성공과 실패가 CEO HR의 단계에서 이미 결정 됩니다. 세계 탑 클래스의 언론을 다룰 수 있는 방법을 이해하고 있습니까? 래리페이지의 사무실로 찾아가서 구글과 사업거래를 성사 시킬 수 있나요?

8. 제품에 대한 접근성 - 오클리, GM, 포드, 보잉 그리고 그 밖에 수많은 메이커들이 미국에서 물건을 만들어냅니다. 이 사실은 그러한 물건들을 만들어 내는 방법을 만드는 사람들도 미국에서 찾기 쉽다는 이야기 입니다. 애플은 중국으로 생산라인을 옮겼습니다만, 여전히 많은 중국의 제품들은 미국 시장을 겨냥해서 만들어지고 있습니다.

9. 수많은 찬스들 - 샌프란시스코 지역에서 저녁 식사를 하거나 커피를 마시다 보면 수많은 스타트업 기업들과 대형 기업들의 임원들과 우연히 마주칠 기회를 가지게 됩니다. 아마 이러한 우연을 일상적으로 접할 수 있는 곳은 지구상에 이곳밖에 없을껍니다. 저는 그러한 우연들이 거대한 비즈니스로 거래로 이어지는 현장을 목격해 오고 있습니다. 큰 고기는 작은 강이나 개천에선 놀지 않는법 입니다.

Rony Gao - 국제 비즈니스 전문가

Rovert Scoble의 멋진 답변에 추가해 보겠습니다. 인구수를 살펴 보면 금방 답이 나오죠. 3억명이라는 인구는 분명 스타트업에게는 더 없는 축복입니다. 우리들이 미국에서의 기회에 대해서 말 할때 곶잘 간과하는 부분이 있는데, 미국의 인구는 나머지 G7인구를 합친 것과 거의 맞먹는다는 점 입니다.

Patric Keane - www.produckworld.com에서 근무
이 주제에 대한 글이 Paul Graham의 블로그에 잘 정리되어 있습니다.

Why Startups Condense in America

요약해서 보자면
1. 미국은 이민을 받는다.
2. 미국은 부자 나라다.
3. 미국은 경찰국가가 (아직은)아니다.
4. 미국은 나은 대학을 가지고 있다.
5. 미국에선 해고가 자유롭다.
6. 미국에선 적은 고용으로도 일이 가능하다.
7. 미국은 너무 까다롭지 않다.
8. 미국은 거대한 국내 시장을 가지고 있다.
9. 미국은 밴처 펀딩이 있다.
10.  America Has Dynamic Typing for Careers. (해석 불가)

쓰면서 보니 시장과 인구면에 있어서는 2천5백만이라는 인구가 몰려있는 서울도 제법 큰 기회를 제공하는 도시라는 생각이 든다. 인적 물적 인프라도 나쁘지 않은 만큼 서버 인프라의 부담을 크게 덜어줄 수 있는 클라우드 서비스의 등장이 새로운 밴처 열풍의 기폭제가 되었으면 하는 바램을 적어본다.

올바른 자바 프레임워크 선택하기

자바의 경우 선택할 수 있는 프레임워크의 수와 다양성에서 타 언어를 압도한다. 아마 자바와 비견되는 다양한 프레임워크를 제공하는 언어는 PHP정도가 아닐까? (사실 갯수로만 따지자면 PHP의 프레임워크 수는 자바를 상회한다!!) 하지만 목적에 맞는 프레임 워크를 선택하지 못한다면 필요없는 학습 코스트와 런타임 오버헤드를 감수해야만 할 것이다.

The Curious Coder's Java Web Frameworks Comparison!에서는 프레임워크 선택에 대한 고려사항으로 다음과 같은 항목을 꼽고있다.

1. 고속 프로토 타이핑 - 얼마나 빠르고 쉽게 프로토타이핑이 가능한가
2. 기능 - 얼마나 많은 기능들이 제공되는가
3. 사용성 - 얼마나 사용하기 쉬운가
4. 인기도 - 많이 사용하는 프레임워크는 풍부한 도큐먼트와 커뮤니티의 지원을 기대할 수 있다
5. 프레임워크 생태계 - 열성적인 오픈소스 커뮤니티의 지원을 받는 프레임워크들은 스스로 진화하고 확장해 나감으로서 보다 완벽한 모습을 띄게된다.
6. 처리능력과 확장성
7. 코드 유지보수와 업데이트의 용이성
8. UX, Look and feel - UI관련 기능

오늘은 최근 프로젝트에서 사용한 프레임워크들에 대해서 느낀점을 간략히 정리해 보고자 한다.

Spring(SpringMVC) vs JavaEE(6또는7) vs Struts

Spring는 현재 자바 프레임워크의 대세이다. 1800건 이상의 개발자 설문조사를 바탕으로 작성된 Developer Productivity Report 2012에의하면 Spring은 30%의 시장점유율로 자바 프레임워크의 산업표준이라 할 수 있으며 실제 표준인 Java EE 6조차 DI 인젝션과 같은 아키텍쳐상의 주요 컨셉을 상당부분 차용하고 있는 실정이다.  차기 Spring 4.0에서는 역으로 한발 앞서 공개된 Java EE 7 주요 아키텍처 컨셉의 상당부분을 포용함으로서 두 프레임워크는 더욱더 닮은 모습을 띄게 되었다.

최신버전의 Spring과  JavaEE는 모든면에서 서로 닮은 모습을 하고 있으나 어플리케이션 서버의 선택에 있어서 매우 유연한 Spring에 비해 JavaEE는 JavaEE 지원 어플리케이션 서버에서만 구동이 가능하다. 게다가 JavaEE인증을 받은 서버라 할 지라도 특정 DB만을 지원하는 JPA 구현과 같이 세부 사양에 대한 구현방식이 약간씩 다른경우가 있으므로 프레임 워크 선택시엔 표준 사양 세부 항목들의 지원 여부를 따져보고 제약사항을 꼼꼼히 확인해야 한다.

결국 Spring과 JavaEE 양자간의 선택이라고 한다면 오픈 소스의 유연함과 확장성인지 개발 표준에 대한 신뢰성에 대한 선택이 될 수 있을것이다.

Struts는 초기 자바웹 프레임워크의 대표주자로 스마트UI가 주류를 이루었던 시절에 등장하여 오늘날의 MVC패턴이 자리잡는데 큰 역할을 하였다. 현시점에선 다른 프레임워크들에 비해 생산성이나 기능등의 많은 면 에서 뒤떨어지는 모습을 보여주고 있기는 하지만 오랜기간동안 많은 웹 어플리케이션들이 Struts 베이스로 만들어졌기에 오늘날에도 Spring과 JavaEE에 이어 시장점유율 3위를 차지하고 있다.

Hibernate VS JPA VS iBatis(myBatis)

이번엔 퍼시스턴스 프레임워크를 살펴보자. Hibernate는 대표적인 ORM 프레임워크이며 JPA는 퍼시스터스 사양이다.  잘 알려진 JPA의 구현으로는 Eclipselink와 Hibernate등이 있으며  JavaEE와 Spring에서 지원된다. 기존의 Hibernate ORM과 JPA의 가장 큰 차이점은 데이터 영속화에 대한 정보를 XML에서 관리하느냐 어노테이션에서 관리하느냐의 차이점과 관계형 데이터 베이스를 오브젝트가 보다 쉽게 사용할 수 있도록 한 HQL 과 Criteria Query의 존재라 할 수 있겠다.

HQL과 Criteria Query의 차이점에 대해서 Sivateja씨는 자신의 블로그에 다음과 같이 정리해 놓았다.

• HQL 은 데이터에 대해서 선택/비선택 작업이 모두 수행 가능하지만 Criteria는 단지 선택 작업만이 수행 가능하다.
• HQL은 정적 쿼리를 수행하기에, Criteria는 동적 쿼리를 수행하기에 적절하다.
• HQL은 페이징 컨셉을 지원하지 않지만 Criteria는 지원한다.
• Criteria는 일반적으로 HQL보다 수행속도가 느리다. (역자 주 : 이 부분은 최신 버전의 Eclipselink의 경우 차이가 많이 좁혀졌다.)
• Criteria는 동적으로 쿼리를 생성하기 때문에 안전한 SQL인젝션이 가능하다. 반면 HQL는 정적 쿼리이기 때문에 SQL인젝션에 대한 안전성이 보장되지 않는다.

대세는 점차 JPA로 옮겨가는 중인데, 자바 전체가 어노테이션을 지향하고 있다는 점 외에도, 도메인 주도 설계와 같은 도메인 모델 패턴에서 관계형 데이터베이스를 직접적으로 의식하지 않는 퍼시스턴스 레이어 설계가 가능하다는 점이 개발자들에게 받아들여지고 있다고 본다.

마지막으로 대표적인 SQL Mapper인 iBatis의 경우 기존 NativeSQL+JDBC 개발자들에게 친숙해서 많은 환영을 받는 반면 진정한 의미의 퍼시스턴스 레이어 구현과는 거리가 있다.
Transaction Script Pattern 개발에서는 iBatis 만으로도 충분히 대응이 가능하지만 Domain Model Pattern 개발시에는 ORM인 Hibernate나 JPA가 퍼시스턴스 층의 구현으로서 보다 나은 선택이 될 것이다.

Transaction Script Pattern과 Domain Model Pattern에 대한 설명은 최범균님의 블로그 포스트에서 상세히 설명하고 있으니 참고하기 바란다.

애자일 시대의 모델링 : 애자일 팀의 확장에 따른 문서화에 대한 조언

애자일 선언문에서는 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둔다고 명시하고 있다. 그렇다면 문서화따윈 과감히 건너뛰고 바로 코딩부터 하는것이 올바른 것일까?  

InfoQ에 이러한 질문에 대해 심도있게 다룬 기사가 올라왔기에 내용을 소개하고자 한다.

모델링을 포함한 문서화는 팀 규모의 확대와 더불어 기하급수적으로 증가하는 커뮤니케이션 비용을 해소하기 위해 매우 중요한 요소이다. 애자일 개발에 있어서 이상적인 설계와 모델링이란 의식공유를 위한 커뮤니케이션의 일부로서의 존재해야 한다. 또한 오버헤드를 제거하기 위해 문서와 코드는 중복된 정보를 다루지 않아야 한다. 코드로 표현 가능한것은 코드로 표현하고, 코드안에 포함되기 어려운 정보들을 문서화의 대상으로 삼아야 한다.

대표적인 애자일 개발 프로세스중 하나인 스크럼 프로세스에서는 특별히 설계에대한 언급이  없다. 그럼 스크럼은 설계가 없이 개발이 이루어지는 것일까? 

설계는 모든 소프트웨어 개발에서 끊임없이 이루어진다. 그것이 머리속에서든 화이트보드 상에서든 수백페이지 짜리 문서든지간에 말이다.

문서화는 애자일에 대치 되는가? 

애자일 선언에서는 대화(커뮤니케이션)가 문서화보다 가치 있다고 명시하고 있다. 이상적인 문서화는 이러한 커뮤니케이션의 토대가 될 수 있어야 한다. 개개인의 머리속에 존재하는 개념들을 공유하는데 도움이 되어야 한다. 그리고 그러한 공유를 위해 가장 효과적인 방법이 바로 모델링이다.

UML로 대표되는모델링은 문장만으로 구성 할 수 없는 많은 정보들을 알기쉽고 간략하게 표현 할 수 있게 해 준다. 설계서의 목적은 커뮤니케이션의 토대가 되는것이지 납품 명세서의 목록을 채우기 형식적인 작업이 되어서는 안된다.

모델은 프로젝트 기간동안 지속적으로 갱신이 이루어지는 "유지모델"과 커뮤니케이션을 지원하기 위해 임시적으로 사용되는 "임시모델"로 나누어 관리 한다. "유지모델"은 프로젝트의 진행과 더불어 축척된 지식을 피드백하여 끊임없이 업데이트 되어야 하며, 화이트보드위에 그려진 클래스 다이어그램과 같이 그때 그때의 커뮤니케이션을 위해 작성되는 "임시모델"은

목적(그때 그때의 팀원간의 의식공유)이 달성에만 사용한다.

저자인 히라나베 캔지씨는 다음과 같은 세가지 형태의 모델을 유지모델로서 제안하고 있다.

1. 팀이 전체 시스템 구조의 개략적 인 아이디어를 얻기위한 시스템 " 아키텍처 "
2. 팀이 문제 도메인에서 사용되는 개념의 이해를 도와 줄 " 도메인 모델 "
3. 시스템의 일반 사용자를 이해하고 그들이 시스템에서 유용함을 얻는 방법에 대한 " 키 유즈 케이스 "

이 기사에서는 또한 팀의 규모확대와 더불어 어떻게 모델을 기반으로한 커뮤니케이션 프레임웍을 확대해 나가는지에 대해 매우 구체적으로 설명하고 있다.

간단히 요약하자면 타이거팀이라고 하는 이른바 초기 맴버들을 중심으로 전체적인 밑그림을 그리고 이 타이거팀의 맴버들이 주축이 되어 각 서브팀으로 설계에 대한 의식공유를 이끌어 나간다. 이때 중요한것은 서브팀에서 구체화된 모델은 다시 타이거팀으로 피드백하여 유지모델을 지속적으로 업데이트 해 나간다는 점이다.

저자는 설계의 의도와 이해를 공유하는데 유용한 팁으로 모델링 워크샾을 필요한 만큼 충분히 열고 벽이에 유지모델을 인쇄해 걸어놓고(또는 화이트보드에 프로젝트로 모델을 영사해 놓고) 그 모델위에 필기로 지식을 추가해 나가는  것을 추천하고 있다.

마지막으로 모델링에 대한 지식을 효과적으로 전파하는 데에는 사람에서 사람으로 지식을 전달해 나가야 한다. 단순히 문서만을 서브팀에 전달해서는 효율도 낮을 뿐더러 설계 의도가 충분히 전달되지 않는 경우가 많다. 가장 이상적인 방법은 타이거팀의 맴버가 서브팀의 일원이 되어 함께 코드작업까지 진행하며 모델과 아키텍쳐 지식을 전달하는 것 이다. 

저자는 기사 말미에 모델링에 대해서 몇가지 유용한 팁을 제안하고 있다.

전술 한 아이디어와 경험을 바탕으로 당신의 일일 모델링 작업 또는 모델링 워크숍에서 사용할 수있는 몇 가지 팁을 여기에 소개합니다.

• 리버스 및 모델 : 많은 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 판에서 다시이 주제를 다룹니다.

• 스콧 W 느리게 걷는 사람, 2002, "민첩 모델링"
• 크레이그 라만, 2007, "실천 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"

"유지 모델"과 "임시 모델"아이디어는 여기서 가지고 왔습니다.

• Strategic Systems, 2012, "Agile Modeling by Example "

같은 문제를 다루고있는 또 다른 InfoQ 기사입니다. 아직 2 부를 계속 기다리고 있습니다.

• Lee Ackerman, 2011, "Agile Modeling : Enhancing Communication and Understanding"

민첩한 개발 및 아키텍처에 대해 더 넓게 다루고있는 기사

• Bill Opdyke, Dennis Mancl, Steve Fraser "Architecture in an Agile world, 2010", SPLASH workshop

모쪼록 시간을 내서라도 꼭 원문을 읽어두길 바라며 영어에 대한 압박을 느끼는 분이라면 일본어판의 구글 번역 링크를 참고하기 바란다.(매끄럽지는 않지만 내용을 이해하는데 큰 문제는 없을것이다.)

원문 링크

Modeling in the Agile Age: What to Keep Next to Code to Scale Agile Teams

일본어판 InfoQ 기사 구글번역 링크

민첩한 시대의 모델링 : Agile 팀 확대를 위해 코드의 다음에 무엇을 유지해야 하는가

이 글을 쓴 히라나베 캔지씨는 UML, ERM, Mindmap과 리버스엔지니어링을 지원하는 소프트웨어 디자인 툴인 Astah를 만든 Change Vision社의 CEO이다. Astah는 뛰어난 기능과 합리적인 가격으로 일본에서는 이미 보편적인 설계툴 로 자리잡은지 오래이다. 만약 무상으로 사용 가능한 UML설계툴을 알아보고 있다면 Astah Community를 고려해 볼 것 을 추천한다.