ประสิทธิภาพค่าใช้จ่ายสัมพัทธ์ของการทดสอบขับเคลื่อน (ยอมรับ)

ฉันต้องการทราบว่าผลกระทบโดยรวมของการวางแผนทรัพยากรในโครงการซอฟต์แวร์คืออะไรซึ่งความต้องการและการออกแบบของโครงการนั้นเกิดจากการทดสอบการยอมรับอัตโนมัติและการทดสอบหน่วยในทางตรงกันข้ามกับแนวทางการพัฒนาซอฟต์แวร์แบบดั้งเดิม

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

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

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

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

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

ส่วนใหญ่แล้ว TDD นั้นทำเพราะมันส่งผลให้โค้ดดีขึ้น โดยเฉพาะอย่างยิ่ง TDD ผลในรหัสที่เป็นเรื่องง่ายที่จะเปลี่ยนแปลง

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

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

การทดสอบหน่วยที่ดีให้ข้อดีดังต่อไปนี้:

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

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

เพื่อสรุป:

การพัฒนาเวอร์ชั่น 1 อาจช้ากว่านี้ การพัฒนาเวอร์ชั่น 2-10 จะเร็วขึ้น

มีบทในเรื่องการทำซอฟแวร์เกี่ยวกับการทดสอบขับเคลื่อนการพัฒนาซึ่งอ้างอิงกระดาษกล่าวถึงที่นี่

กรณีศึกษาถูกดำเนินการกับทีมพัฒนาสามทีมที่ Microsoft และอีกทีมหนึ่งที่ IBM ซึ่งใช้ TDD ผลจากกรณีศึกษาระบุว่าความหนาแน่นข้อบกพร่องก่อนวางจำหน่ายของผลิตภัณฑ์ทั้งสี่ลดลงระหว่าง 40% และ 90% เมื่อเทียบกับโครงการที่คล้ายกันซึ่งไม่ได้ใช้วิธีฝึก TDD ทีมพบว่าเวลาในการพัฒนาเริ่มต้นเพิ่มขึ้น 15-35% หลังจากใช้ TDD

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

ฉันไม่มีเอกสารการวิจัยหรือสถิติใด ๆ ที่จะให้คุณ แต่ฉันจะเล่าประสบการณ์ของฉันจากการทำงานในทีม / องค์กรที่ในอดีตมีการครอบคลุมการทดสอบหน่วยต่ำถึงเฉลี่ยและไม่มีการทดสอบแบบ end-to-end และค่อยๆ ย้ายแถบเพื่อที่เรามีตอนนี้มีมากขึ้นของ ATDD ( แต่กระทบกระเทียบไม่ TDD ดั้งเดิม) วิธีการ

นี่คือวิธีที่ระยะเวลาโครงการใช้ในการเล่น (และยังคงเล่นกับทีม / ผลิตภัณฑ์อื่น ๆ ในองค์กรเดียวกัน):

• นานถึง 4 สัปดาห์ของการวิเคราะห์และการใช้งาน
• 2 สัปดาห์ของการทดสอบการถดถอยการแก้ไขข้อบกพร่องการทำให้เสถียรและการเตรียมการเผยแพร่
• 1-2 สัปดาห์ของการแก้ไขข้อบกพร่องที่รู้จัก
• การล้างข้อมูลโค้ดและการสนับสนุนหลังการผลิตประมาณ 2-3 สัปดาห์ (ข้อบกพร่องที่ไม่รู้จัก / การหยุดทำงานที่ไม่ได้วางแผนไว้)

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

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

ในทางตรงกันข้ามการเปิดตัวทุกครั้งนับตั้งแต่การเปิดตัวครั้งแรกนั้นมีเกณฑ์การยอมรับและการทดสอบการยอมรับก่อนหน้านี้และการทำซ้ำปัจจุบันของเรามีลักษณะดังนี้:

• 8 วันของการวิเคราะห์และการใช้งาน
• 2 วันของการรักษาเสถียรภาพ
• 0-2 วันรวมการสนับสนุนหลังการผลิตและการล้างข้อมูล

กล่าวอีกนัยหนึ่งเราคืบหน้าจากค่าบำรุงรักษา 55-65% เป็น 20-30% ค่าใช้จ่ายในการบำรุงรักษา ทีมเดียวกันผลิตภัณฑ์เดียวกันความแตกต่างหลักคือการปรับปรุงอย่างต่อเนื่องและความคล่องตัวของการทดสอบการยอมรับของเรา

