Apa yang Anda hasilkan dalam beberapa iterasi pertama di Agile?

22

Seperti yang saya mengerti, ide dengan metodologi Agile adalah bahwa Anda memberikan sesuatu yang fungsional dan Anda sering memberikannya. Aplikasi masuk ke kenaikan bentuk akhirnya setelah penambahan.

Tetapi dalam iterasi awal Anda mungkin membangun kerangka kerja atau fondasi di mana aplikasi akan berdiri sehingga itu sesuatu yang penting tetapi tidak terlihat oleh pengguna.

Apa yang dikirim ke klien dalam iterasi pertama ini? Bagaimana Anda menunjukkan kemajuan ke arah yang benar ketika Anda membangun kode perancah?

— JohnDoDo
sumber

2

Membangun seluruh kerangka kerja atau yayasan harus merupakan keputusan yang dibuat selambat-lambatnya dalam proyek.

— JeffO

@ Jeffoff: apa maksudmu selambat mungkin? Bisakah Anda mengembangkannya menjadi jawaban?

— JohnDoDo

5

Idealnya, itu sama sekali bukan keputusan. Suatu kerangka kerja seharusnya tidak dibuat, itu harus muncul secara organik sebagai hasil dari refactoring. Tidak ada kerangka kerja "baik" (untuk definisi subyektif saya sendiri tentang "baik") yang dirancang dari awal, mereka baik diekstraksi setelah fakta dari aplikasi yang ada atau berdasarkan pada kerangka kerja lain yang ada.

— Jörg W Mittag

7

@JohnDoDo membangun fondasi di muka mengasumsikan Anda tahu apa persyaratan aplikasi Anda sebelum itu ada. Setiap kali saya melihat orang melakukan ini, mereka berakhir dengan sesuatu yang kaku dan sangat sulit untuk dikerjakan. Lebih sering daripada tidak, para pengguna "kerangka" itu akhirnya bertarung lebih daripada memeluknya.

— Stefan Billiet

15

Biasanya memiliki sprint 2 minggu.

Bagi saya, sprint pertama atau 2 kemungkinan akan memiliki lebih sedikit fitur "terlihat" daripada sprint kemudian untuk alasan yang tepat ini (untuk beberapa deskripsi lemah "kurang").

Yang sedang berkata, tentu saja Anda tidak perlu 2 minggu untuk membangun seluruh perancah Anda dan tidak ada yang terlihat di UI untuk ditampilkan.

Mungkin Anda tidak menyempurnakan setiap item perancah di sprint pertama atau 2. Mungkin bagian bisa menunggu dan ditambahkan nanti.

Mungkin sprint pertama Anda memiliki "Buat halaman web X dengan data dummy" sehingga Anda bisa mendapatkan sesuatu yang mengkilap untuk ditampilkan kepada pelanggan Anda. Dan kemudian sprint berikutnya memiliki "Ubah halaman web X untuk menggunakan data dari database".

— ozz
sumber

6

+1 untuk paragraf terakhir - merupakan ide bagus untuk memulai pengembangan dengan prototipe yang ditujukan untuk validasi pengguna.

— Konamiman

4

"Mungkin sprint pertama Anda memiliki" Buat halaman web X dengan data dummy "sehingga Anda bisa mendapatkan sesuatu yang mengkilap untuk menunjukkan kepada pelanggan Anda.": IMO tergantung pada pelanggan dan pada skala waktu proyek: Untuk proyek 2 bulan, pelanggan dapat ingin melihat sesuatu dalam 1 minggu atau 2. Untuk proyek 18 bulan, orang mungkin OK untuk mendapatkan demo pertama dalam 1 atau 2 bulan. Bagaimanapun, sementara beberapa pelanggan mungkin ingin melihat halaman dummy, yang lain mungkin ingin melihat sesuatu yang lebih bermakna dan mendapatkan perasaan Anda membuang-buang waktu mereka. Saya pikir Anda tidak dapat menggeneralisasi.

— Giorgio

4

+1, tetapi selalu, selalu menjaga rahasia gunung es dalam pikiran ketika menunjukkan bagian UI kepada pelanggan Anda joelonsoftware.com/articles/fog0000000356.html

— Doc Brown

1

