Bagaimana prototyping cepat masuk ke dalam metodologi tangkas?

12

Saya bekerja untuk perusahaan besar, yang menentukan penggunaan proses gesit. Misalnya, untuk proyek kami, kami menggunakan layanan berbasis cloud yang secara khusus ditargetkan untuk mengelola pengembangan yang gesit.

Kelompok teknik spesifik tempat saya bekerja belum secara tradisional mengembangkan perangkat lunak (sebagai gantinya kami membantu mengarahkan proyek dari sudut pandang burung-jauh lebih banyak), tetapi itu berubah. Kami memiliki berbagai proyek perangkat lunak yang akan datang / direncanakan yang sebagian besar data-sentris - misalnya, kami akan melakukan pemantauan data, pengumpulan, pengumpulan, dan beberapa pelaporan. Tugas lain melibatkan otomatisasi dengan perangkat keras khusus dan berbagai jenis arsitektur klien / server (multitier). Saya akan membantu dalam proses mempekerjakan beberapa orang, dan merumuskan banyak rencana kami untuk bergerak maju.

Pertanyaan saya adalah apakah melakukan prototyping cepat (kode sekali pakai) cocok dengan filosofi lincah. Sebagai contoh, saya suka Python dan berbagai paketnya. Saya melihat kemungkinan menerapkan banyak ide kami dengan sangat cepat dengan alur kerja berbasis Python. Namun, saya berpikir bahwa akan ada banyak persepsi bahwa Python tidak "berkualitas perusahaan", dan banyak dari pekerjaan ini perlu ditulis ulang di Jawa atau mungkin C ++.

Namun, membuat prototipe Python akan memberi kita banyak keuntungan untuk memungkinkan kita dengan cepat memberikan hasil nyata.

Apakah Anda dapat memasukkan prototyping cepat - mudah-mudahan dengan Python - ke dalam alur kerja yang gesit di lingkungan perusahaan?

— BobIsNotMyName
sumber

3

Menulis kode membuang adalah hal yang berbahaya untuk dilakukan. Jika berhasil maka mengapa bisnis harus peduli, "buang". Itu selalu terjadi kecuali Anda tidak menunjukkannya kepada mereka. Saya tidak pernah kompromi kualitas kode saya, bahkan ketika saya sudah memasukkan hackathons. Saya mungkin meletakkan hack aneh di sana-sini - tetapi tidak ada yang akan "membuang". Saat membuat prototipe, berkonsentrasilah pada cerita yang membuat demo yang bagus.

— Dave Hillier

3

"perusahaan besar, yang menentukan penggunaan lincah" - campuran kata-kata lucu "mendiktekan" dan "lincah" entah bagaimana mengingatkan saya pada Manifes Agile Setengah-Arsed . Individu dan interaksi lebih dari proses dan alat ... dan kami memiliki proses dan alat wajib untuk mengontrol bagaimana individu-individu (kami lebih suka istilah 'sumber daya') berinteraksi

— agas

11

Konsep "prototyping", sebagaimana dimaksud dalam RAD , agak asing untuk pengembangan tangkas. Ini tidak berarti itu tidak dapat dilakukan, tetapi itu tidak biasa.

Ada beberapa kasus berbeda yang perlu dieksplorasi:

Apakah prototipe itu "cangkang kosong", tiruan atau demo, dibuat untuk memberikan gambaran tentang bagaimana sebuah produk akan terlihat? Anda tentu dapat melakukannya dengan satu atau lebih cerita - namun Anda membangun sesuatu dari imajinasi Anda sendiri, bukan membangun produk dari umpan balik nyata. Orang tidak mengevaluasi demo seperti mereka mengevaluasi suatu produk. Sebagai contoh, lihat umpan balik tentang prototipe batang atas kami versus penerapan batang atas nyata kami .
Apakah prototipe itu sesuatu yang perlu dibangun untuk memahami lebih baik ruang masalahnya? Maka harus ditutup sebagai lonjakan , dan hanya hasilnya disimpan (kode sumber bersifat sementara).
Apakah prototipe versi 0.x? Sebuah produk yang layak mininimum ? Kemudian gunakan proses tangkas pilihan Anda untuk itu. Jika Anda perlu membangunnya kembali dalam bahasa lain, Anda mungkin akan lebih baik jika Anda memperlakukan produk yang berbeda. Perhatikan bahwa kadang-kadang ini diperlakukan sebagai cara pintas penulisan spec ("itu harus melakukan hal yang sama seperti prototipe!"). Itu cara yang sangat buruk untuk mendokumentasikan suatu produk, tetapi ini mungkin lebih baik dijelaskan sebagai pertanyaan dan jawaban terpisah :-)

