Agile ครบ 20 ปี: การกบฏที่ล้มเหลว

 (simplethread.com)
23 คะแนน โดย xguru 2021-08-09 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตอนนี้ผ่านไป 20 ปีแล้วนับตั้งแต่มีการประกาศ Agile Manifesto (ปฏิญญา Agile) และมีข้อเท็จจริงชัดเจนอยู่ 2 ข้อคือ

  1. Agile ชนะในแง่ของการตั้งชื่อ ไม่มีใครอยากถูกเรียกว่า non-Agile

  2. แต่ในแง่ของการนำ Agile ไปปฏิบัติจริงนั้น ยังห่างไกลจากแนวคิดเชิงปฏิวัติของผู้ก่อตั้งมาก

  • "ทุกคนบอกว่าตัวเองทำ Agile แต่แทบไม่มีใครที่ Agile จริง ๆ" แล้วทำไมสถานการณ์ถึงกลายเป็นแบบนี้?

[ Whence The Manifesto : ปฏิญญาเริ่มต้นขึ้นอย่างไร ]

  • กุมภาพันธ์ 2001 กลุ่มผู้เชี่ยวชาญซอฟต์แวร์ 17 คนมาพบกันที่สกีรีสอร์ตในยูทาห์

  • หลังจากถกเถียงกันอยู่หลายวัน พวกเขาได้ร่วมกันเขียน "Agile Software Development Manifesto"

  • ประเด็นสำคัญคือ พวกเขาเป็น "Practitioner (ผู้ปฏิบัติงานจริง)" ไม่ใช่ PM, CTO หรือ VP Eng พวกเขาคือนักพัฒนา โปรแกรมเมอร์ นักวิทยาศาสตร์ และวิศวกร ตอนนั้นพวกเขายังคงเขียนโค้ดและร่วมมือกับผู้มีส่วนได้ส่วนเสียเพื่อแก้ปัญหาอยู่ นี่สำคัญมาก

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

→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming

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

  • แกนกลางของปฏิญญาคือการอธิบายคุณค่า 4 ประการ

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

  • Individuals and interactions (บุคคลและปฏิสัมพันธ์) มากกว่า processes and tools (กระบวนการและเครื่องมือ)

  • Working software (ซอฟต์แวร์ที่ใช้งานได้จริง) มากกว่า comprehensive documentation (เอกสารที่ครอบคลุมทุกอย่าง)

  • Customer collaboration (การร่วมมือกับลูกค้า) มากกว่า contract negotiation (การเจรจาสัญญา)

  • Responding to change (การตอบสนองต่อการเปลี่ยนแปลง) มากกว่า following a plan (การทำตามแผน)

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

[ A New Hope : ความหวังใหม่ ]

  • เมื่อมองจากมุมมองของปี 2021 มันอาจง่ายที่จะคิดว่าการพัฒนาซอฟต์แวร์สมัยใหม่เป็นเรื่องปกติ แต่ในปี 2001 แนวคิดเหล่านี้ถือว่าหัวก้าวหน้ามาก

  • จะเริ่มพัฒนาซอฟต์แวร์ก่อนรวบรวม requirement ทั้งหมดและก่อนประเมินทุกฟีเจอร์งั้นเหรอ? บ้าชัด ๆ !

  • ประเด็นสำคัญที่กำลังถูกลืมคือ ในช่วงแรก Agile เปิดเผยและเป็นปฏิปักษ์กับการบริหารอย่างชัดเจน

  • ตัวอย่างเช่น Ken Schwaber ผู้ร่วมก่อตั้ง Scrum เคยเสนอให้ยกเลิกตำแหน่งผู้จัดการโครงการทั้งหมด ไม่ใช่แค่ถอด PM ออกจากโปรเจกต์ แต่ถึงขั้นควรยกเลิกอาชีพนี้ออกจากทั้งอุตสาหกรรม

"เราพบว่าบทบาทของผู้จัดการโครงการนั้น ไม่ก่อให้เกิดผลิตภาพในงานที่ซับซ้อนและต้องใช้ความคิดสร้างสรรค์

ความคิดของผู้จัดการโครงการที่ถูกแสดงออกมาในรูปของแผนโครงการ

