Bagaimana Anda menangani desain di Scrum?

26

Bagaimana Anda menangani desain di Scrum? Apakah Anda masih memiliki dokumen desain yang ditulis dengan baik untuk setiap iterasi scrum? Apakah Anda hanya membuat catatan desain yang menampilkan diagram UML? Atau apakah Anda hanya memiliki kode komentar yang baik?

Setiap iterasi mungkin melibatkan perubahan desain jadi saya hanya ingin tahu bagaimana orang menangkap ini sehingga pengembang baru memiliki pekerjaan yang mudah untuk memahami domain dan masuk ke papan secepat mungkin.

design scrum

— Seth
sumber

Desain harus ditangani secara bertahap oleh tim, baik sebelum sprint maupun selama. Sebagian besar tim memasukkan penyempurnaan jaminan simpanan sebagai kegiatan berkelanjutan untuk meninjau item jaminan simpanan yang akan datang. Ini adalah waktu yang tepat bagi tim untuk mendesain dan merancang cukup solusi untuk memperkirakan upaya. Setiap artefak yang dibuat harus dilampirkan pada cerita. Selama sprint, arsitektur berbutir lebih halus dan kegiatan desain harus terjadi. Tempelkan artefak ini juga. Ketika cerita selesai, harus ada banyak informasi tentang solusi yang disediakan.

— treefiddy

11

hanya karena itu scrum tidak berarti semuanya mengubah setiap sprint!

Scrum adalah tentang melakukan apa yang perlu (tetapi tidak lebih) . Anda masih perlu melakukan desain dan Anda masih perlu mendokumentasikan. Jumlahnya tidak pasti atau bagaimana melakukannya.

Bagian dari perencanaan setiap sprint adalah memutuskan apa yang perlu dilakukan. Jika sesuatu dalam tumpukan perlu dirancang karena berdampak pada hal-hal lain maka Anda perlu menambahkan tugas khusus untuk proses desain dan melakukannya sebelum tugas implementasi.

— Martin York
sumber

9

Saya punya banyak hal untuk dikatakan tentang topik ini. Saya telah melihat banyak kasus di mana perusahaan / tim / orang mengatakan mereka menggunakan pendekatan Agile untuk perangkat lunak, tetapi pada kenyataannya, mereka ingin memetik hasil yang dijanjikan metode Agile tanpa mematuhi prinsip-prinsip.

Agar iterasi cepat berfungsi, Anda harus melakukan pengembangan yang digerakkan oleh tes (saya berhenti mengatakan Anda harus melakukan TDD dengan enggan). Dalam TDD, tes Anda menyatakan desain dan maksud kode (ketika mereka mengatakan "kode adalah dokumentasi" apa yang seharusnya mereka katakan adalah "tes adalah dokumentasi"). Dengan menulis unit test yang mengekspresikan pemahaman Anda tentang fitur yang ada, Anda secara eksplisit menyatakan apa yang Anda yakini perlu dilakukan oleh kode. Kemudian Anda menulis kode yang melakukannya. Kemudian Anda merevisi kode itu sehingga mematuhi prinsip arsitektur yang baik "Red-Green-Refactor".

Menjalankan pengujian unit Anda dengan setiap checkin (atau bahkan sebelum setiap checkin) memverifikasi bahwa kode baru yang Anda tulis tidak melanggar fungsi yang diharapkan di beberapa area aplikasi lainnya. Ini memberikan jaring pengaman yang memungkinkan Anda untuk mengubah kode dengan mengabaikan tanpa kerusakan. Ketika pemahaman Anda tentang persyaratan yang ada meningkat, Anda dapat memodifikasi tes untuk mencerminkan pengetahuan baru itu. Desain sebenarnya terletak pada tes Unit. Segala sesuatu yang lain (termasuk kode yang tidak tercakup) adalah bohong.

Inilah beberapa bacaan yang direkomendasikan

Ini adalah tempat yang baik untuk mulai mencari cara untuk benar-benar mendekati pengembangan tangkas.

— Michael Brown
sumber

4

@ Murph: Idenya adalah bahwa arsitektur muncul, bahwa Anda harus menemukannya melalui pengujian daripada mendefinisikannya di muka.

— Martin Wickman

5

@ Martin Aku agak melihat - tapi masih ada masalah skala mengerikan di sana. Saya nyaman dengan itu hingga tingkat tertentu tetapi di luar itu ... baik saya kira Anda mungkin harus melakukan itu (atau setidaknya mendapat struktur awal) sebelum Anda sampai pada tingkat pengembangan scrum (di mana orang mungkin mengharapkan tim untuk memperbaiki dan mengembangkan arsitektur tingkat tinggi serta rendah).