— Sklivvz
sumber

Saya berpendapat ini adalah jawaban terburuk sejauh ini, saya kesulitan memahami dari mana semua upvote itu berasal. Prototipe untuk mendapatkan umpan balik awal bukanlah hal yang tidak biasa, ini asli untuk pengembangan tangkas.

— Martin Maat

@ MartinMaat Dengan "prototipe" yang Anda maksud "versi awal produk yang dikirim ke pelanggan yang secara bertahap berevolusi dalam produk secara iteratif"? Dalam hal ini, tentu saja, Anda benar bahwa itu asli cara kerja tangkas dan tiga poin yang saya jelaskan menjelaskan caranya. Tapi bukan itu yang orang maksudkan dengan kata itu.

— Sklivvz

8

Bukankah prototyping cepat (yaitu pengembangan iteratif dan inkremental) menjadi semacam inti dari Agile?

Sepertinya Anda mengalami masalah dengan "persepsi adalah kenyataan" di organisasi Anda. Anda mungkin ingin mengingatkan semua orang bahwa Agile tidak berarti "membuang semua rencana," seperti halnya Test-Driven Development berarti "membuang semua arsitektur."

Dan Python bukan (jika pernah ada) bahasa mainan. NASA dan kontraktornya menggunakan Python , dan jika itu cukup baik untuk mereka, itu cukup baik untuk saya.

— Robert Harvey
sumber

Setuju, Python bukan bahasa mainan ... Namun, banyak organisasi di perusahaan saya menggunakan Java secara luas, dan kita perlu berinteraksi dengan kode mereka, dan oleh karena itu merupakan persyaratan bahwa kami membawa orang-orang dengan latar belakang Jawa yang kuat . Plus itu bukan persepsi orang-orang yang memahami perangkat lunak yang menjadi perhatian - persepsi orang-orang yang tidak. Mereka adalah orang-orang yang menginginkan nama yang pernah mereka dengar sebelumnya, dan nama itu adalah "Jawa" ... Saya ingin kami membangun tim yang berkomitmen pada Python sebagai bahasa utama, tetapi itu akan sulit.

— BobIsNotMyName

1

Bahkan jika Anda membuat prototipe dalam Python dan menulis ulang sebagian atau semuanya di Jawa, itu belum tentu buruk (python tidak memiliki profil kinerja yang diperlukan beberapa aplikasi). Setelah "mendengar" suatu bahasa bukanlah suatu dukungan dering. Diberi pilihan, saya pribadi akan memilih beberapa bahasa selain Jawa, tetapi kekuatan lain sering menentukan pilihan bahasa.

— Robert Harvey

@Robert Harvey: "Bukankah prototyping cepat (yaitu pengembangan iteratif dan bertahap) semacam titik Agile?": Sejauh yang saya mengerti, prototyping cepat berarti membuat prototipe yang cepat, dibuang dan, setelah pelanggan telah menyetujuinya, untuk membangun produk nyata (dengan desain yang tepat, dll). Dalam tangkas Anda memiliki kompromi antara keduanya: Anda selalu memiliki prototipe yang secara teknis "cukup baik" (mungkin tidak sebagus sistem yang telah dirancang dimuka, tetapi cukup baik untuk produksi) sehingga dapat dikirim sebagai produk segera setelah pelanggan puas dengannya.

— Giorgio

1

@Giorgio: Tidak apa-apa, tetapi pelanggan tidak tahu apa yang mereka inginkan sampai Anda menunjukkannya kepada mereka dan mereka berkata "tidak, itu bukan yang saya inginkan, saya menginginkan ini. " Apakah Anda melakukan itu dalam kode atau pada selembar kertas tidak ada bedanya dengan saya, selama itu mengidentifikasi apa yang diinginkan pelanggan.

— Robert Harvey

2

Ada praktik yang cukup mapan dalam Pemrograman Ekstrim yang disebut Spike . Ini berarti bahwa itu adalah kode sekali pakai. Tidak ada yang istimewa di dalamnya. Ini hanya Sprint di mana hasil yang diharapkan adalah pengetahuan tentang kode sekali pakai.

