- การเขียนโปรแกรมในปัจจุบันมีความเครียดมากกว่ายุค 90 และช่วงต้นทศวรรษ 2000 อย่างมาก
- ในตอนนั้น งานจะหนักบ้าคลั่งเฉพาะช่วงใกล้เดดไลน์เท่านั้น และช่วงเวลาอื่นก็ถือว่าค่อนข้างสงบ
- ผู้เขียนได้ลองคิดทบทวนว่าทำไมความเครียดจึงเพิ่มขึ้นในช่วงหลายทศวรรษที่ผ่านมา
- สาเหตุไม่ใช่การแข่งขัน การเปลี่ยนแปลงของตลาด หรือเดดไลน์ที่เข้มงวด แต่เป็นการทำงานแบบสปรินต์
1. สปรินต์ไม่เคยหยุด
- สปรินต์คือเดดไลน์ต่อเนื่องที่ไม่สิ้นสุด
- วิธีแบบ Waterfall เคยสอดคล้องกับเดดไลน์และเหตุการณ์จริง
- สปรินต์เป็นเดดไลน์ที่ถูกสร้างขึ้นมา จึงไม่มีช่วงพักตามธรรมชาติ
- ความเครียดระยะสั้นอาจดีต่อสุขภาพได้ แต่ความเครียดระยะยาวเป็นอันตรายต่อร่างกาย
2. สปรินต์ไม่ใช่สิ่งที่ทำโดยสมัครใจ
- มันต่างจากกรณีที่ทีมเลือกปล่อยโค้ดทุก 2 สัปดาห์ด้วยความสมัครใจ
- ทุกแง่มุมของสปรินต์ถูกกำหนดไว้หมดแล้ว
- ความเป็นอิสระมีบทบาทสำคัญต่อประสบการณ์ในการทำงาน
- การทำงานที่ถูกบังคับก่อให้เกิดความเครียดและความอึดอัด
3. สปรินต์มองข้ามกิจกรรมสนับสนุนที่สำคัญ
- สปรินต์ไม่ได้ให้เวลาสำหรับการเตรียมงานถัดไป
- การทำงานให้สำเร็จต้องอาศัยเวลาในการเตรียมการ
- สปรินต์พยายามแยกการเตรียมงานออกจากการลงมือทำ แต่สิ่งนี้ทำให้เกิดความเครียด
Scrumfall: ภาพจริงที่เกิดขึ้นบ่อยกว่า (และแย่กว่า)
- การนำ Scrum ไปใช้ส่วนใหญ่เป็นการผสมกันระหว่าง Waterfall กับ Scrum
- เดดไลน์ใหญ่ยังคงมีอยู่เบื้องหลังเสมอ
- เมื่อเดดไลน์ใหญ่ใกล้เข้ามา Scrum จะหยุดชะงัก และความเครียดจะเพิ่มขึ้น
บทสรุป
- สปรินต์ไม่มีช่วงพัก ขาดความเป็นอิสระ และมีเวลาเตรียมงานไม่เพียงพอ
- นักพัฒนาควรสามารถควบคุมงานและกระบวนการทำงานของตนเองได้
- เพื่อให้เกิดสิ่งนี้ อาจต้องสร้างองค์กรที่มีจริยธรรมหรือเปลี่ยนไปทำงานแบบฟรีแลนซ์
สรุปโดย GN⁺
- บทความนี้อธิบายว่าทำไมวิธีทำงานแบบ Scrum จึงสร้างความเครียดอย่างต่อเนื่องให้กับนักพัฒนา
- เดดไลน์ที่ต่อเนื่องของสปรินต์ การขาดความเป็นอิสระ และเวลาเตรียมงานที่ไม่พอ คือสาเหตุหลัก
- ควรเปิดโอกาสให้นักพัฒนาควบคุมวิธีการทำงานของตนเองได้
- โครงการอื่นที่มีลักษณะคล้ายกันคือแนวทางแบบ Kanban
8 ความคิดเห็น
แม้แต่ตอนทำโปรเจกต์อย่าง SI หรือภาครัฐ ก็ยังถูกเร่งแบบไม่หยุดเป็น phase 1, 2, 3.. ไปเรื่อย ๆ และในแต่ละ phase ก็ยังมีการเปลี่ยนแปลงเกิดขึ้นอย่างมหาศาลอีก แบบนี้ไม่มีทางบรรลุเป้าหมายแท้จริงของ scrum ที่ต้องการพัฒนาให้สำเร็จได้เลย สุดท้ายท่ามกลางความโกลาหลและบรรยากาศที่วุ่นวายไร้ระเบียบนี้ ก็มีแต่นักพัฒนาเท่านั้นที่ถูกเผาผลาญจนหมดแรง
ผมทำงานเป็น PM อยู่ครับ
ใน Agile/Scrum ที่ผมรู้สึกว่ามันเวิร์กจริง ๆ เมื่อสปรินต์หลักจบลง จะมีการรีโทรสเปกทีฟและมีเวลาให้พัก ทั้งทีมพัฒนาและทีมวางแผนต่างก็มีจังหวะให้ได้พักก่อนเตรียมงานถัดไป
ส่วนในรูปแบบที่ผมรู้สึกว่ามันไม่ได้ทำงานแบบเดียวกับในบทความ ภายใต้เดดไลน์ที่ไหลลงมาแบบ Waterfall ภายในทีมโปรดักต์ก็ยังพยายามเดิน Scrum ไปพร้อมกัน ทำให้ความเครียดทับถมมากขึ้น และเพราะตัวเดดไลน์เองก็ขยับไม่ได้ เลยต้องวิ่งกันทุกสัปดาห์โดยไม่มีเวลาพักหรือรีโทรสเปกทีฟ ให้ความรู้สึกเหมือนเป็นการวิ่งที่ไม่มีวันจบ
ผมเข้าใจว่าเจตนาของ waterfall คือการระบุความต้องการให้ได้มากที่สุดตั้งแต่ต้น และเพราะงานออกแบบ-พัฒนา-ทดสอบมีการพึ่งพากัน จึงควรทำงานตามลำดับ ส่วนเจตนาของ agile และ sprint คือการนำงานที่มีขนาดใหญ่เกินกว่าจะออกแบบหรือพัฒนาล่วงหน้าแบบ waterfall มาแบ่งเป็นชิ้นเล็ก ๆ แล้วค่อยลองทำดู ทั้งสองแบบต่างก็มีข้อดีข้อเสีย และแทนที่จะยึดติดกับวิธีการแบบเคร่งครัด ก็น่าจะเลือกใช้เฉพาะสิ่งที่จำเป็นให้เหมาะกับสถานการณ์ก็พอ ตามที่บทความกล่าวไว้ ก็ควรมีเวลาพัก รวมถึงมีเวลาเตรียมตัวสำหรับการทบทวนทางเทคนิคหรือการทำ prototype ด้วย
ไม่ว่าใครจะเป็นคนกำหนดลำดับของงาน ถ้าเข้าใจปัจจัยรบกวนและจัดลำดับความสำคัญตามลำดับการทำงานจริง ผมก็รู้สึกว่าการมีหรือไม่มีอิสระของนักพัฒนาจะสำคัญมากขนาดนั้นหรือไม่
หรือว่าคนที่ไม่มีประสบการณ์พัฒนาเลย แต่พยายามนำขั้นตอนของวิธีการพัฒนามาใช้แบบไม่ลืมหูลืมตา ก่อให้เกิดผู้จัดการแบบนี้ขึ้นมากในต่างประเทศ จนมีบทความลักษณะนี้ออกมาตามบล็อกต่างประเทศ? มันชวนให้นึกถึงความขัดแย้งระหว่างนักวางแผนกับนักพัฒนาที่ไม่เข้าใจงานภาคปฏิบัติจริงในบ้านเราเลย
เมื่อพิจารณาตามลำดับงานจริง คนที่น่าจะตัดสินใจเรื่องลำดับความสำคัญได้ดีที่สุดก็คือตัวนักพัฒนาเองอยู่แล้วครับ/ค่ะ ดังนั้นผม/ฉันคิดว่าแนวทางที่พรากความเป็นอิสระนั้นไป แล้วให้คนอื่นมาทำแทน กลับเป็นสาเหตุที่ทำให้งานภาคปฏิบัติกับการวางแผนของทีมแยกขาดจากกันเสียมากกว่า
ถ้ามองว่าการบริหารจัดการเองก็เป็นความเชี่ยวชาญอย่างหนึ่ง ต่อให้เป็นผู้จัดการที่ไม่มีประสบการณ์ด้านการพัฒนา เมื่อถึงจุดที่พบว่าการบริหารทรัพยากรฝั่งพัฒนาเริ่มทำได้ไม่ดี คำตอบของสถานการณ์นั้นก็ควรเป็นให้ผู้จัดการปรับตัวหรือรับมือเอง แต่ผม/ฉันเห็นบ่อยมากว่า ความรับผิดชอบนี้กลับถูกผลักไปให้ผู้มีส่วนร่วมรายบุคคล...
ความรับผิดชอบสุดท้ายของคุณ ผู้จัดการควรเป็นคนรับไว้สิครับ แต่ดูเหมือนว่าในความเป็นจริงจะไม่เป็นแบบนั้น เหมือนกับ CEO ที่ทำเป็นแค่บริหาร แต่ไม่เข้าใจธุรกิจของบริษัทเลย และสุดท้ายก็มักพาบริษัทพังนั่นแหละ
PM ที่เอาแต่โยนงานไปมาเยอะมากเลย ฮือๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆ
ความคิดเห็นจาก Hacker News
อ้างคำพูดของ Rich Hickey ว่าโปรแกรมเมอร์แก้ปัญหาไม่เหมือนนักวิ่งระยะสั้น แต่กลับถูกบังคับให้เริ่มสปรินต์ใหม่ด้วยการยิงสัญญาณออกตัวทุก ๆ 100 หลา
เริ่มไม่ชอบกระบวนการซอฟต์แวร์แล้ว หากกำหนดขนาดทีมให้เหมาะสมและให้อำนาจนักพัฒนาในการบรรลุเป้าหมาย พวกเขาก็ทำงานได้ดีโดยไม่ต้องมีสายพานการจัดการเรื่องผลิตภาพ Agile และสิ่งคล้ายกันมีไว้เพื่อให้ผู้จัดการใช้สร้างความชอบธรรมให้เงินเดือนของตัวเอง
สงสัยว่าคำว่า "สปรินต์ไม่ใช่ความสมัครใจ" หมายถึงอะไร ทีมเป็นผู้เลือกคุณลักษณะของสปรินต์เอง ไม่ได้ถูกสุ่มกำหนด เป็นความร่วมมือระหว่างผู้นำ สมาชิกทีม และผู้มีส่วนได้ส่วนเสียนอกทีม อยากให้ช่วยอธิบายว่าทำไม Scrum ถึงแข็งทื่อเกินไป
ตั้งแต่ Scrum ออกมาใหม่ ๆ ก็คิดแล้วว่าการให้ผู้พัฒนาทำสปรินต์ต่อเนื่องตลอดเวลาเป็นเรื่องไม่สมเหตุสมผล สปรินต์ควรสั้นและเร็ว แล้วหลังจากนั้นต้องมีเวลาพัก การทำให้งานทุกอย่างกลายเป็นสปรินต์เป็นเรื่องบ้าชัด ๆ
บ่อยครั้ง Scrum ในโลกจริงกลับกลายเป็น "Scrumfall" ที่แย่กว่า เดิมทีใช้ Scrum เพื่อการสื่อสารในทีมรีโมต แต่ค่อย ๆ กลายเป็นเป้าหมายที่การตลาดเป็นคนนำและสปรินต์ที่กดดันสูง ภาวะหมดไฟของนักพัฒนาเห็นได้ชัดเจน
ช่วงต้นยุค 2000 ทีมวิศวกรเคยทำงานกันเองโดยไม่มีผู้จัดการโครงการ ซอฟต์แวร์ในตอนนั้นไม่ได้เชื่อมโยงถึงกันมากเหมือนทุกวันนี้ และรอบการดีพลอยก็ยาวกว่า ปัจจุบัน CI/CD และการดีพลอยต่อเนื่องทำให้ทุกอย่างเดินเร็วมาก SCRUM ทำให้เกิดความเครียด
บทสนทนาส่วนใหญ่สรุปได้ว่าเป็น "ที่ทำงานฉัน Scrum แย่เพราะ X, Y, Z" กับ "นั่นไม่ใช่ Scrum ในอุดมคติ"
พัฒนาซอฟต์แวร์มา 40 ปีแล้ว และไม่ว่าจะใช้วิธีไหนก็ต้องแบ่งงานและแสดงให้เห็นว่าบรรลุเป้าหมายได้ สำหรับทีมเล็กที่มีโค้ดเบสเรียบง่าย Kanban อาจเพียงพอ แต่สำหรับทีมใหญ่หรือโซลูชันที่ซับซ้อนก็จำเป็นต้องมีการรายงาน
ไม่ใช้ Agile, Scrum, Standups และสิ่งเหล่านี้ ประชุมสัปดาห์ละครั้งเพื่อจัดลำดับความสำคัญใหม่ และติดตามความคืบหน้าด้วยระบบตั๋วงาน เปิดโอกาสให้นักพัฒนาทำงานได้อย่างอิสระ ควรใช้เวลากับการเขียนโค้ดมากกว่าการประชุมหรือรายงาน TPS
จากการทำงานมา 8 บริษัท พบว่าแนวทาง Shape Up ของ Basecamp ประสบความสำเร็จมากที่สุด สิ่งสำคัญคือการถามว่า "จะทุ่มเวลาไปเท่าไร" ไม่ใช่ "ต้องใช้เวลากี่วัน" Shape Up มีช่วงคูลดาวน์ระหว่างรอบ 6 สัปดาห์ และส่งมอบผลิตภัณฑ์ที่ประสบความสำเร็จได้อย่างสม่ำเสมอ