Pemrograman vs Perencanaan [ditutup]


15

Baru-baru ini, saya ditugasi lebih banyak tugas perencanaan tingkat tinggi karena pengembang utama tim saya pergi. Saya benci perencanaan jangka panjang. Otak saya sepertinya tidak terhubung dengan kabel untuk itu, dan saya tidak cukup tertarik untuk menghabiskan waktu untuk mempelajarinya (itu cukup sulit untuk mengikuti sisi pemrograman gambar).

Masih bisakah seseorang menjadi programmer yang baik tanpa menjadi perencana tingkat tinggi juga?

Sebagai seorang programmer senior, apakah orang diharapkan pandai merencanakan seluruh produk dan memilih tanggal penyelesaian?


Jika posisi Anda adalah Pengembang, mengapa Anda diharapkan untuk merencanakan? Mungkin memperkirakan, tetapi tidak berencana
superM

ya itu mungkin. Dalam hal ini, produktivitas Anda akan sangat tergantung pada seberapa baik manajer / pemimpin tim Anda
agas

1
Ini pertanyaan yang sangat menarik. Saya tidak berpikir Anda perlu melakukan banyak spesifikasi teknis untuk menjadi pengembang senior yang baik - dalam pengembangan Agile banyak fitur dari sistem atau proyek baru muncul. Lihat jawaban saya untuk info lebih lanjut.
Robin Winslow

1
Bagaimana satu kutipan itu? "Hari-hari pengkodean dapat menghemat berjam-jam perencanaan" atau sesuatu untuk efek itu.
Drake Clarris

Jawaban:


17

Rencana proyek jangka panjang terperinci terkenal karena biasanya sangat tidak akurat. Fungsi dari sistem pasti akan berubah sebelum diluncurkan, dan orang-orang biasanya menghabiskan waktu lama untuk mengerjakan spesifikasi yang masuk ke dalam spesifikasi hanya untuk meminta pemegang saham memberikan pandangan sekilas yang terbaik.

Anda harus membaca lebih lanjut tentang perencanaan Agile , Anda mungkin menemukan itu lebih cocok dengan pola pikir Anda. Banyak metodologi Agile mencoba menemukan cara untuk menjauh dari perencanaan jangka panjang yang terperinci.

Metodologi Agile mencoba untuk meminimalkan spesifikasi teknis dan dokumentasi rinci dalam mendukung kode dokumentasi diri dan terisolasi, cerita pengguna atom dan akhirnya perangkat lunak yang berfungsi. Dalam tim Agile yang efisien, akan ada jumlah minimum waktu yang dihabiskan untuk perencanaan.

Baca Agile Manifesto dan lihat Scrum . Gunakan metode Pengembangan Iteratif dan Pengembangan sistem dinamis untuk memandu proyek.

Kelemahan utama dengan pendekatan Agile adalah Anda harus mengakui secara terbuka bahwa Anda tidak tahu ruang lingkup persis proyek Anda , dan mendapatkan dukungan manajemen terhadap ide ini bisa sangat sulit, dan biasanya membutuhkan waktu. Lihat pertanyaan dan jawaban ini dan posting ini untuk beberapa tips tentang itu.

Namun memang benar bahwa ketika Anda menjadi programmer yang lebih senior Anda mungkin akan melakukan lebih sedikit pengkodean, tapi saya pikir bahwa dalam tim Agile bukannya berarti Anda menulis lebih banyak spesifikasi teknis, itu berarti Anda menghabiskan lebih banyak waktu mengelola dan bimbingan anggota tim Anda dan membuat keputusan arsitektur tentang kode.


4
"Rencana proyek jangka panjang terperinci terkenal karena biasanya sangat tidak akurat." DING DING DING +1
Ryan Kinal

11

Ya itu mungkin. Namun, jika Anda ingin menjadi insinyur perangkat lunak yang baik atau arsitek perangkat lunak di situlah perencanaan tingkat tinggi Anda ikut berperan. Bagi saya, perbedaan utama antara seorang programmer dan seorang insinyur adalah kemampuan untuk melihat gambaran besarnya.


