เป็นไปได้ที่จะเรียกตัวเองอย่างถูกต้อง (หรือทีมของคุณ) "ว่องไว" ถ้าคุณไม่ทำ TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ)?

ใช่ใช่ใช่ล้านครั้งใช่

Agile เป็นปรัชญา TDD เป็นวิธีการเฉพาะ

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

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

คุณต้องการทดสอบหน่วยหรือไม่? แน่นอนว่าคุณทำด้วยเหตุผลทุกประการ - และคุณอาจโต้แย้งว่าคุณไม่คล่องถ้าไม่มีการทดสอบหน่วย (แม้ว่าฉันสงสัยว่าคุณสามารถ) - แต่คุณไม่จำเป็นต้องเขียนก่อน เปรียว

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

ดูเหมือนว่าคนอื่น ๆ (ที่มีตัวแทน SOLID มากกว่า) มีความคิดเห็นที่คล้ายกัน ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cSแม้ว่าจะไม่สามารถทำ Agile ได้หากไม่มี TDD และ OOD แต่ก็เป็นเรื่องยาก หากไม่มี TDD อัตราการวนซ้ำของ ...

(ลิงค์ในทวีตคือคำตอบทั้งหมดใน LinkedIn)

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

ใช่คุณสามารถคล่องแคล่วโดยไม่ต้องทำการทดสอบ TDD หรือหน่วย

ฉันไม่อยากจะแนะนำว่า ...

ใช่ ,

ดูหนึ่งในค่าความคล่องตัว:

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

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

ฉันจะสรุปได้เช่น:

• วันนี้ TDD เป็นมาตรฐานสำหรับความคล่องแคล่ว

• อาจมีวิธีการที่คล่องตัวโดยไม่มี TDD

ฉันพูด

ไม่ [เรียงจาก]

หากคุณกลับไปที่แหล่งต้นฉบับhttp://en.wikipedia.org/wiki/Extreme_Programming TDD นั้นเป็นพื้นฐานของกระบวนการ การทดสอบแทนที่ข้อกำหนดเฉพาะและกรณีการใช้น้ำตกทำหน้าที่เป็นเอกสารประกอบการใช้ชีวิตและตัวอย่างการใช้งาน ฯลฯ สิ่งเหล่านี้ขาดไม่ได้

อย่างไรก็ตามมีรสชาติที่แตกต่างกันมากมายของ 'เปรียว' ที่ลอยไปมาในตอนนี้ซึ่งเป็นไปได้ทั้งหมดที่หนึ่งในนั้นหลบเลี่ยง TDD

แก้ไข: @ การตีความ Murph ของคำถามที่ดูเหมือนจะเป็นที่ต้องการ Heck ฉัน upvoted มันเป็นคำตอบที่ดี อย่างไรก็ตามฉันยังคงรักษาตำแหน่งของฉันไว้อย่างชัดเจนว่า Agile Manifesto เป็นชุดของหลักการไม่ใช่วิธีการพัฒนา ฉันไม่เห็นประโยชน์ในการพูดว่า "โอ้ใช่ฉันว่องไว" โดยไม่ต้องใช้วิธีปฏิบัติที่ก่อให้เกิดประโยชน์ โดยเฉพาะอย่างยิ่ง:

ซอฟต์แวร์ที่ใช้งานเป็นมาตรการหลักของความคืบหน้า

และ

กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน สปอนเซอร์นักพัฒนาและผู้ใช้ควรจะสามารถรักษาอัตราการคงที่อย่างต่อเนื่อง

สำหรับฉันหลักการสองข้อนี้บอกเป็นนัยว่าหากไม่ต้องการ TDD - อย่างน้อยฉันก็รู้ว่าไม่มีวิธีอื่นใดที่จะทำให้บรรลุผลสำเร็จหากปราศจากมัน!

แก้ไข 2: ใช่ในทางเทคนิคคุณสามารถเขียนการทดสอบในภายหลัง แต่ฉันยังถือว่าการทดสอบครั้งแรก / TDD เป็นพื้นฐาน ไม่ใช่เพราะคุณไม่สามารถ "ว่องไว" หากปราศจากมัน แต่เพราะคุณจะว่องไวขึ้นด้วย การทดสอบครั้งแรก / การทดสอบขับเคลื่อนเป็นวิธีที่มีประสิทธิภาพมากกว่าการทดสอบในภายหลัง / ทดสอบภายหลัง คำอธิบายการทดสอบมีความต้องการ อย่านำไปใช้จนกว่าจะภายหลัง ;-)

