MANAJEMEN PROYEK PERANGKAT LUNAK
3.12 ORGANISASI DAN STRUKTUR TIM
chart untuk masalah MIS pada Gambar 3.8 ditunjukkan pada Gambar 3.12. Bagan Gantt berguna untuk perencanaan sumber daya (yaitu mengalokasikan sumber daya untuk kegiatan). Berbagai jenis sumber daya yang perlu dialokasikan untuk kegiatan termasuk staf, perangkat keras, dan perangkat lunak.
Bagan Gantt adalah jenis bagan batang khusus di mana setiap batang mewakili suatu aktivitas. Bar digambar sepanjang garis waktu. Panjang setiap batang sebanding dengan durasi waktu yang direncanakan untuk aktivitas yang bersangkutan. Representasi bagan Gantt dari jadwal proyek sangat membantu dalam merencanakan pemanfaatan sumber daya, sedangkan bagan PERT berguna untuk memantau kemajuan kegiatan secara tepat waktu. Juga, lebih mudah untuk mengidentifikasi aktivitas paralel dalam sebuah proyek menggunakan grafik PERT. Manajer proyek perlu mengidentifikasi aktivitas paralel dalam proyek untuk penugasan ke developer yang berbeda.
Pemantauan dan pengendalian proyek
Setelah proyek berjalan, manajer proyek memantau proyek secara terus menerus untuk memastikan bahwa proyek berjalan sesuai rencana. Manajer proyek menunjuk peristiwa penting tertentu seperti penyelesaian beberapa aktivitas penting sebagai tonggak sejarah. Beberapa contoh tonggak adalah sebagai berikut—sebuah tonggak dapat berupa persiapan dan peninjauan dokumen SRS, penyelesaian pengkodean dan pengujian unit, dll.
Setelah tonggak tercapai, manajer proyek dapat mengasumsikan bahwa beberapa kemajuan terukur telah dibuat. Jika keterlambatan dalam mencapai tonggak diprediksi, maka tindakan korektif mungkin harus diambil. Ini mungkin memerlukan pengerjaan ulang semua jadwal dan menghasilkan jadwal baru.
Seperti yang telah disebutkan, grafik PERT sangat berguna dalam pemantauan dan pengendalian proyek. Lintasan dalam graf ini adalah himpunan simpul dan tepi yang berurutan dari simpul awal hingga simpul terakhir. Jalur kritis dalam grafik ini adalah jalur di mana setiap tonggak penting untuk memenuhi tenggat waktu proyek. Dengan kata lain, jika ada penundaan yang terjadi di sepanjang jalur kritis, seluruh proyek akan tertunda. Oleh karena itu, penting untuk mengidentifikasi semua jalur kritis dalam jadwal—mengikuti jadwal tugas yang muncul di jalur kritis adalah sangat penting untuk memenuhi tanggal pengiriman. Harap dicatat bahwa mungkin ada lebih dari satu jalur kritis dalam jadwal. Tugas di sepanjang jalur kritis disebut tugas kritis. Tugas-tugas kritis perlu dipantau secara ketat dan tindakan korektif perlu dimulai segera setelah keterlambatan diketahui. Jika perlu, seorang manajer dapat mengalihkan sumber daya dari tugas non-kritis ke tugas kritis sehingga semua tonggak sepanjang jalur kritis terpenuhi.
Beberapa alat tersedia yang dapat membantu Anda untuk mengetahui jalur kritis dalam jadwal yang tidak dibatasi, tetapi mencari tahu jadwal yang optimal dengan keterbatasan sumber daya dan dengan sejumlah besar tugas paralel adalah masalah yang sangat sulit. Ada beberapa produk komersial untuk mengotomatisasi teknik penjadwalan yang tersedia. Alat populer untuk membantu menggambar grafik terkait jadwal termasuk perangkat lunak MS-Project yang tersedia di komputer pribadi.
Struktur organisasi
Pada dasarnya ada tiga cara luas di mana organisasi pengembangan perangkat luna k dapat terstruktur — format fungsional, format proyek, dan format matriks.
Format fungsional
Dalam format fungsional, staf pengembangan dibagi berdasarkan kelompok fungsional tertentu di mana mereka berasal. Format ini secara skematis telah ditunjukkan pada Gambar 3.13(a). Proyek-proyek yang berbeda meminjam developer dari berbagai kelompok fungsional untuk fase tertentu dari proyek dan mengembalikan mereka ke kelompok fungsional setelah selesainya fase. Akibatnya, tim programmer yang berbeda dari kelompok fungsional yang berbeda melakukan fase proyek yang berbeda. Misalnya, satu tim mungkin melakukan spesifikasi persyaratan, yang lain melakukan desain, dan seterusnya. Produk yang selesai sebagian berpindah dari satu tim ke tim lain saat produk berkembang. Oleh karena itu, format fungsional memerlukan komunikasi yang cukup di antara tim yang berbeda dan pengembangan dokumen berkualitas baik karena pekerjaan satu tim harus dipahami dengan jelas oleh tim berikutnya yang mengerjakan proyek. Oleh karena itu, organisasi fungsional mengamanatkan dokumentasi berkualitas baik untuk dihasilkan setelah setiap kegiatan.
Format proyek
Dalam format proyek, staf pengembangan dibagi berdasarkan proyek tempat mereka bekerja (Lihat Gambar 3.13(b)). Satu set developer ditugaskan untuk setiap proyek pada awal proyek, dan tetap bersama proyek sampai penyelesaian proyek. Dengan demikian, tim yang sama melakukan semua aktivitas siklus hidup. Keuntungan dari format proyek adalah menyediakan rotasi pekerjaan. Artinya, setiap developer melakukan aktivitas siklus hidup yang berbeda dalam sebuah proyek. Namun, ini menghasilkan pemanfaatan tenaga kerja yang buruk, karena tim proyek penuh dibentuk sejak awal proyek, dan sangat sedikit pekerjaan untuk tim selama fase awal siklus hidup.
Gambar 3.13 Representasi skematis dari organisasi fungsional dan proyek.
Format fungsional versus proyek
Meskipun komunikasi yang lebih besar di antara anggota tim mungkin tampak sebagai overhead yang dapat dihindari, format fungsional memiliki banyak keuntungan. Keuntungan utama dari organisasi fungsional adalah:
• Kemudahan penempatan staf
• Produksi dokumen berkualitas baik
• Spesialisasi pekerjaan
• Penanganan masalah yang terkait dengan pergantian tenaga kerja3 secara efisien.
Organisasi fungsional memungkinkan developer untuk menjadi spesialis dalam peran tertentu, mis. analisis persyaratan, desain, pengkodean, pengujian, pemeliharaan, dll. Mereka melakukan peran ini berulang kali untuk proyek yang berbeda dan mengembangkan wawasan mendalam untuk pekerjaan mereka. Ini juga menghasilkan lebih banyak perhatian yang diberikan pada dokumentasi yang tepat di akhir fase karena kebutuhan yang lebih besar untuk komunikasi yang jelas antara tim yang melakukan fase yang berbeda. Organisasi fungsional juga memberikan solusi yang efisien untuk masalah kepegawaian. Masalah staf proyek berkurang secara signifikan karena personel dapat dibawa ke proyek sesuai kebutuhan, dan dikembalikan ke kelompok fungsional ketika mereka tidak lagi dibutuhkan. Ini mungkin adalah keuntungan paling penting dari organisasi fungsional.
Struktur organisasi proyek memaksa manajer untuk menerima jumlah developer yang hampir konstan selama seluruh durasi proyeknya. Hal ini mengakibatkan developer tidak bekerja pada fase awal pengembangan perangkat lunak dan berada di bawah tekanan luar biasa pada fase pengembangan selanjutnya. Keuntungan lebih lanjut dari organisasi fungsional adalah lebih efektif dalam menangani masalah pergantian tenaga kerja. Ini karena developer dapat didatangkan dari kumpulan fungsional saat dibutuhkan. Selain itu, organisasi ini mengamanatkan produksi dokumen berkualitas baik, sehingga developer baru dapat dengan cepat terbiasa dengan pekerjaan yang sudah dilakukan.
Terlepas dari beberapa keuntungan penting dari organisasi fungsional, itu tidak terlalu populer di industri perangkat lunak. Paradoks yang tampak ini tidak sulit untuk dijelaskan. Kita dapat dengan mudah mengidentifikasi tiga poin berikut:
• Format proyek memberikan rotasi pekerjaan kepada anggota tim. Artinya, setiap anggota tim mengambil peran sebagai desainer, koder, penguji, dll selama proyek berlangsung. Di sisi lain, mengingat kekurangan keterampilan saat ini, akan sangat sulit bagi organisasi fungsional untuk mengisi slot untuk beberapa peran seperti kelompok pemeliharaan, pengujian, dan pengkodean.
• Masalah lain dengan organisasi fungsional adalah jika sebuah organisasi menangani proyek yang membutuhkan pengetahuan tentang area domain khusus, maka pakar domain ini tidak dapat dibawa masuk dan keluar dari proyek untuk fase yang berbeda, kecuali jika perusahaan menangani sejumlah besar proyek semacam itu.
• Untuk alasan yang jelas format fungsional tidak cocok untuk organisasi kecil yang hanya menangani satu atau dua proyek.
Format matriks
Sebuah organisasi matriks dimaksudkan untuk memberikan keuntungan dari kedua struktur fungsional dan proyek. Dalam organisasi matriks, kumpulan spesialis fungsional ditugaskan untuk proyek yang berbeda sesuai kebutuhan. Dengan demikian, penyebaran spesialis fungsional yang berbeda dalam proyek yang berbeda dapat direpresentasikan dalam matriks (lihat Gambar 3.14) Pada Gambar 3.14 mengamati bahwa anggota yang berbeda dari spesialisasi fungsional ditugaskan untuk proyek yang berbeda. Oleh karena itu dalam organisasi matriks, manajer proyek perlu berbagi tanggung jawab untuk proyek dengan sejumlah manajer fungsional individu.
Gambar 3.14 Organisasi matriks.
Organisasi matriks dapat dicirikan sebagai lemah atau kuat, tergantung pada otoritas relatif dari manajer fungsional dan manajer proyek. Dalam matriks fungsional yang kuat, manajer fungsional memiliki wewenang untuk menugaskan pekerja ke proyek dan manajer proyek harus menerima personel yang ditugaskan. Dalam matriks yang lemah, manajer proyek mengontrol anggaran proyek, dapat menolak pekerja dari kelompok fungsional, atau bahkan memutuskan untuk mempekerjakan pekerja luar. Dua masalah penting yang sering dialami oleh organisasi matriks adalah:
• Konflik antara manajer fungsional dan manajer proyek atas alokasi pekerja.
• Pergeseran pekerja yang sering dalam mode pemadam kebakaran karena krisis terjadi di berbagai proyek.
Struktur Tim
Struktur tim membahas organisasi tim proyek individu. Mari kita periksa kemungkinan cara di mana tim proyek individu diatur. Dalam teks ini, kita hanya akan mempertimbangkan tiga struktur tim formal-demokratis, kepala programmer, dan organisasi tim kontrol campuran, meskipun beberapa variasi lain dari struktur ini dimungkinkan. Proyek dengan kompleksitas dan ukuran tertentu seringkali membutuhkan struktur tim khusus untuk kerja yang efisien.
Ketua tim programmer
Dalam organisasi tim ini, seorang insinyur senior memberikan kepemimpinan teknis dan ditunjuk sebagai kepala pemrogram. Kepala programmer membagi tugas menjadi banyak tugas yang lebih kecil dan menugaskannya kepada anggota tim. Dia juga memverifikasi dan mengintegrasikan produk yang dikembangkan oleh anggota tim yang berbeda. Struktur tim kepala programmer ditunjukkan pada Gambar 3.15. Programmer utama memberikan otoritas, dan struktur ini bisa dibilang lebih efisien daripada tim demokratis untuk masalah yang dipahami dengan baik. Namun, tim kepala programmer mengarah ke moral tim yang lebih rendah, karena anggota tim bekerja di bawah pengawasan konstan kepala pemrogram. Ini juga menghambat pemikiran asli mereka. Tim programmer kepala tunduk pada kegagalan titik tunggal karena terlalu banyak tanggung jawab dan wewenang diberikan kepada programmer utama. Artinya, sebuah proyek mungkin sangat menderita, jika kepala programmer meninggalkan organisasi atau menjadi tidak tersedia karena beberapa alasan lain.
Gambar 3.15 Struktur tim kepala programmer.
Tim programmer kepala mungkin merupakan cara paling efisien untuk menyelesaikan proyek sederhana dan kecil karena programmer kepala dapat dengan cepat membuat desain yang memuaskan dan meminta programmer untuk mengkodekan modul yang berbeda dari solusi desainnya. Sekarang mari kita coba memahami jenis proyek yang cocok untuk organisasi tim programmer kepala. Misalkan sebuah organisasi telah berhasil menyelesaikan banyak proyek SIM sederhana. Kemudian, untuk proyek MIS serupa, struktur tim kepala programmer dapat diadopsi. Struktur tim programmer kepala bekerja dengan baik ketika tugas berada dalam jangkauan intelektual satu individu. Namun, bahkan untuk masalah yang sederhana dan mudah dipahami, organisasi harus selektif dalam mengadopsi struktur kepala pemrogram. Struktur tim programmer kepala tidak boleh digunakan kecuali pentingnya penyelesaian awal melebihi faktor-faktor lain seperti moral tim, pengembangan pribadi, dll.
Tim Demokrat
Struktur tim demokratis, seperti namanya, tidak memaksakan hierarki tim formal (lihat Gambar 3.16). Biasanya, seorang manajer memberikan kepemimpinan administratif. Pada waktu yang berbeda, anggota kelompok yang berbeda memberikan kepemimpinan teknis.
Gambar 3.16 Struktur tim Demokrat.
Dalam organisasi yang demokratis, anggota tim memiliki semangat kerja dan kepuasan kerja yang lebih tinggi. Akibatnya, ia menderita lebih sedikit pergantian tenaga kerja.
Meskipun tim demokratis kurang produktif dibandingkan dengan tim programmer utama, struktur tim demokratis sesuai untuk masalah yang kurang dipahami, karena sekelompok developer dapat menemukan solusi yang lebih baik daripada satu individu seperti dalam tim
programmer utama. Struktur tim yang demokratis cocok untuk proyek berorientasi penelitian yang membutuhkan kurang dari lima atau enam pengembang. Untuk proyek berukuran besar, organisasi demokrasi murni cenderung menjadi kacau. Organisasi tim demokratis mendorong pemrograman tanpa ego karena programmer dapat berbagi dan meninjau pekerjaan satu sama lain. Untuk menghargai konsep pemrograman tanpa ego, kita perlu memahami konsep ego dari perspektif psikologis.
Sebagian besar dari Anda mungkin pernah mendengar tentang seniman temperamental yang sangat bangga dengan apa pun yang mereka buat. Biasanya, psikologi manusia membuat seorang individu bangga dengan segala sesuatu yang ia ciptakan dengan menggunakan pemikiran orisinal. Pengembangan perangkat lunak membutuhkan pemikiran orisinal juga, meskipun dari jenis yang berbeda. Psikologi manusia membuat seseorang terlibat secara emosional dengan ciptaannya dan menghalanginya dari pemeriksaan objektif atas ciptaannya. Sama seperti seniman temperamental, programmer merasa sangat sulit untuk menemukan bug dalam program mereka sendiri atau kekurangan dalam desain mereka sendiri. Oleh karena itu, cara terbaik untuk menemukan masalah dalam desain atau kode adalah meminta seseorang untuk meninjaunya.
Gambar 3.17 Struktur tim campuran.
Seringkali, harus menjelaskan program seseorang kepada orang lain memberi seseorang cukup objektivitas untuk mencari tahu apa yang mungkin salah. Pengamatan ini adalah ide dasar di balik penelusuran kode yang akan dibahas dalam Bab 10. Penerapannya, adalah untuk mendorong tim demokratis untuk berpikir bahwa desain, kode, dan hasil lainnya adalah milik seluruh kelompok. Ini disebut pemrograman tanpa ego karena mencoba untuk menghindari programmer menginvestasikan banyak ego dalam aktivitas pengembangan yang mereka lakukan dalam pengaturan yang demokratis. Namun, struktur tim yang demokratis memiliki satu kelemahan—anggota tim mungkin membuang banyak waktu untuk berdebat tentang hal-hal sepele karena kurangnya otoritas dalam tim untuk menyelesaikan perdebatan.
Organisasi tim kontrol campuran
Organisasi tim kontrol campuran, seperti namanya, mengacu pada ide-ide dari organisasi demokratis dan organisasi kepala-programmer. Organisasi tim kontrol campuran ditunjukkan pada Gambar 3.17. Organisasi tim ini menggabungkan pelaporan hierarkis dan pengaturan demokratis. Pada Gambar 3.17, jalur komunikasi ditampilkan sebagai garis putus- putus dan struktur pelaporan ditampilkan menggunakan panah padat. Organisasi tim kontrol campuran cocok untuk ukuran tim yang besar. Penataan demokratis di tingkat developer senior digunakan untuk menguraikan masalah menjadi bagian-bagian kecil. Setiap pengaturan demokratis di tingkat programmer mencoba solusi untuk satu bagian. Dengan demikian, organisasi tim ini sangat cocok untuk menangani program yang besar dan kompleks. Struktur tim ini sangat populer dan digunakan di banyak perusahaan pengembangan perangkat lunak.