requirement กับ scope นี่สำคัญสุดเลย ถ้าไม่วางตั้งแต่เริ่มงาน มีแต่งานจะบวมขึ้นเรื่อย ๆ จนเสร็จไม่ทันกำหนด หรือปิดงานไม่ได้กันเลย

หรือ requirment ที่เขียน > หรือ requirement ที่เขียน

ในฐานะคนที่ทำงานด้านนี้ คอนเฟิร์มเลยครับว่า requirement สำคัญที่สุดสำหรับเรื่องนี้ครับ และถ้าไม่ละเอียดจริง สุดท้ายมา ไม่ตรงกับ requirement ของลูกค้า แล้วงานน่าจะพังได้ง่ายมาก ๆ

แสดงว่าต้องกลับไปใช้ 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 ขั้นพื้นฐาน ฯลฯ ผมไม่แน่ใจว่า บ.ไทยมีทำแบบนี้บ้างหรือเปล่า หรือมาถึงถีบลูกสิงโตตกเขา ถ้าสิงโตเอาตัวรอดไม่ได้ก็ปล่อยหลุดทดลองงานไป อะไรแบบนี้ครับ

Agile มันก็แค่เครื่องมือนะ ถ้าใช้ให้ถูกที่ถูกทางมันก็ดีแหละ ถึงส่วนตัวจะไม่ชอบมันมากๆก็เถอะ 5555
ตัวอย่างบ.ใหญ่ๆ อยากใช้ agile แต่ไปจ้าง outsource ซึ่งเค้าไม่มีความรู้สึกถึงความเป็นทีมความเป็นเจ้าของโปรดักซ์ ทำๆตามที่ AC เขียนในแต่ละ US เสร็จพอ ไม่สนใจเรื่องอื่น ซึ่งมันก็ขัดกับความ agile ที่ต้อง adaptive to change อยู่ละ
ถามหาแต่ user requirement คิออะไร เขียนมา จะทำ แต่ถ้าทำแล้วแก้ ก็ดราม่า ตอนแรกบอกแบบนี้ ทำไมจะแก้ ไม่อยากแก้ บลาๆ พังสิ 555

ในงานวิจัยนี้ เค้าวัดความสำเร็จยังไงนะครับ

ทุกคนอวยกันสวยหรู ใครไม่ใช้เชย ใครใช้โคตรเท่คุยยันชาติหน้า
แต่ใช้จริง suffer

นึกถึงตอนทำงาน
พยายามบอกให้ รวบรวมความคิด/สรุปก่อนว่า
"งานเสร็จ" คือ อะไร

แต่หัวหน้ากำลังบ้า Agile ยัดข้อหา
"พวก Waterfall ตกยุค"
แล้วก็ลุยกันไปแบบ เพิ่ม/ลด โน่นนั่นนี่ ตามที่ไปดีลเรื่อยๆ ไม่เสร็จซะที
ลูกค้างบบานปลาย เพราะคิดเงินลูกค้าไปเรื่อยๆ
จนเขาปิดงบไม่จ่ายเพิ่มแล้วแต่งานยังไม่เสร็จ
จะควักเนื้อเพื่อปิดงาน ก็ขาดทุน

แถมพอมีคนในทีมออก คราวนี้ชิบหายละ
คนมาแทนต้องแกะโค้ด จนไม่ได้งานไปอีก

แปลกใจว่า มันฮิตในวงการ dev มาได้ยังไงร่วม 20ปี 😑

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

ทำไมถึงบิดเบือนกันไปไกลจริงๆ ไม่นับว่าเข้าใจผิด Agile == Scrum ด้วย

อีกอย่างเอกสาาร เครื่องมือที่ใช้ หรือสัญญา ก็ไม่ใช่ว่าจะไม่ทำ แค่ให้โฟกัสอีกอย่างทีสำคัญกว่าเท่านั้น

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