Tumpukan tugas "ukuran gigitan" secara paralel dengan jaminan fitur "utama"?


16

Setelah lebih dari dua tahun bekerja di struktur departemen pengembangan yang sangat sunyi, "lone-wolf", kami mengadopsi Agile SCRUM. Bagus. Saya suka Agile; sebagai pengembang, ini membuat Anda tetap fokus, sibuk, dan produktif tanpa memiliki banyak pemangku kepentingan yang mendorong proyek demi proyek, dengan harapan mereka semua akan dilakukan kemarin.

Namun, ada satu aspek pindah ke SCRUM versus "model" kami saat ini, yang saya pikir orang di luar Pembangunan tidak akan suka sedikit pun. Itulah kemampuan mereka saat ini untuk meminta kami melakukan perubahan kecil "selagi Anda menunggu". Sebagian besar dari pengembangan kami hanya untuk konsumsi internal, dan kami sebagian besar berada di gedung yang sama. Jadi, sudah lazim selama bertahun-tahun bagi seorang pimpinan departemen atau manajer di tempat lain untuk datang ke "pemilik basis kode" aplikasi tertentu dan meminta barang-barang kecil (kadang-kadang tidak begitu kecil, tapi kami cukup baik untuk tidak mengambil tiga- proyek minggu berdasarkan "drive-bys" ini). Bahkan bos kami terkadang menyampaikan hal-hal yang disampaikan kepadanya dengan cara ini. Sangat sering, jika kita bekerja dalam basis kode yang dimaksud pada saat itu, kita cukup memunculkan file sumbernya,

Dengan metodologi Agile SCRUM dasar, perubahan ini akan dicatat sebagai cacat (kami tidak memenuhi persyaratan yang ditentukan dalam cerita yang sebelumnya dikonsumsi) atau cerita kecil baru (kami memenuhi semua persyaratan yang disebutkan, tetapi persyaratan itu tidak lengkap, kabur atau tidak benar , atau mereka berubah setelah pengiriman setelah pengguna melihat fitur baru). Either way, sebagian besar akan menjadi salah satu-pointer di sebagian besar, jika tidak nol, dan prioritas relatif rendah (sistem ini dapat digunakan dalam kondisi saat ini, tapi akan jadi lebih dingin jika ...), membuat mereka tidak mungkin dibawa berlari ketika bekerja backlog top-down.

Kemungkinan ini dinaikkan pada pertemuan dev sebagai sumber oposisi aktif untuk proses Agile kami oleh departemen lain, yang akan melihatnya sebagai kurang "gesit" daripada kemampuan kami saat ini untuk membuat tweak kecil berdasarkan permintaan. Ini adalah masalah IMO yang valid; para pemangku kepentingan di balik PO tidak selalu sepakat tentang hal-hal apa yang paling penting, karena mereka semua tidak memiliki sudut pandang yang sama, namun biasanya hanya para manajer yang membuat keputusan akhir, dan oleh karena itu bias mereka adalah yang ditampilkan di jaminan produk.

Sebuah solusi kemudian diusulkan, yang sementara ini disebut "toples permen" (istilah lain yang dibuang adalah "perahu saus"). Perbaikan kecil yang diminta oleh "orang-orang kecil" di berbagai departemen, yang tidak cacat dalam cerita yang ada, yang diperkirakan dengan konsensus atau aklamasi dalam tim untuk mengambil kurang dari setengah hari pengembang, dan itu akan membuat dampak langsung, signifikan, dan positif pada pengalaman pengguna menurut pendapat pengguna akhir, dimasukkan dalam daftar secara paralel dengan jaminan simpanan utama. Mereka akan diidentifikasi sebagai "cerita", tetapi akan disimpan terpisah dari simpanan utama cerita "besar" yang menjadi prioritas. Jika, sewaktu-waktu selama kemajuan normal sprint, kami bekerja di area sistem di mana salah satu tweak ini dapat dibuat, membuat tweak sepele, kita bisa membawa tweak ke sprint dan kode di samping cerita yang lebih besar. Melakukan initidak boleh membahayakan penyelesaian cerita yang lebih besar atau pekerjaan berkomitmen lainnya. PO juga akan memiliki akses ke daftar ini, dan jika mereka mengerjakan cerita pengguna yang akan datang menyentuh fitur dasar yang melibatkan tweak, mereka dapat melipatnya ke dalam cerita sebagai persyaratan dan kemudian kami akan memenuhi persyaratan seperti yang akan kami lakukan lain. Ini, diperkirakan, akan membuat tweak lebih mungkin untuk dikerjakan lebih cepat daripada nanti.

