ฉันสามารถใช้เหตุผลอะไรในการ "ขาย" แนวคิด BDD ให้กับทีมที่ไม่เต็มใจยอมรับมัน

ฉันเป็นแกนนำของวิธีการขับเคลื่อนการพัฒนาพฤติกรรม (BDD) ฉันใช้ BDD มาสองสามปีแล้วและได้ปรับใช้StoryQเป็นกรอบทางเลือกของฉันเมื่อพัฒนาแอพพลิเคชั่น DotNet แม้ว่าฉันได้ทำการทดสอบหน่วยมาหลายปีแล้วและก่อนหน้านี้ได้เปลี่ยนวิธีการทดสอบเป็นครั้งแรก แต่ฉันก็พบว่าฉันได้รับประโยชน์มากขึ้นจากการใช้กรอบการทำงานของ BDD เนื่องจากการทดสอบของฉันจับความต้องการของความต้องการค่อนข้าง ชัดเจนภาษาอังกฤษภายในรหัสของฉันและเนื่องจากการทดสอบของฉันสามารถดำเนินการยืนยันหลายโดยไม่สิ้นสุดการทดสอบครึ่งทาง - หมายถึงฉันสามารถดูว่าการยืนยันที่เฉพาะเจาะจงผ่าน / ล้มเหลวได้อย่างรวดเร็วโดยไม่ต้องแก้จุดบกพร่องเพื่อพิสูจน์มัน

นี่เป็นส่วนเล็ก ๆ ของภูเขาน้ำแข็งสำหรับฉันอย่างที่ฉันสังเกตเห็นว่าฉันสามารถดีบักทั้งรหัสทดสอบและการติดตั้งในลักษณะที่ตรงเป้าหมายมากขึ้นด้วยผลลัพธ์ที่ทำให้ประสิทธิภาพการทำงานของฉันเติบโตขึ้นอย่างมีนัยสำคัญ กำหนดได้อย่างง่ายดายว่ามีข้อผิดพลาดเกิดขึ้นที่ใดหากมีปัญหาเกิดขึ้นเพื่อให้สามารถสร้างการรวมได้เนื่องจากเอาท์พุทที่เข้าสู่บันทึกการสร้าง นอกจากนี้ StoryQ api มีไวยากรณ์ที่ไพเราะน่ารักซึ่งง่ายต่อการเรียนรู้และสามารถนำไปใช้ได้หลายวิธีโดยไม่ต้องพึ่งพาภายนอกเพื่อใช้งาน

ดังนั้นด้วยผลประโยชน์ทั้งหมดนี้คุณจะคิดว่ามันง่ายที่จะแนะนำแนวคิดให้กับทีมอื่น ๆ น่าเสียดายที่สมาชิกในทีมคนอื่น ๆ ยังลังเลที่จะดู StoryQ เพื่อประเมินมันอย่างถูกต้อง (ให้ความบันเทิงกับความคิดในการใช้ BDD) และเชื่อมั่นซึ่งกันและกันเพื่อลองและลบองค์ประกอบของ StoryQ ออกจากกรอบการทดสอบหลักของเราเอง แม้ว่าในตอนแรกพวกเขาจะสนับสนุนการใช้ StoryQ และแม้ว่ารหัสที่พวกเขาต้องการลบจะไม่ส่งผลกระทบต่อส่วนอื่น ๆ ของระบบการทดสอบของเรา การทำเช่นนั้นจะเป็นการเพิ่มปริมาณงานโดยรวมอย่างมีนัยสำคัญและขัดต่อธัญพืชจริง ๆ เพราะฉันเชื่อมั่นในประสบการณ์จริงว่าเป็นวิธีที่ดีกว่าในการทำงานในลักษณะการทดสอบครั้งแรกในสภาพแวดล้อมการทำงานเฉพาะของเราและสามารถนำไปสู่ การปรับปรุงคุณภาพของซอฟต์แวร์ของเราเนื่องจากฉัน เราพบว่าง่ายต่อการติดกับการทดสอบครั้งแรกโดยใช้ BDD เพื่อชี้แจงเพิ่มเติมส่วนใหญ่ของการทดสอบหน่วยที่เรามีแนวโน้มที่จะค่อนข้างเปราะบางและยากที่จะรักษาเป็นโฮลดิ้งจากปีของการทดสอบที่ใช้ไม่ดีที่ไม่เต็มใจที่จะยึดติดกับกระบวนการทดสอบขับเคลื่อนได้เห็นนักพัฒนาถอยกลับ ทำการทดสอบทั้งหมดเมื่อสิ้นสุดโครงการ (บุคคลเดียวกันนี้อ้างว่าเป็น Agile!)

ดังนั้นคำถามจริง ๆ มีดังต่อไปนี้:

