Bagaimana cara mengembangkan perangkat lunak yang sangat baik dengan metode gesit?

The model Kano kepuasan pelanggan mendefinisikan kelas yang berbeda dari fitur produk. Diantaranya adalah

1. Kualitas must-be: Jika ini tidak diterapkan pelanggan tidak akan menerima produk.

2. Kualitas menarik (kesenangan): Fitur yang sering tidak diharapkan oleh pelanggan, tetapi menimbulkan kegembiraan dan kesenangan saat ditemukan.

Kualitas yang menarik jelas memiliki banyak nilai bisnis. Mereka membuat orang membeli Ferrari seharga 500.000 ketika Fiat bekas dengan harga kurang dari 5.000 akan memenuhi semua persyaratan yang harus dipenuhi.

Namun, semua proses gesit yang saya tahu sangat mendukung persyaratan yang harus ada. Ini selalu mendapatkan prioritas tertinggi. Tampaknya tidak ada tempat untuk kualitas menarik dalam tangkas.

Saya percaya bahwa proses gesit sangat berguna dalam pengembangan perangkat lunak. Tetapi bagaimana mereka dapat diterapkan untuk menciptakan produk perangkat lunak berkualitas tinggi yang menyenangkan dan bukan hanya minimum yang hampir tidak memenuhi persyaratan yang harus dipenuhi?

Tambahan: Seperti yang ditunjukkan oleh dua jawaban pertama, masuk akal untuk memberikan persyaratan yang harus menjadi prioritas tertinggi. Tetapi apakah kita (dan pelanggan) benar-benar selalu tahu sebelumnya apa persyaratan yang harus dipenuhi. Saya telah membuat pengalaman beberapa kali bahwa persyaratan yang diberikan prioritas tinggi pada awalnya, ternyata jauh lebih penting, jika tidak sia-sia, nanti. Oleh karena itu saya percaya seseorang tidak boleh secara sembrono fokus pada persyaratan yang harus dipenuhi.

Jawaban resmi adalah Anda salah paham lincah, lincah tidak mendikte persyaratan, pemangku kepentingan lakukan. Inti dari lincah bukanlah mengukir persyaratan Anda di atas batu tetapi meminta mereka muncul saat Anda pergi, dalam kontak dekat dengan klien Anda, mendapatkan manfaat dari wawasan progresif.

Tapi itu semua teori. Apa yang Anda saksikan memang sifat umum dari banyak jalur produksi perangkat lunak yang mengadopsi cara kerja yang gesit.

Masalahnya adalah, mendengarkan pelanggan dan dengan cepat menanggapi kebutuhan pelanggan sering kali berakhir dengan tidak memikirkan produk atau melakukan desain sama sekali. Apa yang dulunya merupakan proses proaktif yang diumpankan oleh visi dan keahlian dapat dan seringkali akan memburuk menjadi proses yang sepenuhnya reaktif yang digerakkan oleh keinginan pelanggan. Ini akan mengarah pada hanya membuat kebutuhan kosong yang "akan melakukan pekerjaan".

Mobil tidak akan pernah ditemukan jika pabrik pada saat itu akan "gesit" karena semua pelanggan meminta adalah kuda yang lebih cepat.

Ini tidak membuat tangkas buruk. Itu agak seperti komunisme. Ide bagus yang hampir tidak pernah berhasil dengan baik karena orang hanya orang, melakukan hal-hal orang. Dan metode / ideologi / agama menidurkan mereka ke dalam gagasan bahwa mereka melakukan dengan baik selama mereka melalui gerakan dan / atau mengikuti aturan.

[sunting]

Slebetman:

Sungguh ironis kemudian bahwa lincah berevolusi dari industri automatif (yaitu Toyota).

Ingat aturan emas otomatisasi? "Pertama mengatur, lalu mengotomatisasi". Jika Anda mengotomatiskan proses yang rusak, hal terbaik yang bisa terjadi adalah Anda mempercepat semua yang salah. Orang-orang di Toyota bukan idiot.

