Suggerimenti per evitare la sindrome del secondo sistema

Question

Ultimamente ho visto il nostro team di sviluppo avvicinarsi pericolosamente alle idee di tipo "second system syndrome" mentre stiamo pianificando la prossima versione del nostro prodotto. Mentre io sono tutto per apportare miglioramenti e annullare alcuni degli errori del nostro passato, mi dispiacerebbe vederci bloccati in un ciclo infinito di riscrittura e mai lanciare nulla.

Esiste un buon metodo di progettazione/sviluppo che si presta alla creazione di una versione 2.0 migliore evitando al contempo scenari di sistema secondari?

Answer 1

"Mi dispiacerebbe vederci bloccati in un ciclo infinito di riscrittura e mai il lancio di nulla. "

Ecco perché le persone utilizzano Scrum.

1. Definire un backlog di cose da costruire.

2. Priorità, in modo che le cose che portano a un rilascio siano le prime. Le cose che dovrebbero essere riparate sono seconde.

3. Eseguire scatti per ottenere il rilascio. Esegui uno scatto di rilascio.

Answer 2

Concentrarsi sull'architettura di sistema dovrebbe aiutare ad es.

• vista interfacce documentate che supportano "accoppiamento lasco" tra i sottosistemi
• aver documentato decisioni di progettazione (evitare di ri-hashing percorsi precedentemente battute)

Quindi, senza passare per un tutto Alternando , il sistema attuale può essere "aggiornato" con interfacce più appropriate per aiutare la crescita futura.

---

Un altro buon modo per mettere a fuoco: assegnare una cifra $$$ per ogni funzione e dare la priorità di conseguenza ;-)

In ogni caso, solo i miei 2Cents

Answer 3

cercare di concentrarsi sui cicli brevi di consegna, vale a dire sforzatevi di fornire qualcosa di tangibile e utile per gli utenti ogni poche settimane o mesi. Dare priorità alle attività in base al loro valore per il cliente. In questo modo hai sempre un'applicazione utilizzabile e funzionale con utenti soddisfatti, mentre sotto il cofano puoi rifattorizzare l'architettura a piccoli passi se lo desideri (e se puoi giustificarne la necessità - cioè, verso la direzione/i clienti, non solo compagni di squadra!).

È di grande aiuto se si dispone di un processo di compilazione stabile con una buona suite di test automatici (unità/integrazione).

I metodi di sviluppo agili come Scrum fanno questo e sono vivamente consigliati. Ma ovviamente non è sempre facile o addirittura possibile adattare un tale metodo alla tua squadra. Anche se non puoi, puoi ancora prenderne elementi e applicarlo a beneficio del tuo progetto (magari senza menzionare pubblicamente le parole "agile" o "Scrum" ;-)

Answer 4

Ottieni qualcuno che abbia scritto almeno tre sistemi per guidare il progetto.

Answer 5

Assicurati di documentare i requisiti nel miglior modo possibile.Anche se ovviamente è necessario gestire anche ciò che entra nei requisiti per evitare la sovra-progettazione, avere un ambito fisso aiuta a impedire agli sviluppatori di scappare con idee o placcatura d'oro che cosa deve essere fatto e aiuta a mantenere la gestione o i clienti dall'introduzione dello scope creep . Definire tutti i requisiti e in che modo verranno affrontati i cambiamenti dell'ambito.

Sono tutto per cicli di sviluppo brevi (assicurati di scrivere test) e metodologia agile, ma nessuno di questi è uno scudo contro il sistema della seconda sindrome. In un certo senso è più facile continuare ad aggiungere funzionalità dopo funzione se si sta lavorando in sprint brevi senza fermarsi a guardare l'immagine complessiva. Usa pratiche agili per costruire la cosa più semplice che funzioni, quindi continua ad aggiungere gli altri requisiti nel modo più semplice possibile. Ricorda YAGNI, perché quando costruisci un sistema una seconda volta, è più probabile che tu costruisca qualcosa di cui avrai sicuramente bisogno ad un certo punto, qualcosa che renderà il sistema "estendibile" quindi non ci sarà mai bisogno di essere una terza build. È la migliore delle intenzioni, ma la strada per l'inferno e tutto il resto.

Answer 6

I up-votato risposta di S. Lott e vorrei aggiungere alcuni suggerimenti:

1. consegnare un prodotto di lavoro per il cliente il più frequentemente possibile. Le iterazioni della durata di alcune settimane e di 2 mesi sono ideali. Metodologie agili, come Scrum, si prestano bene a questo.

