- ในงานประชุม Black Hat, Moxie Marlinspike ผู้ก่อตั้ง Signal ระบุว่า ตลอด 20 ปีที่ผ่านมา นวัตกรรมซอฟต์แวร์ได้หายไปเพราะการพัฒนาแบบ Agile
- เขาชี้ว่านักพัฒนาถูกขังอยู่ใน "ชั้นนามธรรมแบบกล่องดำ" จนสูญเสียอิสรภาพที่จำเป็นต่อการสร้างนวัตกรรม
- "ใครก็ตามที่บริหารองค์กรวิศวกรรมล้วนมีปรัชญาการจัดการที่เป็นแนวคิดย่อยของ Agile หรือเป็นแนวคิดที่แตกแขนงมาจากมัน หรืออยู่ในขอบเขตของ Agile หรือเกี่ยวข้องกับมันไม่ทางใดก็ทางหนึ่ง"
- แทนที่นักพัฒนาจะขับเคลื่อนจากล่างขึ้นบน ด้วยการผสานความเชี่ยวชาญด้านวิศวกรรมเข้ากับวิสัยทัศน์ที่มองเห็นความเป็นไปได้ใหม่ ๆ ของเทคโนโลยีเดิม
กลับกลายเป็นว่าทีม Agile ถูกแยกเป็นไซโล ทำงานแยกจากกัน และไม่สามารถรู้ได้ว่าทีมอื่นกำลังทำอะไรอยู่
- นอกจากนี้ ในช่วงปิดท้ายงาน Window Snyder ผู้ก่อตั้งและ CEO ของ Thistle Technologies ยังเสริมว่า ทีมแบบกล่องดำลักษณะนี้มักขาดการมองเห็นว่าผลิตภัณฑ์ของตนเองทำงานบนหลักการใด
- Snyder ยังโต้แย้งด้วยว่า นักเรียนที่เรียนเขียนโปรแกรมไม่ได้เรียนรู้การโต้ตอบกับภาษาระดับล่างหรือ machine code แต่เรียนเฉพาะภาษาระดับสูงที่ช่วยให้การพัฒนาแอปทำได้ราบรื่น ส่งผลให้วิศวกรขาดบริบทที่จำเป็นต่อการเข้าใจว่าชิ้นส่วนของปริศนาแต่ละชิ้นประกอบเข้ากับภาพรวมที่ใหญ่กว่าอย่างไร
นักวิจัยด้านความปลอดภัยกุมกุญแจของนวัตกรรม
- Marlinspike ยังกล่าวอีกว่า ในช่วงหลายทศวรรษที่ผ่านมา วิศวกรรมซอฟต์แวร์ถูกทำให้อยู่ในรูปนามธรรมมากขึ้นเพื่อให้เร็วขึ้น ยืดหยุ่นขึ้น และก้าวหน้าไปได้มากขึ้น ขณะที่นักวิจัยด้านความปลอดภัยพยายามมองให้ทะลุผ่านนามธรรมเหล่านั้น
- "ความปลอดภัยคือกระบวนการมองเข้าไปในสิ่งที่เป็นนามธรรม เพื่อดูว่ามันทำงานจริงอย่างไร มีอะไรอยู่ข้างใต้ และบางครั้งก็เพื่อทำความเข้าใจมันให้ดีกว่าคนที่สร้างมันขึ้นมาตั้งแต่แรกเสียอีก"
- ดังนั้นเขาจึงมองว่า นักวิจัยด้านความปลอดภัยคือผู้กุมกุญแจในการผลักดันนวัตกรรมใหม่ ๆ
- เขายังเปรียบว่าการเข้าใจซอฟต์แวร์ก็เหมือนการเข้าใจเวทมนตร์ และผู้เชี่ยวชาญด้านความปลอดภัยก็คือ "ผู้ที่นั่งอยู่ในห้องสมุดและศึกษาวิชาเวทมนตร์"
ความเห็นของ GN⁺
- เป็นความเห็นที่เฉียบคมและเปี่ยมด้วยอินไซต์จาก Marlinspike ที่ชี้ให้เห็นปัญหาเชิงรากของ Agile
- เห็นด้วยกับประเด็นที่ว่า เมื่อหมกมุ่นอยู่กับนามธรรมและความเร็วในการพัฒนาเพียงอย่างเดียว นักพัฒนาก็ยิ่งห่างไกลจากความเข้าใจแนวคิดพื้นฐานมากขึ้น
- ประเด็นที่ให้ความสำคัญกับบทบาทของนักวิจัยด้านความปลอดภัยนั้นน่าประทับใจ ความปลอดภัยคือการขุดค้นความเป็นจริงที่ซ่อนอยู่หลังนามธรรม จึงอาจเป็นแรงขับของนวัตกรรมได้
- ในอีกมุมหนึ่ง นี่คือสารที่บอกว่าวิศวกรซอฟต์แวร์ควรแสวงหาความเข้าใจที่ลึกซึ้งยิ่งขึ้น
- อย่างไรก็ตาม Agile ก็มีข้อดีอย่างชัดเจนเช่นกัน จึงควรมีแนวทางที่สมดุล โดยรักษาความคล่องตัวและความยืดหยุ่นของ Agile เอาไว้ พร้อมกับเสริมรากฐานให้แข็งแรง
- เพื่อให้เป็นเช่นนั้น จำเป็นต้องเริ่มปรับปรุงตั้งแต่หลักสูตรการศึกษาด้านการพัฒนา ควรเสริมการเรียนการสอนวิชาพื้นฐาน เช่น ภาษาระดับล่าง สถาปัตยกรรมคอมพิวเตอร์ และวิชาแกนอื่น ๆ
11 ความคิดเห็น
ดูเหมือนว่ากำลังเข้าใจผิดว่าเป็นปัญหาของ Agile ทั้งที่จริงแล้วเป็นปัญหาของผู้จัดการที่เข้าใจ Agile อย่างผิดๆ
ดูเหมือนว่าตามกระแสของยุคสมัย ผู้คนมองว่าการเรียนรู้ความรู้ระดับล่างไม่ก่อให้เกิด ROI จึงลงเอยด้วยการเรียนรู้เพียงความรู้ระดับสูงเท่านั้น
ทำไมต้องไปจ้องจับผิด Agile ที่ไม่ได้เกี่ยวอะไรด้วย ...
เหมือนกำลังพูดปนกันระหว่างแนวคิด north-south กับ east-west เลยทำให้เนื้อหาชวนสับสนครับ
การที่ไม่รู้ว่าทีมอื่นทำอะไรอยู่ ผมว่าปัญหาน่าจะเป็นเรื่องโครงสร้างองค์กรแบบ cross-functional มากกว่าตัว Agile เองหรือเปล่า
ส่วนเรื่องที่ไม่ค่อยรู้ low level ถ้าดูจากเนื้อหาเหมือนกำลังบอกว่า "พอเป็นแบบนั้นก็มีแนวโน้มจะไม่ค่อยรู้ low level ด้วย" อะไรทำนองนี้นะครับ
ต่อให้จะบอกว่าการไม่รู้ว่าทีมอื่นทำอะไรอยู่ยังพอเกี่ยวกับ Agile ได้อยู่บ้าง แต่ผมนึกไม่ออกจริง ๆ ว่าการไม่รู้ low level มันเกี่ยวอะไรกับ Agile 5555
ถ้าจะว่ากันจริง ๆ ก็อาจจะใกล้เคียงกว่าว่า พอโอเพนซอร์สแพร่หลายอย่างกว้างขวาง ก็ไม่จำเป็นต้องสร้างทุกอย่างขึ้นมาเอง ไม่ต้อง
reinventing wheelและพอฝั่ง low level ก็หยิบของที่มีมาใช้กันหมด เลยกลายเป็นว่าไม่ได้ศึกษาเองมากกว่าถ้าจะพยายามตีความคำนั้น ก็คงพอเข้าใจได้ว่าเพราะ Agile เน้นทำให้เสร็จเร็ว เลยไม่ค่อยไปศึกษา low level อะไรทำนองนั้น แต่ผมว่าที่จริงแล้วคำอธิบายแบบ "ไม่จำเป็นเลยไม่ทำ" น่าจะตรงกว่านะ
ผมคิดว่า Agile กำลังละเลยการเลือกทางที่ทำให้เรามองปัญหาในภาพกว้างและทำให้สิ่งต่าง ๆ ยั่งยืนได้ในระยะยาว และในมุมของซอฟต์แวร์เองก็ทำให้เราโฟกัสแค่การแก้ปัญหาเฉพาะหน้าอยู่ตรงหน้าเท่านั้น
การทำให้มันพอใช้งานได้ไปก่อนแบบไม่คิดอะไรคงไม่ใช่ความเป็น Agile เสียทีเดียว แต่ก็ดูเหมือนว่าจะเกิดแนวโน้มของการตัดสินใจที่ให้น้ำหนักกับความเร็วมากเกินไป และผมคิดว่านั่นอาจเป็นปัจจัยที่ทำให้การแสวงหาความเข้าใจอย่างลึกซึ้งทำได้ยากขึ้นครับ
ผมไม่เข้าใจว่าทำไมถึงพยายามไปหาต้นตอของปัญหาที่องค์กรวิศวกรรมไม่มีอำนาจในการตัดสินใจจาก Agile
สถานการณ์ที่ไม่รู้ด้วยซ้ำว่าทีมอื่นกำลังทำอะไรอยู่ มันเกี่ยวอะไรกับ Agile กัน... ;;;
แต่ชื่อ Window Snyder นี่แปลกมากจริง ๆ นะ...
เหมือนอยากดูวิดีโอต้นฉบับ แต่ตอนนี้ยังไม่มีนะครับ/ค่ะ คิดว่าอีกไม่นานคงจะถูกอัปโหลดขึ้น YouTube ทางการ
https://www.youtube.com/@BlackHatOfficialYT/
ความคิดเห็นจาก Hacker News
โครงสร้างองค์กรสมัยใหม่คือรากของปัญหา
ไอเดียที่ดีของ Agile ถูกดูดซึมเข้าไปในวิศวกรรมซอฟต์แวร์ทั่วไป
ความไม่พอใจต่อ Agile, Scrum และ OKR
ประสบการณ์จากการประชุมจัดระเบียบ backlog
ทฤษฎีเกี่ยวกับปัญหาของ Agile
คุณภาพซอฟต์แวร์ที่แย่ลง
ควรให้นักวิศวกรได้ "เป็นเจ้าของ" โค้ดบางส่วน
ประสบการณ์การหลีกเลี่ยงการประชุม standup รายวัน
ปัญหาขององค์กรขนาดใหญ่
ความเห็นว่าต้องนำ "มนตร์เสน่ห์" ของการพัฒนาซอฟต์แวร์กลับคืนมา
> มีทฤษฎีการจัดการสมัยใหม่ที่มองว่าความรับผิดชอบและการตัดสินใจควรไล่ระดับขึ้นไปตามลำดับชั้นขององค์กร
นี่ไม่ใช่ลักษณะขององค์กรที่เป็นระบบราชการงั้นหรือ?