Bagaimana tim Scrum menjelaskan tugas-tugas infrastruktur dalam rapat perencanaan?

33

Bagaimana tim Scrum menjelaskan tugas dev / infrastruktur dalam rapat perencanaan?

Pada pandangan pertama, mereka sepertinya bukan cerita pengguna karena mereka tidak memberikan nilai pengguna akhir.

Namun, melampirkannya sebagai tugas ke cerita pengguna tertentu terkadang juga tidak masuk akal. Misalnya, tugasnya adalah: "Mengatur Bambu." Tugas itu tidak diperlukan untuk menyelesaikan cerita pengguna apa pun karena tim dapat membangun dan menyebarkan secara manual. Jadi melampirkannya ke cerita pengguna tidak masuk akal karena tugas ini tidak diperlukan untuk menyelesaikan cerita pengguna.

Jadi, ini menunjukkan bahwa tugas-tugas ini menjadi cerita pengguna. Tetapi kemudian, jika cerita tim menunjuk mereka, maka ini mengubah kecepatan yang aneh karena Pemilik Produk ingin mengetahui kecepatan terhadap jaminan simpanannya, bukan terhadap jaminan simpanannya dengan sekelompok cerita pengguna teknis yang melekat padanya.

scrum planning

— pengguna11347
sumber

25

Mereka sebenarnya bukan cerita pengguna. Itu adalah cerita pemangku kepentingan. Kecuali jika perangkat lunak sebenarnya dibayar untuk langsung oleh pengguna, jarang ada cerita yang dibuat sepenuhnya untuk keuntungan mereka.

Saya memberi Anda beberapa contoh:

artikel dengan kata kunci, yang memungkinkan pengiklan untuk memiliki iklan yang lebih efektif
CAPTCHA, yang ada untuk menghentikan moderator harus berurusan dengan spam secara manual.

Kebanyakan kisah teknis sebenarnya memberikan manfaat bisnis, tetapi jarang bagi pengguna. Membuat frase dengan cara yang berbeda dapat membantu. Saya biasanya menggunakan template injeksi fitur Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Ini secara eksplisit mengakui semua jenis pemangku kepentingan, termasuk tim pengembangan. Sekarang Anda juga dapat mengutarakan kisah teknis Anda, menyebut manfaat bisnis:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Saya telah menulis beberapa posting blog tentang ini: Itu bukan Cerita Pengguna , dan Fitur Injeksi dan menangani cerita teknis . Semoga mereka bisa membantu.

— Lunivore
sumber

3

Semantik ... IMHO ini bertentangan dengan filsafat Agile; menambahkan pemisahan yang dibutuhkan di mana tidak memberikan nilai nyata selain perasaan hangat yang kabur.

— Aaron McIver

5

Apakah Anda berbicara berdasarkan pengalaman, atau berteori? Saya bertanya karena saya telah menggunakan templat ini dengan sejumlah tim sekarang, dan menemukan bahwa mengutamakan tujuan benar-benar membantu menetapkan apa yang diperlukan untuk mencapai visi proyek. Mike Cohn menggunakan "sehingga" opsional. Saya tidak percaya itu.

— Lunivore

1

Saya melihat bahwa templat ini berguna untuk membantu mengkomunikasikan nilai tugas teknis yang akan dilakukan ke PO non-teknis. Ada perbedaan antara "sebagai seorang analis QA Saya ingin server integrasi terus menerus sehingga aplikasi diuji setiap hari secara otomatis" dan "Untuk mengurangi jumlah pengujian manual yang diperlukan pada akhir proyek, dan probabilitas suatu kesalahan tergelincir ke produksi, sebagai Tim QA kami ingin menguji server integrasi berkelanjutan ". Menampilkan bisnis yang tersembunyi memberikan OP informasi yang cukup untuk memutuskan apakah akan memasukkannya atau tidak.

— Soronthar

1

