Apakah Scrum mengubah pengembang aktif menjadi pengembang pasif?


103

Saya seorang pengembang web yang bekerja di tim yang terdiri dari tiga pengembang dan satu desainer. Sekarang sudah sekitar lima bulan kami menerapkan metodologi pengembangan perangkat lunak scile tangkas. Tapi saya punya perasaan aneh yang ingin saya bagikan di situs ini.

Salah satu faktor penting dalam kehidupan manusia adalah proses pengambilan keputusan. Namun, ada perbedaan besar dalam keputusan yang Anda buat. Beberapa keputusan hanyalah hasil dari kekuatan internal atau eksternal, sementara keputusan lain sepenuhnya didasarkan pada kehendak bebas Anda, dan beberapa keputusan hanyalah sesuatu di antaranya. Semakin banyak kebebasan yang Anda miliki dalam membuat keputusan, pekerjaan Anda akan semakin mandiri. Ini sepertinya aturan. Karena kita cenderung membentuk hidup kita sendiri.

Ada perbedaan besar antara Anda memutuskan apa yang harus dilakukan , atau diberi tahu apa yang harus dilakukan .

Sebelum scrum, saya merasa memiliki lebih banyak kebebasan dalam membuat keputusan yang terkait dengan pengembangan, analisis, memprioritaskan implementasi, dll. Saya lebih merasa seperti saya memutuskan apa yang saya lakukan .

Namun, karena metodologi scrum, sekarang banyak keputusan hanya datang dari pemilik produk. Dia memprioritaskan PBI , dia menganalisis bagaimana perangkat lunak harus bekerja, bahkan kadang-kadang bagaimana UI dan fungsionalitas harus diimplementasikan. Saya tahu bahwa ini adalah bagian dari metodologi scrum, dan saya juga tahu bahwa ini dapat menghasilkan penjualan produk yang lebih baik di masa depan. Namun, saya sekarang merasa seperti saya selalu disuruh melakukan sesuatu, daripada memutuskan untuk melakukan sesuatu . Sindrom ini sekarang telah membuat saya lebih pasif terhadap pekerjaan.

  1. Saya cenderung mencari lebih sedikit untuk menemukan solusi, pendekatan, atau teknik yang lebih baik
  2. Saya tidak bangun di pagi hari berharap untuk mendapatkan pekerjaan yang menyenangkan. Sebaliknya, saya merasa seperti dipaksa untuk bekerja agar bisa hidup
  3. Saya memiliki lebih banyak kelaparan untuk mengerjakan proyek hobi saya sendiri setelah bekerja
  4. Saya tidak akan mendorong tim lagi untuk mencapai tingkat teknologi yang lebih tinggi
  5. Saya menghabiskan lebih banyak waktu sekarang untuk makan malam, atau minum teh dan kurang antusias untuk kembali bekerja
  6. Saya sekarang lebih bersedia untuk menyelesaikan pekerjaan lebih cepat, sehingga saya bisa pulang

Masalah besar adalah, saya melihat dan mendiagnosis perilaku ini pada rekan-rekan saya juga. Apakah ini hasil scrum? Apakah scrum benar-benar membuat tim pengembangan merasa seperti mereka tidak memiliki bagian dalam membentuk perangkat lunak secara keseluruhan, sehingga membuat pasif terhadap proyek? Bagaimana saya bisa mengatasi perasaan ini?


4
Apakah Anda yakin tidak hanya melakukan diri Anda secara disfungsi jauh sebelumnya?
Donal Fellows

27
Posting blog yang bagus.
Robert S.

20
apa yang Anda gambarkan bukan SCRUM

4
@Chad. Apa yang saya diskusikan di sini bukanlah keluhan tentang situasi pekerjaan saya. Saya hanya ingin tahu apakah suasana hati ini adalah hasil dari scrum? Dan apakah pengembang lain juga mengalami hal yang sama atau tidak?
Saeed Neamati

