เปรียวโดยไม่ต้องทดสอบหน่วย

มันสมเหตุสมผลหรือไม่ที่จะพูดถึง "การพัฒนาที่คล่องตัว" หรืออ้างว่าคุณกำลังใช้ "วิธีการที่คล่องตัว" ถ้ารหัสฐานที่คุณกำลังทำงานอยู่มีการครอบคลุมการทดสอบหน่วย 0% (และคุณในฐานะทีมไม่ได้ทำอะไรเกี่ยวกับเรื่องนี้)

เพื่อให้ชัดเจน: สำหรับฉันมันไม่สมเหตุสมผล จากประสบการณ์ส่วนตัวของฉันฉันพบว่าการทดสอบหน่วยเป็นเครื่องมือเดียวที่ช่วยให้คุณ "คล่องแคล่ว" (เช่นตอบสนองต่อการเปลี่ยนแปลงปรับปรุงการออกแบบของคุณแบ่งปันความรู้ ฯลฯ ) และ TDD เป็นวิธีปฏิบัติเดียวที่จะพาคุณไปที่นั่น .

อาจมีวิธีอื่นบ้าง แต่ฉันก็ยังไม่เห็นว่าพวกเขาจะทำงานได้อย่างไร

ไม่มีอะไรใน Agile Manifesto หรือ Scrum Guide ที่อ้างอิงถึงวิธีปฏิบัติทางเทคนิคใด ๆ เช่นการทดสอบหน่วยหรือ TDD ดังนั้นใช่ในทางทฤษฎีคุณสามารถส่งมอบต้นและมักจะให้ความสำคัญกับการทำงานร่วมกันและความคุ้มค่าโดยที่พวกเขาและเรียกตัวเองเปรียวคุณก็จริงอาจมีความคล่องตัว

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

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

แถลงการณ์เปรียวเพียง:

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

ไม่มีการเอ่ยถึงการทดสอบหน่วยที่นั่น แม้แต่หลักการ 12 ข้อที่ไม่ได้กล่าวถึงการทดสอบ

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

แม้ว่าจะไม่มีคำโดยตรงที่ระบุเกี่ยวกับการทดสอบหน่วยหรือ TDD หรือการทดสอบใด ๆ ในรายการที่มีความคล่องตัวเหมือนที่คนอื่น ๆ ได้ตอบไว้ที่นี่

ซอฟต์แวร์ที่ทำงาน  ผ่านเอกสารที่ครอบคลุม

ทุกคนจะรู้ได้อย่างไรว่าซอฟต์แวร์ทำงานได้ดี รายการไม่จำเป็นต้องระบุคำทดสอบอย่างชัดเจน มันรวบรัด

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

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

ไม่คุณไม่จำเป็นต้องทำการทดสอบหน่วยเลย

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

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

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

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

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

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

ฉันต้องการที่จะโต้เถียง (คำตอบอื่น ๆ ) ว่าแถลงการณ์เปรียวระบุอย่างชัดเจนเกี่ยวกับเรื่องนี้คือ:

การเอาใจใส่อย่างต่อเนื่องเพื่อความเป็นเลิศทางเทคนิค และการออกแบบที่ดีช่วยเพิ่มความคล่องตัว

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

ความคล่องตัวขององค์กรถูก จำกัด ด้วยความคล่องตัวทางเทคนิค

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

หากคุณสามารถป้องกันผลิตภัณฑ์ของคุณจากการต่อต้านการเปลี่ยนแปลงในอีกทางหนึ่งคุณอาจกำลังถูกทาง แต่:

ฉันคิดค้น Extreme Programming เพื่อทำให้โลกปลอดภัยสำหรับโปรแกรมเมอร์ - เคนท์เบ็ค

การต่อสู้ขาดการปฏิบัติทางเทคนิคใด ๆ แต่เจฟฟ์พูดดังต่อไปนี้:

ฉันไม่เคยเห็นทีมต่อสู้แย่งชิงผลประโยชน์เกินขีดที่ไม่ได้ใช้แนวทางการพัฒนา Extreme Programming - Jeff Sutherland

อ้างถึงจากบทความนี้: http://ronjeffries.com/articles/017-02ff/gathering2017/

ฉันคาดหวังว่าทีมการต่อสู้โดยปราศจากการฝึกฝนเชิงเทคนิคในที่สุดโดยการใช้การหวนกลับมาพร้อมกับการฝึกฝนที่คล้ายกัน คุณต้องการที่จะมีประสิทธิผลเกินเช่นกันใช่ไหม

แบบจำลองความคล่องแคล่วว่องไวกล่าวถึงในระดับดาวสองดวง:

เทคนิคที่มีประโยชน์รวมถึงการรวมอย่างต่อเนื่องการพัฒนาที่ขับเคลื่อนด้วยการทดสอบการเขียนโปรแกรมคู่

หากคุณตั้งเป้าหมายเพียงระดับแรกของความคล่องแคล่วว่องไวคุณสามารถข้ามการฝึกซ้อมได้ แต่ผลิตภัณฑ์ที่มีขนาดใหญ่กว่าและยาวกว่านั้นควรพยายามให้ได้ระดับดาวสองดวงอย่างน้อยที่สุด

ดังนั้นฉันทามติทั่วไปคือใช่โดยไม่ต้องมีการทดสอบหน่วยที่ดีรหัสที่สะอาดและวิธีปฏิบัติในการรีแฟคเตอร์ตอนนี้มันเป็นไปไม่ได้ที่จะมีความคล่องตัวอย่างแท้จริง สิ่งนี้อาจเปลี่ยนแปลงได้ในอนาคตเมื่อมีการปฏิบัติทางเทคนิคใหม่ ๆ

คุณคิดว่าคำตอบจะเป็นอย่างไรถ้าเราถามผู้ลงนามในแถลงการณ์เช่น Robert C. Martin, Martin Fowler หรือ Kent Beck พวกเขาอาจจะบอกว่ามันขึ้นอยู่กับ แต่โดยทั่วไปมันเป็นสิ่งที่คุณควรทำ