Argumen apa yang dapat saya gunakan untuk “menjual” konsep BDD kepada tim yang enggan untuk mengadopsinya?

Saya sedikit pendukung vokal dari metodologi Pengembangan Perilaku Didorong (alias BDD). Saya telah menerapkan BDD selama beberapa tahun sekarang, dan telah mengadopsi StoryQ sebagai kerangka pilihan saya ketika mengembangkan aplikasi DotNet. Meskipun saya telah menguji unit selama bertahun-tahun, dan sebelumnya telah bergeser ke pendekatan test-first, saya telah menemukan bahwa saya mendapatkan nilai lebih dari menggunakan kerangka BDD, karena tes saya menangkap maksud dari persyaratan dalam relatif bahasa Inggris yang jelas dalam kode saya, dan karena tes saya dapat menjalankan beberapa pernyataan tanpa mengakhiri tes setengah jalan - yang berarti saya dapat melihat pernyataan spesifik yang lulus / gagal sekilas tanpa debugging untuk membuktikannya.

Ini benar-benar menjadi puncak gunung es bagi saya, karena saya juga memperhatikan bahwa saya dapat men-debug kode pengujian dan implementasi dengan cara yang lebih bertarget, dengan hasil bahwa produktivitas saya telah tumbuh secara signifikan, dan bahwa saya dapat lebih dengan mudah menentukan di mana kegagalan terjadi jika masalah terjadi untuk membuat semua jalan ke build integrasi karena output yang masuk ke log build. Lebih lanjut, api StoryQ memiliki sintaks fasih yang indah yang mudah dipelajari dan yang dapat diterapkan dalam sejumlah cara yang luar biasa, tidak memerlukan dependensi eksternal untuk menggunakannya.

Jadi dengan semua manfaat ini, Anda akan merasa mudah untuk memperkenalkan konsep ini ke seluruh tim. Sayangnya, anggota tim yang lain enggan untuk bahkan melihat StoryQ untuk mengevaluasinya dengan benar (apalagi menghibur ide menerapkan BDD), dan telah meyakinkan satu sama lain untuk mencoba dan menghapus sejumlah elemen StoryQ dari kerangka pengujian inti kami sendiri, bahkan meskipun mereka awalnya mendukung penggunaan StoryQ, dan meskipun kode yang ingin mereka hapus tidak berdampak pada bagian lain dari sistem pengujian kami. Melakukan hal itu pada akhirnya akan menambah beban kerja saya secara keseluruhan secara keseluruhan dan benar-benar bertentangan dengan keinginan, karena saya yakin melalui pengalaman praktis bahwa itu adalah cara yang lebih baik untuk bekerja dengan cara uji-pertama di lingkungan kerja khusus kami, dan hanya dapat mengarah pada peningkatan peningkatan kualitas perangkat lunak kami, mengingat saya Saya merasa lebih mudah untuk tetap dengan tes pertama menggunakan BDD. Untuk lebih memperjelas, sebagian besar unit test kami cenderung sangat rapuh dan sulit untuk dipertahankan, peninggalan dari tahun pengujian yang diterapkan dengan buruk di mana keengganan untuk bertahan dengan proses yang digerakkan tes telah melihat pengembang jatuh pada kebiasaan lama dan lakukan semua pengujian mereka di akhir proyek (orang-orang yang sama ini mengklaim Agile!).

Jadi pertanyaannya benar-benar muncul sebagai berikut:

Argumen apa yang dapat saya gunakan untuk benar-benar mengarahkan poin bahwa akan lebih baik bagi tim ini untuk menggunakan StoryQ, atau paling tidak untuk mengadopsi metodologi BDD?
Dapatkah Anda menunjukkan bukti anekdotal yang dapat saya gunakan untuk mendukung argumen saya untuk mengadopsi BDD sebagai metode pilihan standar kami?
Argumen balasan apa yang dapat Anda pikirkan yang dapat menyarankan bahwa keinginan saya untuk mendorong tim untuk mengadopsi BDD mungkin salah? Ya, saya senang terbukti salah asalkan argumennya masuk akal.

CATATAN : Saya tidak menganjurkan agar kami menulis ulang pengujian kami secara keseluruhan, melainkan untuk mulai bekerja dengan cara yang berbeda untuk semua pekerjaan pengujian di masa depan, dan lebih disukai dengan cara kami melibatkan pelanggan kami.

