Quanto tempo è troppo presto per essere coinvolti nello sviluppo di nuove funzionalità?

Non esiste una regola generale, è sempre un compromesso.

• Da un lato, coinvolgere presto gli ingegneri del settore SW potrebbe significare un sacco di lavoro inutile per loro, perché discutono e pensano a problemi che risultano essere irrilevanti.
• D'altra parte, coinvolgere presto gli ingegneri SW consente loro di fornire un feedback sulla relativa complessità della funzionalità desiderata e sui possibili problemi. Ciò potrebbe risparmiare molto tempo agli altri ingegneri, perché possono modificare i loro piani in anticipo per evitare problemi in seguito quando il software è in fase di sviluppo.

A che punto esattamente coinvolgere gli sviluppatori SW dipende da come si vuole fare questo compromesso (ad esempio, quanto è probabile che l'ingegneria prenderà decisioni di progettazione che in seguito renderanno la vita difficile agli sviluppatori SW, quanto è probabile che gli sviluppatori SW possano aiutare gli ingegneri, quanto è importante ridurre al minimo i rischi nel progetto, anche se ciò comporta un costo complessivo più elevato).

Questa è una decisione specifica per il progetto (e difficile)

Modifica

La domanda si riduce in realtà a "Gli sviluppatori SW dovrebbero essere coinvolti nella progettazione dei requisiti?". Secondo la mia esperienza, un coinvolgimento (limitato) è molto prezioso anche all'inizio, in quanto evita requisiti totalmente irrealistici.

Fondamentalmente, la progettazione dei requisiti riguarda "ottenere il massimo dal botto": identifica le funzionalità che sono tanto utili quanto possbili, ma anche facili / economiche / veloci da implementare il più possibile.

Gli esperti di dominio sanno cosa è utile, gli sviluppatori di SW sanno cosa è facile da implementare. Hai bisogno di entrambe le informazioni per decidere quali funzioni considerare.

Non c'è niente di sbagliato nel coinvolgere gli sviluppatori nella fase dei requisiti se la tua azienda può permetterselo. Ciò non significa che inizieranno altre fasi del ciclo di sviluppo in qualsiasi momento.

In base alla mia esperienza, è spesso inestimabile che uno sviluppatore esperto sia coinvolto nelle prime fasi del processo di raccolta dei requisiti, in quanto può aiutare il team a evitare eventuali problemi derivanti da assunzioni di sviluppo non corrette da parte del management / azienda. Tuttavia, questo potrebbe anche essere un enorme spreco di tempo per gli sviluppatori se la fase dei requisiti si trasforma in una sessione di brainstorming debole.

Non c'è davvero una regola ferrea su quando gli sviluppatori dovrebbero essere coinvolti. Ho partecipato a progetti in cui sono stato portato troppo tardi, solo per essere presentato troppo presto l'altro perché lo hanno riconosciuto e ho cercato di non commettere lo stesso errore due volte. Se la tua azienda non ha una leadership strong in grado di valutare quando portare gli sviluppatori, potrebbero esserci molti sviluppatori frustrati che partecipano alle riunioni "Sarebbe bello se potessimo ...".

Un buon project manager dovrebbe conoscere il momento giusto per coinvolgere gli sviluppatori. Questo è difficile perché il project manager dovrebbe capire sia i progressi dei requisiti, sia i propri limiti quando si tratta della loro comprensione tecnica. Un grande project manager saprà quali sviluppatori dovrebbero essere coinvolti in quella fase (dato che alcuni sviluppatori sono migliori nella fase dei requisiti rispetto ad altri).

Devo ancora vedere un progetto che lo ha reso completamente attraverso la fase dei requisiti che non avrebbe potuto utilizzare alcuni input da uno sviluppatore. Se ciò accade ovunque, vorrei che la mia azienda assumesse quei project manager / analisti.

Consideralo come un problema di prototipazione. Un prototipo è un mezzo di raccolta dei requisiti, in cui la creazione di qualcosa di fisico che riflette il pensiero corrente fino ad ora può aiutare a consolidare se è quello che vogliono, o se ci sono requisiti più o più diversi.

Se gli ingegneri stanno mettendo insieme alcune idee di base con gli sviluppatori a disposizione, gli sviluppatori dovrebbero essere in grado non solo di dire se sia fattibile, ma dovrebbero anche essere in grado di mettere insieme un prototipo che potrebbe essere la base per vera applicazione. Portato al suo estremo logico, questo diventa un metodo incrementale e iterativo di progettazione e sviluppo, nella vena del processo unificato e / o agile.

Vorrei anche sottolineare che gli sviluppatori DOVREBBERO dare un feedback. Com'è che il tuo no?

Idealmente dovrebbe funzionare in questo modo, ma questo presuppone un progetto concordato che non cambi rapidamente durante la fase di implementazione, e che in questo caso andrebbe per entrambe le discipline ingegneristiche, non solo per quella relativa al software. In questo caso sono dipendenti l'uno dall'altro.

La situazione sembra che gli ingegneri non abbiano una conoscenza completa del problema che stanno cercando di risolvere prima di progettare, o il problema che stanno cercando di risolvere è ben definito ma non sono proprio sicuri come per risolverlo fino a quando non si sporcano le mani.

Questo forum non riguarda le discipline ingegneristiche non legate al software, tuttavia se questo fosse un problema di progettazione del software, il modo migliore per mitigare questo tipo di problema è quello di far sviluppare agli sviluppatori un prototipo approssimativo che abbia l'obiettivo di affrontare come molte potenziali incognite nella progettazione formale possibile. In questo modo, la progettazione formale può essere più completa e l'approccio all'implementazione del problema può essere compreso molto bene.