ไม่ได้เป็นการรวบรวมสติปัญญาของทุกคนเพื่อแก้ปัญหาให้ดีที่สุด

แต่กลับจำกัดความคิดสร้างสรรค์และสติปัญญาของทุกคนไว้ในสิ่งที่เขียนอยู่ในแผน"

  • Scrum master แทบไม่มีอำนาจ และไม่มีสิทธิ์โหวตประเด็นต่าง ๆ พวกเขาเป็น servant leader* คอยปกป้องทีมและกำจัดอุปสรรค แต่ไม่ได้บริหารทีม

→ servant leader : ผู้นำที่รับใช้ผู้ใต้บังคับบัญชา ช่วยให้พวกเขาเติบโตและพัฒนา สร้างความไว้วางใจระหว่างผู้นำกับผู้ตาม เพื่อให้ผู้ตามมีส่วนร่วมบรรลุเป้าหมายขององค์กรด้วยตนเอง

  • เดิมที XP ก็มี Tracker และ Coach ซึ่งทำงานในลักษณะคล้ายกัน

  • Alistair Cockburn ผู้สร้าง Crystal และสถาปัตยกรรม Hexagonal เคยพูดไว้ในเธรด Twitter ล่าสุดว่า

"Scrum ปิดดีลมหาศาลในดินแดนที่เป็นศัตรูได้:

  • ฝ่ายบริหารสามารถเปลี่ยนทิศทางได้ 12 ครั้งต่อปี หลังแต่ละ sprint ตามแบบที่ต้องการ

  • ทีมได้ช่วงเวลาหนึ่งเดือนที่เงียบสนิท ไม่มีการขัดจังหวะหรือเปลี่ยนทิศทาง เพื่อทำงานคิดหนักและงานจริงจัง

  • ทีมสามารถประกาศได้ในการ Bid (เพื่อกำหนดลำดับความสำคัญ) ว่าภายในหนึ่งเดือนทำอะไรได้และทำอะไรไม่ได้ โดยไม่มีการแทรกแซงจากฝ่ายบริหาร

  • ไม่มีผู้บริหารคนไหนเคยได้ดีลที่ดีกว่านี้

  • และไม่มีทีมพัฒนาทีมไหนเคยได้ดีลที่ดีกว่านี้

"

(ในเธรดนี้ เดิมทีเริ่มจากคำถามว่า "แนวคิดที่ว่าทีม Scrum ต้องทำ item ทั้งหมดที่จัดสรรไว้ใน sprint ให้เสร็จ 100% มาจากไหน? มันไร้สาระมาก" และนี่คือคำตอบ ขอแนะนำให้อ่านเธรดต้นฉบับทั้งหมด)

  • แม้ผมจะเป็น certified scrum master และทำงานกับทีม Agile มานานกว่า 15 ปี อีกทั้งยังอ่านหนังสือดังในสายนี้มามาก แต่ก็ไม่เคยเห็นใครอธิบายแนวคิดของ Scrum ได้ชัดเจนและกระชับเท่านี้มาก่อน

  • Scrum ถูกสร้างมาให้ทำงานได้ในสภาพแวดล้อมที่เป็นปรปักษ์ มันคือข้อตกลงระหว่างนักพัฒนาที่ต้องการเวลาในการคิดและสำรวจ กับผู้จัดการที่ชอบกดดันควบคุม