5
@Saeed - Maaf untuk menjadi tumpul tetapi suasana hati Anda adalah hasil dari keputusan Anda tentang cara menangani lingkungan kerja Anda. Ini mungkin dipengaruhi oleh pendapat dan sikap orang lain, tetapi Anda juga bisa memilih untuk menggunakan metode ini. Ini membebaskan Anda dari kebutuhan untuk bertanggung jawab atas keputusan desain dan memungkinkan Anda hanya bekerja untuk memecahkan masalah tertentu. Itu tidak menguras semua energi Anda dan memungkinkan Anda untuk mengerjakan lebih banyak proyek rumah Anda. Anda memiliki lebih banyak waktu untuk mengembangkan Anda. Ini bukan hal-hal buruk. Bukan pekerjaan atasan Anda untuk membuat Anda bahagia. Anda dapat menemukan pekerjaan lain atau Anda dapat menerima ini.
SoylentGray

Jawaban:


51

Namun, saya sekarang merasa seperti saya selalu disuruh melakukan sesuatu, daripada memutuskan untuk melakukan sesuatu.

Ini adalah indikator serius bahwa ada sesuatu yang hilang. Proyek lincah seharusnya tidak terasa seperti ini. Retorika "orang yang melebihi proses" harus memasukkan "kita tidak memaksa orang untuk melakukan hal-hal yang payah." Berikut ini beberapa ide:

Apakah Anda melakukan "scrum but"? Yaitu, sebagian scrum, sebagian lagi. (yaitu: "Kami melakukan scrum, tetapi semua cerita kami harus berasal dari PMO kami, bukan pemilik produk.") Banyak omong kosong gila yang disebut Scrum hari ini.

Apakah Anda, secara pribadi, tidak terlibat dalam proses di mana Anda seharusnya berada? Saya kenal sejumlah orang yang kecewa dengan isi cerita, dan ternyata mereka hanya terlibat begitu cerita ada di sprint backlog. Bicaralah dengan pemilik produk sejak awal dalam pengembangan cerita, dan dapatkan umpan balik Anda. (Sebagai PO, mereka memiliki pendapat akhir, tetapi itu tidak berarti mereka harus melakukannya sendiri.)

Di Scrum, tim seharusnya memiliki proses, dan diharapkan proses akan berubah seiring waktu sesuai dengan kebutuhan tim. Sampaikan kekhawatiran Anda di retrospektif. Jika Anda dapat membuat proses tweak untuk menyarankan, itu cenderung membuatnya lebih mudah untuk dijual untuk beberapa tim.


10
Scrum +1 (karena semua metodologi Agile) lebih berat dalam percakapan daripada arahan. PO harus menggambarkan apa yang harus dicapai hasil akhir, kemudian melibatkan para desainer dan pengembang tentang cara untuk sampai ke sana.
StevenV

5
"people over process": Lucu, lalu mengapa memaksakan proses SCRUM alih-alih membiarkan orang menggunakan milik mereka sendiri? Dan mengapa semua tindakan itu (pemrograman berpasangan, tinjauan kemajuan yang sering) yang, atas nama transparansi, memungkinkan untuk memantau pekerjaan pengembang lebih dekat?
Giorgio

3
@Giorgio: Karena pengembangan yang terstruktur memungkinkan tim untuk bekerja bersama tanpa menginjak kaki satu sama lain setiap saat. Kami belum menemukan cara melakukannya dengan sempurna.
Phoshi

2
@ Giogio, ini masalah dengan lincah secara umum. Meskipun tujuannya adalah untuk membuat orang lebih dari proses, pada kenyataannya Agile menjadi diikuti secara religius - yang lagi-lagi menempatkan proses atas orang. Secara pribadi saya pikir lean melakukan pekerjaan yang lebih baik daripada gesit, meskipun tidak berusaha untuk menegakkan struktur tim yang benar-benar horizontal - itu memungkinkan pengembang untuk memilih tugas dengan lebih baik. Dengan asumsi tim Anda tidak akan berubah, papan kanban selain apa yang Anda lakukan sekarang dapat membuat manajemen bahagia dan Anda juga senang, memberi Anda kebebasan untuk memilih cerita / tugas Anda.
jQwierdy

