Manajer Perangkat Lunak yang membuat pengembang melakukan Manajemen Proyek

Saya seorang pengembang perangkat lunak yang bekerja di perusahaan sistem embedded. Kami memiliki Manajer Proyek, yang mengurus jadwal proyek secara keseluruhan (termasuk listrik, kualitas, perangkat lunak dan manufaktur) sehingga jadwal perangkat lunaknya sangat singkat.

Kami juga memiliki Manajer Perangkat Lunak, siapa bos saya. Dia membuat saya menulis dan memelihara jadwal perangkat lunak, dokumen desain (desain tingkat tinggi dan rendah), SRS, manajemen perubahan, rencana dan laporan verifikasi, manajemen rilis, ulasan, dan tentu saja perangkat lunak.

Kami hanya memiliki satu Teknisi Uji untuk seluruh tim perangkat lunak (10 anggota), dan pada waktu tertentu, ada beberapa proyek yang sedang berlangsung.

Saya menghabiskan 80% waktu saya untuk membuat dokumen-dokumen ini. Bos saya berasal dari latar belakang Proses, dan percaya bahwa yang kita butuhkan adalah dokumentasi yang lebih baik untuk meningkatkan perangkat lunak:

1. Dia menganggap desain sebagai yang terpenting, pengkodean adalah "hanya menulis desain", seharusnya tidak terlalu lama, dan "semua kode harus ditulis sebelum perangkat keras siap".
2. Tidak mengerti perbedaan antara kontrol Versi Pusat & Terdistribusi, bahkan setelah kami katakan kepadanya lebih mudah untuk berkolaborasi dengan model terdistribusi.
3. Tidak mengerti kode, dan ingin memahami setiap bug dan solusi yang diajukannya.
4. Verifikasi orang percaya harus dilakukan oleh pengembang, dan validasi oleh Penguji. Masalahnya, verifikasi kami hanya memeriksa apakah implementasi sudah benar (kami tidak menulis tes unit, tidak pernah dipertimbangkan dalam jadwal), dan validasi adalah pengujian kotak hitam, sehingga tes unit tidak ada.

Saya sangat bingung.

1. Apakah saya bertanggung jawab untuk memelihara semua dokumen ini? Itu membuat saya merasa seperti sedang melakukan Manajemen Proyek Perangkat Lunak, pada dasarnya. Saya setuju dengan dokumentasi teknis, tapi saya percaya penjadwalan / perencanaan tidak boleh dilakukan oleh pengembang.
2. Saya tidak begitu suka membuat dokumen, saya ingin menyelesaikan masalah dan menulis kode. Dalam pengalaman saya, membuat dokumen desain hanya membantu sampai batas tertentu, tidak pernah solusi untuk kode yang lebih baik atau lebih cepat.
3. Saya merasa bos tidak terlalu peduli untuk membuat produk yang lebih baik, tetapi hanya tentang menjadi manajer yang baik di mata manajemen.

Apa yang dapat saya? Sepanjang tahun ini saya telah melakukan 3 bulan pengkodean aktual, sisanya hanya dihabiskan untuk membuat dokumen dan menunggu laporan bug dari klien.

Anda terdengar seperti Insinyur Perangkat Lunak.

Seorang Manajer Proyek lebih fokus pada status proyek secara keseluruhan dan mengalokasikan sumber daya secara efektif untuk memastikan bahwa tonggak pencapaian terpenuhi dan dalam waktu yang tepat. Mereka juga menghilangkan hambatan dan membantu sumber daya proyek fokus pada fungsi pekerjaan spesifik mereka.

Menulis dan memelihara desain dan dokumentasi teknis adalah bagian penting dari menjadi insinyur perangkat lunak dan sesuai untuk peran Anda. Terlalu banyak hal baik bisa buruk (Lihat Analisis Paraylsis )

Dia menganggap desain sebagai yang terpenting, pengkodean adalah "hanya menuliskan desainnya"

Jika manajer proyek menganggap dokumen desain sebagai yang terpenting, maka ia mengharapkan dokumen sebagai hasil dalam proses. Ini bukan waktu yang terbuang di pihak Anda jika dia merasa itu cukup penting untuk mengalokasikan 80% dari waktu Anda untuk itu.

seharusnya tidak terlalu lama, dan "semua kode harus ditulis sebelum perangkat keras siap".

