Agile - ประกาศ

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

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

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

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

หลักการแสดงความว่องไวสิบสองประการ

  • Customer Satisfaction - ให้ความสำคัญสูงสุดเพื่อตอบสนองความต้องการของลูกค้าผ่านการส่งมอบซอฟต์แวร์ที่มีคุณค่าในช่วงต้นและต่อเนื่อง

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

  • Deliver a Working Software - ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยตั้งแต่สองสามสัปดาห์ถึงสองสามเดือนโดยพิจารณาจากระยะเวลาที่สั้นลง

  • Collaboration - นักธุรกิจและนักพัฒนาต้องทำงานร่วมกันตลอดชีวิตของโครงการ

  • Motivation- โครงการควรสร้างขึ้นจากบุคคลที่มีแรงจูงใจ จัดสภาพแวดล้อมเพื่อสนับสนุนสมาชิกในทีมแต่ละคนและไว้วางใจพวกเขาเพื่อให้พวกเขารู้สึกรับผิดชอบในการทำงานให้สำเร็จ

  • Face-to-face Conversation - การสนทนาแบบเห็นหน้าเป็นวิธีการที่มีประสิทธิภาพและประสิทธิผลสูงสุดในการถ่ายทอดข้อมูลไปยังและภายในทีมพัฒนา

  • Measure the Progress as per the Working Software - ซอฟต์แวร์ที่ใช้งานได้คือกุญแจสำคัญและควรเป็นตัวชี้วัดความก้าวหน้าขั้นต้น

  • Maintain Constant Pace- กระบวนการ Agile มุ่งสู่การพัฒนาที่ยั่งยืน ธุรกิจนักพัฒนาและผู้ใช้ควรสามารถรักษาความก้าวหน้าของโครงการได้อย่างต่อเนื่อง

  • Monitoring - ใส่ใจกับความเป็นเลิศทางเทคนิคและการออกแบบที่ดีเป็นประจำเพื่อเพิ่มความคล่องตัว

  • Simplicity - ทำให้สิ่งต่างๆเรียบง่ายและใช้คำศัพท์ง่ายๆในการวัดผลงานที่ยังไม่เสร็จสมบูรณ์

  • Self-organized Teams - ทีมที่มีความคล่องตัวควรจัดระบบด้วยตนเองและไม่ควรพึ่งพาทีมอื่นมากนักเนื่องจากสถาปัตยกรรมข้อกำหนดและการออกแบบที่ดีที่สุดเกิดจากทีมที่จัดขึ้นเอง

  • Review the Work Regularly - ทบทวนงานที่ทำในช่วงเวลาปกติเพื่อให้ทีมสามารถไตร่ตรองว่าจะมีประสิทธิภาพมากขึ้นและปรับพฤติกรรมให้เหมาะสมได้อย่างไร