62

Masalah Anda bukanlah Scrum (dan seperti yang dikatakan Jarrod Roberson dalam komentar, itu bukan Scrum yang Anda uraikan) - melainkan manajemen mikro Pemilik Produk dan kurangnya ketegasan Anda (dan Tim) .

"Namun, karena metodologi scrum, sekarang banyak keputusan hanya berasal dari pemilik produk. Dia memprioritaskan PBI, ia menganalisis bagaimana perangkat lunak harus bekerja, bahkan kadang-kadang bagaimana UI dan fungsionalitas harus dilaksanakan. Saya tahu bahwa ini adalah bagian dari metodologi scrum."

Anda salah. Hanya dari melihat sekilas halaman wikipedia untuk Scrum, Anda dapat melihat bahwa: "Tim, grup lintas fungsi yang melakukan analisis, desain, implementasi, pengujian, dll." Lihat? Pemilik Produk memberi tahu Anda apa yang harus dilakukan, tetapi tergantung pada Tim untuk memutuskan bagaimana melakukannya.

Anda adalah orang yang bertanggung jawab untuk implementasi, jadi Anda harus memutuskan bagaimana aplikasi akan diimplementasikan. Dengarkan pendapat Pemilik Produk, tetapi keputusan akhir terserah Anda (atau Tim).

Pengelolaan mikro BTW memang mengubah pengembang aktif menjadi pengembang pasif.


38
Amin ke baris terakhir
Wivani

6
"Pemilik Produk memberi tahu Anda apa yang harus dilakukan, tetapi tergantung pada Tim untuk memutuskan bagaimana melakukannya." Itulah yang sebenarnya bisa menjadi masalah bagi motivasi para pengembang: kurangnya inovasi. Sebagian besar pelanggan akan menginginkan kuda yang lebih cepat, bukan mobil. Tapi saya sangat setuju dengan manajemen mikro.
MaR

1
+1 @Lukas, karena perbedaan antara apa dan bagaimana . Terimakasih kawan.
Saeed Neamati

5
"Pemilik Produk memberi tahu Anda apa yang harus dilakukan" - Saya tidak setuju dengan itu. Mereka harus memberi tahu Anda apa yang mereka butuhkan . Perbedaan kecil tapi penting. Dengan kata lain: mereka menggambarkan masalah / masalah, Anda memberikan solusinya.
DanMan

2
@ MAr Itu sebabnya para devs tidak berbicara dengan pelanggan. Pelanggan berbicara dengan Pemilik Produk dan meminta kuda yang lebih cepat, PO adalah orang yang melihat semua masalah klien, menggabungkan dan memprioritaskannya, dan dalam prosesnya diketahui bahwa mobil lebih baik daripada kuda yang lebih cepat
Izkata

29

Apa yang Anda uraikan BUKAN SCRUM

Pemilik produk Anda sudah melampaui batas jika ia memberi tahu Anda bagaimana melakukan pekerjaan Anda secara teknis, itu sama sekali bukan tentang SCRUM.

SCRUM adalah tentang membebaskan para pengembang untuk berkonsentrasi pada masalah-masalah pembangunan dan memberdayakan mereka untuk menentukan berapa lama hal itu dilakukan dan bagaimana melakukannya.

SCRUM adalah tentang kolaborasi, itulah tujuan dari pertemuan perencanaan Sprint, untuk mempromosikan kolaborasi antara semua pemegang saham; pemilik produk, pengembang, dan pengujian.

Ya pemilik produk harus memprioritaskan fitur, apa yang perlu disampaikan terlebih dahulu sesuai dengan kebutuhan pelanggan, tetapi pengembang harus melakukan rekayasa dan desain, bukan pemilik produk.

