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

<p>- ตอนนี้ผ่านไป 20 ปีแล้วนับตั้งแต่มีการประกาศ Agile Manifesto (ปฏิญญา Agile) และมีข้อเท็จจริงชัดเจนอยู่ 2 ข้อคือ<br /> 1. Agile ชนะในแง่ของการตั้งชื่อ ไม่มีใครอยากถูกเรียกว่า non-Agile<br /> 2. แต่ในแง่ของการนำ Agile ไปปฏิบัติจริงนั้น ยังห่างไกลจากแนวคิดเชิงปฏิวัติของผู้ก่อตั้งมาก<br /> - "ทุกคนบอกว่าตัวเองทำ Agile แต่แทบไม่มีใครที่ Agile จริง ๆ" แล้วทำไมสถานการณ์ถึงกลายเป็นแบบนี้?<br /> <br /> [ Whence The Manifesto : ปฏิญญาเริ่มต้นขึ้นอย่างไร ]<br /> - กุมภาพันธ์ 2001 กลุ่มผู้เชี่ยวชาญซอฟต์แวร์ 17 คนมาพบกันที่สกีรีสอร์ตในยูทาห์<br /> - หลังจากถกเถียงกันอยู่หลายวัน พวกเขาได้ร่วมกันเขียน "Agile Software Development Manifesto"<br /> <br /> - ประเด็นสำคัญคือ พวกเขาเป็น "Practitioner (ผู้ปฏิบัติงานจริง)" ไม่ใช่ PM, CTO หรือ VP Eng พวกเขาคือนักพัฒนา โปรแกรมเมอร์ นักวิทยาศาสตร์ และวิศวกร ตอนนั้นพวกเขายังคงเขียนโค้ดและร่วมมือกับผู้มีส่วนได้ส่วนเสียเพื่อแก้ปัญหาอยู่ นี่สำคัญมาก<br /> - อีกจุดหนึ่งคือ Agile Manifesto ไม่ได้ถือกำเนิดขึ้นจากความว่างเปล่า หลายคนในกลุ่มมีวิธีการที่ตนเองสร้างขึ้นหรือกำลังเผยแพร่อยู่แล้ว <br /> → XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming <br /> <br /> - ทุกคนในกลุ่มมีประสบการณ์ด้านการพัฒนาซอฟต์แวร์อย่างยาวนาน และกำลังมองหาทางเลือกแทนกระบวนการพัฒนาซอฟต์แวร์แบบหนักหน่วงที่ขับเคลื่อนด้วยเอกสารซึ่งเป็นกระแสหลักของตลาดในเวลานั้น<br /> - แกนกลางของปฏิญญาคือการอธิบายคุณค่า 4 ประการ<br /> <br /> "เรากำลังค้นหาวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์ ทั้งจากการลงมือทำเองและจากการช่วยผู้อื่นทำงานนี้ ผ่านงานนี้ เราได้เห็นคุณค่าของสิ่งต่อไปนี้:<br /> - Individuals and interactions (บุคคลและปฏิสัมพันธ์) มากกว่า processes and tools (กระบวนการและเครื่องมือ)<br /> - Working software (ซอฟต์แวร์ที่ใช้งานได้จริง) มากกว่า comprehensive documentation (เอกสารที่ครอบคลุมทุกอย่าง)<br /> - Customer collaboration (การร่วมมือกับลูกค้า) มากกว่า contract negotiation (การเจรจาสัญญา)<br /> - Responding to change (การตอบสนองต่อการเปลี่ยนแปลง) มากกว่า following a plan (การทำตามแผน)<br /> กล่าวคือ แม้สิ่งที่อยู่ทางซ้ายจะมีคุณค่า แต่เราให้คุณค่ากับสิ่งที่อยู่ทางขวามากกว่า"<br /> <br /> [ A New Hope : ความหวังใหม่ ]<br /> - เมื่อมองจากมุมมองของปี 2021 มันอาจง่ายที่จะคิดว่าการพัฒนาซอฟต์แวร์สมัยใหม่เป็นเรื่องปกติ แต่ในปี 2001 แนวคิดเหล่านี้ถือว่าหัวก้าวหน้ามาก<br /> - จะเริ่มพัฒนาซอฟต์แวร์ก่อนรวบรวม requirement ทั้งหมดและก่อนประเมินทุกฟีเจอร์งั้นเหรอ? บ้าชัด ๆ !<br /> - ประเด็นสำคัญที่กำลังถูกลืมคือ ในช่วงแรก Agile เปิดเผยและเป็นปฏิปักษ์กับการบริหารอย่างชัดเจน<br /> <br /> - ตัวอย่างเช่น Ken Schwaber ผู้ร่วมก่อตั้ง Scrum เคยเสนอให้ยกเลิกตำแหน่งผู้จัดการโครงการทั้งหมด ไม่ใช่แค่ถอด PM ออกจากโปรเจกต์ แต่ถึงขั้นควรยกเลิกอาชีพนี้ออกจากทั้งอุตสาหกรรม<br /> <br /> "เราพบว่าบทบาทของผู้จัดการโครงการนั้น ไม่ก่อให้เกิดผลิตภาพในงานที่ซับซ้อนและต้องใช้ความคิดสร้างสรรค์ <br /> ความคิดของผู้จัดการโครงการที่ถูกแสดงออกมาในรูปของแผนโครงการ <br /> ไม่ได้เป็นการรวบรวมสติปัญญาของทุกคนเพื่อแก้ปัญหาให้ดีที่สุด <br /> แต่กลับจำกัดความคิดสร้างสรรค์และสติปัญญาของทุกคนไว้ในสิ่งที่เขียนอยู่ในแผน"<br /> <br /> - Scrum master แทบไม่มีอำนาจ และไม่มีสิทธิ์โหวตประเด็นต่าง ๆ พวกเขาเป็น servant leader* คอยปกป้องทีมและกำจัดอุปสรรค แต่ไม่ได้บริหารทีม <br /> → servant leader : ผู้นำที่รับใช้ผู้ใต้บังคับบัญชา ช่วยให้พวกเขาเติบโตและพัฒนา สร้างความไว้วางใจระหว่างผู้นำกับผู้ตาม เพื่อให้ผู้ตามมีส่วนร่วมบรรลุเป้าหมายขององค์กรด้วยตนเอง <br /> - เดิมที XP ก็มี Tracker และ Coach ซึ่งทำงานในลักษณะคล้ายกัน <br /> <br /> - Alistair Cockburn ผู้สร้าง Crystal และสถาปัตยกรรม Hexagonal เคยพูดไว้ในเธรด Twitter ล่าสุดว่า <br /> "Scrum ปิดดีลมหาศาลในดินแดนที่เป็นศัตรูได้:<br /> - ฝ่ายบริหารสามารถเปลี่ยนทิศทางได้ 12 ครั้งต่อปี หลังแต่ละ sprint ตามแบบที่ต้องการ<br /> - ทีมได้ช่วงเวลาหนึ่งเดือนที่เงียบสนิท ไม่มีการขัดจังหวะหรือเปลี่ยนทิศทาง เพื่อทำงานคิดหนักและงานจริงจัง <br /> - ทีมสามารถประกาศได้ในการ Bid (เพื่อกำหนดลำดับความสำคัญ) ว่าภายในหนึ่งเดือนทำอะไรได้และทำอะไรไม่ได้ โดยไม่มีการแทรกแซงจากฝ่ายบริหาร<br /> - ไม่มีผู้บริหารคนไหนเคยได้ดีลที่ดีกว่านี้<br /> - และไม่มีทีมพัฒนาทีมไหนเคยได้ดีลที่ดีกว่านี้<br /> "<br /> (ในเธรดนี้ เดิมทีเริ่มจากคำถามว่า "แนวคิดที่ว่าทีม Scrum ต้องทำ item ทั้งหมดที่จัดสรรไว้ใน sprint ให้เสร็จ 100% มาจากไหน? มันไร้สาระมาก" และนี่คือคำตอบ ขอแนะนำให้อ่านเธรดต้นฉบับทั้งหมด)<br /> <br /> - แม้ผมจะเป็น certified scrum master และทำงานกับทีม Agile มานานกว่า 15 ปี อีกทั้งยังอ่านหนังสือดังในสายนี้มามาก แต่ก็ไม่เคยเห็นใครอธิบายแนวคิดของ Scrum ได้ชัดเจนและกระชับเท่านี้มาก่อน <br /> - Scrum ถูกสร้างมาให้ทำงานได้ในสภาพแวดล้อมที่เป็นปรปักษ์ มันคือข้อตกลงระหว่างนักพัฒนาที่ต้องการเวลาในการคิดและสำรวจ กับผู้จัดการที่ชอบกดดันควบคุม<br /> <br /> [ The Empire Strikes Back : จักรวรรดิโต้กลับ ]<br /> - ในบางแง่ Agile คือขบวนการแรงงานระดับรากหญ้า มันเริ่มจากผู้ปฏิบัติงานจริงแล้วค่อย ๆ ไต่ขึ้นไปถึงฝ่ายบริหาร แล้วมันสำเร็จได้อย่างไร?<br /> - ส่วนหนึ่งเพราะจำนวนนักพัฒนาเพิ่มขึ้น และคุณค่าที่พวกเขามอบให้ธุรกิจก็เพิ่มขึ้นด้วย<br /> - แต่เหตุผลที่ใหญ่กว่าคือ วิธีพัฒนาแบบ Waterfall ดั้งเดิมใช้งานไม่ได้ผลจริง<br /> - เมื่อซอฟต์แวร์ซับซ้อนขึ้น ความเร็วของธุรกิจสูงขึ้น และผู้ใช้มีความคาดหวังมากขึ้น การวางแผนทุกอย่างล่วงหน้าจึงกลายเป็นเรื่องเป็นไปไม่ได้<br /> - การยอมรับการพัฒนาแบบ iterative จึงเป็นเรื่องมีเหตุผล แต่สำหรับผู้จัดการที่เคยชินกับการวางแผนทุกอย่าง มันก็ชวนหวั่นใจอยู่บ้าง <br /> <br /> - ช่วงกลางทศวรรษ 2000 ฝ่ายบริหารยังไม่ได้ยอมรับมันนัก <br /> - แต่แล้วก็เริ่มมีเสียงว่า "ลองไอเดียบ้าบอนี่ที่พวกวิศวกรพูดถึงกันอยู่ตลอดดูสักครั้งไหม ตอนนี้เราก็ส่งงานไม่ทัน deadline อยู่แล้ว จะเลวร้ายไปกว่านี้ได้แค่ไหน?"<br /> - แต่ที่น่าแปลกคือมันเริ่มใช้ได้ผล ตอนแรกทีมยังเกร็ง ๆ อยู่บ้าง (จึงช้า) แต่เมื่อเวลาผ่านไปก็เริ่มเข้าใจว่ารูปแบบไหนเวิร์กกับแต่ละทีม แล้วความเร็วก็เริ่มมา<br /> - หลังผ่านไปไม่กี่ sprint พวกเขาก็เริ่มเห็นพลังของซอฟต์แวร์ที่ใช้งานได้จริง การทำงานร่วมกัน การใช้เวลาตรวจสอบและปรับตัว และการจัดลำดับความสำคัญให้สิ่งเหล่านี้อยู่เหนืออย่างอื่นทั้งหมด<br /> <br /> - ราว 5 ปีให้หลัง Agile เปลี่ยนจากแนวทางที่เคยมีแต่คนได้ยินชื่อ มาเป็นสิ่งที่แม้ไม่ใช่ทุกคนจะคุ้นเคย แต่ก็แพร่หลายมากขึ้น <br /> - ในปี 2005 Agile และ TDD เป็นตัวสร้างความแตกต่างอย่างแท้จริง <br /> - ในปี 2010 ทีมซอฟต์แวร์ยุคใหม่แทบทั้งหมดต่างก็ทำ Agile ในรูปแบบใดรูปแบบหนึ่ง<br /> - อย่างน้อยในโลกที่ปรึกษานั้นมันกลายเป็นฟองสบู่ไปแล้ว แม้องค์กรใหญ่จะยังเคลื่อนไหวช้าเสมอก็ตาม<br /> <br /> "เราทำได้แล้ว! เราชนะแล้ว! มาฉลองกันเถอะทุกคน"<br /> และนี่คือจุดจบของเรื่อง คุณสามารถปิดแท็บเบราว์เซอร์ได้เลย<br /> <br /> "Winning was easy, young man. Governing’s harder."<br /> "การชนะนั้นง่าย เจ้าหนุ่ม แต่การปกครองยากกว่า" <br /> → George Washington ตามที่ถูกถ่ายทอดใน Hamilton (มิวสิคัล)<br /> <br /> - แต่น่าเสียดาย เช่นเดียวกับการปฏิวัติหลายครั้ง ประวัติศาสตร์ของ Agile ไม่ได้ดำเนินไปในแบบที่ผู้ก่อตั้งจินตนาการไว้<br /> → ปรากฏว่าการให้ความสำคัญกับ "บุคคลและปฏิสัมพันธ์" เป็นแนวคิดที่ขายต่อได้ยาก การขาย process และ tools นั้นง่ายกว่ามาก<br /> → ปรากฏว่าการสร้าง "ซอฟต์แวร์ที่ใช้งานได้จริง" ยากกว่าการทำแผนที่ไม่สมจริงและเอกสารกองโต<br /> → "การร่วมมือกับลูกค้า" ต้องอาศัยความไว้วางใจและความเปราะบาง (vulnerability) ซึ่งไม่ใช่สิ่งที่มีอยู่ในธุรกิจเสมอไป<br /> → "การตอบสนองต่อการเปลี่ยนแปลง" มักถูกลดน้ำหนักลงต่อหน้าแรงกดดันจากผู้บริหารที่ต้องการวางแผนระยะยาวและควบคุมทุกอย่าง<br /> <br /> "ปรากฏว่าเมื่อทำ Agile ไม่ถูกต้อง มันมักให้ความรู้สึกเหมือนความโกลาหล"<br /> <br /> - แต่นั่นไม่ได้หมายความว่าคุณค่าทั้ง 4 ข้อนี้ผิด<br /> - มันหมายถึงว่าการทำให้ทุกอย่างเวิร์กต้องใช้ความพยายาม และต้องมีความกล้าที่จะยอมรับว่าซอฟต์แวร์นั้นโดยธรรมชาติยุ่งเหยิงและสับสน <br /> - ต้องเข้าใจและเชื่อว่า ถ้าเรียนรู้ ปรับตัว พัฒนา และปล่อยของต่อไปเรื่อย ๆ สุดท้ายเราจะไปถึงจุดที่ดีกว่า Waterfall มาก เป็นจุดที่ซื่อสัตย์กับความจริง สมจริง และมีผลิตภาพมากกว่าเดิมอย่างมาก<br /> <br /> "ขบวนการ Agile ไม่ใช่ anti-methodology <br /> จริง ๆ แล้วพวกเราหลายคนอยากเห็นความเชื่อมั่นในคำว่า 'methodology' ได้รับการฟื้นฟู เราต้องการให้ความสมดุลกลับคืนมา <br /> เรายอมรับการทำ modeling แต่ไม่ใช่เพื่อเอา diagram ไปกองฝุ่นไว้ในห้องเก็บของของบริษัท <br /> เรายอมรับ documentation แต่ไม่ใช่หนังสือหลายร้อยหน้าที่ไม่เคยถูกดูแลและแทบไม่มีใครใช้ <br /> เราวางแผน แต่ก็รับรู้ถึงข้อจำกัดของแผนในสภาพแวดล้อมที่ปั่นป่วน <br /> คนที่ตีตราผู้สนับสนุน XP, Scrum หรือวิธีแบบ Agile อื่น ๆ ว่าเป็น 'Hacker' นั้น กำลังไม่เข้าใจความหมายดั้งเดิมของคำว่า 'methodology' และ 'hacker'"<br /> - Jim Highsmith, History: The Agile Manifesto<br /> <br /> - นี่คือประเด็นสำคัญ เรายังคงทำแผนและเอกสาร และเราควรจริงจังกับ Agile มันคือเรื่องของความสมดุล<br /> - แต่ถ้าองค์กรของคุณกำลังลำบากกับการเปลี่ยนผ่านสู่ Agile และกำลังจมอยู่ในความโกลาหล เมื่อมีใครยื่นเรือชูชีพอย่าง certification, process หรือ tools มาให้ คุณก็มักจะกระโดดขึ้นไปทันที<br /> - ฝ่ายบริหารเข้าใจ process และ tools ได้ดีกว่า "ทีมที่จัดการตัวเองได้" มาก <br /> <br /> [ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (การกลับมา) ]<br /> - ตรงนี้โครงสร้าง 3 องก์ของผมเริ่มพังนิดหน่อย เพราะเราไม่เห็นกบฏผู้กล้าที่กลับมาพร้อมบางสิ่งที่ไม่ติดชื่อ Agile<br /> <br /> - vendor เครื่องมือ ที่ปรึกษาด้าน process และผู้เชี่ยวชาญ มักให้คำสัญญาในสิ่งที่พวกเขาไม่มีวันส่งมอบได้จริง<br /> - นี่คือเหตุผลที่เรามี SAFe (Scale Agile Framework for Enterprise), Scaled Scrum และ Agile สำหรับองค์กรขนาดใหญ่อีกหลายเวอร์ชัน<br /> - framework เหล่านี้ไม่ได้ถูกสร้างขึ้นด้วยเจตนาร้าย และอาจมีคุณค่าอยู่บ้างในบริบทที่เหมาะสม<br /> - แต่ผมจะไม่เรียกมันว่า Agile<br /> - เมื่อพยายาม scale วิธีการที่เน้นบุคคลและปฏิสัมพันธ์เป็นหลัก ปัญหาย่อมเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ และคุณค่าเดิมของวิธีการก็ถูกบิดเบือนไปด้วย<br /> <br /> - บทความดังที่ Ron Jeffries ผู้ลงนามในปฏิญญา Agile และผู้ร่วมก่อตั้ง XP เขียนไว้ในปี 2018<br /> <br /> "นักพัฒนาควรเลิกใช้ Agile<br /> หากแนวคิด 'Agile' ไม่ถูกนำไปใช้อย่างเหมาะสม สิ่งที่เกิดขึ้นคือการแทรกแซงนักพัฒนามากขึ้น ให้เวลาทำงานน้อยลง กดดันมากขึ้น และเรียกร้องให้ 'เร่งให้เร็วขึ้น' ซึ่งไม่ดีต่อนักพัฒนา และท้ายที่สุดก็ไม่ดีต่อบริษัทด้วย เพราะการทำ 'Agile' แบบไม่ถูกต้องมักนำไปสู่ defect มากกว่าที่ควรจะเป็น และความคืบหน้าที่ช้าลงกว่าที่ทำได้จริงอยู่มาก บ่อยครั้งนักพัฒนาฝีมือดีก็จะลาออกจากบริษัทเหล่านั้น และผลลัพธ์สุดท้ายคือองค์กรมีประสิทธิภาพต่ำกว่าก่อนนำ 'Agile' มาใช้อีก"<br /> <br /> - อีกบทความดังที่ Dave Thomas ผู้ลงนามอีกคนหนึ่งและผู้ร่วมก่อตั้ง Practical Programming เขียนไว้ในปี 2014 <br /> <br /> "Agile ตายแล้ว (ขอให้ Agility จงอยู่ตลอดไป)<br /> คำว่า 'Agile' ถูกบ่อนทำลายจนแทบไม่มีความหมายเหลืออยู่ และในหลายกรณี community ของ Agile ก็กลายเป็นพื้นที่ที่ที่ปรึกษาและ vendor ใช้ขายบริการกับผลิตภัณฑ์ของตนเองเป็นหลัก เมื่อ Manifesto ได้รับความนิยม คำว่า Agile ก็กลายเป็นแม่เหล็กที่ดึงดูดทุกสิ่งที่มีอะไรให้สนับสนุน มีเวลาที่จะเรียกเก็บเงิน หรือมีผลิตภัณฑ์จะขาย จนสุดท้ายมันกลายเป็นคำทางการตลาด <br /> <br /> ดังนั้นผมคิดว่าถึงเวลาแล้วที่จะปลดระวางคำว่า 'Agile'"<br /> <br /> [ Retro : ย้อนกลับไปดูอดีต ]<br /> - สิ่งที่น่าเศร้าจริง ๆ คือการเห็นนักพัฒนารุ่นใหม่ดูถูก Agile และมองว่ามันเป็นเครื่องมือให้ฝ่ายบริหารรีดเอาคำมั่นสัญญาที่ไม่สมจริงออกมา และผลักดันให้นักพัฒนาทำงานหนักเกินไปอย่างมาก<br /> - Agile เพียงแบบเดียวที่พวกเขารู้จัก คือกลไกการควบคุมที่ถูกยัดเยียดมา ไม่ใช่เครื่องมือแห่งการให้อำนาจตนเองที่ผู้คนเคยต้อนรับด้วยความยินดี<br /> - แต่หวังว่าการเริ่มต้นถกเถียงกันถึงประวัติศาสตร์และวิสัยทัศน์ดั้งเดิม จะช่วยให้เราจำได้ว่าเราควรก้าวต่อไปอย่างไร <br /> <br /> - ถึงอย่างนั้น ข่าวดีก็คือ หลักการของ Agile Manifesto ยังฉลาดและเหมาะสมในวันนี้ไม่ต่างจากเมื่อ 20 ปีก่อน และแม้แต่คนที่ดูเหมือนจะเป็นพวกละทิ้งศรัทธาอย่าง Jeffries หรือ Thomas ก็ยังคิดเช่นนั้น<br /> <br /> - ในบทความที่กล่าวถึงข้างต้น Jeffries พูดไว้ว่า <br /> "อย่างไรก็ตาม คุณค่าและหลักการของ Manifesto for Agile Software Development ยังคงเป็นวิธีสร้างซอฟต์แวร์ที่ดีที่สุดเท่าที่ผมรู้จัก และจากประสบการณ์อันยาวนานและหลากหลายของผม ไม่ว่าองค์กรใหญ่จะใช้วิธีการแบบใด ผมก็จะยึดตามคุณค่าและหลักการเหล่านี้"<br /> <br /> - ผมเห็นด้วยกับความเห็นนี้<br /> - ทุกวันนี้การพูดถึง Agile ไม่ใช่เรื่องเท่หรือทันสมัยอะไรอีกแล้ว Agile นั้นน่าเบื่อ <br /> "ทุกคนก็ทำ Agile กันอยู่แล้วใช่ไหม?"<br /> - ตอนนี้จึงเป็นเวลาที่เหมาะอย่างยิ่งในการมองย้อนกลับไป 20 ปีที่ผ่านมา แล้วถามตัวเองสักสองสามข้อ <br /> → อะไรที่ไปได้ดี?<br /> → อะไรที่ผิดพลาด?<br /> → ครั้งหน้าคุณอยากทำอะไรให้ต่างออกไป?<br /> - ในอีกไม่กี่เดือนข้างหน้า ผมวางแผนจะกลับไปอ่านหลักการ Agile ดั้งเดิมทั้ง 12 ข้ออีกครั้ง วางมันไว้ในบริบทของความหมายดั้งเดิม และพิจารณาคุณค่าของมันในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ปัจจุบัน <br /> <br /> "ความหวังของผมคือ ด้วยการศึกษาหลักการก่อตั้งเหล่านี้ เราจะสามารถเรียนรู้จากอดีต และอย่างที่ Dave Thomas พูดไว้ ต่อให้เราทิ้งคำว่า 'Agile' ไป ก็ยังรักษา 'Agility (ความคล่องตัว)' เอาไว้ได้"</p>

