Bagaimana cara mengatur proyek satu orang? [Tutup]

Sekali-sekali (baca: setiap hari) saya mendapat ide baru, memulai proyek baru di editor / IDE favorit saya, mulai coding dan hari berikutnya saya menghapusnya dan memulai sesuatu yang baru. Saya sudah memprogram sekitar enam tahun sekarang dan dalam enam tahun itu saya hanya benar-benar menyelesaikan satu proyek yang sangat kecil (widget Dashboard untuk Pastebin.com). Meskipun ini mungkin bagus untuk belajar coding, saya benar-benar ingin menyelesaikan sesuatu.

Apa beberapa hal yang harus saya lakukan sebelum, sementara dan setelah pengkodean yang sebenarnya? Apa sumber daya bagus yang mengajari saya cara mengatur proyek one-man seperti itu?

Jika itu penting, saya ingin melakukan pengembangan web atau Mac.

Saya pikir masalah sebenarnya, jangka panjang, adalah motivasi, bukan organisasi.

1. Temukan pengguna dan bicarakan dengan mereka. Lihat proyek Anda sebagai semacam hadiah (atau produk yang dapat dijual) kepada orang-orang itu. (Seseorang untuk memantulkan ide juga bagus, bahkan jika mereka tidak benar-benar mengembangkan kode dengan Anda.)

   Memiliki motivasi sosial akan jauh lebih kuat untuk menjaga proyek tetap menarik dalam jangka panjang daripada sekadar rasa ingin tahu pribadi.

2. Tujuan Anda harus berupa potongan kecil fungsionalitas yang bermanfaat. Letakkan di SourceForge atau GitHub, dan perlakukan proyek tersebut sebagai sesuatu yang membutuhkan peluang untuk bertahan hidup bahkan jika Anda tiba-tiba terkena meteor.

   Ini mengarah ke lebih banyak rilis (yang berarti lebih banyak umpan balik dan antusiasme dari pengguna) dan juga kemungkinan lebih besar bahwa orang lain mungkin memutuskan untuk berkontribusi pada proyek.

3. Pilih tujuan pembelajaran tertentu untuk Anda sendiri. Teknologi atau teknik apa yang membantu proyek Anda belajar? Jika ternyata tekniknya tidak cocok untuk area masalah, apakah Anda akan cukup tertarik untuk menyelesaikan versi 1.0 sebelum mengesampingkannya?

   Contoh tujuan tersebut termasuk parser penulisan, protokol jaringan, aspek AI game, kerangka kerja pembelajaran atau toolkit, bahasa baru, dll.

Skenario terburuk berarti melewatkan ketiganya, di mana Anda berulang kali melakukan "penulisan ulang besar-besaran" dari alat yang tidak pernah dirilis yang melibatkan kode yang menurut Anda tidak menarik bagi orang yang Anda tidak yakin ada.

Ketika Anda datang dengan ide untuk proyek baru saat mengerjakan proyek, cukup catat di daftar ide proyek. Kemudian kembali ke proyek saat ini. Jika proyek ini bermanfaat, jangan biarkan diri Anda terganggu oleh proyek baru. Gunakan langkah-langkah berikut ini hanya jika itu adalah ide yang luar biasa.

Sebelum Anda memulai proyek kami, rencanakanlah. Apa yang akan dilakukannya? Seberapa sulit untuk dilakukan? Apa yang diketahui dan tidak diketahui? Apa yang kemungkinan salah? Itu akan makan waktu berapa lama? [Sekarang Anda dapat memutuskan apakah akan melanjutkan atau berhenti sekarang.] Simpan rencana Anda. [Jika Anda mengerjakan suatu proyek, sisihkan proyek baru dan lanjutkan dengan proyek asli lainnya.]

Ketika Anda memulai proyek Anda, aturlah sebagai proyek terpisah di IDE Anda. (Jadi Anda tidak perlu menghapusnya untuk memulai proyek Anda berikutnya.) Periksa ke beberapa perangkat lunak kontrol versi sebagai proyek baru. (Sekarang Anda dapat menghapusnya jika Anda menghalangi proyek lain.) Periksa proyek Anda setiap kali Anda melakukan sesuatu dengan benar. (Sekarang Anda dapat kembali jika keluar jalur.)

Lacak masalah yang muncul pada proyek Anda. Ini dapat dilakukan dengan beberapa file teks dalam proyek. File seperti TODO, Changelog, README (dapat mencakup bug dan masalah yang diketahui) mungkin sesuai.

Ketika Anda mendapatkan kode Anda bekerja tag itu di kontrol versi Anda. Jika layak berbagi lakukanlah.

Kembali ke rencana Anda dan lihat seberapa baik Anda melakukannya. Buatlah dokumen pelajaran untuk Anda sendiri. Apa yang Anda pelajari, seberapa baik perkiraan Anda? Masalah apa yang Anda lewatkan? Masalah apa yang Anda anggap terlalu tinggi? Apa pun yang Anda anggap penting.

Ketika Anda meninggalkan proyek, lakukan proses pembelajaran. Tambahkan catatan tentang mengapa Anda meninggalkan proyek.

Tinjau pelajaran yang Anda pelajari sebulan sekali atau lebih. Seiring berjalannya waktu, Anda dapat meningkatkan interval antar ulasan.

Berikut tautan ke " Melakukan Agile dalam tim satu ". Ini bacaan yang menarik!

