BDD konseptini benimsemeye isteksiz bir ekibe “satmak” için hangi argümanları kullanabilirim?

Ben Davranış Odaklı Gelişim metodolojisinin (aka BDD) biraz vokal savunucusuyum. BDD'yi birkaç yıldır uyguluyorum ve StoryNet'i DotNet uygulamaları geliştirirken tercih ettiğim çerçeve olarak benimsedim . Yıllarca birim test yapmam ve daha önce test ilkine yaklaşmış olmama rağmen, bir BDD çerçevesi kullanmaktan çok daha fazla değer elde ettiğimi fark ettim, çünkü testlerim gereksinimlerin amacını nispeten ele alıyor kodumdaki İngilizce'yi temizleyin ve testlerim, testi yarıya kadar bitirmeden birden fazla iddia yürütebildiğinden, kanıtlamak için hata ayıklamadan hangi belirli iddiaların bir bakışta geçtiğini / başarısız olduğunu görebiliyorum.

Bu benim için buzdağının ucu oldu, çünkü hem test hem de uygulama kodunu daha hedefli bir şekilde hata ayıklayabildiğimi fark ettim, sonuçta üretkenliğim önemli ölçüde büyüdü ve daha fazlasını yapabilirim derleme günlüklerine giden çıktı nedeniyle tümleştirme derlemesine kadar bir sorun oluşması durumunda bir hatanın nerede ortaya çıktığını kolayca belirleyin. Ayrıca, StoryQ api'nin öğrenmesi kolay ve kullanmak için harici bir bağımlılık gerektirmeyen olağanüstü sayıda şekilde uygulanabilen hoş bir akıcı sözdizimi vardır.

Tüm bu avantajlarla, konsepti ekibin geri kalanına tanıtmanın kolay olduğunu düşünürdünüz. Ne yazık ki, diğer ekip üyeleri bile düzgün bir şekilde değerlendirmek için StoryQ'ya bakmak konusunda isteksizdir (bırakın BDD uygulama fikrini eğlendirmek için) ve birbirimizi kendi çekirdek test çerçevemizden birkaç StoryQ öğesini denemeye ve çıkarmaya ikna ettiler. başlangıçta StoryQ kullanımını desteklediler ve kaldırmak istedikleri kod test sistemimizin başka bir bölümünü etkilemese de. Bunu yapmak, iş yükümü genel olarak önemli ölçüde artıracak ve gerçekten tahıllara karşı gidecektir, çünkü pratik deneyimlerle, belirli çalışma ortamımızda ilk önce bir şekilde çalışmanın daha iyi bir yolu olduğuna ve sadece daha fazla Ben 'verilen yazılım kalitemizdeki gelişmeler' BDD kullanarak önce teste bağlı kalmayı daha kolay buldum. Daha da açıklığa kavuşturmak için, birim testlerin çoğunluğu oldukça kırılgan ve bakımı zor olma eğilimindedir, test odaklı bir sürece sadık kalmanın isteksizliğin eski alışkanlıklara düştüğü ve tüm testlerini projenin sonunda yapın (aynı insanlar Çevik olduğunu iddia ediyorlar!).

Yani soru gerçekten aşağıdakilere iniyor:

1. Bu ekibin StoryQ kullanmasının veya en azından BDD yöntemini benimsemesinin daha iyi olacağı noktasını gerçekten yönlendirmek için hangi argümanları kullanabilirim?
2. BDD'yi standart seçim yöntemimiz olarak benimsemek için argümanımı desteklemek için kullanabileceğim herhangi bir anekdot kanıtına işaret edebilir misiniz?
3. Bunun hangi karşı argümanları düşünebilirsiniz ki, ekibi BDD'yi benimsemeye teşvik etme isteğim hatalı olabilir? Evet, argüman sağlam olduğu sürece yanlış olduğu kanıtlanmış olmaktan mutluluk duyuyorum.

NOT : Testlerimizi bütünüyle yeniden yazmamayı değil, gelecekteki tüm test çalışmaları için farklı bir şekilde ve tercihen müşterilerimizle etkileşimde bulunma biçiminde çalışmaya başlamayı savunuyorum.

BDD hakkında daha fazla bilgi edinmek isteyenler için aşağıdaki bağlantılar yararlı olabilir:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Daha fazla ayrıntıyla ilgilenenler için, yaklaşık 5 büyük proje üzerinde çalışan 4 kişilik küçük bir ekibiz. BDD için "pilot deneme" başlangıçta yaklaşık 2 ay sürdü ve yaklaşık 4 aylık bir süre daha devam etti. Ekip, bu şekilde çalışmaya devam etmem gerektiğini kabul etti ve kendi duruşmalarını yapacağım. Duruşmanın sona ermesinden bu yana yaklaşık 2 yıldır BDD-ing oldum, diğerleri ise bu konuda çok başarılı oldular. Konu üzerinde bir "çatışmayı" zorlamak yerine, ekibi nazikçe kolektif davranışlarından kurtulmaya ve zamanlarını yapmaya zaman ayırmaya ikna etmenin yollarını arıyorum.}

