ขั้นตอนและขั้นตอนของระเบียบวิธีแบบ Agile: คำอธิบายที่สมบูรณ์ [2022]
เผยแพร่แล้ว: 2021-01-04สมมติว่า Google ไม่ได้อัปเดตแอปพลิเคชันเป็นประจำ จะเกิดอะไรขึ้นถ้าเกมมือถือที่คุณชื่นชอบไม่ได้รับการอัพเดต? จะเกิดอะไรขึ้นถ้าคุณต้องรอเป็นเดือนหรือหลายปีกว่าจะได้แอปเวอร์ชันใหม่
มันค่อนข้างจะน่ารำคาญและน่าผิดหวัง อย่างไรก็ตาม ด้วยวิธีการแบบ Agile ในการพัฒนาซอฟต์แวร์ บริษัทต่างๆ จะออกการอัปเดตเป็นประจำ แก้จุดบกพร่องของแอปพลิเคชัน และทำให้คุณซึ่งเป็นผู้ใช้มีความสุข
คุณอาจสงสัยว่า “วิธีการแบบ Agile คืออะไร” เราจะอธิบายรายละเอียดนั้นในคู่มือนี้ มาเริ่มกันเลยดีกว่า
สารบัญ
วิธีการ Agile คืออะไร – อธิบาย
ตามชื่อที่แนะนำ วิธีการแบบเปรียวมุ่งเน้นไปที่การเปิดตัวผลิตภัณฑ์บ่อยครั้งและปรับให้เข้ากับการเปลี่ยนแปลง ตามพจนานุกรมของ Oxford คำว่า 'ความคล่องตัว' หมายถึงความสามารถในการเคลื่อนไหวอย่างรวดเร็วหรือรวดเร็ว วิธีการแบบ Agile ได้รับความนิยมอย่างมากในช่วงไม่กี่ปีที่ผ่านมา เนื่องจากวิธีการที่มีประสิทธิภาพและมุ่งเน้นผลลัพธ์
เป็นปรัชญาการจัดการโครงการที่เน้นการพัฒนาซอฟต์แวร์ดังกล่าวซึ่งอาศัยผลตอบรับและการเปลี่ยนแปลงที่เพิ่มขึ้น คุณเข้าใจสภาพแวดล้อมรอบตัวคุณอย่างไรและเผชิญกับความไม่แน่นอนประเภทใด สิ่งเหล่านี้เป็นส่วนสำคัญของแนวทางนี้
การพัฒนาแบบ Agile มุ่งเน้นไปที่ทีมมากกว่าผลิตภัณฑ์ วิธีแก้ปัญหาในแนวทางนี้ขึ้นอยู่กับการทำงานร่วมกันและการทำงานข้ามสายงานของทีมคุณ ทีมที่คล่องตัวคือการจัดระเบียบตนเอง
นั่นไม่ได้หมายความว่าผู้จัดการไม่จำเป็นในการพัฒนาที่คล่องตัว ผู้จัดการมีหน้าที่ดูแลให้สมาชิกในทีมทุกคนมีทักษะที่จำเป็น พวกเขามีหน้าที่รับผิดชอบในการจัดหาสภาพแวดล้อมที่ดีให้สมาชิกเพื่อให้พวกเขาสามารถประสบความสำเร็จในการทำงาน
อ่าน: คำถามสัมภาษณ์เกี่ยวกับระเบียบวิธีแบบ Agile
ประวัติการพัฒนาเปรียว
ก่อนที่การพัฒนาที่คล่องตัวจะเป็นที่นิยม วิธีน้ำตกเป็นวิธีที่ได้รับความนิยมมากที่สุด วิธีการน้ำตกเป็นที่แพร่หลายก่อนสองสามทศวรรษ แต่รุ่นของนักพัฒนาซอฟต์แวร์ในช่วงปลายยุค 90 ไม่พึงพอใจกับวิธีการนี้ พวกเขาต้องการแนวทางที่ยืดหยุ่นมากขึ้น
วิธีการแบบ Waterfall นั้นเข้มงวด และวิธีการแบบ Agile นั้นยืดหยุ่นได้ ในปี 2544 นักพัฒนาซอฟต์แวร์ 17 คนได้สร้าง Agile Manifesto พวกเขาต้องการพัฒนาทางเลือกอื่นแทนกระบวนการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วยเอกสารรุ่นหนา ค่านิยมพื้นฐานสี่ประการของการพัฒนา Agile มีดังนี้:
- คุณควรจัดลำดับความสำคัญของผู้คนและการโต้ตอบของพวกเขาเหนือเครื่องมือและกระบวนการ
- คุณควรจัดลำดับความสำคัญของซอฟต์แวร์ที่ใช้งานได้มากกว่าเอกสารที่มีรายละเอียด
- คุณควรให้ความสำคัญกับการทำงานร่วมกันของลูกค้ามากกว่าการเจรจาสัญญา
- คุณควรจัดลำดับความสำคัญการตอบสนองของคุณเพื่อเปลี่ยนแปลงมากกว่าความสามารถในการยึดติดกับแผน
นี่ไม่ได้หมายความว่าคุณควรเพิกเฉยต่อเอกสารและกำหนดเวลา หมายความว่าคุณควรให้ความสำคัญกับการทำซ้ำ การสร้างต้นแบบ ผู้คน และการทำงานร่วมกัน
ความคิดแบบเปรียว
โดยพื้นฐานแล้ว Agile คือกรอบความคิด ผู้สร้าง Agile Manifesto ได้วางหลักการ 12 ประการของการพัฒนาซอฟต์แวร์ Agile เพื่ออธิบายให้ดีขึ้น:
- การสร้างความพึงพอใจให้กับลูกค้าของคุณด้วยการส่งมอบผลิตภัณฑ์อย่างต่อเนื่องและก่อนกำหนดควรเป็นสิ่งสำคัญสูงสุดของคุณ
- หากข้อกำหนดของโครงการของคุณเปลี่ยนไปแม้ในระยะหลังๆ ของการพัฒนา คุณควรยินดีต้อนรับ
- คุณควรส่งมอบผลิตภัณฑ์ที่ใช้งานได้ (ซอฟต์แวร์) บ่อยครั้ง ไม่ว่าคุณจะเปิดตัวภายในสองสามสัปดาห์หรือหลายเดือน
- ต้องมีการทำงานร่วมกันทุกวันระหว่างผู้มีส่วนได้ส่วนเสียของโครงการและนักพัฒนา
- โครงการของคุณควรสร้างขึ้นจากคนที่มีแรงบันดาลใจ คุณต้องให้สภาพแวดล้อมและการสนับสนุนที่พวกเขาต้องการ และคุณต้องไว้วางใจพวกเขาว่าพวกเขาจะทำงานให้เสร็จ
- การสนทนาแบบเห็นหน้ากันเป็นวิธีที่มีประสิทธิภาพและประสิทธิผลมากที่สุดในการถ่ายโอนข้อมูลไปยังและภายในทีมพัฒนาของคุณ
- ผลิตภัณฑ์ที่ใช้งานได้ (ซอฟต์แวร์) เป็นตัวชี้วัดความก้าวหน้าที่สำคัญของคุณ
- คุณควรส่งเสริมการพัฒนาที่ยั่งยืน ทีมของคุณ ผู้มีส่วนได้ส่วนเสีย ผู้ใช้ และนักพัฒนาควรสามารถรักษาความต่อเนื่องได้โดยไม่มีอุปสรรค
- คุณควรให้ความสำคัญกับความเป็นเลิศทางเทคนิคอย่างต่อเนื่อง และการออกแบบที่ดีจะช่วยเพิ่มความคล่องตัว
- การรักษากระบวนการให้เรียบง่าย เช่นเดียวกับการลดงานที่คุณต้องทำเป็นสิ่งสำคัญ
- ทีมที่จัดระเบียบตนเองจะสร้างการออกแบบ ความต้องการ และสถาปัตยกรรมที่ดีที่สุด
- ทีมของคุณควรไตร่ตรองถึงการใช้งานมากขึ้นแล้วปรับพฤติกรรมตามนั้น
คุณจะสังเกตได้ว่าหลักการเบื้องต้นของการพัฒนาแบบ Agile เน้นที่ความพึงพอใจของผู้ใช้มากที่สุด ตั้งแต่การเปิดตัวผลิตภัณฑ์ที่ใช้งานได้บ่อยครั้งไปจนถึงการออกแบบที่ดี ค่านิยมพื้นฐานทั้งหมดของแนวทางนี้มุ่งเน้นที่การทำให้ผู้ใช้มีความสุข
อ่าน: DevOps v Agile
และมันก็เป็นความจริง ผู้ใช้ของคุณ (หรือลูกค้า) ไม่สนใจเอกสารซอฟต์แวร์ของคุณหรือกลยุทธ์ในอนาคตของคุณ พวกเขาสนใจว่าพวกเขาจะได้รับผลิตภัณฑ์เร็วแค่ไหน พวกเขาแก้ไขจุดบกพร่องได้เร็วแค่ไหน และคุณค่าที่ผลิตภัณฑ์มอบให้พวกเขา
ความแตกต่างระหว่าง Agile และ Waterfall
คุณจึงรู้ว่าก่อนที่จะมีการพัฒนา Agile ขึ้นมา โมเดล Waterfall ได้รับความนิยมมากที่สุด แบบจำลองน้ำตกสูญเสียความนิยมไป แต่นั่นไม่ได้หมายความว่าล้าสมัย หลายทีมยังคงใช้วิธีนี้ มีความแตกต่างมากมายระหว่างสองแนวทางที่ทำให้แตกต่างออกไป
- โมเดล Agile มุ่งเน้นไปที่วิธีการแบบวนซ้ำและแบบเพิ่มส่วนเพื่อการพัฒนาซอฟต์แวร์ ในขณะที่ในโมเดล Waterfall การพัฒนาซอฟต์แวร์ของคุณจะเกิดขึ้นตามลำดับตั้งแต่ต้นจนจบ
- คุณต้องแบ่งโครงการที่คล่องตัวออกเป็นแต่ละรุ่น แต่คุณไม่จำเป็นต้องทำอย่างนั้นในแนวทางของน้ำตก
- ลูกค้าของคุณเข้าถึงผลิตภัณฑ์ที่ทำงานของคุณก่อนกำหนดและบ่อยครั้งในแนวทางที่คล่องตัว พวกเขาสามารถให้ข้อเสนอแนะแก่คุณและให้คุณเปลี่ยนแผนงานในอนาคตของคุณได้ ในทางกลับกัน ลูกค้าของคุณจะสามารถเข้าถึงผลิตภัณฑ์ได้ก็ต่อเมื่อผลิตภัณฑ์เสร็จสิ้นหากคุณปฏิบัติตามแนวทางของ Waterfall
- โมเดล Agile นั้นไม่มีโครงสร้าง ในขณะที่โมเดล Waterfall มีโครงสร้าง ดังนั้นหลายคนจึงคิดว่าโมเดลนี้มีความปลอดภัยมากกว่า
- การพัฒนาแบบ Agile นั้นยอดเยี่ยมสำหรับโครงการขนาดเล็ก เนื่องจากคุณสามารถทำให้เสร็จได้อย่างรวดเร็ว วิธีแบบ Waterfall นั้นยอดเยี่ยมสำหรับโครงการขนาดใหญ่ เนื่องจากคุณสามารถประมาณค่าที่แม่นยำยิ่งขึ้นและดำเนินการตามแผนให้เสร็จสิ้นตามนั้น
- มีการวางแผนในการพัฒนา Agile น้อยกว่าเมื่อเปรียบเทียบกับการพัฒนา Waterfall
- คุณดำเนินการตามกระบวนการพัฒนาซ้ำ ๆ ในสองสามสัปดาห์เมื่อคุณปฏิบัติตามแนวทางที่คล่องตัว ในทางกลับกัน ด้วยวิธี Waterfall คุณจะเสร็จสิ้นกระบวนการพัฒนาเป็นขั้นตอน และขั้นตอนจะใหญ่กว่าการทำซ้ำ
- ด้วยแนวทางที่คล่องตัว คุณสามารถแก้ไขข้อผิดพลาดในระหว่างกระบวนการเมื่อคุณได้รับคำติชมบ่อยๆ ด้วยวิธีการแบบ Waterfall คุณจะทดสอบผลิตภัณฑ์ขั้นสุดท้ายในตอนท้ายและไม่เคยทำมาก่อน หากคุณพบข้อผิดพลาดในผลิตภัณฑ์ขั้นสุดท้าย คุณจะต้องเริ่มโครงการใหม่ตั้งแต่เริ่มต้น
- เอกสารมีความสำคัญน้อยกว่าในการพัฒนาที่คล่องตัวเมื่อเปรียบเทียบกับการพัฒนาวอเตอร์ฟอล อันที่จริง ในระยะหลัง คุณอาจใช้เอกสารประกอบการฝึกอบรมพนักงานของคุณด้วย
- เมื่อการทำซ้ำสิ้นสุดลงในการพัฒนาที่คล่องตัว คุณจะส่งคุณสมบัติที่จัดส่งได้ให้กับลูกค้าของคุณโดยตรง ลูกค้าสามารถใช้คุณสมบัติเหล่านั้นได้ทันทีหลังจากได้รับ ในแนวทางของ Waterfall คุณจะต้องส่งคุณลักษณะทั้งหมดของผลิตภัณฑ์ของคุณไปพร้อม ๆ กันเมื่อคุณทำโปรเจ็กต์เสร็จหลังจากสิ้นสุดขั้นตอน
- ในแนวทางที่คล่องตัว ผู้ทดสอบและนักพัฒนาทำงานร่วมกัน ในขณะที่แนวทางของ Waterfall จะไม่ทำงานร่วมกัน
- คุณจะต้องยอมรับผู้ใช้เมื่อสิ้นสุดทุกการวิ่งใน Agile ในวิธี Waterfall คุณต้องดำเนินการยอมรับผู้ใช้เมื่อสิ้นสุดโปรเจ็กต์ของคุณ
- การพัฒนาแบบ Agile ต้องการให้นักพัฒนาสื่อสารอย่างใกล้ชิดและสม่ำเสมอเพื่อการวางแผนและวิเคราะห์ ในการพัฒนา Waterfall นักพัฒนาไม่ได้มีส่วนร่วมในกระบวนการวางแผนและเกี่ยวข้องกับขั้นตอนการเข้ารหัสเท่านั้น
ขั้นตอนวิธีการแบบ Agile
วิธีการแบบ Agile มีหลายประเภท เราจะพูดถึงเรื่องที่โดดเด่นที่สุดในหมู่พวกเขาโดยสังเขป คุณสามารถอ้างถึงวิธีการเป็นชุดข้อตกลงเฉพาะที่ทีมของคุณเลือกปฏิบัติตาม ทีมต่างๆ ของคุณสามารถมีวิธีการที่แตกต่างกันได้ วิธีการแบบ Agile คือวิธีที่เป็นไปตามค่านิยมหลักและหลักการของการพัฒนาแบบ Agile ที่เราได้พูดคุยกันก่อนหน้านี้ มีวิธีการแบบ Agile ดังต่อไปนี้:
- Scrum
- คัมบัง
- DSDM (วิธีการพัฒนาซอฟต์แวร์แบบไดนามิก)
- วิธีการคริสตัล
- FDD (การพัฒนาคุณลักษณะที่ขับเคลื่อนด้วย)
- XP (การเขียนโปรแกรมเอ็กซ์ตรีม)
มาพูดถึงประเด็นหลักด้านล่างกัน:
วิธีที่ 1: SCRUM
SCRUM เป็นเฟรมเวิร์กที่เน้นการเสริมพลังให้ทีมทำงานร่วมกันได้ มันเป็นฮิวริสติก เน้นการปรับตัวตามปัจจัยที่ผันผวนและการเรียนรู้อย่างต่อเนื่อง เข้าใจว่าทีมไม่จำเป็นต้องรู้ทุกอย่างตั้งแต่เริ่มงาน Scrum ขึ้นอยู่กับกลยุทธ์ของทีมรักบี้
โดยเน้นที่การเสริมสร้างการทำงานร่วมกันในทีมโดยแบ่งเป็นกลุ่มย่อยๆ เช่นเดียวกับทีมรักบี้ คุณเห็นไหมว่าทีมรักบี้มีผู้เล่นหลายกลุ่มที่มีหน้าที่รับผิดชอบเฉพาะ ใน Scrum ทีมของคุณจะถูกแบ่งออกเป็นกลุ่มย่อยด้วย
Scrum มีอาร์ติแฟกต์หลักสามอย่าง ได้แก่ การเพิ่มขึ้น งานในมือของสปรินต์ และงานในมือของผลิตภัณฑ์ มาพูดคุยกันสั้น ๆ เพื่อทำความเข้าใจ Scrum ให้ดีขึ้น:
Backlog สินค้า
งานในมือหมายถึงรายการงานหลักที่ทีมของคุณต้องดำเนินการ ความรับผิดชอบในการรักษารายการนี้ตกเป็นของผู้จัดการผลิตภัณฑ์หรือเจ้าของผลิตภัณฑ์ เป็นรายการสิ่งที่ต้องทำของกลุ่มเนื่องจากมีข้อกำหนด การแก้ไข การปรับปรุง และคุณลักษณะที่เป็นอินพุตสำหรับอาร์ติแฟกต์ถัดไป คือ sprint backlog
Sprint Backlog
สิ่งประดิษฐ์นี้มีรายการการแก้ไขข้อผิดพลาดและรายการที่ทีมพัฒนาของคุณเลือกสำหรับรอบการวิ่งเฉพาะ อย่างไรก็ตาม งานในมือของ Sprint นั้นค่อนข้างยืดหยุ่น และคุณมีตัวเลือกในการปรับเปลี่ยนระหว่าง Sprint ได้หากต้องการ
เพิ่มขึ้น
อีกชื่อหนึ่งสำหรับการเพิ่มขึ้นคือเป้าหมายการวิ่ง หมายถึงผลิตภัณฑ์ขั้นสุดท้ายที่คุณได้รับจากการวิ่งระยะสั้น เป้าหมายการวิ่งเป็นผลสูงสุดของทีมพัฒนาของคุณ และคุณสามารถพูดได้ว่าคุณบรรลุเป้าหมายนี้ก็ต่อเมื่อคุณเสร็จสิ้นกระบวนการทั้งหมดแล้วเท่านั้น
สมมติว่าทีมของคุณจำเป็นต้องเผยแพร่แอปใน Play Store ในกรณีนี้ คุณสามารถพูดได้ว่าคุณบรรลุเป้าหมายการวิ่งแล้วเมื่อกดปุ่มเผยแพร่
ดังที่เราได้กล่าวไว้ก่อนหน้านี้ Scrum แบ่งทีมของคุณออกเป็นส่วนย่อยๆ ส่วนแรกจะเป็น Scrum Master ซึ่งมีหน้าที่รับผิดชอบในการตั้งค่าทีมและการจัดการการประชุมสปรินต์ คนที่สองคือเจ้าของผลิตภัณฑ์ที่ต้องสร้างงานในมือและดูแลการส่งมอบเมื่อสิ้นสุดการทำซ้ำทุกครั้ง
คนสุดท้ายคือ Scrum Team ซึ่งทำงานในวงจรการวิ่ง
วิธีที่ 2: Kanban
Kanban มุ่งเน้นไปที่การพัฒนาซอฟต์แวร์ในวงจรเดียวที่ยาวนาน มันค่อนข้างแตกต่างจาก SCRUM ซึ่งเป็นวิธีเปรียวที่เราพูดถึงก่อนหน้านี้ ในกระบวนการคัมบัง คุณจะต้องใช้การ์ดที่เดินทางตลอดกระบวนการ Kanban เป็นการเพิ่มขึ้นแต่ไม่ทำซ้ำ เนื่องจากไม่มีการทำซ้ำ โปรเจ็กต์ Kanban จึงไม่มีจุดเริ่มต้นและจุดสิ้นสุดที่เฉพาะเจาะจง
โครงการของบริษัทมีขีดจำกัด 'งานระหว่างทำ' พวกเขาช่วยทีมของคุณในการมุ่งเน้นไปที่ส่วนเล็ก ๆ ของงานในแต่ละครั้ง คุณจะเพิ่มฟังก์ชันใหม่ในรอบนี้ก็ต่อเมื่อคุณทำฟังก์ชันก่อนหน้าเสร็จเท่านั้น Kanban แสดงถึงขั้นตอนต่างๆ ของกระบวนการสร้างผ่านหลายขั้นตอนของวงจรชีวิตการพัฒนาซอฟต์แวร์ คุณแสดงคุณลักษณะต่างๆ ผ่านการ์ด Kanban และจัดการโฟลว์ของคุณลักษณะดังกล่าว โดยที่ปริมาณของฟีเจอร์ที่ป้อนจะเท่ากับจำนวนฟังก์ชันที่เสร็จสมบูรณ์
วิธีที่ 3: การพัฒนาคุณลักษณะที่ขับเคลื่อนด้วย (FDD)
การพัฒนาคุณลักษณะที่ขับเคลื่อนด้วยมุ่งเน้นไปที่การสร้างและออกแบบคุณลักษณะ ใน FDD ทีมของคุณจะทำงานในระยะสั้นๆ ซึ่งมีความเฉพาะเจาะจงสูงและมุ่งเน้นการทำงานกับองค์ประกอบ การตรวจสอบการออกแบบ คำแนะนำเกี่ยวกับโดเมน การตรวจสอบรหัส และการเลื่อนขั้นสำหรับการสร้างเป็นเพียงตัวอย่างบางส่วนเท่านั้น กล่าวง่ายๆ ก็คือ FDD มุ่งเน้นไปที่การพัฒนาคุณลักษณะเฉพาะ
คุณต้องทำงานกับความเป็นเจ้าของส่วนประกอบ การสร้างแบบจำลองวัตถุโดเมน การสร้างปกติ การตรวจสอบ และทีมคุณลักษณะ คุณต้องรักษาการมองเห็นผลลัพธ์ที่เหมาะสมและความคืบหน้าในปัจจุบันของโครงการด้วย
วิธีที่ 4: การพัฒนาแบบลีน
วิธีการพัฒนาแบบวนซ้ำของ Agile ตรงกับหลักการพัฒนาซอฟต์แวร์แบบลีน Lean ตั้งเป้าที่จะลดปริมาณงานในกระบวนการเพื่อจัดการโฟลว์ ซึ่งจะช่วยในการเพิ่มความเร็วในการจัดส่ง ทีมแบบลีนทำงานเป็นระบบ “ทันเวลาพอดี” ซึ่งหมายความว่าพวกเขาต้องรอจนถึงช่วงเวลาสุดท้ายที่จำเป็นสำหรับการตัดสินใจ
ลีนเน้นการกำจัดของเสีย และตามหลักการของ Lean อะไรก็ตามที่ลูกค้าไม่จ่ายก็ถือว่าสูญเปล่า นอกจากนี้ยังมุ่งเน้นไปที่กระบวนการอัตโนมัติที่สามารถทำซ้ำได้และมีแนวโน้มสูงที่จะเกิดข้อผิดพลาดของมนุษย์
รับ หลักสูตรการพัฒนาซอฟต์แวร์ จากมหาวิทยาลัยชั้นนำของโลก รับโปรแกรม PG สำหรับผู้บริหาร โปรแกรมประกาศนียบัตรขั้นสูง หรือโปรแกรมปริญญาโท เพื่อติดตามอาชีพของคุณอย่างรวดเร็ว
ความคิดสุดท้าย
วิธีการแบบ Agile เป็นหัวข้อกว้างๆ คุณสามารถดูว่ามันซับซ้อนแค่ไหน ผลกระทบต่อสังคมสมัยใหม่สามารถมองเห็นได้ทุกที่
โดยรวมแล้ว แนวทางปฏิบัติ/วิธีการแบบ Agile ช่วยสร้างสภาพแวดล้อมที่ความต้องการมีการพัฒนาและเปลี่ยนแปลงอย่างต่อเนื่อง ด้วยวิธีการจัดการโครงการที่มีระเบียบวินัย วิธีการแบบ Agile จะส่งเสริมและผลักดันการส่งมอบซอฟต์แวร์คุณภาพสูงที่สอดคล้องกับความต้องการของลูกค้า สำรวจเพิ่มเติมเกี่ยวกับการพัฒนาซอฟต์แวร์ Agile ดูโปรแกรม Executive PG ของ upGrad ในหลักสูตรการพัฒนาซอฟต์แวร์แบบครบวงจร