— Murph

2

@Murph: Ya bootstrap adalah masalah. Anda harus memilih bahasa pemrograman setidaknya. Persyaratan non-fungsional seperti skalabilitas dan kinerja banyak mempengaruhi arsitektur dan harus diperhitungkan secepatnya. Tapi selain itu saya ingin memulai sesederhana mungkin, kemudian secara bertahap dan iteratif menambahkan fitur kerja (yagni) irisan demi irisan. Fokus pada refactoring untuk menjaga basis kode tetap bersih dan mengekstrak hal-hal sampai desain muncul.

— Martin Wickman

1

Alasan mengapa Scrum berulang adalah karena sifat dasar perangkat lunak berarti kita tidak pernah melakukannya dengan benar pertama kali. Dalam banyak kasus, para pemangku kepentingan tidak tahu apa yang sebenarnya mereka inginkan sampai mereka memiliki sesuatu di depan mereka. Apa yang lebih baik: menghabiskan waktu berjam-jam membuat desain untuk fitur (yang perlu disempurnakan atau kemungkinan besar dibuang ketika karet menyentuh trotoar) dan mengkomunikasikan desain itu ke pelaksana; atau menghabiskan waktu itu menerapkan pass pertama di fitur dan memperbaikinya melalui tes dan refactoring.

— Michael Brown

3

Ngomong-ngomong, Anda tidak akan pernah menyadari nilai TDD yang sebenarnya sampai Anda memiliki tes yang TIDAK TERKENA-MENURUT merah. Itu adalah momen "aha" besar saya dengan TDD. Melihat tes yang baru saja berubah merah, saya menyadari bahwa tanpa tes, bug akan sangat sulit untuk dilacak setelah kode berada di tangan penguji. Jika Anda perlu melihat arsitektur top-down tingkat tinggi, ada banyak alat yang dapat menghasilkan diagram Urutan dan Kelas dari kode Anda. Gunakan mereka untuk mendapatkan laporan foto dan membuangnya karena mereka bukan hukum.

— Michael Brown

2

Scrum adalah metodologi manajemen proyek, bukan metodologi pengembangan perangkat lunak. Scrum biasanya digunakan bersama dengan metodologi Agile. Di situlah letak jawaban Anda.

— Steven A. Lowe
sumber

4

Scrum adalah metodologi yang gesit dan berfokus pada tim pengembangan dan pemegang saham serta mendapatkan pengiriman kode kerja yang berulang. Manajemen proyek top down dan Scrum seperti minyak dan air.

— Michael Brown

1

@ Mike setuju, tapi saya selalu merasa bahwa Scrum adalah metodologi tangkas manajer proyek sementara Extreme Programming adalah metodologi tangkas pengembang. Yang mengatakan, saya telah melihat Scrum diterapkan pada banyak proyek selain perangkat lunak. Menariknya, Wikipedia memberikan definisi Scrum: Scrum ini merupakan metodologi berulang untuk manajemen proyek yang sering terlihat dalam pengembangan perangkat lunak yang tangkas, sejenis rekayasa perangkat lunak: en.wikipedia.org/wiki/Scrum_(development) .

— ahsteele

2

Baru menyadari bahwa saya secara tidak sengaja menurunkan komentar Anda ... tidak bermaksud demikian. Mereka tidak akan membiarkan saya menghapus suara itu kecuali jika Anda melakukan sedikit pengeditan. Saya belum pernah melihat Scrum digambarkan sebagai metode manajemen proyek sebelumnya. Menarik. Yang sedang berkata, saya pikir mengharapkan scrum bekerja untuk perangkat lunak tanpa menerapkan TDD adalah mengapa banyak upaya "melakukan gesit" gagal.

— Michael Brown

1

Tidak ada desain depan sebanyak persyaratan yang sering berubah. Jadi mendesain ke tingkat kelas biasanya membuang-buang waktu. Namun, dapat bermanfaat untuk membuat sketsa keputusan arsitektur tingkat yang lebih tinggi.

Masalah dengan melakukan dokumen desain tugas berat adalah bahwa dokumen tersebut sudah usang segera setelah dibuat. Jadi yang paling berhasil biasanya adalah dokumentasi tingkat tinggi yang tidak mungkin berubah sepenuhnya dalam waktu singkat.

— Vadim
sumber

1