Alasan khas untuk mengadopsi metodologi baru adalah bahwa semuanya tidak berjalan dengan baik. Manajemen mengakuinya, tetapi mereka mungkin tidak memahami masalah inti. Jadi mereka mempekerjakan guru yang memberikan pidato tangguh tentang Agile dan Scrum. Dan semua orang menyukainya. Untuk alasan mereka sendiri.

Para pengembang mungkin berpikir, "Hei, ini mungkin berhasil. Kami akan lebih terlibat dengan masalah bisnis dan kami dapat memberikan masukan untuk mengisi simpanan ini. Ini bisa menjadi peluang untuk membuat penjualan dan layanan pelanggan memahami apa yang kami lakukan, mengapa perlu, dan kita akan mengeluarkannya dari rambut kita sementara kita secara transparan membakar apa yang kita sepakati. " Tidak ada lagi "hentikan apa yang Anda lakukan, ini perlu dilakukan sekarang" oleh beberapa pria Anda tidak ingin menunda muncul di meja Anda.

Penjualan, layanan pelanggan atau pemilik di sisi lain dapat melihatnya sebagai cara untuk mendapatkan (kembali) kontrol atas kotak hitam departemen ini yang mungkin melakukan hal-hal yang diperlukan. Mereka tidak melihat apa yang terjadi di sana, tetapi mereka cukup yakin inti masalahnya terkubur di suatu tempat di sana. Jadi mereka memperkenalkan Scrum, memasang pemilik produk pilihan mereka dan tiba-tiba mereka memiliki kontrol semua, semua string ada di tangan mereka. Sekarang apa? ... Ehrr ...

Masalah sebenarnya sering bahwa toko itu tidak terorganisir dengan baik sejak awal dan ini tidak berubah. Orang-orang telah diberi tanggung jawab yang tidak dapat mereka tangani, atau mungkin mereka bisa tetapi Tn. Boss terus-menerus mencampuri dan merusak apa yang mereka lakukan, atau (paling sering menurut pengalaman saya), tanggung jawab penting belum diakui atau diberikan kepada siapa pun.

Kadang-kadang seiring waktu suatu organisasi informal akan muncul di antara garis formal. Ini kemudian dapat mengimbangi kurangnya struktur formal. Beberapa orang akhirnya melakukan apa yang mereka kuasai, apakah mereka memiliki kartu nama untuk membuktikannya atau tidak. Pengenalan Agile / Scrum yang tumpul dapat merusaknya secara instan. Karena orang sekarang diharapkan untuk bermain sesuai aturan. Mereka merasa apa yang biasa mereka lakukan tidak dihargai, mereka mendapatkan kertas-kertas kuning kecil dengan cerita-cerita kecil sebagai gantinya, pesannya adalah: "apa pun yang Anda lakukan, tidak ada yang peduli". Tidak perlu dikatakan bahwa ini tidak akan memotivasi orang-orang itu. Mereka akan mulai menunggu pesanan dan tidak mengambil inisiatif lagi.

Jadi segalanya menjadi lebih buruk dan kesimpulannya adalah Agile menyebalkan.

Agile tidak payah, itu bagus untuk proyek pemeliharaan dan bahkan bisa baik untuk pengembangan baru jika diterapkan dengan hati-hati tetapi jika orang yang salah tidak memahaminya atau mengadopsinya karena alasan yang salah, itu bisa sangat merusak.

Tampaknya tidak ada tempat untuk kualitas menarik dalam tangkas.

Anda membandingkan apel dan jeruk. Di air terjun tradisional, jika kebutuhan Anda mengatakan Anda harus memiliki yang dimiliki, Anda mendapatkan Fiat. Jika persyaratan mengatakan itu harus kedudukan tertinggi, Anda mendapatkan Ferrari.

Hal yang sama terjadi pada Agile. Jika kebutuhan Anda berhenti di must-have, Anda mendapatkan Fiat. Jika Anda memiliki cerita untuk keunggulan, Anda mendapatkan Ferrari. Semua yang Agile benar-benar memaksa adalah bahwa Anda melakukan harus kaya pertama . Tidak membangun spoiler super keren selama dua tahun dan kemudian melewatkan tenggat waktu untuk mesin.

