Quali sono alcuni buoni criteri per l'utilizzo di Tracer Bullets?

Recentemente ho letto per la prima volta The Pragmatic Programmer e mi sono imbattuto nel concetto di Tracer Bullets. Mi sono reso conto di aver codificato in base a questo modello in passato e di aver semplicemente archiviato il modo in cui stavo lavorando nel mio cervello come "agile".

Danno solo un esempio di dove lo avevano usato in passato. Il modo in cui la situazione è stata identificata come un buon candidato per i proiettili Tracer è stato

C'erano molte incognite e molti ambienti diversi e nessuno era troppo sicuro di come si sarebbe comportata la GUI.

Questo tipo di sembra il modo in cui un numero enorme di progetti inizia, specialmente quando lavori con persone non tecniche su una tipica linea di business app per un hedge fund (come esempio).

L'ho usato perché sembrava semplicemente giusto, senza sapere davvero come si chiamava o non me lo spiegava. Sapevo che se avessi provato a mettere tutti in una stanza e avessi potuto specificare tutto (o almeno alcune cose) in anticipo sarebbe stato un disastro completo, ma di nuovo è una specie di sensazione ...

Qualcuno può trovare alcuni criteri più concreti per quando questo modello potrebbe essere la strada da percorrere?

Devi avere un progetto in cui puoi farti un'idea se sei sulla strada giusta con solo un piccolo sottoinsieme di funzionalità. In genere questo è possibile per cose come la progettazione di base della GUI, ma è difficile con cose in cui i risultati sono sconosciuti, ad esempio se si sta progettando un'app di data mining e la forma dello strumento dipenderà dal tipo di pattern che si verificano nei dati.

Devi anche trovarti in una situazione in cui puoi permetterti di ripetere più volte. Questo costa tempo e sviluppo (e ovviamente può essere utile se ti abboni a processi di sviluppo agili), ma più difficile è il costo in termini di esposizione agli utenti. Gli utenti si esauriranno rapidamente se mostri loro troppi progetti e la qualità del tuo feedback diminuirà di molto. Quindi hai bisogno di un grande pool di utenti o di scegliere attentamente le tue (micro) versioni.

Direi che esiste davvero solo un fattore di base che determina quanto sia utile un approccio Tracer Bullet: il numero e la portata delle incertezze nell'architettura e nel design dell'applicazione.

Poiché l'obiettivo principale (se non solo) della tecnica è chiarire tali incertezze, non ne trarrai alcun vantaggio se non ne hai o non riguardano l'architettura o il design. Un progetto greenfield senza vincoli architettonici è un tipico esempio di quando iniziare con un Tracer Bullet è quasi l'unica cosa sensata da fare, mentre per un progetto maturo con alcune nuove funzionalità per implementarlo sarebbe probabilmente una perdita di tempo (anche se ci possono essere incertezze riguardo ai requisiti, chiarire quelli è più il dominio dello sviluppo agile o iterativo generale).

Mi sono imbattuto nel concetto di sviluppo di Tracer Bullet nel libro Ship It! , a cura dei programmatori pragmatici .

Immagino che nella tua domanda ti riferisca al libro The Pragmatic Programmer: From Journeyman to Master . Non l'ho letto e non so come sia presentato TBD lì. In Ship It! , c'è un capitolo (20 pagine), dedicato a TBD. In particolare, parlano della loro esperienza con un esempio concreto: un'applicazione di datamining per un'azienda biotecnologica. Fondamentalmente, spiegano che avere dei bei livelli di astrazione (progettati usando TBD) li ha aiutati a rimuovere i colli di bottiglia delle prestazioni uno per uno, parellellizzando ogni livello.

A mio avviso, TBD è due cose:

• Crea un'architettura software isolando gli oggetti di sistema e consenti agli sviluppatori di collaborare per definire le interfacce tra questi oggetti di sistema
• Utilizzare oggetti finti per garantire che l'architettura sia sostenibile (testare l'architettura in anticipo)

Penso che il primo punto sia un ottimo modo per progettare un software, non importa quale. Il secondo punto è interessante: può potenzialmente impedire una completa riscrittura di un progetto a causa di un'architettura iniziale che non funziona in pratica.