Saya tidak setuju bahwa pengembang harus merancang GUI dan alur kerja kecuali mereka secara khusus ditugaskan dan dilatih untuk bekerja dengan pelanggan dan hash fungsionalitas dengan pelanggan secara langsung. Programmer membangun GUI yang dilakukan dalam ruang hampa jarang memenuhi kebutuhan pelanggan.

SCRUM adalah tentang menempatkan proses yang ringan yang dapat diprediksi dan diulang melalui manifesto tangkas.

Membuatku sedih mendengar cerita bahwa hal-hal yang sangat baik sedang diselewengkan seperti ini.


3
Sifat manusia akan selalu menemukan cara untuk merebut kekalahan dari rahang kemenangan.
Warren P

2
Ada yang seharusnya menjadi SCRUM , dan akhirnya ada , setidaknya di sebagian besar perusahaan. SCRUM bukanlah kejahatan dalam dirinya sendiri, tetapi merupakan alat yang sangat mudah digunakan untuk kejahatan oleh manajemen.
AresAvatar

11

Saya menduga sebelum Scrum, semua orang hanya melakukan apa yang diinginkan: yippee ki-yay mf'er . Pengguna Anda adalah dermawan Anda dan mereka yang mendorong cerita dan membayar tagihan. Pemilik produk memastikan cerita tersebut selesai. Entah bagaimana, grup Anda sampai pada kesimpulan bahwa Pemilik Produk harus memberi tahu Anda cara memprogram.

Anda ingin menulis kode atau membuat aplikasi kecil yang menurut Anda keren? "Aku ingin melakukan fitur A pertama dan bukan B, jadi aku bisa mempertahankan kebebasan memilih." Temukan dermawan yang berbeda dan bukan metodologi pengembangan baru.

Anda terjebak dalam judul Pemilik Proyek atau sesuatu. Jika Anda memiliki alasan yang sah untuk tidak setuju dengan cerita tersebut, katakan sesuatu, berargumentasi. Anda mungkin tidak selalu menang. Adalah tugas mereka untuk kembali ke pengguna dan memberi tahu mereka ada masalah yang valid dengan permintaan mereka. Mari kita hadapi itu, jika cerita meminta Anda untuk menjatuhkan database secara acak sepanjang hari, tanpa cadangan, tanpa kehilangan data atau down time, Anda memiliki masalah dan tugas untuk meluruskan cerita.


10

Sepertinya petualanganmu ke Agile telah dirusak oleh Scrum. Saya menemukan bahwa, dari semua metodologi tangkas, Scrum adalah yang paling tangkas. Ini lebih seperti air terjun mini dan manajemen proyek tambahan. Ini, tentu saja, menjadikannya yang paling disukai oleh manajemen yang merasa mereka mengambil kendali kembali dari para pengembang sial itu, tetapi tentu saja Anda melihat kenyataan situasi.

Agile bukan tentang mengikuti jalan yang ditentukan, ia dirancang untuk membuat Anda lebih produktif dan termotivasi. Orang yang tidak memproses mengatakan manifesto (diparafrasakan), dan itu hilang dalam sistem yang Anda gunakan.

Jadi ubahlah. Bawa itu ke manajemen dan katakan itu adalah langkah mundur, bahwa produktivitas Anda lebih rendah dari dulu dan Anda semua tidak senang dengan cara kerjanya. Tunjukkan Agile Manifesto (dan kembarannya yang jahat ) dan tunjukkan bahwa Anda tidak hanya belajar dari percobaan ini, tetapi juga ingin mengubah bagian-bagian yang baik dari itu menjadi sistem yang lebih baik (yang dulu Anda miliki, yang tampaknya berfungsi dengan baik untukmu).


