Agile Method: วิธีการพัฒนาซอฟท์แวร์สำหรับปัจจุบันและอนาคต

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

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

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

b61

Agile คืออะไร

เป็นหลักการในการพัฒนา software แบบใหม่ที่เน้น…

  • Rapid and flexible response to change
  • ทำให้การพัฒนาว่องไว
  • มีการทำเรื่อยๆไม่ต้องหยุด แม้มีอะไรมากระทบก็ไม่เป็นไร
  • เมื่อมีการเปลี่ยนแปลง เราสามารถรองรับความเปลี่ยนแปลงนั้นได้อย่างรวดเร็ว ไม่ตายตัว

 

วัตถุประสงค์ของ Agile

  1. เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย
  2. ให้ทำงานโดยยึดที่ผลผลิตหรือ software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนทีี่ว่าเรามี sw หรือของส่งให้ลูกค้าหรือยัง
  3. ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนาและลูกค้า
  4. ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน(gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้

 

หลักการ Agile

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

 

โมเดลของ Agile (AM : Agile Modeling)

  • เลือกบางหลักการมาทำ
  • เป็นวิธีนึงที่จะเอาหลักการของ Agile มาจัดการกับเอกสารและระบบเดิมที่มีอยู่ได้
  • ใน Agile ประกอบด้วย
    1. value ผลลัพธ์
    2. principle หลักการ
    3. practices วิธีปฏิบัติ
  • ทั้งสามอย่างนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สามารถนำมาพัฒนา Software ให้มีประสิทธิภาพ และเกิด overhead น้อย
  • ให้มอง Agile เป็นส่วนขยายของกระบวนการพัฒนา Software แบบเดิมได้
    1. ให้ Agile เข้าไปกำกับ ดูว่าของเดิมที่มีอยู่อันไหนสำคัญก็ทำ ไม่สำคัญก็ละ
    2. นำ Agile มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำ ไม่ควรทำ

 

 Value (ผลลัพธ์)

  • เน้นติดต่อสื่อสาร
  • เน้นความง่าย ไม่ซับซ้อน
  • เน้น feedback จากลูกค้า
  • เน้นความกลัาตัดสินใจ
  • เน้นความเคารพกันและกัน

 

Core Principle (หลักการ)

  • ง่าย ไม่เวอร์เกิน
  • รับ requirement พร้อมเปลี่ยนแปลงได้ตลอดเวลา
  • เ้น้นปัจจุบีนเป็นหลัก
  • ทำ model ตามความจำเป็นเท่านั้น
  • พยายามใช้ multiple model มองหลายๆมุมมอง
  • มีการตอบกลับเร็ว
  • SW ถือเป็นจุดมุ่งหมายหลัก
  • ให้แบกสัมภาระเบาๆ
  • Supplement Principle
    • น้น content มากกว่า representation(ที่ใช้ UML เขียน) ไม่เน้นเครื่องมือ เน้นที่เน้อหาข้างใน
    • ติดต่อกันอย่างเปิดเผย และตรงไปตรงมา

Core Practice (แนวทางปฏิบัติ /ลงมือทำ)

  1. จัดประชุม รวบรวม Active stakeholder เท่านั้น บางมีอาจมี None stakeholder เข้ามาฟังได้ แต่ห้ามออกความคิดเห็น ห้ามถาม ห้ามติดต่อ ห้ามแสดงไอเดีย
  2. นำ Artifact มาใช้ให้ถูกต้อง
    • Note : Artifact คือชิ้นส่วนของงานที่เราทำระหว่างการพัฒนาระบบเช่น อีเมลล์, source code,จดหมาย,ใบเชิญประชุม ถ้า Artifact ใดถูกเลือกมาใช้ในการทำงาน เรียกว่า “work products” และถ้า work products นี้ ถูกส่งมอบให้ลูกค้า้เรียกว่า “Deliverable”
  3. พยายามเป็นเจ้าของงาน สามารถทำงานแทนกันและกันได้
  4. พยายามใช้โมเดลแบบคู่ขนาน จะได้มองต่างมุม เพื่อเก็บรายละเอียดของระบบให้ครบ
  5. ทำให้เนื้อหาง่าย
  6. พยายามวาดรูปไม่ให้ซับซ้อน
  7. พยายามให้โมเดลเข้าถึงได้ทุกคน
  8. สามารถเปลี่ยน Artifact นึงไปอีกอันได้
  9. ใช้โมเดลแบบเล็กก่อนค่อยขยาย
  10. พยายามให้ผู้อื่นมีส่วนร่วมในการทำโมเดล
  11. พิสูจน์ด้วยการลองเขียน code ดู (จาก code เริ่มต้นตั้งแต่แรก)
  12. ใช้เครื่องมือง่ายๆในการทำงาน เช่น กระดาษ,กระดานดำ
  • Supplement Practices
    • ทำให้เป็นาตรฐาน
    • ค่อยๆ สร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้
    • โมเดลไม่ใช้ ให้โยนทิ้งไปเลย เพราะจะได้ไม่เสียเวลามาดูแล
    • เน้น contract (สัญญาระหล่างระบบที่สัมพันธ์กันอยู่) พยายามจัด contract ให้เป็นทางการ เช่น web service มี signature อะไรบ้างใน function call
    • การ update code เฉพาะตอนที่มีปัญหา

รูปแบบวิธีการที่ทำเอา Agile มาใช้

  1. Agile UP
  2. XP (eXtream Programming)
  3. FDD (Feature Driven Development)
  4. Scrum
Sign in to leave a comment
Run Odoo with Virtualenv on Ubuntu