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

Question

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

#1 da (5 voti)
#2 da (2 voti)
#3 da (0 voti)

9

Recentemente ho letto The Pragmatic Programmer per la prima volta 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 archiviare il modo in cui stavo lavorando nel mio cervello come "agile".

Forniscono solo un esempio di dove lo avevano usato in passato. Il modo in cui la situazione è stata identificata per essere un buon candidato per Tracer Bullets era

There were many unknowns, and many different environments, and no one was too sure how the GUI should behave.

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

L'ho usato perché semplicemente mi sembrava giusto, senza sapere veramente come si chiamava o se mi aveva spiegato. Sapevo che se avessi cercato di far entrare tutti in una stanza e averli spinti a specificare tutto (o almeno alcune cose) in anticipo sarebbe stato un disastro completo, ma ancora una volta è una cosa del genere ...

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

language-agnostic

posta Jason Punyon 07.05.2009 - 18:18

fonte

3 risposte

Leggi altre domande sui tag language-agnostic

Quante copie sono necessarie per ingrandire un array? Come gestisco i progetti in cui il mio project manager è lo stesso del client?

score 5 · Answer 1

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

Devi anche essere in una situazione in cui puoi permetterti di ripetere molte volte. Questo costa tempo e sviluppo (e ovviamente può essere utile se si sottoscrive un processo di sviluppo agile), ma più difficile è il costo in termini di esposizione agli utenti. Gli utenti si esauriranno rapidamente se mostrerai loro troppi disegni e la qualità del tuo feedback sarà alquanto ridotta. Quindi hai bisogno di un grande pool di utenti o di scegliere con cura le tue (micro) versioni.

score 2 · Answer 2

Direi che c'è davvero un solo fattore di base che determina quanto sia utile un approccio a Tracer Bullet: il numero e la portata delle incertezze nell'architettura e nella progettazione dell'applicazione.

Poiché l'obiettivo principale (se non solo) della tecnica è quello di chiarire tali incertezze, non ne trarrai beneficio 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à da implementare sarebbe probabilmente una perdita di tempo (anche se ci possono essere incertezze riguardo ai requisiti, chiarirli è più il dominio dello sviluppo generale o iterativo generale.

score 0 · Answer 3

Mi sono imbattuto nel concetto di sviluppo di Tracer Bullet nel libro Ship It! , edito da i programmatori pragmatici .

Immagino che nella tua domanda ti riferisca al libro The Pragmatic Programmer: From Journeyman to Master . Non ho letto quello, e non so come viene presentata la TBD. In Spedisci! , c'è un capitolo (20 pagine) dedicato al TBD. In particolare, parlano della loro esperienza con un esempio concreto: un'applicazione di datamining per un'azienda biotech. 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, parellelandizzando ogni strato.

A mio avviso, TBD è due cose:

Crea un'architettura software isolando gli oggetti di sistema e lascia collaborare gli sviluppatori per definire le interfacce tra questi oggetti di sistema
Utilizza oggetti fittizi per garantire che l'architettura sia sostenibile (verifica l'architettura in anticipo)

Penso che il primo punto sia un ottimo modo per progettare un software, indipendentemente da cosa. Il secondo punto è l'interrelazione: può potenzialmente impedire una completa riscrittura di un progetto a causa di un'architettura iniziale che non funziona nella pratica.