Tracer Bullets를 사용하기위한 좋은 기준은 무엇입니까?

최근에 Pragmatic Programmer를 처음 읽었고 Tracer Bullets의 개념을 접했습니다. 나는 과거에이 모델에 따라 코드를 작성했으며 뇌에서 "민첩한"방식으로 일하는 방식을 정리했습니다.

과거에 사용했던 곳의 예를 하나 보여줍니다. 상황이 Tracer Bullets에 적합한 후보로 확인 된 방식은

알려지지 않은 환경과 다양한 환경이 있었으며 GUI의 작동 방식을 아무도 확신하지 못했습니다.

이러한 종류의 사례는 특히 많은 수의 프로젝트가 시작되는 방식으로 보입니다. 특히 비전문가와 함께 전형적인 비즈니스 응용 프로그램 라인에서 헤지 펀드 (예 : 헤지 펀드)를 사용하는 경우에 그러합니다.

나는 그것이 무엇이라고 불렀는지 나에게 설명하지 않고 단순히 기분이 좋았 기 때문에 그것을 사용했습니다. 나는 방에있는 모든 사람들을 데리고 모든 것을 (또는 적어도 몇 가지) 미리 설명하게하면 완전한 재앙이 될 것이지만 다시는 일종의 느낌이라는 것을 알았습니다 ...

이 모델이 언제 갈 수 있는지에 대한 더 구체적인 기준을 제시 할 수 있습니까?

작은 기능의 하위 집합만으로 올바른 길을 가고 있는지에 대한 아이디어를 얻을 수있는 프로젝트가 필요합니다. 일반적으로 기본 GUI 디자인과 같은 경우에는 가능하지만 결과를 알 수없는 경우에는 어려움이 있습니다. 예를 들어 데이터 마이닝 앱을 디자인하는 경우 도구의 모양은 데이터에서 발생하는 패턴 종류에 따라 다릅니다.

또한 여러 번 반복 할 여유가있는 상황에 있어야합니다. 시간과 개발 비용이 들지만 (애자일 개발 프로세스에 가입하면 유리할 수 있음) 사용자에게 노출되는 비용은 더 어렵습니다. 너무 많은 디자인을 보여 주면 피드백이 빨리 지쳐지고 피드백의 질이 떨어집니다. 따라서 큰 사용자 풀이 필요하거나 (마이크로) 릴리스를 신중하게 선택해야합니다.

Tracer Bullet 접근 방식이 얼마나 유용한 지 결정하는 기본 요소는 실제로 하나 뿐이라고 말하고 싶습니다. 응용 프로그램의 아키텍처와 디자인에서 불확실성의 수와 범위.

이 기술의 주요 목표는 이러한 불확실성을 해소하는 것이기 때문에 아키텍처 나 디자인에 관심이 없거나 관심이없는 경우 그 이점을 크게 누리지 못할 것입니다. 구조적 제약이없는 그린 필드 프로젝트는 Tracer Bullet으로 시작할 때 수행 할 수있는 유일한 예이며, 일부 새로운 기능이 포함 된 성숙한 프로젝트의 경우 시간 낭비 일 수 있습니다. 요구 사항에 대한 불확실성이있을 수 있으며, 요구 사항을 정리하면 일반적인 민첩성 또는 반복 개발 영역이 더 커집니다).

나는 Ship It! 책에서 Tracer Bullet 개발 개념을 발견했습니다 . 실용 프로그래머에 의해 편집 .

나는 당신의 질문에서 당신은 Pragmatic Programmer : Journeyman에서 Master로 책을 언급하고 있다고 생각합니다 . 나는 그 책을 읽지 못했고, TBD가 어떻게 제시되는지 모른다. 에서 선박이! , TBD 전용의 한 장 (20 페이지)이 있습니다. 특히, 그들은 생명 공학 회사의 데이터 마이닝 응용 프로그램 인 구체적인 예에 ​​대한 경험에 대해 이야기합니다. 기본적으로 멋진 추상화 계층 (TBD를 사용하여 설계됨)을 사용하면 각 계층을 병렬화하여 성능 병목 현상을 하나씩 제거 할 수있었습니다.

내 생각에 TBD는 두 가지입니다.

• 시스템 오브젝트를 분리하여 소프트웨어 아키텍처를 작성하고 개발자 가 이러한 시스템 오브젝트 사이 의 인터페이스를 정의하기 위해 협업하도록하십시오.
• 사용 mock 객체를 아키텍처가 지속 보장 (초기 아키텍처를 테스트)에

첫 번째 요점은 소프트웨어를 설계하는 아주 좋은 방법이라고 생각합니다. 두 번째 요점은 끼어 들기입니다. 실제로 작동하지 않는 초기 아키텍처로 인해 프로젝트가 완전히 다시 작성되는 것을 막을 수 있습니다.