2. Utilizzare FogBugz per funzionalità e tracciamento dei bug. Le sue caratteristiche sono molto pratiche per progetti agili. FogBugz consente una facile definizione delle priorità in base a rilasci e priorità. Se il tuo team inserisce i livelli di sforzo stimati per ciascuna attività, puoi anche utilizzarlo per calcolare date di spedizione ragionevoli.

3. Dare priorità alle funzionalità sviluppate in base allo standard 80/20 rule (il 20 percento delle funzioni verrà utilizzato l'80 percento delle volte) e il massimo del prezzo. Ciò aiuta a mantenere il sistema il più semplice possibile, aiuta a prevenire feature bloat e risparmia tempo di sviluppo e test.

4. Dare un pensiero simile a entrambe le nuove funzionalità e bug quando si determina la priorità di un problema. Un punto di the Joel Test è "Correggi bug prima di scrivere un nuovo codice?". Nella maggior parte dei negozi questo non accade, ma non fare un debugging del sistema in un secondo momento. Inoltre, mantieni una copia funzionante del vecchio sistema da confrontare quando vengono trovati bug nel nuovo sistema.

5. Anche fattore nel livello di sforzo richiesto per mantenere e, se necessario, riscrivere, codice esistente. Se non lo hai già fatto, dai al team un po 'di tempo per revisionare tutti i file che trovano problematici da modificare. Se il codice del sistema è stato difficile da mantenere per la prima volta, ciò peggiorerà e farà sì che la tua squadra dedichi più tempo alle nuove funzionalità.

Answer 7

Ho esperienza della seconda sindrome di sistema da entrambe le parti come cliente/sponsor e parte di un team di sviluppo.

Una causa dei problemi è quando il team si attacca a una visione utopica della versione 2, come il desiderio di rendere il nuovo software "flessibile". In questo scenario tutto è astratto all'ennesima potenza. Ad esempio, anziché gli oggetti dati che rappresentano entità reali, viene creato un oggetto "oggetto" generico che può rappresentare qualsiasi cosa. Un'idea sbagliata è che possiamo costruire tanta flessibilità nel software per anticipare le esigenze future, che i non programmatori saranno in grado di configurare semplicemente nuove funzionalità. Spesso un obiettivo come la "flessibilità" oscura lo sforzo fino al punto che il software risultante non funziona.

Un'equilibrata considerazione pratica di usabilità, prestazioni, scalabilità, caratteristiche, manutenibilità e obiettivi di flessibilità può riportare il team sulla terra. "Sarebbe bello se ..." dovrebbe essere vietato dal vocabolario della squadra. Il backlog Scrum è un buon strumento e il team dovrebbe essere sentito dire spesso ... "Facciamo il backlog che ... non abbiamo bisogno di quello per la versione 2."

Answer 8

Non può mai essere evitato nella sua interezza. Ma essere prudenti potrebbe alleviare il problema. È consigliabile formulare una regola del pollice in base ai parametri vitali (risorsa più scarsa) che definiscono il successo del sistema. Ad esempio, la riduzione del numero potenziale di bug potrebbe ridurre direttamente i costi operativi (potenziali chiamate di assistenza al centro di supporto). Ma questo potrebbe non essere il caso in tutti gli altri sistemi. Un altro esempio, l'uso scarso di CPU, memoria e altre risorse potrebbe essere utile in alcuni casi, ma potrebbero esserci ambienti in cui potrebbero essere disponibili in abbondanza.

Così semplicemente per evitare "tentazioni", identificare la risorsa più scarsa (tempo, fatica, denaro $, ecc) e prendere in considerazione solo quelli che superano il valore di soglia di attuazione. [F (s1, s2 ...)> Soglia]

Nonostante lo sviluppo iterativo, vorrei sottolineare come vengono gestiti i debiti tecnici.
collegamenti che sono legati a questo:
Tech Debts: Effort Vs Time
Tech Debt Quadrant

Answer 9

Non si può arrivare vicino alla sindrome secondo sistema. O ci sei dentro, o sei lontano da esso. Saprai quando ci sei dentro, ma solo dopo aver sprecato molte risorse.

I suggerimenti sono: conoscono lo (quindi, in sostanza, abbiamo già coperto quello). È un'informazione preziosa per sapere che cos'è un "secondo sistema" e ancor più per avere un po 'di esperienza in questo. Penso che tutti noi abbiamo qualche esperienza con questo, si spera benigno.

Questa conoscenza spesso ti fa pensare due volte e troverai una soluzione senza avventurarti in un limbo del secondo sistema.

PS: Conosce anche come utilizzare il sistema attuale, che include soluzioni, magari documentate, e altra documentazione.