Dalam Scrum, haruskah tugas-tugas seperti pengaturan lingkungan pengembangan dan pengembangan kemampuan dikelola sebagai subtugas dalam cerita pengguna yang sebenarnya?

23

Terkadang dalam proyek kita perlu menghabiskan waktu untuk tugas-tugas seperti:

menjelajahi kerangka kerja dan alat alternatif
mempelajari kerangka kerja dan alat-alat yang dipilih untuk proyek
menyiapkan server dan infrastruktur proyek (kontrol versi, membangun lingkungan, database, dll)

Jika kita menggunakan Cerita Pengguna, kemana perginya semua pekerjaan ini?

Salah satu opsi adalah menjadikannya bagian dari kisah pengguna pertama (mis. Buat beranda untuk aplikasi). Pilihan lain adalah melakukan spike untuk tugas-tugas ini. Opsi ketiga adalah menjadikan tugas bagian dari Masalah / Hambatan (mis. Lingkungan pengembangan belum dipilih) daripada Kisah pengguna.

— Asim Ghaffar
sumber

saya telah mengubah pertanyaan sedikit untuk membuatnya lebih jelas .. pertanyaan sekarang sebagai subtugas dalam cerita pengguna sebenarnya dan bukan sebagai cerita

— Asim Ghaffar

12

Kami memikirkan masalah ini cukup banyak dalam setahun terakhir.

Sementara saya setuju bahwa kerangka dasar harus ada sebelum proyek dimulai, dalam penggunaan praktis dapat menjadi bagian dari proyek itu sendiri. Jadi, Anda harus mengelola entah bagaimana.

Walaupun mencampur pengaturan proyek dengan cerita pengguna mungkin masuk akal kadang-kadang kami telah menyelesaikan tugas - tugas sederhana yang dapat ditambahkan ke tumpukan produk dan mendapatkan perhatian yang sama dengan cerita pengguna. Kita tahu bahwa tugas-tugas teknis ini kadang-kadang diperlukan, tetapi harus dibenarkan dalam hal apa pun. Jika tim berpikir bahwa mereka benar-benar diperlukan untuk mencapai tujuan tertentu, mereka akan menjadi bagian dari sprint.

Sulit mengatakan apa yang paling cocok untuk Anda, jadi cobalah ! Lonjakan mungkin cukup untuk saat ini, tapi saya pikir Anda akan berakhir dengan masalah yang sama nanti, jadi rencanakan ke depan. Lakukan tugas yang merupakan tempat penampung untuk aktivitas semacam itu. Untuk memisahkan tugas dari cerita dua, saya akan dengan cepat membandingkannya berdasarkan pengalaman saya dengan mereka.

Tugas: Tugas adalah kebutuhan teknis. Mungkin hal-hal untuk manajemen konfigurasi atau pengaturan proyek umum, seperti menyiapkan repositori untuk komit, atau menambahkan alat ulasan kode terpanas yang pernah Anda lihat ke proses pengembangan. Tugas harus dipertimbangkan dalam perencanaan, sama seperti kisah pengguna. Jika tim dapat meyakinkan pemilik produk bahwa memiliki alat peninjau kode terbaru dan terhebat meningkatkan kinerja dan meningkatkan komunikasi tim dengan menghilangkan sesi pemrograman pasangan yang tahan lama atau ulasan kode langsung, maka itu akan mendapatkan perhatian pemilik produk.

Cerita : Berfokus pada perspektif bisnis saja, cerita selalu menghasilkan nilai yang terlihat bagi pelanggan. Kualitas internal adalah sesuatu yang sejalan dengan menghasilkan nilai bisnis.

Kami bahkan menetapkan poin cerita untuk tugas-tugas dan kadang-kadang bekerja dengan mereka sama seperti yang kami lakukan dengan cerita.

Pada akhirnya saya akan memilih solusi ini untuk Anda (yang dapat diterapkan secara umum juga):