6
saya? ya - kami dulu bekerja dengan baik, maka manajemen memutuskan bahwa Agile adalah masa depan, dan memberlakukan scrum, yang sangat membatasi kami. Apa yang kami lakukan dengan mudah menjadi macet dalam proses dan birokrasi. Saya pernah mengambil 3 kartu dari papan scrum !! Lampu menyala dan sirene meraung-raungkan karena melanggar 'jalan scrum', dan aku pernah mengambil kartu itu kembali ke mejaku . Polisi manajemen proyek datang untuk saya. Dan saya biasa duduk dalam scrum harian, itu juga tidak turun. Semua hal sepele IMHO, tetapi dibuat menjadi gunung.
gbjbaanb

2
Tidakkah menurut Anda dalam kasus Anda itu adalah implementasi Scrum yang buruk dan top-down yang menyebabkan hilangnya produktivitas? Anda mengatakan Anda "macet dalam proses dan birokrasi" yang aneh karena Scrum adalah metodologi birokrasi paling sederhana di dunia ... Sebenarnya seluruh kerangka Scrum cocok dalam satu lembar atau 2. Btw apa yang Anda sebut "papan scrum" bukan bagian dari kerangka kerja. Namun dalam kasus Saeed saya percaya masalahnya adalah kesenjangan antara jenis organisasi tempat dia bekerja (dengan kebebasan dan kekuatan keputusan yang besar untuk para pengembang) dan jenis organisasi yang diterapkan Scrum.
guillaume31

3
@ ian31: ya, proyek itu sangat buruk, tetapi Scrum menarik dirinya untuk para manajer semacam itu. Anda tidak pernah melihat mereka memilih Kanban atau Crystal. Scrum terlalu mudah berubah menjadi "scrum tapi" ketika orang-orang ini mendapatkannya. kasihan.
gbjbaanb

1
Saya pikir itu lucu bahwa perusahaan mana pun akan mengubah Scrum menjadi upacara keagamaan. Hei! Berdiri selama upacara ini di mana kita berpura-pura lincah! Hei! Tersenyumlah saat kami berpura-pura mendengarkan Anda, dan kemudian melanjutkan melakukan apa yang ingin kami lakukan!
Warren P

2
Saya sama sekali tidak setuju dengan dorongan jawaban ini. Saya pikir semacam "air terjun mini" bisa sangat bermanfaat, terutama bagi pengembang yang tidak berpengalaman tetapi pintar, yang bertanggung jawab untuk melakukan 5 hal berbeda sekaligus dan tidak menyelesaikannya. Sebenarnya orang yang melatih saya di Scrum mengatakan bahwa Anda masih bisa melakukan "air terjun mini" di Scrum jika Anda mau, tetapi idealnya, mereka harus dalam jangka waktu berhari-hari atau bahkan berjam - jam . Saya pikir, jam terlalu pendek. Anda tidak bisa selalu merancang-> mengimplementasikan-> menguji sebuah cerita dalam beberapa jam. Dan membelah cerita agar Anda tidak selalu optimal juga.
Robin Green

8

Saya pikir, bahwa hanya kalian yang terbiasa memiliki lebih banyak kepemilikan - dan semua orang yang saya pikir lebih suka itu, sifat manusiawi.

Sayangnya saya pikir banyak perangkat lunak kurang dari yang seharusnya, karena sering kali bagian ditulis untuk dev dan bukan klien. Pendekatan baru Anda harus mengurangi itu, tetapi dengan mengorbankan perasaan kepemilikan Anda.

Saya tidak tahu bagaimana menyarankan Anda untuk membuat hal-hal lebih baik atau lebih menyenangkan tetapi itu adalah pertanyaan yang bagus dan wawasan yang sangat bagus.


100% setuju. Anda sekarang lebih selaras dengan pemilik produk tetapi dalam istilah itu berarti Anda memiliki lebih sedikit kebebasan untuk melakukan apa yang Anda anggap benar. Saya juga pernah mengalami ini dan itu mengisap dan membuat pekerjaan saya jauh lebih tidak menyenangkan. Tetapi itu berarti bahwa saya jauh lebih selaras dengan tujuan bisnis dan manajer produk. Bisnis membayar tagihan - termasuk gaji saya - jadi ya, mereka bisa mengatakan apa yang mereka inginkan pada tingkat detail. Saya tidak berpikir mereka benar-benar memberitahu Anda cara membuat kode. Jika mereka tahu bagaimana mereka bisa melakukannya sendiri.
Michael Durrant