Dan bagi Anda yang ingin mempelajari lebih lanjut tentang BDD, tautan berikut mungkin berguna:

_{Bagi mereka yang tertarik pada detail lebih lanjut, kami adalah tim kecil yang terdiri dari 4 orang yang mengerjakan sekitar 5 proyek besar. "Uji coba percontohan" untuk BDD berjalan sekitar 2 bulan pada awalnya, dengan sekitar 4 bulan berikutnya. Tim menerima bahwa saya harus terus bekerja dengan cara ini dan harus melakukan uji coba sendiri. Saya sudah mengalami BDD selama sekitar 2 tahun sekarang sejak persidangan berakhir, sementara yang lain menjadi sangat pandai mengelak masalah ini. Alih-alih memaksakan "konfrontasi" atas masalah ini, saya mencari cara untuk dengan lembut membujuk tim untuk keluar dari belakang kolektif mereka dan meluangkan waktu untuk melakukan bagian mereka.}

— S.Robins
sumber

Mari kita pikirkan "MEREKA" - mengapa mereka ingin itu dihapus? Pasti bermanfaat bagi mereka - sudahkah Anda mencoba mencari tahu manfaatnya PERTAMA dan melihat jalan tengah apa yang bisa dicapai SEBELUM mengajukan manfaat Anda :)

— PhD

Cobalah kurang berjualan dan lebih mendidik. Dalam pengalaman saya, orang tidak ingin dijual sesuatu tetapi selalu mau belajar sesuatu yang baru. Kemudian biarkan kartu jatuh di mana mereka mungkin. Jika mereka masih menentangnya, Anda gagal sebagai pendidik atau bdd tidak semua yang Anda katakan.

— Kevin

@Kevin Saya pikir Anda melewatkan komentar saya sebelumnya untuk Nupal, dan mungkin titik pertanyaan saya sepenuhnya. Anda telah mengambil satu kata dari pertanyaan saya dan menafsirkannya di luar konteks. Saya sebenarnya mencoba mendidik, dan tidak hanya "menjual" seperti itu. Saya mencari poin tertentu yang dapat saya gunakan untuk membantu saya mengatasi keengganan yang tidak perlu untuk melakukan sesuatu yang berbeda. Harap jawab jika Anda memiliki pengetahuan tentang materi pelajaran, daripada hanya memberikan pernyataan provokatif tentang kemampuan saya atau teknologi, yang jelas-jelas tidak membantu di pihak Anda.

— S.Robins

Diagram keputusan biner? Beli salinan TAoCP vol 4 Knuth dan pinjamkan kepada mereka.

— Peter Taylor

Saya pikir masalah yang dimiliki tim Anda bukan dengan BDD itu sendiri, melainkan masalah kelelahan metodologi pengembangan. Saya sendiri menderita ini. Terlalu banyak metodologi yang menjanjikan untuk merevolusi pembangunan. Sayangnya beberapa bulan kemudian selalu ada metodologi dan toolset baru. Saya datang untuk melihatnya sebagai gangguan yang mengganggu daripada kesempatan untuk meningkatkan. Untuk memperkenalkan BDD, Anda harus mengatasi masalah ini.

— Antonio2011a

Jawaban:

Argumen apa yang dapat saya gunakan untuk benar-benar mengarahkan poin bahwa akan lebih baik menggunakan StoryQ, atau paling tidak menerapkan metodologi BDD?

"Pelanggan menginginkannya."

IMO Anda ingin menjual BDD kepada pelanggan Anda / pakar domain setidaknya sebanyak ke tim pengembangan.

BDD adalah proses kolaborasi luar-dalam di mana banyak pemangku kepentingan terlibat. Manfaat BDD tidak hanya bagi pengembang untuk secara otomatis menyimpulkan kode tes mereka dari tes penerimaan, mereka juga terletak pada kerja sama kreatif yang terjadi antara orang-orang teknis dan bisnis untuk menghasilkan spesifikasi berharga, yang didefinisikan dengan baik dari perilaku sistem yang dimaksudkan.