Ini memicu reaksi di antara kita dengan pelatihan ScrumMaster "uh-uh". Ada satu jaminan simpanan. Dua backlog memperkenalkan pertanyaan tentang item # 1 mana yang benar - benar paling penting, item mana yang menentukan kecepatan nyata , dan dari mana dari dua backlog cerita mana yang sebenarnya berada (demarkasi ukuran / kompleksitas akan memiliki beberapa kasus yang jatuh secara relatif sewenang-wenang ke satu sisi atau yang lain). "Biarkan prosesnya bekerja", kami berkata; jika perubahan benar-benar signifikan bagi pengguna akhir, mereka akan membuat suara yang cukup untuk membuat kepala departemen membuat keputusan waktu / uang di papan, dan itu akan menabrak kesadaran tim dev menuju bagian atas tumpukan.

Saya pikir saya akan mengajukan pertanyaan: Menurut pendapat Anda, apakah daftar paralel cerita "ukuran gigitan" memiliki nilai dalam mendapatkan perubahan kecil, bermanfaat tetapi pada akhirnya prioritas rendah dibuat lebih cepat, atau apakah secara keseluruhan itu keputusan yang lebih baik untuk melipatnya ke dalam tumpukan utama dan membiarkan proses dasar mengatur inklusi mereka dalam sprint?


5
Seberapa baik gaya pengembangan kafetaria saat ini bekerja? Jika semua orang senang dengan itu, dan dapat hidup dengan ketidakpastian tenggat waktu yang terus bergerak, lalu mengapa mengadopsi scrum sama sekali? Ini bukan sekadar pertanyaan retoris; alasan utama Anda ingin mengadopsi scrum adalah untuk menghilangkan dengan tepat kualitas gaya pengembangan Anda saat ini yang tampaknya dihargai oleh para pemangku kepentingan Anda. Anda harus mempertimbangkan scrum karena Anda merasakan masalah yang scrum akan pecahkan; Apakah masalah itu telah dikomunikasikan secara memadai dan meyakinkan kepada para pemangku kepentingan?
Robert Harvey

Kami memiliki beberapa masalah dengan sistem saat ini; pertama, orang yang "memiliki" basis kode dari berbagai aplikasi internal dikuburkan oleh "drive-by" yang meminta fitur tambahan. Sulit atau mustahil untuk bergerak dan fokus pada sesuatu yang lain. Yang pada dasarnya menjadikan setiap pengembang "guru" untuk kode yang telah mereka tulis, alih-alih setiap aplikasi menjadi upaya tim yang setidaknya diketahui oleh setiap pengembang. Tidak mengatakan bahwa kepemilikan kode apa pun buruk, tetapi kepemilikan kode kuat, ya kami ingin menghentikannya.
KeithS

Sistem ini juga sangat mencegah komunikasi; kita semua masing-masing mendukung aplikasi yang masih ada di sekitar kita yang telah melakukan pekerjaan dengannya, dan kita tidak punya waktu untuk mempelajari apa yang dilakukan orang lain. Ini telah menghasilkan adopsi kerangka kerja yang berbeda tergantung pada apa yang paling akrab dengan pembuat kode itu, membuat interop antara basis kode menjadi mimpi buruk (dan kita hidup dan mati sebagai perusahaan pada keterampilan kita dalam integrasi sistem).
KeithS

Terakhir, ada beberapa hal yang tidak bisa dilakukan oleh satu orang, tidak peduli seberapa bagusnya. Kami ingin dapat memanfaatkan seluruh tim kami secara terkoordinasi pada proyek-proyek besar alih-alih menunggu berbulan-bulan untuk satu orang untuk mendapatkan semua LoC yang diketik di NBT kami. Itu membutuhkan sistem yang memungkinkan koordinasi semacam itu tanpa melalui bos kami untuk semuanya. Sampai sekarang kami belum terganggu, bahkan sampai mempekerjakan orang baru untuk tunggal tujuan memberi mereka sesuatu yang baru untuk mengembangkan dan sendiri.
KeithS

