Come possiamo gestire efficacemente i progetti software senza uccidere la creatività?

Ti stai sbagliando cosa significa "gestire". Nel contesto dello sviluppo del software, la gestione di un progetto significa che il progetto procede con le funzionalità necessarie, il budget, i tempi e con una qualità accettabile.

La suddivisione del progetto in blocchi di dimensioni ridotte è uno dei tanti modi in cui dovrebbe essere possibile raggiungere gli obiettivi sopra descritti. E come immagini, potrebbe non essere il modo ottimale per te. Personalmente, questo approccio mi insulta, poiché considera me, uno sviluppatore, irresponsabile e incapace di progredire correttamente nel progetto, a meno che non sia gestito da micro.

Se vuoi veramente gestire correttamente uno sviluppatore, dovresti trattarlo come una persona competente e responsabile che sa cosa sta facendo ed è disposto e motivato a fare tutto il necessario per il successo di un progetto (naturalmente, ovviamente) . La tua responsabilità principale di gestione, sarebbe quella di comunicare chiaramente gli obiettivi del tuo progetto e lasciare la gestione quotidiana agli stessi sviluppatori. Dovresti monitorare i progressi non in base al numero di attività completate, ma a quanto è buono il software corrisponde ai tuoi obiettivi.

E se gli stessi sviluppatori pensano che suddividere il progetto in piccoli compiti e rintracciare tali compiti sia vantaggioso per il loro lavoro, lo faranno proprio così. Ma questo dovrebbe essere completamente estraneo a ciò che voi, come una mangiatoia, fate.

Ti consiglierei di pensare allo sviluppo del tuo software nel contesto del business. L'obiettivo dell'azienda è realizzare un profitto. Per ottenere un profitto, l'azienda deve produrre il più velocemente possibile mantenendo un livello di qualità.

Quando siamo al centro dei progetti e del codice, a volte è facile dimenticare che spesso il metodo più semplice, diretto e veloce è il migliore per il business, ma non è sempre così. A volte ci vuole molta considerazione e creatività per completare una funzionalità.

Il mio suggerimento è di tenere conto di tutto questo quando si valuta. Se questa è una caratteristica importante che dedicare più tempo a migliorare sensibilmente la qualità o migliorare l'agilità del resto del progetto, stimare più in alto. Se stai costantemente lottando per produrre un risultato decente nel tempo che hai stimato, stimati più in alto. Proporre compromessi di qualità con il project manager e ottengono la loro opinione. Se all'inizio lavori sul compito, pensi che più tempo potrebbe produrre un risultato migliore, consulta il tuo project manager per ottenere la sua opinione sul fatto che un risultato migliore valga lo slittamento delle stime. In questo modo condividi la responsabilità del programma e della qualità con il resto del tuo team.

In un mondo perfetto non avremmo bisogno di fare stime su nulla e avremmo tempo illimitato per creare software belli ed eleganti, ma soprattutto non è così, e dobbiamo accettare che le esigenze aziendali debbano essere poste al primo posto.

Le stime non sono scadenze.

Una stima specifica per quanto tempo tale attività richiede in media, ma i dettagli di tale attività potrebbero renderlo più facile o più difficile di quanto previsto.

Se si trattano le stime come scadenze, le scadenze saranno spesso perse, o le stime saranno integrate in qualcosa come il 90 ° percentile. Ciò rende le stime inutili per stimare lo sforzo residuo totale (è possibile ricordare dalle statistiche che la media della somma è la somma delle medie, ma il 90 ° percentile della somma è inferiore alla somma del 90 ° percentile. Compiti La legge strong dei grandi numeri implica che il 90% percentile della somma si avvicini alla somma delle medie, quindi se vuoi sommare le stime, hai bisogno di medie, non di garanzie).

La gestione del progetto che si occupa della gestione del progetto , avendo una buona stima per lo sforzo del progetto è più importante di una buona stima delle attività, quindi un buon project manager dovrebbe consentire notevoli variazioni per i tempi di completamento dell'attività. Nel corso di settimane o mesi, tuttavia, le medie dovrebbero avvicinarsi alla stima.

Dal mio punto di vista personale, i progetti noiosi uccidono la creatività, non la gestione del software in generale.

