Programmazione vs pianificazione [chiuso]

Di recente, mi è stato assegnato il compito di incarichi di pianificazione di più alto livello a causa dello sviluppatore principale della mia partenza di squadra. Odio la pianificazione a lungo termine. Il mio cervello non sembra naturalmente cablato per questo, e non mi interessa abbastanza da spendere il tempo per impararlo (è abbastanza difficile tenere il passo con il lato di programmazione dell'immagine).

Si può ancora essere un buon programmatore senza essere anche un pianificatore di alto livello?

Come programmatore senior, ci si aspetta che sia bravo a pianificare l'intero prodotto e scegliere una data di completamento?

I piani di progetto dettagliati a lungo termine sono noti per essere generalmente imprecisi. Le funzionalità del sistema cambieranno inevitabilmente prima del lancio, e le persone di solito impiegano molto tempo a elaborare le specifiche che vanno nelle specifiche solo per fare in modo che gli stakeholder le diano uno sguardo veloce.

Dovresti leggere di più sulla pianificazione Agile , potresti trovare che si adatta meglio alla tua mentalità. Molte metodologie Agili cercano di trovare il modo di abbandonare una pianificazione dettagliata a lungo termine.

Metodologie agili cercano di ridurre al minimo le specifiche tecniche dettagliate e la documentazione a favore del codice autocompensante e delle storie utente isolate e atomiche e del software funzionante. In un efficiente team Agile, ci sarà un minimo di tempo speso per la pianificazione.

Leggi il Manifesto Agile e guarda Scrum . Utilizzare lo sviluppo iterativo e il metodo di sviluppo dinamico dei sistemi per guidare il progetto.

Il principale svantaggio degli approcci Agile è che devi ammettere apertamente di non conoscere l'esatta portata del tuo progetto e che l'acquisizione da parte della direzione di questa idea può essere estremamente difficile e di solito richiede del tempo. Vedi questa domanda e risposta e questo post per alcuni suggerimenti al riguardo.

Tuttavia è certamente vero che, man mano che diventerai un programmatore più senior, probabilmente eseguirai meno programmazione, ma penso che in un team Agile invece di significare che scrivi più specifiche tecniche, significherebbe che dedichi più tempo a gestire e tutorare i membri del tuo team e prendere decisioni architettoniche sul codice.

Sì, è possibile. Tuttavia, se vuoi essere un buon ingegnere del software o un architetto del software, è qui che entra in gioco la tua pianificazione di alto livello. Per me, la differenza principale tra un programmatore e un ingegnere è stata la capacità di vedere il quadro generale.

È possibile essere un buon programmatore e non un pianificatore di alto livello?

Per un po ', si. È possibile farlo a lungo? No.

Al giorno d'oggi con molti datori di lavoro è una procedura operativa standard fornire aumenti competitivi del settore della vita . Se non migliori te stesso, non cercare di affrontare problemi più grandi e più difficili, questi aumenti competitivi del settore ti porteranno fuori dal mercato in cinque o dieci anni. Continuate così e il vostro datore di lavoro alla fine inizierà a cercare un motivo per sbarazzarsi di voi, e anche la vostra occupabilità altrove sarà drasticamente ridotta.

Certo, puoi essere un buon programmatore, dal punto di vista di un programmatore. Dal punto di vista della direzione è tutta un'altra domanda. Nella mia esperienza, essere coinvolti nel processo di pianificazione è il modo migliore per 1) ottenere incarichi di programmazione più interessanti e 2) arrivare a svolgerli nel modo desiderato.

In altre parole, una volta che si arriva alla pianificazione a breve termine, molte opzioni sono fuori dal tavolo. Se la tua soluzione preferita richiederebbe sei settimane ma ne prevedevano solo due, sei bloccato con quello che hanno deciso. Se hai dubbi su qualcosa di cui hanno già discusso nella pianificazione a lungo termine, non vorranno ripeterlo.

Se sei soddisfatto di quello stato di cose, più potere per te. La maggior parte delle persone diventa meno soddisfatta di ciò, più esperienza acquisisce.

Il piccolo sporco segreto è che nessuno è molto bravo nella pianificazione e nella stima a lungo termine. I pianificatori migliori sono quelli che sono consapevoli dei loro limiti, quindi credici o no, sei davanti alla curva. Ottieni una formazione sulla contabilità per incertezza nella stima. Esamina tecniche come la pianificazione basata su prove o la mischia, che si basano su dati storici per mostrare la precisione delle stime. Sarai più felice a lungo termine se hai più voce in capitolo nel tuo lavoro.

È possibile essere un buon programmatore e non un pianificatore di alto livello?

Risposta breve: Sì, è possibile.

Tuttavia, più acquisisci esperienza con il tipo di progetti coinvolti, più idee progettuali avrai. Idealmente, come programmatore abbiamo un approccio su come risolvere il problema o ne cerchiamo uno. Pertanto, se conosciamo l'approccio, potremmo iniziare a pensare alla pianificazione :)

Un'altra possibile via è che un programmatore che diventa un buon pianificatore si dirige infine verso la gestione del progetto. Pertanto, se sei interessato alla gestione dei progetti, potresti fare uno sforzo in più in quella direzione.

Sì e No sono le tue risposte.

Da un lato, vieni spinto verso la gestione del progetto. IMO, tutti i bravi programmatori hanno un certo grado di capacità di gestione del progetto, ma sono diverse competenze. La capacità di pianificare a lungo termine migliora la capacità di comunicare con l'effettiva gestione del progetto. Quindi "no" non puoi essere un buon programmatore senza la possibilità di pianificare a lungo termine.

Detto questo, la gestione del progetto è un insieme di competenze diverse che fa appello ad aspetti correlati ma diversi dalla programmazione. Quindi ecco dove entra in gioco il "sì". Non devi essere un project manager per essere un grande programmatore.

Per la tua situazione specifica, cerca di diventare più obiettivo su ciò di cui l'azienda ha bisogno e su ciò che ti piace fare. C'è un po 'troppo ego riflesso nella tua domanda e questo sta influenzando la tua capacità di guardare questa situazione. Se riesci a trovare modi per contribuire maggiormente al tuo datore di lavoro mentre fai ancora le cose che ti piacciono, allora dovresti considerarle e discutere la questione con il tuo capo.

Planning and the Bungie-Boss

Dilbert ha molte strisce sul bungie-boss. Le nostre sfide e aspettative in merito alla pianificazione possono essere sia la causa che l'effetto della caduta della leadership. La mia esperienza in una società Fortune 100 è stata che in un anno tutti quelli che hanno iniziato l'anno come capo progetto sono usciti. Forse questo era dovuto al problema di pianificazione. Non sono sicuro che il tuo ex lead sia partito per questo motivo, ma quando il tuo ruolo richiede che tu faccia un piano con un impegno, se non accade, spesso, ne deriva un'uscita correlata alla scadenza.

Contesto organizzativo della pianificazione

Se non ti senti a tuo agio con la pianificazione, forse non ti senti a tuo agio con la responsabilità degli impegni assunti con il marketing o altre parti interessate prima che i problemi da risolvere siano documentati o compresi. Questo è un buon istinto.

La pianificazione è uno strumento importante. Non trascurarlo. Non fraintenderlo.

La pianificazione è integralmente collegata agli impegni, alla responsabilità e al potere negoziale. La pianificazione agile ha molti meriti. Dovresti conoscere le sue tecniche, così come le tecniche delle metodologie pianificate. La tua organizzazione può avere il suo approccio e ottenere consigli e lavorare con qualcuno che è sopravvissuto alla leadership di molti progetti, molti di cui possono essere sorprendentemente utili.

Un semplice esempio di pianificazione - Non deve riguardare il software ...

Se una società di copertura venisse a casa mia per fare un'offerta su un sostituto, se fanno un'offerta troppo bassa, potrebbero perdere soldi per il lavoro, ma se fanno un'offerta troppo alta, non otterranno affatto il lavoro. Ad ogni modo, sono fuori dal mercato. Nel tuo nuovo ruolo, se diventi troppo basso, eseguirai il progetto fino a quando non inizia la responsabilità, quindi avrai problemi. Se stimate un progetto con abbastanza imbottitura per assicurare il successo entro la scadenza, molti scelgono semplicemente qualcun altro da guidare. Il kicker è che non sei come il roofer. Può vedere quanto è grande il tetto e ha dati storici su quanto tempo impiega quel tetto di dimensioni.

Diventare un pianificatore migliore

Potresti prendere in considerazione un qualche tipo di allenamento. Nelle metodologie Agili e nelle più recenti metodologie pianificate, la stima è un'attività a livello di team. Di conseguenza, dovresti considerare di allenarti anche per la tua squadra.

Per esperienza, posso dirti che può essere frustrante ottenere stime dai membri del team che lo rimandano, darti stime che fanno in due minuti in base al nome dell'attività senza riferimento a un requisito o alla descrizione della funzione o al codice esistente, oppure che insistono sul fatto che molti dei compiti elencati possono essere svolti in una frazione del giorno anche se i progetti passati hanno trascorso settimane su problemi simili.

Esistono vari corsi di formazione e certificazioni per i project manager, ma vorrei controllarne uno accreditato in modo indipendente. Potrebbe valere la pena di ripensarci prima di scegliere di certificare con approcci basati su metodologie pianificate se si prevede di lavorare con i team Agile (o viceversa).

SLIM è un metodo inventato da Putnam dopo aver lavorato presso GE e altre società su progetti DoD negli anni '70. SLIM è influente e la sua società QSM offre una certificazione che sembra uscire da uno strumento che producono. A seconda che la tua azienda abbia adottato il proprio strumento, potrebbe non avere valore o valore elevato.

Steve McConnell (autore di Code Complete) ha anche scritto un libro sulla stima del software e la sua società Construx insegna due classi per crediti PDU che sono accreditati attraverso il Project Management Institute. Ho il suo libro e se volessi conoscere l'argomento attraverso la formazione in classe, probabilmente sceglierei Construx. Fanno anche formazione Scrum e amministrano varie valutazioni Scrum accreditate tramite Scrum.org.

Un'altra fonte che potrebbe fornire una grande formazione accademica sulla stima di progetti software, sarebbe il gruppo di Barry Boehm alla USC , basato sul loro ampio lavoro sulla modellazione costruttiva dei costi COCOMO e COSYSMO che è stato utilizzato dalla NASA e da altri grandi appaltatori per stimare progetti molto grandi. Non sono sicuro di essere un vero sostenitore di COCOMO, ma mi piace il lavoro empirico che hanno svolto per correlare gli effetti della scala e dei driver di costo sulla durata del programma.

Ho anche trovato un capitolo di un libro di testo pubblicato da O'Reilly che discute brevemente i principali metodi di stima del software tra cui Watts Humphreys PROBE e il gioco di pianificazione di Kent Beck. SONDA include l'idea che gli ingegneri tengono traccia delle metriche sulla propria produttività, quindi le applicano alla parte assegnata a nuovi progetti. Planning Game è estremamente collaborativo tra sviluppatori e altre parti interessate.