Juga, Anda mungkin ingin mempertimbangkan mengapa disiplin perangkat lunak yang kami lakukan "di tempat kerja" penting. Apakah mereka hanya penting jika ada 10 orang di tim? Tidak, itu penting karena membantu Anda memikirkan proyek Anda.

Siapa audiens target Anda? (Jika itu Anda, maka hebat - tapi ingat untuk apa Anda awalnya menginginkan aplikasi itu)

Jika Anda menggunakan UI, pikirkan kebutuhan audiens Anda, lalu lakukan beberapa mock up sebelum masuk ke pengembangan UI hard core.

Jika Anda melihat logika bisnis Anda, coba TDD atau BDD. Pikirkan bagaimana Anda ingin aplikasi Anda berfungsi sebelum menyerang. Pertimbangkan untuk membungkusnya dengan harness seperti Fitnesse atau sejenisnya. Jika Anda ingin menguji aplikasi Anda, tempat termudah untuk memulai adalah di awal .

Diberikan komentar Anda, berhenti menghapus proyek Anda!

Saya biasanya tidak menyimpan proyek yang saya tidak kembangkan secara aktif (atau diramalkan akan berkembang dalam waktu dekat) di komputer saya, tetapi file sumbernya ada di repositori SVN dan semuanya (termasuk file konfigurasi IDE) didukung di HDD eksternal. Itu tidak menjawab pertanyaan Anda, menghapus pekerjaan Anda, dan fokus pada memotivasi diri sendiri.

Jika Anda mencari repositori yang dihosting, lihat Google Code, SourceForge, GitHub, dan BitBucket. Unggah file Anda, simpan di suatu tempat, dan ketika Anda memiliki minat baru, tarik ke bawah. Meskipun Anda dapat menjadikannya pribadi, Anda dapat membuatnya menjadi publik jika Anda tidak malu karenanya. Mungkin seseorang akan tertarik memulai kembali pekerjaan Anda atau belajar dari contoh Anda (terutama jika Anda menggunakan perpustakaan atau kerangka kerja yang menarik).

Seiring waktu, kerjakan motivasi Anda. Cobalah untuk fokus pada satu hal pada satu waktu. Anda mungkin tidak mendapatkan kode untuk kualitas produksi, tetapi mungkin Anda bisa menjadikannya sebagai contoh kualitas, atau sesuatu yang dapat dilihat orang lain untuk melihat keahlian Anda, pengetahuan, atau untuk belajar tentang cara tertentu dalam melakukan sesuatu.

Pertama-tama, ada proyek dan proyek. Jika Anda mencoba beberapa teknologi atau perpustakaan, atau yang lain, Anda mungkin membuat proyek di IDE Anda, cari tahu apakah hal ini menarik bagi Anda atau tidak, dan kemudian hapus proyek Anda. Tidak apa-apa, semua orang melakukan ini.

Jenis proyek lainnya adalah perangkat lunak / situs / etc. Nyata, yang merupakan bisnis, di mana 'proyek', file, program hanyalah alat, dan mengembangkan hal-hal rumit seperti itu membutuhkan motivasi dan tujuan :

• apa yang Anda kembangkan (situs web / editor teks / aplikasi seluler / ...)
• untuk apa Anda membutuhkannya (menghasilkan uang, mengambil beberapa teknologi baru / berkontribusi ke open source / ...)
• kapan Anda melakukannya (berapa lama Anda mencurahkan proyek Anda, berapa lama Anda berencana untuk melakukan itu)

Apa yang Anda kembangkan harus baru . Jika Anda ingin membuat hanya editor teks lain karena Anda merasa beberapa fitur yang Anda minta tidak ada, Anda mungkin tidak perlu melakukan itu. Ada ratusan alat sumber terbuka, berkontribusi pada salah satunya.

Bahkan jika Anda membuat alat kecil sekali pakai seperti skrip, Anda harus menyatakan hal-hal yang tercantum, akan lebih mudah untuk menyelesaikan masalah itu sendiri.

Jika Anda tidak dapat menulis kode (mis., Menulis ulang kode Anda secara besar-besaran), Anda mungkin tidak cukup berpengalaman untuk melakukan itu. Ambil buku bagus tentang rekayasa perangkat lunak, platform Anda (mac / web / dll), baca kode yang ditulis oleh pengembang yang lebih berpengalaman yang melakukan hal serupa. Ada banyak tempat untuk melakukannya sekarang (github, kode google, blog pemrograman, stackoverflow).

Jangan mencoba untuk memecahkan masalah yang sangat kompleks (misalnya penulis kompiler atau sistem operasi) dari awal, pertama menguraikannya menjadi tugas yang lebih kecil, sering kali, seseorang telah membuat perpustakaan yang membantu Anda memecahkan masalah Anda.

Pernahkah Anda mempertimbangkan untuk bertanya kepada orang yang dicintai apa yang sebenarnya mereka butuhkan untuk sebuah webtool, dan kemudian benar - benar membuatnya untuknya?

Ini harus memberikan motivasi untuk benar-benar menyelesaikan dan menyampaikan yang merupakan bagian yang sulit dalam hal ini. Anda juga mendapat manfaat dari mendukung dan memelihara aplikasi jika itu berguna untuk orang yang Anda cintai. Jika tidak berguna, Anda bisa belajar dari pengalaman apa yang bisa salah.