¿Cuáles son algunos buenos criterios para usar Tracer Bullets?

Hace poco leí The Pragmatic Programmer por primera vez y me encontré con el concepto de Tracer Bullets. Me di cuenta de que había codificado de acuerdo con este modelo en el pasado y simplemente presenté la forma en que estaba trabajando en mi cerebro como "ágil".

Solo dan un ejemplo de dónde lo habían usado en el pasado. La forma en que se identificó la situación como un buen candidato para Tracer Bullets fue

Había muchas incógnitas y muchos entornos diferentes, y nadie estaba muy seguro de cómo debería comportarse la GUI.

Ese tipo de parece ser la forma en que comienzan una gran cantidad de proyectos, especialmente cuando trabajas con personas no técnicas en una línea típica de aplicación comercial para un fondo de cobertura (como ejemplo).

Lo usé porque simplemente se sentía bien, sin saber realmente cómo se llamaba o que me lo explicaran. Sabía que si intentaba poner a todos en una habitación y hacer que especificaran todo (o al menos algunas cosas) por adelantado, sería un completo desastre, pero de nuevo, eso es una especie de cosa ...

¿Alguien puede llegar a algunos criterios más concretos para cuándo este modelo podría ser el camino a seguir?

Debe tener un proyecto en el que pueda hacerse una idea sobre si está en el camino correcto con solo un pequeño subconjunto de funcionalidades. En general, esto es posible para cosas como el diseño básico de GUI, pero es difícil con cosas donde los resultados son desconocidos, por ejemplo, si está diseñando una aplicación de minería de datos y la forma de la herramienta dependerá de qué tipo de patrones ocurran en sus datos.

También debe estar en una situación en la que pueda permitirse iterar muchas veces. Esto cuesta tiempo y desarrollo (y, por supuesto, puede ser beneficioso si se suscribe a procesos de desarrollo ágiles), pero es más difícil el costo en términos de exposición a los usuarios. Los usuarios se agotarán rápidamente si les muestra demasiados diseños y la calidad de sus comentarios disminuirá. Por lo tanto, necesita un grupo de usuarios grande o elegir sus versiones (micro) con cuidado.

Diría que en realidad solo hay un factor básico que determina cuán útil es un enfoque de Tracer Bullet: la cantidad y el alcance de las incertidumbres en la arquitectura y el diseño de la aplicación.

Debido a que el objetivo principal (si no solo) de la técnica es aclarar tales incertidumbres, no se beneficiará mucho si no tiene ninguna o si no se refieren a la arquitectura o el diseño. Un proyecto greenfield sin restricciones arquitectónicas es un ejemplo típico para cuando comenzar con un Tracer Bullet es casi lo único sensato, mientras que un proyecto maduro con algunas características nuevas para implementar probablemente sea una pérdida de tiempo (aunque puede haber incertidumbres con respecto a los requisitos, aclararlos es más el dominio del desarrollo ágil o iterativo general).

Encontré el concepto de desarrollo de Tracer Bullet en el libro Ship It! , editado por los programadores pragmáticos .

Supongo que en su pregunta, se está refiriendo al libro El programador pragmático: de oficial a maestro . No he leído esa, y no sé cómo se presenta TBD allí. En Ship It! , hay un capítulo (20 páginas), dedicado a TBD. En particular, hablan de su experiencia con un ejemplo concreto: una aplicación de minería de datos para una empresa de biotecnología. Básicamente, explican que tener buenas capas de abstracción (diseñadas usando TBD) les ayudó a eliminar los cuellos de botella de rendimiento uno por uno, al parelizar cada capa.

En mi opinión, TBD es dos cosas:

• Cree una arquitectura de software aislando los objetos del sistema y permita que los desarrolladores colaboren para definir las interfaces entre estos objetos del sistema.
• Utilice objetos simulados para garantizar que la arquitectura sea sostenible (pruebe la arquitectura temprano)

Creo que el primer punto es una muy buena manera de diseñar un software, pase lo que pase. El segundo punto es interesante: puede evitar una reescritura completa de un proyecto debido a una arquitectura inicial que no funciona en la práctica.