1
Saya tidak keberatan merencanakan pekerjaan yang saya lakukan sekarang / dalam 2 minggu ke depan. Artinya, jika apa yang akan saya tulis melibatkan banyak bagian, saya tidak keberatan merencanakan itu pada tingkat tinggi dan kemudian melakukannya (pada kenyataannya - itulah yang akan saya lakukan). Saya tidak berhasil mencoba mencari kencan berbulan-bulan di masa depan - kemudian mencoba mencari tahu mengapa kita tidak akan melakukannya. Di situlah frustrasi pribadi saya mulai memuncak.
MattW

Saya mencoba untuk tidak membiarkan hal itu membuat saya frustrasi. Saya mencoba menyematkan hal semacam itu pada manajer proyek;).
Blaise Swanwick

Untuk menambahkan komentar Blaise. Manajer yang buruk bersikeras untuk memenuhi jadwal dan menyalahkan tim karena kehilangan "komitmen". Dalam lingkungan itu, jadwal tentu saja membuat frustrasi. Manajer yang baik menyadari bahwa jadwal awal adalah perkiraan dasar dan bukan komitmen. Mereka tahu bahwa beberapa tugas akan memakan waktu lebih lama dan beberapa lebih pendek. Yang paling menarik bagi mereka adalah tren jangka panjang. mis. Kami saat ini menjalankan 20% di belakang pada jadwal baseline selama 3 bulan. Itu kemungkinan berarti kita akan menjalankan 20% pada tugas-tugas serupa yang tersisa. Mereka kemudian menggunakan jadwal baru ini untuk mengelola proyek.
Dunk

9

Apakah mungkin untuk menjadi programmer yang baik dan bukan perencana tingkat tinggi?

Untuk sementara, ya. Apakah mungkin untuk melakukan ini dalam waktu lama? Tidak.

Dengan banyak pengusaha saat ini, itu adalah prosedur operasi standar untuk memberikan kenaikan biaya hidup industri yang kompetitif. Jika Anda tidak memperbaiki diri sendiri, jangan mencoba untuk mengatasi masalah yang lebih besar dan lebih sulit, kenaikan yang kompetitif di industri akan membuat Anda keluar dari pasar dalam lima atau sepuluh tahun. Pertahankan ini dan majikan Anda pada akhirnya akan mulai mencari alasan untuk menyingkirkan Anda, dan kemampuan kerja Anda di tempat lain akan berkurang secara drastis juga.


Saya bingung. Kenaikan COL harus mengimbangi laju inflasi, secara teori. Apakah Anda menyarankan agar uang riil yang dibayarkan kepada pengembang perangkat lunak secara bertahap menurun dari waktu ke waktu? Atau bahwa kenaikan COL umumnya lebih dari kenaikan biaya hidup yang sebenarnya? Saya akan mengatakan kekhawatiran yang lebih besar adalah bahwa ketidakmampuan untuk menunjukkan pertumbuhan, itu sendiri, umumnya dianggap negatif. Namun, ada cara lain untuk menunjukkan pertumbuhan, seperti luasnya atau kedalaman keterampilan teknis.
Ethel Evans

1
Saya seharusnya mengatakan kenaikan yang kompetitif di industri daripada kenaikan biaya hidup. Saya mengedit jawaban saya untuk mengatakan hal itu. Kenaikan kompetitif industri cukup manis untuk dewasa muda, biasanya jauh lebih baik daripada inflasi. Kenaikan biaya hidup adalah untuk kabut lama. Ada masalah ketika seseorang mendapat kenaikan gaji lebih tinggi dari inflasi tetapi keterampilan orang itu tetap merupakan hal baru.
David Hammen

Kena kau! Terima kasih telah mengklarifikasi, itu jelas masuk akal.
Ethel Evans