[ The Empire Strikes Back : จักรวรรดิโต้กลับ ]

  • ในบางแง่ Agile คือขบวนการแรงงานระดับรากหญ้า มันเริ่มจากผู้ปฏิบัติงานจริงแล้วค่อย ๆ ไต่ขึ้นไปถึงฝ่ายบริหาร แล้วมันสำเร็จได้อย่างไร?

  • ส่วนหนึ่งเพราะจำนวนนักพัฒนาเพิ่มขึ้น และคุณค่าที่พวกเขามอบให้ธุรกิจก็เพิ่มขึ้นด้วย

  • แต่เหตุผลที่ใหญ่กว่าคือ วิธีพัฒนาแบบ Waterfall ดั้งเดิมใช้งานไม่ได้ผลจริง

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

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

  • ช่วงกลางทศวรรษ 2000 ฝ่ายบริหารยังไม่ได้ยอมรับมันนัก

  • แต่แล้วก็เริ่มมีเสียงว่า "ลองไอเดียบ้าบอนี่ที่พวกวิศวกรพูดถึงกันอยู่ตลอดดูสักครั้งไหม ตอนนี้เราก็ส่งงานไม่ทัน deadline อยู่แล้ว จะเลวร้ายไปกว่านี้ได้แค่ไหน?"

  • แต่ที่น่าแปลกคือมันเริ่มใช้ได้ผล ตอนแรกทีมยังเกร็ง ๆ อยู่บ้าง (จึงช้า) แต่เมื่อเวลาผ่านไปก็เริ่มเข้าใจว่ารูปแบบไหนเวิร์กกับแต่ละทีม แล้วความเร็วก็เริ่มมา

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

  • ราว 5 ปีให้หลัง Agile เปลี่ยนจากแนวทางที่เคยมีแต่คนได้ยินชื่อ มาเป็นสิ่งที่แม้ไม่ใช่ทุกคนจะคุ้นเคย แต่ก็แพร่หลายมากขึ้น

  • ในปี 2005 Agile และ TDD เป็นตัวสร้างความแตกต่างอย่างแท้จริง

  • ในปี 2010 ทีมซอฟต์แวร์ยุคใหม่แทบทั้งหมดต่างก็ทำ Agile ในรูปแบบใดรูปแบบหนึ่ง

  • อย่างน้อยในโลกที่ปรึกษานั้นมันกลายเป็นฟองสบู่ไปแล้ว แม้องค์กรใหญ่จะยังเคลื่อนไหวช้าเสมอก็ตาม

"เราทำได้แล้ว! เราชนะแล้ว! มาฉลองกันเถอะทุกคน"

และนี่คือจุดจบของเรื่อง คุณสามารถปิดแท็บเบราว์เซอร์ได้เลย

"Winning was easy, young man. Governing’s harder."

"การชนะนั้นง่าย เจ้าหนุ่ม แต่การปกครองยากกว่า"

→ George Washington ตามที่ถูกถ่ายทอดใน Hamilton (มิวสิคัล)

  • แต่น่าเสียดาย เช่นเดียวกับการปฏิวัติหลายครั้ง ประวัติศาสตร์ของ Agile ไม่ได้ดำเนินไปในแบบที่ผู้ก่อตั้งจินตนาการไว้

→ ปรากฏว่าการให้ความสำคัญกับ "บุคคลและปฏิสัมพันธ์" เป็นแนวคิดที่ขายต่อได้ยาก การขาย process และ tools นั้นง่ายกว่ามาก

→ ปรากฏว่าการสร้าง "ซอฟต์แวร์ที่ใช้งานได้จริง" ยากกว่าการทำแผนที่ไม่สมจริงและเอกสารกองโต

→ "การร่วมมือกับลูกค้า" ต้องอาศัยความไว้วางใจและความเปราะบาง (vulnerability) ซึ่งไม่ใช่สิ่งที่มีอยู่ในธุรกิจเสมอไป

→ "การตอบสนองต่อการเปลี่ยนแปลง" มักถูกลดน้ำหนักลงต่อหน้าแรงกดดันจากผู้บริหารที่ต้องการวางแผนระยะยาวและควบคุมทุกอย่าง

"ปรากฏว่าเมื่อทำ Agile ไม่ถูกต้อง มันมักให้ความรู้สึกเหมือนความโกลาหล"

  • แต่นั่นไม่ได้หมายความว่าคุณค่าทั้ง 4 ข้อนี้ผิด

  • มันหมายถึงว่าการทำให้ทุกอย่างเวิร์กต้องใช้ความพยายาม และต้องมีความกล้าที่จะยอมรับว่าซอฟต์แวร์นั้นโดยธรรมชาติยุ่งเหยิงและสับสน

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

"ขบวนการ Agile ไม่ใช่ anti-methodology

จริง ๆ แล้วพวกเราหลายคนอยากเห็นความเชื่อมั่นในคำว่า 'methodology' ได้รับการฟื้นฟู เราต้องการให้ความสมดุลกลับคืนมา

เรายอมรับการทำ modeling แต่ไม่ใช่เพื่อเอา diagram ไปกองฝุ่นไว้ในห้องเก็บของของบริษัท

