Come dovrei valutare il costo del test rapido per il segnale del cliente rispetto alla progettazione iniziale corretta?

C'è ovviamente una scala mobile in queste cose, ma il mio consiglio numero uno per te è di smettere di usare termini caricati emotivamente come "pianificazione adeguata" o "veloce contro lento".

Basta essere chiari sui requisiti tecnici e non ci sono requisiti non dichiarati nascosti. (più facile a dirsi che a farsi)

Ciò consente allo sviluppatore di valutare se stanno saltando fuori le funzionalità per andare veloci o di aggiungere funzionalità extra che non dovrebbero essere perse.

In secondo luogo, sii chiaro sugli obiettivi strategici della squadra. Cioè ottenere 10 progetti demo completati entro il terzo trimestre o qualsiasi altra cosa.

Ciò consentirà agli sviluppatori di giudicare quanto tempo dovrebbero dedicare a ciascun progetto.

In terzo luogo. Prendi in considerazione il tuo cliente. Alcune persone odiano vedendo prodotti incompleti "ovviamente voglio che sia completamente stilizzato secondo la mia guida alla progettazione aziendale! Fammi vedere quando è finito!" e un po 'di odio è stato chiesto per i requisiti in anticipo: "Non posso dirti dove voglio il pulsante fino a quando non lo vedo, solo mostrami qualcosa e ti dirò di più."

We are ... responsible for testing a bunch of new ideas.

Quindi è necessario concentrarsi sul prodotto minimo vitale. Fondamentalmente, sono d'accordo con B: ottenere feedback precoci e iterare ti darà un prodotto risultante più strong, dal punto di vista degli utenti . Ciò non significa ingegneria scadente, ma significa appoggiarsi pesantemente su YAGNI , e significa certamente che la spesa un sacco di tempo per il design up-front è una cattiva idea. A è probabile che all'inizio trovi questo frustrante, ma spero che, vedendo il prodotto crescere per adattarsi agli utenti, vedranno il valore.

Guarda in questo modo: A è preoccupato che dovrai rielaborare le cose. Ma qualunque percorso tu segua finirà per ricostruire roba, perché era impopolare con gli utenti o un nuovo requisito incompatibile con l'approccio precedente. Se hai passato settimane a progettare la soluzione perfetta al vecchio problema, questo è estremamente frustrante; se hai passato solo dei giorni, non così tanto. Il Pragmatic Programmer parla di punti traccianti , ottenendo un feedback dal vivo su quanto sei vicino al bersaglio (particolarmente prezioso con un bersaglio in movimento, o in cui non sei ancora sicuro di dove si trova).

Pensa anche a cosa succede a tutto ciò che ha successo. Se sei lo skunkworks e qualcosa si dimostra utile, ti viene tolto dalle mani e donato a qualcun altro? Stanno davvero fornendo valore all'organizzazione più ampia creando un prodotto raffinato, oppure farebbero meglio a tutti se il tuo team dimostrasse il valore fondamentale del prodotto e lascerebbe che il team che lo fa si costruisse su di esso o si riprogettasse come meglio credeva? Potrebbero essere più felici con una serie di utili informazioni sui clienti, un prototipo funzionante e alcuni test end-to-end sulle funzionalità principali che possono essere riutilizzate per ricostruirli a modo loro.

Quindi cosa puoi fare a riguardo? In primo luogo, è chiaro quali sono gli obiettivi del team, in che modo verrà misurato il successo della squadra e dei loro prodotti. Se hai un sacco di nuove idee da provare con un piccolo team e tempi brevi, non puoi fare tutto perfettamente (se riesci anche a capire cosa sia "perfettamente", ma è tutto altra risposta), quindi sia chiaro se dovrebbero dare la priorità alla costruzione di un numero minore o maggiore o superiore a uno standard più elevato. Aiutali a prendere le decisioni tecniche che non puoi, fornendo loro un quadro in cui misurare e confrontare i risultati.

In secondo luogo incoraggia entrambi a collaborare da vicino, o addirittura a unire un programma. Ho trovato l'abbinamento con altri ingegneri con tendenze diverse per essere un buon modo per trovare un equilibrio positivo tra i nostri punti di forza e di debolezza; B può incoraggiare A a vedere il valore nei primi feedback e scoraggiare le loro tendenze al piatto d'oro, mentre A può usare la loro inclinazione a pensare al quadro più ampio per far fronte a qualsiasi decisione "senza uscita" che funzioni contro la capacità del team di continuare a svilupparsi l'app quando arrivano nuovi requisiti.

Come grande sostenitore dell'architettura e del design in prima linea, devo accettare con riluttanza che l'ingegnere B è corretto in questo specifico scenario.

La tua squadra ha l'impressione che la sua responsabilità principale non sia quella di costruire un prodotto altamente specifico, ma suona più come un incubatore di prodotti futuri sviluppando prototipi. Nelle tue specifiche circostanze è meglio concentrarsi sulla costruzione di un prototipo e consegnarlo a un altro team per il perfezionamento in un prodotto appropriato. Direi che a quel tempo dovrebbe essere fatta un'architettura adeguata e un design iniziale, e questo ti aiuterà a identificare importanti requisiti tecnici non funzionali del tuo Qualità del sistema .

L'altra squadra potrebbe scoprire che il percorso appropriato è il refactoring di grandi parti del prototipo, tuttavia è prevedibile. A volte la rilavorazione può essere molto meno costosa di essere in ritardo rispetto al mercato o alla produzione. Guarda i primi giorni di Twitter. È stato essenzialmente sviluppato rapidamente con un piccolo progetto iniziale utilizzando tecniche RAD con tecnologie Ruby. Quando Twitter è diventato popolare, questo rapidamente non è stato ridimensionato, quindi le parti grandi sono state riscritte in Java.

Con tutto ciò detto, anche con Design in anticipo, si dovrebbe tenere presente che gli artefatti di progettazione sono utili solo come mezzo per comunicare o trasmettere un'idea tecnica. Un ottimo libro sull'argomento di quanto l'architettura sia sufficiente può essere trovato qui ... Basta Architettura Software, A Risk Driven approccio .

Falli lavorare.

Se vengono da te per rompere un pareggio con una divergenza di opinioni, non fingere di sapere meglio quando non lo fai. Se qualcosa ti colpisce come sbagliato, non dirlo, a meno che tu non possa spiegare chiaramente perché. Non votare quando non lo sai. Se puoi contribuire con la conoscenza, allora va bene. Se non sono disposti a raggiungere un compromesso equilibrato, l'autorità suprema in un pareggio è una moneta.