Singkat cerita: Anda mendapatkan apa yang Anda butuhkan. Jika Anda berencana untuk mobil sport, Anda mendapatkan mobil sport. Agile tidak mengubah itu sama sekali. Jika proses tangkas Anda menghasilkan persyaratan untuk Fiat, jangan salahkan tangkas, salahkan orang-orang yang hanya membutuhkan Fiat.

Namun, semua proses gesit yang saya tahu sangat mendukung persyaratan yang harus ada. Ini selalu mendapatkan prioritas tertinggi.

Sebagaimana seharusnya - lihat model Kano Anda lagi: jika persyaratan yang harus dipenuhi tidak dipenuhi, pelanggan tidak akan menerima produk. Dan kesenangan Anda tidak penting.

Tampaknya tidak ada tempat untuk kualitas menarik dalam tangkas.

Tidak ada yang bisa lebih jauh dari kebenaran.

Proses lincah biasanya menekankan poin-poin ini:

• Sering mengirimkan produk yang dapat Anda gunakan untuk mendapatkan umpan balik.
• Membagi fitur menjadi bagian-bagian kecil yang dapat diselesaikan dalam waktu singkat.
• Laksanakan bagian-bagian itu dalam urutan prioritas.

Tidak ada yang mencegah Anda memberikan fitur "menyenangkan" dengan prioritas tinggi. Ini sepenuhnya tergantung pada orang-orang yang bertugas menentukan prioritas.

Sekarang memang benar bahwa banyak orang seperti itu memilih untuk tidak mengambil risiko dan karenanya mungkin tidak memberikan prioritas tinggi pada "orang yang senang". Tetapi dalam proyek non-gesit itu masih akan terjadi.

Agile tidak mengatakan apa- apa tentang apa yang harus dilakukan terlebih dahulu, hanya kode yang harus ditulis secara bertahap, dan disimpan dalam keadaan yang dapat dirilis sesering mungkin, alih-alih direncanakan tidak dapat digunakan selama berbulan-bulan hingga keadaan yang dapat dirilis berikutnya.

Saya telah bekerja di bawah proses Agile dan BDUF (Big Design Up Front), dan walaupun Anda pasti bisa mendapatkan fitur yang inovatif dan menarik dari kedua proses, di BDUF, tidak mengejutkan, Anda harus merencanakannya terlebih dahulu. Itu berarti inovasi umumnya harus diusulkan atau setidaknya disponsori oleh orang-orang yang memiliki pengaruh dalam proses desain.

Ini karena Anda memiliki enam bulan (atau apa pun) hingga rilis berikutnya, dan manajer proyek merasa tertekan tentang apa yang terjadi pada rilis itu, karena jika fitur mereka tidak masuk, itu akan menjadi enam bulan lagi sampai yang berikutnya . Jadi ada daftar fitur yang penuh sesak dalam jadwal padat, dan jika peringkat rendah dan file tertangkap bekerja selama dua atau tiga hari pada sesuatu yang keren mereka hanya berpikir pelanggan akan suka, dan itu bukan pada daftar, mereka mempertaruhkan seluruh jadwal dan akan ada neraka untuk membayar.

Dalam proses Agile, kami berusaha untuk menjaga perangkat lunak dalam keadaan yang dapat dirilis, dan manajer proyek kurang stres karena jika fitur mereka tergelincir, mereka hanya bisa mendapatkannya dalam dua minggu. Jadi, jika seorang pengembang kembali dari konferensi dengan ide keren dan menghabiskan beberapa hari untuk sesuatu, mereka tidak membahayakan jadwal tertulis-dalam-darah selama enam bulan.

Pada dasarnya, Anda menuai apa yang Anda tabur. Jika Anda mendorong inovasi dan memberi tim otonomi yang cukup untuk disampaikan, Anda akan mendapatkannya. Jika Anda terus-menerus menuntut pemotongan sudut untuk memenuhi tenggat waktu, Anda akan mendapatkan perangkat lunak yang cocok, tidak peduli metodologi Anda.

Perangkat lunak luar biasa berasal dari dua hal:

• Memberi pelanggan apa yang mereka butuhkan