เรายอมรับ documentation แต่ไม่ใช่หนังสือหลายร้อยหน้าที่ไม่เคยถูกดูแลและแทบไม่มีใครใช้

เราวางแผน แต่ก็รับรู้ถึงข้อจำกัดของแผนในสภาพแวดล้อมที่ปั่นป่วน

คนที่ตีตราผู้สนับสนุน XP, Scrum หรือวิธีแบบ Agile อื่น ๆ ว่าเป็น 'Hacker' นั้น กำลังไม่เข้าใจความหมายดั้งเดิมของคำว่า 'methodology' และ 'hacker'"

  • Jim Highsmith, History: The Agile Manifesto

  • นี่คือประเด็นสำคัญ เรายังคงทำแผนและเอกสาร และเราควรจริงจังกับ Agile มันคือเรื่องของความสมดุล

  • แต่ถ้าองค์กรของคุณกำลังลำบากกับการเปลี่ยนผ่านสู่ Agile และกำลังจมอยู่ในความโกลาหล เมื่อมีใครยื่นเรือชูชีพอย่าง certification, process หรือ tools มาให้ คุณก็มักจะกระโดดขึ้นไปทันที

  • ฝ่ายบริหารเข้าใจ process และ tools ได้ดีกว่า "ทีมที่จัดการตัวเองได้" มาก

[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (การกลับมา) ]

  • ตรงนี้โครงสร้าง 3 องก์ของผมเริ่มพังนิดหน่อย เพราะเราไม่เห็นกบฏผู้กล้าที่กลับมาพร้อมบางสิ่งที่ไม่ติดชื่อ Agile

  • vendor เครื่องมือ ที่ปรึกษาด้าน process และผู้เชี่ยวชาญ มักให้คำสัญญาในสิ่งที่พวกเขาไม่มีวันส่งมอบได้จริง

  • นี่คือเหตุผลที่เรามี SAFe (Scale Agile Framework for Enterprise), Scaled Scrum และ Agile สำหรับองค์กรขนาดใหญ่อีกหลายเวอร์ชัน

  • framework เหล่านี้ไม่ได้ถูกสร้างขึ้นด้วยเจตนาร้าย และอาจมีคุณค่าอยู่บ้างในบริบทที่เหมาะสม

  • แต่ผมจะไม่เรียกมันว่า Agile

  • เมื่อพยายาม scale วิธีการที่เน้นบุคคลและปฏิสัมพันธ์เป็นหลัก ปัญหาย่อมเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ และคุณค่าเดิมของวิธีการก็ถูกบิดเบือนไปด้วย

  • บทความดังที่ Ron Jeffries ผู้ลงนามในปฏิญญา Agile และผู้ร่วมก่อตั้ง XP เขียนไว้ในปี 2018

"นักพัฒนาควรเลิกใช้ Agile

หากแนวคิด 'Agile' ไม่ถูกนำไปใช้อย่างเหมาะสม สิ่งที่เกิดขึ้นคือการแทรกแซงนักพัฒนามากขึ้น ให้เวลาทำงานน้อยลง กดดันมากขึ้น และเรียกร้องให้ 'เร่งให้เร็วขึ้น' ซึ่งไม่ดีต่อนักพัฒนา และท้ายที่สุดก็ไม่ดีต่อบริษัทด้วย เพราะการทำ 'Agile' แบบไม่ถูกต้องมักนำไปสู่ defect มากกว่าที่ควรจะเป็น และความคืบหน้าที่ช้าลงกว่าที่ทำได้จริงอยู่มาก บ่อยครั้งนักพัฒนาฝีมือดีก็จะลาออกจากบริษัทเหล่านั้น และผลลัพธ์สุดท้ายคือองค์กรมีประสิทธิภาพต่ำกว่าก่อนนำ 'Agile' มาใช้อีก"

  • อีกบทความดังที่ Dave Thomas ผู้ลงนามอีกคนหนึ่งและผู้ร่วมก่อตั้ง Practical Programming เขียนไว้ในปี 2014

"Agile ตายแล้ว (ขอให้ Agility จงอยู่ตลอดไป)

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

ดังนั้นผมคิดว่าถึงเวลาแล้วที่จะปลดระวางคำว่า 'Agile'"