Bisnis tidak membayar pengembang untuk melakukan apa yang mereka inginkan. Mereka membayar pengembang untuk peningkatan produktivitas yang disediakan oleh lingkungan perangkat lunak yang baik. Jika Anda membiarkan bisnis memberi tahu Anda apa yang harus dilakukan "pada level detail", apakah Anda benar-benar berpikir mereka akan mendapatkan lingkungan perangkat lunak yang baik yang mereka cari?
Andomar

@Andomar - Ini keseimbangan. Masing-masing pihak memiliki cita-cita, asumsi, dan kesalahan. Mengabaikan salah satu dari ini mengarah pada bahaya.
Jonno

5

Apakah Anda mendapatkan cerita pengguna dalam bentuk "Sebagai --role -, saya ingin --go / desire - agar --benar -"? Sepertinya Pemilik Produk Anda ingin melakukan pekerjaan desain, dan dia mungkin bukan orang terbaik untuk melakukan itu. Menggunakan pola cerita pengguna dapat membantu memastikan bahwa Pemilik Produk berpegang teguh pada kepentingan bisnis, dan pengembangan perangkat lunak dilakukan oleh pengembang perangkat lunak.


4
Sebagai seorang pengembang, saya ingin tidak pernah melihat kisah pengguna seperti ini lagi, sehingga saya mungkin tidak perlu mengeluh dalam hati pada ketidakmampuannya.
Warren P

@ WarrenP Ya, boilerplate bisa menjadi masalah, apakah itu berupa kode boilerplate atau persyaratan boilerplate. Saya pikir poin kuncinya adalah bahwa ketiga elemen tersebut harus dinyatakan atau dipahami, tetapi yang lebih penting, harus jelas bagi semua orang apa yang benar-benar diinginkan, dan persyaratan templated boilerplate sebenarnya dapat menghambat itu. Terutama jika pengembang mulai berpikir bahwa mengisi beberapa kata pendek ke dalam template itu selalu cukup.
Robin Green

4

Di Scrum ada banyak ruang bagi pengembang untuk berkontribusi dan memberikan saran mereka tentang fitur baru, UI, kegunaan ... Kolaborasi dan percakapan antara pelaku bisnis dan pengembang diperlukan di Scrum dan memungkinkan. Namun pada akhirnya pemilik produk akan selalu memiliki keputusan akhir karena dialah yang bertanggung jawab untuk memaksimalkan nilai bisnis dari peningkatan perangkat lunak yang dihasilkan sprint setelah sprint (dengan kata lain, ROI).

Dari Agile Manifesto:

Prioritas tertinggi kami adalah untuk memuaskan pelanggan melalui pengiriman awal dan terus menerus perangkat lunak berharga.

Pemilik produk yang memberi tahu Anda bagaimana UI dan fungsionalitas harus diimplementasikan tidak dapat diterima. Dalam hal ini Anda harus memiliki keputusan akhir karena Anda bertanggung jawab atas kualitas internal perangkat lunak yang Anda hasilkan.

Mungkin Anda bekerja di perusahaan yang dibuat oleh pengembang tempat programmer memiliki kebebasan untuk mengimplementasikan fitur apa pun yang mereka inginkan. Namun, sebagian besar metodologi Agile membuat pemisahan yang jelas antara orang-orang domain bisnis dan tim yang bertanggung jawab untuk memproduksi perangkat lunak (pengembang, penguji ...) yang merupakan divisi kerja paling umum di sebagian besar tempat. Jika asumsi saya benar, saya dapat memahami perasaan yang Anda miliki bahwa Anda tidak dapat "memiliki pengaruh pada gambaran besar" lagi tetapi dengan pertumbuhan perusahaan saya kira itu akan menjadi masalah, Scrum atau tidak.