Pisahkan "pengaturan" dan hal-hal teknis menjadi tugas (hal-hal yang tidak secara langsung menghasilkan nilai bisnis bagi pemilik produk).
Mungkin melakukan lonjakan sebelum penyiapan proyek untuk mendapatkan alat yang paling penting (SCM, alat dev, definisi proses, standar pengkodean dll.)
Terimalah bahwa tugas-tugas ini muncul selama durasi proyek dan rencanakan untuk ini dengan memiliki "jenis" kegiatan yang terpisah selain cerita.

— malte
sumber

Jadi apa yang Anda panggil TASK pada dasarnya adalah benda kerja seperti Cerita pengguna atau Bug? .. Ini bukan TUGAS seperti dalam tugas-tugas dalam cerita pengguna misalnya kode, tes, gunakan dll.

— Asim Ghaffar

2

Ya untuk mendapatkan perbedaan antara yang kami sebut sub-tugas cerita "Aktivitas".

— Malte

Apa yang Anda sebut Tugas pada dasarnya adalah Masalah sesuai MSF untuk Agile 5.0

— Asim Ghaffar

Jika Anda merujuk ke deskripsi ini di sini: msdn.microsoft.com/en-us/library/dd997897.aspx - Anda bisa menyebutnya masalah seperti yang dijelaskan di sana, menurut saya itu pas. Jadi itu akan menjadikannya pilihan Anda nomor 3.

— malte

2

Butir 3 "Terima bahwa tugas-tugas ini muncul selama durasi proyek" sangat penting. Agile Unified Process memiliki gambar hebat yang menunjukkan ini: i.stack.imgur.com/CUVFI.jpg . Perhatikan bahwa disiplin "lingkungan" mereka tidak pernah benar-benar hilang. Perhatikan juga bahwa sebagian besar pekerjaan lingkungan ada di depan. Jadi jika Anda tiba-tiba menemukan bahwa Anda melakukan banyak pekerjaan lingkungan di tahap selanjutnya mungkin ada sesuatu yang salah.

— Michael

4

Lakukan apa pun yang paling masuk akal di perusahaan Anda. Jangan pernah biarkan orang lain melakukan hal-hal yang menjadi penghambat akal sehat.

Tetapi saya akan mengatakan bahwa semua tugas ini terdengar seperti sesuatu yang harus terjadi jauh sebelum Anda memulai pengembangan. Jadi saya mempertanyakan apakah Scrum bahkan relevan dengan tugas-tugas ini. Ada beberapa pemeliharaan yang sedang berlangsung dan semacamnya untuk kontrol sumber dan basis data, tetapi ini seharusnya tidak dijadwalkan, mereka hanya harus menjadi hal-hal yang terjadi dan mempengaruhi kecepatan Anda.

Akan ada saat-saat ketika Anda harus memilih kerangka kerja atau apa pun selama proyek, tetapi ketika saya mengatakan bahwa maksud saya kerangka kerja seperti nHibernate, bukan kerangka kerja seperti .NET. Dalam kasus-kasus itu, penelitian harus dibubuhi spekulasi dan timebox, belum lagi cukup singkat. Cobalah untuk mengelolanya seolah-olah Anda memiliki pengembang yang sakit selama beberapa hari.

Transfer pengetahuan adalah proses berkelanjutan lainnya yang harus dikelola di luar kecepatan perkembangan umum.

— pdr
sumber

ketika saya mengatakan framework .. itu seperti kita harus pergi untuk JSF atau Spring .. atau ketika saya mengatakan tool .. itu seperti kita pergi untuk Jboss atau Glassfish ..

— Asim Ghaffar

1

Saya tidak tahu apa yang Anda maksud "jauh sebelum Anda memulai pengembangan" .. ketika proyek dimulai, tidak boleh sprint 1 mulai ASAP misalnya dalam waktu 2 minggu dari tanggal mulai proyek ... dan dalam sprint 1 ada kode nyata.

— Asim Ghaffar

1

