{"id":593,"date":"2022-01-26T01:46:08","date_gmt":"2022-01-26T01:46:08","guid":{"rendered":"https:\/\/www.cybermedian.com\/id\/?p=593"},"modified":"2025-02-14T16:50:18","modified_gmt":"2025-02-14T08:50:18","slug":"cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/id\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"Tim lintas fungsi vs Tim mandiri vs Tim fitur vs Tim komponen dalam Agile"},"content":{"rendered":"
\n
\n
\n

Secara tradisional, sebuah proyek diorganisir di sekitar tim komponen<\/strong> (yaitu UX, Dev, Bisnis, Penguji, dan \u2026), setiap rilis yang memerlukan berbagai keahlian komponen akan membutuhkan keterlibatan beberapa tim komponen. Biasanya, tim yang berbeda akan memiliki set prioritas yang berbeda, yang pada akhirnya menyebabkan kemacetan dalam siklus rilis produk.<\/p>\n

Menurut Wikipedia, tim lintas fungsi adalah sekelompok orang dengan keahlian fungsional yang berbeda yang bekerja menuju tujuan bersama. Salah satu cara terbaik untuk meningkatkan kualitas tim Anda adalah dengan menjadikannya lintas fungsi. Tim lintas fungsi memiliki semua keterampilan yang diperlukan untuk mengubah ide menjadi produk yang berfungsi.<\/p>\n

\u201cSebuah <\/em>Tim lintas fungsi<\/em><\/strong> memiliki semua kompetensi yang diperlukan untuk menyelesaikan pekerjaan tanpa bergantung pada orang lain yang bukan bagian dari tim<\/em>\u201d\u200a\u2014\u200aPanduan Scrum<\/p>\n

Berlawanan dengan pendekatan tim komponen, sebuah tim lintas fungsi<\/strong> adalah kelompok yang terdiri dari orang-orang dari berbagai area fungsional di perusahaan.\u200a\u2014\u200aitu harus dibentuk tidak hanya dengan spesialis teknis (pengembang Back-end, Front-end, insinyur QA, dll.) tetapi juga terdiri dari anggota seperti Analis Bisnis, spesialis Pemasaran dan UX atau siapa pun yang mengambil bagian aktif dalam proyek.<\/p>\n

<\/figure>\n

Sebuah tim mandiri<\/strong> adalah tim yang memiliki otonomi untuk memilih cara terbaik untuk menyelesaikan pekerjaan mereka, daripada diarahkan oleh orang lain di luar tim. Berbeda dengan prinsip manajemen tradisional, tim mandiri yang diberdayakan tidak diarahkan dan dikendalikan dari atas; melainkan mereka berkembang dari anggota tim yang berpartisipasi secara aktif & kolektif dalam semua praktik dan acara Scrum.<\/p>\n

<\/figure>\n

Tim tradisional vs Tim Agile<\/p>\n

\u201cSebuah <\/em>Tim Organisasi Mandiri<\/em><\/strong> terdiri dari sekelompok pekerja pengetahuan yang harus mengelola diri mereka sendiri. Mereka harus memiliki otonomi\u201d\u200a\u2014\u200a<\/em>Peter Drucker.<\/p>\n

Panduan Scrum menunjukkan \u201cTim Scrum terdiri dari seorang Pemilik Produk, Tim Pengembangan, dan seorang Scrum Master. Mereka adalah:<\/p>\n

Tim Scrum<\/strong> adalah mandiri<\/strong> dan lintas fungsi<\/strong>\u201d\u200a\u2014\u200a<\/em>Panduan Scrum:<\/p>\n

Tim Komponen vs Tim Fitur<\/h3>\n

Pendekatan tradisional adalah memecah produk lebih atau kurang secara logis dan bermakna menjadi komponen dan menugaskan tim komponen kepada mereka. Namun, komponen-komponen ini sama sekali tidak relevan dari sudut pandang pelanggan.<\/p>\n

Pendekatan Tim Fitur sekarang hampir secara universal diterima sebagai cara untuk mengorganisir tim mereka, berbeda dengan tim tumpukan teknologi, terutama, dalam pendekatan pengiriman berkelanjutan, ini menekankan fitur (yaitu, irisan vertikal dari sistem) yang memenuhi kebutuhan pengguna yang dapat mempercepat pengiriman nilai dari fitur atau perangkat lunak yang berfungsi dan memperpendek umpan balik dari pengguna nyata. Tim fitur akan memiliki semua keterampilan untuk melakukan pekerjaan tingkat tugas yang diperlukan untuk menyelesaikan pekerjaan. Secara khusus, dengan asumsi arsitektur tiga tingkat, anggota tim akan bekerja pada tugas yang terkait dengan GUI, tingkat tengah, dan bagian basis data dari cerita ini.<\/p>\n

<\/figure>\n

Kekurangan besar dari organisasi komponen adalah jelas: itu memperlambat aliran nilai. Sebagian besar fitur sistem menciptakan ketergantungan yang memerlukan kerjasama antara tim komponen untuk membangun, menerapkan, dan akhirnya merilis. Tim menghabiskan banyak waktu mereka untuk mendiskusikan ketergantungan antara tim dan menguji perilaku antar komponen daripada dapat memberikan nilai kepada pengguna akhir.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n