@MatthewFlynn - Scrum mungkin tidak memiliki fase "persyaratan" yang sebenarnya, tetapi itu tidak berarti ada persyaratan NOL atau dokumentasi yang tersedia. Saya tidak pernah terlibat dengan sebuah proyek di mana seorang pelanggan berkata "silakan saja dan mulai membangun dan kami akan mencari tahu di sepanjang jalan". Saya pikir ada istilah untuk itu. Biasanya harus ada semacam fase elisitasi proyek yang mencakup beberapa diskusi dan kesepakatan tentang apa yang akan disampaikan. Saya telah mempresentasikan prototipe selama promosi penjualan

— hanzolo

1

@hanzolo - Proyek yang sangat sukses yang saya kerjakan baru-baru ini melibatkan penerapan solusi untuk menangani persyaratan hukum baru yang merupakan bagian dari Undang-Undang Perawatan Terjangkau. Persyaratan dasar sudah diketahui, ya, tapi tidak ada prototipe atau desain di tempat seperti apa solusinya. Tim proyek (yang termasuk analis bisnis) menemukan jawabannya dalam konteks sprint. Paling-paling, BA akan berbicara dengan orang-orang bisnis tentang cerita sprint atau dua di depan seluruh tim, tapi hanya itu yang harus kita kerjakan. Itu bekerja dengan baik.

— Matthew Flynn

13

Agile Manifesto menyarankan bahwa Perangkat Lunak yang Bekerja lebih berharga daripada dokumentasi yang komprehensif, dan kerangka kerja Scrum mengambil gagasan ini untuk menyarankan bahwa memberikan perangkat lunak yang telah teruji dan berfungsi dengan nilai bisnis menjadi persyaratan setiap sprint.

Mengapa? Ya, antara lain, desainer dan pengembang sering menjadi korban menghabiskan banyak waktu untuk barang-barang YNNI (Anda tidak akan pernah membutuhkannya). Sayangnya, kerangka kerja yang Anda bicarakan seringkali merupakan tanggung jawab besar dalam bidang ini. Pengembang mulai membangun semua hal yang harus didukung oleh kerangka kerja dan tiba-tiba Anda berusia 3 bulan dan tidak memiliki nilai bisnis apa pun untuk ditampilkan. Kemudian ternyata kerangka itu bahkan tidak benar-benar mendukung apa yang mereka butuhkan.

Jadi pendekatan yang disarankan adalah membangun hanya apa yang sebenarnya dibutuhkan sekarang, dan mengirimkannya sekarang.

Ini BUKAN berarti Anda tidak dapat membangun bagian yang dapat digunakan kembali dan sejenisnya, Anda hanya selalu melakukannya untuk mendukung pembangunan kebutuhan saat ini. Selain itu, itu tidak berarti Anda harus benar-benar memakai penutup mata untuk apa yang akan terjadi - jangan membangun sesuatu sehingga tidak mungkin untuk mengubah / meningkatkannya nanti. Tetapi kuncinya adalah selalu memberikan nilai bisnis.

Sering ada beberapa hal penting yang benar-benar perlu ditetapkan sebelum apa pun dapat disampaikan, seperti pengaturan lingkungan dan sejenisnya. Untuk hal-hal ini, banyak tim merasa berguna untuk memiliki "Sprint 0" di mana landasannya diletakkan. Sprint 0 bisa menjadi sedikit lebih lama dari sprint Anda yang lain, karena tidak berlaku untuk jaminan simpanan produk Anda atau burn-down, tetapi sprint itu masih harus dikotak-kotak hingga durasi yang masuk akal.

— Matthew Flynn
sumber

8

Apa yang dikirim ke klien dalam iterasi pertama ini?

Apa yang memiliki nilai bisnis tertinggi bagi pengguna. Misalnya, jika aplikasi memiliki aturan bisnis yang kompleks, iterasi pertama hanya akan berisi aturan bisnis yang disandikan dalam bentuk kode. Pelanggan harus puas selama Anda memiliki kode untuk aturan bisnis tersebut. (Masalah yang sebenarnya meyakinkan pelanggan untuk menerima hal seperti itu adalah masalah yang sama sekali berbeda.) Misalnya, Anda dapat menunjukkan kepada pakar bisnis pelanggan unit Anda / tes penerimaan yang menyatakan apa yang harus dilakukan domain dan kode yang lulus dengan hasil hijau. Atau bahkan lebih baik, buat pakar bisnis membantu membuat tes itu.

Ada juga pertanyaan tentang

Anda mungkin membangun kerangka kerja atau fondasi

