Backend devs ditulis oleh cerita pengguna


10

Saya berencana untuk mengiris dalam pengembangan backend ke cerita pengguna secara vertikal. Tetapi seorang backend di tim kami mulai mengeluh bahwa ini membuat pekerjaan mereka tidak terlihat.

Jawaban saya adalah itu

  • pada pertemuan perencanaan dan tinjauan sprint kami membahas tugas backend di depan para pemangku kepentingan sehingga membuatnya terlihat, dan

  • mempertahankan kualitas tinggi selama proyek akan menghasilkan langkah awal yang lebih lambat daripada tim lain, tetapi kami akan memiliki kecepatan yang stabil selama proyek. Dan kecepatan sangat terlihat oleh para pemangku kepentingan.

Dia masih bersikeras memiliki cerita seperti: "Sebagai pengembang saya perlu memiliki lapisan domain sehingga saya dapat merangkum logika bisnis."

Bagaimana saya bisa menyelesaikan masalah sebelum mencemari tim?

Akar dari masalah ini adalah bahwa manajemen kami secara sistematis menganggap pekerjaan backend sebagai tidak terlihat dan memanggil penambang dev yang didukung, atau istilah merendahkan lainnya.


7
Saya tidak akan punya cerita backend, mereka tidak masuk akal .. Namun, saya tidak ingin memiliki manajer seperti itu .. Saya pikir para backend
dev adalah bintang rock

2
Membuat kisah back-end yang terpisah menyiratkan bahwa pekerjaan back-end dapat diprioritaskan secara terpisah dari front-end. Ini memiliki risiko bahwa prioritas ditugaskan sehingga pekerjaan back-end akan terdegradasi ke bagian bawah backlog sampai dimasukkan kembali dalam cerita front-end. Untuk masalah dengan kurangnya penghargaan dari manajemen, saya sarankan Anda bertanya tentang hal itu di Workplace.SE.
Bart van Ingen Schenau

Solusi fantasi saya melibatkan tamparan sesekali dari semua pihak. tamparan Berhenti merengek. slap Stop mengabaikan peran penting yang diberikan data dan logika bisnis untuk kesuksesan bisnis yang membayar sewa kita. tamparan Berhenti makan siang orang lain. Itu bukan lemari es ibumu.
Erik Reppen

1
iris topik secara vertikal, kemudian iris cerita yang dihasilkan menjadi tugas horisontal.
jwenting

Jawaban:


4

Ada beberapa hal yang salah dengan situasi yang dijelaskan, masalah yang jelas adalah kurangnya rasa hormat yang diberikan kepada pengembang back-end. Karena pertanyaan ini ditandai dengan tangkas, saya akan mendorong kembali pada jawaban lain yang menyarankan ini hanya masalah sosial. Ada beberapa bau busuk dan kemungkinan anti-pola dalam cerita Anda, tidak ada yang berhubungan dengan manajemen yang bodoh atau bahkan bagaimana Anda mengiris cerita.

Fakta bahwa sekelompok individu dalam tim merasa diremehkan karena tidak mendapatkan kejayaan dari pekerjaan telah menyelesaikan beberapa masalah yang mungkin terjadi.

  • Seharusnya tidak ada orang yang hanya melakukan pengembangan back-end. Pendekatan Agile yang umum adalah membuat tim lintas fungsi terdiri dari generalisasi spesialis yang mempraktikkan kepemilikan kode bersama. Individu tidak boleh berfokus secara eksklusif pada pengembangan back-end atau front-end, meskipun mereka pasti akan lebih berpengalaman atau lebih baik dalam beberapa hal daripada yang lain.
  • Arsitektur tidak menghasilkan nilai. Dari perspektif pengguna - satu-satunya perspektif yang benar-benar penting - tidak masalah jika Anda memiliki lapisan atau bahasa domain atau bahkan jika solusinya diprogram. Satu-satunya hal yang penting adalah apakah Anda menciptakan nilai bagi pengguna. "Cerita" yang diusulkan dari pengembang back-end adalah persyaratan yang tidak masuk akal - ini adalah ringkasan dari keputusan desain yang, dari perspektif pengguna / pelanggan tidak melakukan apa pun untuk mencapai fungsi yang diinginkan. Dengan kata lain, setiap cerita pengguna yang diberikan dapat dicapai dengan sejumlah desain arsitektur yang berbeda. Ada kemungkinan bahwa cerita pengguna dapat diselesaikan tanpa modifikasi ke back-end sama sekali. Ini tidak menjadikannya cerita yang tidak valid.
  • Berpikir secara sistemik masih kritis. Meskipun arsitektur mungkin tidak mendapatkan nilai, arsitektur tetap penting untuk kesuksesan. Pengembang back-end memiliki masalah yang valid. Anda harus memikirkan bagaimana Anda akan membangun sistem. Anda harus menuliskan keputusan itu. Seluruh sistem itu penting meskipun hanya fitur front-end yang akan mendapatkan semua kemuliaan.