Un problema interessante (progetto) in genere richiede di eseguire al meglio e utilizzare ciò che finora hai imparato. Se trovi che stai inventando semplici soluzioni barebone che sono noiose, è molto probabile perché il progetto è di tale natura.

Immagina di chiederti di creare la stessa pagina web quattro volte con solo leggerissime differenze di design e di non poter riutilizzare il codice base per motivi legali. La tua creatività è molto più probabile che venga soffocata dalla ripetizione dell'attività piuttosto che da qualsiasi programma temporale impostato.

Ho anche svolto attività di manutenzione su progetti che potrebbero essere considerati nella criostasi, che non è una prospettiva molto allettante. Si adatta all'approccio di rispolverare il codice, correggerlo e scappare velocemente e dovresti farlo, perché non riuscirai mai a coltivare questi prodotti per la salute.

La tua opinione deriva ovviamente dalla tua percezione della realtà in cui hai lavorato ma, come ho ritratto, ci sono casi in cui trovo che sia vero; in genere quando la direzione non apprezza il valore di spendere più del tempo minimo necessario su qualsiasi soluzione o quando la soluzione è predeterminata. L'ultimo di questi due punti merita un piccolo paragrafo.

Mi vengono in mente alcuni passaggi di The Mythical Man-Month che discute la natura della creatività nel software. Implicava strongmente che la creatività fosse possibile a basso livello di implementazione fintanto che l'implementazione è libera per l'implementatore da progettare. In sostanza, se ti dico di scrivere una funzione in un modo specifico, non c'è molta creatività in gioco se vuoi scriverla da zero da sola con un input e output predefinito.

Il tempo di ricercare nuove tecniche, modelli e tecnologie è qualcosa che apprezzo molto. Molto spesso posso essere trovato alla ricerca di qualcosa non correlato al mio compito durante il mio orario di lavoro. Ciò che è importante qui è che ha dimostrato di fornire molto valore nel lungo periodo. Stiamo parlando di correzioni di sicurezza a causa di vulnerabilità scoperte, modelli di progettazione, ottimizzazioni per codice non più performante e così via. È importante che ci sia un equilibrio, ma ovviamente non puoi esaurire tutto il tuo tempo in questo modo.

Quindi sì, penso che ci siano cose che soffocano la creatività. Cosa possiamo fare per loro? Francamente la maggior parte delle cose dipendono dal progetto e / o dalla gestione, puoi evidenziare le tue opinioni e sperare in cambiamenti o cercare di portare i tuoi servizi altrove.

Soprattutto però: accetta le soluzioni non creative quando è ciò che è meglio e spendi le tue energie per i problemi che lo richiedono.

Dalla lettura dell'OP, vedo qui 2 domande,

1. Creatività: non vedo una separazione tra attività e amp; creatività. Il team di sviluppo deve impostare come completare l'attività e soddisfare i requisiti. Con ciò, il lead di sviluppo può definire obiettivi e tempistiche di attività che offrono agli sviluppatori la libertà di essere creativi nelle loro soluzioni, entro i limiti del soddisfacimento dei requisiti e della conformità agli standard / criteri di codifica aziendale.

Sì, i project manager e le parti interessate guideranno verso scadenze, è parte della loro responsabilità. Ma se il responsabile dello sviluppo ha fatto il proprio lavoro, allora c'è spazio per la creatività. E sinceramente, alla fine, ci saranno momenti in cui devi solo fare la cosa nel modo più veloce che puoi. Parte del mondo degli sviluppatori.

2. Compiti: mentre la natura dei progetti richiede che le attività abbiano una stima del tempo, ho visto seri problemi causati quando le attività sono state suddivise troppo finemente con un limite arbitrario (come 8 ore). Ciò può creare una lista mostruosa di compiti che diventano ingestibili e non importabili. È meglio creare attività che rappresentino un'unità logica di lavoro. Ad esempio, "codifica nuova schermata di inserimento cliente". La natura dello sviluppo è che avrai iterazioni, avrai punti appiccicosi che richiedono più tempo. Cercare di definire le attività al livello di "codice di scrittura per i campi richiesti per la schermata di inserimento del cliente", "campi richiesti per i test unitari" e collegarli in modo sequenziale sarà illogico, a causa del codice - test - debug - codice di correzione - test. .... cicli. I project manager devono pensare a unità di lavoro logiche, non conformi ad alcun modello arbitrario di A Task.

