ทำอย่างไรจึงจะประสบความสำเร็จในการประชุมเชิงปฏิบัติการ BDD


9

วันนี้เราพยายามแนะนำ BDD ในกระบวนการพัฒนาซอฟต์แวร์ของเราโดยมีเวิร์กช็อปสเปค

สำหรับเวิร์คช็อปนี้เรามีนักพัฒนา 2 คนผู้ทดสอบ 1 คนและนักวิเคราะห์ธุรกิจ 1 คน การประชุมเชิงปฏิบัติการใช้เวลา 1h30 และในตอนท้ายเราได้จัดการกับสถานการณ์ BDD บางอย่างสำหรับคุณสมบัติใหม่ของเรา เราพยายามที่จะมุ่งเน้นไปที่การค้นหาสถานการณ์ที่เราอาจพลาดและสิ่งที่ยากลำบาก

ในตอนท้ายของการประชุมเชิงปฏิบัติการบางคนไม่พอใจกับการประชุมเชิงปฏิบัติการ

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

การประชุมเชิงปฏิบัติการทดลองนี้ใช้เวลา 1h30 และในตอนท้ายเราไม่รู้สึกมั่นใจเพียงพอเกี่ยวกับสิ่งที่เราทำ ... แน่ใจว่าเราสามารถใช้เวลากับมันได้ แต่คนส่วนใหญ่หมดแรงหลังจากการระดมสมองใน 1h30 เพื่อดึงธุรกิจออกมา กฎจากสมองของ BA

ดังนั้นคำถามของฉันคือวิธีการประชุมเชิงปฏิบัติการประเภทนั้นสามารถทำงานได้จริง ในทางทฤษฎีเมื่อคุณมีคุณสมบัติใหม่ในการพัฒนาคุณวางต้นไม้ 'amigos' (dev / tester / ba) ในห้องเดียวกันเพื่อให้พวกเขาสามารถทำงานร่วมกันในการเขียนข้อกำหนด differents สำหรับคุณลักษณะใหม่โดยใช้ตัวอย่าง ฉันเห็นประโยชน์ทั้งหมดจากสิ่งนั้น พิเศษในแง่ของการแบ่งปันความรู้และผลิตภัณฑ์ทั่วไป / เป้าหมายสุดท้าย / ทำวิสัยทัศน์

บทสรุปของเราจากการทดลองนี้คือจริง ๆ แล้วมันคุ้มค่ากว่าการได้รับปริญญาตรีในการทำงานด้วยตนเองในตัวอย่างและจากนั้นจะมีสถานการณ์ที่จะต้องตรวจสอบ / ทำใหม่โดย 3 'amigos'. โดยการให้ BA ทำงานด้วยตัวเองจริง ๆ แล้วเรารู้สึกมั่นใจมากขึ้นว่าเราจะพลาดสิ่งต่าง ๆ น้อยลง + เรายังได้ทบทวนสถานการณ์หลังจากนั้นเพื่อตรวจสอบอีกครั้ง เราไม่คิดว่าจะง่ายไปกว่าการระดมสมอง / การค้นพบครั้งเดียวที่ง่ายพอที่จะครอบคลุมความต้องการทั้งหมดสำหรับคุณสมบัติใหม่อย่างจริงจัง นักวิเคราะห์ธุรกิจเป็นบุคคลที่ดีที่สุดสำหรับสิ่งนั้น สิ่งที่ดีที่สุดที่เราสามารถทำได้คือทบทวนสิ่งที่เธอเขียนและดูว่าเรามีความเข้าใจร่วมกันหรือไม่ (ซึ่งอาจนำไปสู่การเขียนสถานการณ์ของเธอใหม่หรือเพิ่มสิ่งใหม่ที่เธออาจพลาด)

ดังนั้นคุณจะทำให้การฝึกปฏิบัตินั้นมีประสิทธิภาพได้อย่างไร

คำตอบ:


4

หากคุณสามารถรับสถานการณ์จากคำอธิบายคุณทำเสร็จแล้ว

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

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

ในทำนองเดียวกันฉันอาจพูดว่า "นี่คือแบบฟอร์มสำหรับการลงทะเบียนผู้ใช้เราต้องสามารถสร้างผู้ใช้ใหม่ให้พวกเขาแก้ไขรายละเอียดและลบตัวเองยกเว้นการลบนั้นไม่ควรลบจริง ๆ มันควรจะทำเครื่องหมายว่าถูกลบ เพื่อให้พวกเขาสามารถกู้คืนบัญชีได้หากต้องการ "

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

"มันอาจเป็นคุณสมบัติสองอย่างถ้าคุณต้องการ"

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

โดยทั่วไปหากคำอธิบายพฤติกรรมเพียงพอสำหรับทีม dev ที่จะได้รับสถานการณ์คุณไม่จำเป็นต้องพูดคุยกับพวกเขา คุณสามารถทำได้หากมีข้อสงสัยใด ๆ แต่คุณอาจต้องการบันทึกสถานการณ์ที่คุณต้องจำถ้าคุณจับภาพใด ๆ เลย

หากคุณไม่เคยทำมาก่อนหรือไม่แน่ใจให้คุยผ่านสถานการณ์ต่างๆ

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