@ AsimGhaffar: Saya rasa tidak seharusnya begitu. Jika Anda mulai membuat kode bahkan sebelum membuat keputusan seperti server aplikasi mana yang akan digunakan, Anda akan membuat setidaknya satu keputusan yang mengharuskan Anda menulis ulang sebagian besar kode itu. Dan saya tidak dapat membayangkan memulai proyek saat ini tanpa pengaturan sumber. Maksudku ok, jika Anda memiliki pengembang duduk-duduk, temukan mereka sesuatu yang produktif untuk dilakukan, seperti prototipe. Tapi jangan langsung masuk ke proyek sampai Anda membuat keputusan kunci.

— pdr

"Tidak boleh sprint 1 mulai ASAP misalnya dalam waktu 2 minggu dari tanggal mulai proyek". Benar. Itu berarti lingkungan Anda sudah siap dan siap untuk digunakan. Anda sudah terampil menggunakan alat, melakukan pembangunan dan penyebaran. Jika Anda belum mahir dalam hal ini dan lingkungan belum siap, maka Anda belum siap untuk memulai.

— S.Lott

@ S.Lott hmm Saya berpikir bahwa seseorang mendapatkan keterampilan yang diperlukan DI ATAS PEKERJAAN yaitu saat bekerja pada proyek dan tidak ada prasyarat alat pembelajaran untuk sprint 1.

— Asim Ghaffar

2

Ada nama untuk membuat keputusan desain sebanyak mungkin di muka sebelum dimulainya "resmi" proyek Anda. Ini disebut air terjun. Tidak ada yang salah dengan cerita pengguna seperti, "Sebagai pengembang, saya perlu memilih kerangka kerja, jadi kami memiliki titik awal untuk situs web." Jika terlalu besar untuk dimasukkan dalam iterasi, coba jabarkan seperti, "Sebagai pengembang, saya perlu mengimplementasikan halaman muka dasar di Drupal, jadi kita akan tahu apakah itu sesuai dengan kebutuhan kita."

— Karl Bielefeldt
sumber

1

Salah satu opsi adalah menjadikan mereka semua bagian dari kisah pengguna pertama, misalnya membuat beranda untuk aplikasi.

Memecah "kisah pengguna" sebagai sebuah konsep. Pengguna apa yang terlibat dalam hal ini? Tidak ada Ini pekerjaan yang seharusnya sudah Anda lakukan.

Pilihan lain adalah melakukan spike untuk ini.

Tidak buruk.

Opsi ketiga adalah menjadikan bagian tugas dari suatu Masalah (mis. Lingkungan pengembangan belum dipilih) daripada Kisah pengguna.

Hampir sama dengan lonjakan sejauh menyangkut perencanaan dan biaya overhead.

Pengaturan bukan kisah pengguna.

Itu yang harus Anda miliki sebelum memulai proyek ini.

Anda tidak dapat benar-benar memulai proyek kecuali Anda memiliki pengaturan kerangka / alat dan server dan siap untuk pergi.

Saya sangat menyadari bahwa banyak organisasi tidak benar-benar ada sampai setelah kontrak ditandatangani. Saya juga sangat menyadari bahwa banyak organisasi tidak memilih teknologi sampai setelah kontrak ditandatangani. Ini semua adalah hal yang tidak efisien yang berada di luar cerita pengguna mana pun.

— S.Lott
sumber

masalah tidak sama dengan Spike .. Pikirkan masalah sebagai item pekerjaan yang dijadwalkan dalam sprint normal tetapi tidak memiliki poin cerita .. Contoh Masalah: SVN tidak dipilih. Saya meminjam kata masalah dari MSF untuk Agile 5.0

— Asim Ghaffar

"Masalah tidak sama dengan lonjakan". Untuk definisi kata-kata, Anda benar. Tetapi ketika Anda berpikir tentang merencanakan kerja ekstra sebelum sprint 1, tidak masalah jika Anda menyebutnya masalah atau lonjakan. Pilih salah satu. Lempar koin. Kepala.

— S.Lott

