ระเบียบวิธีแบบ Agile: ความหมาย ข้อดี ข้อเสีย และอื่นๆ

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

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

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

แต่ในช่วงปลายทศวรรษ 1990 อินเทอร์เน็ตได้เปลี่ยนแปลงโลกอย่างมากและจำเป็นต้องมีแนวทางใหม่ นั่นเป็นวิธีที่วิธีการที่คล่องตัวเข้ามาในชีวิต

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

ประวัติของวิธีการพัฒนาแบบ Agile

การพัฒนาซอฟต์แวร์แบบ Agile เติบโตขึ้นจากอินเทอร์เน็ตและความต้องการแอปพลิเคชันที่ไม่เพียงพอในช่วงปีที่เฟื่องฟูของทศวรรษ 1990 และต้นทศวรรษ 2000

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

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

เพื่อตอบโต้ข้อจำกัดที่โมเดล Waterfall กำหนดในการนำผลิตภัณฑ์ออกสู่ตลาดโดยเร็วที่สุด นักพัฒนาต่างๆ ได้คิดค้นวิธีการที่แตกต่างกันในช่วงปี 1990 ได้แก่ Rapid Application Development (RAD), Scrum, Extreme Programming (XP), Kanban และอื่นๆ

จากนั้นในปี 2544 นักพัฒนา 17 คนที่ฝึกฝนการพัฒนาแบบว่องไวในระยะแรกหรืออีกรูปแบบหนึ่งมารวมกันในยูทาห์ สหรัฐอเมริกา จากนั้นพวกเขาก็จบการประชุมด้วยการเผยแพร่ 'Manifesto for Agile Software Development'

แถลงการณ์นี้อิงตามค่านิยม 4 ประการและหลักการ 12 ประการ

คุณค่า 4 ประการและหลัก 12 ประการของการพัฒนาแบบ Agile

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

ค่าสี่เหล่านี้มีดังนี้:

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

ค่านิยม Agile Manifesto ด้านบนนี้ยึดตามหลักการ 12 ประการ และมีดังต่อไปนี้:

1. ความพึงพอใจของลูกค้าด้วยการส่งมอบซอฟต์แวร์ที่มีคุณค่าตั้งแต่เนิ่นๆ และต่อเนื่อง
2. ยินดีต้อนรับความต้องการที่เปลี่ยนแปลง แม้กระทั่งในช่วงการพัฒนาที่ล่าช้า
3. ส่งซอฟต์แวร์ที่ใช้งานได้บ่อย (สัปดาห์แทนที่จะเป็นเดือน)
4. ความร่วมมืออย่างใกล้ชิดทุกวันระหว่างนักธุรกิจและนักพัฒนา
5. โครงการสร้างขึ้นจากบุคคลที่มีแรงบันดาลใจซึ่งควรได้รับความไว้วางใจ
6. การสนทนาแบบเห็นหน้าเป็นรูปแบบการสื่อสารที่ดีที่สุด (co-location)
7. ซอฟต์แวร์ทำงานเป็นตัววัดความก้าวหน้าเบื้องต้น
8. การพัฒนาที่ยั่งยืน สามารถรักษาอัตราการก้าวให้คงที่
9. เอาใจใส่อย่างต่อเนื่องสู่ความเป็นเลิศทางเทคนิคและการออกแบบที่ดี
10. ความเรียบง่าย—ศิลปะของการเพิ่มปริมาณงานที่ไม่ได้ทำ—เป็นสิ่งสำคัญ
11. สถาปัตยกรรม ข้อกำหนด และการออกแบบที่ดีที่สุดเกิดขึ้นจากทีมที่จัดระเบียบตนเอง
12. เป็นประจำ ทีมงานจะไตร่ตรองถึงวิธีการที่จะมีประสิทธิภาพมากขึ้นและปรับตามนั้น

ทำซ้ำหรือ Sprints

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

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

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

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

ข้อดีของการพัฒนาแบบ Agile

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

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

ข้อเสียของวิธีการแบบ Agile

นอกจากนี้ยังมีข้อเสียบางประการในการทำงานกับวิธีการพัฒนาที่คล่องตัว และอาจรวมถึง:

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

เมื่อใดควรใช้ Agile Methods

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