Se sei preoccupato per i limiti di tempo, in genere spieghiamo la situazione generale ai project manager nel seguente modo.

Lavoro sempre il più velocemente possibile, ma non più veloce. Troppo veloce porta solo a ulteriori errori / bug che richiedono più tempo per risolverlo rispetto al semplice lavoro più attento in primo luogo. Quindi lavorare alla massima velocità > > < < è ciò che farà il lavoro nel più breve tempo possibile. E se questo non è abbastanza veloce per il tuo programma, allora o il programma non è realistico o hai l'uomo sbagliato (io) per il lavoro.

Si noti che (come potete immaginare) ho sempre detto che l'ultima frase è molto più "delicatamente". Ti sto solo telegrafando l'idea. Tuttavia, in qualche modo devi riuscire a farti un'idea.

Modifica (modifica tua che enfatizza il "valore aziendale")
A volte i tempi stretti sono dettati dalla "realtà fisica / sociale" piuttosto che dalla capricciosità dei project manager. E in questi casi la "creatività" può significare trovare un modo per accorciare un lungo lavoro. Ecco due esempi tratti dalla mia esperienza personale (vedi il mio curriculum, URL della home page sul profilo, per i dettagli, inclusi esempi di codice e documentazione).

Indietro (via del ritorno) nel 1986, avevo un contratto con la CBS come programmatore capo per contribuire a sviluppare il loro "Sistema di visualizzazione elettronica" per le elezioni di metà mandato di quell'anno. Quindi la scadenza era il 4 novembre, periodo!

Anche nel lontano 1989, avevo un contratto con la banca di Chase per sviluppare un sistema di negoziazione a prezzo fisso per obbligazioni governative (e successivamente corporate). Sebbene ci fosse un po 'più di margine di manovra in questo programma rispetto a CBS, il sistema includeva anche vari cambiamenti regolamentari SEC, e Chase avrebbe potenzialmente potuto incorrere in sanzioni significative se il programma non fosse stato rispettato.

Molti altri progetti recenti hanno avuto una rigidità programmatica simile (ma non discuto i clienti dopo y2k online). In ogni caso, tutti questi tipi di situazioni richiedono una notevole creatività orientata a svolgere il lavoro correttamente e nei tempi previsti. Esistono tutti i tipi di "creatività" e il tuo kit di strumenti dovrebbe includere anche questi tipi.

Now here's my problem: I find it hard to be creative when facing a time limit for a job, even if it is a soft limit based on estimates or story points.

In realtà trovo il contrario, in un certo senso. Nella mia esperienza, un limite di tempo può essere un vincolo di creatività che ti costringe a mettere in discussione l'utilità di ogni requisito iniziale. Quando sei a corto di tempo, devi anche sviluppare soluzioni alternative e trovare nuovi modi più economici o più intelligenti per affrontare un problema.

Alla fine della giornata, potresti aver rinunciato alla qualità, all'estendibilità o allo scopo per un po 'di tempo, ma puoi davvero dire che sei meno creativo?

In altre parole, essere creativo significa necessariamente creare molte cose ?

Modifica sulla creatività tecnica: non dovrebbe essere qualcosa che improvvisi totalmente da solo all'ultimo momento

Nel mio team, gran parte della "creatività" nella progettazione del codice avviene mentre gli sviluppatori stanno collettivamente abbattendo una user story in compiti e stimandoli. Questo è quando avremo discussioni tecniche sui dettagli nitty grintosi del design, fare il nostro brainstorming white board e schema di disegno. L'idea è che non ti viene in mente una stima del compito a caso. È qualcosa che tutti hanno ampiamente pensato e concordato.

Un'altra parte importante della creatività si verifica in picchi , attività di ricerca tecnica e di esplorazione che hanno anche un limite di tempo. Ancora una volta, il vincolo creativo del tempo gioca un ruolo importante qui. Ti costringe a concentrarti su alcune soluzioni pragmatiche e allevia la paralisi dell'analisi.

Tutto ciò limita la libertà creativa che un singolo sviluppatore ha bisogno di quando svolge un'attività. Ovviamente, hanno ancora la libertà di nominare le cose nel modo in cui vogliono nominarle, progettando i loro test unitari come meglio credono, ecc. Ma l'immagine generale avrebbe dovuto essere impostata collettivamente prima.