[ Retro : ย้อนกลับไปดูอดีต ]

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

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

  • แต่หวังว่าการเริ่มต้นถกเถียงกันถึงประวัติศาสตร์และวิสัยทัศน์ดั้งเดิม จะช่วยให้เราจำได้ว่าเราควรก้าวต่อไปอย่างไร

  • ถึงอย่างนั้น ข่าวดีก็คือ หลักการของ Agile Manifesto ยังฉลาดและเหมาะสมในวันนี้ไม่ต่างจากเมื่อ 20 ปีก่อน และแม้แต่คนที่ดูเหมือนจะเป็นพวกละทิ้งศรัทธาอย่าง Jeffries หรือ Thomas ก็ยังคิดเช่นนั้น

  • ในบทความที่กล่าวถึงข้างต้น Jeffries พูดไว้ว่า

"อย่างไรก็ตาม คุณค่าและหลักการของ Manifesto for Agile Software Development ยังคงเป็นวิธีสร้างซอฟต์แวร์ที่ดีที่สุดเท่าที่ผมรู้จัก และจากประสบการณ์อันยาวนานและหลากหลายของผม ไม่ว่าองค์กรใหญ่จะใช้วิธีการแบบใด ผมก็จะยึดตามคุณค่าและหลักการเหล่านี้"

  • ผมเห็นด้วยกับความเห็นนี้

  • ทุกวันนี้การพูดถึง Agile ไม่ใช่เรื่องเท่หรือทันสมัยอะไรอีกแล้ว Agile นั้นน่าเบื่อ

"ทุกคนก็ทำ Agile กันอยู่แล้วใช่ไหม?"

  • ตอนนี้จึงเป็นเวลาที่เหมาะอย่างยิ่งในการมองย้อนกลับไป 20 ปีที่ผ่านมา แล้วถามตัวเองสักสองสามข้อ

→ อะไรที่ไปได้ดี?

→ อะไรที่ผิดพลาด?

→ ครั้งหน้าคุณอยากทำอะไรให้ต่างออกไป?

  • ในอีกไม่กี่เดือนข้างหน้า ผมวางแผนจะกลับไปอ่านหลักการ Agile ดั้งเดิมทั้ง 12 ข้ออีกครั้ง วางมันไว้ในบริบทของความหมายดั้งเดิม และพิจารณาคุณค่าของมันในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ปัจจุบัน

"ความหวังของผมคือ ด้วยการศึกษาหลักการก่อตั้งเหล่านี้ เราจะสามารถเรียนรู้จากอดีต และอย่างที่ Dave Thomas พูดไว้ ต่อให้เราทิ้งคำว่า 'Agile' ไป ก็ยังรักษา 'Agility (ความคล่องตัว)' เอาไว้ได้"

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
kaykim 2021-08-10

ผมเห็นด้วยกับคำอธิบายด้านล่างนี้ ส่วนที่เหลือก็ฟังไว้เท่านั้น

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

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

"ทีมพัฒนาเกมที่ยอดเยี่ยมทำให้สมาชิกทุกคนได้รับการฝึกฝนให้เข้าใจและปฏิบัติตามระเบียบวิธีการพัฒนาของสตูดิโอเป็นอย่างดี [1] นอกจากนี้ ระหว่างการพัฒนาเกมก็ยังทุ่มเทอย่างต่อเนื่องเพื่อขัดเกลาและปรับปรุงวิธีพัฒนาให้ดีขึ้นอยู่เสมอ อย่างไรก็ตาม เราไม่พบความแตกต่างของผลลัพธ์ที่มีนัยสำคัญทางสถิติระหว่าง Agile, Agile-Scrum หรือวิธีการพัฒนาแบบ Waterfall [2] สิ่งที่ทำให้ผลลัพธ์แตกต่างกันในบรรดาวิธีการพัฒนาคือกรณีที่ไม่มีวิธีการพัฒนาใด ๆ เลย: งานวิจัยของเราพบว่า การไม่มีระเบียบวิธีการพัฒนาเป็นหายนะ ไม่ว่าทีมจะมีขนาดเล็กหรือใหญ่ก็ตาม

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