Oh, dan terakhir-terakhir; sistem pengiriman persyaratan saat ini terutama adalah "drive-bys" ini. Jika saya kebetulan siku jauh di dalam basis kode yang sama sekali berbeda, dan saya tidak menuliskan apa yang Anda inginkan dalam detail yang cukup untuk mengingat apa yang sebenarnya Anda inginkan ketika Anda datang dengan kubus saya untuk bertanya kepada saya, kemungkinan besar akan menyelinap melalui sepenuhnya retak. Pengumpulan persyaratan untuk proyek yang lebih besar lebih terorganisir, tetapi selalu ada satu hal lagi, dan saat ini tidak ada gudang pusat untuk hal-hal ini.
KeithS

Jawaban:


10

Saya akan berbicara tentang beberapa poin yang, semoga, akan membantu Anda menemukan jalan Anda:

  1. " SCRUM " adalah tentang menjadi gesit. Akal sehat diperlukan. Jika perubahannya adalah perubahan beberapa menit, saya tidak berpikir Anda perlu jaminan simpanan untuk itu. Jika lebih dari 2 jam, saya pikir Anda harus memikirkannya lagi. Tidak semua yang merupakan "kemenangan mudah" harus dilakukan. Di SCRUM Anda bekerja berdasarkan prioritas. Saya pikir PO harus mendapatkan informasi tentang apa yang Anda peroleh dari penambahan dan upaya yang diperlukan. Hanya dengan begitu PO dapat memutuskan apakah itu penting atau tidak. Pindah ke SCRUM, kadang-kadang datang dengan banyak pertanyaan dan pengembang akan sering mengatakan "tetapi, itu hanya akan memakan waktu ד beberapa jam". Terus? Beberapa jam adalah waktu, tidak semua yang pendek perlu dimasukkan.
  2. Saya pernah bekerja di sebuah proyek di mana kami memiliki "rekayasa jaminan simpanan" . Tumpukan ini berisi item yang disarankan oleh pengembang untuk meningkatkan produk. Item-item itu tidak memiliki nilai pengguna eksplisit (tetapi memang memiliki nilai pengguna implisit). Misalnya: refactoring komponen dalam kode. Kami telah menggambarkan perubahan, upaya, dan keuntungan (dalam hal ini, Anda tidak dapat menampilkan apa pun kepada pengguna. Tetapi jika refactoring tersebut menyebabkan pengembangan kemampuan baru lebih cepat maka itu pasti merupakan keuntungan bagi pengguna). PO kami memutuskan bahwa selama versi kami harus menginvestasikan 10% dari setiap sprint (rata-rata) untuk barang-barang tersebut. Sebelum setiap sprint, ketika PO memutuskan tentang backlog sprint yang akan datang, dia memastikan bahwa kami memiliki 10% dari item backlog enginerring. Jadi 2 versi backlog -> 1 sprint backlog.
  3. Buffer - Ketika mulai bekerja di SCRUM orang sering lupa bahwa, sebagai insinyur perangkat lunak, kami meninggalkan dunia yang penuh ketidakpastian. Tidak apa-apa untuk menghitung 1 hari kerja sebagai 6 jam alih-alih 8. Katakanlah Anda memiliki sprint 15 hari, itu berarti Anda memiliki 30 jam ekstra yang digunakan untuk rapat, untuk hal-hal yang terlalu lama, dan ya - juga untuk mereka yang kecil hal-hal yang terlalu kecil untuk diingat tetapi merupakan bagian dari pekerjaan kita sehari-2 hari.
  4. Tetap fokus - Terakhir tapi tak kalah pentingnya, di SCRUM penting untuk tetap fokus. Putuskan berapa banyak dari total usaha Anda, dan apa prioritasnya, untuk berinvestasi dalam tugas-tugas tersebut dan ingat untuk menginvestasikan waktu & upaya ini. Jangan melayang untuk mengerjakan "hal-hal kecil" hanya karena mereka kecil. Anda memiliki PO untuk membantu Anda memutuskan dan Anda memiliki akal sehat.
  5. Tetap Agile - Dan, pada akhirnya, jangan lupa untuk mencoba berbagai metode untuk mendekati masalah ini, tanyakan pada diri Anda apakah itu memang cara terbaik. Memperbaiki di jalan.