1. ฉันสามารถใช้ข้อโต้แย้งอะไรในการผลักดันจุดกลับบ้านจริง ๆ ว่ามันจะดีกว่าสำหรับทีมนี้ที่จะใช้ StoryQ หรืออย่างน้อยที่สุดก็เพื่อใช้ระเบียบวิธี BDD?
2. คุณสามารถชี้ให้ฉันเห็นหลักฐานใด ๆ ที่ฉันสามารถใช้เพื่อสนับสนุนการโต้แย้งของฉันที่จะนำ BDD มาใช้เป็นวิธีมาตรฐานที่เราเลือกได้หรือไม่?
3. คุณคิดว่าการโต้แย้งแย้งนั้นสามารถแนะนำว่าความปรารถนาของฉันในการสนับสนุนให้ทีมนำ BDD มาใช้อาจมีข้อผิดพลาดหรือไม่? ใช่ฉันมีความสุขที่จะได้รับการพิสูจน์ผิดหากอาร์กิวเมนต์เป็นเสียงหนึ่ง

หมายเหตุ : ฉันไม่ได้สนับสนุนให้เราเขียนการทดสอบของเราใหม่ทั้งหมด แต่ให้เริ่มต้นการทำงานในลักษณะที่แตกต่างกันสำหรับการทดสอบในอนาคตทั้งหมดและควรใช้วิธีที่เราดึงดูดลูกค้า

และสำหรับผู้ที่ต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ BDD ลิงก์ต่อไปนี้อาจมีประโยชน์:

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

_{สำหรับผู้ที่สนใจรายละเอียดเพิ่มเติมเราเป็นทีมขนาดเล็ก 4 คนที่ทำงานเกี่ยวกับ 5 โครงการขนาดใหญ่ "การทดลองใช้นักบิน" สำหรับ BDD นั้นใช้เวลาประมาณ 2 เดือนในขั้นต้นและอีกประมาณ 4 เดือนหลังจาก ทีมยอมรับว่าฉันควรทำงานนี้ต่อไปและทำการทดลองด้วยตัวเอง ฉันใช้ BDD มาประมาณ 2 ปีแล้วตั้งแต่การทดลองสิ้นสุดลงในขณะที่คนอื่น ๆ ก็เก่งเรื่องการอ่าน แทนที่จะบังคับให้ "เผชิญหน้า" กับเรื่องนี้ฉันกำลังมองหาวิธีที่จะโน้มน้าวให้ทีมค่อยๆละทิ้งกลุ่มของพวกเขาและทำเวลาที่จะทำ}

ฉันสามารถใช้ข้อโต้แย้งอะไรในการผลักดันจุดกลับบ้านให้ดีกว่าการใช้ StoryQ หรือใช้วิธีการ BDD อย่างน้อยที่สุด

"ลูกค้าต้องการมัน"

IMO คุณต้องการขาย BDD ให้กับลูกค้า / ผู้เชี่ยวชาญด้านโดเมนอย่างน้อยเท่ากับทีมพัฒนา

BDD เป็นกระบวนการทำงานร่วมกันภายนอกซึ่งมีผู้มีส่วนเกี่ยวข้องหลายฝ่ายเข้าร่วม ประโยชน์ของ BDD ไม่เพียง แต่สำหรับนักพัฒนาที่จะอนุมานรหัสทดสอบของพวกเขาโดยอัตโนมัติจากการทดสอบการยอมรับพวกเขายังอยู่ในความร่วมมืออย่างสร้างสรรค์ที่เกิดขึ้นระหว่างนักวิชาการและนักธุรกิจในการสร้างข้อกำหนดที่มีคุณค่าและกำหนดไว้อย่างดี

การให้ลูกค้า / นักวิเคราะห์ธุรกิจเข้าถึงอินเทอร์เฟซที่สามารถเรียกใช้ข้อมูลจำเพาะที่สามารถดำเนินการได้แต่ละรายการควบคุมสถานะของพวกเขาและดูความคืบหน้าในการดำเนินการตามปกติ

มีการนำเสนอโดย Dan North เกี่ยวกับวิธีที่คุณสามารถขาย BDD ให้กับธุรกิจได้: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. ในทีมลังเลที่จะใช้ BDD มีแนวโน้มว่าจะไม่มี "ข้อโต้แย้ง" ที่คุณสามารถใช้เพื่อ "แปลง" เพื่อนร่วมงานของคุณเป็นการยอมรับอย่างเต็มรูปแบบ
    
   ฉันคิดว่าสิ่งที่ดีที่สุดที่คุณทำได้คือการโน้มน้าวให้พวกเขาลอง ("การทดสอบควัน", "การทดสอบควัน", "โครงการนำร่อง") - โดยเฉพาะอย่างยิ่งถ้าคุณทำให้ชัดเจนว่าคุณจะทิ้งความคิดหากผลการทดสอบ เป็นลบ
