#acl +All:read

FDD에 대해 알아보면서, 모델링을 미리 한다는 점, 기능 목록 위주의 계획을 한다는 점 등이 실제 프로젝트에서 진행하는 방식과 일치하는 부분이 좀 있는 것 같다는 생각이 들었고, 그래서 실제 프로젝트에 좀 더 적합한 방식이라는 생각이 들었다.

== FDD Process ==

 1. Develop Model
 1. Build Feature List
 1. Planning
 1. Design by Feature
 1. Build by Feature

1~3 단계는 시동 단계라고 할 수 있고, 4~5 단계는 구현 단계라고 할 수 있다.

4->5->4->5 이렇게 iterative하게 진행한다.


=== Develop Model ===

이 단계에서는 세 가지의 역할이 필요하다.

 * Chef Architect
 * Chef Developers
 * Domain Experts

이 세 명이 Modeling team을 구성한다. 그리고 도메인 전문가들은 본인들이 아는 것들을 말해주고, 아키텍트와 개발자와 함께 모델을 만든다. 모델링 과정은 협력적으로 진행된다. 모델을 어떤 정도까지 발전시킬지는 팀의 판단에 따라 달라질 수 있다. 워터폴처럼 거의 모든 것을 확정할 수도 있고, 애자일스럽게 조금만 확정해놓고 진행해가면서 보완해갈 수도 있다.

도메인과 개발쪽 양쪽의 멤버를 초기부터 함께 참여시키는 것은 문제 영역(problem domain)에 대한 공동의 이해(shared understanding)를 높이는데 도움이 된다. 모든 사람이 주요한 문제 영역 컨셉이 무엇인지, 어떻게 관계지어지고 어떻게 상호작용하는지 이해하는 것은 중요하다. 그렇게 함으로써 팀 전체가 서로와 커뮤니케이션하는 것을 배워가고, 공유된 어휘(shared vocabulary), Eric Evans가 말하는 Uniquitous Language (UL)을 정립하게 된다. 이 단계에서 만드는 오브젝트 모델은 깊이보다는 넓이를 추구한다. 깊이는 프로젝트가 진행되면서 더해진다. 따라서 모델은 살아있는 결과물이다. 프로젝트가 진행되면서 팀이 논의하고 도전하고 요구사항들을 분류하는 기본적인 수단이 된다.


=== Build Feature List ===

'''A FDD feature is a small client valued feature'''

 * Feature: <action> the <result> <by|for|of|to> a(n) <object>
 * Feature Set: <action>ing <object>
 * Major Feature Set: <object> management

예)

Herd Management
 * Birthing cattle
  1. Add a new baby cattle to herd
  1. Mark mom not pregnant for cattle

Feature는 Model과 연관되어 있다.

 * Add a new baby cattle to herd <===> Herd.!AddNewBabyCattle(Cattle)

Feature는 문서화(reporting) 가능하다.


FDD의 첫번째 단계가 모델링 단계이기 때문에 어떤 사람들은 FDD를 model-driven process라고 할 수도 있겠다. 하지만 실제로는 그렇지 않다. 비록 모델이 프로세스의 중심이 되지만, FDD는 요구사항 중심이다. 작은, 고객에게 가치를 주는 요구사항, 다른 말로 '기능(feature)'이라고 불리우는 것이 프로젝트를 이끌어나간다. 모델은 단지 가이드일 뿐이다. 작다는 것은, 대개 구현에 1~3일 정도 걸리는 것을 말한다. 5일 정도 걸릴 수도 있지만, 10일 이상 걸리면 안된다.

Scrum이나 XP는 Backlog나 [[UserStory]]를 단일(flat) 목록으로 정리한다. 하지만 FDD는 기능(features)들을 3계층으로 구조화한다. 이렇게 하면 큰 프로젝트에서도 기능 관리하기가 용이하다.

기능 목록의 상위 계층을 정의하기 위해서, 오브젝트 모델링 과정에서 도메인 전문가가 자연스럽게(무의식적으로) 구분한 고수준(high-level)의 분할(breakdown)로부터 도메인 주제 영역들을 도출해낸다. 이 영역들 내에서 팀은 그 영역의 비즈니스 활동(business activity)들을 식별하고 그러한 활동들 내에 존재하는 개개의 기능(feature)들을 식별한다. 즉, 기능 목록(feature list/set)은 도메인 주제 영역(area)에 대응하고, 비즈니스 활동들(activity)은 기능(features)들에 대응한다.