Mengenai analisis, desain, dan aktivitas pengembangan meta lainnya yang Anda sebutkan (yang lagi-lagi tidak seharusnya dilakukan oleh Pemilik Produk), tim Agile seharusnya bersifat lintas fungsi dan bebas silo. Tidak ada yang seharusnya memiliki semua pengetahuan di sekitar satu aktivitas pengembangan tertentu, jadi mungkin ada kesempatan bagi Anda untuk melakukan diversifikasi di sana vs hanya "kode monkeying".


3

Sebaliknya, saya mendapati bahwa memiliki pemilik produk membuat keputusan tentang fungsionalitas memungkinkan saya untuk mencurahkan lebih banyak waktu untuk menghasilkan kode berkualitas. Plus, jika ada kekhawatiran yang valid, saya selalu dapat mempertanyakan keputusan pemilik produk, dan itu biasanya mengarah pada diskusi yang bermanfaat.


3

Kami berlatih Scrum di sini. Kami memiliki pertemuan perencanaan dua minggu di mana kami memberi makan dalam prioritas bisnis saat ini, dan keberhasilan dan kegagalan dari sprint sebelumnya, dan kami memutuskan, sebagai tim , apa yang ingin kami tangani untuk sprint berikutnya.

Salah satu cara kami melakukan ini adalah dengan mengurutkan simpanan di papan berdasarkan kompleksitas secara vertikal, dan prioritas bisnis secara horizontal. Setelah itu, Pemilik Produk telah mendapat masukan, jadi terserah tim untuk memilih apa yang ingin kita lakukan. Jelas, memilih tugas dengan kompleksitas tinggi dan prioritas rendah disukai, tetapi kami memutuskan ini sebagai tim. Itu membuat sesi perencanaan lebih lama, tapi itu layak, dan merupakan bagian inti dari proses Agile.

Dan kami memang memiliki manajemen mikro kadang-kadang, tapi itu masalah yang berbeda.


3

Masalah sebenarnya yang Anda gambarkan adalah patologi umum ketika tim mengadopsi Metodologi: mereka mematikan otak mereka. Ini juga berlaku dengan sistem lincah sekolah baru seperti halnya dengan sistem kelas berat sekolah tua.

T: Metodologi menentukan x, tetapi x tidak berfungsi dengan baik. Apa yang harus kita lakukan?

A: Saring implementasi x Anda. Mungkin berhenti melakukannya sama sekali. Metodologinya bukan bos Anda!

Dalam kasus khusus ini, sepertinya pemilik produk mungkin melakukan terlalu banyak. Apakah Anda nyaman berbicara dengannya tentang hal itu? Apakah Anda akan merasa nyaman melakukan percakapan itu jika Anda tidak "melakukan scrum?" Jika pemilik produk tidak sensitif terhadap umpan balik konstruktif, itu bukan masalah metodologi, itu masalah dengan pemilik produk.


2

Saya tidak benar-benar selaras dengan hal scrum keseluruhan karena telah lebih banyak air terjun untuk sementara waktu.

Tapi jujur ​​saja, ini terdengar lebih seperti masalah personil manajemen daripada masalah teknik manajemen proyek. Seperti di dalamnya lebih banyak orang yang berbasis daripada teknik.


Tidak @temptar, hubungan kami sangat bagus. Jangan tersinggung, tidak ada kebencian, tidak ada sama sekali. Semuanya baik-baik saja, semuanya kecuali bagaimana perasaan kita terhadap pekerjaan itu.
Saeed Neamati

2

Peran Pemimpin dalam Tim Self-Organizing akan menjadi posting blog tentang sesuatu yang tampaknya hilang dari posting Anda. Di mana tim memutuskan pekerjaan apa yang harus dilakukan dalam sprint? Di mana tim memiliki kepemilikan dalam proses dan pekerjaan? Apakah Anda memiliki seseorang yang cukup mengenal Scrum sehingga Anda melakukan Scrum dan bukan versi sesat darinya?


