Agile è applicabile anche nelle società di sviluppo prodotto? [chiuso]

Il metodo Agile (e qualsiasi altro iterativo) è ancora più utile per le società di sviluppo prodotto rispetto al settore dei servizi.

In uno dei miei primi incarichi in una start-up di sviluppo del prodotto, abbiamo gestito con la gestione uno scope molto dettagliato (compresa la stampa fine) e il mio capo ha buttato fuori la maggior parte di esso e ha ridotto il requisito a quasi tutti i fondamentali; il prodotto non ha gizmo, nemmeno campane e fischietti.

Dopo la conclusione il punto cruciale è bisogno di sperimentare con il mercato , come ha detto

... look, we are not a services company. Many typical service contracts (he gave examples of companies) starts out with unnecessary stuff; later on when people realize gaps, it's essentially more money to the services company. In a product development, we cann't afford to waste resources like that.

ha continuato ...

... when you build a product, you really have to go out and experiment with the market to understand what is really needed, that's when you go and build this (extra) things on top of the core product.

Quindi dal punto di vista dello sviluppo del prodotto, qualsiasi metodologia che inizia con l'attenzione ai requisiti minimi ed essenziali è la più importante. Agile si adatta perfettamente.

In secondo luogo, vi sono altre cose fondamentali che le aziende di sviluppo prodotto devono affrontare con maggiore ferocia, time to market .

Mentre ti stai sviluppando, invariabilmente, ti renderai conto che apparirà qualche concorrente, e tenderai a cercare di ridurre al minimo l'ambito il più possibile per arrivare al mercato velocemente, o potresti imparare quel bisogno del mercato deve adattarsi.

Agile è ancora più importante per l'ambiente di sviluppo del prodotto rispetto alle società di servizi.

Un avvertimento:
Può essere un posto in cui posso pensare che Agile sia disadattato sia dove c'è un bel po 'di lavoro di ricerca. Anche il lavoro basato sulla ricerca richiede una pianificazione per attività individuali; tuttavia, all'improvviso ci si rende conto di enormi problemi o arriva una nuova idea, e la pianificazione procede per un lancio. Probabilmente qui, qualsiasi approccio strutturato trova qualche limite. Qualcuno ha provato Agile nel lavoro orientato alla ricerca ?

Agile traccia le sue origini al Toyota Production System , che alla fine ha influenzato l'intera industria automobilistica, che a sua volta ha influenzato l'intera industria manifatturiera.

L'ingegneria del software è design del prodotto. Il nostro codice è l'equivalente dello strumento & progettazione dello stampo e progettazione dei processi industriali richiesti per la fabbricazione di prodotti fisici. I compilatori sono i lavoratori.

Definisci chi credi che i tuoi clienti siano. Sono le persone che acquistano i prodotti della tua azienda, sono le persone della tua azienda che potrebbero usare e testare il tuo codice, o forse sono entrambi? Quando scrivi il tuo codice e lo invii per il test, completi prima l'intero prodotto o lo consegni in fasi da testare e firmare?

Indipendentemente dal fatto che Agile lavori in qualsiasi azienda, tutto si riduce alla mentalità delle persone che lavorano con esso, al modo in cui la squadra ci pensa e quanto si impegnano a fare in modo che una metodologia Agile funzioni per loro.

In fin dei conti, Agile è adatto al team che vuole farlo funzionare per loro, e sì questo significa che può essere implementato con successo anche in alcune delle situazioni di sviluppo più "spaventose", a patto che la metodologia sia adattata alle proprie esigenze. Non importa se ritieni che la tua azienda sia focalizzata sul servizio o sul prodotto.

La cosa da ricordare è che andare in Agile non significa copiare la metodologia di qualcun altro in modo letterale, il che andrebbe bene se la metodologia fosse in grado di soddisfare le esigenze della tua particolare azienda. Alla fine, quando si cambia il modo di scrivere software, qualcosa deve dare. Si tratta di raggiungere un compromesso tra la visione di un flusso di lavoro agile e i processi aziendali esistenti che potrebbero dover essere modificati per adattarsi a processi agili. Questo non è qualcosa che puoi cambiare facilmente da un giorno all'altro, ma che cambia gradualmente, e in fasi, mentre affini il processo agile e aziendale in modo che si gelificino l'uno con l'altro. Potrebbe anche richiedere un cambiamento nel tuo modo di pensare, in modo da applicare tutti i concetti agili di cui i tuoi sviluppatori hanno bisogno, e ignorare quelli che potrebbero creare problemi per il tuo team, e il tuo "cliente agile" diventa un "rappresentante del cliente" all'interno del azienda che si assume la responsabilità di essere la campionessa del prodotto, agendo come "voce" del cliente nella squadra solo per mantenere tutti saldamente radicati.

Nell'azienda in cui lavoro, probabilmente facciamo solo la metà delle cose che tutte le metodologie standard raccomandano che dovremmo fare e, per il resto, abbiamo messo a punto le cose per soddisfare le nostre esigenze. Ogni volta che ci imbattiamo in qualcosa che è inefficiente, implementiamo le modifiche al metodo per affrontare il problema. Questo può accadere da un progetto all'altro in rare occasioni, a seconda di chi stiamo lavorando e per chi lavoriamo. Quindi, alla fine, il modo specifico di implementare l'agile nel tuo posto di lavoro dipende in realtà da te. La chiave di tutto è semplicemente mantenere una mente aperta e rivalutare regolarmente le prestazioni della tua squadra, rimuovendo le pratiche che peggiorano le cose e introducendo le pratiche che migliorano le cose.

Buona fortuna.

Soddisfazione del cliente mediante consegna rapida di software prodotto

Benvenuto nel modificare i requisiti del prodotto o dell'ingegneria , anche in ritardo nello sviluppo

Il software prodotto di lavoro viene consegnato frequentemente prima (settimane anziché mesi) e il tempo di ciclo del prodotto è ridotto .

Lavorando a stretto contatto con il product owner . Spesso ciò implica che un rappresentante del cliente il proprietario del prodotto sia una parte del team di sviluppo.

La conversazione faccia a faccia è la migliore forma di comunicazione (co-locazione)

In breve, come può Agile non applicare allo sviluppo del prodotto?

Un precedente datore di lavoro ha utilizzato sia software "shrinkwrap" agile che consegnato. Alcuni dei prodotti sono stati spediti ogni anno per 2 decenni. Gli sprint erano generalmente di 2 settimane, e la programmazione delle coppie era comune, specialmente quando le scadenze erano strette.

Welcome changing requirements, even late in development

Alcuni dei loro prodotti sono stati utilizzati dai clienti per compilare moduli governativi. Generalmente, l'IRS ha moduli annuali aggiornati entro l'intervallo di tempo di ottobre / novembre per le cose che devono essere presentate a gennaio (e ad aprile). Alcuni anni, il Congresso spende troppo tempo a fare finta di ottenere i cambiamenti della legge fiscale in tempo, quindi ci sono stati alcuni anni in cui le forme che hanno una data di deposito del 31 gennaio (come W-2) non sono finite dall'IRS prima del 15 gennaio.

L'obiettivo era di avere diverse versioni pianificate durante un anno, ma ci sono stati alcuni anni in cui abbiamo avuto molti aggiornamenti a causa della modifica dei regolamenti (e dei bug fix).