Software Manager che fa fare agli sviluppatori la gestione dei progetti

Sono uno sviluppatore di software che lavora in un'azienda di sistemi embedded. Abbiamo un Project Manager, che si occupa del programma generale del progetto (inclusi elettrico, qualità, software e produzione), quindi il suo programma del software è molto breve.

Abbiamo anche un Software Manager, che è il mio capo. Mi fa scrivere e mantenere il programma del software, i documenti di progettazione (progettazione di alto e basso livello), SRS, gestione delle modifiche, piani e rapporti di verifica, gestione delle versioni, revisioni e, naturalmente, il software.

Abbiamo un solo tecnico di test per l'intero team di software (10 membri) e in un dato momento, ci sono un paio di progetti in corso.

Sto spendendo l'80% del mio tempo per realizzare questi documenti. Il mio capo proviene da un background di processo e ritiene che ciò di cui abbiamo bisogno sia una migliore documentazione per migliorare il software:

1. Considera il progetto fondamentale, la codifica è "solo scrivere il disegno", non dovrebbe richiedere troppo tempo e "tutto il codice dovrebbe essere scritto prima che l'hardware sia pronto".
2. Non capisce la differenza tra un controllo versione centrale e versione distribuita, anche dopo che gli abbiamo detto che è più facile collaborare con un modello distribuito.
3. Non capisce il codice e vuole capire ogni bug e la sua soluzione proposta.
4. Crede che la verifica dovrebbe essere fatta dallo sviluppatore e la validazione da parte del tester. Il fatto è che la nostra verifica verifica solo se l'implementazione è corretta (non scriviamo test unitari, non è mai considerato nel programma) e la convalida è un test black box, quindi i test unitari sono mancanti.

Sono veramente confuso.

1. Sono responsabile della conservazione di tutti questi documenti? Mi fa sentire come se stessi facendo il Project Management del software, in sostanza. Sono d'accordo con la documentazione tecnica, ma credo che la programmazione / pianificazione non debba essere effettuata dallo sviluppatore.
2. Non mi piace molto creare documenti, voglio risolvere problemi e scrivere codice. Nella mia esperienza, la creazione di documenti di progettazione aiuta solo fino a un certo punto, non è mai la soluzione per un codice migliore o più veloce.
3. Sento che il capo non si preoccupa davvero di realizzare prodotti migliori, ma solo di essere un buon manager agli occhi della direzione.

Cosa posso fare? Per tutto questo anno ho fatto 3 mesi di vera programmazione, il resto ha speso solo per fare documenti e aspettare segnalazioni di bug dai clienti.

Sembri un ingegnere del software.

Un Project Manager è più focalizzato sullo stato dell'intero progetto e sull'allocazione delle risorse in modo efficace per garantire che i traguardi vengano raggiunti e in tempo utile. Inoltre rimuovono i blocchi stradali e aiutano le risorse del progetto a concentrarsi sulle loro specifiche funzioni lavorative.

Scrivere e mantenere la progettazione e la documentazione tecnica è una parte importante dell'essere un ingegnere del software ed è appropriato per il tuo ruolo. Troppo di buono può essere negativo (vedi Analisi Paraylsis ).

Considera il design fondamentale, la codifica è "solo scrivere il design"

Se il project manager considera i documenti di progettazione di primaria importanza, si aspetta che i documenti siano consegnabili nel processo. Non è un tempo sprecato da parte tua se sente che sono abbastanza importanti da destinare l'80% del tuo tempo.

non dovrebbe richiedere troppo tempo e "tutto il codice dovrebbe essere scritto prima che l'hardware sia pronto".

Questo è un pio desiderio e una visione piuttosto antiquata in stile Cascata su come funziona lo sviluppo del software. Invariabilmente non è mai così pulito, non importa quanto design e preparazione dedichi. Tuttavia, dovresti avere specifiche hardware chiare, ambienti di test adeguati e simulazioni hardware simulate per far interagire il tuo codice ma, di nuovo, il mondo reale è disordinato.

La gestione del progetto è incredibilmente facile in un mondo perfetto. Il mondo non è perfetto, tuttavia, non importa quanto tu voglia che sia, rendendo incredibilmente difficile la vera gestione dei progetti. Questo è il motivo per cui vengono pagati i soldi.

(2) Non comprende la differenza tra un controllo versione centrale e versione distribuita.

Perché dovrebbe interessarsene? In che modo influisce sulle pietre miliari? Non

3) Non capisce il codice e vuole capire ogni bug e la sua soluzione proposta

Il suo obiettivo è lavorare con il software e dovrebbe esserlo anche il tuo. Non ha bisogno di capire il codice ma ha bisogno di capire i problemi che impediscono il funzionamento del software. Una volta che voi due vedrete di persona questo livello di base, il vostro obiettivo comune vi aiuterà a lavorare insieme in modo più efficace.

(4) Crede che la verifica dovrebbe essere fatta dallo sviluppatore e la validazione da parte del tester.

Cosa c'è di sbagliato in questo sentimento? I tester nel ruolo di controllo della qualità dovrebbero preoccuparsi di convalidare funzionalità e requisiti. Gli sviluppatori dovrebbero fare tutto il possibile per verificare e testare il proprio lavoro prima di passare ai test.

Non mi piace molto creare documenti, voglio risolvere problemi e scrivere codice.

Se preferisci essere un semplice programmatore, forse dovresti parlarne con il tuo capo e vedere se c'è un ruolo migliore per te nel progetto. Qualcuno deve scrivere e conservare la documentazione tecnica, quindi forse uno degli altri sviluppatori può aiutarti con alcune di queste attività in modo da non spendere l'80% del tuo tempo a scrivere documentazione.