[kaykim]

<p>ผมเห็นด้วยกับคำอธิบายด้านล่างนี้ ส่วนที่เหลือก็ฟังไว้เท่านั้น<br /> <br /> &gt; &quot;คำว่า 'Agile' ถูกบิดความหมายจนแทบไม่เหลือความหมายอีกต่อไป และในกรณีของชุมชน Agile โดยมากก็กลายเป็นพื้นที่ที่คอนซัลแทนต์และเวนเดอร์ใช้ขายบริการและผลิตภัณฑ์ของตน&quot;<br /> <br /> เหตุผลนั้นก็อย่างที่ทุกคนรู้อยู่แล้ว คือไม่มีวิธีการใดรับประกันความสำเร็จในเชิงพาณิชย์ (หรือความสำเร็จของโปรเจกต์) ได้ และถึงขั้นมีงานวิจัยด้วยว่า อย่างน้อยในวงการเกม Agile ก็ไม่ได้ให้ผลลัพธ์ที่มีนัยสำคัญทางสถิติเหนือกว่าแนวทางอื่น ๆ:<br /> <br /> &quot;ทีมพัฒนาเกมที่ยอดเยี่ยมทำให้สมาชิกทุกคนได้รับการฝึกฝนให้เข้าใจและปฏิบัติตามระเบียบวิธีการพัฒนาของสตูดิโอเป็นอย่างดี [1] นอกจากนี้ ระหว่างการพัฒนาเกมก็ยังทุ่มเทอย่างต่อเนื่องเพื่อขัดเกลาและปรับปรุงวิธีพัฒนาให้ดีขึ้นอยู่เสมอ อย่างไรก็ตาม เราไม่พบความแตกต่างของผลลัพธ์ที่มีนัยสำคัญทางสถิติระหว่าง Agile, Agile-Scrum หรือวิธีการพัฒนาแบบ Waterfall [2] สิ่งที่ทำให้ผลลัพธ์แตกต่างกันในบรรดาวิธีการพัฒนาคือกรณีที่ไม่มีวิธีการพัฒนาใด ๆ เลย: งานวิจัยของเราพบว่า การไม่มีระเบียบวิธีการพัฒนาเป็นหายนะ ไม่ว่าทีมจะมีขนาดเล็กหรือใหญ่ก็ตาม<br /> <br /> ไม่มีคำตอบที่ถูกต้องเป็นสากลสำหรับระเบียบวิธีการพัฒนา จงเลือกวิธีการพัฒนาที่คุณเห็นว่าเหมาะสมที่สุดกับทีมและโปรเจกต์ของคุณ&quot;<br /> <br /> (ที่มา: https://masterfarseer.blogspot.com/2015/03/5.html )<br /> <br /> ถึงอย่างนั้น เหตุผลที่ผมยังชอบแนวทางของ Agile (ให้แม่นยำกว่านั้นคือ Scrum, XP และ Kanban) ก็เพราะมันช่วยแก้ปัญหาที่ผมกำลังเผชิญอยู่ได้ (It works!) ด้วยเหตุผลเดียวกัน ส่วนที่ผมชอบที่สุดใน &quot;Agile Manifesto&quot; คือ &quot;เรากำลังค้นหาวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์ ทั้งจากการลงมือพัฒนาเองและช่วยผู้อื่นพัฒนา&quot; เพราะมันไม่ได้เป็นวิธีการที่สร้างขึ้นจากทฤษฎี แต่ตั้งอยู่บนพื้นฐานของการที่ 'ฉันลองทำเองแล้วได้ผล และเมื่อแนะนำให้คนอื่นทำก็ได้ผลเช่นกัน' ใน Agile Software Deveopment with Scrum ที่ Ken Schwaber และ Mike Beedle เขียนไว้ ก็มีการกล่าวถึงเส้นทางที่เริ่มจากการคิดค้นแนวปฏิบัติขึ้นมาก่อน แล้วจึงค้นพบรากฐานทางทฤษฎีในภายหลัง และหากมองจากมุมนั้น ผมคิดว่าสักวันหนึ่งอาจมีใครสักคนพัฒนา Agile ให้ก้าวหน้าไปกว่านี้ หรืออาจประดิษฐ์สิ่งที่ดีกว่า Agile ขึ้นมาก็ได้<br /> <br /> เช่นเดียวกับเครื่องมืออื่น ๆ ทั้งหมด Agile ไม่ใช่ยาครอบจักรวาล ดังนั้นผมคิดว่าสำหรับบางคนมันก็ได้ผล และสำหรับบางคนมันก็ไม่ได้ผล เพราะอย่างนั้น เดี๋ยวนี้ถ้าใครสักคนประสบความสำเร็จด้วย Agile ผมก็ไม่ได้ฮึกเหิมเป็นพิเศษ และถ้าใครล้มเหลวก็ไม่ได้ท้อแท้เป็นพิเศษเช่นกัน ขณะเดียวกัน ถ้ามีวิธีที่ดีกว่า ผมก็พร้อมเสมอที่จะลองและปรับตัว (inspect and adapt) เพราะนั่นคือบทเรียนที่แท้จริงที่ Scrum มอบให้ผม</p>

[kenuheo]

<p>- กระบวนการและเครื่องมือ &lt; ปัจเจกบุคคลและปฏิสัมพันธ์<br /> - เอกสารที่ครอบคลุม &lt; ซอฟต์แวร์ที่ใช้งานได้จริง<br /> - การเจรจาสัญญา &lt; ความร่วมมือกับลูกค้า<br /> - การทำตามแผน &lt; การตอบสนองต่อการเปลี่ยนแปลง<br /> <br /> ถ้าลองสลับเครื่องหมายอสมการตรงนี้ดู<br /> <br /> - กระบวนการและเครื่องมือ &gt; ปัจเจกบุคคลและปฏิสัมพันธ์<br /> - เอกสารที่ครอบคลุม &gt; ซอฟต์แวร์ที่ใช้งานได้จริง<br /> - การเจรจาสัญญา &gt; ความร่วมมือกับลูกค้า<br /> - การทำตามแผน &gt; การตอบสนองต่อการเปลี่ยนแปลง<br /> <br /> มันก็จะกลายเป็น SI<br /> <br /> ขอบคุณสำหรับสรุปแปลครับ</p>

[xguru]

<p>- ทำไมผู้พัฒนาบางคนถึงเกลียด Agile https://th.news.hada.io/topic?id=661<br /> - คำตอบจากอดีต Engineering Director ของ Google ต่อประเด็นที่ว่าทำไมนักพัฒนาบางคนของ Google ถึงบอกว่าการพัฒนาแบบ Agile ไร้ความหมาย https://th.news.hada.io/topic?id=265<br /> - โมเดลทีม Squad ของ Spotify นั้นล้มเหลว https://th.news.hada.io/topic?id=2191<br /> → เอกสารไวท์เปเปอร์ &quot;Scaling Agile&quot; ของ Spotify ที่เคยมีชื่อเสียงในปี 2012 เป็นเพียงความหวังของพวกเขา และไม่เคยถูกนำไปใช้จริงอย่างสมบูรณ์<br /> <br /> - What is Agile? | Atlassian - Agile A to Z ที่ Atlassian อธิบายไว้ https://th.news.hada.io/topic?id=4389</p&gt;