By: lew 
on 7 June 2024 - 16:41
Tags:
Topics:
Engprax บริษัทให้คำปรึกษาตรวจสอบซอฟต์แวร์ออกรายงานสำรวจวิศวกรซอฟต์แวร์ 600 คนในสหรัฐฯ และสหราชอาณาจักร ผลสำรวจพบว่าแนวทางของ Agile Manifesto หลายข้อทำให้โครงการซอฟต์แวร์มีโอกาสล้มเหลวสูงขึ้น โดยรวมแล้วโครงการที่ทำตามแนวทาง Agile มีโอกาสล้มเหลวสูงกว่าโครงการที่ไม่ใช้ถึง 268%
รายงานระบุถึงแนวทางหลายประการใน Agile Manifesto เช่น การทำให้ซอฟต์แวร์ใช้งานได้ก่อนทำเอกสารเสร็จ, การร่วมมือกับลูกค้ามากกว่าเน้นเจรจาสัญญา, การตอบสนองต่อความเปลี่ยนแปลงมากกว่าการทำตามแผนการ โดยพบว่าโครงการที่ทำตามแนวทางเหล่านี้มีโอกาสล้มเหลวสูงขึ้น เช่น การมีเอกสาร requirement ชัดเจนช่วยให้โอกาสโครงการสำเร็จเพิ่มขึ้น 50% และหาก requirements ชัดเจนก่อนเริ่มโครงการจะเพิ่มโอกาสสำเร็จถึง 97%
ปัจจัยอื่นๆ ที่ส่งผลเช่นการทำงานที่วิศวกรรู้สึกปลอดภัยที่จะพูดคุยถึงปัญหาจะช่วยให้โอกาสสำเร็จเพิ่มขึ้น 87% (รายงานยังพบว่าโปรแกรมเมอร์ในสหราชอาณาจักรกล้าพูดคุยถึงปัญหาน้อยกว่าโปรแกรมเมอร์ในสหรัฐฯ) หรือ requirements ที่เขียนจากปัญหาจริงนั้นจะเพิ่มโอกาสสำเร็จ 54%
ที่มา - Engprax
ภาพโดย Pexels
Get latest news from Blognone
Follow @twitterapi
Comments
requirement กับ scope นี่สำคัญสุดเลย ถ้าไม่วางตั้งแต่เริ่มงาน มีแต่งานจะบวมขึ้นเรื่อย ๆ จนเสร็จไม่ทันกำหนด หรือปิดงานไม่ได้กันเลย
เป็นแก่นของ agile เลย คือ
เปลี่ยนได้ทุกอย่างตามใจลูกค้า
ขอแค่จ่ายเงินมาเรื่อยๆก็พอ
เน้นรับเงิน ไม่เน้นงานเสร็จ😅
requirements ต้องมี s ลงท้ายเสมอด้วยครับ
ในฐานะคนที่ทำงานด้านนี้ คอนเฟิร์มเลยครับว่า requirement สำคัญที่สุดสำหรับเรื่องนี้ครับ และถ้าไม่ละเอียดจริง สุดท้ายมา ไม่ตรงกับ requirement ของลูกค้า แล้วงานน่าจะพังได้ง่ายมาก ๆ
Coder | Designer | Thinker | Blogger
แสดงว่าต้องกลับไปใช้ v model ดั้งเดิม เน้นตรง User requirements analysis
ความเห็นส่วนตัว Agile Manifesto เหมาะกับงานที่ พัฒนาProduct ของตัวเอง เช่น Line , shopee
เพื่อปรับเปลี่ยนให้ตอบ สนอง แข่งกับทางการตลาดได้รวดเร็ว
ส่วนงาน พัฒนา แบบ outsource project
ถ้า requirement กับ scope มันเปลี่ยนไปเรื่อยๆ ไม่สิ้นสุด
จะ พัฒนา ด้วย model ไหนก็พังทั้งหมดอยู่ดี
จริงเลย
..: เรื่อยไป
ปรกติ ลูกค้าที่ไม่ใช่บริษัท it ยากที่จะทำตาม
เอาจริง ๆ ผมว่า คนที่จะทำ Agile ได้ Effective มาก ๆ คือคนที่มีสกิลเซ็ตดี และมีความเข้าใจในธุรกิจที่ตัวเองทำ (เป็น domain expert) เพื่อที่จะตอบสนองต่อการเปลี่ยนแปลงไปมาแบบ Agile (ที่เน้นความคล่องตัวเพื่อเอามาต่อกรกับความเปลี่ยนแปลงไปมานี่ล่ะ)
ทีนี้บางทีเราดันเอา Agile ไปให้คนที่ไม่รู้เรื่องอะไรเลยทำ ต้องเรียนรู้ใหม่ ลำพังแค่ต้องเรียนรู้ตัว business domain ที่ตัวเองจะต้อง implement ก็ยากแล้ว พอเจอกับ requirement ที่อาจจะเปลี่ยน (ด้วยเหตุผลที่ว่า เพราะลูกค้าเองบางทีก็ไม่รู้ว่าต้องการอะไร) มันเลยกลายเป็นการยืนอยู่บนความไม่แน่นอนเหมือนกัน
ที่จริงผมไม่แน่ใจว่าคนที่ทำ survey ที่ว่า เคยทำ "Agile" ที่เป็น Agile จริง ๆ ไหม หรือว่าแบบฉันเคยทำ Scrum มานะแล้วก็คิดไปเองว่าเคยทำ Agile (ทั้ง ๆ ที่ Scrum เองก็อาจจะเป็น Scrumfall ก็ได้ แล้ว Scrum ก็ไม่เชิงว่าเป็น Agile ซะทีเดียว) อันนี้เป็นอีกมุมที่ผมว่าน่าสนใจเหมือนกัน
อันนี้เล่าให้ฟัง อาจจะไม่ได้เกี่ยวมาก ที่ทำงานนึงที่ผมเคยไปทำอยู่ช่วงสั้น ๆ (ใกล้ ๆ กับ Blognone นี่ล่ะ) ในทีมคือมีคนที่ technical skill ไม่แข็งแรงมากขนาดนั้นในทีม แล้วตัว domain knowledge ผมเองก็ไม่ได้คิดว่าเก่งขนาดนั้นเหมือนกัน (ผมไม่ได้จะบอกว่าน้องคนนี้ไม่เก่งนะ ผมแค่คิดว่าน้องเค้ายังใหม่กับทุก ๆ อย่างที่เขาโดนโยนมา) พอมาเจอกับ scrum แล้วเจอทีมที่คาดหวังว่า task ที่เขาได้รับจะต้องเสร็จภายในสัปดาห์แรก แล้วครึ่งสัปดาห์ที่สองก็ส่งงานให้รีวิวกัน จากนั้นก็ sprint retro ผมเจอว่าน้องคนนี้ทุก sprint จะโดนบีบให้แก้งานให้จบก่อนวันพุธในสัปดาห์ที่สอง แล้วทุกคนในทีมก็ต้องมารุมน้องคนนี้กันถึงสองทุ่มสามทุ่มเพื่อบีบให้ปิดให้ได้ แน่นอนว่ามันทำให้งานมันออกได้ทุก sprint แต่กลายเป็น WLB ทุกคนเสียหมด น้องคนนี้ก็กลายเป็นมองตัวเองเป็นภาระของคนในทีม (ทั้ง ๆ ที่ไม่ได้ทำอะไรผิดเพราะเค้ายังใหม่กับทุกอย่างอยู่)
เรื่องนี้ปัญหามันอยู่ที่การคาดหวังจากตัว engineer สักคนว่าเฮ้ย นายต้องทำงานได้เร็วเท่านั้นเท่านี้สิโดยไม่ได้ดูศักยภาพที่แท้จริงของคนที่ทำงาน เข้าใจว่ามันเกิดจากความคาดหวังของฝ่ายธุรกิจว่าต้องทำได้เสร็จตามเวลาเท่านั้นเท่านี้ นึกสภาพว่าถ้าแบบคนทั้งทีมไม่เก่งทั้งในด้าน domain knowledge และ technical knowledge มันก็จะทำให้โปรเจคล่มได้ถ้าเวลามันบีบเข้ามา
ทั้งนี้ผมว่า Agile นี่เวิร์คกับโปรเจคแนว discovery นะ คือเน้นทดลองทำอะไรใหม่ ๆ เสร็จแล้วพอโปรเจคมันมีทิศทางที่แน่นอนแล้ว การเปลี่ยนกลับไปเป็น waterfall อาจจะเมคเซนส์มากกว่าก็ได้ (ถ้าจำไม่ผิด RE7 ก็ทำแบบนี้)
ปล. สมัยผมทำงานแรก ๆ เริ่มงานใหม่สามเดือนแรกคือเทรนล้วน ๆ ทั้งด้าน business knowledge ขั้นพื้นฐาน ทั้งด้าน technical skill ขั้นพื้นฐาน ฯลฯ ผมไม่แน่ใจว่า บ.ไทยมีทำแบบนี้บ้างหรือเปล่า หรือมาถึงถีบลูกสิงโตตกเขา ถ้าสิงโตเอาตัวรอดไม่ได้ก็ปล่อยหลุดทดลองงานไป อะไรแบบนี้ครับ
คุณตาหวานโชคดีมากๆแล้วครับที่เค้าเทรนให้สามเดือนเต็มๆ เมืองไทยนี่น่าจะหายากมากๆ ส่วนใหญ่น่าจะอารมณ์ถีบลูกแมว แนวๆ on the job training มอบหมายงานเล็กๆให้ค่อยๆทำ จริงๆอาจจะมีหลากหลายวิธีแหละ แต่ที่ผมเห็นส่วนใหญ่จะประมาณนี้
ตอนนี้ที่อยากรู้คือบริษัทต่างชาติยังเทรนแบบนี้อยู่รึเปล่า
..: เรื่อยไป
ของผมเป็น บ.ฝรั่ง แล้วก็เหตุการณ์เกิดขึ้นเมื่อนานมาแล้ว เผลอ ๆ บ.ต่างชาติเดี๋ยวนี้อาจจะไม่เทรนแบบนี้แล้วก็ได้ 555
Agile มันก็แค่เครื่องมือนะ ถ้าใช้ให้ถูกที่ถูกทางมันก็ดีแหละ ถึงส่วนตัวจะไม่ชอบมันมากๆก็เถอะ 5555
ตัวอย่างบ.ใหญ่ๆ อยากใช้ agile แต่ไปจ้าง outsource ซึ่งเค้าไม่มีความรู้สึกถึงความเป็นทีมความเป็นเจ้าของโปรดักซ์ ทำๆตามที่ AC เขียนในแต่ละ US เสร็จพอ ไม่สนใจเรื่องอื่น ซึ่งมันก็ขัดกับความ agile ที่ต้อง adaptive to change อยู่ละ
ถามหาแต่ user requirement คิออะไร เขียนมา จะทำ แต่ถ้าทำแล้วแก้ ก็ดราม่า ตอนแรกบอกแบบนี้ ทำไมจะแก้ ไม่อยากแก้ บลาๆ พังสิ 555
ในงานวิจัยนี้ เค้าวัดความสำเร็จยังไงนะครับ
ผมอ่านต้นทางมาก็ยังไม่รู้เลยว่าเขาวัดยังไงเหมือนกัน (ส่วนตัวคิดว่าน่าจะนับจาก launch กับ cancel หรือไม่ก็ launch แบบตามความคาดหวัง กับ launch แบบไม่เป็นไปตามความคาดหวัง)
Coder | Designer | Thinker | Blogger
ทุกคนอวยกันสวยหรู ใครไม่ใช้เชย ใครใช้โคตรเท่คุยยันชาติหน้า
แต่ใช้จริง suffer
จริงเลยเน้นขายงาน พอทำจริง Agile จะกลายเป็นกระจุย คนพูดก็ไม่รู้ ส่วนคนทำก็ฮะ😆😆😆
สมัยผมเริ่มอาชีพผมไปนั่งอ่านบทความวิทยากร ผมก็เบะปากใส่เลย กับงาน core การเงินไปทำแบบนี้มีแต่พังกับพัง แต่ชะรอยเจอบอสสั่งงานแบบ agile (รึ on demand หว่า) ยับครับ งานงอกจัดๆ
นับแต่นั้นมาผมเห็นใครพูดเรื่อง agile กับ scrum ผมป้ายหัวไว้เลยว่าขี้โม้ เด็กเลี้ยงแกะ
ยังสงสัยในนิยามคำว่า "สำเร็จ" ในการสำรวจนี้อยู่ สำเร็จที่หมายถึงแค่ "ทำเสร็จ" หรือ สำเร็จที่หมายถึงบรรลุวัตถุประสงค์ในการจัดทำ software ถ้าทำงานแบบ waterfall ทำงานแบบ silo ก็อาจจะเสร็จ สำเร็จกลายเป็น final product ที่สวยหรูสำหรับทีม แต่ก็อาจจะ fail หลังจาก launch ไม่มีใครอยากใช้เพราะ product ไม่ได้ fit กับตลาด แบบนี้ก็เป็นได้ครับ
นึกถึงตอนทำงาน
พยายามบอกให้ รวบรวมความคิด/สรุปก่อนว่า
"งานเสร็จ" คือ อะไร
แต่หัวหน้ากำลังบ้า Agile ยัดข้อหา
"พวก Waterfall ตกยุค"
แล้วก็ลุยกันไปแบบ เพิ่ม/ลด โน่นนั่นนี่ ตามที่ไปดีลเรื่อยๆ ไม่เสร็จซะที
ลูกค้างบบานปลาย เพราะคิดเงินลูกค้าไปเรื่อยๆ
จนเขาปิดงบไม่จ่ายเพิ่มแล้วแต่งานยังไม่เสร็จ
จะควักเนื้อเพื่อปิดงาน ก็ขาดทุน
แถมพอมีคนในทีมออก คราวนี้ชิบหายละ
คนมาแทนต้องแกะโค้ด จนไม่ได้งานไปอีก
แปลกใจว่า มันฮิตในวงการ dev มาได้ยังไงร่วม 20ปี 😑
ผมว่าอันนี้ออกแนว sunk cost แล้วล่ะ การที่ใช้ agile ทำ software แล้วรู้ว่า product มันจะ fail แน่ๆ แล้วก็เลิกทำไป ผมว่านี่มันก็อาจจะเป็นคำตอบหนึ่งของการนำ agile มาใช้ได้เหมือนกัน
หลักการ Agile มีง่ายๆ แค่
ให้คนคุยกัน ทำซอฟต์แวร์ที่ใช้งานได้จริง (เล็กๆ ตั้งแต่แรกๆ ไม่ใช่รอเป็นปี)
ทำงานกับลูกค้าไม่ใช่มโนเอง แล้วก็ตอบสนองต่อการเปลี่ยนแปลง ไม่ใช่ยึดตามสัญญา (เพราะล็อคเวลานานเป็นปี)
ทำไมถึงบิดเบือนกันไปไกลจริงๆ ไม่นับว่าเข้าใจผิด Agile == Scrum ด้วย
อีกอย่างเอกสาาร เครื่องมือที่ใช้ หรือสัญญา ก็ไม่ใช่ว่าจะไม่ทำ แค่ให้โฟกัสอีกอย่างทีสำคัญกว่าเท่านั้น
ถูกครับ
จริงๆหลักมันแค่ “ทำให้เร็ว” โดย “แบ่งเป็นงานเล็กๆ ที่ใช้งานได้จริง”
เพื่อขึ้น s/w ไป ทดสอบว่ามันใช้งานได้กับคนใช้จริงๆ หรือ business model มันได้ผลจริงๆ ไม่ใช่ dev ไปปีนึงแล้วออกแอพมา business model นี้เจ๊ง
ปัญหามันน่าจะเป็นระดับ management อยากใช้ agile แต่ไม่มี mindset แบบ agile
อยากได้ความสมบูรณ์แบบ นั่งเกลา requirement แรก เป็นหลายๆ เดือน แล้วก็ไปเร่งให้ทำตาม timeline แล้วตัวเองก็เปลี่ยน requirement ไปเรื่อยๆ หลังจากเริ่ม development process ไปแล้ว (เพราะเข้าใจว่า agile ทำได้)
แทนที่จะรีบให้ requirement ไป ให้ไปทำ ออก product มาใช้ แล้วค่อยดูว่าติดขัดอะไรค่อยแก้
คือปัจจุบันมันแย่ เพราะคนเอา waterfall มายัดความเร่งกับ flexible แบบ agile แทน
This is the reason why I love Scrum 🥰
Agile มันดีนะ "ถ้า" ทีมสามารถปั่น Product ออกมาใช้ได้เลยหลังจากวาง Requirement ครั้งแรก (และห้าม Scope เวอร์วังด้วย) จากนั้นเรา Increment/Adapt ไปเรื่อย ๆ จนกว่าเราจะได้ Product ที่ใช้งานได้จริง แต่ผมเชื่อว่าส่วนมากไม่ได้เป็นแบบนั้น เพราะเจอ Requirement ออกมาตู้มเดียวแล้วทำไม่ทัน จากนั้นโดนนั่งเรียง List ที่ต้องแก้แถมโดนเพิ่ม Requirement เข้าไปอีก = 💀
ผมเองเจอ Agile เข้าจริงจังในงาน Outsource ไม่กี่ครั้งเอง ส่วนมากลูกค้าแทบจะวางมาให้แบบ Scrumfall หมดเลย Req และ Design ที่อยากได้ชัดเจนตั้งแต่แรก ปั่น + แก้บั๊กกลางน้ำ แล้ว Launch ออกไปแบบสบาย ๆ
มันอยู่ที่คนล้วนๆ
Water fall ถ้าคนห่วย ก็ fail
Agile ถ้าคนห่วยก็ fail