Diventare il team one-man più efficiente

Question

Come molti qui, sono un team di sviluppo di un solo uomo. Sono responsabile di tutto, dalla raccolta dei requisiti del progetto, alla progettazione di schermi di concetti, alla pianificazione e allo sviluppo di database e alla scrittura di tutto il codice.

Essere una squadra di un solo uomo è bello, ma ha i suoi aspetti negativi. Non ho la possibilità di consultarmi rapidamente con altri sviluppatori, raramente ho una seconda serie di occhi per il mio codice, e sono sicuro che anche voi ragazzi potete inventare molti altri aspetti negativi.

Per sfruttare al massimo il mio tempo e dedicarmi al mio lavoro in modo più efficiente, quali consigli o pratiche potrei implementare nella mia routine quotidiana per essere la migliore squadra individuale possibile?

Answer 1

• Elenco giornaliero di ciò che sto per fare.

• Rimuovi il maggior numero di distrazioni possibili per concentrarsi sulle attività. Disattiva l'email , disattiva la messaggistica immediata, ecc. Anche se per un determinato periodo di tempo e quindi durante un'interruzione controllali.

• Prenditi del tempo per conoscere altre tecniche di codifica, strumenti e conoscenze di programmazione. Questo ho trovato fondamentale per il mio sviluppo. È facile da codificare e sentirsi produttivi. Che dire di ciò che potrebbe essere se tu avessi solo un po 'più di conoscenza/armi sotto la cintura per sbattere fuori il prossimo widget. So che questo suona davvero controproducente, ma in realtà non lo è. Conoscenza/know how è la nostra valuta reale. Più conosciamo e più possiamo prendere una decisione migliore su come qualcosa dovrebbe essere fatto e farlo più velocemente.

• Fare pause ed essere consapevoli del proprio corpo . Quando siamo stanchi noi non pensiamo così e renderà più errori, frustrati più facilmente, ecc ...

• Imparare ad usare la regola 80/20 al vostro vantaggio. Non intendo lesinare o essere pigro. Spesso però lavoreremo la nostra coda per quel 20% quando non era necessaria.

• Stabilire obiettivi per se stessi (giornaliero, settimanale, bisettimanale). Assicurati che gli obiettivi siano anche in linea con quelli che stai codificando per o potresti trovarti che hanno perso tempo.

Da un punto di vista tecnico considerano:

• consideri Unit Testing/TDD. Ho trovato in il mio lavoro che questo effettivamente risparmia tempo . Ci vuole un po 'per ottenere il blocco di ma con qualsiasi cosa tu possa migliorare.
• Prenditi cura del tuo codice. Refactor it (in particolare se si avvia il test dell'unità). Migliore è il codice più è facile mantenere il tempo impiegato da . Più facile è per capire più velocemente è possibile modificare /implementare le funzionalità.

Answer 2

• Assicurati di refactoring presto e spesso. Questo serve quasi come una seconda serie di occhi (almeno per me).
• Non lavorare ore folle (particolarmente difficile se stai lavorando da casa). In realtà, lavorare in meno di ore spesso si rivela più produttivo in quanto l'imminente pressione di pausa/fine giornata aumenta la tua efficienza.
• Si consiglia di cercare Parkinson's Law per la gestione del tempo di lavoro.

Answer 3

Secondo la ricerca operativa, il lavoro più breve è il miglior programma di pianificazione per ottenere la maggior parte delle operazioni.

Answer 4

scrivo e test di integrazione e di sistema run, ma nessun test di unità, perché non ho bisogno di test precoce (pre-integrazione): Should one test internal implementation, or only test public behaviour?

Un corrolary della legge di Conway è che è necessario testare le interfacce software interne che separano/integrano gli sviluppatori, mentre un "one man army" non ha bisogno di testare esplicitamente le sue interfacce interne in questo modo.

Answer 5

Sto imparando a dedicare molto più tempo a pianificare la mia giornata rispetto a prima. Ciò include la pianificazione di progetti, fino alla scrittura di psuedo-code per la programmazione che devo fare. Trovo che con tutte le interruzioni del mio programma, è difficile per me iniziare a qualcosa. Avere tutto suddiviso in piccoli compiti rende molto più facile iniziare dopo un'interruzione.

Answer 6

Uso un file di testo per raccogliere tutte le cose che faccio ogni giorno. Ogni volta che mi imbatto in un problema o ho una domanda o trovo una soluzione, la aggiungo al mio file. È molto low-tech ma fornisce una grande quantità di informazioni, come "dove sto spendendo la maggior parte del mio tempo?" o "come ho risolto il problema prima?". Inoltre, rende super veloce la consegna al tuo cliente di un elenco di ore alla fine del ciclo di fatturazione.

Uso anche un altro file di testo (per client) che contiene tutti gli elementi di lavoro nel mio piatto, disposti in ordine di priorità e aggiornati di frequente. Aiuta me e i miei clienti a concentrarsi su ciò su cui dovrei lavorare, quindi la pompa è sempre pronta.

Eventualmente mi sposterò da file di testo piatto a utilizzare qualcosa come FogBugz, ma per ora non riesco a battere il prezzo, o quanto sia facile cercare, o quanto sia facile per l'e-mail.

Answer 7

Molti altri suggerimenti sono validi, ma si applicano anche agli sviluppatori che lavorano in team e agli sviluppatori solitari.

Penso che la cosa più difficile come un team di un solo uomo sia una comunicazione efficace con il resto della vostra azienda. Sarai sempre la voce di un programmatore solitario in qualsiasi riunione o discussione sul modo migliore di creare software.

Come risultato, consiglierei di provare a migliorare le capacità di negoziazione e di concentrarsi sul modo in cui descrivi concetti tecnici in termini comprensibili a un non programmatore. Leggere libri come Getting to Yes e How to win friends and influence people sono un buon modo per iniziare.

Quando c'è più di una persona che accetta un punto di vista, il punto di vista ottiene automaticamente credibilità con quelli che stai cercando di convincere. In assenza di questa possibilità è necessario lavorare molto duramente per preparare i tuoi argomenti con prove ben documentate e una visione equilibrata.

Answer 8

Sono nella stessa situazione. C'è già un sacco di buoni consigli sopra, ma una cosa che vorrei aggiungere è trovare quando sono i tuoi tempi di codifica migliori e assicurarti di essere codificati durante quel periodo. Ho alcune ore al mattino che mi sembra di essere al meglio per la programmazione. Cerco di mantenere quel tempo libero da tutte le distrazioni. Pianifica cose come riunioni, documentazione scritta, test (almeno le cose noiose e ripetitive) e tutte le altre cose per il tuo tempo meno produttivo. Tieni quelle ore di codifica quando sei da 2 a 5 volte più produttivo per la codifica.