@ Koronthar Di mana akhirnya? "Untuk mengurangi tingkat frustrasi, sebagai tim pengembangan kami ingin membuat aturan sendiri" Ini sifatnya melingkar. Itulah salah satu alasan mengapa Anda tetap fokus pada pengguna dan hanya itu. Tugas harus disembunyikan dari PO; karena PO seharusnya tidak perlu khawatir dengan rincian itu.

— Aaron McIver

9

Oh, dan kalau-kalau itu tidak jelas - saya lebih peduli tentang menyelesaikan pekerjaan yang bermanfaat daripada saya tentang Scrum. Atau Ramping. Atau BDD. Saya juga percaya bahwa pekerjaan yang paling berguna dalam perangkat lunak berkaitan dengan belajar dan mengelola risiko. Ketika metodologi menghalangi pekerjaan yang bermanfaat, saya cenderung ke arah pekerjaan yang bermanfaat.

— Lunivore

12

Velocity adalah ukuran kapasitas tim untuk melakukan pekerjaan yang bermanfaat (sebagai lawan Drag). Tugas infrastruktur masih memberikan nilai pengguna akhir, meskipun secara tidak langsung, dengan membuat tim lebih efisien dalam jangka panjang. Saya tidak memiliki masalah melacak hal-hal ini sebagai cerita pengguna (pengguna adalah tim pengembang dalam kasus ini) dan memprioritaskannya dengan tepat. Seorang Pemilik Produk dalam komunikasi yang baik dengan pelanggan harus dapat mengetahui di mana tugas-tugas tersebut dapat ditampung tanpa mengganggu kiriman.

— Kristo
sumber

3

Saya pikir berbahaya bagi tim untuk mengaburkan perbedaan antara hal-hal yang secara langsung bernilai bagi pengguna dan hal-hal yang diharapkan memberikan nilai tidak langsung. Secara khusus, pendekatan "segala sesuatu yang kita sukai adalah berharga" mendorong pengembang pelapisan emas dan infrastruktur demi infrastruktur. Saya sangat menganjurkan orang hanya menghitung cerita dengan nilai bisnis langsung menuju kecepatan, karena itulah satu-satunya hal yang akan dibayar pelanggan.

— William Pietri

3

Bersantai dengan Beruang. Semua yang Anda lakukan yang benar-benar bernilai sebagian besar berharga karena tidak ada yang pernah melakukannya sebelumnya (jika tidak ada cara lain yang lebih murah untuk menyelesaikannya). Sebagian besar dari apa yang kami lakukan yang berharga adalah tentang mempelajari cara melakukan hal-hal baru. Tugas infrastruktur membantu kami mendapatkan umpan balik tentang hal-hal baru, dan belajar lebih cepat. Saya bersama @Kristo jika itu membantu kami belajar lebih cepat.

— Lunivore

@Lunivore - Perbedaannya adalah tidak ada yang membayar Anda untuk belajar. Mereka membayar Anda untuk apa yang Anda lakukan dengan pembelajaran. Tim harus selalu meluangkan waktu untuk meningkatkan alat dan pengetahuan mereka. Tetapi menghitungnya sebagai kecepatan membingungkannya dengan jenis pekerjaan yang harus dilakukan tim.

— William Pietri

Ini bukan hanya tentang alat dan pengetahuan. Eksperimen pemikiran dari Ashley Johnson: Pikirkan proyek terakhir yang Anda lakukan. Pikirkan tentang berapa lama untuk melakukannya lagi dengan orang yang sama, persyaratan yang sama, teknologi yang sama, tetapi setelah mempelajari semua yang Anda pelajari. Kutipan dari PM berjalan sekitar 25% hingga 33% - sisanya adalah berapa banyak pembelajaran yang kita lakukan dalam proyek perangkat lunak. Baca posting Dan North di Deliberate Discovery: dannorth.net/2010/08/30/introducing-deliberate-discovery

— Lunivore

11

Lakukan secara bertahap.