Sekali lagi saya maksudkan masalah penjadwalan bersama cerita dalam Sprint 1 - bukan sebelum Sprint 1. Jadi untuk Sprint 1 katakanlah kita memilih 2 cerita pengguna dan 1 masalah. Tidak ada poin cerita untuk Masalah ini. Spike memang akan sebelum sprint 1 ..

— Asim Ghaffar

Spike atau Issue tidak masalah. Ini semua pekerjaan yang bukan bagian dari kisah pengguna. Itu semua pekerjaan yang harus dilakukan sebelum sprint pertama. Anda bisa menyebutnya lonjakan atau masalah, apa pun yang membuat Anda bahagia. Tapi ini bukan cerita pengguna.

— S.Lott

1

Di tempat kerja kami menggunakan tugas untuk mempersiapkan lingkungan. Mungkin membingungkan bagi sebagian orang, tetapi tugas yang kami gunakan adalah tugas yang sama dengan tugas dari kisah pengguna. Tugas tersebut bukan milik cerita pengguna tetapi diperkirakan dalam hitungan jam dan harus disetujui oleh pemilik produk untuk diselesaikan dalam sprint tertentu.

Kami juga menggunakan tugas untuk pekerjaan arsitektur yang tidak memiliki nilai bisnis "nyata" tetapi itu menambah kualitas produk terutama untuk produk yang sudah ada dengan basis kode yang besar.

Ini mungkin tidak berlaku di lingkungan kerja Anda tetapi itu bekerja dengan baik untuk kami.

— Chris Chou
sumber

0

Saya pikir Anda mencampur dua hal independen. Kisah pengguna tidak boleh menyertakan detail teknis apa pun.

Pilihan kerangka kerja, pengaturan repositori dan server, dan tugas-tugas lain, harus masuk ke iterasi awal.

— BЈовић
sumber

Anda benar dan saya tidak menyarankan mereka dalam deskripsi cerita .. apa yang saya maksudkan adalah untuk memiliki tugas-tugas seperti "instal MySQL", "evaluasi kerangka kerja" sebagai bagian dari kisah pengguna yang sebenarnya pertama .. yaitu Sebagai pengguna yang saya inginkan beranda sehingga saya memiliki akses cepat ke fitur-fitur penting.

— Asim Ghaffar

@ AsimGhaffar Itu bisa dilakukan di iterasi awal. Bukan sebagai cerita pengguna, karena pengguna tidak perlu tahu (atau mereka harus peduli) teknologi apa yang Anda gunakan untuk memenuhi kebutuhan mereka.

— BЈовић

0

Saya mengikuti kursus Scrum baru-baru ini dan instruktur menyarankan agar sprint khusus yang disebut Sprint 0 harus digunakan untuk menyelesaikan masalah-masalah seperti ini. Ada orang-orang di lapangan dengan berbagai tingkat pengalaman di Scrum dan hampir semua orang yang berpengalaman setuju, mengatakan bahwa mereka melakukan hal yang sama. Dalam beberapa kasus, perusahaan menggunakan Sprint 0 untuk mengevaluasi proyek dan memutuskan apakah layak atau tidak.

Bagi seseorang yang baru mengenal metodologi Scrum seperti saya, sepertinya ini adalah solusi yang fantastis karena membuat Anda bebas dari cerita pengguna dan semua aspek lain dari sprint normal seperti umpan balik pengguna.

Karena Sprint 0 memiliki waktu yang sama dengan sprint Anda yang lain, sprint ini berfungsi sebagai cara untuk memastikan Anda tidak menghabiskan terlalu banyak waktu untuk mengatur sesuatu karena mereka selalu dapat di-tweak kemudian. Poin utamanya adalah membuat diri Anda dalam keadaan di mana Anda dapat benar-benar mulai mengembangkan produk.

— Stuart Leyland-Cole
sumber

3

Mengutip Alistair Cockburn Saya memiliki perasaan menyelinap bahwa seseorang ditekan tentang penggunaannya Scrum ketika dia melakukan sesuatu yang tidak memiliki nilai bisnis yang jelas di awal, dan dia menemukan "Oh, itu Sprint Zero!" untuk mendapatkan para petani dengan kapak menjauh dari ambang pintu.

