Agile Manifesto คืออะไร?ค่านิยมหลักและหลักการอธิบาย

ประเด็นสำคัญ

ประวัติและจุดประสงค์ของ Agile Manifesto

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

เป้าหมายของพวกเขาคือเชิงปฏิบัติ: ทำให้การพัฒนาปรับตัวได้และยึดอยู่กับการส่งมอบ เมื่อเวลาผ่านไป ความคิดนี้หล่อหลอมกรอบงานอย่าง Scrum และ Kanban ซึ่งทำให้รอบสั้น backlog ที่มองเห็นได้ และจุดทบทวนเป็นประจำกลายเป็นรูปแบบเป็นทางการ

คุณค่าหลักของ Agile Manifesto

คุณค่าทั้งสี่ตรงข้ามโดยตรงกับตรรกะของการบริหารโครงการแบบดั้งเดิม:

1. บุคคลและการสื่อสารเหนือกระบวนการและเครื่องมือ. การสื่อสารที่ชัดเจนช่วยลดสมมติฐานที่ซ่อนอยู่ ปัญหาจะปรากฏเร็วขึ้นเมื่อทีมพูดคุยโดยตรงแทนที่จะพึ่งพาเอกสารเพียงอย่างเดียว
2. ซอฟต์แวร์ที่ทำงานได้เหนือเอกสารที่ครอบคลุม. หากผู้ใช้จริงสามารถลองใช้ฟีเจอร์ได้ นั่นคือความก้าวหน้า เอกสารเพียงอย่างเดียวไม่พิสูจน์ว่าสิ่งใดทำงานได้
3. การร่วมมือกับลูกค้าเหนือการเจรจาสัญญา. การตอบกลับเป็นประจำแสดงให้เห็นแต่เนิ่น ๆ ว่าฟีเจอร์นั้นแก้ปัญหาจริงหรือเพียงดูสมเหตุสมผลในข้อกำหนด
4. การตอบสนองต่อการเปลี่ยนแปลงเหนือการทำตามแผน. แผนยังคงมีอยู่ แต่ถูกทบทวนบ่อย ๆ ลำดับความสำคัญเปลี่ยนได้โดยไม่ต้องเริ่มโครงการทั้งหมดใหม่

หลักการของ Agile Manifesto

หลักการ 12 ข้อขยายคุณค่าเหล่านี้สู่การปฏิบัติประจำวัน ในความเป็นจริง พวกมันวนเวียนรอบรอบที่สั้นลงและการตอบกลับที่สม่ำเสมอ:

1. ความพึงพอใจของลูกค้า. ส่งมอบฟังก์ชันการทำงานที่ใช้ได้แต่เนิ่น ๆ และพัฒนาต่อไป การตอบกลับหลังการปล่อยแต่ละครั้งแสดงว่าทิศทางถูกต้องหรือไม่
2. โอบรับการเปลี่ยนแปลง. ขอบเขตเปลี่ยนแปลง การเปลี่ยนแปลงถูกจัดการผ่านการอัปเดต backlog ไม่ใช่การออกแบบใหม่ฉุกเฉิน
3. การส่งมอบบ่อยครั้ง. การปล่อยเป็นชิ้นเล็ก ๆ เปิดเผยข้อผิดพลาดในขณะที่ยังถูกในการแก้ไข
4. การร่วมมืออย่างใกล้ชิด. ธุรกิจและการพัฒนาทำงานเคียงข้างกัน ซึ่งจำกัดการตีความข้อกำหนดที่ผิด
5. ทีมที่จัดระบบตนเอง. ทีมตัดสินใจเองว่าจะแบ่งงานอย่างไร สิ่งนี้ย่นห่วงโซ่การอนุมัติและเร่งการดำเนินการ

เมื่อการส่งมอบเกิดขึ้นเฉพาะที่ปลายของรอบยาวเท่านั้น ความเสี่ยงจะซ่อนอยู่นานกว่า การทำซ้ำลดการเปิดรับนั้น

ผลกระทบของ Agile ต่อการพัฒนาซอฟต์แวร์

Agile ทำให้สามารถทดสอบไอเดียได้เร็วขึ้นแทนที่จะรอการปล่อยเต็มรูปแบบ แทนที่จะรอหลายเดือนเพื่อเห็นผล ทีมจะปล่อยส่วนเพิ่มขนาดเล็กก่อน สมมติฐานถูกทดสอบในเงื่อนไขจริง กรอบงานอย่าง Scrum และ Kanban สนับสนุนแนวทางนี้ด้วยการจัดโครงสร้างงานเป็นรอบสั้นหรือการไหลต่อเนื่อง ทำให้คอขวดมองเห็นได้

ทำงานเป็นชิ้นเล็กลง ตรวจผลบ่อยขึ้น และอัปเดตลำดับความสำคัญเมื่อมีข้อมูลใหม่ปรากฏขึ้น

การประยุกต์ใช้หลัก Agile ในอุตสาหกรรมอื่น

ทีมการตลาดทำการทดลองแคมเปญเล็ก ๆ ก่อนขยายงบประมาณ หากข้อความล้มเหลว ความเสียหายจะจำกัด ในฝ่ายบุคคลหรือการบริหารราชการ บอร์ดงานที่มองเห็นได้และการวางแผนแบบเพิ่มทีละขั้นทำให้ความรับผิดชอบชัดเจนขึ้นและการประสานงานราบรื่นขึ้น

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

หนังสือแนะนำ

"Agile Project Management" by Bill Galvin

คู่มือเชิงปฏิบัติเพื่อความสำเร็จในการบริหารโครงการ Agile

"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland

การเจาะลึก Scrum หนึ่งในกรอบงาน Agile ที่ใช้กันแพร่หลายที่สุด

"Agile Principles, Patterns, and Practices in C#" by

คู่มือเชิงเทคนิคสำหรับการนำ Agile ไปใช้ในการพัฒนา C#

"The Lean Startup" by Eric Ries

หนังสือเกี่ยวกับการนำหลักการทำซ้ำมาใช้กับการพัฒนาผลิตภัณฑ์

บทสรุป

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