Ini adalah angan-angan dan pandangan gaya air terjun kuno tentang bagaimana pengembangan perangkat lunak bekerja. Itu selalu tidak pernah bersih tidak peduli berapa banyak desain dan persiapan yang Anda curahkan. Namun, pada catatan itu, Anda harus memiliki spesifikasi perangkat keras yang jelas dan lingkungan pengujian yang tepat serta simulasi perangkat keras tiruan agar kode Anda dapat berinteraksi, tetapi sekali lagi, dunia nyata berantakan.

Manajemen proyek sangat mudah di dunia yang sempurna. Dunia ini tidak sempurna, betapapun Anda menginginkannya, membuat manajemen proyek nyata menjadi sangat sulit. Inilah sebabnya mereka dibayar mahal.

(2) Tidak memahami perbedaan antara kontrol Versi Pusat & Terdistribusi.

Kenapa dia harus peduli? Bagaimana pengaruhnya terhadap tonggak sejarah? Tidak.

3) Tidak mengerti kode, dan ingin memahami setiap bug dan solusi yang diajukannya

Tujuannya adalah untuk menjalankan perangkat lunak dan milik Anda juga harus. Dia tidak perlu memahami kode tetapi dia perlu memahami masalah yang mencegah perangkat lunak yang berfungsi. Begitu Anda berdua bertemu secara langsung pada tingkat dasar ini maka tujuan bersama Anda akan membantu Anda bekerja sama secara lebih efektif.

(4) Verifikasi orang percaya harus dilakukan oleh pengembang, dan validasi oleh Tester.

Apa yang salah dengan sentimen ini? Penguji dalam peran penjaminan mutu harus peduli dengan memvalidasi fitur dan persyaratan. Pengembang harus melakukan segala upaya untuk memverifikasi dan menguji pekerjaan mereka sebelum melakukan pengujian.

Saya tidak begitu suka membuat dokumen, saya ingin menyelesaikan masalah dan menulis kode.

Jika Anda lebih suka menjadi programmer sederhana maka mungkin Anda harus berbicara dengan atasan Anda tentang ini dan melihat apakah ada peran yang lebih baik bagi Anda dalam proyek tersebut. Seseorang perlu menulis dan memelihara dokumentasi teknis, jadi mungkin salah satu pengembang lain dapat membantu Anda dengan beberapa tugas ini sehingga Anda tidak menghabiskan 80% dari waktu Anda menulis dokumentasi.

Dalam pengalaman saya, membuat dokumen desain hanya membantu sampai batas tertentu, tidak pernah solusi untuk kode yang lebih baik atau lebih cepat.

Ini sebagian besar benar ... tetapi hanya jika semua pengembang menghabiskan 80% dari waktu mereka menulis dokumentasi teknis yang tidak akan pernah dibaca oleh siapa pun. Ini adalah anti-pola manajemen besar yang pernah saya jalani sebelumnya. Jika Anda mendapati bahwa Anda melakukan sebagian besar dokumentasi untuk tim, maka tampaknya tidak adil bahwa Anda ditolak hak untuk melakukan lebih banyak pekerjaan pengkodean.

Faktanya adalah bahwa dokumentasi teknis terbaik adalah kode itu sendiri.

Saya merasa bos tidak terlalu peduli untuk membuat produk yang lebih baik, tetapi hanya tentang menjadi manajer yang baik di mata manajemen

Saya merasa dia benar- benar peduli karena produknya adalah lingkungannya dan jika proyek dan fitur tidak selesai dan klien tidak senang maka manajemen tingkat atas tidak akan terlalu peduli padanya. Masalahnya adalah bahwa perspektif Anda tentang peningkatan kualitas yang diperlukan tidak sesuai dengannya, dan manajemen atas, dan persepsi klien tentang apa yang mereka anggap penting.

Cobalah untuk memahami apa yang benar-benar penting bagi produk, karena sementara Anda dapat meningkatkan efisiensi proses 3 kali lipat, jika Anda menghabiskan satu minggu melakukan hal ini maka itu adalah biaya fitur penting lain yang dituntut oleh klien.

Kita semua ingin terlihat baik di mata atasan kita. Tidak ada yang salah dengan itu, sudah menjadi sifat manusia untuk melayani diri sendiri. Ini adalah fakta kehidupan.

Untuk beberapa derajat, saya setuju dengan manajer proyek Anda. Pengembangan perangkat lunak melampaui fitur pengkodean. :-)