StoryQ kullanmanın veya en azından BDD metodolojisini uygulamanın daha iyi olacağı noktasını gerçekten yönlendirmek için hangi argümanları kullanabilirim?

"Müşteri bunu istiyor."

IMO'yu en azından geliştirme ekibine olduğu kadar müşterilerinize / alan adı uzmanlarınıza satmak istiyorsunuz.

BDD, birden fazla paydaşın dahil olduğu, işbirlikçi bir dış-giriş sürecidir. BDD'nin faydaları sadece geliştiricilerin test kodlarını kabul testlerinden otomatik olarak çıkarmaları değil, aynı zamanda sistemin amaçlanan davranışının değerli ve iyi tanımlanmış özelliklerini üretmek için teknik ve iş adamları arasında gerçekleşen yaratıcı işbirliğinde yatmaktadır.

Müşterilere / iş analistlerine, her bir yürütülebilir özelliği çalıştırabilecekleri, durumlarını kontrol edebilecekleri ve uygulamalarındaki ilerlemenin genel olarak çok takdir edilebilecekleri bir arayüze erişim izni vermek.

Dan North tarafından BDD'yi işletmeye nasıl satabileceğiniz konusunda bir sunum var: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. BDD'yi benimsemeye isteksiz bir ekipte, meslektaşlarınızı tam ölçekli evlat edinmeye "dönüştürmek" için kullanabileceğiniz "argümanlar" yoktur.
    
   Bence yapabileceğiniz en iyi şey onları denemeye ("duman testi", "kuru çalışma", "pilot proje") ikna etmektir - özellikle de eğer test sonuçları konusunda fikri düşürebileceğinizi açıkça belirtirseniz negatiftir.
2. Anekdot kanıt bulma yaklaşımınız, ekibi denemeye ikna etme fikrine mükemmel bir şekilde uyar. Bunun için web'de "Davranış Odaklı Gelişim başarı öyküsü" gibi bir şey arar ve benim için kullanımı daha kolay olanı seçerdim.
3. Düşünebileceğim birkaç karşı argüman var, takım çabalarını BDD'ye dönüştürme isteğinizin yanlışlıkla olabileceğini düşündürüyor.
    
   Bunların hiçbiri, özellikle bir "değişim savunucusu" açısından özellikle yapıcı değildir, ancak ne yazık ki tam olarak bu tür söylemlerle ( BTDTGTTS ) uğraşmanız gerekecektir :
    
   • genel ekip verimliliğinin artacağını garanti edemezsiniz
   • BDD'yi benimsemek için harcanan çabaların önemli ölçüde yatırım getirisi sağlayacağını garanti edemezsiniz
   • ekibi BDD olmadan yeterince iyi gidiyordu, mevcut yaklaşımı değiştirme riski haklı değil
   • Google (veya Microsoft veya IBM - sadece "saygın" yazılım satıcılarının adını doldurun) BDD olmadan iyi gidiyor, bu da BDD'nin gerekli olmadığını "kanıtlıyor"
   • BDD dışı yaklaşımlara karşılaştırmalı testte adil bir şans verilmedi
   • BDD genellikle iyi olabilir, ancak bu ve bu modül / proje için geçerli değildir

Deneyimlerime göre, yukarıda listelenen gibi karşı argümanları ele almanın en az acı verici yolu, önerilen bir değişiklik için sınırlı kontrollü bir test çalıştırması yapmaktı.

"Sınırlı test" durumu, "saygın tedarikçi" hakkında bir tanesi hariç, yukarıdaki dört argümanın üçünü geçersiz kılar; bu , başarı hikayesinin anekdot kanıtları sağlayarak karşılanabilir (anekdot kanıtları muhtemelen "büyük patlama değişikliği" için işe yaramaz, ancak sınırlı test yeterli).

Değişiklik gerçekten değerliyse ve test çalıştırması düzgün bir şekilde düzenlenmişse, ekip ve yönetim tutumunda olumlu bir değişiklik fark edeceksiniz, bu da tam ölçekli değişime geçişi pürüzsüz ve ağrısız hale getirecektir.

Sınırlı test çalışmasının bir diğer yararı, çok fazla soruna neden olmadan ve fikre daha düşük "itibar hasarı" riski ile hedef süreç detayını netleştirmenize ve ayarlamanıza izin vermesidir. Bu tür test çalışmalarına her katıldığımda, test çalışmasında belirlenmiş ve netleştirilen en önemli ayrıntılara sahip tam ölçekli evlat edinmeye geçmenin ne kadar pürüzsüz olduğunu bulmak hoş bir sürpriz oldu.

Yönetimi işe alma zamanı gelmiş olabilir. Bir deneme yaptıysanız ve somut sonuçlar gördüyseniz, ancak ekip balkıyorsa, yönetimin dahil olması gerekebilir.

Bu özellikle şirketlerin en verimli ekip üyelerine zarar veriyorlarsa geçerlidir. Boşluk için hazırlıklı olun. Yönetime yaklaşarak ve ekibin test senaryolarınızı çıkararak sizi alt üst etmeyi bırakmasını sağlayarak işe başlayabilirsiniz.