Questo è un post tradotto da IA.
[Storia di uno sviluppatore SI] 09. L'inizio dello sviluppo vero e proprio dopo l'inserimento nel progetto SI
- Lingua di scrittura: Coreana
- •
-
Paese di riferimento: Tutti i paesi
- •
- Tecnologia dell'informazione
0000-00-00 00:00:00
Seleziona la lingua
Testo riassunto dall'intelligenza artificiale durumis
- Dopo l'inserimento nel progetto SI, lo sviluppo diventa effettivamente parte del progetto, ma la frequente modifica dei requisiti del cliente rende fondamentale uno stile di sviluppo flessibile.
- L'ambiguità dei requisiti del cliente porta a frequenti richieste di funzionalità aggiuntive o modifiche durante il processo di sviluppo, il che può portare a duplicazione di codice e riduzione dell'efficienza.
- Pertanto, nello sviluppo SI, è importante raggiungere una rapida velocità di sviluppo e una stretta comunicazione con il cliente per ottenere un feedback continuo, e le richieste aggiuntive non necessarie devono essere attentamente valutate.
Storia dello sviluppatore SI
#9. Dopo l'inserimento nel progetto SI - L'inizio dello sviluppo vero e proprio
Dopo essere entrati nel progetto, dopo un periodo di adattamento, si inizia a lavorare sullo sviluppo vero e proprio. Lo sviluppo avviene in base alle funzionalità presenti nel RFP (Documento di definizione dei requisiti) e in base alla tempistica del WBS, ma nell'ambito SI si considera che le funzionalità possano cambiare in qualsiasi momento, quindi si cerca di rendere il più possibile sciolto il collegamento con gli altri moduli.
Il motivo è che la società cliente che ha commissionato il progetto, pur conoscendo il proprio lavoro, non è in grado di fornire indicazioni su quali funzionalità siano necessarie, come debba essere strutturata l'interfaccia, ecc. Di conseguenza, una volta che viene mostrata un'interfaccia sviluppata, è molto comune che emergano ulteriori requisiti o modifiche.
Pertanto, se il collegamento con gli altri moduli è stretto, per modificare un modulo bisogna modificare anche gli altri, cosa che può comportare effetti collaterali imprevisti e quindi una proliferazione disordinata di duplicazione di codice.
L'obiettivo dell'SI è che il sistema funzioni in qualche modo, quindi la chiarezza del codice e l'efficienza passano in secondo piano.
All'inizio si è tentati di fare bene le cose, ma i tempi stretti e le richieste del cliente che ogni giorno chiede modifiche spingono a lavorare sempre più velocemente.
Inoltre, il cliente, visto che ha pagato, spesso pensa che il lavoro debba essere fatto senza il suo intervento. Questo è un campanello d'allarme per l'inferno che si scatenerà alla fine del progetto, quindi se non si sa qualcosa, è meglio chiedere e fare chiarezza.
Quando si sviluppa nell'ambito SI, bisogna tenere presente quanto segue:
- Il contenuto può cambiare in qualsiasi momento.
- Il cliente non sa niente. Bisogna mostrargli le schermate una per una, a piccoli blocchi, e chiedere un feedback frequente.
- Non bisogna dire sì a ogni richiesta di modifica, a meno che non sia veramente necessaria.
- Non sono Bill Gates. I clienti preferiscono le interfacce che vengono create rapidamente a un programma ben progettato.