แก้ไข 3: ในที่สุดฉันก็ค้นพบสิ่งที่รบกวนจิตใจฉันมากเกี่ยวกับคำตอบที่เขียนได้ดีของ Murph มันเป็นความคิดที่ว่าว่าจะ "เป็นเปรียว" ไม่จริงทำมัน และ "ลงมือทำ" (ดังที่แสดงไว้ด้านบน) ค่อนข้างต้องใช้ TDD

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

คุณสามารถคล่องแคล่ว แต่อาจมีที่ว่างสำหรับการปรับปรุง

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

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

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

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

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

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

ดังนั้น TDD จึงช่วยหลีกเลี่ยงการผลิตมากเกินไปทำให้ทีมมีประสิทธิภาพมากที่สุดซึ่งเป็นหลักการที่สำคัญอย่างว่องไว

ซอฟต์แวร์ที่ใช้งานเป็นมาตรการหลักของความคืบหน้า

คุณสามารถเป็น Agile ได้หรือไม่โดยไม่ต้องทำการพัฒนา TDD (การทดสอบด้วยการพัฒนา)?

คำตอบสั้น ๆ : ใช่

คำตอบอีกต่อไป: มีคำตอบที่ดีมากสำหรับคำถามนี้และการอ้างอิงที่ดีมาก ฉันจะไม่พยายามอภิปรายประเด็นเหล่านั้น

จากประสบการณ์ของฉัน Agile กำลังเลือกระดับที่เหมาะสมของ Lean-ness สำหรับโครงการในมือ Lean-ness หมายถึงอะไร แล้วทำไมฉันถึงต้องตอบคำถามนี้?

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

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

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

ดังนั้นห่วงโซ่อุปทานโดยรวมต้องทนทุกข์ทรมานหากการเพิ่มประสิทธิภาพในท้องถิ่นได้รับอนุญาตโดยไม่คำนึงถึงทั้งหมด

กลับไปที่ TDD และ UT TDD เป็นกลไกการแสดงออกของข้อกำหนด ระบบจะต้องปฏิบัติตามข้อ จำกัด เหล่านั้น ยุติธรรมพอสมควร TDD สามารถแทนที่พฤติกรรมความต้องการใช้ Case Drive Development หรือพฤติกรรมความต้องการของ User Development Driven Development มันมีประโยชน์ "เอน" ในการรวมการทดสอบหน่วยและภาระงาน มันจะเป็นประโยชน์ถ้าภาระงานโดยรวมลดลง ไม่ใช่ถ้าปริมาณงานโดยรวมของซัพพลายเชนเพิ่มขึ้น (เรามาแก้ไขคุณภาพ)

และดังนั้นคุณถาม: คุณสามารถเปรียวโดยไม่ต้องทำ TDD (ทดสอบขับเคลื่อนการพัฒนา)?

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

หากต้องการอ้างถึงผู้แต่งคนโปรด ... JRR Tolkien

ลอร์ดออฟเดอะริ มิตรภาพแห่งแหวน หน้า 94 'มีคำกล่าวอีกว่า' และโฟรโดตอบว่า 'อย่าไปหาพวกเอลฟ์เพื่อขอคำแนะนำเพราะทั้งคู่จะไม่และใช่'

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

ไปที่ TDD หรือไม่ไปยัง TDD นั่นคือคำถาม :-)

PS - ฉันโพสต์คำตอบนี้ในเว็บไซต์อื่นด้วย https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

เปรียบเทียบกับวิศวกรรมปราสาท

ปราสาทเปรียว

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

ปราสาท TDD

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

ปราสาท TDD เปรียว

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

ข้อสรุป

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

TDD แก้ปัญหาการคาดการณ์ความล้มเหลว การค้นหาและแก้ไขความล้มเหลวเมื่อมันเกิดขึ้น ณ จุดหนึ่งในกระบวนการที่ง่ายที่สุดในการแก้ไข มันเกี่ยวข้องกับการทดสอบหน่วย de-coupled ที่มีเสถียรภาพของรหัสที่แยกออกจากการออกแบบโดยรวม

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

หมายเหตุ

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

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

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