Nella mia esperienza, la creazione di documenti di progettazione aiuta solo fino a un certo punto, non è mai la soluzione per un codice migliore o più veloce.

Questo è per lo più vero ... ma solo se tutti e dieci gli sviluppatori trascorrono l'80% del loro tempo a scrivere documentazione tecnica che nessuno leggerà mai. Questo è un enorme anti-modello gestionale in cui ho vissuto prima. Se scopri che stai facendo la maggior parte della documentazione per il team, non sembra giusto che ti venga negato il diritto di eseguire più lavori di programmazione.

Il fatto è che la migliore documentazione tecnica è il codice stesso.

Sento che il capo non si preoccupa davvero di realizzare prodotti migliori, ma solo di essere un buon manager agli occhi della direzione

Sento che lui fa attenzione perché il prodotto è il suo reparto e se i progetti e le caratteristiche non sono completati e clienti non sono soddisfatti, allora la gestione superiore non si cura di lui molto. Il problema è che la tua prospettiva sui necessari miglioramenti della qualità non coincide con la sua e la direzione superiore e con la percezione dei clienti di ciò che ritengono importante.

Cerca di capire cosa è veramente importante per il prodotto, perché mentre puoi aumentare l'efficienza di un processo 3 volte, se trascorri un'intera settimana a farlo, è a costo di un'altra importante caratteristica che il cliente richiede.

Vogliamo tutti avere un bell'aspetto agli occhi del nostro superiore. Non c'è nulla di sbagliato in questo, è la natura umana essere egoista. Questo è un dato di fatto.

In una certa misura, sono d'accordo con il tuo project manager. Lo sviluppo del software va ben oltre le funzionalità di codifica. :-)

Data la tua situazione, andrei da lui e spiegherei che le sue richieste richiedono l'80% del tuo tempo e cerco di capire perché per lui è importante che passi questo tempo a conservare la documentazione piuttosto che a sviluppare (che va oltre la codifica).

FYI, Atlassion , una società di software, ha un rapporto di 13 sviluppatori per una persona addetta al controllo qualità e la maggior parte dei test (pianificazione ed esecuzione) vengono effettuati dagli sviluppatori. L'ho imparato durante una delle loro presentazioni ad Agile 2012 e i nostri team al momento sto cercando di emulare questa pratica.

Tuttavia, vorrei anche discutere con il vostro project manager se fosse aperto a provare Scrum come metodologia per aiutare a far avanzare l'intero team. Data la tua descrizione, non penso che tu stia usando Scrum.

Come te, ero estremamente frustrato nel mantenere piani in costante cambiamento e un approccio leggero Scrum mi ha aiutato a superare questa frustrazione.

I team più performanti della mia esperienza sono stati quelli che hanno affrontato il minor numero di processi necessari per svolgere il proprio lavoro. Ad un certo punto inizia un ulteriore processo che toglie qualità al prodotto. Se il QA inizia a perdere i bug perché sono più interessati a scartare le scartoffie e DEV non sta codificando le funzioni o correggendo i bug perché stanno scrivendo documentazione, allora hai un problema. Tuttavia, capire se questo è effettivamente il caso nella tua azienda è una domanda altamente localizzata a cui solo le persone del tuo team possono rispondere (non noi).

C'è una cosa su cui il tuo capo ha torto, ed è il fatto che hai così poco QA e nessun test unitario. Un bug creato da Adeveloper è per definizione una svista da parte loro. Aspettarsi che gli sviluppatori testino sempre le proprie funzionalità e avere pochi test a parte questo è un problema di processo. Il QA può essere sostituito da test automatici a seconda del tuo dominio in una certa misura, ma se non ne hai nessuno allora probabilmente stai lasciando passare i bug (e questo di solito finisce per costare di più che trovarli in anticipo).

Inoltre, da una rigorosa prospettiva aziendale, assumere QA è più economico di assumere sviluppatori. Sarai in grado di coprire più terreno per i soldi spesi se i team hanno un buon rapporto QA / DEV.

Le implementazioni CMMI che ho visto o di cui ho sentito parlare direttamente sono state tutte pesanti per processi e documentazione; i vostri capi credono che la documentazione dovrebbe essere sufficientemente dettagliata per rendere banale l'implementazione implica fortemente che le sue aspettative sono simili.

Se ricevi una quota sproporzionata della scrittura / manutenzione della documentazione, è ragionevole chiederne una distribuzione più uniforme. Se gli altri sviluppatori hanno una documentazione simile ai rapporti di codifica e si desidera dedicare la maggior parte del tempo a scrivere codice; potrebbe essere il momento di prendere in considerazione la ricerca di un nuovo datore di lavoro.

Stai parlando di sistemi medici ... quindi la sicurezza è fondamentale - e quindi la documentazione (in particolare la tracciabilità) è essenziale.

Un tester sembra un po 'leggero, ma a parte questo, sì - sei responsabile di garantire che la documentazione sia a posto.

La mia esperienza nel mondo medico è limitata, ma nel mondo aerospaziale / della difesa abbiamo Do-178B (ora C) che prescrive un modello del ciclo di vita che specifica la documentazione e il livello dei test necessari (a seconda della criticità della sicurezza [più specificamente, livello di garanzia del design] del software) e nel mondo automobilistico abbiamo ISO26262 che fa altrettanto.

Se la documentazione non è presente, il prodotto non viene certificato.

Ma l'importante è lavorare con la documentazione richiesta per migliorare il tuo prodotto ... non provare a decodificare la documentazione come ripensamento perché non serve a nulla nel mondo reale.