ค่าใช้จ่ายในการบำรุงรักษาคือ 30 วันสำหรับนักวิเคราะห์ QA และต่อนักพัฒนา 1-2 วัน ทีมงานของเรามีนักพัฒนา 4 คนและนักวิเคราะห์ประกันคุณภาพ 2 คน (ไม่นับ UX, การจัดการโครงการ ฯลฯ ) ซึ่งเป็นจำนวนสูงสุด 7 วันทำการจาก 60 วันซึ่งฉันจะได้รับค่าใช้จ่ายในการดำเนินงาน 15% ด้านความปลอดภัย

เราใช้จ่าย 15% ของแต่ละช่วงเวลาในการพัฒนาการทดสอบการยอมรับอัตโนมัติและในกระบวนการสามารถลด 70% ของแต่ละรุ่นที่ทำการทดสอบการถดถอยและแก้ไขข้อบกพร่องก่อนการผลิตและหลังการผลิต

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

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

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

ATDD จะช่วยคุณในโครงการระยะยาวที่ดำเนินการในรูปแบบ RUP หรือ (ugh) Waterfall หรือไม่โครงการที่ใช้เวลานาน 3 เดือนหรือมากกว่า? ฉันคิดว่าคณะลูกขุนยังคงอยู่ในนั้น จากประสบการณ์ของฉันความเสี่ยงที่ใหญ่ที่สุดและเลวร้ายที่สุดในโครงการระยะยาวคือวันครบกำหนดที่ไม่สมจริงและข้อกำหนดที่เปลี่ยนแปลง กำหนดเวลาที่ไม่สมจริงจะทำให้คนใช้ทางลัดรวมถึงการทดสอบทางลัดและการเปลี่ยนแปลงข้อกำหนดที่สำคัญจะทำให้การทดสอบจำนวนมากทำให้การทดสอบเหล่านั้นต้องใช้ซ้ำและทำให้การใช้งานเกินจริง

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

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

ข้อกำหนดด้านทรัพยากร

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

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

• refactors ขนาดใหญ่
• การอัพเกรดแพลตฟอร์ม / แพ็คเกจ
• การโยกย้ายแพลตฟอร์ม
• การอัพเกรด Toolchain

นี่คือการสมมติว่าทีมที่คุ้นเคยกับกระบวนการและการปฏิบัติที่เกี่ยวข้อง

การมีส่วนร่วมของลูกค้า

ต้องใช้ความพยายามมากแค่ไหนจากลูกค้า?

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

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

การประมาณโครงการ

ฉันคิดว่าการประมาณเวลาจะคลุมเครือมากในกระบวนการ TDD วนซ้ำเมื่อเริ่มต้นโครงการ TDD (เนื่องจากไม่มีแผนพัฒนาซอฟต์แวร์)

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

ตัวอย่างเช่น:

"sprints" ของทีมของฉันใช้เวลาหนึ่งสัปดาห์และเรามีค่าเฉลี่ยและ std ความเบี่ยงเบนของ 14 สัปดาห์ที่ผ่านมา หากโครงการคือ 120 คะแนนเรามีค่าเฉลี่ย 25 ​​และ std ความเบี่ยงเบนของ 6 จากนั้นประมาณความสำเร็จของโครงการคือ:

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

เราใช้ 2 Std ส่วนเบี่ยงเบนกฎง่ายๆสำหรับการประเมินความมั่นใจ 95% ของเรา ในทางปฏิบัติเรามักจะทำโครงการให้เสร็จสมบูรณ์ใน std แรก เบี่ยงเบน แต่เหนือค่าเฉลี่ยของเรา ซึ่งมักเกิดจากการปรับแต่งการเปลี่ยนแปลง ฯลฯ

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

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

ปัญหาของนักพัฒนาคือพวกเขามักจะนำไปใช้แม้กระทั่งสิ่งที่ไม่จำเป็นต้องใช้ในการสร้างซอฟต์แวร์ทั่วไปเท่าที่จะทำได้

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

นั่นไม่ควรสำคัญ ใครก็ตามที่ทำข้อกำหนดควรทำมันให้ดีที่สุด

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

ดังนั้นหากพวกเขาต้องการทำ BDUF ให้พวกเขาทำ มันจะทำให้ชีวิตของคุณง่ายขึ้นในฐานะนักพัฒนา