Tautan di atas memiliki informasi yang cukup tentang praktik yang baik, perangkap paku.

Kasus penggunaan spesifik Anda tampaknya merupakan contoh yang bagus: dapat membantu merancang antarmuka, memvalidasi utilitas, dan memperlihatkannya kepada beberapa pengguna.

— Borjab
sumber

1

Anda akan membuang kode dan tidak memproduksinya (buat itu menjadi jelas bagi SEMUA ORANG), jadi gesit atau tidak tidak terlalu masalah. Praktik gesit apa pun murni opsional untuk prototipe: sprint, burn-down, pengujian, pemrograman pasangan atau apa pun yang Anda rencanakan untuk digunakan.

Jika Anda terutama akan membangun model fungsional dengan Python untuk membantu pemilik produk dan pembuat keputusan lainnya untuk membuat konsep proyek, Anda tidak perlu siap untuk perusahaan. Namun, jika Anda membuat bukti konsep atau mencoba melihat apakah Anda dapat menangani level kinerja tertentu, Anda mungkin harus tetap menggunakan bahasa produksi. Itu tidak berarti Anda tidak dapat mencobanya dengan Python.

Apa pun yang terjadi, Anda akan membuang kode itu, tetapi memiliki pengetahuan untuk dapat membuat pekerjaan ini bersama dengan rasa yang lebih baik tentang apa yang diinginkan pemilik. Sekarang Anda dapat menggunakan metode apa pun yang Anda inginkan.

— JeffO
sumber

1

Saya akan menambahkan bahwa prototipe sangat penting untuk belajar, dan juga dalam semangat Agile. Jika prototipe memungkinkan Anda untuk belajar, terutama dalam siklus umpan balik yang lebih cepat, maka lakukanlah. Ini semua tentang memaksimalkan pembelajaran dan berbagi pembelajaran dengan tim.

— Melissa
sumber

0

Dalam hal belajar, saya akan menambahkan bahwa prototipe membuat Anda belajar, lebih cepat. Dengan begitu, Anda dapat memvalidasi apakah orang-orang peduli dengan masalah yang Anda coba selesaikan - dan jika solusi yang Anda miliki sesuai dengan apa yang mereka cari - tanpa membuang banyak waktu untuk membangun solusi lengkap yang mungkin , pada akhirnya, tidak menyelesaikan masalah yang cukup menyakitkan atau tidak menyelesaikannya dengan cara yang benar.

— Ethan Teng
sumber

0

Semangat Agile yang sejati adalah tentang interaksi dan komunikasi. Saya akan mengatakan jika prototipe berfungsi dengan baik sebagai alat untuk membantu komunikasi, tidak ada yang salah untuk menggunakannya di dunia Agile. Di tim kami (kami telah berlatih Agile selama lebih dari 5 tahun) kami menggunakannya dari waktu ke waktu. Dan ada beberapa manfaat yang bisa saya lihat dari itu

1) Membantu komunikasi

2) Dapatkan pengguna ke wawancara solusi dan dapatkan umpan balik awal

Peringatan:

Komunikasi langsung antara UX dan insinyur harus TIDAK PERNAH digantikan oleh artefak prototyping. Jika memungkinkan, berpasangan dengan insinyur bekerja jauh lebih baik daripada berkomunikasi melalui mediator (prototipe).

— Huimin
sumber

0

Yang lain telah menyebutkan tujuan pembelajaran paku. Apa yang hilang adalah prinsip gesit yang mendasarinya yang gagal cepat .

Salah satu pilar dalam pengembangan tangkas adalah mengenali bagian-bagian yang sulit dan mencari bukti konsep, lihat apakah Anda bisa melakukannya sama sekali. Cara klasik untuk menyelesaikan semua tugas dalam urutan "logis" mungkin menjadi sangat mahal jika Anda tidak dapat melakukan sesuatu di proyek. Segala sesuatu yang dilakukan sejauh ini bisa sia-sia.

Jika harus berakhir seperti itu, Anda ingin tahu secepat mungkin. Kemudian para pemangku kepentingan dapat memilih untuk hanya berhenti membakar uang sementara belum banyak yang dibakar dan menerima apa yang mereka inginkan tidak layak atau untuk mencoba pendekatan yang berbeda secara radikal terhadap masalah yang akan memiliki peluang baru untuk berhasil. Jika prototipe Anda melayani tujuan ini, itu memang paling gesit.

— Martin Maat
sumber