Agile Methodology คืออะไร? อธิบายการพัฒนาซอฟต์แวร์สมัยใหม่

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

แต่วิธีการแบบว่องไวคืออะไรและควรปฏิบัติอย่างไรในการพัฒนาซอฟต์แวร์ การพัฒนาแบบว่องไวแตกต่างจากน้ำตกในทางปฏิบัติอย่างไร? วงจรชีวิตการพัฒนาซอฟต์แวร์แบบ Agile หรือ Agile SDLC คืออะไร แล้ว scrum agile เทียบกับ Kanban และรุ่น Agile อื่น ๆ คืออะไร? 

Agile เปิดตัวอย่างเป็นทางการในปี 2544 เมื่อนักเทคโนโลยี 17 คนได้ร่าง Agile Manifesto พวกเขาเขียนหลักการสำคัญ 4 ประการสำหรับการจัดการโครงการแบบ Agile โดยมีเป้าหมายในการพัฒนาซอฟต์แวร์ที่ดีขึ้น:

  • บุคคลและปฏิสัมพันธ์กับกระบวนการและเครื่องมือ
  • ซอฟต์แวร์ที่ใช้งานได้กับเอกสารที่ครอบคลุม
  • การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา
  • การตอบสนองต่อการเปลี่ยนแปลงตามแผน

ก่อนเปรียว: ยุคของวิธีการน้ำตก

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

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

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

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

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

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

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

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

วิดีโอที่เกี่ยวข้อง: วิธีการแบบ Agile ทำงานอย่างไร

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

แกนนำไปสู่การพัฒนาซอฟต์แวร์ที่คล่องตัว

วิธีการแบบ Waterfall ได้รับการคิดค้นขึ้นในปี 1970 เนื่องจากนำระเบียบวินัยมาสู่การพัฒนาซอฟต์แวร์เพื่อให้แน่ใจว่ามีข้อกำหนดที่ชัดเจนที่จะปฏิบัติตาม มันขึ้นอยู่กับวิธีการผลิตแบบน้ำตกที่ได้มาจากนวัตกรรมสายการประกอบปี 1913 ของ Henry Ford ซึ่งให้ความมั่นใจในแต่ละขั้นตอนในกระบวนการผลิตเพื่อรับประกันว่าผลิตภัณฑ์ขั้นสุดท้ายตรงกับสิ่งที่ระบุไว้ตั้งแต่แรก

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

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

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

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

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

ในปี 2544 กลุ่มนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ได้รวมตัวกันและตระหนักว่าพวกเขาฝึกพัฒนาซอฟต์แวร์โดยรวมซึ่งแตกต่างจากวิธีการแบบน้ำตกแบบคลาสสิก และพวกเขาไม่ได้อยู่ในสตาร์ทอัพทั้งหมด กลุ่มนี้ซึ่งรวมถึงผู้ทรงคุณวุฒิด้านเทคโนโลยี Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber และ Jeff Sutherland มาพร้อมกับ Agile Manifesto ที่บันทึกความเชื่อร่วมกันของพวกเขาในกระบวนการพัฒนาซอฟต์แวร์สมัยใหม่ว่าควรดำเนินการอย่างไร พวกเขาเน้นการทำงานร่วมกันในการจัดทำเอกสารการจัดระเบียบตนเองมากกว่าการจัดการที่เข้มงวดและความสามารถในการจัดการกับการเปลี่ยนแปลงอย่างต่อเนื่องแทนที่จะขังตัวเองไว้กับกระบวนการพัฒนาแบบน้ำตกที่เข้มงวด

จากหลักการเหล่านั้นก่อให้เกิดวิธีการที่คล่องตัวในการพัฒนาซอฟต์แวร์

บทบาทในวิธีการแบบเปรียว

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

ผู้ใช้

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

เจ้าของผลิตภัณฑ์

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

เราเรียกคนนี้เจ้าของผลิตภัณฑ์ ความรับผิดชอบของเขาคือการกำหนดวิสัยทัศน์นี้จากนั้นทำงานร่วมกับทีมพัฒนาเพื่อทำให้เป็นจริง

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

ทีมพัฒนาซอฟต์แวร์

ในความคล่องตัวทีมพัฒนาและความรับผิดชอบของสมาชิกแตกต่างจากทีมพัฒนาซอฟต์แวร์แบบดั้งเดิม

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

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

Scrum, Kanban และเฟรมเวิร์กเปรียวอื่น ๆ

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

กรอบเปรียวที่นิยมมากที่สุดเรียกว่าทะเลาะกัน โดยมุ่งเน้นไปที่จังหวะการส่งมอบที่เรียกว่าโครงสร้างการวิ่งและการประชุมซึ่งรวมถึงสิ่งต่อไปนี้:

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

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

หลายองค์กรจ้างผู้เชี่ยวชาญด้านการต่อสู้หรือโค้ชเพื่อช่วยทีมในการจัดการกระบวนการต่อสู้

แม้ว่าการต่อสู้จะครอบงำ แต่ก็มีกรอบที่คล่องตัวอื่น ๆ :

  • Kanban ทำงานเป็นกระบวนการ Fan-in และ Fan-Out โดยทีมงานจะดึงเรื่องราวของผู้ใช้จากบอร์ดไอดีและนำเรื่องราวเหล่านั้นมาผ่านกระบวนการพัฒนาแบบทีละขั้นจนกว่าจะเสร็จสมบูรณ์
  • องค์กรบางแห่งนำแนวทาง Agile และ Waterfall แบบผสมผสานมาใช้โดยใช้กระบวนการแบบ Agile สำหรับแอปพลิเคชันใหม่และ Waterfall สำหรับแบบดั้งเดิม
  • นอกจากนี้ยังมีกรอบการทำงานหลายอย่างเพื่อให้องค์กรสามารถปรับขนาดการปฏิบัติไปยังหลายทีมได้

แม้ว่าเฟรมเวิร์กแบบ Agile จะกำหนดกระบวนการและการทำงานร่วมกัน แต่แนวทางปฏิบัติในการพัฒนาแบบ Agile นั้นเฉพาะเจาะจงเพื่อจัดการกับงานการพัฒนาซอฟต์แวร์ที่ดำเนินการให้สอดคล้องกับเฟรมเวิร์กแบบ Agile

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

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

ทำไมวิธีการแบบเปรียวจึงดีกว่า