(ที่มา: https://masterfarseer.blogspot.com/2015/03/5.html )

ถึงอย่างนั้น เหตุผลที่ผมยังชอบแนวทางของ Agile (ให้แม่นยำกว่านั้นคือ Scrum, XP และ Kanban) ก็เพราะมันช่วยแก้ปัญหาที่ผมกำลังเผชิญอยู่ได้ (It works!) ด้วยเหตุผลเดียวกัน ส่วนที่ผมชอบที่สุดใน "Agile Manifesto" คือ "เรากำลังค้นหาวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์ ทั้งจากการลงมือพัฒนาเองและช่วยผู้อื่นพัฒนา" เพราะมันไม่ได้เป็นวิธีการที่สร้างขึ้นจากทฤษฎี แต่ตั้งอยู่บนพื้นฐานของการที่ 'ฉันลองทำเองแล้วได้ผล และเมื่อแนะนำให้คนอื่นทำก็ได้ผลเช่นกัน' ใน Agile Software Deveopment with Scrum ที่ Ken Schwaber และ Mike Beedle เขียนไว้ ก็มีการกล่าวถึงเส้นทางที่เริ่มจากการคิดค้นแนวปฏิบัติขึ้นมาก่อน แล้วจึงค้นพบรากฐานทางทฤษฎีในภายหลัง และหากมองจากมุมนั้น ผมคิดว่าสักวันหนึ่งอาจมีใครสักคนพัฒนา Agile ให้ก้าวหน้าไปกว่านี้ หรืออาจประดิษฐ์สิ่งที่ดีกว่า Agile ขึ้นมาก็ได้

เช่นเดียวกับเครื่องมืออื่น ๆ ทั้งหมด Agile ไม่ใช่ยาครอบจักรวาล ดังนั้นผมคิดว่าสำหรับบางคนมันก็ได้ผล และสำหรับบางคนมันก็ไม่ได้ผล เพราะอย่างนั้น เดี๋ยวนี้ถ้าใครสักคนประสบความสำเร็จด้วย Agile ผมก็ไม่ได้ฮึกเหิมเป็นพิเศษ และถ้าใครล้มเหลวก็ไม่ได้ท้อแท้เป็นพิเศษเช่นกัน ขณะเดียวกัน ถ้ามีวิธีที่ดีกว่า ผมก็พร้อมเสมอที่จะลองและปรับตัว (inspect and adapt) เพราะนั่นคือบทเรียนที่แท้จริงที่ Scrum มอบให้ผม
 
kenuheo 2021-08-09

  • กระบวนการและเครื่องมือ < ปัจเจกบุคคลและปฏิสัมพันธ์

  • เอกสารที่ครอบคลุม < ซอฟต์แวร์ที่ใช้งานได้จริง

  • การเจรจาสัญญา < ความร่วมมือกับลูกค้า

  • การทำตามแผน < การตอบสนองต่อการเปลี่ยนแปลง

ถ้าลองสลับเครื่องหมายอสมการตรงนี้ดู

  • กระบวนการและเครื่องมือ > ปัจเจกบุคคลและปฏิสัมพันธ์

  • เอกสารที่ครอบคลุม > ซอฟต์แวร์ที่ใช้งานได้จริง

  • การเจรจาสัญญา > ความร่วมมือกับลูกค้า

  • การทำตามแผน > การตอบสนองต่อการเปลี่ยนแปลง

มันก็จะกลายเป็น SI

ขอบคุณสำหรับสรุปแปลครับ
 
xguru 2021-08-09

  • ทำไมผู้พัฒนาบางคนถึงเกลียด Agile https://th.news.hada.io/topic?id=661

  • คำตอบจากอดีต Engineering Director ของ Google ต่อประเด็นที่ว่าทำไมนักพัฒนาบางคนของ Google ถึงบอกว่าการพัฒนาแบบ Agile ไร้ความหมาย https://th.news.hada.io/topic?id=265

  • โมเดลทีม Squad ของ Spotify นั้นล้มเหลว https://th.news.hada.io/topic?id=2191

→ เอกสารไวท์เปเปอร์ "Scaling Agile" ของ Spotify ที่เคยมีชื่อเสียงในปี 2012 เป็นเพียงความหวังของพวกเขา และไม่เคยถูกนำไปใช้จริงอย่างสมบูรณ์