Yang saya percaya jauh lebih penting daripada apa yang sebenarnya disampaikan. Ada hal besar bagi Desain Evolusi , yang mengatakan, bahwa Anda harus membuat arsitektur dari waktu ke waktu alih-alih mencoba membuatnya di awal. Adapun dasar, ini biasanya berarti semacam database atau kerangka UI. Dalam hal ini, ada gagasan " Arsitektur yang baik adalah arsitektur yang memungkinkan Anda menunda keputusan penting ." Dan memilih basis data atau UI adalah keputusan penting. Sebagai contoh, Anda mungkin baik-baik saja dengan hanya penyimpanan di memori untuk data alih-alih mencoba menggunakan DB dari iterasi pertama.

— Euforia
sumber

3

Apa yang kami coba lakukan adalah memberikan dalam iterasi pertama aplikasi paling sederhana yang mungkin (versi dunia halo dari apa yang kami kirimkan). Kami melihat 3 manfaat penting dalam hal ini:

Atur prosedur pengiriman (selalu menjadi salah satu bagian tersulit) (dapatkan lingkungan, server ada, perbarui keamanan untuk lingkungan ini). Karena kami akan sering mengirimkan, penting untuk mendapatkan ini secepat mungkin.
Beri pengguna pandangan pertama tentang bagaimana rupa aplikasi itu. Ini membantu pengguna dan pengembang untuk memahami apa yang sebenarnya mereka inginkan dan butuhkan.
Punya ide dasar tentang bagaimana arsitektur aplikasi akan terlihat (aplikasi harus mencakup 'lapisan' dasar atau komponen aplikasi).

— pengguna99561
sumber

"Mengatur proses pengiriman" jauh lebih sulit daripada yang dipikirkan orang.

— Frank Shearar

Ya itu. Itu sebabnya Anda harus melakukan ini sedini mungkin.

— user99561

2

Tetapi dalam iterasi awal Anda mungkin membangun kerangka kerja atau fondasi di mana aplikasi akan berdiri sehingga itu sesuatu yang penting tetapi tidak terlihat oleh pengguna.

Ini salah, karena Anda tidak perlu membangun kerangka kerja yang dapat Anda gunakan di masa depan. Idenya adalah membangun hanya apa yang dibutuhkan (lihat juga YAGNI ).

Dalam sprint zero, Anda harus bersiap untuk pekerjaan yang sebenarnya. Banyak orang berdebat apa yang harus dilakukan dalam sprint ini, tetapi menurut saya, itu selesai ketika Anda dapat mulai mengerjakan item-item di backlog. Langkah ini termasuk pengaturan PC, pengaturan proses build, memilih kerangka kerja, dll.

Ketika Anda selesai dengan sprint zero (atau iterasi nol), Anda dapat mulai mengerjakan aplikasi Anda. Ambil item dari backlog, dan selesaikan satu per satu. Setelah Anda menyelesaikan iterasi satu, Anda akan memiliki sesuatu yang bermanfaat. Iterasi pertama biasanya mencakup beberapa fitur yang paling penting.

Apa yang dikirim ke klien dalam iterasi pertama ini? Bagaimana Anda menunjukkan kemajuan ke arah yang benar ketika Anda membangun kode perancah?

Setelah iterasi nol, jelas Anda tidak memiliki apa pun untuk dikirim. Hasil datang setelah iterasi satu. Ini berisi fitur yang Anda tetapkan untuk iterasi.

Jika pertanyaan Anda adalah "bagaimana memilih apa yang masuk ke dalam iterasi X?", Maka lihatlah videocast ini (video untuk iterasi 0 A dan bagian dari B).

— BЈовић
sumber

+1 untuk menjadi satu-satunya yang menyebutkan iterasi nol

— crad

Saya tidak mempertimbangkan pengaturan proses build dan memilih tugas framework untuk sprint zero. Bagaimana Anda bisa tahu kerangka mana yang Anda butuhkan jika Anda tidak tahu apa yang harus dibangun? Saya selalu membatasi sprint 0 hingga minimum. Dapatkan PC orang dan temukan ruang di mana mereka bisa duduk. Cari tahu dengan siapa Anda perlu berbicara dari bisnis. Atur rapat perencanaan pertama. Saya menerapkan YAGNI ke yang lainnya.

— user99561