• Menjadi seorang profesional

Ada berbagai macam prinsip yang harus diikuti ketika mengembangkan perangkat lunak. KERING, mudah dibaca, SOLID, dll. Yang tidak ada hubungannya dengan persyaratan pelanggan. Pelanggan meminta mobil sport. Jika pelanggan mengerti apa yang diperlukan untuk membuat mobil sport luar biasa, mereka tidak akan membutuhkan Anda. Terserah Anda untuk mencari tahu apa lagi yang penting.

Bagian dari pekerjaan kami adalah mempertahankan standar yang tidak pernah dialami pelanggan kecuali ada yang salah.

Jika Anda melakukannya dengan benar maka gesit cenderung ke arah fiat hanya ketika itulah yang benar-benar diinginkan pelanggan. Tidak ketika itu yang mereka pikir mereka harus puas.

Air terjun berbeda karena sekali kesalahpahaman tentang kebutuhan mobil sport kelas atas telah menetap di dalamnya cenderung bertahan. Agile dapat mengatasi informasi baru dan beradaptasi jika ternyata yang benar-benar mereka butuhkan adalah sepeda peluru.

Air terjun masih digunakan di banyak toko hingga hari ini. Toko-toko ini berhasil karena persyaratan mereka berubah kurang dari 2% dalam setahun.

Pekerjaan Anda bukan hanya memberi pelanggan apa yang mereka inginkan. Ini juga untuk mengurus hal-hal yang Anda tahu Anda tidak akan mendapatkan kredit sama sekali. Hal-hal yang pelanggan tidak akan pernah ungkapkan kecuali Anda membiarkan semuanya berjalan salah. Hal-hal ini sebaiknya dipilih dengan baik atau Anda akan mengambil banyak omong kosong untuk membuang-buang waktu pada mereka.

Setiap orang idiot dapat membangun jembatan dengan anggaran tak terbatas. Seorang profesional membangun jembatan yang nyaris tidak pernah jatuh.

Oleh karena itu saya percaya seseorang tidak boleh secara sembrono fokus pada persyaratan yang harus dipenuhi.

Tentu kamu harus. Kecuali saat memperkirakan waktu Anda. Karena persyaratan yang harus dipenuhi itu bukan satu-satunya pertimbangan.

Baik,

Di Agile programmer dapat membuat perangkat lunak, tetapi pada akhirnya pemilik produk yang menciptakan produk. (dengan menggunakan pengembang perangkat lunak.)

Jadi tentang "kualitas menarik", itu terserah pemilik produk.

Jika pemilik produk mengamanatkan "desain seksi", itu bisa dijadikan persyaratan. Pengembang tidak perlu khawatir tentang pilihan ini.

Juga, perangkat lunak sangat berbeda dari produk fisik yang sebenarnya sehingga saya pikir banyak model Kano tidak berlaku. Misalnya, mengapa saya facebook? Satu-satunya alasan: karena teman-teman saya melakukannya. Cara memasukkannya dalam sprint berikutnya ........ Dan juga, salah satu kualitas paling menarik dalam perangkat lunak, adalah bahwa ia benar-benar melakukan apa yang seharusnya dilakukan. (Dan di situlah tangkas banyak membantu: P)

Pengalaman saya setuju dengan komentar di atas - tidak ada yang melekat pada Agile yang menghalangi pengembangan perangkat lunak yang sangat baik - namun ada beberapa aspek tentang bagaimana Agile sering (mal-) dipraktikkan yang mengarah ke perangkat lunak yang hanya "cukup baik" . "