Memberikan pelanggan / analis bisnis akses ke antarmuka di mana mereka dapat menjalankan setiap spesifikasi yang dapat dieksekusi, mengontrol status mereka dan melihat perkembangan dalam implementasi mereka umumnya sangat dihargai juga.

Ada presentasi oleh Dan North tentang bagaimana Anda dapat menjual BDD ke bisnis: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

— guillaume31
sumber

Saya telah melihat presentasi itu dan Anda benar, ini adalah cara yang baik untuk pendekatan memperkenalkan konsep kepada pelanggan. Dalam kasus saya, saya perlu mengambil beberapa langkah kecil. Jika satu-satunya hal yang saya bisa meyakinkan tim untuk lakukan adalah mengadopsi bahasa, saya mungkin memiliki kesempatan untuk mendorong metode lengkap untuk diterapkan. Saya juga perlu menangani masalah bahwa sebagian besar pelanggan kami adalah internal, dan kurang fokus pada bisnis. Namun poin Anda dicatat dengan baik. :-)

— S.Robins

Dalam tim yang enggan mengadopsi BDD, kemungkinan tidak ada "argumen" yang dapat Anda gunakan untuk "mengubah" kolega Anda menjadi adopsi skala penuh.

Saya pikir yang terbaik yang dapat Anda lakukan adalah meyakinkan mereka untuk mencobanya ("tes asap", "lari kering", "proyek percontohan") - terutama jika Anda membuatnya sangat jelas bahwa Anda akan membatalkan gagasan jika hasil pengujian negatif.
Pendekatan Anda untuk menemukan bukti anekdotal sangat cocok dengan gagasan meyakinkan tim untuk mencobanya. Untuk itu, saya cukup mencari di web untuk sesuatu seperti "Kisah sukses Pembangunan Berbasis Perilaku" dan memilih apa yang terasa lebih mudah digunakan untuk saya.
Ada beberapa argumen kontra yang dapat saya pikirkan yang dapat menyarankan bahwa keinginan Anda untuk mengubah upaya tim menjadi BDD mungkin salah.

Tidak satu pun dari ini yang sangat konstruktif, terutama dari sudut pandang "advokat perubahan" tetapi sayangnya Anda mungkin harus berurusan dengan retorika ( BTDTGTTS ) seperti ini:
- Anda tidak dapat menjamin bahwa produktivitas tim secara keseluruhan akan meningkat
- Anda tidak dapat menjamin bahwa upaya yang diinvestasikan untuk mengadopsi BDD akan memberikan ROI yang substansial
- Tim melakukan cukup baik tanpa BDD, risiko mengubah pendekatan saat ini tidak dibenarkan
- Google (atau Microsoft, atau IBM - cukup masukkan nama vendor perangkat lunak "terhormat" apa pun) berjalan baik tanpa BDD, yang "membuktikan" bahwa BDD tidak diperlukan
- pendekatan non-BDD tidak diberi kesempatan yang adil dalam pengujian komparatif
- BDD mungkin secara umum OK tetapi untuk ini / itu modul / proyek itu tidak berlaku

Per pengalaman saya, cara paling tidak menyakitkan untuk mengatasi argumen kontra seperti yang tercantum di atas adalah dengan melakukan uji coba terkontrol terbatas untuk perubahan yang diusulkan.

Status "pengujian terbatas" pada dasarnya membatalkan tiga dari empat argumen di atas, kecuali satu tentang "vendor terhormat", yang dapat dilawan dengan memberikan bukti anekdotal kisah sukses (bukti anekdotal mungkin tidak akan bekerja untuk "perubahan besar" tetapi untuk pengujian terbatas itu cukup bagus).

Jika perubahan itu memang bermanfaat dan uji coba diatur dengan benar, Anda akan melihat perubahan positif dalam tim dan sikap manajemen, membuat transisi ke perubahan skala penuh lancar dan tidak menyakitkan.

Manfaat lain dari uji coba terbatas adalah memungkinkan Anda mengklarifikasi dan menyesuaikan detail proses target tanpa menyebabkan terlalu banyak masalah dan dengan risiko "kerusakan reputasi" yang lebih rendah terhadap ide tersebut. Setiap kali saya berpartisipasi dalam uji coba semacam itu , saya terkejut mengetahui betapa mulusnya beralih ke adopsi skala penuh dengan rincian paling penting ditetapkan dan diklarifikasi dalam uji coba.