Saya berpendapat, sayangnya, bahwa seiring waktu keterampilan pemrograman semakin mudah dipelajari, dan dengan demikian, keterampilan seorang insinyur yang ada, tidak mengalami penurunan nilai di luar COL.
New Alexandria

6

Tentu, Anda bisa menjadi programmer yang baik, dari sudut pandang programmer. Dari sudut pandang manajemen adalah pertanyaan lain. Dalam pengalaman saya, terlibat dalam proses perencanaan adalah cara terbaik untuk 1) mendapatkan tugas pemrograman yang lebih menarik dan 2) melakukannya dengan cara yang Anda inginkan.

Dengan kata lain, begitu sampai ke perencanaan jangka pendek, banyak pilihan yang keluar dari meja. Jika solusi pilihan Anda akan memakan waktu enam minggu tetapi mereka hanya menganggarkan dua, Anda terjebak dengan apa yang mereka putuskan. Jika Anda memiliki kekhawatiran tentang sesuatu yang sudah mereka bahas dalam perencanaan jangka panjang, mereka tidak akan mau mengulanginya.

Jika Anda senang dengan keadaan itu, lebih banyak kekuatan untuk Anda. Kebanyakan orang menjadi kurang puas dengan semakin banyak pengalaman yang mereka dapatkan.

Rahasia kecil yang kotor adalah tidak ada seorang pun yang sangat baik dalam perencanaan dan estimasi jangka panjang. Perencana yang lebih baik adalah mereka yang menyadari keterbatasan mereka, jadi percayalah atau tidak, Anda berada di depan kurva. Dapatkan beberapa pelatihan akuntansi untuk ketidakpastian dalam estimasi. Lihatlah teknik-teknik seperti penjadwalan berdasarkan bukti atau scrum, yang mengandalkan data historis untuk menunjukkan seberapa akurat perkiraan Anda. Anda akan lebih bahagia dalam jangka panjang jika Anda memiliki suara yang lebih besar dalam pekerjaan Anda.


"Rahasia kecil yang kotor adalah tidak ada yang sangat bagus dalam perencanaan dan estimasi jangka panjang." Bukankah itu benar! +1 hanya untuk itu. Bahkan dengan sejarah yang baik, ada banyak angka yang perlu dipetik dari langit biru jernih karena proyek berikutnya tidak pernah merupakan salinan persis dari proyek sebelumnya. Jika ya, kami dapat menggunakan kembali semua kode apa adanya dan selesai dengan ASAP. Selalu ada sesuatu yang baru, dan kinerja masa lalu tidak selalu merupakan indikator yang baik tentang bagaimana upaya diperlukan untuk hal-hal baru itu.
David Hammen

Ok - jadi mungkin frustrasi (dan bahkan ego ) lebih dari apa yang saya butuhkan untuk mengelola. Jika saya tidak bisa menyalahkan diri sendiri terlalu buruk dan semakin baik dengan waktu (alih-alih mengatakan "Saya tidak suka melakukan ini") - Saya akan menjadi lebih baik dalam jangka panjang. Saya bisa sulit pada diri saya sendiri ketika saya melakukannya dengan buruk - tetapi tampaknya (berdasarkan jawaban di sini) saya lebih baik belajar melakukannya dengan baik jika saya ingin tetap bekerja sebagai insinyur perangkat lunak. Saya menghargai pikiran semua orang. Saya benar-benar tidak memiliki siapa pun di perusahaan saya untuk belajar ini - jadi mendengar ini dari semua orang di sini adalah bantuan besar!
MattW

3

Apakah mungkin untuk menjadi programmer yang baik dan bukan perencana tingkat tinggi?

Jawaban Singkat: Ya itu mungkin.

Namun, semakin Anda mendapatkan pengalaman dengan jenis proyek yang Anda terlibat, semakin baik ide perencanaan yang akan Anda miliki. Idealnya, sebagai programmer kita memiliki beberapa pendekatan bagaimana menyelesaikan masalah atau kita mencari satu. Jadi, jika kita tahu pendekatannya maka kita mungkin mulai berpikir tentang perencanaan :)