• Agile menekankan pada mendapatkan sesuatu yang bekerja SECEPATNYA; namun ini berarti membuat asumsi yang disederhanakan dan mengambil jalan pintas, khususnya dalam infrastruktur yang tidak terlihat oleh pengguna. Tidak ada yang salah secara inheren tentang ini, jika biaya memperbaiki asumsi penyederhanaan rendah; namun terlalu sering "utang teknis" ini tidak dihapus sebelum produk masuk ke produksi;
• Agile mengabarkan bahwa pada akhir sprint, Anda harus selalu memiliki sesuatu yang sedekat mungkin dengan shippable, sehingga pemegang saham dan manajer proyek dapat memutuskan bahwa "apa yang mereka miliki" cukup baik untuk didorong ke dalam produksi. Sekali lagi, tidak ada yang salah dengan ini, jikaAnda telah melunasi semua "hutang teknis" Anda (atau berdamai dengan berapa banyak yang Anda miliki dan di mana ia berada). Namun, dalam pengalaman saya, terlalu banyak utang teknis masuk ke produksi dengan janji oleh manajer bahwa "kami akan membersihkannya setelah tekanan untuk mengirim mati ", yang dengan cepat berubah menjadi" itu dalam produksi, kita harus sangat berhati-hati tentang apa yang kita ubah sekarang ", yang akhirnya berubah menjadi" Anda tidak pernah mengatakan kepada kami bahwa kami memiliki paparan itu! Kita harus melakukan pekerjaan yang lebih baik lain kali! " Pelajaran Ben Frankin tentang "Pahitnya kualitas yang buruk tetap lama setelah rasa manis harga rendah dilupakan" tampaknya tidak pernah dipelajari;
• Namun, bahkan dengan manajer yang percaya dan pengembang yang disiplin, ada masalah umum yang terlalu sedikit analisis, desain, dan tinjauan desain yang tepat terjadi sebelum dimulainya sprint di mana implementasi diharapkan untuk dimulai dan diselesaikan. Kegagalan untuk mempertimbangkan alternatifMetafora dan desain UI besar - biasanya terlalu mahal untuk merevisi ini secara signifikan setelah proyek dimulai; kegagalan tim junior untuk mempelajari produk pesaing mereka dengan cermat, atau memprioritaskan definisi dan implementasi teknologi infrastruktur seperti I18N, kerangka kerja pemberitahuan, penebangan, keamanan, dan strategi versi API (misalnya) berarti mereka pada akhirnya akan memiliki bug yang lebih tinggi, produktivitas yang lebih rendah, dan akan menghasilkan lebih banyak utang teknis, daripada jika mereka baru saja menghabiskan 2-5 sprint pertama di muka melakukan pelatihan yang diperlukan, analisis, desain, dan pembuatan prototipe. Singkatnya, tim Agile harus menolak lisensi untuk meretas;
• Saya memiliki manajer tingkat kedua (lebih dari 100 pengembang) yang mencegah pengembangnya meluangkan waktu untuk menuliskan desain yang direncanakan, bahkan di tingkat paling dasar. Alasannya - "Saya ingin orang-orang berbicara satu sama lain" - yang ironis karena mereka berada di 5 zona waktu dan 3 negara yang berbeda. Tak perlu dikatakan, ada banyak petunjuk tentang tim mana yang harus bekerja banyak malam-dan-akhir pekan di proyek setelah mereka tahu bahwa semua orang berpikir orang lain bertanggung jawab untuk menerapkan beberapa fungsi (atau menerapkan kembali karena desain pemasok dan konsumen tidak cocok.)

Itu semua bermuara pada apakah manajer proyek dan pemegang saham ingin memberikan produk berkualitas tinggi. Jika mereka berkomitmen untuk melakukannya, Agile akan mengaktifkannya. OTOH, karena Agile menempatkan jadwal pengambilan keputusan hanya di tangan pemegang pasak dan manajer proyek, Agile menyulitkan tim pengembangan untuk memberikan proyek yang luar biasa tanpa dukungan itu. Singkatnya: pertanggungjawaban untuk kualitas produk terletak hanya di kaki manajer proyek.

TL; DR

Bahkan, pengembangan tangkas membantu Anda untuk meningkatkan kualitas perangkat lunak, membuat pelanggan puas dan memberikan produk yang sangat berharga.

Pengembangan tangkas diperkenalkan oleh beberapa orang pintar untuk mengatasi masalah yang dihadapi banyak proyek perangkat lunak dalam proses tradisional.

Nilai-nilai kunci dari pengembangan tangkas seperti yang didefinisikan oleh manifesto tangkas (1) adalah,

