การพัฒนาแบบ Agile คืออะไร?

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

หน้านี้ครอบคลุมภูมิหลัง หากคุณรู้ทั้งหมดนี้แล้ว ให้ข้ามไปอ่าน East Agile Tracker แมปเข้ากับ agile อย่างไร

ปฏิญญา Agile (The Agile Manifesto)

ในเดือนกุมภาพันธ์ 2001 นักปฏิบัติด้านซอฟต์แวร์สิบเจ็ดคน — Kent Beck, Martin Fowler, Robert Martin, Ron Jeffries และคนอื่น ๆ — พบกันที่ลอดจ์สกีในรัฐยูทาห์ และเขียนสิ่งที่พวกเขามีเหมือนกัน พวกเขาเรียกมันว่า ปฏิญญา Agile มันคือสี่บรรทัด:

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

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

นั่นคือ ในขณะที่สิ่งที่อยู่ทางขวามีคุณค่า เราให้คุณค่ากับสิ่งที่อยู่ทางซ้ายมากกว่า

แค่นั้น คำนำหนึ่งหน้า หลักการสนับสนุนสิบสองข้อ และสี่บรรทัดข้างต้น มันคือเอกสารที่ทรงอิทธิพลที่สุดในการปฏิบัติด้านซอฟต์แวร์สมัยใหม่

หลักการสิบสองข้อ

เบื้องหลังสี่คุณค่า หลักการสิบสองข้อของปฏิญญาขยายความว่า “agile” หน้าตาเป็นอย่างไรในแต่ละวันจริง ๆ:

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

กลุ่มของวิธีการ

“Agile” คือร่ม ภายใต้มันมีวิธีการที่แตกต่างกันหลายแบบ:

• eXtreme Programming (XP) — ที่เรียกร้องมากที่สุดในกลุ่ม การเขียนโปรแกรมเป็นคู่ TDD การบูรณาการอย่างต่อเนื่อง ลูกค้าอยู่ที่ไซต์งาน release เล็ก ๆ ดู หน้า XP ของเรา
• Scrum — รอบงานที่มีกรอบเวลาเรียกว่า sprint standup รายวัน บทบาทที่มีชื่อ (Product Owner, Scrum Master) เน้นการปฏิบัติทางวิศวกรรมเบากว่า XP
• Kanban — มองเห็นเวิร์กโฟลว์ จำกัดงานที่กำลังทำอยู่ ปรับการไหลให้เหมาะสม ไม่มีกรอบเวลา ดึง (pull) แทนการผลัก (push)
• Lean — ยืมมาจากระบบการผลิตของโตโยต้า: กำจัดความสูญเปล่า ปรับให้เหมาะสมทั้งระบบ ส่งมอบเร็ว สร้างคุณภาพเข้าไป

วิธีการเหล่านี้ทับซ้อนและผสมผสานกัน ทีมที่ทำงานจริงส่วนใหญ่หยิบเลือกจากทั้งสี่แบบ East Agile Tracker มีจุดยืนเอนเอียงไปทาง XP — ดู eXtreme Programming — แต่สิ่งที่มันให้ส่วนใหญ่ใช้ได้กับ agile รสชาติใดก็ตาม

Agile ไม่ใช่อะไร

ความเข้าใจผิดที่ฝังลึกอยู่ไม่กี่อย่างที่ควรกล่าวถึง:

• Agile ไม่ใช่ “ไม่มีการวางแผน” แผนเล็กลงและสั้นลง แต่การวางแผนเป็นไปอย่างต่อเนื่อง
• Agile ไม่ใช่ “ไม่มีเอกสาร” เขียนสิ่งที่จำเป็น ปฏิญญาบอกว่าซอฟต์แวร์ที่ใช้งานได้มีคุณค่า มากกว่า เอกสารที่ครอบคลุม — ไม่ได้บอกว่าเอกสารแย่
• Agile ไม่ใช่ Scrum Scrum เป็น หนึ่ง วิธีการของ agile มีอยู่หลายแบบ
• Agile ไม่ใช่เครื่องมือ ไม่มีเครื่องมือใดทำให้คุณ agile Agile คือวิธีการทำงาน เครื่องมือ (รวมถึงตัวนี้) ช่วยได้ มันไม่ได้มาแทนที่