Rute lain yang mungkin adalah bahwa seorang programmer yang menjadi perencana yang baik juga akhirnya menuju Manajemen Proyek. Jadi, jika Anda memiliki minat dalam pengelolaan proyek, Anda dapat melakukan upaya ekstra ke arah itu.


1

Ya dan Tidak adalah jawaban Anda.

Di satu sisi, Anda didorong ke arah manajemen proyek. IMO, semua programmer yang baik memiliki beberapa tingkat kemampuan manajemen proyek, tetapi mereka memiliki keahlian yang berbeda. Kemampuan untuk merencanakan untuk jangka panjang meningkatkan kemampuan Anda untuk berkomunikasi dengan manajemen proyek yang sebenarnya. Jadi "tidak" Anda tidak bisa menjadi programmer yang baik tanpa kemampuan untuk merencanakan jangka panjang.

Yang telah dikatakan, manajemen proyek adalah keahlian yang berbeda yang menarik bagi aspek yang terkait tetapi berbeda dari pemrograman. Jadi di sinilah "ya" berperan. Anda tidak harus menjadi manajer proyek untuk menjadi programmer yang hebat.

Untuk situasi spesifik Anda, cobalah untuk menjadi lebih objektif tentang apa yang dibutuhkan perusahaan dan juga apa yang Anda sukai. Ada terlalu banyak ego yang tercermin dalam pertanyaan Anda dan itu bias kemampuan Anda untuk melihat situasi ini. Jika Anda dapat menemukan cara untuk berkontribusi lebih banyak kepada atasan Anda sambil tetap melakukan hal-hal yang Anda sukai, maka Anda harus mempertimbangkannya dan membicarakannya dengan atasan Anda.


1

Perencanaan dan Bos Bungie

Dilbert memiliki banyak strip tentang bos bungie. Tantangan dan harapan kita tentang perencanaan dapat menjadi sebab dan akibat dari krisis kepemimpinan. Pengalaman saya di perusahaan Fortune 100 adalah bahwa dalam satu tahun, semua orang yang memulai tahun sebagai pemimpin proyek keluar. Mungkin ini karena masalah perencanaan. Tidak yakin apakah mantan pemimpin Anda pergi karena alasan ini, tetapi ketika peran Anda mengharuskan Anda membuat rencana dengan komitmen, jika itu tidak terjadi, seringkali, jalan keluar terkait tenggat waktu adalah hasilnya.

Konteks Perencanaan Organisasi

Jika Anda merasa tidak nyaman dengan perencanaan, mungkin Anda merasa tidak nyaman untuk bertanggung jawab atas komitmen yang dibuat untuk pemasaran atau pemangku kepentingan lainnya sebelum masalah yang akan dipecahkan didokumentasikan atau dipahami. Ini adalah insting yang bagus.

Perencanaan adalah alat yang penting. Jangan abaikan itu. Jangan salah paham.

Perencanaan secara integral terkait dengan komitmen, akuntabilitas, dan kekuatan negosiasi. Perencanaan yang tangkas memiliki banyak kelebihan. Anda harus tahu tekniknya, serta teknik metodologi yang direncanakan. Organisasi Anda mungkin memiliki pendekatan sendiri dan mendapatkan saran dan bekerja dengan seseorang yang telah bertahan dalam kepemimpinan banyak proyek yang secara mengejutkan sangat membantu.

Contoh Perencanaan Sederhana - Tidak boleh mengenai perangkat lunak ...