• Individu dan Interaksi atas proses dan alat
• Bekerja Perangkat Lunak melalui dokumentasi yang komprehensif
• Kolaborasi Pelanggan atas negosiasi kontrak
• Menanggapi Perubahan setelah mengikuti rencana

Oleh karena itu, pengembangan tangkas tidak mencegah Anda untuk membuat perangkat lunak berkualitas tinggi. Pengembangan Agile mendukung Anda untuk menghadirkan perangkat lunak berkualitas tinggi.

Tetapi apakah kita (dan pelanggan) benar-benar selalu tahu sebelumnya apa persyaratan yang harus dipenuhi.

Itulah intinya. Dengan berfokus pada individu, pelanggan, perangkat lunak yang berfungsi, dan perubahan persyaratan pengembangan tangkas membantu Anda untuk mengetahui apa yang diinginkan pelanggan sebelum produk akhir dikirimkan.

Itulah alasan mengapa kerangka kerja gesit seperti Scrum memiliki siklus iterasi pendek yang hasilnya adalah produk yang berfungsi. Anda sudah dapat memvalidasi pekerjaan Anda pada tahap awal terhadap harapan pelanggan dan menyesuaikan tujuan / persyaratan sesuai permintaan. Pengembangan yang gesit membantu Anda memastikan untuk menyadari kualitas produk yang harus ada.

Kembali ke masa - itu masih berlaku untuk hari ini - banyak proyek perangkat lunak yang dikembangkan dalam pendekatan tradisional gagal, tidak berhasil atau menyebabkan pelanggan tidak senang karena kualitas yang harus dicapai tidak tercapai.

Selain itu, pengembangan tangkas juga membantu Anda mencapai Kualitas Menarik . Mencerminkan produk setelah setiap iterasi menerangkan persyaratan baru yang tidak diperhatikan oleh pelanggan pada awal proyek (kualitas menarik). Ini membuat pelanggan puas.

Saya juga ingin menyebutkan Kualitas Terbalik - atribut yang mengarah pada ketidakpuasan - model Kano.

Di setiap proyek ada persyaratan yang tampaknya menjadi ide bagus di awal proyek. Setelah beberapa saat mereka berubah ke sebaliknya dan menyebabkan kekecewaan.

Dalam proses pengembangan perangkat lunak tradisional, Anda akan mengenali persyaratan tersebut dalam produk akhir setelah proyek yang lama berjalan. Terlambat untuk menghindari kekecewaan pelanggan dan mengubahnya, proyek tindak lanjut diperlukan.

Pengembangan lincah membantu Anda mengidentifikasi persyaratan yang tidak berfungsi atau tidak memuaskan sejak dini dan mengubahnya selama proyek.

Seperti yang saya katakan, pengembangan tangkas membantu Anda meningkatkan kualitas perangkat lunak, menjaga kepuasan pelanggan dan memberikan produk yang sangat berharga.

Saya agak terlambat ke pesta ini, tetapi saya ingin berbagi sudut lain tentang hal ini:

Tetapi bagaimana mereka dapat diterapkan untuk menciptakan produk perangkat lunak berkualitas tinggi yang menyenangkan dan bukan hanya minimum yang hampir tidak memenuhi persyaratan yang harus dipenuhi?

Ada aspek temporal dalam pengembangan perangkat lunak gesit yang dihasilkan dari pendekatan berulang dan mempertimbangkan umpan balik pelanggan , yang merupakan dua elemen penting dari metodologi tangkas. Contoh: Fitur yang diidentifikasi sebagai kualitas menarik dalam iterasi t mungkin menjadi kualitas yang harus ada di iterasi berikutnya t + 1.

Menerapkan metode gesit secara dinamis dapat mengubah kategori kualitas fitur. Jika Anda membandingkan fitur yang direncanakan dari iterasi t dengan fitur yang sudah selesai pada beberapa iterasi nanti t + n, Anda akan mengalami apa yang Anda sebutkan:

Saya telah membuat pengalaman beberapa kali bahwa persyaratan yang diberikan prioritas tinggi pada awalnya, ternyata jauh lebih penting, jika tidak sia-sia, nanti.