Rekomendasi saya adalah memperlakukan arsitektur sebagai warga negara kelas satu - tetapi lakukan dengan cara yang benar. Lakukan lokakarya atribut berkualitas dengan para pemangku kepentingan . Libatkan pemangku kepentingan utama dalam tinjauan arsitektur , atau setidaknya rangkum keputusan desain penting pada tonggak penting. Gambar arsitektur di atas kertas besar dan buat itu terlihat sehingga seluruh tim bisa melihatnya.

Mensyaratkan bahwa setiap orang mengembangkan di mana saja dalam sistem (front-end dan back-end), pasangkan program jika Anda perlu sehingga ini dapat terjadi secara efektif. Terus membuat cerita pengguna yang berfokus pada pengguna. Tetapi juga mengidentifikasi skenario atribut kualitas utama yang menunjukkan mengapa sistem dirancang seperti itu dan mendorong pengambilan keputusan tentang desain "back-end". Tinggikan desain arsitektur sehingga tidak terlihat lagi.


1
Terima kasih atas jawaban yang bisa ditindaklanjuti! Saya ingin menjernihkan sedikit pemahaman yang disebabkan oleh kata-kata saya yang salah. Dia bukan hanya "backend dev" sebenarnya dia bekerja di seluruh stack bahkan di firmware. Titik sakitnya adalah arsitektur backend tidak mendapatkan pengakuan yang tepat. Dan sementara arsitektur tidak mendapatkan nilai dengan sendirinya arsitektur yang ceroboh dapat merusak sistem atau setidaknya itu membuat mereka sangat mahal untuk dipelihara. Rencana saya adalah memfasilitasi lebih banyak pembicaraan tentang arsitektur selama pertemuan tinjauan dan perencanaan, dan lokakarya berkualitas juga terlihat seperti alat yang hebat!
Szili

FWIW, itu tidak selalu praktis untuk memiliki pengembang bekerja tumpukan penuh. Salah satu persyaratan di perusahaan saya saat ini mungkin melibatkan pengembangan CICS pada mainframe IBM, MQ, Java di Mule ESB, Datapower, dan akhirnya UI web yang kaya dengan jquery dan templat lainnya. Kisah pengguna lain mungkin melibatkan CORBA yang berbicara VMS COBOL, dan backend lain ditulis dalam Gupta.
Alan Shutko

@AlanShutko - tepatnya. "Ujung depan seseorang adalah ujung belakang orang lain" bukan? Ini adalah salah satu alasan mengapa saya tidak suka slang seperti "back end" dan "front end" terutama ketika berbicara tentang beberapa komponen dalam suatu sistem. Maksud Anda sangat penting! Bahkan "tumpukan penuh" adalah istilah relatif yang dapat memiliki arti berbeda di berbagai bagian sistem!
Michael

11

Ini tampaknya menjadi masalah sosial, sehingga akan membutuhkan solusi sosial.

Jika (seperti yang saya mengerti Anda) pengembang backend merasa diabaikan dan diremehkan, dan merasa bahwa pekerjaan mereka tidak cukup dihargai, maka ada sedikit yang bisa dilakukan proses pengembangan untuk mengubahnya.

Jika saya mengerti dengan benar, saya sepertinya para devs merasa bahwa mereka setidaknya harus memiliki cerita pengguna "sendiri", sehingga mereka dapat menunjuk ke mereka dan mengatakan "Ini adalah apa yang kami lakukan, hanya kami backend guys / gals". Namun, memiliki cerita yang diiris "horizontal" seperti ini adalah ide yang buruk, dan saya setuju dengan Anda untuk mengirisnya secara vertikal.

Solusi terbaik mungkin adalah melakukan pembicaraan diam-diam dengan pengembang yang bersangkutan (secara individu atau kelompok), dan mengatasi masalah yang mendasarinya, yang tampaknya menjadi salah satu rasa hormat. Pada titik tertentu, ini mungkin perlu ditingkatkan ke manajemen.


