블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

애자일 스크럼과 JIRA를 이용한 구현 방법


근래에 강의했던 스크럼 방법론과 JIRA를 통한 구현 방법에 대한 교육 자료 입니다.

상업적 용도가 아닌 사내 교육이나 스터디등으로 자유롭게 사용이 가능합니다.



저작자 표시 비영리
신고

Feature team에서 길드 모델을 이용한, 기술 거버넌스의 확보방안


조대협 (http://bcho.tistory.com)


지난번에 고민했던,  Feature team model에 대해서 조금더 리서치를 해보니, 음원 서비스를 제공중인 Spotify가 이 모델을 조금 더 발전 시켜서 Squad & Tribe 라는 모델을 사용하고 있다. 


Feature team 모델의 문제점 중의 하나가, Feature 단위로 팀을 나누다 보니 발생하는 문제가, 같은 기술을 쓰는 엔지니어가 다른 팀에 속하기 때문에, 기술에 대한 통제(거버넌스)나 기술 교류가 약해질 수 있는 문제가 있다. 




이러한 문제를 해결하는 방법으로는 길드의 개념을 사용한다.

길드는 같은 기술을 사용하는 사람들의 모임으로, 기술적인 리더쉽을 위해서 각 길드에는 길드 마스터가 있다.


다시 쉽게 이야기 하면 백앤드 개발팀에 기술 리드가 있고, 이 인원들이 각각의 기능팀으로 묶여 있는 모델로 보면 된다. 보통 Functional 팀 모델이 백앤드, 프론트 앤드와 같이 기술로 묶는데에 비해서 Feature 팀이 기능 단위로 묶었다면, 기능 단위 팀을 횡적으로 다시 기술 단위로 묶는 모델이다.


기존의 팀 모델 중에서 Matrix 모델이나 Pool 모델과 유사한 성격을 가지고 있다.

저작자 표시 비영리
신고

애자일 팀 모델에 대하여

ALM/애자일 | 2015.09.08 23:50 | Posted by 조대협

애자일 팀 발전 모델에 대하여

Functional team, Product Team, Feature Team

조대협 (http://bcho.tistory.com)

 

개요

 

관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.

근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.

·             Self organized

·             Cross functional

·             2 pizza team


Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가지고 모델이다. 이런 모델을 기반을 Self organized라는 팀 모델을 가질 수 있는데, 이는 팀내의 모든 기능 유닛들이 다 있기 때문에 팀이 독립적으로 제품에 대한 기획에서 부터 개발 및 출시가 가능하게 되는 모델이다. 이러한 팀 모델은 원할한 커뮤니케이션을 전제로 하기 때문에 팀의 구조가 커지면 원할한 커뮤니케이션이 어려운 이유로 팀의 규모는 두개의 피자를 먹을 수 있는 정도의 팀구조 즉 7~8명 정도의 2 pizza team 정도의 구조를 가지게 된다

 

팀 모델과 더불어 이러한 모델을 효과적으로 적용할 수 있는 Devops와 같은 서비스 운영 모델이나, MSA (Micro Service Architecture)와 같은 아키텍쳐 모델이 발전되고 있다. 이 부분은 오늘 다루고자 하는 부분이외의 부분이기 때문에 넘어가도록 한다.

 

이렇게 Cross functional team model로 이동을 함에 있어서도 몇가지 문제들이 발생하는데, 이러한 문제를 해결하기 위한 다음 모델이 Featured team model 이다. 이 글에서는 전통적인 functional team model에서 부터, 현대 애자일이나 MSA와 함께 대두 되고 있는 Component based team model 그리고 최근에 소개되고 있는 Featured team model에 대해서 알아보고자 한다.

 

이해를 돕기 위해서 아래와 같은 일반적인 앱/웹 서비스를 예를 들어서, 이러한 서비스를 개발하기 위한 각 팀모델에 대해서 설명하도록 하겠다.

이 서비스는 뉴스에 대한 포스팅과 함께 포스팅에 대한 댓글 기능을 제공하는 서비스이고,

모바일앱과 HTML 웹 페이지를 이용하여 사용자에게 서비스를 제공하고,

운영 시스템으로는 관리도구를 이용하여 댓글과 포스팅을 관리할 수 있다.”

 



Functional vs Cross functional team


이러한 팀 모델을 이해하기 위해서는 Functional team modelCross functional team model에 대해서 먼저 이해할 필요가 있다.

 

Functional team

먼저Functional team 모델은 가장 흔하게 존재하는 팀 모델중의 하나로, 개발 기술이나 역할 별로 팀을 나누는 방식이다. 예를 들어 프론트앤드 웹 개발, 앱 개발, 백앤드 개발, QA, 운영팀등으로 나눠서 팀을 관리하는 방식이다.

이 팀 모델을 앞에서 언급한 서비스에 적용하게 되면 다음과 같은 팀 모델이 나오게 된다.

 



이 모델의 장점은 기술을 각팀이 잘 통제하여 각 레이어(계층)별로 일관된 아키텍쳐와 기술 통제 모델을 가지고 갈 수 있지만, 일종의 풀(Pool)모델 처럼 각 기능이나 제품을 개발할때 마다 개발자를 그때 그때 마다 순환 배치하기 때문에 제품(프로덕트)에 대한 일관성을 가지고 가기가 힘들고, 각팀간의 인터페이스를 맞추기 위해서 커뮤니케이션 작업이 추가로 많이 소요된다.

 

Cross functional team

그래서 이러한 기술 중심의 Functional team 모델에서 발전한 것이 근래에 유행하고 있는 Cross functional team 모델이다.

Cross functional team 모델은 앞에서도 언급하였지만, 하나의 팀 안에서 기획에서 부터 프론트앤드, , 백앤드 개발, 테스트 및 운영까지 모두 할 수 있는 조직 모델이다.

 

Component Team & Featured Team in Cross functional team model


Cross functional 팀은 모든 기능(역할)구조를 가지고 있는 구조라는 기본을 가지고 있는데, 이를 세부적으로 살펴보면 크게 Component team (Product Team)Featured team 이라는 두가지 모델로 나눠볼 수 있다.

 

근래에 가장 많이 언급되는 Cross functional team modelcomponent team (product team) 모델이다. 모든 역할을 가지고 있는 하나의 팀이 하나의 제품을 맞는 형태이다. 앞서 언급한 서비스 예제에 맞추어 보면 다음과 같은 구조를 따르게 된다.

 



 

특히나 근래에 마이크로 서비스 아키텍쳐 (aka. MSA)와 함께 가장 많이 언급되는 모델로, 하나의 팀이 하나의 제품을 장기간 맏아서 진행하는 형태이다.  이 경우 기획에서 부터 운영 및 기술 셋까지 완벽하게 독립적으로 운영할 수 있기 때문에, 독립성이 매우 뛰어나서 기동성이 나올 수 있기 때문에 이론적으로는 참 이상적이다.

 

이상적이기는 하지만 이 모델에는 단점이 존재하는데, 일반적으로 하나의 서비스는 하나의 제품이로만 구성되지 않으며, 서비스를 구성하는 제품간에는 유기적인 연동이 반드시 필요하다는 것이다.

위의 예를 들어보면 새로운 댓글 기능이 들어간다고 가정했을때, 이 댓글 기능은 단순히 앱 개발팀이 혼자 단독적으로 수행할 수 있는 것이 아니라, 웹 개발팀도 댓글을 개발해야 하고, 관리도구 개발팀도 이 댓글을 관리 하는 지원 시스템을 개발해야 한다.

그러면 댓글이란 기능을 개발하려면 요구 사항이 3개의 팀으로 전파되어야 하고, 3개의 팀의 연계 아키텍쳐가 같이 설계되어야 한다.

즉 단일 요구 사항을 분석하고, 아키텍트가 기능에 대한 전체 컴포넌트에 대한 큰 설계를 마무리 한후 각 프로덕트팀으로 설계를 내려 보내서 개발을 진행해야 한다.



<그림. Component(Product) 기반 개발팀의 개발 프로세스 >

출처 : http://www.featureteams.org/feature_team_primer12.pdf

 

실제로 필자가 몇년전에 운영했던 팀운용 방식인데, 여러 프로덕트팀을 조율하는 Chief 아키텍트의 역할이 필요하고, 또한 각 팀의 개발 역량이나 개발 분량이 다르기 때문에 개발 스케쥴이 서로 맞지 않는 일이 발생하고 결국에는 이를 조율하기 위한 Program manager와 같은 역할이 필요하다.

 

새로운 팀에서도 이러한 방식의 팀 모델링을 하려고 시도를 했으나 벽에 부딪혔다. 기획이 각 기능 단위로 나오기 때문에, 각각의 프로덕트 오너(기획자)를 팀마다 묶을 수 도 없었을 뿐더러, 그렇게 팀을 나누기에 팀의 크기에 팀원간의 역량에도 차이가 있었다.

할 수 없이 전통적인 Functional Team 모델을 사용하면서 운용을 하면서 적절한 팀 모델을 찾기 시작했다http://bcho.tistory.com/1040

 키는 기능 단위의 팀 모델을 찾았는데, Feature Driven Development (FDD)와 같은 개발 방법론을 찾았으나, 실용적인 개발팀 모델은 찾지는 못했고, 어설프게나마 기능 우선의 개발팀 모델이 필요하다는 것을 느끼고 팀구조를 그렇게 차차 전환하던중에, Craig LarmanBas Vode가 작성한 “Feature Team Primer” 라는 문서를 찾게 되었다. http://www.featureteams.org/feature_team_primer12.pdf

 

잠깐 옆으로 빠지자면, Craig Larman을 처음 접한것은 1996Applying UML 이라는 책을 접하면서였다. 그 당시만 해도 UML에 대한 서적들은 대부분 UML에 대한 Notation이나 다이어그래밍 방법에 포커스가 맞춰져 있었을뿐, 요구 사항에서 부터 UML기반의 잘 정리된 설계 문서까지를 만들어내는 프로세스나 실용적인 방법론이 없었기 때문에 나름 상당히 감명을 받고 읽은 책이었는데, 2010년대에, 큰 조직에서 일을 하면서 애자일 방법론을 엔터프라이즈 레벨까지 확장하고 싶다고 생각하면서 찾았던것이 Enterprise Agile 방법론이나 Scaled Agile 방법론이었는데, 그러던중에 “Scaled Lean & Agile Development” 라는 책에서 또 다시 Craig Larman을 만나게 되었다.




변함없이 실용적인 내용을 담고 있었고, 그 나이에도 그러한 안목과 실용성을 잃지 않는다는게 대단하다고 느끼게 하는 분이다.

그리고 이 “Feature team primer”의 공동 저작자인 Bas VodeOdd-e라는 애자일 컨설팅 회사의 컨설턴트로, 국내에서 일년에 몇번 애자일 교육을 여는 분인데, 팀원들에게 애자일 스크럼 공인 자격증을 받게 하기 위해서 교육 프로그램을 찾던중에 접하게 되었다. 노키아 애자일 방법론등에 영향을 줬고, Craig Larman과 이 문서를 만들었는데, 국내에 20159월달에 교육이 있었고, 오프모임까지 있었지만 (신청해놓고 못나갔다.) 못 만난게 아쉽다. 30분이라도 이야기할 시간이 있었다면 아마도 또 다른 배움이 있지 않았을까?

 

다시 본론으로 돌아와서, 이러한 제품 기반의 Cross functional team의 문제점을 해결하고자 제안된 방법론이 Feature Team 모델이다. 이 모델은 Cross functional team을 조직하고, 이 팀이 제품(프로덕트) 단위가 아니라 기능 단위로 여러 프로덕트에 걸쳐서 개발을 진행하는 모델이다.




 

이 팀 모델을 앞에서 제시한 예시 서비스에 대입해보면 위와 같은 그림이 된다.

각팀에는 기획, 프론트,백앤드,,QA등의 모든 역할의 사람이 들어가 있고, 각 팀은 댓글이나 포스팅과 같은 기능 단위로 전체 컴포넌트(프로덕트)에 걸쳐서 개발을 진행한다.

 

지금까지 생각에는 이게 조금 더 실리적인 방법이 아닌가 하는 결론에는 도달해 있으나, Feature team 모델 역시 많은 단점과 제약 사항을 가지고 있다. 예를 들어 백앤드 개발자는 전체 백앤드에 기능을 녹여놔야 하기 때문에, 전체 백앤드의 구조를 모두 알고 있어야 한다. 프론트앤드도 웹과 관리도구에 대한 프론트엔드 개발을 해야 하기 때문에, 전체를 다 알아야 한다. 즉 개인 개발자나 기획자가 커버해야 하는 영역이 늘어나고, 손대야 하는 코드가 많아지기 때문에, 코드를 개발한 후 머지도 여러 컴포넌트에 걸쳐서 해야 하고, 손이 많이 가지만 하나의 서비스 기능에 대해서 일관성을 가질 수 있는 장점은 있다.

또 다른 문제로는 중앙 통제적으로 아키텍쳐를 드라이브하지 않기 때문에 기능별로 각각의 변종 아키텍쳐가 생겨날 수 있는 문제가 생기고 결국은 기술에 대한 통제 (Technology governance)문제가 발생한다.

 

기술적으로 한명의 엔지니어가 전체 영역을 이해하고, 거기에 각각 코드를 넣기 위해서는 많은 시간이 필요한데, 이를 줄이려면, 새로운 기능을 넣는 컴포넌트(프로덕트)가 새로운 기능을 붙이기에 잘되어 있다면 가능하다. 여기서 프레임웍과 플랫폼에 대한 니즈(needs)가 발생하는데, 새로운 기능을 쉽게 꼽아 넣을 수 있는 형태로 시스템이 개발되어 있으면 된다. 새로운 API를 넣기 위해서는 Spring REST + JPA를 레퍼런스에 따라서 개발을 쉽게할 수 있고, DB 정규화 없이도 탄력적으로 DB모델링을 할 수 있는 Document based NoSQL (eg. MongoDB, CouchBase etc)들로 잘 구성되어 있으며 가이드가 잘되어 있다면, 새로운 기능을 기존 컴포넌트에 추가하는데 크게 문제가 없다. Feature team 모델을 운영하려면, 시스템 아키텍쳐가 쉽게 이해하고 확장할 수 있는 구조로 설계되어 있어야 하고, 새로운 기능을 추가하기 쉬운 가이드나 레퍼런스 구현이 잘되어 있어야 하며, 여러 컴포넌트에 걸쳐 한명의 개발자가 기능을 추가할 수 있어야 하기 때문에, 테크놀로지(프로그래밍 언어나 프레임웍)들이 한정(표준화)되어 있고, 각 엔지니어들에게 교육되어 있어야 한다.

 

그렇다면 결론은 Feature Team 모델인가?

그렇다면 이 Feature team 모델이 모든 개발에 있어서 만병 통치약인가? 결론은 당연히 No이고, 모범 답안은 역시 “Case by case” 이다.

조직에 따라서 프로덕트 단위로 개발을 하는게 더 효율적일 수 도 있고 이런 경우에는 프로덕트(Component) 중심의 cross functional team 모델이 적합할 수 도 있다. 프로덕트에 따라서 빠르고 생산적인 개발 기술이 필요할 경우에는 Ruby on railsnode.js 로 그 제품(프로덕트)를 개발하는 모델을 사용할 수 있다.

또는 한 조직내에서 어떤 제품은 독립성이 높고, 계속해서 기능 추가가 독립적으로 가능하다면 제품 기반의 cross functional team으로 독립 운영하고, 나머지 부분은 Feature team 모델로 운영할 수 도 있다.

즉 개발하고자 하는 서비스나 팀의 상황, 조직의 성숙도, 개발 스피드, 기술 수준, 관리 역량등 다양한 요인에 맞춰서 팀 모델을 점차적으로 변화시켜 나가고 최적의 모델을 찾는게 답이 아닌가 싶다.

 

참고 : http://www.featureteams.org/feature_team_primer12.pdf

저작자 표시 비영리
신고


플래닝 포커를 이용한 프로젝트 일정 산정

조대협 (http://bcho.tistory.com)


프로젝트 진행을 하거나, 애자일 방법론 기반으로 스프린트 기반의 프로젝트를 진행할때도 항상 문제가 되는 것이, 일정 산정이다. 먼저 정확한 일정 산정이 어려울 뿐더러, 프로젝트를 진행하는 외부의 인원이 보기에 일정 산정의 근거가 약해서 “왜 저일이 왜 그렇게 오래 걸려요?” 라는 등의 비난을 받을 수 가 있다.


그래서 정확한 일정 산정 프로젝트 일정 관리와 함께, 팀의 일정 산정에 대한 정당성을 확보하는 것 두 가지의 목적을 가지고 있다. 


그러나 이러한 일정 산정은 불확실한 미래를 예측하는 작업이기 때문에 매우 어려운데, 이러한 일정 산정의 좋은 기법의 하나로 “플래닝포커(Planning Poker)”라는 기법을 소개하고자 한다.


플래닝 포커는 애자일 기법으로 대략적인 방식은 다음과 같다.

먼저 다음과 같은 역할이 필요하다.


  • 기획자(Product Owner) : 요구 사항을 정의하는 사람
  • 진행자 : 플래닝 포커를 진행하는 사람
  • 참석자 : 실제 개발을 진행하는 사람


그리고, 그 스프린트에서 개발을 진행할 요구 사항 목록이 필요하다.  (User story backlog)

준비가 되었으면 다음과 같은 순서로 진행한다.


기획자가 먼저 사용자 스토리를 전체적으로 쭈욱 훝어가면서 설명한다. 이를 통해서 참석자들이 무엇을 개발할것인지 사용자 관점에서 이해를 하게 된다. (전체 그림을 이해하는 단계.) 이때 가급적이면 사용자 스토리는 사용자가  사용하는 시간순으로 나열되는게 좋다.

예를 들어 다음과 같은 스토리가 있다고 하자


  • 글쓰기
  • 글목록보기
  • 로그인


사용자 시나리오 순서는 사용자가 로그인 한후, 글 목록을 본후에, 새로운 글을 글쓰기로 올린다. 라고 했을때 위의 백로그는 시간 순서에 맞지 않는다.

그래서 백로그를 정리하면 다음과 같이 정리가 되는게 좋다. 


  • 로그인
  • 글 목록 보기
  • 글쓰기


(참고. 이렇게 시간 순서대로 사용자 스토리를 배치하는 기법을 사용자 스토리 맵핑이라고 한다.)


전체 컨택스트(문맥)을 이해했으면 각각의 스토리에 대해서 걸리는 시간을 Estimation (산정)한다.

하나의 스토리를 올리고, 기획자가 기능에 대해서 다시 설명을 한다. 참석자는 기능에 대해서 궁금한점이 있으면 기획자에게 물어보고 설명을 듣는다. 어느정도 기능이 이해가 되면 그 스토리에 대해서 참석자들이 구현에 걸릴 시간을 투표한다. 기간은 디자인, 구현 과 “테스트”를 포함한 시간을 예측해서 투표한다.

이 기간은 전체 구현기간이다. 예를 들어 “로그인”이라는 기능을 앱에 구현할 경우, 앱 개발 기간, 뒷단의 API 서버 백앤드 개발 기간을 예측 산정해야 한다. 참석자가 당연히 풀스택은 아니겠지만 그간의 경험을 기반으로 예측 산정을 한다. (정확하지 않을거 같은데.. 직접 해보면 생각보다 정확도가 높다.)


예측치를 상대방에게 보이지 않고 포커에서 카드를 뒤집듯이 한꺼번에 뒤집기 때문에, 플래닝 포커라고 이야기 하고, 이렇게 함으로써 상대방의 예측에 관여하지 않고 각 참석자의 의견을 객관적으로 들을 수 있다.


요즘은 시스템이 발전해서 이러한 플래닝포커를 실제 카드로 하지 않고 웹/앱의 온라인 시스템을 사용할 수 있다.


 


<그림. http://www.planitpoker.com/ >


본인의 경우http://www.planitpoker.com/을 이용해서 실제 플래닝 포커를 수행했는데, 사용하기가 그다지 어렵지 않다. 


단, 여러개의 스토리를 손으로 일일이 입력해야 하고(액셀 업로드가 있었으면 좋았을듯..) 반대로 끝나고 나서 결과를 액셀로 다운로드가 불가하다. (수기로 적었다.)


(혹시나 더 좋은 툴을 발견하면 알려주시기를..)


투표가 끝났으면 제일 낮은 점수와 제일 높은 점수의 사람으로 부터 그렇게 점수를 준 이유를 설명을 듣는다.

낮은 점수를 준 사람은 몬가 빠른 해결책을 가지고 있을 수 있고, 반대로 높은 점수를 준 사람은 다른 사람이 놓치고 있는 것을 알고 있을 가능성이 많다. 충분히 의견을 듣고, 같은 스토리에 대해서 투표를 재 진행한다.

주의할점은 투표를 하기전에 얼마의 일정이 걸릴지를 다른 사람에게 절대 이야기 하지 않는다. (아이고 이장님~~~!! 이 뜻을 아시는분은 있을듯..). 그러면 그쪽으로 의견이 쏠리기 때문에 객관적인 일정 산정이 어렵다.





이 과정이 중요한것이, 일정 산정시 내가 놓치고 있는 부분에 대한 의견 교환이 가능하다는 것이다.

재 투표는 대략적으로 포인트가 비슷한 포인트로 수렴할때 까지 계속해서 반복한다. (8번까지도 해봤다는..)


여기에 몇가지 팁이 있는데, 스토리가 복잡할 경우, 먼저 스토리를 구현하기 위한 대략적인 아키텍쳐를 설계 해보는 것이 좋다. (종이에… 본인의 경우에는 3M 에서 나오는 테이프가 달린 4절지를 애용하는데..) 이 과정에서 전체 팀원이 대략적인 아키텍쳐에 대한 협의가 이루어지고 같은 컨택스트에 들어오는 효과가 있다.


아래 그림의 뒤의 벽에 붙어 있는 사진이 각 스토리를 구현하기 위한 아키텍쳐 흐름이다.






이렇게 모든 과정이 끝나면, 전체 스토리 포인트를 합산하여 걸리는 시간을 예측한다. 본인의 경우 1포인트를 “한사람이 하루에 할 수 있는 양”으로 정하는데, 60포인트가 산정이되고 팀원이 4명이라면 총 15포인트. 워킹데이로 3주가 소요되고, 스토리가 빠질 수 있는 가능성이나 버퍼를 감안해서 20~30% (야근을 피하고 싶다면 50%)를 곱해서 전체 기간으로 산정한다. 


20개 내외의 스토리에 대한 일정 산정은 전체 스토리 설명 (1시간) 투표 (1~1.5시간) 정도가 소요된다.


몇가지  경험을 공유하면

내가 구현하지 않는 부분에 대해서 상대방에게 가혹하게 짧은 일정을 줄 수 있다.

수평적인 커뮤니케이션이 가능해야 한다. 아니면 주니어 엔지니어가 시니어 엔지니어 의견에 밀려서 객관적인 산정이 깨질 수 있다.

그리고 생각보다 잼있다. 

:)


저작자 표시 비영리
신고

스크럼 모델에 대한 고민


요즘 애자일 스크럼 방법론에 대한 회의를 느끼고 있습니다.

가장 널리 사용된다는 스크럼 방법론이고, 예전 몇몇 회사에서도 톡톡히 재미를 봤던 방법론이기 때문에 새로운 팀에 스크럼 방법론을 적용하기 위한 시도를 하고 있습니다.


그런데, 이 스크럼 방법론이 동작하지를 않습니다.

스크럼의 전제 조건인 즉슨, 스크럼팀이 Product(상품/서비스) 단위로 움직인다는 개념을 가지고 있습니다.

즉 특정 기능이나 모듈에 대해서 특정 팀이 계속해서 오너쉽을 가지고 개발을 진행하는 모델로, 이렇게 하면, 상품에 대한 경험이 지속적으로 쌓인다는 장점이 있습니다. 그리고 기획자 (Product Owner : PO)가 팀 내에 있기 때문에 궁극적으로는 각 서비스가 독립적으로 스스로 기획 부터 개발, 테스트까지 같이 될 수 있는 장점이 있습니다.

결과적으로는 팀이 무진장 빨라지고, 타 팀에 대한 의존성이 없이 개발을 나갈 수 있기 때문에 상당히 효율적이기 때문에 많은 개발팀이 택하는 방법론입니다.


그런데 이 방법론에는 몇가지 문제가 있습니다.

일단 서비스나 상품별로 쪼겔 수 있는 만큼의 팀 규모가 되야 하며

각 기획 인원과 개발팀으로 이루어진 팀이 그에 맞는 실력을 가지고 있어야 한다는 전제가 있습니다.

특히나 각 서비스가 서로 의존성을 가지고 있다면 전체 팀의 스피드에 문제가 될 수 있습니다.


간단하게 신문사 서비스가 있다고 가정하져. 시스템은 저작도구, 앱 그리고 웹 등으로 구성되어 있다고 합시다.

이때 어떤 새로운 기능을 넣으려고 하면, 저작도구 팀, 앱팀, 웹팀이 스피드를 같이 맞춰서 나가야 합니다.

근데 한팀의 역량이 안 따라와 주면, 전체 서비스 개발에 진도가 맞지 않게 됩니다.


예전에. 모 회사에서 새로운 서비스를 개발할때가 있었는데, 여러 시스템이 많이 얽혀 있었고, 스크럼 방법론으로 PO 기반의 개발을 하고 있었습니다. 이러다 보니, 중앙에 있는 웹 포탈 시스템이 요건에 대한 부하를 많이 받게 되더군요. 새로운 요건이 들어왔을때, 각 개별 서비스는 그 기능만 개발하면 되지만 반대로 포탈은, 포탈 자체의 개선 이외에 신규 서비스에 대한 기능 개선 요건을 처리해줘야 하기 때문에 어려운 점이 종종 있었습니다. 그나마 상품이 잘 나눠져 있는 상태라서 잘 Working을 했는데, 이번에는 상황이 좀 다른것 같습니다


내부에 시스템 종류는 아직 크게 많지는 않으며, 팀 규모가 스크럼 팀 형태로 운영하기에는 애매한 사이즈이고.

기획이 각 프로덕 기반으로 나오는게 아니라, 기능 기반으로 나오고 있기 때문입니다. (사실 이게 지금은 맞는 모델 같네요.)


그러다 보니, 여러 기능을 한 스프린트에 동시 개발하다 보면, 여러 서비스 컴포넌트들이 동시에 여러 기능에 대한 요건을 여러 기획자로 부터 받게 되서 개발팀이 혼란이 생기는 경우가 있습니다.


예를 들어 이런거져, 앞의 신문사 서비스의 예를 계속해서 이야기 해보면, 네이버 연동 서비스 기능, 로그 수집 기능 추가, 새로운 신문 기사 컨텐츠 타입 추가 라는 기능들이 각각의 기획자로 부터 나왔다고 봅시다. 그런데 각 기능을 정의한 기획자가 각각이다 보니, 스크럼 모델과는, 다르게 PO가 상품 별로 있는 것이 아니기 때문에, 저작도구,앱팀,웹팀과 같은 개발팀이 이 여러가지 요건에 대해서 우선 순위를 정하기가 매우 어려워집니다. 아울러 안 좋은 경우 각 기획자를 개발팀이 코디네이션 해야 하는 문제까지 생길 수 가 있습니다. 결국은 개발팀내의 새로운 PO나 PM이 필요할 수 도 있고, 이런 역할이 없을 경우, 오히려 개발자가 이런 역할을 겸임해야 하기 때문에 오버로드가 생길 수 있게 됩니다. 그렇다고 작은 조직안에서 기능 기획 이외에, 각 상품(서비스)별로 기획자를 넣는 것은 새로운 오버로드가 될 수 있습니다


그러면 어떻게 이 문제를 해결해야 할까?

기능 위주로 개발을 하는 애자일 개발 방법론이 있는데, 이를 FDD (Feature Driven Development)라고 합니다.

이름은 있는데, 그렇게 크게 유행하는 방법론이 아니라서, 덮어 두고 있다가 요즘 들어서 주의 깊게 살펴보고 있습니다.

개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론입니다.


이 방법론을 선택할 경우에는 각 개발 컴포넌트별 코디네이션이 대단히 중요합니다. 신문사 시스템 예제의 웹/앱,저작도구 와 같은 개발팀이 있을 경우, 하나의 신규 기능을 개발하기 위해서 전체 팀에서 필요한 내용을 중재하기 위한 프로젝트(또는 프로그램 관리자)와 전체 시스템 흐름을 정의할 수 있는 아키텍트의 역할이 필요하게 됩니다.


아울러 개발하고자 하는 피쳐의 크기가 작을때, 동시에 몇개의 피쳐를 더 개발하고자 하면, 각 팀의 개발 속도가 어느정도 맞아야 하느넫 이를 조율하는게 큰 문제로 다가옵니다. 단순하게 각 개발팀의 역량이나 사이즈의 문제가 아니라, 기능에 따라서, 각 팀이 개발해야 하는 개발량이 매번 다를 수 있다는 것입니다. 그러면 어떤 개발팀은 놀고 어떤 개발팀은 항상 바쁜 현상이 발생하게 됩니다.


이를 해결 하려면, 크로스 앤지니어링을 통하여 리소스를 유연하게 운용할 수 있는 방법이 필요하게 됩니다.

즉, 어떤 기능에 대해서 개발할 양이 앱팀이 적고, 웹팀이 많으면, 앱팀의 리소스를 웹팀으로 그 기능을 개발하는 동안만 배치해서 개발을 하고 빠지는 운영 방식이 필요합니다. 이를 위해서는 팀간의 개발 도메인 뿐만 아니라 각 시스템에 대한 이해도가 높아야 하기 때문에 대단히 어려운 방식이지만, 반대로 요즘 같은 풀스택을 기본으로 하는 스타트업에는 적절한 방식이 될수 있습다. 


내지는 서비스별로 개발팀을 나누는 게 아니라 (앱,웹팀, 저작도구 팀), 기술별로 팀을 나눠서 운용을 하고, 각 기능별로 임시 팀을 만들어서 운용하는 방법이 있을 수 있습니다. 예를 들어 안드로이드, 웹 프론트, 백앤드 팀이 있다고 하고 각 팀이 특정 기능을 개발하고자 할 때, 기능을 개발할 인원을 착출해서 개발을 진행하고 끝내는 방식입니다. 이렇게 하려면, 각 팀의 개발 인원이 각 서비스에 대해서 잘 알고 있어야 한다는 전제를 가지고 있습니다. 즉 웹 프론트 앤지니어가 저작도구, 웹을 동시에 건들 수 있어야 합니다. 이 경우, 각 서비스에 대한 도메인 지식 수준이 높아야 하기 때문에 개발자가 여기저기 서비스에 컨택스트 스위칭을 해야 하는 부담이 생기기 때문에 큰 서비스에서는 사용을 하기 어려운 모델이라고 볼 수 있습니다.


팀에 대한 리더쉽을 잃지 않기 위해서 각 기능별로 PM 역할을 하는 사람이 정의되어야 합니다.

또한 각 기술별로 리더쉽을 유지하기 위해서는 앱,웹 등 기술별로 팀장을 둬서 역량 개발이나 일반적인 관리 업무를 수행하고, 개발 업무는 기능별 PM이 관리해야 합니다. 즉 하나의 개발자에 두명의 메니져가 생기는 모델인데 이를 매트릭스 팀 모델이라고 합니다. 


요즘은 개발 프로세스와, 팀 모델링 방법론에 관심이 많습니다. 관심도 가져야 하구요.

대기업 만큼 풍부한 리소스를 쓸 수 없으니, 최적화를 통한 기동성 확보 방법에 대한 고민중인데, 좋은 방법이 없을까요?














저작자 표시 비영리
신고

애자일에서 문서화가 필요할까?

ALM/애자일 | 2015.01.24 19:37 | Posted by 조대협

애자일에 문서 작성이 필요할까요?

조대협 (http://bcho.tistory.com)


일본에 계신 정도현님과, 마이크로서비스 아키텍쳐에 대해서 이야기 하다가, 팀이 분할이 되어 있어서, 서로 디자인등에 대한 싱크업(서로 사상과 내용을 공유해서 모두 디자인을 이해하도록 하는것)을 하기가 어렵다는 이야기를 하던중에, 정도현님이 추천해준 글을 보니, 문서화에 대한 이야기가 나옵니다.

http://www.infoq.com/articles/kenji-modeling-agile

이 글인데, 생각해볼만한 가치가 있어서 몇가지생각을 정리해서 남겨봅니다.

마이크로 서비스 아키텍쳐의 장점은 각 서비스를 개발하는 개발자가, 자신이 개발하는 서비스에 대해서 알기가 편하다는 겁니다. 서비스가 작게 쪼게져 있으니 빠르게 이해할 수 있지만, 반대로 전체 시스템에 대한 구조나 사상을 이해하기 어려운 문제가 생깁니다.

실제로 제 경험상, 여러 팀에 서비스를 쪼게주고, 각 서비스에 대한 기능만을 이야기 해주고 서비스를 모아보면, 전체 시스템 사상에 맞지 않는 설계들이 많이 나옵니다.

서비스를 나눠서 개발한다하더라도 전체 팀이 같은 목표와 같은 큰 맥락의 디자인을 공유해야할 필요가 있는데, 제 경우를 먼저 예를 들어보면, 먼저 요구사항을 수집하고 요구사항에 있는 주요 시나리오를 기반으로 전체 컴포넌트와 주요 시스템 흐름을 문서로 정의합니다. 그후에, 분산되어 있는 각팀에 있는 아키텍트들과 싱크업(공유를) 합니다. 주로 전화나 화상회의를 통해서 문서를 화면 공유해서 보면서, 이 시스템의 전체적인 기능은 OO가 있고, 각 기능에 대한 흐름을 컴포넌트들간의 인터렉션 다이어그램을 보면서 쭈욱 같이 따라갑니다. 팀이 많고 분산되어 있다보니, 시간이 많이 걸립니다. (시간대도 틀리기 때문에.)

그러면 전체적인 사상적 공유가 이루어지고, 각 세부 서비스에 대해서 디자인을 각팀에 요청합니다. 그후에,   컴포넌트에 대한 디자인이 오게 되면, 검토를 해서 전체 흐름에 문제가 없는지를 검증합니다

개인적으로 문서 작업을 썩 좋아 하는 편은 아니지만, 그래도 최소한의 문서작업은 꼭 필요하다는 생각을 가지고 있었고, 마이크로 서비스 아키텍쳐에 대해서 고민하던중, 실제로 팀간에 디자인에 대한 이해가 틀려서 문제가 생기는 경험도 많이 했고, 문서를 놔두고 설명을 하면 서로 싱크업이 잘못되거나 서로 잘못 이해 하는 경우를 많이 줄일 수 있었습니다.

특히나 영어로 커뮤니케이션을 해야하기 때문에 상대방이 OK 알아들었다고 하더라도, 이해의 수준이 다릅니다.  또는 잘못 이해하고 이해했다고 하는 경우도 많구요. 이해를 확인하기 위해서 문서화를 하면 이 사람이 제대로 이해했는지 못했는지를 확인할 수 있습니다.


문서 작성 원칙

 

애자일 사상은 문서화 방법이나 문서화를 하라 말라에 대해서는 정확하게 가이드 하지 않습니다. 문서화를 최소화 하라고는 합니다만, 하지말라고도 않합니다.

자칫 이해가 잘못되면, 애자일에서는 문서화를 하지 말라는 것으로 이해될 수 있습니다.

지금까지 대략적으로 문서화의 필요성에 대해서 이야기 했는데, 그렇다면 효율적인 문서화 원칙에 대해서 생각해봅시다.

첫번째. “커뮤니케이션을 위한 문서화를 하라는 겁니다.

애자일에서 효율적인 문서화는 최소한으로 문서화를 하되, 잘못된 문서 관행을 만들어 낸 이유는 보지도 않는 문서를 프로세스에 맞추기 위해서 산더미 같은 문서를 만들어내기 때문에, 문서화를 기피하게 되는데, 대화를 시작하기 위한 문서는 효율성이 높습니다. 그냥 대화를 시작하면 원래 주제를 잃거나 서로 다른 기준점에서 출발해서 이해에 더 많은 시간이 소요될 수 있는데 문서는 같은 기준점을 줄 수 있습니다.

이때 문서를 만들고 그냥 주고..읽어보세요 라고 하면 절대 안되고, 문서를 보고 설명을 해야 합니다.


두번째. “문서는 계속해서 업데이트 되어야 한다

리뷰나 디자인 변경, 요구 사항 변경에 따라 계속해서 변경되기 때문에 문서는 계속해서 업데이트 되어야 합니다. 이때 중요한것이 변경 관리 인데, 변경된 내용은 문서 배포시 같이 함께 변경 내용을 공시 해서 배포 해야 합니다. 이때는 문서 히스토리 (Revision history) 페이지를 맨 앞장에 추가해서 무엇이 누구에 의해서 언제 어떻게 변했는지 기록해야 합니다. 수십 페이지 문서중에서 어떤 부분이 변화 되었는지를 이야기 하기 힘드니까요.

그래서, 앞에서도 설명했듯이 문서가 변경이 된 후에는 반드시 문서만 전달하는게 아니라 바로 또는 주기적으로 전체 흐름을 리뷰해서 공유를 해야 합니다.


세번째. “업데이트된 문서는 쉬운 방법으로 공유되어야 한다.

문서를 개인 PC에 저장하고 이메일을 통해서 배포하면 문제되는 점중의 하나가 이메일을 제대로 체크하지 않은 사람은 예전 버전의 문서를 계속 보고 있을 가능성이 매우 높다는 겁니다. 그래서 공유된 문서 저장소 개념이 필요한데, 이는 마이크로 소프트의 쉐어 포인트등을 이용하는 것도 하나의 방법이될 수 있고, 드롭박스와 같은 온라인 클라우드 스토리지를 이용하는 방법도 있습니다.

조금 더 진보적인 방법으로는 파일로 문서를 만들지 않고, 아예 위키에 작성해서 온라인으로 실시간으로 공유하는 방법도 있습니다. (아틀라시안 社의 Confluence 위키의 경우, MS-WORD 플러그인을 이용하면, 워드에서 저장하면 자동으로 Confluence에 저장되도록 하는 것도 가능합니다.)


문서에 들어가야 하는 내용

 

그러면 효율적인 문서 작성을 위해서 문서에 들어가야 할 내용을 알아보자. 꼭 문서화 되어야 하는 내용은 크게 3가지 인데,

  • ·         주요 사용자 시나리오

  • ·         아키텍쳐

  • ·         도메인 모델

를 들 수 있습니다. 이를 모두 묶어서 큰그림(Big picture)라고 부르도록 하겠습니다.


3가지 모델을 문서화하는 가장 큰 이유는 이 3가지 요소가 전체 시스템을 이해 하는데 가장 핵심 적인 요소가 됩니다.

기존의 전통적인 소프트웨어 개발 방법론은 divide & conquer 식의 접근 방법, 즉 전체 시스템을 조각조각 나눠서 설계 하는 접근 방식을 사용했으나, 근래에는 conquer & divide식의 역행된 방법이 권장됩니다.

“Rather than divide and conquer, an XP team conquers and divides. - Kent Beck”

이러한 접근 방식은 구성원에게 전체의 숲을 보여주고, 각각의 나무를 보게 하는 방식으로.

예를 들어 보면, 큰 도시를 계획하고 만들려고 했을 때 각각 건물을 먼저 디자인한 후에 배치하는 것이 아니라, 전체 도시에 대한 커다란 구도를 잡고 각 구역에 맞는 건물을 디자인하는 것과 같은 이치가 됩니다.

이런 접근을 구체화 하려면 ,전체 시스템에 대한 기능이나 주요 사용자 시나리오를 기술하고, 그 후에, 아키텍쳐를 서술하는데, 아키텍쳐는 주요 기능을 구현하기 위해 필요한 컴포넌트와 그에 대한 관계를 기술하고, 그 다음에는 각 시나리오를 실행하기 위한 컴포넌트간의 플로우(UML에서 activity diagram또는 sequence diagram)를 서술하는 구조가 됩니다.

이와 아울러 시스템을 구성하기 위한 도메인 (개체)들에 대한 모델을 정의하는 것이 필요한데, 데이타 베이스의 ERD등이 대표적인 예에 속한다. 이를 통해서 전체 시나리오가 어떤 개체에 의해서 이루어지는지 그리고 각 시나리오를 구현하기 위해서 어떤 컴포넌트들이 필요하며 컴포넌트들이 어떻게 순서대로 상호 작용을 하는지 이해할 수 있습니다.


공유 방식


자아 그러면 이쯤에서 Infoq.com에 있는 Kenji님의 글중에 있는 내용을 몇가지 살펴봅시다.

문서 공유 방식에 대해서, 좋은 방법을 제시하고 있는 데, “타이거 팀이라는 개념이 잘 정리된 개념이라서 이 개념을 기반으로 설명해보겠습니다.

먼저 전체적인 개념을 요약하자면,각 서브 개발팀의 리드들이 타이거 팀이라는 형태로 모이고 큰그림(아키텍쳐,주요 시나리오,도메인 모델)등을 정의하고 이를 같이 리뷰하여 공유 합니다.



<그림. 각 서비스 개발팀에서 타이거팀에 모여서 큰 그림을 공유>


타이거 팀 멤버들이 이해가 다 되면 각 팀으로 돌아가서 큰그림 문서를 가지고 다시 전체 팀에 전파 하는 방식입니다.


<그림. 타이거팀 멤버들이 각팀으로 돌아가서 큰 그림을 각 팀원에게 전파>


이때 타이거팀의 멤버는 각 서브 개발팀에서 기술과 커뮤니케이션에 뛰어난 사람이 되어야 한다.

실제 예를 들어 보면, 여러개의 서비스 컴포넌트 개발팀이 있을때, 각 서비스 컴포넌트 개발팀의 아키텍트가 모여서 치프 아키텍트 아래에서 전체 시스템을 설계하고 토론한 후에, 큰그림 문서를 만들고 나서, 공유 합니다. 이해가 되면 각 팀으로 돌아가서 각 서비스 개발팀의 아키텍트가 큰그림 문서로 모든 팀원에게 전체 시스템 사상과 기능,구조등을 설명하게 됩니다.

각 팀에서 나온 피드백은 아키텍트가 수집해서 검토하고 팀내의 토론을 거쳐서 아키텍트 모임에 의견을 제시 하여 전체에 반영되게 하고, 다시 큰 그림 문서를 업데이트한 후에, 다시 각 팀에 전파를 합니다.

처음 전체 큰그림을 이해하고 전파하는데는 시간이 걸리지만, 큰 그림이 정의된 후에, 세부 조정은 그다지 많지 않은 문서 수정과 공유 시간만으로 가능합니다.

이때 팁은 전체 주요 시나리오를 먼저 설명한 다음에 각 시나리오별로 아키텍쳐 흐름을 따라가는 방법이 효과적입니다.


Kenji님의 문서에서는 이러한 형태의 중앙팀을 타이거팀이라고 소개하였는데, 인터넷을 찾아보니 타이거팀에 대한 정의는 갖가지라서 자세한 정의는 찾아보기 바랍니다.

일반적으로 타이거팀은 뛰어난 사람들을 모아서 프로젝트에서의 문제를 해결하는 소방수와 같은 역할을 하는 개념이나, 또는 프로젝트 초반에 구조와 기술을 잡아내는 선행 개발팀과 같은 개념으로 설명이 되는 경우가 많습니다. 이러한 개념은 예전에도 COE (Center Of Excellence)팀이라는 개념으로 있었고, 애자일 모델에서 각 스크럼팀간의 공유를 위한 스크럼위의 스크럼을 타이거팀으로 정의할 경우에는 예전에 PMO (Project Management Office : 프로젝트 관리 모임. 그러나 PMO는 별도의 분리된 팀 모델을 가짐. 스크럼의 스크럼은 각 멤버들이 각 스크럼에 속해 있고 공유를 위할때만 만나는 형태), 커미티 등으로 정의할 수 있습니다.  어쨌거나 애자일에서 COE 팀과 같은 개념이 언급되는것도 재미있는 부분 같습니다. 시간 나시면 꼭 찾아보시기를 권장합니다.

 

제가 개발하고 커뮤니케이션을 하면서 가장 자주 쓰는 말이 있습니다. "Bring all into same page."

모든 참여한 사람들이 같은 컨셉과 같은 이해를 가지고 개발을 할 수 있도록 한다는 말입니다. 이의 중점은 커뮤니케이션이고 이 글에서는 그 방법중의 하나로 최소한의 문서를 이용한 커뮤니케이션 방법에 대해서 설명하였습니다

 

문서는 커뮤니케이션을 돕기 위한 하나의 도구입니다. 도구는 절대 목적이 되면 안됩니다. “문서는 단지 거들뿐..”



 

 

 

 

저작자 표시 비영리
신고

프로젝트 인셉션에 대해서

ALM/애자일 | 2014.08.13 15:09 | Posted by 조대협


프로젝트 인셉션에 대해서 

원글 : http://www.infoq.com/articles/project-inception-meeting


프로젝트 시작전에, 프로젝트 팀에 대한 alignment를 하기가 어렵다.

alignment란 팀이 같은 프로젝트에 대한 배경과 목표를 이해하고, 주요 기능과 일정, 그리고 인원별 역할등 전체적인 프로젝트의 컨텍스를 이해하는 것인데,

일반 개발자들은 비지니스쪽 인원을 만나기 힘들 뿐만아니라, 상위 임원들의 방향과 생각을 중간 메니져를 통해서 듣기 때문에, 내용 전달이 부족하거나 오역 되었을때, 팀의 alignment가 제대로 되지 않는 경우가 많다.

이런 문제를 해결하기 위해서, 하루 full day로 프로젝트 시작하기 전에 공유하는 회의를 갖는데 이를 프로젝트 inception meeting이라고 한다. 미팅에서 얻고자 하는 것은 "Knowing what to build and where to start" 로 무엇을 만들것이고, 어디부터 시작할것인가를 공유하고 정의하는 것을 목표로한다.



※ Kick off 미팅과 유사하다.


미팅에서는 

  • 프로젝트에 대한 개요
  • 비전과 목표
  • 위험요소
  • 주요 인원과 역할에 대한 소개
  • 프로세스
  • 주요 기능 스토리
  • 소요 자원(시간)
  • 우선순위
  • 회고

등의 순서로 진행된다.


원글에서 인셉션의 목적과, 이유,누가 어떻게 언제 진행해야 하는지등이 잘 정리 되어 있어서 꼭 한번 참고해볼만하다.



저작자 표시
신고