Dengan mempertimbangkan aspek temporal ini, masuk akal bahwa metode gesit dapat menghasilkan produk perangkat lunak berkualitas tinggi yang menyenangkan sambil berkonsentrasi pada jumlah minimum . The Pendekatan berulang dipasangkan dengan umpan balik pelanggan mengubah aturan permainan dari waktu ke waktu.

Kesimpulan

Bagaimana cara mengembangkan perangkat lunak yang sangat baik dengan metode gesit?

Terapkan pendekatan berulang dan dengarkan umpan balik pelanggan . Parit salah satu elemen ini dan Anda akan mendapatkan bentuk pengembangan perangkat lunak tangkas yang kurang berhasil.

   > How to develop excellent software with agile methods?

• Saat memproduksi perangkat lunak individu khusus pelanggan :
  • menemukan pelanggan di mana biaya tidak masalah karena fitur "menyenangkan" membutuhkan uang tambahan dan pelanggan harus memutuskan apakah dia ingin membayar untuk ini.
• Saat memproduksi Softwareproducts :
  • Fitur "menyenangkan" bagus untuk menarik pelanggan baru dan biaya untuk menerapkan fitur "menyenangkan" tidak begitu penting jika produk dijual lebih dari 1000 kali.
• Dalam lingkungan di mana "cukup baik (termurah) adalah yang terbaik" Anda tidak akan mendapatkan uang untuk mengimplementasikan fitur "menyenangkan"

Dalam tim Scrum, Pemilik Produk bertanggung jawab untuk memilih fitur mana yang akan diterapkan. Jadi terserah padanya (dan sesuai anggarannya) untuk menentukan perangkat lunak "goodtec baik" atau "excelent"

Anda menaikkan beberapa poin bagus. Tapi saya tidak percaya masalah ini terbatas pada proses / metodologi yang gesit.

Ada beberapa pendapat berbeda tentang apa yang penting dan tidak penting. Untuk menggunakan contoh Anda, seseorang yang membeli mobil mungkin menganggap perhatian sebagai fitur penting dan karenanya menganggap Fiat tidak memenuhi persyaratan yang harus dimiliki ini.
Lebih realistis, produk perangkat lunak mungkin perlu memiliki fungsionalitas tertentu untuk memenuhi kebutuhan pengguna akhir yang sebenarnya ... tetapi mungkin juga perlu memiliki fitur tertentu lainnya untuk bisa dijual. Karena orang yang mengotorisasi pembelian sering kali bukan pengguna akhir.
Jadi fitur yang "tidak penting" bagi pengguna akhir mungkin penting untuk menjual produk ... dan karena itu juga penting bagi perusahaan yang menciptakan produk.

Semua itu bermuara pada kenyataan bahwa sangat penting untuk memiliki tim pengembangan produk yang baik untuk menetapkan persyaratan dan prioritas dengan tepat. Tapi itu tidak hanya berlaku untuk toko gesit.

Penting juga untuk memiliki pemilik / pemangku kepentingan produk yang berwenang untuk mengambil keputusan. Jika keputusan pemilik produk Anda terus-menerus ditolak oleh orang lain, saya akan menjadi orang pertama yang setuju bahwa itu masalah, tetapi sekali lagi, itu bukan masalah dengan gesit.

Ada hal-hal lain yang Anda inginkan dalam pemilik produk Anda ... satu deskripsi yang saya dengar adalah "CRACK" (kolaboratif, representatif, resmi, berkomitmen, dan berpengetahuan). Pemilik produk yang kurang dalam bidang-bidang ini dapat mengeja masalah untuk suatu proyek. Tapi saya pertama kali mendengar akronim ini di lingkungan air terjun, jadi jelas rasa sakit pelanggan buruk / pemilik produk tidak terbatas pada toko gesit.

Apa yang tangkas dapat (bantu) lakukan adalah membawa beberapa masalah ini ke permukaan.

Misalnya, literatur XP adalah IIRC cukup eksplisit tentang membuat "pelanggan" berpengetahuan, dapat diakses oleh tim, dan berwenang untuk membuat keputusan. Istilah "pemilik produk" menyiratkan beberapa tingkat pengetahuan, komitmen, dan otoritas.