Mengingat situasi Anda, saya akan mendatanginya dan menjelaskan bahwa permintaannya menghabiskan 80% waktu Anda, dan berusaha memahami mengapa penting baginya bahwa Anda menghabiskan waktu ini dengan menjaga dokumentasi daripada mengembangkan (yang melampaui pengkodean).

FYI, Atlassion , sebuah perusahaan perangkat lunak, memiliki rasio 13 pengembang untuk satu orang QA dan sebagian besar pengujian (perencanaan dan pelaksanaan) dilakukan oleh pengembang. Saya mengetahui hal ini selama salah satu presentasi mereka di Agile 2012 dan tim kami saat ini berusaha meniru praktik ini.

Namun, saya juga akan membahas dengan manajer proyek Anda jika dia terbuka untuk mencoba Scrum sebagai metodologi untuk membantu memajukan seluruh tim. Dengan uraian Anda, saya tidak berpikir Anda menggunakan Scrum.

Seperti Anda, saya sangat frustrasi mempertahankan rencana yang terus berubah dan pendekatan ringan Scrum membantu saya mengatasi frustrasi ini.

Tim yang paling berkinerja dalam pengalaman saya adalah mereka yang menghadapi paling sedikit proses yang diperlukan untuk melakukan pekerjaan mereka. Pada titik tertentu, proses tambahan mulai menghilangkan kualitas dari produk. Jika QA mulai ketinggalan bug karena mereka lebih mementingkan mengeluarkan dokumen, dan DEV tidak mengkodekan fitur atau memperbaiki bug karena mereka menulis dokumentasi maka Anda memiliki masalah. Namun, mencari tahu apakah ini benar-benar terjadi di perusahaan Anda adalah pertanyaan yang sangat terlokalisasi yang hanya dapat dijawab oleh orang-orang di tim Anda (bukan kami).

Ada satu hal yang sangat salah bos Anda, dan itu adalah fakta bahwa Anda memiliki QA yang sangat sedikit dan tidak ada tes unit. Bug yang dibuat oleh adeveloper menurut definisi merupakan pengawasan di pihak mereka. Mengharapkan pengembang untuk selalu menguji fitur mereka sendiri dan memiliki sedikit pengujian selain dari itu adalah masalah proses. QA dapat diganti dengan pengujian otomatis tergantung pada domain Anda sampai batas tertentu, tetapi jika Anda tidak memilikinya, Anda mungkin membiarkan bug lolos (dan itu biasanya menghabiskan lebih banyak biaya daripada menemukannya lebih awal).

Juga, dari perspektif bisnis yang ketat, mempekerjakan QA lebih murah daripada merekrut pengembang. Anda akan dapat menutupi lebih banyak alasan untuk uang yang dihabiskan jika tim memiliki rasio QA / DEV yang baik.

Implementasi CMMI yang pernah saya lihat atau dengar secara langsung, semuanya merupakan proses dan dokumentasi yang berat; bos Anda percaya bahwa dokumentasi harus cukup detail untuk membuat implementasi sepele sangat menyiratkan bahwa harapannya sama.

Jika Anda menerima bagian yang tidak proporsional dari penulisan / pemeliharaan dokumentasi, meminta agar didistribusikan secara lebih merata adalah wajar. Jika pengembang lain memiliki dokumentasi yang mirip dengan rasio pengodean dan Anda ingin menghabiskan sebagian besar waktu Anda menulis kode; mungkin sudah waktunya untuk mempertimbangkan mencari majikan baru.

Anda sedang berbicara tentang sistem medis ... jadi keselamatan adalah yang terpenting - dan karena itu dokumentasi (khususnya keterlacakan) sangat penting.

Satu penguji tampaknya agak ringan, tetapi selain itu, ya - Anda bertanggung jawab untuk memastikan dokumentasi sudah ada.

Pengalaman saya di dunia medis terbatas, tetapi di dunia kedirgantaraan / pertahanan kita memiliki Do-178B (sekarang C) yang menetapkan model siklus hidup yang menentukan dokumentasi dan tingkat pengujian yang diperlukan (tergantung pada kekritisan keselamatan [lebih khusus, tingkat jaminan desain] dari perangkat lunak), dan di dunia otomotif kita memiliki ISO26262 yang melakukan hal yang sama.

Jika dokumentasi tidak ada, produk tidak mendapatkan sertifikat.

Tetapi yang penting adalah bekerja dengan dokumentasi yang diperlukan untuk membuat produk Anda lebih baik ... jangan mencoba dan merekayasa balik dokumentasi sebagai pemikiran setelah karena itu tidak melayani tujuan dunia nyata.