Gestore del software che rende gli sviluppatori responsabili della gestione dei progetti

Sembri un ingegnere del software.

Un Project Manager è più focalizzato sullo stato del progetto complessivo e l'allocazione delle risorse in un modo efficace per assicurare che le milestone siano raggiunte e in tempo utile. Rimuovono anche i blocchi stradali e aiutano le risorse del progetto a concentrarsi sulle loro specifiche funzioni di lavoro.

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 una cosa buona può essere però male (vedi Analisi Paraylsis ).

He considers the design to be paramount, coding is "just writing the design down"

Se il project manager ritiene che i documenti di progettazione siano di primaria importanza, si aspetta che i documenti siano consegnabili nel processo. Non è un tempo sprecato da parte tua se ritiene di essere abbastanza importante da dedicare l'80% del tuo tempo ad esso.

it shouldn't take too long, and "all the code should be written before the hardware is ready".

Questo è un pio desiderio e una visione abbastanza antiquata di Waterfall su come funziona lo sviluppo del software. Invariabilmente non è mai così pulito, indipendentemente da quanto design e preparazione che dedichi. Su questa nota, tuttavia, dovresti avere specifiche hardware chiare e ambienti di test appropriati e simulazioni hardware simulate per far interagire il tuo codice, ma ancora una volta, il mondo reale è disordinato.

La gestione dei progetti è incredibilmente facile in un mondo perfetto. Il mondo non è perfetto, ma non importa quanto tu desideri che sia così rendendo la gestione dei progetti reale incredibilmente difficile. Questo è il motivo per cui vengono pagati i soldi.

(2) Doesn't understand the difference between a Central & Distributed Version control.

Perché dovrebbe interessarsene? In che modo influisce sulle pietre miliari? Non è così.

3) Doesn't understand code, and wants to understand every bug and its proposed solution

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

(4) Believes verification should be done by developer, and validation by the Tester.

Cosa c'è di sbagliato in questo sentimento? I tester nel ruolo di garanzia della qualità dovrebbero occuparsi della convalida di caratteristiche e requisiti. Gli sviluppatori dovrebbero fare ogni sforzo per verificare e testare il loro lavoro prima che vada in fase di test.

I don't really like creating documents, I want to solve problems and write code.

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

In my experience, creating design documents only helps to an extent, its never the solution to better or faster code.

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

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

I feel the boss doesn't really care about making better products, but only about being a good manager in the eyes of the management

Sento che ci cura perché il prodotto è il suo reparto e se i progetti e le funzionalità non sono completati e i clienti non sono felici, la direzione non si prenderà cura di lui molto. Il problema è che la tua prospettiva sui miglioramenti qualitativi necessari non coincide con la sua e la sua gestione superiore e 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 di 3 volte, se passi un'intera settimana a farlo, è al costo di un'altra importante funzionalità che il cliente sta richiedendo .

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

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

Data la tua situazione, vorrei andare da lui e spiegare che le sue richieste stanno prendendo l'80% del tuo tempo, e cercare di capire perché è importante per te che passi questo tempo a conservare la documentazione anziché svilupparla (che va oltre la codifica ).

FYI, Atlassion , una società di software, ha un rapporto di 13 sviluppatori per una persona QA e la maggior parte dei test (pianificazione e esecuzione) è fatto dagli sviluppatori. L'ho imparato durante una delle loro presentazioni ad Agile 2012 e ai nostri team che attualmente sto cercando di emulare questa pratica.

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

Come te, ero estremamente frustrato nel mantenere piani che cambiano costantemente e un approccio leggero Scrum mi ha aiutato a superare questa frustrazione.

I team più performanti nella mia esperienza sono quelli che hanno affrontato il minor numero di processi necessari per svolgere il proprio lavoro. A un certo punto, il processo aggiuntivo inizia a togliere qualità dal prodotto. Se il QA inizia a perdere i bug perché sono più preoccupati di far fuori i documenti, e DEV non sta codificando le funzionalità o correggendo i bug perché stanno scrivendo la documentazione, allora hai un problema. Tuttavia, capire se questo è effettivamente il caso nella tua azienda è una domanda altamente localizzata che solo le persone del tuo team possono rispondere (non noi).

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

Inoltre, da una rigida prospettiva aziendale, l'assunzione di QA è più economica rispetto all'assunzione di sviluppatori. Sarai in grado di coprire più terreno per i soldi spesi se le squadre hanno un buon rapporto QA / DEV.

Le implementazioni CMMI che ho visto o sentito direttamente sono state tutte pesanti per processo e documentazione; i vostri capi credono che la documentazione dovrebbe essere sufficientemente dettagliata da rendere l'implementazione banale che implica strongmente che la sua aspettativa è simile.

Se stai ricevendo una quota sproporzionata della documentazione di scrittura / manutenzione, chiedendo che sia distribuito in modo più equo è ragionevole. Se gli altri sviluppatori hanno una documentazione simile ai rapporti di codifica e si vuole passare la maggior parte del tempo a scrivere codice; potrebbe essere il momento di prendere in considerazione la possibilità di trovare un nuovo datore di lavoro.

Parli 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 assicurare 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 di test necessari (in base alla criticità di sicurezza [ più specificamente, il livello di sicurezza del progetto] del software), e nel mondo automobilistico abbiamo ISO26262 che fa altrettanto.

Se la documentazione non è a posto, 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 un ripensamento perché non serve a scopi reali.