Jika sebuah perusahaan atap datang ke rumah saya untuk mengajukan tawaran penggantian, jika mereka menawar terlalu rendah, mereka mungkin kehilangan uang pada pekerjaan itu, tetapi jika mereka menawar terlalu tinggi, mereka tidak akan mendapatkan pekerjaan sama sekali. Bagaimanapun, mereka gulung tikar. Dalam peran baru Anda, jika Anda sedikit terlalu rendah, Anda akan menjalankan proyek sampai akuntabilitas dimulai, maka Anda akan memiliki masalah. Jika Anda memperkirakan suatu proyek dengan bantalan yang cukup untuk memastikan kesuksesan pada tenggat waktu, mereka banyak memilih orang lain untuk memimpin. Kicker adalah bahwa Anda tidak menyukai roofer. Dia bisa melihat seberapa besar atapnya, dan memiliki data historis tentang berapa lama ukuran atap itu.

Menjadi Perencana yang Lebih Baik

Anda mungkin ingin mempertimbangkan semacam pelatihan. Dalam metodologi Agile, dan metodologi terencana terbaru, estimasi adalah aktivitas tim secara luas. Konsekuensinya, Anda harus mempertimbangkan untuk mendapatkan pelatihan untuk tim Anda juga.

Dari pengalaman, saya dapat memberitahu Anda bahwa frustasi untuk mendapatkan perkiraan dari anggota tim yang akan menundanya, memberi Anda perkiraan yang mereka buat dalam dua menit berdasarkan nama tugas tanpa merujuk pada persyaratan atau deskripsi fitur atau kode yang ada, atau yang bersikeras bahwa beberapa tugas yang Anda daftarkan dapat dilakukan dalam beberapa hari, meskipun proyek-proyek sebelumnya telah menghabiskan waktu berminggu-minggu untuk masalah yang sama.

Ada berbagai kursus dan sertifikasi pelatihan manajer proyek, tetapi saya akan mencari satu yang terakreditasi secara independen. Mungkin ada baiknya dipikirkan sebelum memilih untuk mensertifikasi dengan pendekatan berdasarkan metodologi yang direncanakan jika Anda berharap untuk bekerja dengan tim Agile (atau sebaliknya).

SLIM adalah metode yang ditemukan oleh Putnam setelah bekerja di GE dan perusahaan lain pada proyek DoD pada 1970-an. SLIM berpengaruh, dan perusahaannya QSM menawarkan sertifikasi yang tampaknya mengalir keluar dari alat yang mereka buat. Bergantung pada apakah perusahaan Anda telah mengadopsi alat mereka, itu mungkin tidak memiliki nilai atau nilai tinggi.

Steve McConnell (penulis Code Complete) juga menulis buku tentang estimasi perangkat lunak, dan perusahaannya Construx mengajarkan dua kelas untuk kredit PDU yang terakreditasi melalui Project Management Institute. Saya memiliki bukunya, dan jika saya ingin belajar tentang topik melalui pelatihan kelas, saya mungkin akan memilih Construx. Mereka juga melakukan pelatihan Scrum dan mengelola berbagai penilaian scrum yang terakreditasi melalui Scrum.org.

Sumber lain yang dapat memberikan pelatihan akademis yang hebat tentang estimasi proyek perangkat lunak, akan menjadi kelompok Barry Boehm di USC , berdasarkan pada pekerjaan ekstensif mereka pada pemodelan biaya konstruktif COCOMO dan COSYSMO yang telah digunakan di NASA dan kontraktor besar lainnya untuk memperkirakan proyek yang sangat besar. Saya tidak yakin saya benar-benar percaya pada COCOMO, tapi saya suka pekerjaan empiris yang telah mereka lakukan untuk mengkorelasikan efek skala dan driver biaya pada durasi jadwal.

Saya juga menemukan bab dari buku teks yang diterbitkan oleh O'Reilly yang secara singkat membahas metode estimasi perangkat lunak utama termasuk Watts Humphreys PROBE dan permainan perencanaan Kent Beck. PROBE mencakup gagasan bahwa para insinyur melacak metrik berdasarkan produktivitas mereka sendiri, kemudian menerapkannya pada bagian yang ditugaskan pada proyek-proyek baru. Game Perencanaan sangat kolaboratif antara pengembang dan pemangku kepentingan lainnya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.