East Agile Tracker แมปเข้ากับ agile อย่างไร

East Agile Tracker ออกแบบมารอบหลักการข้างต้น นี่คือความสัมพันธ์:

หลักการ	tracker สนับสนุนมันอย่างไร
การส่งมอบอย่างต่อเนื่อง	รอบงาน 1–4 สัปดาห์ การวางแผนอัตโนมัติตามความเร็ว release เป็นประเภท story ระดับชั้นหนึ่ง
ต้อนรับการเปลี่ยนแปลง	จัดลำดับ backlog ใหม่ได้ทุกเมื่อ story ย้ายข้ามรอบงานได้อย่างอิสระ ไม่มี “การล็อกรอบงาน”
ซอฟต์แวร์ที่ใช้งานได้เป็นมาตรวัด	ความเร็วนับแต้มที่ ตรวจรับ แล้วตามค่าเริ่มต้น — เฉพาะงานที่ส่งมอบและใช้งานได้เท่านั้นที่นับ
ก้าวเดินที่ยั่งยืน	ความเร็วไม่ใช่เป้าหมาย มันคือการสังเกต ระบบวางแผนรอบงานถัดไปด้วยสิ่งที่คุณทำได้จริง
การไตร่ตรอง	การวิเคราะห์รายรอบงาน: burndown อัตราการปฏิเสธ cycle time การคาดการณ์
ทีมที่จัดระเบียบตัวเอง	บทบาทถูกออกแบบให้น้อยที่สุดโดยตั้งใจ: owner / member / viewer ทีมเป็นผู้ตัดสินใจ
ความเรียบง่าย	แผงรายละเอียดอยู่ในหน้าจอเดียว บอร์ดพอดีในหน้าเดียว เราต้านทานฟีเจอร์ที่เบี่ยงเบนจากการส่งมอบ

Agile ในปี 2026 — และเอเจนต์

ปฏิญญาเขียนขึ้นในปี 2001 ตั้งแต่นั้นมา การพัฒนาซอฟต์แวร์ได้ผู้เข้าร่วมชนิดใหม่: เอเจนต์ AI

เราคิดว่าเอเจนต์เป็นส่วนหนึ่งของทีม agile — ในฐานะผู้เข้าร่วมที่มีชื่อ มีบทบาทของตัวเอง ทำงานจริงเคียงข้างมนุษย์ หลักการยังคงเป็นจริง ปัจเจกบุคคลและการมีปฏิสัมพันธ์ ตอนนี้รวมถึงผู้เข้าร่วมที่เป็นเอเจนต์ ทีมที่จัดระเบียบตัวเอง ตอนนี้รวมถึงการตัดสินใจว่าจะนำเอเจนต์ใดมาและอนุญาตให้พวกมันทำอะไร การไตร่ตรอง ตอนนี้รวมถึงการดูการมีส่วนร่วมของเอเจนต์ในบันทึกกิจกรรมและปรับจูนสิ่งที่พวกมันกำลังทำ

East Agile Tracker สร้างขึ้นเพื่อทำให้สิ่งนี้ใช้งานได้จริง ทุก story สามารถมีเจ้าของเป็นมนุษย์หรือเอเจนต์ได้ ทุกรายการในบันทึกการตรวจสอบระบุผู้กระทำที่แท้จริง ทุกการกระทำที่เอเจนต์ทำมองเห็นได้ ตรวจสอบได้ และเพิกถอนได้

อ่านเพิ่มเติม

• ปฏิญญา Agile — ต้นฉบับ
• eXtreme Programming — หน้าของเราเกี่ยวกับ XP ในทางปฏิบัติ
• คู่มือการใช้งาน — วิธีใช้ tracker

สร้างโดย East Agile