Semoga berhasil :)


1
+1 untuk backlog teknik. Ini juga dapat digunakan untuk permintaan pengguna yang tidak memotong.
Bart van Ingen Schenau

3

Kerangka kerja pemrograman seperti Agile dan SCRUM dirancang untuk menerapkan disiplin dan struktur pada pengembangan. Namun, disiplin dan struktur tampaknya menjadi antonim kesenangan dan kreativitas. Biasanya, Anda perlu bekerja lebih keras untuk membangun dan mempertahankan disiplin. Sangat sulit untuk menemukan keseimbangan antara konsep-konsep yang berlawanan ini. Karena itu, kerangka kerja cenderung menghindari topik.

Pada proyek terakhir saya, kami mengamati bahwa pengembang membutuhkan sedikit waktu setiap hari untuk menyegarkan atau menjernihkan pikiran mereka, dll. Mereka diberi waktu yang dianggarkan (0,5 jam / hari atau 2,5 jam / minggu) di mana mereka dapat melakukan apa saja, dalam alasan (dengan kemungkinan diterapkan pada sesuatu di tempat kerja). Untuk menjaga agar disiplin, mereka diminta untuk mendokumentasikan kegiatan mereka sehingga mereka dapat memperoleh pujian atas pencapaian apa pun, dll. Memiliki anggaran khusus untuk "toples permen" yang sesuai dengan jadwal kami dan mencegah hal-hal menjadi tidak terkendali.

Btw, kami menyebut kami "proyek coolness" dan akhirnya menjadi sumber banyak ide bagus dan perbaikan di perusahaan itu.


3

Anda harus menyimpan cerita-cerita kecil di tumpukan utama.

Saya menghadapi masalah serupa dengan apa yang Anda gambarkan, meskipun saya tidak menggunakan scrum. Saya melihat Anda menghadapi tantangan prioritas dan efisiensi .

Kedengarannya seperti di bawah "cara lama" Anda, siapa pun secara implisit diberdayakan untuk menjadikan tugas mereka sebagai "prioritas utama" saat ini jika mereka mengunjungi kantor pengembang. Ini memiliki beberapa manfaat. Pemohon merasa seperti mereka ditanggapi, dan pemohon dan pengembang mendapatkan "kemenangan cepat".

The downside adalah bahwa sering memasukkan tugas-tugas ini cenderung memperlambat atau menggagalkan tugas-tugas prioritas utama yang disepakati dengan pemilik produk. (Catatan tambahan, seringkali semua orang meremehkan jumlah waktu yang dibutuhkan untuk perbaikan "cepat" ini.)

Pengalaman saya adalah bahwa mencoba memeras dalam tugas dengan prioritas rendah merusak manfaat prioritas. Sebagai pengembang, prioritisasi memvalidasi bagi saya bahwa saya sedang mengerjakan apa yang diinginkan oleh pemilik produk. Pemilik produk harus memutuskan apakah dia ingin mengambil pekerjaan ekstra dan risiko (betapapun kecilnya) dari permintaan "senang".

Seringkali ketika saya meminta pemangku kepentingan untuk memprioritaskan, saya ditanya "Bisakah Anda memerasnya?". Keinginan tersirat adalah bagi saya untuk menyelesaikan tugas baru secara ajaib tanpa memengaruhi prioritas tertinggi saat ini.

Yang sering terjadi pada saya adalah bahwa para pemangku kepentingan meminta LargeImportantProject dan SmallLessImportantTask. Dilema adalah, harus SmallLessImportantTask menunggu LargeImportantProject untuk menyelesaikan (atau memiliki hambatan)? Ada pengorbanan, dan pengalaman saya adalah bahwa pemilik produk harus memutuskan. (Jika pemilik produk tidak memutuskan, tim pengembang harus menebak.)