실제로는 기능 목록을 작성하는 것은 오브젝트 모델 개발 과정에서 이미 논의되었던 것들을 기능이라는 단위로 형식화(formalizing)하는 것이다. 때문에 선임 개발자는 이 작업을 수행할 때 모델링 과정에서 얻은 지식들을 사용할 수 있다. 모델링 팀의 다른 멤버들(도메인 전문가 등)은 이 단계에 필요한 정보들을 제공하거나 목록을 검증한다.

이는 종종 고객/도메인 전문가가 이런 종류의 형식화 분해(formal decomposition)에 참여하지 않아서 발생하는 문제를 피하게 해줄 뿐 아니라, 무엇이 요구되는지를 선임 개발자가 이해했다는 것을 확인하는 면도 있다.

게다가 모델이 제공하는 UL은 기능을 꾸준히 언급하는데 도움이 된다. 큰 팀에서는 종종 서로 다른 도메인 전문가들이 서로 다른 용어를 사용해서 문제가 되곤 한다.


=== Planning ===

Feature Sets가 iteration이 된다.

개발 순서를 결정한다. feature set들 간에 의존성이 있을테니 그것도 고려하고, 무엇이 위험도가 높은 기능인지도 고려하고, 복잡도가 높은 기능인지도 고려하고.

PM을 선정하고, feature set들에 선임 개발자들을 할당한다. 개발자들을 클래스 담당자(class owner)로 임명한다. 'Justin은 "Meat Storage" 클래스의 담당자고, Miki는 "Cow" 클래스의 담당자고'라는 식으로. Iteration 자체에 대한 진행은 워터폴로 해도 되고 애자일식으로 해도 된다. Feature Set이 iteration이 되는 것만 지켜지면 된다.

계획 팀은 액티비티를 나타내는 기능 집합을 연관성 있는 비즈니스 가치에 의해 순서를 결정한다. 기능 집합은 선임 개발자들에게 할당되고, 개발에 대한 책임을 진다. 이 과정이 마무리되면 각 선임 개발자들은 자신에게 할당된 기능 목록들을 받는다. 선임 개발자들에게는 이것이 일종의 백로그가 된다.

계획 팀은 기술적인 위험도나 의존성에 따라 순서를 변경할 수도 있다.

FDD는 코드 공유(collective ownership)를 채택하지 않는다는 측면에서는 전통적인 애자일 사고에서는 약간 벗어나 있다. 대신에 FDD는 각 개발자들에게 특정 클래스를 각각 나눠주고 책임을 지게 한다. 개발자들에게 클래스를 할당하는 것은 계획 과정에서 한다.

클래스 소유를 개인에게 지우는 것은 이런 장점이 있다.

 * 그 클래스에 대한 개념적인 일관성(integrity)을 책임지는 누군가가 있다. 개선이 일어나면 클래스 소유자는 클래스의 목적과 디자인이 흐트러지지 않았다는 것을 확인한다.
 * 특정한 클래스가 어떻게 작동하는지 설명할 수 있는 전문가가 존재하게 된다. 이것은 복잡하거나 비즈니스 크리티컬한 상황에서는 더욱 중요하다.
 * 클래스 소유자는 대개의 경우 그 클래스에 친숙하지 않은 다른 개발자들보다 더 빠르게 필요한 변화를 구현한다.
 * 클래스 소유자는 자신이 자랑스러워할만한 무언가를 소유하게 된다.

게다가 팀의 크기가 커질수록 코드 공동 소유를 실제로 유지한다는 것은 어려운 일이다. 대개의 경우 같은 개발자가 한 부분을 계속 담당하게 되어 고착되고, 그게 반복되면서 실질적으로 그들의 소유가 되곤 한다.

물론 코드 소유권에 대한 이슈가 있기는 하다. XP는 코드 공동 소유를 통해 실제로 존재하는 문제를 해결하는 경우가 있다. 어떤 개발자가 코드 변경을 하는 것을 기다리느라 다른 기능 구현들이 멈춰 있는 것은 바람직하지 않은 상황이다. 하지만 FDD 모든 개발자가 필요하다면 모든 부분을 수정할 수 있게 허용하는 것과는 다르게 문제를 해결한다.

첫째로, FDD에서는 클래스 소유권이라는 것은 책임을 의미하지만 배타적일 필요는 없다. 클래스 소유자는 다른 개발자들이 자신의 클래스를 수정하도록 허용할 수 있다. 큰 차이점은, 클래스 소유자는 자신의 클래스에 주의를 기울이면서 코드 변화가 올바르게 이루어졌는지 확인할 책임을 진다는 점이다.


== Resources ==

 * http://www.featuredrivendevelopment.com/files/fddoverview.pdf
 * http://www.featuredrivendevelopment.com/files/FeatureDrivenDevelopment_0.pdf
 * https://dzone.com/articles/introduction-feature-driven
 * https://dzone.com/articles/introduction-feature-driven-2