Jika Anda menemukan diri Anda dalam situasi di mana sebagian besar fungsionalitas yang dikirim terdiri dari kesenangan daripada fitur yang harus dimiliki, jauh lebih mudah untuk mengangkat masalah itu (dan jauh lebih mudah untuk menentukan penyebabnya) ketika Anda memberikan perangkat lunak yang berfungsi atau hampir-bekerja setiap 2-3 minggu dibandingkan saat pengiriman terpisah beberapa bulan atau tahun.

Jika Anda bekerja dalam iterasi kecil - dan meninjau backlog sering (termasuk meninjau kembali prioritas) - yang memberi tim kesempatan untuk belajar dari kesalahan sebelumnya. "Ini terasa sangat penting sekarang, tapi ingat navigasi dinamis yang kami yakin kami butuhkan sehingga kami tidak menggunakannya?" Seperti yang telah ditunjukkan oleh orang lain, diskusi-diskusi itu sangat kecil kemungkinannya jika semuanya telah direncanakan di muka.

Sebaliknya, metodologi desain muka mengasumsikan (secara default) bahwa pemahaman tentang produk dan fitur adalah statis. Itu belum pengalaman saya: memiliki sesuatu yang nyata untuk bekerja dengan hampir selalu mengubah pemahaman orang bisnis tentang masalah tersebut. Karenanya penekanan pada umpan balik cepat. (Pemahaman pengembang berubah juga, tetapi itu tidak akan mempengaruhi prioritas.)

Menunda beberapa perencanaan juga memungkinkan Anda merespons perubahan dalam kebutuhan bisnis. "Kamu tahu situs web yang kamu bangun itu? Kita benar-benar membutuhkannya untuk menjadi aplikasi seluler, yang mampu memutus operasi." Ini bukan sesuatu yang ditanyakan secara khusus ... tetapi tidakkah Anda ingin proses Anda mampu merespons perubahan dalam lanskap bisnis (setidaknya secara teori)?

Agile tidak mengatakan "jangan membangun fitur yang tidak penting". Itu mengatakan "memungkinkan bisnis untuk memutuskan fitur mana (tidak) untuk membangun".
... dan (sama pentingnya) "memungkinkan teknisi untuk memberi tahu Anda berapa lama fitur yang Anda inginkan untuk membangun".

1. Must-be qualitiesseringkali sulit ditentukan. Orang memilikinya dalam subkonsepsi. Iterasi yang tangkas dan partisipasi klien membantu untuk menemukan sebagian besar yang harus dimiliki. Itu adalah kekuatan lincah dan bodoh untuk mengabaikannya .
2. One-dimensional qualitiesitu berarti janji yang harus dipenuhi, didukung oleh air terjun OK, sampai mereka tidak berubah. Di sini menjadi gesit hanya membantu, tetapi tidak begitu kuat.
3. Attractive qualitiesadalah fitur yang bagus. Mereka bisa menjadi calon generasi penerus. Tetapi dalam generasi saat ini mereka bahkan tidak dalam perjanjian - atau mereka akan menjadi kualitas satu dimensi. Metode gesit yang menganggap partisipasi perwakilan klien mendukung kualitas ini dengan sangat baik. Sebab kita bisa mengubah lingkupnya dengan ringan selama bekerja. Kami dapat menawar perbaikan di satu tempat untuk mendapatkan kompensasi di tempat lain. Di air terjun itu praktis tidak mungkin. Tanpa penundaan organisasi yang hebat, kami hanya dapat TAMBAH fitur secara gratis. Mungkin saja, jika beberapa waktu ekstra sebelumnya dimasukkan ke dalam anggaran.

Jadi, proses lincah dapat mendukung model Kano, beberapa dari mereka melakukannya dengan sangat, dan jelas jauh lebih baik daripada proyek air terjun terbaik.

Untuk melakukannya dengan sangat dalam pemahaman Anda, Anda harus mengatur proses lincah dengan peserta perwakilan klien yang bertanggung jawab.