Il vantaggio principale di avere un prodotto potenzialmente spedibile alla fine di ogni Sprint è la possibilità di rilasciare rapidamente il prodotto in caso di cambiamento delle condizioni di mercato.
Tuttavia, solitamente nel primo semestre o più il prodotto non ha abbastanza valore per essere effettivamente spedito. Allora perché spendere tutta questa energia per fare un incremento potenzialmente spedibile ogni Sprint se sai con certezza assoluta che il prodotto non verrà spedito?
E il più importante (almeno secondo me)
Potenzialmente spedibile non significa necessariamente che il prodotto abbia un senso o sia desiderabile dal punto di vista del mercato. Solo che funziona da uno di ingegneria.
Capisco "potenzialmente spedibile" come incoraggiamento a gestire il debito tecnico e funzionale:
Sembra che ti stai dipingendo in un angolo qui.
Non vedo perché un prodotto non possa essere minimamente redditizio entro poche settimane (se non giorni, ad esempio vedi hackathon) anziché mesi. Dipende dal prodotto e dal mercato e da chi stai effettuando la spedizione, e per quale scopo.
Che cosa intendi con "minimamente fattibile"? Ha bisogno di essere lucidato? Se sì, come sarebbe minimally praticabile? In molti casi ho visto prodotti che non sono mai stati minimamente fattibili perché "nessuno li comprava". Ma non è questo che significa mezzi minimamente praticabili. Un prodotto che non puoi vendere, ad esempio puoi dimostrarlo o provare. Oppure puoi regalare una versione minimale senza tutti i campanelli e i fischietti liberi per creare una base di utenti prima di introdurre nuove funzionalità.
Mantenere il prodotto sotto controllo fino a quando non è "pronto" (versione big-bang) è l'opposto di MVP. : -)
Per definizione, ogni iterazione fornirà valore sotto forma di incrementi potenzialmente shippabili . Poiché le iterazioni iterazioni forniscono valore , perché il prodotto minimamente non è valido? Sono d'accordo che non sarà grandioso, però, inizialmente e probabilmente non vendibile.
"Viable" non significa niente da solo: per quale scopo dovrebbe essere praticabile?
A chi spediamo? Non tutti gli utenti hanno gli stessi requisiti. Spesso puoi spedire a un sottoinsieme di utenti molto prima.
Un aneddoto personale. A Stack Exchange siamo sempre spedizione. Prendiamo le nostre app mobili: non appena abbiamo creato il sistema di creazione, abbiamo iniziato a utilizzarli internamente. C'è stata una compilazione per i dipendenti interni interessati entro poche settimane e un programma alfa / beta per utenti selezionati. La maggior parte di questi utenti non ha visto un'app lucida, completa e priva di errori, ma il feedback che abbiamo ottenuto è stato inestimabile. Siamo ora che spediamo la nostra prima app "per davvero", apertamente, al pubblico, ma non c'è dubbio che i nostri precedenti incrementi "potenzialmente spedibili" fossero estremamente preziosi per feedback e test sul campo.
No, il vantaggio principale di avere un prodotto potenzialmente spedibile alla fine di ogni iterazione è la capacità di ottenere un feedback tempestivo, di mostrare che gli sviluppatori stanno effettivamente facendo qualcosa e di motivare gli sviluppatori a fare effettivamente qualcosa. Il "potenzialmente spedibile" non ha nulla a che fare con l'essere in grado di spedirlo, ma il fatto che il software debba essere di qualità spedibile.
In questo caso, all'inizio del progetto non vi è alcun problema di avere un prodotto barebone, a condizione che il cliente sia in grado di produrre un feedback basato su di esso.
In parte il motivo è che spetta alle parti interessate determinare quando il prodotto è degno di essere rilasciato, e questa determinazione si basa sulla dimostrazione dei risultati di ogni sprint. In qualsiasi punto arbitrario, il prodotto potrebbe essere considerato "abbastanza buono" e rilasciato.
Potrebbero essere necessarie molte più iterazioni per portare a termine il progetto, ma è del tutto possibile che un sottogruppo di funzionalità molto piccolo fornisca la maggior parte del valore del prodotto, vale la pena farlo presto. Se la definizione delle priorità è corretta, tali funzioni dovrebbero essere eseguite per prime.
Le metodologie di sviluppo iterativo non fanno supposizioni su quanto sia presto raggiunto lo stadio "abbastanza buono", quindi è più facile assicurarsi che il prodotto possa essere sempre spedito.
È importante avere un prodotto che può essere spedito perché implica che la qualità del prodotto è stata mantenuta più elevata di quanto sarebbe se lo sviluppo fosse eseguito con un piano di spedizione a lungo termine.
Bisogna tenere a mente la motivazione per il requisito "spedibile". In molti progetti software con un lungo programma di sviluppo, molte risorse potrebbero andare a sviluppare una parte del software, di solito l'area chiamata "infrastruttura essenziale" quando si comunica con i manager di livello superiore. Ciò potrebbe causare uno squilibrio in base al quale troppe risorse vengono spese in un'area, mentre altre aree, come i test o la progettazione dell'interfaccia utente, sono affamate di risorse. Alla fine, le risorse potrebbero esaurirsi e il risultato finale è un prodotto inutilizzabile.
Se, al contrario, il prodotto viene mantenuto "spedibile", il progetto sembra almeno non essere uno spreco completo, anche se la spina viene spostata sullo sviluppo a metà strada.