Come si integra il software standard con lo sviluppo agile?[Chiuso]

Question

Forse la mia comprensione dello sviluppo agile non è buona come dovrebbe essere, ma sono curioso di sapere come uno sviluppatore agile potrebbe potenzialmente utilizzare software off-the-shelf (OTS) quando i requisiti e la conoscenza di quale dovrebbe essere il sistema finale sono cambiando con la stessa rapidità con cui li capisco (spesso dopo ogni iterazione di sviluppo).

---

Vedo due situazioni che mi interessano particolarmente:

(1) Un sistema OTS soddisfa la serie iniziale di requisiti con modifiche minime o nulle, a parte la potenziale integrazione in un sistema esistente.Tuttavia, nel giro di poche iterazioni di sviluppo, questo sistema non soddisfa più le esigenze senza riscrivere il codice principale.Gli sviluppatori devono scegliere se dedicare ulteriore tempo all'apprendimento del codice principale dietro questo software OTS o buttarlo via e crearlo da zero.Entrambi avrebbero un impatto drastico sui tempi di sviluppo e sui costi del progetto.

(2) Le esigenze iniziali non sono come qualsiasi sistema OTS esistente disponibile, tuttavia, alla fine, quando il cliente accetta il prodotto, finisce per essere molto simile alle soluzioni esistenti a causa delle aggiunte e sottrazioni dei requisiti.Se gli sviluppatori avessero avuto più requisiti e avessero dedicato più tempo a lavorarci su in anticipo, questa soluzione avrebbe potuto essere utilizzata invece di ricostruire.Il progetto è stato consegnato, ma più tardi e ad un costo superiore al necessario.

---

In qualità di ingegnere del software, parte delle mie responsabilità (come mi è stato insegnato) sono fornire al cliente software di alta qualità in tempo e al minor costo possibile (tra le altre cose).Lo sviluppo agile consente software di alta qualità, ma in alcuni casi potrebbe non essere evidente che esistono alternative migliori finché non è troppo tardi e non sono stati spesi troppi soldi.

Le mie domande sono:

1. Come si integra il software standard con lo sviluppo agile?
2. Come affrontano questi casi il manager agile e lo sviluppatore agile?
3. Cosa dicono i paradigmi agili di questi casi?

Answer 1

Scenario 1:

Ciò può verificarsi indipendentemente dalla natura OTS del componente.Agile non significa miope..dovresti conoscere i pezzi grossi..la struttura viene elaborata e dedicare del tempo a pensarci sopra in anticipo.Detto questo, puoi costruire solo in base a ciò che sai..Ritarda solo fino all'ultimo momento responsabile. Poi devi scegliere una delle alternative e iniziare con quella.(Eviterei l'applicazione di terze parti a meno che il costo per svilupparla internamente non sia fattibile..ma sono solo io).Prototipare più soluzioni per verificare la fattibilità con l'elenco dei requisiti noti.Mantieni le cose liberamente accoppiate (sostituibili), facili da cambiare e completamente testate.Se raggiungi il bivio tra continuare a hackerare o riscrivere, dovresti pensare a quale ha un valore migliore per l'azienda e scegliere quell'opzione.La risposta è 'Ora che siamo qui, qual è la cosa migliore che possiamo fare adesso?'

Scenario2:

Ciò può accadere, anche se le possibilità sono scarse rispetto a quando il team impiega 2-3 mesi cercando di "finalizzare" i requisiti solo per scoprire che le esigenze del mercato o le menti dei clienti sono cambiate e "Ora lo vogliamo in questo modo".Ancora una volta, è una questione di quale sia il momento fino al quale sei pronto a investigare ed esplorare prima di impegnarti in un percorso d'azione.Decidi saggiamente con qualunque informazione tu abbia fino a quel momento..Il senno di poi è sempre 20-20 ma i clienti non aspetteranno per sempre.Non puoi aspettare fino al momento in cui i requisiti si uniscono per adattarsi a un componente OTS noto :)

Agile dice di fare tutto ciò che ha senso ed eliminare le attività che non aggiungono valore :) Agile non è una bacchetta magica. solo i miei 2 centesimi agili :)

Answer 2

Non è una risposta rigorosa di per sé, ma penso che l'utilizzo di software standard come componente di una soluzione software possa essere molto vantaggioso se:

• I suoi dati sono aperti, ad es.un database aperto o un servizio web per interagire con esso
• Il sistema standard può essere personalizzato facilmente utilizzando un paradigma di programmazione simile al resto della soluzione
• Può essere adattato perfettamente al resto del flusso di lavoro

Sono un grande sostenitore del non reinventare la ruota e utilizzare le tue capacità di sviluppo per progettare il "collante" tra soluzioni standard può essere una grande vittoria.

Ricorda che "aperto" è la parte importante e un fornitore spesso pubblicizza la propria soluzione come aperta quando in realtà non lo è.

Answer 3

Credo di aver letto da qualche parte che se durante un'iterazione scopri di avere più del 20% di lavoro in più rispetto a quanto pensavi inizialmente allora dovresti abbandonare lo sprint e iniziare a pianificarne uno nuovo tenendo conto del lavoro aggiuntivo.

Ciò significherebbe quindi riprogrammare l'azienda per vedere se vuole ancora portare avanti i requisiti originali ora che ne sai di più.

Nella nostra azienda utilizziamo anche la prototipazione prima dello sprint per cercare di identificare questo tipo di situazioni prima che si verifichino durante uno sprint.Anche se ovviamente ciò potrebbe ancora non identificare il tipo di situazione che descrivi.

Answer 4

Discussione wiki C2: http://c2.com/cgi/wiki?BuyDontBuild