Scrum Master vs Product Owner: Perbandingan Peranan
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Product Owner bertanggungjawab memaksimumkan nilai produk dan mengurus apa yang masuk ke dalam Backlog: iaitu "apa" dan "mengapa". Scrum Master pula bertanggungjawab ke atas keberkesanan Pasukan Scrum dan cara pasukan bekerja: iaitu "bagaimana", bukan "apa". Jika kedua-duanya dikelirukan, hampir semua kekeliruan lain tentang kedua-dua tugas ini akan mengikutinya.
Kekeliruan ini cukup lazim sehingga kita perlu tepat sejak awal, kerana kedua-dua tugas ini sentiasa bercampur dalam amalan, sama ada Scrum Master yang diam-diam menyusun semula Backlog kerana Product Owner lambat, atau Product Owner yang mengendalikan Daily Scrum seperti mesyuarat status kerana tiada siapa memberitahunya supaya tidak berbuat demikian.
Fakta Utama
- Scrum Guide 2020 menyatakan bahawa Scrum "mentakrifkan tiga akauntabiliti khusus dalam Pasukan Scrum: Developer, Product Owner, dan Scrum Master," iaitu bahasa yang menggantikan "peranan" dalam edisi terdahulu.
- Menurut Guide tersebut, Product Owner "bertanggungjawab memaksimumkan nilai produk yang terhasil daripada kerja Pasukan Scrum," manakala Scrum Master "bertanggungjawab ke atas keberkesanan Pasukan Scrum."
- Pasukan Scrum "lazimnya terdiri daripada 10 orang atau kurang," menurut Scrum Guide 2020, cukup kecil sehingga kedua-dua akauntabiliti berada dalam satu pasukan dan bukannya dalam lapisan pengurusan di atasnya.
- Large-Scale Scrum (LeSS) mengekalkan tepat seorang Product Owner merentasi setiap pasukan yang membina satu produk, atas alasan bahawa membahagikan Backlog kepada beberapa Product Owner akan memecahkan keutamaan.
Dua akauntabiliti, bukan dua peranan
Kebanyakan perbandingan antara kedua-dua jawatan ini bermula di tempat yang salah: senarai simetri "Scrum Master melakukan X, Product Owner melakukan Y," seolah-olah kedua-duanya berada di landasan yang sama taraf dan selari. Hakikatnya tidak begitu, dan Scrum Guide 2020 sebenarnya mengubah perkataannya untuk menjelaskan perkara ini. Edisi terdahulu memanggil Product Owner, Scrum Master, dan Developer sebagai "peranan". Edisi semasa tidak menggunakan perkataan itu untuk mana-mana daripadanya. Ia menyatakan Scrum "mentakrifkan tiga akauntabiliti khusus dalam Pasukan Scrum," satu perubahan yang disengajakan dan masih tersalah ditulis oleh banyak penerangan pesaing yang kembali kepada "peranan" kerana kebiasaan.
Pilihan perkataan ini penting. "Peranan" membayangkan huraian tugas: sekumpulan tugasan yang diberikan kepada seseorang. "Akauntabiliti" membayangkan sesuatu yang lebih sempit dan lebih berat: seseorang bertanggungjawab ke atas sesuatu hasil, sama ada dia sendiri yang melakukan kerja di sebaliknya atau tidak. Jika dibaca begitu, perbezaan antara kedua-dua tugas ini bukan lagi senarai tugasan, tetapi soalan tentang apa yang menjadi tanggungan setiap orang apabila sesuatu berlaku salah.
Jika anda baru mengenali cara Scrum berfungsi sebagai rangka kerja, bacalah dahulu sebelum perbandingan ini, kerana semua yang berikut mengandaikan adanya Sprint, tiga artifak, dan Pasukan Scrum yang kecil dan mengurus diri sendiri yang ditakrifkannya. Kedua-dua akauntabiliti hanya wujud dalam struktur itu. Tanpa Scrum, kedua-dua jawatan ini tidak lagi bermakna apa-apa yang khusus.
Scrum Master vs Product Owner secara ringkas
| Scrum Master | Product Owner | |
|---|---|---|
| Bertanggungjawab ke atas | Keberkesanan Pasukan Scrum, cara pasukan bekerja | Memaksimumkan nilai produk, apa yang dibina dan dalam susunan apa |
| Artifak utama | Tidak memiliki mana-mana secara langsung; menyokong ketiga-tiganya (Product Backlog, Sprint Backlog, Increment) | Product Backlog |
| Siapa yang dilayan | Developer, Product Owner, dan organisasi yang lebih luas | Pihak berkepentingan, pelanggan, dan Developer yang membina apa yang disusunnya |
| Acara utama | Memudahkan setiap acara Scrum; tidak memiliki kandungannya | Menghadiri setiap acara; memacu kandungan Sprint Planning dan Sprint Review |
| Kejayaan diukur dengan | Kurang halangan, acara yang lebih sihat, pengurusan diri pasukan yang lebih baik | Nilai yang dihantar: kesihatan Backlog, kepercayaan pihak berkepentingan, hasil produk |
| Corak kegagalan lazim | Menjadi penjadual mesyuarat atau pelapor status tanpa kesan bimbingan | Menjadi proksi penulis tiket tanpa kuasa sebenar untuk menolak |
| Tempat akauntabiliti terletak | Dalam pasukan dan prosesnya | Dalam produk dan Backlog |
Apa yang sebenarnya menjadi akauntabiliti Product Owner
Menurut Guide, "Product Owner juga bertanggungjawab ke atas pengurusan Product Backlog yang berkesan," yang terbahagi kepada empat tugas khusus: membangunkan dan menyampaikan Matlamat Produk, mencipta dan menyampaikan item Backlog dengan jelas, menyusun Backlog, dan memastikannya telus serta difahami. Apabila diterjemahkan kepada seminggu sebenar, senarai itu kurang kelihatan seperti kerja pentadbiran dan lebih seperti rentetan keputusan yang memerlukan pertimbangan.
| Bahasa Scrum Guide | Rupanya dari minggu ke minggu |
|---|---|
| "Membangunkan dan menyampaikan Matlamat Produk secara eksplisit" | Menulis (dan menerangkan semula) satu perenggan yang menyatakan apa yang cuba dicapai produk ini seterusnya, supaya setiap perbualan penghalusan Backlog mempunyai penapis |
| "Mencipta dan menyampaikan item Product Backlog dengan jelas" | Menukar permintaan pihak berkepentingan kepada kisah pengguna yang terbentuk baik dengan hasil yang jelas, bukan sekadar nama ciri |
| "Menyusun item Product Backlog" | Berkata tidak, secara terbuka, kepada pihak berkepentingan yang paling lantang dalam bilik itu, kerana ada perkara lain yang lebih bernilai sekarang |
| "Memastikan Product Backlog telus, kelihatan dan difahami" | Memastikan Backlog cukup mudah dibaca supaya seorang Developer boleh mengambil item seterusnya tanpa mesyuarat untuk menyahkodnya |
Dua baris dalam Guide melakukan lebih banyak kerja daripada yang kelihatan pada mulanya. Yang pertama: "Product Owner boleh melakukan kerja di atas atau boleh mewakilkan tanggungjawab itu kepada orang lain. Walau bagaimanapun, Product Owner kekal bertanggungjawab." Product Owner boleh meminta orang lain menulis kisah pengguna sebenar atau menjalankan proses pengambilan permintaan. Dia tidak boleh menyerahkan akauntabiliti itu sendiri, bermakna tanggungjawab akhir tetap pada dirinya walaupun bukan dia yang memegang pena.
Yang kedua: "agar Product Owner berjaya, seluruh organisasi mesti menghormati keputusan mereka." Itu bukan sekadar adab; ia keperluan struktur. Product Owner yang susunan Backlog-nya dibatalkan oleh sesiapa sahaja yang mengadu kepada seorang VP sebenarnya tidak bertanggungjawab ke atas apa-apa, walau apa pun jawatannya. Jika itu berlaku dalam pasukan anda, jawatan itu hanyalah perhiasan.
Apa yang sebenarnya menjadi akauntabiliti Scrum Master
Akauntabiliti Scrum Master terbahagi kepada khidmat kepada tiga khalayak berbeza: Pasukan Scrum, Product Owner, dan organisasi. Pembahagian tiga hala ini mudah terlepas pandang jika anda hanya menganggap Scrum Master sebagai "orang yang mengendalikan stand-up."
| Melayani | Bahasa Scrum Guide | Dari hari ke hari |
|---|---|---|
| Pasukan Scrum | "Membimbing ahli pasukan dalam pengurusan diri dan kepelbagaian fungsi"; "menyebabkan penyingkiran halangan" | Duduk bersama Developer yang tersekat untuk menyelesaikan satu kebergantungan, bukan sekadar mencatat sekatan itu dalam laporan status |
| Pasukan Scrum | "Memastikan semua acara Scrum berlangsung dan bersifat positif, produktif, serta kekal dalam had masa" | Mengekalkan Daily Scrum pada 15 minit dan mengarahkannya kembali kepada perbualan perancangan, bukan bacaan status |
| Product Owner | "Membantu mencari teknik untuk pentakrifan Matlamat Produk dan pengurusan Product Backlog yang berkesan" | Mencadangkan format penghalusan yang lebih ringan apabila item mula bertimbun tanpa dihaluskan |
| Organisasi | "Memimpin, melatih, dan membimbing organisasi dalam penggunaan Scrum"; "menyingkirkan halangan antara pihak berkepentingan dan Pasukan Scrum" | Menolak balik apabila seorang eksekutif cuba memasukkan kerja baharu ke dalam sprint di tengah kitaran, supaya pasukan tidak perlu berdepan pertarungan itu seorang diri |
Perhatikan apa yang tiada dalam senarai itu: menulis laporan status kepada pengurusan, memiliki tarikh penghantaran, atau menentukan apa yang dibina pasukan. Tugas-tugas itu terus diserap ke dalam peranan ini dalam amalan, dan itulah cara Scrum Master bertukar menjadi penyelaras projek dengan jawatan yang berbeza. Menurut Guide, akauntabiliti itu ialah keberkesanan pasukan, itu sahaja, bukan fungsi pelaporan yang dilekatkan padanya.
Titik pertembungan dan cara pasukan yang sihat menyelesaikannya
Inilah bahagian yang kebanyakan perbandingan langkau, dan inilah yang sebenarnya penting dari hari ke hari. Kedua-dua akauntabiliti ini tidak direka untuk bermusuhan, tetapi ia menarik ke arah yang berbeza cukup kerap sehingga geseran itu normal, bukan tanda ada sesuatu yang rosak.
| Titik pertikaian | Naluri Product Owner | Naluri Scrum Master | Cara pasukan yang sihat menyelesaikannya |
|---|---|---|---|
| Pihak berkepentingan meminta kerja baharu disisipkan di tengah sprint | Mahu berkata ya dengan cepat untuk memelihara hubungan | Mahu melindungi Sprint Goal dan fokus pasukan | Pertukaran itu dibincangkan bersama seluruh pasukan, bukan diputuskan secara sepihak; skop baharu menunggu Sprint Planning seterusnya melainkan semua bersetuju menukar ganti sesuatu |
| Penghalusan Backlog terus berlarutan | Mahu menyelesaikan lebih banyak item supaya Backlog sentiasa mendahului pasukan | Mahu melindungi had masa dan tenaga pasukan | Scrum Master mencadangkan format yang lebih ringan (kelompok lebih kecil, bahan bacaan awal secara tak segerak) dan bukannya sekadar memendekkan mesyuarat lalu membiarkan Backlog nipis |
| Pihak berkepentingan cuba terus kepada Developer, memintas Backlog | Bimbang kehilangan kawalan atas keutamaan | Bimbang pasukan ditarik ke dua arah serentak | Scrum Master mengarahkan pihak berkepentingan itu kepada Product Owner, secara konsisten dan terbuka, sehingga ia berhenti berlaku |
| Sprint Review menunjukkan pasukan terlebih komited | Mahu menguruskan perbualan dengan pihak berkepentingan tentang apa yang tertangguh | Mahu retrospektif mendedahkan mengapa anggaran itu salah | Kedua-duanya separuh menyelesaikannya: Product Owner memiliki mesej kepada pihak berkepentingan, Scrum Master memiliki pembaikan proses, dan tiada seorang pun melangkau bahagiannya |
| Definition of Done dilonggarkan secara senyap untuk mengejar tarikh | Mahu menghantar kemajuan yang kelihatan sebelum tarikh akhir | Bertanggungjawab agar pasukan memenuhi Definition of Done-nya sendiri | Scrum Master mempunyai tuntutan yang lebih kukuh di sini. Standard kualiti yang dipersetujui seluruh pasukan bukan sasaran yang boleh digugurkan oleh Product Owner secara sepihak |
Corak di sebalik kelima-lima baris itu: tugas Product Owner ialah menyokong nilai dan bergerak pantas, manakala tugas Scrum Master ialah melindungi keupayaan pasukan untuk menghantar nilai itu secara mampan. Tiada satu pun naluri itu salah dengan sendirinya. Geseran itu ialah sistem yang berfungsi, bukan gagal, selagi seorang tidak sekadar mengatasi akauntabiliti yang lain demi menghilangkan ketegangan itu.
Acara Scrum satu demi satu: siapa buat apa
Kedua-dua akauntabiliti hadir dalam setiap acara, tetapi dengan kedudukan yang berbeza. Seorang membawa kandungan, seorang lagi melindungi bekas tempat ia berlaku.
| Acara | Product Owner | Scrum Master |
|---|---|---|
| Sprint Planning | Membawa bahagian atas Backlog yang tersusun dan cadangan Sprint Goal; menjawab soalan Developer tentang tujuan | Memudahkan had masa dan memastikan Sprint Goal benar-benar dipersetujui, bukan sekadar diandaikan |
| Daily Scrum | Kehadiran adalah pilihan menurut Guide; biasanya tidak hadir melainkan dijemput menjawab sesuatu yang khusus | Tidak diwajibkan hadir juga, tetapi membimbing Developer supaya ia kekal sebagai pertemuan perancangan dan bukan laporan status ke atas |
| Penghalusan Backlog | Mengetuai sesi: menyusun item, menjelaskan kriteria penerimaan, membuat hujah nilai untuk apa yang seterusnya | Memudahkan format dan had masa; masuk campur jika penghalusan berubah menjadi membahaskan semula keputusan yang telah selesai |
| Sprint Review | Membentangkan apa yang dihantar, mengumpul maklum balas pihak berkepentingan, mengemas kini Backlog berdasarkan apa yang dipelajari | Mengekalkan acara itu sebagai sesi kerja, bukan demo sehala atau penilaian prestasi pasukan |
| Sprint Retrospective | Hadir sebagai ahli pasukan; keputusannya sendiri boleh diberi maklum balas seperti keputusan orang lain | Memudahkan format dan tindakan susulan; bertanggungjawab agar pasukan benar-benar bertambah baik, bukan sekadar berbincang |
Bolehkah seorang melakukan kedua-duanya?
Kadangkala boleh, dan biasanya ia tidak bertahan lama. Kedua-dua akauntabiliti ini bertentangan dari segi struktur: tugas Product Owner memberi ganjaran kepada keputusan berkata ya kepada nilai dan bergerak pantas, manakala tugas Scrum Master memberi ganjaran kepada perlindungan kadar kerja pasukan dan menolak apabila kelajuan mengancam kualiti. Letakkan kedua-dua insentif dalam kepala satu orang, dan satu pihak hampir selalu menang secara lalai, biasanya pihak yang mempunyai tekanan lebih lantang dan lebih segera (tarikh akhir pihak berkepentingan lazimnya mengalahkan sesi bimbingan yang tidak glamor).
Klausa pewakilan dalam Guide menjadikan keadaan ini lebih buruk, bukan lebih baik, bagi peranan gabungan. Mewakilkan tugasan tidak mengurangkan jumlah akauntabiliti, ia hanya memusatkan dua jenis akauntabiliti berasingan ke dalam satu kalendar. Gabungan Product Owner dan Scrum Master bukan melakukan separuh daripada dua tugas; dia bertanggungjawab sepenuhnya ke atas kedua-duanya, dengan jam kerja seorang sahaja.
Perkara ini wajar dibezakan daripada satu lagi bentuk pemampatan peranan. Large-Scale Scrum (LeSS) sengaja mengekalkan seorang Product Owner merentasi banyak pasukan yang membina satu produk, tetapi atas sebab yang bertentangan: untuk menghalang keutamaan berpecah merentasi Backlog yang bersaing, bukan untuk menjimatkan kos kakitangan. Itu satu Product Owner meliputi lebih banyak pasukan, bukan seorang meliputi dua akauntabiliti berbeza. Jika organisasi anda berkembang melangkaui satu pasukan, LeSS dan pendekatan penskalaan serupa wajar dibaca sebelum sesiapa mengada-adakan peranan gabungan kerana terdesak.
| Tempat penggabungan dicuba | Mengapa ia menarik | Mengapa ia biasanya gagal |
|---|---|---|
| Syarikat pemula yang sangat kecil, satu pasukan, satu produk | Bajet hanya cukup untuk satu gaji, bukan dua | Orang itu akhirnya kurang melayan pihak berkepentingan atau kurang membimbing pasukan, kerana kedua-dua tugas bersaing untuk jam yang sama |
| Pasukan alat dalaman dengan sedikit pihak berkepentingan luar | Tekanan luar yang rendah ke atas bahagian Product Owner menjadikan bahagian Scrum Master mendominasi secara lalai | Disiplin Backlog merosot, kerana "tiada pihak berkepentingan yang mendesak" diam-diam menjadi "tiada disiplin Backlog" |
| Pasukan yang baru mengenali Scrum | Kedua-dua akauntabiliti belum terasa diisi sepenuhnya, jadi menggabungkannya nampak cekap di atas kertas | Pasukan tidak pernah melihat apa yang sebenarnya dilakukan oleh Scrum Master yang difasilitasi dengan betul, kerana orang gabungan itu lalai kepada kerja Backlog di bawah tekanan tarikh akhir |
| Seorang developer memegang kedua-duanya di samping kerja pengekodannya | Kecekapan kakitangan maksimum | Penyingkiran halangan dan pengurusan pihak berkepentingan kedua-duanya tewas kepada penghantaran kod, kerana tiada satu pun identiti utama orang itu |
Tempat ia bertahan: pasukan yang sangat kecil dan berkonflik rendah, dianggap secara eksplisit sebagai susunan sementara, disemak semula sebaik sahaja pasukan atau senarai pihak berkepentingan membesar. Kegagalannya bukan kerana mencubanya. Ia kerana tidak pernah merancang untuk memisahkannya semula.
Scrum Master dan Product Owner vs Project Manager dan Product Manager
Scrum Master mahupun Product Owner bukanlah project manager dengan nama lain, walaupun kedua-duanya diam-diam menyerap beberapa bahagian tugas itu dalam amalan. Dan Product Owner sudah mempunyai perbandingan penuh dengan Product Manager di tempat lain: baca Product Owner vs Product Manager untuk asimetri akauntabiliti lawan jawatan yang mencetuskan kebanyakan kekeliruan itu (versi ringkas: Product Owner ditakrifkan oleh satu dokumen, Product Manager tidak ditakrifkan oleh mana-mana).
Perbandingan Scrum Master dengan project manager ialah pembahagian yang lebih bersih, kerana kedua-dua tugas itu hampir tidak bertindih dalam apa yang dimiliki.
| Scrum Master | Project Manager | |
|---|---|---|
| Ditakrifkan oleh | Scrum Guide, satu piawaian luaran | Tiada satu piawaian pemilik; PMBOK PMI ialah rujukan paling hampir, tetapi jawatan itu wujud dengan atau tanpanya |
| Memiliki jadual? | Tidak. Pasukan mengurus kerjanya sendiri dalam Sprint | Selalunya ya, terutamanya dalam persekitaran peringkat program atau berhampiran waterfall |
| Kuasa ke atas skop | Tiada. Skop milik Product Owner | Kerap, bersama bajet dan garis masa |
| Melapor status ke atas? | Bukan tugasnya. Sprint Review dan artifak melakukannya secara telus tanpa laporan berasingan | Kerap, melalui laporan status dan jawatankuasa pemandu |
| Wujud di luar Scrum? | Tidak | Ya, merentasi hampir setiap metodologi penghantaran |
Untuk gambaran lebih lengkap tentang tempat pengurusan projek dan program menyimpang daripada kedua-dua akauntabiliti Scrum, lihat perbandingan pengurusan program vs projek kami.
Mana yang patut diambil dahulu, atau mana yang patut anda jadi
| Situasi anda | Apa yang perlu diutamakan |
|---|---|
| Backlog mempunyai hala tuju yang jelas, tetapi sprint terus gagal mencapai matlamat, acara berlarutan, dan halangan bertimbun tanpa ditangani | Scrum Master. Pasukan sudah ada hala tuju; prosesnya yang perlu dibetulkan |
| Rentak sprint berjalan lancar, tetapi tiada siapa boleh menerangkan mengapa pasukan membina apa yang dibinanya | Product Owner. Proses berfungsi; "mengapa" yang hilang |
| Anda sedang menubuhkan Pasukan Scrum pertama anda dari kosong | Product Owner dahulu, walaupun secara tidak rasmi, supaya ada sesuatu yang berbaloi untuk di-sprint. Scrum Master tanpa Backlog untuk dilindungi belum mempunyai apa-apa untuk difasilitasi |
| Anda seorang developer yang lebih tertarik kepada bimbingan, fasilitasi, dan geseran organisasi daripada strategi Backlog | Condong kepada Scrum Master sebagai laluan kerjaya |
| Anda seorang developer yang lebih tertarik kepada perbualan dengan pelanggan, tukar ganti keutamaan, dan memiliki hasil daripada proses | Condong kepada Product Owner sebagai laluan kerjaya |
| Anda memilih antara kedua-duanya dengan mata tertumpu pada hala tuju kerjaya jangka panjang | Product Owner cenderung lebih hampir dengan kerja strategi produk kemudian, walaupun ramai Scrum Master berpindah ke bimbingan agile atau kepimpinan penghantaran |
Corak lawan lazim
| Corak lawan | Rupanya | Pembetulan |
|---|---|---|
| Scrum Master sebagai setiausaha | Menghantar jemputan kalendar, mencatat nota, melapor status ke atas, tidak pernah membimbing atau menyingkirkan halangan | Arahkan ke arah fasilitasi dan penyingkiran halangan; pelaporan status langsung tiada dalam akauntabiliti Guide |
| Scrum Master sebagai penulis laporan | Menghabiskan sebahagian besar minggu membina carta Velocity dan laporan Burndown untuk pengurusan, bukannya bekerja dengan pasukan | Serahkan pelaporan kepada dashboard layan diri daripada papan; masa Scrum Master adalah milik pasukan |
| Product Owner sebagai proksi penulis tiket | Menyampaikan keputusan seorang pengurus atau jawatankuasa menjadi item Backlog tanpa suara sebenar dalam apa yang diutamakan | Desak organisasi memberi Product Owner kuasa sebenar; Product Owner yang tidak boleh menolak tidak bertanggungjawab ke atas apa-apa |
| Product Owner yang tidak pernah ada | Backlog menjadi basi kerana penghalusan dan soalan penjelasan tidak berjawab selama berhari-hari | Tetapkan waktu pejabat yang eksplisit atau slot penghalusan tetap yang dilindungi Product Owner seperti upacara lain |
| Scrum Master yang diam-diam memiliki Backlog | Masuk campur untuk menyusun semula atau menulis item Backlog kerana Product Owner lambat, mengaburkan kedua-dua akauntabiliti sekali gus | Bimbing Product Owner dan bukannya melakukan tugasnya; jika jurang itu bersifat struktur, naikkan isu itu, jangan menyerapnya |
| Product Owner yang mengendalikan Daily Scrum | Menukar acara pengurusan diri pasukan menjadi mesyuarat status yang melapor kepada Product Owner | Kehadiran Product Owner adalah pilihan menurut Guide; jika dia hadir, dia mendengar, dia tidak mengendalikannya |
Tiada satu pun daripada ini menjadi keputusan carta organisasi kekal yang dibuat sekali dan dilupakan. Saiz pasukan berubah, peringkat produk berubah, dan titik geseran dalam jadual pertembungan di atas muncul semula setiap kali sesuatu beralih, sama ada pihak berkepentingan baharu, Backlog yang membesar, atau pasukan yang sudah melampaui peranan gabungan yang dimulakan kerana terdesak. Jalan paling pantas kembali kepada kejelasan apabila itu berlaku bukanlah perdebatan baharu tentang jawatan. Ia kembali kepada satu ayat yang menjadi asas setiap akauntabiliti: siapa yang bertanggungjawab ke atas nilai produk, dan siapa yang bertanggungjawab ke atas keupayaan pasukan menghantarnya.
Soalan Lazim tentang Scrum Master vs Product Owner
Adakah Scrum Master sama dengan Product Owner?
Tidak. Scrum Guide 2020 mentakrifkan kedua-duanya sebagai dua akauntabiliti berasingan dalam Pasukan Scrum yang sama. Product Owner bertanggungjawab memaksimumkan nilai produk dan mengurus Backlog. Scrum Master bertanggungjawab ke atas keberkesanan Pasukan Scrum dan cara pasukan bekerja. Mereka setara dalam pasukan, bukan hierarki, dan tiada seorang pun menguruskan yang lain.
Bolehkah Scrum Master menjadi Product Owner, atau sebaliknya?
Boleh, dan kedua-dua peralihan berlaku secara kerap. Scrum Master yang mahu memiliki hasil produk dan bukannya memudahkan proses pasukan sering beralih ke peranan Product Owner setelah membina pengetahuan domain dan pelanggan yang mencukupi. Product Owner yang mahu menjauhi tekanan pihak berkepentingan dan lebih hampir dengan bimbingan pasukan kadangkala beralih ke arah sebaliknya, secara sengaja.
Siapa yang mempunyai lebih kuasa, Scrum Master atau Product Owner?
Mereka mempunyai kuasa ke atas perkara yang berbeza, bukan lebih atau kurang ke atas perkara yang sama. Product Owner mempunyai kuasa tunggal ke atas kandungan dan susunan Backlog, menurut Scrum Guide. Scrum Master tidak mempunyai kuasa ke atas apa yang dibina pasukan, tetapi bertanggungjawab ke atas cara pasukan bekerja dan boleh menolak balik berkenaan proses, had masa, dan halangan. Tiada seorang pun mengatasi yang lain.
Adakah pasukan kecil benar-benar memerlukan kedua-duanya secara berasingan?
Tidak semestinya, sekurang-kurangnya bukan sebagai dua orang berasingan. Pasukan yang sangat kecil kadangkala menggabungkan akauntabiliti itu dalam satu orang, dan ia boleh berfungsi seketika. Namun kedua-dua tugas itu menarik ke arah berbeza (menyokong nilai berbanding melindungi kapasiti pasukan), jadi susunan itu cenderung tertekan apabila pasukan, Backlog, atau senarai pihak berkepentingan membesar.
Apakah perbezaan sebenar antara Scrum Master dan project manager?
Scrum Master tidak mempunyai kuasa ke atas skop, bajet, atau jadual; Pasukan Scrum mengurus kerjanya sendiri dalam setiap Sprint. Project manager lazimnya memiliki jadual, skop, dan pelaporan status, dan jawatan itu wujud merentasi hampir setiap pendekatan penghantaran, bukan hanya Scrum. Peranan Scrum Master hanya wujud dalam Pasukan Scrum.
Adakah peranan ini wujud di luar Scrum, dalam Kanban atau rangka kerja lain?
Jawatan "Scrum Master" dan "Product Owner" khusus kepada Scrum dan tidak wujud secara rasmi di luarnya. Pasukan yang menjalankan Kanban atau rangka kerja lain masih memerlukan seseorang yang bertanggungjawab ke atas keutamaan dan seseorang yang memerhatikan aliran dan proses pasukan, cuma mereka tidak menyandang jawatan yang sama atau akauntabiliti tepat yang ditetapkan Scrum Guide kepada mereka.
Walau di pihak mana pun anda sedang menyelesaikan perkara ini, sama ada mengambil pekerja, merungkai pasukan yang kabur, atau memilih laluan kerjaya, ayat yang patut anda kembali kepadanya ialah apa yang sebenarnya ditulis oleh Guide: seorang bertanggungjawab ke atas nilai produk, seorang lagi ke atas keberkesanan pasukan. Selebihnya hanyalah butiran.
On this page
- Dua akauntabiliti, bukan dua peranan
- Scrum Master vs Product Owner secara ringkas
- Apa yang sebenarnya menjadi akauntabiliti Product Owner
- Apa yang sebenarnya menjadi akauntabiliti Scrum Master
- Titik pertembungan dan cara pasukan yang sihat menyelesaikannya
- Acara Scrum satu demi satu: siapa buat apa
- Bolehkah seorang melakukan kedua-duanya?
- Scrum Master dan Product Owner vs Project Manager dan Product Manager
- Mana yang patut diambil dahulu, atau mana yang patut anda jadi
- Corak lawan lazim