ได้รับบริบท
เมื่อมีเหตุการณ์เกิดขึ้น
จากนั้นผลลัพธ์ควรเกิดขึ้น

  • มีบริบทอื่น ๆ ซึ่งสำหรับเหตุการณ์เดียวกันก่อให้เกิดผลลัพธ์ที่แตกต่างกันหรือไม่?
  • มีผลลัพธ์อื่นใดที่สำคัญหรือไม่

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

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

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

บางครั้ง BDD ไม่ทำงาน

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

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

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

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

  • สิ่งที่เรียบง่ายและซับซ้อน (รู้จัก) มักเข้าใจดีและคุณไม่จำเป็นต้องพูดถึงรายละเอียดของสถานการณ์

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

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


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

นั่นเป็นวิธีที่ดีในการวางใช่ :) นอกจากนี้การมีการสนทนาสำคัญกว่าการจดบันทึกไว้ซึ่งสำคัญกว่าการทำให้เป็นแบบอัตโนมัติ
Lunivore

ฉันพบว่า "ฉันไม่แน่ใจ" เป็นเรื่องธรรมดา บ่อยครั้งที่ใครบางคนรู้คำตอบ - แต่ไม่ใช่คนที่ devs กำลังพูดถึง การติดตามบุคคลที่ถูกต้องอาจใช้เวลาสักครู่ ...
DNA

1
@DNA ฉันได้ครอบคลุมการประมาณความซับซ้อนในรายละเอียดเพิ่มเติมในโพสต์นี้: lizkeogh.com/2013/07/21/estimating-complexity - ความสะดวกในการติดตามความเชี่ยวชาญนั้นเป็นส่วนหนึ่งของการวัด
Lunivore

5

ความยาวของการประชุมไม่ใช่ปัญหาของคุณ การประชุมเหล่านั้นใช้เวลานาน แต่ทุกคนควรออกมาจากมันรู้สึกมั่นใจ พวกเขาไม่ได้เป็นปัญหาของคุณ

ฉันอยากจะแนะนำการประชุมสั้น ๆ เพื่อหารือเกี่ยวกับข้อกำหนด กำหนดเวลาการประชุมครั้งที่สองในอีกสองสามวันต่อมาดังนั้นทุกคนจึงรู้ว่าพวกเขาจะต้องเตรียมพร้อมก่อน

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

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

จากนั้นมีการวางแผน / การประชุมการออกแบบของคุณ มีวาระการประชุมที่แน่นหนาสำหรับการประชุมครั้งนั้น (เริ่มต้นด้วยกองไพ่วางเนื้อหาที่น่าสนใจไว้ด้านบน) และไม่อนุญาตให้เดินออกนอกเส้นทาง ตรวจสอบให้แน่ใจว่าคุณออกจากการประชุมพร้อมกับการโต้แย้งทุกประเด็น


3

ตรวจสอบให้แน่ใจเสมอว่าทุกคนในการประชุมเตรียมพร้อมสำหรับหัวข้อของการประชุมนั้น!

ไม่เคยใช้การประชุมเพื่อ "ระดมสมอง" อะไรด้วยกัน มันเสียเวลาของทุกคน

สูตรทั่วไปสำหรับการประชุมที่มีประสิทธิภาพ:

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

1

เกี่ยวกับข้อร้องเรียน ...

มาเริ่มกันที่:

นักพัฒนาคนหนึ่งรู้สึกว่าเขาเสียเวลาขณะที่เขาคุ้นเคยกับการอธิบายสถานการณ์โดยตรงจากนักวิเคราะห์ธุรกิจและตรวจสอบกับเธอ

ซึ่งเป็นสิ่งที่เขาทำในการประชุมเชิงปฏิบัติการ ดังนั้นมันจึงเป็นข้ออ้างสำหรับฉัน ฉันสงสัยว่านักพัฒนาซอฟต์แวร์นี้ไม่ชอบ (หรือทั้งสองอย่าง) ตรวจสอบข้อเท็จจริงของการประชุมเชิงปฏิบัติการและข้อ จำกัด การจัดกำหนดการ

นักวิเคราะห์ธุรกิจไม่รู้สึกมั่นใจกับการครอบคลุมสถานการณ์ของเรา (มีความรู้สึกว่าเราอาจพลาดสิ่งสำคัญอื่น ๆ ไป)

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

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

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

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

นอกจากนี้หากมีความต้องการนักพัฒนาในการตรวจสอบสถานการณ์เหล่านี้กับเธอฉันค่อนข้างมั่นใจว่าการกลับไปกลับมานั้นเร็วและมีประสิทธิภาพในการประชุมเชิงปฏิบัติการมากกว่าการใช้ "ฉันทำสิ่งที่ฉันทำคนเดียวและมอบของให้กับ คุณคุณตรวจสอบมันคนเดียวและกลับมาหาฉันและลองทำสิ่งนี้อีกครั้ง "

ข้อเสนอแนะ

  • เป็นบวกและเครียดว่าถ้ากระบวนการถูกต้องคุณจะดีขึ้น

  • ลองปรับปรุงการประชุมเชิงปฏิบัติการและติดตามอย่างต่อเนื่อง

  • อาจให้บางห้องสำหรับการวิเคราะห์ "หมาป่าโดดเดี่ยว" โดยเริ่มต้นการประชุมเชิงปฏิบัติการกับทุกคนที่ออกแบบสถานการณ์บางอย่างด้วยตัวเอง (ดียิ่งขึ้นก่อนการประชุมเชิงปฏิบัติการ) จากนั้นทำการทดสอบและผสาน

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

Given enough eyeballs, all bugs are shallow.

0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.