@ user99561 Kerangka kerja adalah keputusan besar, dan biasanya sulit diubah. Misalnya, Anda harus tahu apakah Anda akan menggunakan gtest atau cppunit untuk pengujian unit sebelum mulai menulis kode. Mengubahnya nanti akan sangat menyebalkan dan banyak waktu terbuang.

— BЈовић

@ BЈовић: Ya kerangka kerja adalah keputusan besar, itu sebabnya Anda harus menunda keputusan itu. Tidak ada gunanya memutuskan kerangka kerja jika Anda tidak tahu apa yang perlu dikembangkan dan bagaimana rupa aplikasi dan arsitekturnya. Anda harus memutuskan kerangka kerja apa yang akan digunakan pada saat terakhir yang memungkinkan. Kalau tidak, Anda pasti menjalankan risiko bahwa Anda harus mengubahnya.

— user99561

@ user99561 Jika Anda tidak tahu apa yang perlu dikembangkan, maka Anda bahkan tidak dapat memulai :) Persyaratan dan cerita pengguna harus ditulis, jika tidak, iterasi 1 bahkan tidak dapat memulai.

— BЈовић

2

Anda dapat memberikan hampir semua yang Anda inginkan. Gagasan membangun infrastruktur sama sekali salah / tidak gesit / tidak berkelanjutan.

Misalnya: membangun aplikasi Hello World yang berfungsi penuh dapat dibangun dalam hitungan jam. Membawa server (bahkan sementara) di cloud atau sebagai VM dapat dilakukan dalam hitungan jam.

Ini sudah cukup untuk mulai berkembang . Kemudian, jika Anda membutuhkan CI, Anda dapat menambahkan cerita CI, jika Anda membutuhkan server fisik, tentu saja, tambahkan cerita untuk itu.

Tapi mulailah mengirim pada Hari 1 dan tidak pernah berhenti!

— Sklivvz
sumber

1

Iterasi awal, terutama yang pertama, akan berisi atau setidaknya harus merencanakan lonjakan arsitektur, yang mencakup sejumlah waktu penemuan dan mungkin beberapa prototipe arsitektur.

Seperti yang Anda katakan, secara umum, ada persyaratan struktural yang mungkin tidak banyak berarti bagi pemangku kepentingan / pelanggan, tetapi diminta untuk membentuk platform atau orientasi pola yang kuat. Anda tidak dapat menyiasatinya karena Anda tidak dapat mulai membangun B hingga A selesai.

Bagian dari pendekatan Agile adalah membuat pelanggan tutup sehingga dokumentasi tidak diperlukan karena yang perlu Anda lakukan hanyalah mengangkat telepon / mengirim email, dan itu diharapkan. Harapan pelanggan harus ditetapkan dengan tepat dan setiap pekerjaan yang diselesaikan harus sangat singkat dan DIPERLUKAN . Tidak ada pelapisan emas, tidak "Anda mungkin membutuhkannya", dll. Bangun apa yang Anda butuhkan dalam A untuk pindah ke B.

Bergantung pada bagaimana Anda menyerang proyek, Anda hanya dapat membangun fondasi yang diperlukan untuk menyelesaikan modul tertentu, sehingga selama pertemuan perencanaan sprint Anda akan menyusun rencana untuk sprint saat ini berdasarkan prioritas yang ditetapkan oleh pelanggan, tergantung pada apa yang diperlukan untuk sprint itu, mungkin ada beberapa persyaratan mendasar, jadi itulah yang masuk ke dalam sprint 1. Setelah sprint 1 selesai dan A telah dibangun dan kemudian berencana untuk menyelesaikan B.

Jika Anda telah menyetujui timeline dengan pelanggan, selama Anda akan memenuhi perjanjian itu, pelanggan mungkin tidak akan peduli apa yang Anda lakukan 1 atau 2. Anda selalu bisa menunjukkan hasil unit test kepada mereka, tetapi jika Anda mengatakan kami akan memiliki sesuatu untuk Anda lihat setelah sprint 2 (atau 3), dan Anda memberikannya, itu akan menjadi prioritas utama. Pelanggan diharapkan masuk akal seperti halnya pengembang dan keduanya bekerja menuju tujuan yang sama. Proyek yang selesai yang memenuhi kebutuhan pelanggan dan berfungsi seperti yang diharapkan. Jadi khawatir bahwa tidak ada yang bisa dilihat setelah sprint 1 adalah titik diperdebatkan karena pelanggan hanya ingin memastikan bahwa setelah sprint 20, proyek akan selesai (-ish).

— Hanzolo
sumber