2. วิธีการของคุณในการหาหลักฐานพอสมควรตรงกับแนวคิดของทีมที่น่าเชื่อถือเพื่อลองทำ สำหรับสิ่งนั้นฉันเพียงแค่ค้นหาเว็บเช่น"เรื่องราวความสำเร็จของการขับเคลื่อนการพัฒนาพฤติกรรม"และเลือกสิ่งที่รู้สึกได้ง่ายกว่าที่จะใช้กับฉัน
3. มีข้อโต้แย้งสองสามข้อที่ฉันสามารถคิดได้ว่าอาจเป็นข้อเสนอแนะว่าความปรารถนาของคุณในการแปลงความพยายามของทีมเป็น BDD อาจผิดพลาด
    
   สิ่งเหล่านี้ไม่ได้สร้างสรรค์อะไรเป็นพิเศษโดยเฉพาะอย่างยิ่งจากมุมมองของ "ผู้สนับสนุนการเปลี่ยนแปลง" แต่น่าเสียดายที่คุณอาจต้องรับมือกับวาทศาสตร์ประเภทนี้ ( BTDTGTTS ):
    
   • คุณไม่สามารถรับประกันได้ว่าประสิทธิภาพโดยรวมของทีมจะดีขึ้น
   • คุณไม่สามารถรับประกันได้ว่าความพยายามที่ลงทุนเพื่อนำไปใช้ BDD จะให้ผลตอบแทนการลงทุนที่สำคัญ
   • ทีมทำงานได้ดีโดยไม่มี BDD ความเสี่ยงในการเปลี่ยนแนวทางปัจจุบันไม่เป็นธรรม
   • Google (หรือ Microsoft หรือ IBM - เพียงแค่กรอกชื่อของผู้ขายซอฟต์แวร์ "ที่น่านับถือ") โดยไม่ต้องใช้ BDD ซึ่ง "พิสูจน์" ว่า BDD นั้นไม่จำเป็น
   • วิธีการที่ไม่ใช่ BDD ไม่ได้รับโอกาสที่เป็นธรรมในการทดสอบเปรียบเทียบ
   • BDD อาจโดยทั่วไปตกลง แต่สำหรับสิ่งนี้และโมดูล / โครงการนั้นไม่สามารถใช้ได้

จากประสบการณ์ของฉันวิธีที่เจ็บปวดน้อยที่สุดในการจัดการกับข้อโต้แย้งอย่างที่กล่าวข้างต้นคือการทำการทดสอบที่ควบคุมอย่าง จำกัดสำหรับการเปลี่ยนแปลงที่เสนอ

สถานะ "การทดสอบที่ จำกัด " นั้นทำให้การโต้แย้งสามในสี่ข้างต้นเป็นโมฆะยกเว้นหนึ่งรายการเกี่ยวกับ "ผู้ขายที่น่าเชื่อถือ" ซึ่งสามารถโต้กลับได้โดยการให้หลักฐานประวัติความสำเร็จที่ประสบความสำเร็จ การทดสอบที่ จำกัด นั้นดีพอ)

หากการเปลี่ยนแปลงนั้นคุ้มค่าและมีการทดสอบการทำงานอย่างถูกต้องคุณจะสังเกตเห็นการเปลี่ยนแปลงเชิงบวกในทัศนคติของทีมและการจัดการทำให้การเปลี่ยนไปสู่การเปลี่ยนแปลงเต็มรูปแบบราบรื่นและไม่เจ็บปวด

ประโยชน์อีกประการของการทดสอบแบบ จำกัด นั้นช่วยให้คุณสามารถชี้แจงและปรับรายละเอียดกระบวนการเป้าหมายได้โดยไม่ก่อให้เกิดปัญหามากเกินไปและมีความเสี่ยงต่ำในการ "ทำลายชื่อเสียง" ต่อแนวคิด ทุกครั้งที่ฉันเข้าร่วมในการทดสอบครั้งนี้ฉันรู้สึกประหลาดใจอย่างยิ่งที่ได้รู้ว่ามันราบรื่นแค่ไหนที่จะเปลี่ยนมาใช้การรับรองเต็มรูปแบบโดยมีรายละเอียดที่สำคัญที่สุดและชี้แจงในการทดสอบ

อาจถึงเวลารับสมัครผู้บริหาร หากคุณได้ลองและเห็นผลที่มั่นคง แต่ทีมกำลังรบกวนการจัดการอาจต้องมีส่วนร่วม

นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งหากพวกเขาทำร้ายสมาชิกในทีมที่มีประสิทธิผลมากที่สุดของ บริษัท เตรียมพร้อมสำหรับการฟันเฟือง คุณอาจเริ่มต้นด้วยการเข้าหาผู้บริหารและหาทางให้ทีมหยุดการตัดราคาคุณโดยการทำกรณีทดสอบ