Terima kasih atas jawabannya. Masalahnya memang masalah sosial. Hari ini kami berbicara tentang argumen kemarin, dan pengembang yang bersangkutan mengatakan kepada saya bahwa ini adalah lebih dari bertahun-tahun penghinaan sistematis terhadap pekerjaan back-endnya daripada tentang pandangannya tentang proyek kami saat ini dan pemahamannya tentang proses scrum. Kami sepakat untuk bergerak maju dengan kisah-kisah yang diiris secara vertikal.
Szili

1
@ Siili: Apakah pekerjaan backend begitu buruk sehingga tidak layak dihormati, atau dia hanya menandai bahwa dia tidak diakui?
Blrfl

Pekerjaan backendnya sangat baik. Pengakuan yang tepat dan bahkan penindasan manajemen adalah masalahnya.
Szili

4

Akar dari masalah ini adalah bahwa manajemen kami secara sistematis menganggap pekerjaan backend sebagai tidak terlihat dan memanggil penambang dev yang didukung, atau istilah merendahkan lainnya.

Memang ini masalahnya. Sudah jelas Anda tidak akan menyelesaikannya dengan cerita!

Secara umum, salah satu fitur pengembangan lincah adalah transparansi. Ini juga berarti bahwa itu membuat masalah organisasi Anda lebih nyata .

Solusi tangkas standar untuk masalah ini adalah untuk mengadopsi pendekatan yang lebih "vertikal" atau "tumpukan penuh" untuk pengembangan, di mana pengembang backend Anda mengambil cerita dari atas ke bawah alih-alih hanya bekerja di zona nyaman mereka dari tingkat ujung belakang, dan frontend devs juga meregang ke arah backend (*).

Dengan kata lain: buat semua orang menghasilkan nilai untuk pengguna akhir Anda.

(*) Catatan: tidak semua berita harus memiliki komponen front-end atau komponen back-end. Elemen UI dapat diacak ulang tanpa kerja back-end tambahan, dan kinerja adalah fitur .


3
Kedengarannya seperti Anda tidak memiliki pemahaman tentang pengembangan backend. Lihatlah betapa sedikitnya nilai yang diberikan oleh seorang backend yang baik ketika front end guys melakukan semua pemodelan data dan implementasi logika di front end lalu menunggu enam bulan. Sebagian besar rekayasa yang baik tidak baik tentang menghasilkan nilai langsung, ini tentang menghasilkan dividen jangka panjang. Pendekatan Anda diterapkan pada pembangunan jembatan akan membuat setiap jembatan dibuat hanya untuk berdiri selama satu minggu dan tidak akan memiliki cetak biru atau arsitek karena itu bukan nilai langsung.
Jimmy Hoffa

1
Tidak @JimmyHoffa Saya cukup akrab dengan pengembangan back-end. Jawaban saya cukup lincah dari buku teks. Seperti yang mungkin Anda perhatikan, saya tidak menganjurkan memiliki orang-orang front-end saja. Jika Anda tidak suka gesit, jangan menggunakannya, tapi saya hanya menjelaskan cara kerja metodologi, jadi jangan menganggap hal-hal tentang saya, atau apa pun.
Sklivvz

2
Bagian di mana ia keluar jalur adalah di mana Anda mengatakan orang-orang back end tidak menghasilkan nilai dan hanya harus melakukan pekerjaan front-end, jika itu bukan maksud Anda dalam jawaban ini, Anda harus benar-benar mengubah itu menjadi lebih jelas apa yang Anda maksud di sini.
Jimmy Hoffa

1
@JimmyHoffa Tapi mereka tidak menghasilkan nilai apa pun, kepada pengguna akhir. Jika itu adalah tim yang hanya pengembang back end maka pengguna akan menjadi pengembang front end. Dalam hal itu, alasan Anda masuk akal, tetapi sepertinya tidak demikian.
Sklivvz

1
Jika di dunia Anda nilai hanya dihasilkan oleh penciptaan produk yang dapat berinteraksi dengan pengguna, dan pengembang back-end tidak diperlukan untuk itu maka di dunia Anda tampaknya arsitek dan manajer proyek, analis bisnis, SDM, dan semua orang lainnya juga tidak relevan. Dalam dunia saya, nilai dihasilkan oleh kualitas desain dan implementasi sistem sehingga pengembangan fitur di masa depan tidak melibatkan pengembaraan melalui web laba-laba dari basis data akses karena hanya produk yang dapat berinteraksi dengan pengguna yang dinilai ... Implementasi kualitas adalah nilai . Mungkin tidak segera, tetapi dalam jangka panjang.
Jimmy Hoffa

