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

อย่ารอจนกว่าคุณจะได้เรียนรู้ “ทุกอย่าง”

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

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

กำหนดขอบเขตของงานนำเสนอของคุณ

ในกรณีของฉัน ฉันตัดสินใจพูดให้เหลือ 30 นาทีและใช้เพียงตัวอย่างเดียว เพื่อที่จะทำทุกอย่างให้เสร็จภายในเวลาที่จำกัดนั้น ผมเลือกตัวอย่างง่ายๆ คือ ปัญหา " จุดตัดของเส้นตรง " แต่ปรากฎว่า แม้ตัวอย่างนี้จะยาวเกินไปสำหรับการนำเสนอ 30 นาที ดังนั้นผมจึงตัดสินใจเปลี่ยนรูปแบบ กลายเป็นปัญหา “ เส้นต่อเส้น ”

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

เตรียมตัวให้ดี

ฉันมีเวลาหนึ่งสัปดาห์ในการเตรียมตัว ฉันเริ่มต้นด้วยการใช้ TDD เพื่อจัดการกับปัญหาด้วยตัวเอง 2-3 ครั้ง จากนั้นฉันก็มองหาลำดับที่เหมาะสมที่สุดสำหรับกรณีทดสอบเพื่อแสดงให้เห็นกระบวนการ ฉันจัดเรียงกรณีทดสอบตามลำดับที่ฉันต้องการให้ปรากฏ จากนั้นฉันใช้สีเพื่อสร้างภาพวาดง่ายๆ ที่แสดงถึงกรณีที่ฉันกำลังสร้างกรณีทดสอบให้ หลังจากนั้น ฉันเขียนโค้ดทั้งตัวอย่างอีกหลายครั้ง อย่างไรก็ตาม ครั้งนี้ ฉันพูดในขณะที่กำลังเขียนโค้ดราวกับว่าฉันกำลังนำเสนอ ฉันเตรียมงานทั้งหมด 7-8 ชั่วโมง

สนุก!

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

บทสรุป

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

มีความสุขในการเรียนรู้จนถึงตอนนี้!