Jika tidak ada pemangku kepentingan yang menginginkannya, jangan buat cerita. Hanya merawatnya, sedikit demi sedikit. Misalnya, pertama kali Anda menggunakan secara manual. Kedua kalinya, Anda mengotomatiskannya sedikit. Ketiga kalinya, Anda mengotomatisasi sedikit lagi. Akhirnya, bangunan Anda bukan masalah terbesar, jadi Anda fokus pada hal lain.

Anda akan memiliki lebih banyak tugas yang berfokus pada pengembang ini di awal, dan itu bagus; kecepatan Anda (yang diukur dengan cerita) hanya akan lebih rendah. Itu representasi yang tepat dari situasi. Tetapi Anda akan selalu memiliki beberapa, jadi penting bagi tim untuk membiasakan diri melakukan apa yang perlu untuk meningkatkan proses.

— William Pietri
sumber

+1: Solusi Spike pertama kali, lalu refactor menjadi lebih baik dan lebih dapat diandalkan untuk kedua kalinya.

— S.Lott

Jadi, bagaimana Anda memastikan bahwa tugas yang berfokus pada pengembang tidak mengambil alih sprint, terutama ketika Anda belum membuat metrik kecepatan yang baik? Saya tidak ingin ketinggalan pengiriman awal karena kami menghabiskan terlalu banyak waktu untuk hal-hal yang akan membantu dalam jangka panjang.

— Kristo

Dan Anda harus menyediakan waktu untuk refleksi reguler dan melakukan perbaikan proses seperti ini.

— Michael

@ Kristo, saya tidak berpikir pelanggan / manajer produk Anda akan membiarkan Anda lolos begitu saja. Bahkan tanpa kecepatan yang mapan, Anda akan membuat perkiraan yang baik dan menegosiasikan nilai yang akan diberikan untuk sprint pertama tersebut. Ditambah lagi jika Anda spike seperti @ S.Lott menyarankan Anda tidak akan mengirimkannya.

— Michael

@ Kristo: Anda memastikan dengan melakukannya secara bertahap dan berefleksi secara teratur. Ketika Anda memulai, yang Anda tahu adalah bahwa Anda pasti akan melakukan jumlah yang salah. Setiap minggu, bicarakan apakah Anda harus melakukan lebih atau kurang infrastruktur, dan apakah Anda berfokus pada hal-hal bernilai tinggi. Itu selalu merupakan tindakan penyeimbang.

— William Pietri

6

IMHO pendekatan yang ideal adalah menempatkan upaya infrastruktur sebagai tugas di bawah kisah pengguna di mana ia pertama kali memegang nilai; seperti yang telah Anda sebutkan.

Ambil contoh Anda; membangun dan menggunakan secara manual menyiratkan itu adalah upaya yang berkelanjutan dan tidak memiliki bentuk penyelesaian. Itu ada tanpa batas.

Hal yang sama dapat dikatakan untuk kode yang mengotomatiskan setiap bagian dari usaha dalam aplikasi tipikal yang sebelumnya dilakukan secara manual. Mendefinisikan upaya ini sebagai tugas di bawah kisah pengguna mendefinisikan lengkap; yang pada dasarnya memiliki nilai bagi pengguna akhir.

Anda tentu bisa membangun dan menggunakan aplikasi masing-masing dan setiap sprint tetapi itu kemudian menjadi bagian dari tugas sehari-hari yang tidak dilacak secara resmi melalui backlog dan kemudian ini semua menjadi diperdebatkan.

— Aaron McIver
sumber

Terima kasih atas jawaban ini. Akhirnya dijelaskan bagaimana ini harus dilakukan: "pendekatan yang ideal adalah menempatkan upaya infrastruktur sebagai tugas di bawah kisah pengguna di mana ia pertama kali bernilai".

— Igor Popov

Sebenarnya pekerjaan infrastruktur ini harus menjadi bagian dari Definisi Selesai.

— Igor Popov

4

Cerita pengguna menentukan nilai bisnis dari perspektif pengguna. Karena itu tugas infrastruktur umumnya dianggap sebagai "limbah". Bukan berarti mereka tidak perlu. Ini berarti bahwa melakukan lebih banyak tugas infrastruktur akan menghasilkan nilai bisnis yang lebih sedikit. Karena itu, tugas infrastruktur tidak boleh dianggap sebagai penyimpanan pengguna dan tidak boleh dilampirkan ke cerita pengguna apa pun.

