Skip to content

Latest commit

 

History

History
56 lines (55 loc) · 8.59 KB

3.1. Agile methods.md

File metadata and controls

56 lines (55 loc) · 8.59 KB

Rapid software development

ความสำคัญของการพัฒนาและส่งมอบซอฟต์แวร์ที่รวดเร็ว

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

Rapid software development

  • การพัฒนาซอฟต์แวร์ ตามระเบียบแบบแผน (plan-driven) อาจช่วยในหลายเรื่อง แต่ไม่ยืดหยุ่นและไม่รองรับความต้องการที่เปลี่ยนแปลงอย่างรวดเร็ว
    • กว่าจะครบทุกขั้นตอนในการพัฒนา อาจจะใช้เวลาเป็นเดือนหรือปี ทำให้ไม่สามารถตอบสนองต่อความต้องการได้ทันท่วงที
  • วิธีการพัฒนาแบบ agile กำเนิดขึ้นในยุค 1990
    • เพื่อลดระยะเวลาในการพัฒนาและส่งมอบซอฟต์แวร์ให้สั้นลง
    • วิธีการง่ายๆ คือ ปล่อยมาเป็นรุ่นย่อย ๆ (พัฒนาเป็น incremental)

ลักษณะเฉพาะของ Agile development

  • การออกข้อกำหนดโปรแกรม (Program specification) การออกแบบและสร้าง (design and implementation) จะทำควบคู่กันไป
  • การพัฒนาจะทำเป็นรุ่นๆ โดยปล่อยออกมาเป็น incremental
    • ในการพัฒนาแต่ละรุ่น จะมี stakeholders เข้ามาร่วมออก specification และทำการ evaluation
  • ปล่อยรุ่นล่าสุดออกมา ให้บ่อยที่สุด เท่าที่จะเป็นไปได้
  • ใช้เครื่องมือช่วยในการพัฒนาให้มากที่สุด (เช่น automated testing tools)
  • ทำเอกสารน้อย ๆ
    • เน้นที่ working code (เขียนโค้ดให้มีความเป็น document ในตัว เช่นการตั้งชื่อตัวแปรที่สื่อความหมาย)

Plan-driven vs agile development

Plan-driven and agile development

  • Plan-driven development
    • การพัฒนาซอฟต์แวร์แบบ plan-driven จะมีการแบ่ง development stages อย่างชัดเจน
    • outputs ที่ได้จากแต่ละ stages จะเป็นตัวขับเคลื่อน ให้การพัฒนาดำเนินต่อไปได้
    • ไม่ใช่เพียงแต่ใน waterfall model เท่านั้น incremental development เอง ก็ทำให้เกิดรูปแบบ plan-driven ได้เช่นกัน
  • Agile development
    • Specification, design, implementation and testing จะของแต่ละรุ่นจะเกิดขึ้นขนานกันไป
    • outputs ของการพัฒนา จะอยู่ที่การคุยกันระหว่างทีมพัฒนาและ stakeholder

ทำไมต้อง Agile process

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

Agile methods

  • ข้อผิดพลาดในการพัฒนาซอฟต์แวร์ในยุค 80 และ 90 คือ การมี overhead มากเกินไปนำมาสู่การพัฒนาแบบ agile ซึ่งมีลักษณะเฉพาะคือ
    • เน้นที่การเขียน code มากกว่าที่จะเน้นที่การออกแบบ (design)
    • เน้นที่การพัฒนาซอฟต์แวร์แบบ iterative approach
  • มุ่งเน้นในการส่งมอบซอฟต์แวร์ที่ใช้งานได้จริงและตรงตามความต้องการที่เปลี่ยนไปอย่างรวดเร็ว
  • สิ่งที่เรียกว่า overhead ได้แก่ เอกสารจากขั้นตอนต่างๆ ที่เกิดขึ้นในกระบวนการพัฒนา
  • เป้าหมายของ agile methods คือ
    • การลด overheads โดยการจำกัดปริมาณเอกสารที่ต้องทำ
    • มุ่งเน้นที่การตอบสนองต่อความต้องการของลูกค้ามากกว่าการทำงานที่ไม่จำเป็นและสิ้นเปลือง

คำประกาศของอไจล์ (Agile manifesto)

  • พัฒนาซอฟต์แวร์ด้วยความเอื้อเฟื้อซึ่งกันและกัน The principles of agile methods (a) The principles of agile methods (b)

ใช้งาน Agile method เมื่อใด?

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