กรอบการพัฒนา Agile ยอดนิยม

มีกรอบการพัฒนาที่คล่องตัวซึ่งเป็นที่นิยมมากมาย บางคนเริ่มต้นก่อนการประกาศ Agile ของปี 2544 ในขณะที่คนอื่นมาในภายหลัง

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

1. Scrum : เฟรมเวิร์กนี้ออกแบบมาสำหรับทีมที่มีสมาชิกไม่เกิน 10 คน งานแบ่งออกเป็น sprints 2-4 สัปดาห์โดยมีการประชุม 15 นาทีทุกวัน
   
   
2. Kanban : มีต้นกำเนิดมาจาก Toyota, Kanban เป็นคำภาษาญี่ปุ่นที่หมายถึงป้ายโฆษณาและมีประโยชน์มากสำหรับทีมที่ชื่นชอบการมองเห็น งานจะถูกย้ายจากขั้นตอนหนึ่งไปยังอีกขั้นตอนหนึ่งโดยใช้การแสดงภาพ เช่น บันทึกย่อช่วยเตือนหรือแอป
   
   
3. Rapid Application Development RAD : วลีนี้สามารถอ้างถึงการพัฒนาซอฟต์แวร์ที่คล่องตัวโดยทั่วไปหรือวิธีการของ James Martin RAD มุ่งเน้นไปที่ข้อกำหนดของอินเทอร์เฟซผู้ใช้และอาศัยการสร้างต้นแบบอย่างมาก
   
   
4. Lean Startup : กรอบนี้มีไว้สำหรับผู้ที่ต้องการพัฒนาผลิตภัณฑ์หรือบริการ แต่ก่อนอื่น จะต้องกำหนดความเป็นไปได้ของตลาด มันเกี่ยวข้องกับการใช้การทดลองเพื่อดูว่าอะไรได้ผลและไม่ได้ผล

กรอบงานที่โดดเด่นอื่น ๆ ได้แก่ Extreme Programming (XP), Adaptive Software Development, Agile Modeling, Dynamic Systems Development Method และ Scaled Agile Framework

ระเบียบวิธี Agile vs Waterfall

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

การพัฒนาแบบปรับตัวและแบบคาดการณ์ล่วงหน้า

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

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

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

ฝีมือซอฟต์แวร์

Software Craftsmanship เป็นอีกปรัชญาหนึ่งที่สร้างจากหลักการพัฒนาที่คล่องตัว และเน้นที่การเน้นย้ำทักษะของนักพัฒนาซอฟต์แวร์ที่เกี่ยวข้องในโครงการ

ขบวนการ Software Craftsmanship ยังมีแถลงการณ์และระบุว่า:

 ในฐานะที่เป็น Software Craftsmen ที่ต้องการ เรากำลังยกระดับการพัฒนาซอฟต์แวร์อย่างมืออาชีพด้วยการฝึกฝนและช่วยเหลือผู้อื่นในการเรียนรู้งานฝีมือ งานนี้ทำให้เราเห็นคุณค่า:
 
 · ไม่เพียงแต่ซอฟต์แวร์ที่ใช้งานได้ แต่ยังรวมถึงซอฟต์แวร์ที่สร้างขึ้นมาอย่างดีด้วย
 · ไม่เพียงตอบสนองต่อการเปลี่ยนแปลง แต่ยังเพิ่มมูลค่าอย่างต่อเนื่อง
 · ไม่เพียงแต่บุคคลและปฏิสัมพันธ์เท่านั้น แต่ยังรวมถึงชุมชนของผู้เชี่ยวชาญด้วย
 · ไม่เพียงแต่การทำงานร่วมกันกับลูกค้าเท่านั้น แต่ยังรวมถึงความร่วมมือที่มีประสิทธิผลด้วย
 
 นั่นคือ ในการตามหาสิ่งของทางด้านซ้าย เราพบว่าสิ่งของทางด้านขวานั้นขาดไม่ได้
 
  พ.ศ. 2552 ผู้ลงนามข้างท้าย
 คำสั่งนี้สามารถคัดลอกได้อย่างอิสระในรูปแบบใด ๆ แต่เฉพาะในความครบถ้วนผ่านประกาศนี้เท่านั้น

บทสรุป

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

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