Saya tidak akan mengatakan persyaratan terus berubah. Infact selama sprint persyaratannya statis dan tidak berubah. Setelah setiap sprint, prioritas persyaratan dapat dinilai kembali. Beli tujuan keseluruhan Anda tidak akan berubah.

— Martin York

@Martin poin bagus. Saya kira saya harus mengatakan kembali bahwa mereka berubah dari scrum ke scrum.

— Vadim

1

Scrum adalah model iteratif dan inkremental berdasarkan nilai-nilai lincah . Itu berarti Anda tidak memiliki fase desain terpisah. Idenya adalah Anda harus selalu berurusan dengan desain, sama seperti Anda terus-menerus berurusan dengan analisis, implementasi, pengujian, dan integrasi di seluruh proyek.

Anda perlu sedikit perencanaan agar ini berfungsi. Masukkan rapat perencanaan sprint , di mana tim memperkirakan tugas untuk sprint ke depan. Kebanyakan orang tidak menyadari ini bukan hanya pertemuan estimasi, tetapi juga upaya desain. Misalnya, tugas mungkin "Tambahkan kode untuk model mobil baru". Anda belum dapat memperkirakan ini, Anda perlu tahu lebih banyak. Jadi tim membahas desain dan menghasilkan solusi yang luas ("Mobil subkelas?") Dan menambahkannya sebagai pengingat untuk tugas tersebut. Anda jarang membutuhkan formalitas lebih dari itu. Anda sekarang memiliki ide bagaimana menyelesaikan masalah. Anda belum memiliki semua detail dan itu bagus, Anda cukup tahu desain untuk dapat membuat perkiraan yang nyaman. Tanpa harus membuat diagram sama sekali (pada titik ini).

Untuk dokumentasi fisik yang sebenarnya , saya sarankan untuk membuat diagram ikhtisar sistem di dinding agar dilihat semua orang. Tinjauan umum hanya perlu menyertakan kelas dan modul yang paling penting dan jarang harus diperbarui. Juga, membuat beberapa diagram keadaan untuk kelas paling penting dalam sistem sangat membantu. Taburi dengan beberapa diagram urutan pilih dari kasus penggunaan yang umum untuk memudahkan orang melihat dengan cepat bagaimana semua hal terhubung. Saya berasumsi Anda dapat menghasilkan diagram hierarki kelas dari kode Anda, sehingga masalah itu mudah diselesaikan.

Perhatikan bahwa semua diagram dibuat setelah implementasi aktual. Ini sesuai dengan "perangkat lunak yang berfungsi di atas dokumentasi yang komprehensif" dan desain tepat waktu.

Dan ya, kode yang dapat dibaca jelas merupakan dokumentasi.

— Martin Wickman
sumber

1

Arsitektur keseluruhan proyek dan desain tingkat tinggi akan dilakukan di luar tim scrum ketika pemilik proyek membuat cerita.

Perlu ada cukup desain keseluruhan yang ditulis dalam bentuk apa pun untuk membantu melihat hubungan antara cerita dan harapan pelanggan.

Beberapa desain yang diperlukan untuk setiap cerita akan dilakukan dalam perencanaan dan negosiasi dengan pemilik produk selama perencanaan.

Sebagian besar upaya desain untuk sebuah cerita akan dilakukan dalam sprint.

Jika cerita tidak cukup didefinisikan untuk diperkirakan, maka kotak waktu dapat disisihkan dalam sprint saat ini untuk melakukan pekerjaan desain yang cukup sehingga cerita yang sesuai dapat dibuat untuk sprint selanjutnya.

— Blake
sumber

0

Pemahaman saya adalah bahwa Anda melakukan desain tingkat yang lebih tinggi dengan persyaratan di muka yang Anda kumpulkan di awal proyek. Anda mendokumentasikan desain ini dengan baik.

Kemudian ketika Anda benar-benar mengimplementasikan persyaratan, Anda mengubah desain level bawah sesuai kebutuhan, tetapi Anda menghindari mengubah desain level yang lebih tinggi.

Yah, begitulah dijelaskan kepada saya lima menit yang lalu ...

— indyK1ng
sumber

0

Saat ini ada perpecahan di dalam komunitas Eclipse antara alat UML tradisional yang berfokus pada MDD di mana model mendorong kode / pengembangan dan Omondo yang menganggap bahwa iterasi harus mendorong proses pengembangan dan tentu saja tidak hanya model.

Saya setuju dengan mereka karena MDD adalah omong kosong sementara UML benar-benar cara yang sangat baik karena standar untuk berkomunikasi dengan anggota tim lainnya. teks alternatif

— UML_GURU
sumber