Agile ตระหนักว่าการเปลี่ยนความต้องการของผู้ใช้เป็นเรื่องที่หลีกเลี่ยงไม่ได้ ดังนั้น เราควรจะเน้นทำในสิ่งที่ผู้ใช้ต้องการจริงๆ และลดขั้นตอนที่คิดว่าไม่จำเป็นหรือคิดว่าอาจถูกเปลี่ยนแปลงได้ในภายหลัง หลีกเลี่ยงการออกแบบระบบซับซ้อนล่วงหน้าหลีกเลี่ยงการเขียน document ที่ไม่จำเป็น ใช้วิธีแบ่งการส่งผลงานเป็นเฟสย่อยๆบ่อยๆ และเน้นเรื่องการติดต่อกับผู้ใช้อย่างต่อเนื่อง ให้ผู้ใช้เลือกฟีเจอร์ที่เค้าต้องการก่อน แล้วพัฒนาตามนั้น ถ้าผู้ใช้เปลี่ยนความต้องการเมื่อไร ก็ให้จัดลำดับความสำคัญของฟีเจอร์ที่จะทำรวมทั้งฟีเจอร์ใหม่เสียใหม่ อำนาจการตัดสินใจอยู่ที่ตัวลูกค้าเอง เค้าควรจะรู้ว่าส่วนไหนสำคัญและอยากได้ก่อน
Agile เป็นหลักการในการพัฒนาซอฟแวร์ ที่เน้นในเรื่อง
- Rapid and flexible response to change
- ทำให้การพัฒนาว่องไว
- มีการทำเรื่อยๆไม่ต้องหยุด แม้มีอะไรมากระทบก็ไม่เป็นไร
- เมื่อมีการเปลี่ยนแปลง เราสามารถรองรับความเปลี่ยนแปลงนั้นได้อย่างรวดเร็ว ไม่ตายตัว
วัตถุประสงค์ของ Agile
- เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย
-ให้ทำงานโดยยึดที่ผลผลิตหรือ software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนทีี่ว่าเรามี sw หรือของส่งให้ลูกค้าหรือยัง
-ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนาและลูกค้า
-ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน(gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้
AM : Agile Modeling
- value ผลลัพธ์
- principle หลักการ
- practices วิธีปฏิบัติ
AM Value (ผลลัพธ์)
- เน้นติดต่อสื่อสาร
- เน้นความง่าย ไม่ซับซ้อน
- เน้น feedback จากลูกค้า
- เน้นความกลัาตัดสินใจ
- เน้นความเคารพกันและกัน
AM Core Principle (หลักการ)
- ง่าย ไม่เวอร์เกิน
- รับ requirement พร้อมเปลี่ยนแปลงได้ตลอดเวลา
- เ้น้นปัจจุบันเป็นหลัก
- ทำ model ตามความจำเป็นเท่านั้น
- พยายามใช้ multiple model มองหลายๆมุมมอง
- มีการตอบกลับเร็ว
- SW ถือเป็นจุดมุ่งหมายหลัก
- ให้แบกสัมภาระเบาๆ
- AM Supplement Principle
เ้น้น content มากกว่า representation(ที่ใช้ UML เขียน) ไม่เน้นเครื่องมือ เน้นที่เน้อหาข้างใน
ติดต่อกันอย่างเปิดเผย และตรงไปตรงมา
AM Core Practice (แนวทางปฏิบัติ /ลงมือทำ)
- จัดประชุม รวบรวม Active stakeholder เท่านั้น บางทีอาจมี None stakeholder เข้ามาฟังได้ แต่ห้ามออกความคิดเห็น ห้ามถาม ห้ามติดต่อ ห้ามแสดงไอเดีย
- นำ Artifact มาใช้ให้ถูกต้อง (Artifact คือชิ้นส่วนของงานที่เราทำระหว่างการพัฒนาระบบเช่น อีเมลล์, source code,จดหมาย,ใบเชิญประชุม ถ้า Artifact ใดถูกเลือกมาใช้ในการทำงาน เรียกว่า "work products" และถ้า work products นี้ ถูกส่งมอบให้ลูกค้า้เรียกว่า "Deliverable")
- พยายามเป็นเจ้าของงาน สามารถทำงานแทนกันและกันได้
- พยายามใช้โมเดลแบบคู่ขนาน จะได้มองต่างมุม เพื่อเก็บรายละเอียดของระบบให้ครบ
- ทำให้เนื้อหาง่าย
- พยายามวาดรูปไม่ให้ซับซ้อน
- พยายามให้โมเดลเข้าถึงได้ทุกคน
- สามารถเปลี่ยน Artifact นึงไปอีกอันได้
- ใช้โมเดลแบบเล็กก่อนค่อยขยาย
- พยายามให้ผู้อื่นมีส่วนร่วมในการทำโมเดล
- พิสูจน์ด้วยการลองเขียน code ดู (จาก code เริ่มต้นตั้งแต่แรก)
- ใช้เครื่องมือง่ายๆในการทำงาน เช่น กระดาษ,กระดานดำ
- ทำให้เป็นาตรฐาน
- ค่อยๆสร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้
- โมเดลไม่ใช้ ให้โยนทิ้งไปเลย เพราะจะได้ไม่เสียเวลามาดูแล
- เน้น contract (สัญญาระหล่างระบบที่สัมพันธ์กันอยู่) พยายามจัด contract ให้เป็นทางการ เช่น web service มี signatureอะไรบ้างใน function call
- การ update code เฉพาะตอนที่มีปัญหา
Extreme Programming(XP)
Scrum