2

Saya memiliki pengalaman yang sama dengan Scrum dan suka menyebutnya "tirani cerita".

Dari pengalaman saya, pengembang lebih banyak di sisi kreatif / desain / frontend tampaknya lebih menderita daripada orang-orang yang terlibat dalam pekerjaan backend.

Satu-satunya jalan keluar yang saya temukan sejauh ini adalah dengan membuang Scrum - seringkali tidak mungkin dan / atau sesuai karena bagaimanapun juga memiliki kelebihannya - atau untuk memperkenalkan sesuatu seperti waktu 20% Google untuk memberi pengembang outlet kreatif selain dari "Anda" Anda bebas untuk memilih bagaimana mengimplementasikan Halaman Login ", karena pada kenyataannya Anda tidak seperti implementasi Anda dibatasi oleh kode dan arsitektur sistem yang ada - yaitu kecuali seseorang mempertimbangkan kebebasan untuk memilih antara 'a for and a while loop' a kebebasan.


1

Ada perbedaan besar antara Anda memutuskan apa yang harus dilakukan , atau diberi tahu apa yang harus dilakukan .

Dalam pengalaman saya, ada jalan yang agak jauh dari diberi tahu apa yang harus dilakukan untuk memutuskan apa yang harus dilakukan.

Pada akhir cara ini biasanya ternyata kita diperintahkan bukan karena mereka suka kekuasaan dan bukan karena mereka tidak punya yang lebih baik untuk dilakukan. Justru sebaliknya, pada akhir cara ini - ketika mereka mendapatkan kepercayaan yang cukup dalam tim kami - mereka tampaknya lega dan dengan senang hati memberikan kami kontrol sebanyak yang kami bisa tangani (dan jika kepercayaan mereka benar-benar kuat, mereka bahkan mencoba untuk lulus lebih dari itu)

Oh dan dalam pengalaman saya ini pada dasarnya tidak ada hubungannya dengan Scrum / gesit. Terjadi dengan scrum, iteratif, air terjun, apa pun. Tampaknya masalah kepercayaan adalah proses agnostik


1

Di tim kami, pemilik produk memberi tahu kami apa yang harus dilakukan dan kami memutuskan bagaimana kami melakukannya. Sangat penting untuk melakukan pemisahan ini atau Anda akan berakhir dalam situasi yang telah Anda jelaskan.


1

Sesuai pengalaman saya, Scrum sangat memperhatikan Anda apa yang Anda lakukan. Itu hanya duduk di bahu Anda dan menonton apa yang Anda lakukan. Meskipun memiliki keunggulannya sendiri, saya benci metodologi scrum. Mengharapkan hitungan, bukan kualitas. Kualitas semakin dikompromikan dengan metodologi scrum.


"Kualitas dikompromikan dengan metodologi scrum.": Mungkin agak ekstrim untuk mengatakan bahwa kualitas dikompromikan tetapi, ya, pengendalian proyek mendapatkan prioritas yang lebih tinggi daripada kualitas.
Giorgio

Sungguh menakjubkan betapa sedikit orang yang tahu tentang scrum atau gesit, dan bagaimana mereka memposting seperti otoritas. Seseorang mendapat kesan bahwa seseorang bekerja selama beberapa minggu pada kelompok disfungsional di mana mereka mengatakan mereka "melakukan scrum" dan menyimpulkan bahwa itu adalah bagaimana scrum seharusnya. Dalam hal ini, ia adalah orang yang sepenuhnya anonim dengan hanya satu posting atau komentar dalam 4 tahun, dan tidak ada bukti keahlian dalam hal ini. Inilah sebabnya kami tidak dapat menanggapi banyak dari komentar ini dengan sangat serius.
Curtis Reed
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.