— Asim Ghaffar

0

menjelajahi 2-3 kerangka / alat alternatif

Terkadang ini bisa terjadi jika Anda memiliki persyaratan khusus, Anda harus melakukan beberapa POC untuk memilih alat terbaik untuk menyelesaikan persyaratan. Inilah gunanya lonjakan karena tanpa mengetahui kerangka mana yang akan Anda gunakan, kemungkinan besar Anda tidak dapat memperkirakan cerita dan menyimpannya tanpa perkiraan tidak dapat direncanakan dan dibagi menjadi beberapa tugas.

kemudian mempelajari kerangka kerja yang kita pilih untuk proyek tersebut

Baik. Ini sangat berbahaya. Ketika pelanggan membayar Anda untuk SW, ia mengharapkan bahwa Anda adalah profesional yang sudah tahu cara menggunakan alat-alatnya. Pelanggan tidak membayar Anda untuk pembelajaran atau pendekatan pengembangan percobaan / gagal. Pengembang bertanggung jawab untuk mempelajari alat-alat baru di waktu luangnya atau dalam waktu yang dialokasikan khusus yang dibayarkan oleh karyawannya bukan oleh pelanggan. Menghabiskan uang pelanggan untuk belajar tanpa memberi tahu pelanggan tidak profesional.

Jika Anda benar-benar harus menggunakan sesuatu yang istimewa (misalnya API pelanggan atau alat pelanggan yang dipilih) yang tidak pernah Anda gunakan sebelumnya, Anda harus memberi tahu pelanggan bahwa harga akan dinaikkan saat waktu yang diperlukan untuk mempelajari cara menggunakan API. Mungkin pelanggan akan berubah pikiran jika kenaikan harga terlalu besar.

Tentu, maksud saya bukan situasi di mana Anda harus mencari beberapa masalah baru tertentu dalam kerangka yang telah Anda gunakan berkali-kali. Maksud saya situasi di mana Anda mulai menggunakan API atau kerangka kerja baru tanpa menghabiskan waktu yang signifikan (di luar proyek) untuk belajar.

Jika Anda melanggar ini, itu akan tetap terlihat dalam kecepatan Anda karena Anda akan memberikan jumlah bisnis yang sangat kecil per iterasi. Jika pelanggan tidak mengetahui alasannya, ia kemungkinan besar akan membatalkan proyek.

Ini masih berlaku untuk proyek internal - Anda harus memberi tahu manajer / bisnis Anda tentang waktu yang diperlukan untuk mempelajari API atau alat baru. Biasanya memiliki konsekuensi yang sangat buruk jika manajer menghitung dengan produktivitas normal Anda dan produktivitas Anda hanya sebagian kecil karena API baru yang Anda coba pelajari selama tugas Anda. Itu jelas bahkan lebih buruk jika beberapa orang penjualan dihitung dengan produktivitas normal ketika menandatangani kontrak dengan pelanggan.

tentang pengaturan server (SVN, Database, dll)

Itu adalah infrastruktur dan biaya internal Anda. Ketika Anda memulai proyek ini, diharapkan infrastruktur Anda sudah siap. Menyiapkan lingkungan pengembangan Anda tidak memiliki nilai bagi pelanggan dan tidak boleh menjadi bagian dari indikator terkait proyek apa pun - misalnya kecepatan di Scrum. Saya melihat ini diimplementasikan sebagai iterasi pra-proyek khusus yang digunakan hanya untuk pengaturan lingkungan, membuat infrastruktur dasar dll.

— Ladislav Mrnka
sumber

Kami ke dalam pengembangan produk bukan proyek pelanggan :).

— Asim Ghaffar

Baik. Dalam hal ini, Anda masih harus secara terpisah melacak waktu yang dihabiskan untuk pembelajaran dan infrastruktur untuk melihat overhead yang Anda miliki. Menyembunyikan waktu ini di dalam tugas akan merusak visibilitas proses pengembangan Anda.

— Ladislav Mrnka