Salah satu tujuan scrum (dan manajemen proyek secara umum) adalah untuk menghindari hambatan untuk tugas-tugas prioritas tertinggi. Saat Anda menjadi lebih efisien, semakin sedikit ruang untuk bekerja ekstra.

Efisiensi dapat menakutkan, tetapi saya telah melihat manfaatnya melebihi biaya dalam dua cara penting.

  1. Ketika Anda menjadi lebih efisien, Anda meningkatkan kapasitas tim Anda untuk menyelesaikan pekerjaan yang berharga, yang mencakup permintaan "senang memiliki".
  2. Jika suatu permintaan benar-benar "baik untuk dimiliki", itu mungkin sangat sah untuk permintaan untuk menunggu sampai prioritas bisnis yang lebih penting ditangani.

Poin bagus. Bertentangan dengan konsensus sejauh ini, tapi itu sebabnya saya mengajukan pertanyaan; untuk mendapatkan semua sudut pandang.
KeithS

Semua yang dikatakan Aaron benar ... tapi itu semua mengarah pada dinamika "perusahaan besar". Terlalu banyak simpai harus dilewati agar pengguna akhir mendapatkan apa yang mereka inginkan. Dengan demikian, mereka pada akhirnya akan berhenti dengan mengusulkan tweak kecil yang berakhir dengan mereka mendapatkan alat yang baik dan hanya menggunakan alat "payah" apa adanya.
Dunk

2

Menurutku; masalah Anda adalah cara tugas diprioritaskan dalam jaminan simpanan. Misalnya, "prioritas" dapat mempertimbangkan kepentingan dan seberapa cepat itu dapat diselesaikan. Sesuatu yang tidak begitu penting tetapi dapat diselesaikan dalam 10 menit dapat memiliki prioritas lebih tinggi daripada sesuatu yang lebih penting yang akan membutuhkan beberapa minggu untuk diimplementasikan.


1
Ini adalah poin yang bagus; "ROI" harus dipertimbangkan ketika menetapkan prioritas. Lakukan hal yang membuat Anda paling cepat mengalami peningkatan. Ini dapat didorong ketika mengatur backlog (kami benar - benar awal dalam adopsi Agile kami).
KeithS

2

Saya telah bekerja dengan gesit untuk sementara waktu sekarang. Yang bisa saya katakan adalah ini - ada situasi di mana bersikeras pada metodologi dan semua yang dimasukkannya, benar-benar salah. Anda harus AGILE, dan mengutak-atik metodologi untuk situasi tertentu adalah, IMO, suatu keharusan.

Seperti Avi di atas dikatakan - "SCRUM" adalah tentang menjadi gesit. Akal sehat diperlukan. Jika perubahannya adalah perubahan beberapa menit, saya tidak berpikir Anda perlu jaminan simpanan untuk itu.

Jika perubahan itu membutuhkan waktu, itu berarti tidak semua yang "tidak berbahaya" dan harus didokumentasikan dengan baik.


0

Berdasarkan pertanyaan awal Anda dan klarifikasi berikutnya, inilah yang saya rasakan bahwa poin rasa sakit Anda adalah

  • Persyaratan yang terus berubah
  • Ketidakmampuan bagi pengembang untuk fokus pada area lain dari aplikasi, yaitu. kami pahlawan di satu bagian aplikasi tetapi tidak ingin menyentuh yang lain.
  • Berbagai pendekatan untuk arsitektur, solusi, kerangka kerja yang diadopsi
  • Proses pengumpulan persyaratan tampaknya tidak berhasil

Scrum, jika awalnya dipatuhi dengan benar harus memperbaiki banyak masalah ini, dan yang lebih penting, membawa masalah lain ke permukaan yang harus diselesaikan.

- Persyaratan yang terus berubah

Memiliki satu jaminan yang semuanya dimasukkan dan diprioritaskan dengan benar harus berarti bahwa tim tidak harus menanggung beban perubahan persyaratan saat berada di tengah pengembangan. Jika lingkungannya sangat dinamis, sprint kecil 1 atau 2 minggu harus memastikan perubahan prioritas masih dapat difasilitasi dalam periode waktu yang relatif singkat.

- Ketidakmampuan bagi pengembang untuk fokus pada area lain dari aplikasi, yaitu. kami pahlawan di satu bagian aplikasi tetapi tidak ingin menyentuh yang lain.