1

Masalah Anda adalah:

  • Anda memiliki lapisan manajemen di dalam bisnis Anda di mana mereka tidak memiliki tujuan. Scrum, gesit, aku tidak peduli. Manajemen dan pengembangan harus diisolasi dengan masalah bisnis yang ditangani oleh manajer produk yang memiliki petunjuk! @ # $ Ing tentang teknologi. Mungkin itu bekerja untuk Steve Jobs, tetapi saya tidak pernah berada dalam situasi di mana manajer non-teknologi yang dekat dengan dev adalah hal yang sehat atau pada akhirnya berfungsi untuk menghasilkan produk kualitas terbaik yang bisa dibuat oleh tim.

  • Anda memiliki devs yang lebih khawatir tentang penampilan daripada menyelesaikan masalah. Entah itu masalah budaya yang sangat serius (sepertinya kemungkinan diberikan seluruh fenomena "penambang" ini) dan / atau Anda memiliki masalah kualitas pengembang, yang juga tidak akan mengejutkan saya karena kurangnya kepercayaan diri.

Keluarkan orang-orang yang tidak perlu berada di sana karena perencanaan dan standup. Siapa pun yang memiliki gagasan tentang back-end menjadi kurang penting daripada front-end adalah seseorang yang tidak perlu berada di sana dan sebenarnya menghambat proses dengan berada di sana.

Cerita parit. Ya, saya serius. Jika mereka menyebabkan masalah seperti ini, buang airlock mereka. Di pekerjaan saya saat ini, kami hanya berpegang pada kriteria "selesai" untuk tugas yang diberikan, yang biasanya lebih fokus pada aplikasi daripada pengguna yang mungkin menyinggung orang-orang yang berpikir gesit (yang telah berubah terus-menerus selama 20 tahun) menang ' t bekerja jika Anda tidak mengikutinya ke surat itu, tetapi benar-benar jika kami pro, kami tidak perlu apa pun yang menyebabkan masalah bagi kami. Remukkan mereka, lemparkan ke atas bahu Anda.

Dan Anda mungkin ingin mengingatkan bahwa dev bahwa orang-orang yang benar-benar perlu mereka khawatirkan adalah teman sebaya langsung mereka, bukan orang-orang yang terlalu tidak mengerti untuk berada di perencanaan sprint.


Saran yang bagus. Perlu diingat bahwa tidak ada dalam manifesto lincah tentang "cerita pengguna" dan itu hanya praktik populer yang muncul dengan proses tertentu. Anda bisa lincah dengan cerita pengguna sebanyak yang Anda bisa tanpa ..
Michael

Ini benar. Saya tidak yakin manifesto lincah akan dianggap cukup untuk "melakukannya dengan benar" oleh banyak standar dari seluruh industri pelatihan yang dibangun di sekitarnya, tetapi seperti biasa ide-ide dan mana yang masuk akal bagi Anda dan tim Anda harus diutamakan daripada dampaknya, IMO. Anda juga akan mendapatkan banyak jawaban dari depan tentang bagaimana "gesit" dengan benar seperti Anda akan bertanya kepada mahasiswa apa aturan kencan. Tidak ada pengganti untuk berpikir kritis.
Erik Reppen

Saya tidak akan membuang cerita pengguna. Sebenarnya saya bekerja keras untuk memperkenalkan mereka karena kami memiliki tradisi mengabaikan pengguna akhir. Analogi Steve Jobs sangat tepat karena CEO kami adalah orang teknis yang brilian yang memiliki banyak perusahaan multi-juta. Satu hal yang gagal dia lakukan adalah membangun lapisan manajerial, jadi dia tetap sangat aktif dengan pekerjaan yang dilakukan. Ini memberi jalan bagi munculnya budaya bintang yang mengakibatkan kekhawatiran tentang penampilan. Singkatnya: kami memiliki masalah budaya. Tetapi mengingat itu diberikan, saya membutuhkan alat-alat seperti yang ada di jawaban untuk membuat langkah-langkah bayi diperlukan.
Szili

Either way, saya akan merekomendasikan dev UI anal-retensive berpengalaman jika Anda mengalami masalah UX. Tidak ada pengganti selain beberapa generalis hebat yang hanya sedikit orang yang mau membayar satu tim penuh.
Erik Reppen
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.