Pada rapat perencanaan, tim harus mempertimbangkan tugas infrastruktur apa yang mutlak diperlukan selama sprint berikutnya. Komitmen akan dilakukan dengan tugas-tugas infrastruktur ini dalam pikiran. Ini akan mempengaruhi kecepatan tim yang merupakan hasil yang benar karena kecepatan mengukur seberapa banyak nilai bisnis yang dapat diberikan oleh tim.

— Ladislav Mrnka
sumber

2

Saya tidak pernah menyamakan cerita pengguna dengan keharusan memberikan nilai pengguna akhir. Ini mungkin biasa, tetapi ini bukan cara kami menangani cerita pengguna. Terkadang, jenis tugas ini dianggap lonjakan, tetapi kami juga memiliki kisah pengguna reguler, titik yang diperkirakan sama seperti kisah pengguna lainnya.

— Andy Wiesendanger
sumber

Beberapa tim bekerja seperti itu, tetapi itu membuatnya lebih sulit untuk mengukur nilai yang disampaikan. Secara pribadi, saya sarankan tim hanya membuat cerita yang memiliki nilai bisnis. (Paku memiliki nilai bisnis karena orang-orang produk membeli informasi tentang opsi masa depan dan biayanya.)

— William Pietri

Tapi apa itu nilai bisnis? Ini adalah istilah yang luas, dan apa pun yang memungkinkan bisnis untuk merilis perangkat lunak lebih cepat / lebih baik / dll memiliki nilai untuk bisnis itu.

— Andy Wiesendanger

Perbedaan yang saya gambar adalah antara hal-hal yang bernilai langsung terutama bagi tim, dan hal-hal yang bernilai langsung terutama bagi orang-orang yang benar-benar Anda layani. Saya pikir Anda hanya harus menghitung yang terakhir menuju kecepatan karena itulah satu-satunya nilai yang pada akhirnya penting. Hal-hal yang dilakukan untuk membantu meningkatkan penciptaan nilai diperhitungkan dalam kecepatan melalui peningkatan kecepatan jangka panjang. Menghitungnya segera mendistorsi insentif, dan menghitung-ganda perolehannya.

— William Pietri

2

Dari apa yang saya lihat, banyak infrastruktur yang dianggap sudah diberikan. Ini termasuk hal-hal seperti:

Sistem kontrol revisi;
Sistem pembangunan otomatis;
IDE dan alat pengembang lainnya;
Server pengembangan;
Proses penyebaran; dan
Proses dan standar proyek.

Sebagian besar metodologi yang saya gunakan tidak banyak memberikan perhatian kepada mereka. Ini membentuk apa yang saya sebut Rilis 0. Hal-hal ini harus ada sebelum Anda memulai pengembangan. Setelah Anda mulai mengerjakan cerita, perubahan apa pun dalam hal ini dapat dilacak sebagai peningkatan proses.

Sementara tim pengembangan mungkin memiliki input, sebagian besar dari item ini harus ditangani oleh tim pendukung proyek. Standarisasi barang-barang ini di berbagai proyek harus memiliki pengembalian yang signifikan bagi organisasi.

— BillThor
sumber

1

+1: Jika ini tidak ada, Agile sangat sulit. Infrastruktur dan platform yang stabil dan terbukti merupakan semacam prasyarat untuk kelincahan.

— S.Lott

1

Pertimbangkan yang berikut ini:

Tim Scrum menambahkan fitur utama ke rangkaian produk yang ada.
Ada kebutuhan untuk meningkatkan teknologi / alat / utilitas pengembangan agar tetap terkini berdasarkan praktik terbaik rekayasa.
Masuk akal untuk memuat front rilis dengan karya ini sehingga selama rilis masalah Sprint dapat diselesaikan.
Karena bisnis memperoleh nilai tidak langsung dari item-item ini, saya menyarankan agar untuk kepentingan transparansi ini adalah Product Backlog Items (PBIs).
Tim mengukur barang-barang ini dan memperlakukannya seperti PBI apa pun.