Tim scrum bekerja sama dengan baik dan saling mendukung, dengan dorongan khusus untuk berbagi pengetahuan dalam tim dan mencari tantangan untuk bekerja pada bagian lain dari aplikasi akan berusaha untuk memastikan pengetahuan aplikasi dibagikan. Beberapa praktik seperti pemrograman pasangan dapat membantu orang mengatasi rasa takut mereka bekerja pada kode yang tidak mereka kenal sementara juga belajar dan berbagi pengetahuan itu. Ini mungkin memerlukan beberapa sprint sebelum pengetahuan aplikasi didistribusikan antara tim dan orang-orang merasa nyaman bekerja di area aplikasi apa pun. Juga, memungkinkan orang untuk melakukan tugas-tugas dewan, yaitu membuat pilihan mereka sendiri tentang apa yang ingin mereka kerjakan, dapat mendorong hal ini.

- Berbagai pendekatan arsitektur, solusi, kerangka kerja yang diadopsi

Scrum memfasilitasi komunikasi yang lebih baik, memfasilitasi kerja tim dan pengambilan keputusan yang lebih baik serta memberikan visibilitas yang lebih besar ke dalam apa yang sedang terjadi. Ini adalah gilirannya harus memfasilitasi keputusan organisasi di sekitar penggunaan kerangka kerja, solusi arsitektur, dll dan penggunaan mekanisme Scrum of Scrums dapat membantu dalam menanamkan bahwa di seluruh organisasi.

- Persyaratan Proses Pengumpulan

Sekali lagi, jika Anda mematuhi aturan dengan ketat, jika persyaratan tidak ditentukan dan siap untuk tim untuk dapat memahami dan memperkirakan apa yang diperlukan untuk memenuhi persyaratan, itu tidak boleh dibawa ke dalam sprint. Ambil persyaratan lain yang merupakan prioritas tinggi dan telah didefinisikan dengan baik ... karena dengan begitu Anda tahu Anda akan dapat mewujudkannya! Meskipun mungkin tidak segera memperbaiki proses pengumpulan persyaratan, itu akan memaksa perubahan yang diperlukan untuk memperbaiki proses itu.

Untuk menjawab pertanyaan pertama Anda, tidak, seharusnya tidak ada dua tumpukan yang terpisah. Pada waktu tertentu, demi kepentingan semua orang, pengembang dan organisasi mengerjakan item prioritas tertinggi terlebih dahulu. Prioritas terutama harus didasarkan pada nilai bisnis, dan sangat mungkin banyak perubahan kecil dan permintaan menambah nilai bisnis. Biarkan pemilik produk memutuskan itu.

Saya telah menjadi Scrum Master selama lebih dari 7 tahun dan membantu memperkenalkan Scrum ke banyak tim dan perusahaan. Dalam pendapat saya yang rendah hati dan dari pengamatan saya, saya merasa bahwa jika Scrum diperkenalkan ke organisasi Anda untuk pertama kalinya, ikuti dengan buku. Jangan menyimpang. Scrum membutuhkan disiplin untuk dapat tetap berpegang pada praktik dan proses. Terlalu mudah untuk membuat pengecualian agar sesuai dengan keadaan tertentu, dan jika dilakukan terlalu dini, akan menyebabkan erosi manfaat dan nilai-nilai yang dibawanya. Lakukan dasar-dasarnya, lakukan dengan sangat baik. Menjadi seorang ahli dalam melakukan dasar-dasar dan memahami mengapa mereka ada di sana, dan kemudian mengubah prosesnya agar lebih sesuai dan untuk mendorong perbaikan berkelanjutan dalam organisasi Anda.

Ada kasus yang sangat valid untuk mengatakan ini "Agile", jadi kita harus bersedia mengubah proses, tetapi ada perbedaan yang signifikan antara tim yang mengatur diri sendiri, mengatur diri sendiri memahami proses dan mendiskusikan perubahan yang dapat dilakukan untuk proses, sebagai lawan dari tim yang baru mulai berjalan di jalur Agile atau Scrum. Ini seperti mencoba berlari sebelum Anda tahu ...

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.