— agas
sumber

Terima kasih atas jawaban yang bijaksana. Seperti yang terjadi, saya telah berhasil melakukan tes terbatas, diikuti oleh penerimaan oleh tim untuk memungkinkan BDD diterapkan tanpa batas waktu. Peningkatan produktivitas telah terukur, tetapi seperti yang Anda sebutkan tidak ada jaminan ini akan berlaku untuk seluruh tim tanpa menemukan beberapa cara untuk mendorong setiap anggota tim untuk mencobanya sendiri, yang kebetulan merupakan motivasi untuk memperkenalkan pertanyaan.

— S.Robins

@ S.Robins menarik. Pengujian terbatas yang Anda sebutkan, untuk berapa lama itu berjalan? bagian mana dari tim yang terlibat?

— nyamuk

Kami adalah tim kecil yang terdiri dari 4 orang yang bekerja di sekitar 5 proyek besar. "Tes" berjalan sekitar 2 bulan pada awalnya, dengan periode sekitar 4 bulan berikutnya. Tim menerima bahwa saya harus terus bekerja dengan cara ini dan harus melakukan uji coba sendiri. Saya sudah mengalami BDD selama sekitar 2 tahun sekarang sejak persidangan berakhir, sementara yang lain menjadi sangat pandai mengelak masalah ini. Daripada memaksakan "konfrontasi" atas masalah ini, saya lebih suka mencari cara untuk dengan lembut membujuk tim untuk keluar dari belakang kolektif mereka dan meluangkan waktu untuk melakukan bagian mereka! ;-)

— S.Robins

Saya melihat. Itu membuat pertanyaan Anda semakin menarik. Saya perlu waktu untuk mengunyahnya; sampai sekarang saya tidak bisa membayangkan bagaimana mungkin untuk membuat kemajuan lebih lanjut (kecuali untuk pendekatan "tidak adil" seperti memanfaatkan kekuatan manajemen mikro )

— agas

@ S.Robins sementara saya mendapatkan perhatian kami - apakah Anda memiliki modul yang "mencampur" BDD dan non-BDD atau ada semacam pemisahan dengan 100% BDD / 0% modul BDD?

— nyamuk

-1

Mungkin sudah waktunya untuk merekrut manajemen. Jika Anda telah mencoba dan melihat hasil yang solid, tetapi tim menolak, manajemen mungkin harus terlibat.

Ini terutama benar jika mereka menyakiti anggota tim perusahaan yang paling produktif. Bersiaplah untuk serangan balasan. Anda dapat mulai dengan mendekati manajemen dan berusaha agar tim berhenti meremehkan Anda dengan mengambil test case Anda.

— Bill Leeper
sumber

Saya tidak tahu apakah saya setuju dengan ini. Apakah Anda mengatakan bahwa tanpa pengembang membeli dalam pendekatan yang tepat adalah membuat manajemen memaksanya turun dari leher pengembang? Apakah itu tidak menimbulkan kebencian? Terlepas dari manfaat BDD, saya pikir itu akan membawa hasil yang lebih buruk. Yaitu Anda akan memenangkan pertempuran dan kalah perang.

— Kevin

@ Kevin Saya setuju dengan Kevin untuk yang satu ini. Kebencian dan perasaan tidak enak dapat mematahkan tim dengan sangat cepat, dan itu sendiri dapat menjadi risiko yang lebih besar bagi produktivitas tim daripada membiarkan mereka bekerja secara tidak efisien. Komentar Kevin mengingatkan saya pada pepatah tentang tidak memiliki paku. Dalam hal ini, saya tidak mencari untuk melakukan sesuatu yang drastis atau heroik hanya untuk mendapatkan cara saya. Yang saya cari adalah "kuku" saya.

— S.Robins

Tim sudah melawan mereka sebagaimana dibuktikan oleh fakta bahwa mereka mengeluarkan kode uji yang mereka tulis. Itu cukup bermusuhan dalam pikiran saya dan memerlukan intervensi manajer pengembangan. Itulah tugas mereka, untuk membuat seluruh tim berjalan lebih lancar.

— Bill Leeper