Masalah ini bagi saya bermuara pada kenyataan bahwa saya tidak ingin membuang waktu mencoba mencari cara untuk menyembunyikan pekerjaan ini sebagai tugas di bawah PBI lain yang lebih berpusat pada bisnis.

Saya tidak ingin ukuran PBI condong oleh pekerjaan infrastruktur semacam ini. Saya ingin melihat apa yang sedang dilakukan dan memahami apa yang saya bayar.

Saya juga berpikir ada nilai dalam membuat tim memahami komitmen bisnis yang dibuat dengan berinvestasi pada infrastruktur yang diperlukan untuk memberikan solusi berkualitas.

— Chris
sumber

0

XP ~~merekomendasikan~~ menyarankan memiliki "iterasi nol" di mana semua alat dan infrastruktur diatur. Menulis cerita untuk ini adalah opsional, tetapi mungkin ide yang bagus. Mampu menguji infrastruktur Anda (pengembangan bertahap, pengujian dan penerapan otomatis, pemberitahuan, dll.) Bermanfaat

— Steven A. Lowe
sumber

2

XP tidak merekomendasikan itu. Beberapa orang melakukannya, tetapi ini jelas bukan bagian dari Pemrograman Ekstrim sebagaimana didefinisikan oleh Beck, et al. Secara pribadi, saya pikir Iteration Zero adalah ide yang buruk.

— William Pietri

Masalah lain, Anda tidak selalu mulai dari 0, Anda mungkin menyadari Anda membutuhkan sesuatu sekarang, atau di sprint berikutnya.

— Andy Wiesendanger

@ Willill: lihat "Perencanaan Pemrograman Ekstrim" oleh Kent Beck, Bab 15, halaman 66.

— Steven A. Lowe

Itu bukan rekomendasi. Mereka mengatakan itu ide, dan berkata, "Jika Anda belum pernah bekerja dengan teknologi Anda sebelumnya, pertimbangkan menghabiskan dua minggu untuk mendapatkan teknologi tepat sebelum Anda mulai pemrograman." Dan mereka tidak menyarankan "semua infrastruktur", hanya tes otomatis dasar, bangun, dan gunakan skrip.

— William Pietri

@ William: aha, aku mengerti apa maksudmu. Saya tidak bermaksud semua infrastruktur perangkat lunak , hanya hal-hal yang Anda sebutkan

— Steven A. Lowe

0

Di tim kami, kami melakukan hal berikut:

Asumsikan faktor fokus yang lebih rendah .
Cobalah untuk memasukkan tugas-tugas tersebut ke dalam cerita pengguna yang benar-benar perlu menerapkannya.
Jika beberapa tugas benar-benar diperlukan, tetapi tidak memberikan nilai bisnis langsung (seperti memigrasi tes unit dari satu kerangka kerja ke kerangka kerja lainnya), pada awal sprint kami membuat daftar "tugas kontinu" . Ini adalah tugas yang berhubungan dengan pengembangan yang bukan cerita, tetapi tim pengembangan menginginkannya selesai. Kami daftar tugas-tugas ini di papan tulis kami, masih tetap terpisah dari cerita. Selama sprint, pada setiap pertemuan harian kami meninjau apa yang telah dilakukan untuk menyelesaikannya.

Langkah 2 adalah yang paling penting. Seperti dalam latihan yang gesit, dalam Scrum Anda mencoba melakukan sesedikit mungkin untuk menyelesaikan tugas Anda. Anggap itu sebagai cara untuk tidak menyia-nyiakan hidup Anda untuk melakukan pekerjaan yang tidak perlu: pengalaman saya menunjukkan bahwa sebanyak 50% dari "calon keren" hal-hal yang akhirnya ditinggalkan dan tidak terawat dalam jangka panjang.

— P Shved
sumber