Impostazione delle scadenze nello sviluppo del software [duplicato]

3

Ho lavorato su un sistema da solo per circa due anni. Ho ereditato il sistema da un appaltatore che ha lavorato per circa due anni prima di me (da solo). Il sistema non è particolarmente ben progettato perché sono presenti logica aziendale, logica di presentazione e logica dei dati. È un sistema molto complesso, che sto cercando di ridefinire mentre vado avanti e questo richiede tempo.

È stato reclutato un nuovo sviluppatore, ma sembra che stia assumendo più di un ruolo di gestione del progetto. È molto diretto a chiedere esattamente quanto tempo ci vorrà; mettendo in discussione tutte le mie supposizioni e le mie previsioni, che è difficile a causa della complessità e perché sono l'unico esperto al momento.

Sono molto organizzato nella mia vita personale. Ad esempio, mi è stato chiesto a che ora sarebbe arrivata a Manchester la scorsa settimana, quindi ho provveduto a fornire un orario preciso per incidenti e lavori stradali. Trovo difficile applicare gli stessi principi al lavoro nello sviluppo del software al momento.

Non fraintendermi. Ho lavorato con project manager su progetti meno complessi in passato e ho avuto un buon rapporto, ma i progetti sono stati meno complessi e li ho sempre consegnati prima del previsto. Sto lottando con questo particolare project manager e sta causando stress.

In che modo gli altri sviluppatori si occupano dei project manager che desiderano risposte e date di scadenza precise?

    
posta w0051977 07.09.2013 - 19:39
fonte

3 risposte

5

Qual è il ruolo del nuovo sviluppatore? Sta lavorando al tuo fianco, lo stai mentoring, è senior, è il proprietario o il manager della soluzione? Sembra che voglia capire la soluzione e capire dove si trovano le complessità.

A new developer was recruited but he seems to be taking more of a Project management role. He is very direct asking exactly how long things will take; questioning all my assumptions and predictions, which is difficult because of the complexity and because I am the only expert at the moment.

È normale che un nuovo membro del team faccia domande. In quale altro caso ti aspetteresti che qualcuno si adegui alla soluzione: i problemi, i progetti di design realizzati e così via.

La tua domanda solleva più domande per me. A cosa stai rispondendo? Se dice "Quanto tempo ci vuole x ', e tu rispondi' Non so 'o' Non sapremo finché non iniziamo ', o simili, sarei molto preoccupato. Hai lavorato alla soluzione per due anni e hai la responsabilità di dare una guida al progetto. Dopo tutto, sei l'esperto.

    
risposta data 08.09.2013 - 01:23
fonte
2

Chiedi il livello obiettivo di fiducia da utilizzare nelle stime. Ci sarà una grande differenza tra il 50% e il 90% di confidenza.

    
risposta data 08.09.2013 - 00:39
fonte
1

Credo che un approccio agile allo sviluppo del software darà sempre un'esperienza più soddisfacente e preziosa per entrambe le parti.

Per me questo significa tre cose. 1. Condivisione di una visione per il prodotto (comprensione inattesa del tempo di cosa significa "questa cosa è". Ad esempio "Il miglior strumento di gestione del salone per parrucchieri") 2. Definire gli attuali obiettivi condivisi. (le "cose" reali ideali per il tempo che costituiscono la visione. Ad esempio "Entro 6 mesi saremo in grado di gestire le prenotazioni e le scorte") 3. Decidere cosa fare dopo. (attività previste per la prossima iterazione, ad esempio "questa settimana avrò un elenco di tutti gli strumenti software attualmente disponibili per i saloni". Oppure "questa iterazione completeremo l'autenticazione dell'utente").

Le tue iterazioni dovrebbero essere CORTE (la mia preferenza attuale è una settimana) e dovrebbero risultare in "cose" rilasciabili o esperimenti che danno insegnamenti concreti. È quindi la decisione dei "clienti" se ciò che loro hanno è sufficiente. Questo è un punto chiave: hanno hanno qualcosa.

Qualsiasi piano non è aggiornato non appena viene scritto. È una promessa in attesa di essere infranta. È inflessibile cambiare: il cambiamento è un dato di fatto. La pianificazione è essenziale, ma un piano è inutile. Un PM (se mai ne hai bisogno - IMO è un compito e non un ruolo) può quindi allineare le stime e gli obiettivi regolarmente e "vedere dove sono".

Sii snello, sii agile. Le misure di costruzione apprendono e commerciano in "fatto", non "promesse e scuse".

    
risposta data 07.09.2013 - 19:58
fonte

Leggi altre domande sui tag