"Mini waterfall" เป็นหนึ่งในอาการที่อาจเกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์แบบ Scrum ซึ่งเป็นการใช้ Scrum ในลักษณะที่ไม่ถูกต้อง หรือ ไม่ตรงกับหลักการของ Scrum และทำให้เกิดสร้างสภาพแวดล้อมที่คล้ายกับวิธีการพัฒนาแบบ Waterfall
โดยทั่วไปแล้ว Mini waterfall มักเกิดขึ้นจากทีมหรือองค์กรที่เคยทำงานแบบ Waterfall มาก่อน และนำกระบวนการ Waterfall มาใช้ต่อในการทำงานแบบ Scrum
สัญญาณที่บ่งชี้ถึง "Mini waterfall" ใน Scrum:
- การแบ่ง Phase การทำงาน: ยังมีการทำงานเป็นลำดับขั้น โดยมีการส่งต่องานเป็น Phase ไป จาก Design -> Development -> Testing ซึ่งการทำแบบนี้ไม่ต่างอะไรกับการทำงานเป็น Waterfall
- แยกกันทำงาน: การทำงานแต่ละ PBI จะแบ่งหน้าที่การทำงานกันอย่างชัดเจน เช่น Front-end หรือ Back-end โดยมีการหยิบงานที่อยู่ใน Sprint Blacklog ไปทำโดยไม่มีการจัดเรียงลำดับความสำคัญ และไม่สอดคล้องกันระหว่าง Front-end และ Back-end
- ขาดการตั้งเป้าหมายร่วม: ทีมจะรู้ว่า Sprint นี้ทำอะไร แต่เมื่อลงมือพัฒนาก็จะแยกกันทำงานของใครของมัน ทำให้เกิดการทำงานที่ยังไม่จำเป็นต้องใช้งานในวันนั้นๆ
- การแบ่งงานที่มากขึ้นหรือการกำหนดระยะเวลาที่ยาว: หากทีมพยายามทำ Sprint Planning ที่มีระยะเวลาที่ยาวเกินไปหรือกำหนดงานใน Sprint Backlog ที่มากเกินไปโดยที่ไม่ได้พิจารณาความสามารถและความจำเป็นจริงของระยะเวลาที่กำหนด อาจทำให้มีลักษณะของ Waterfall ที่มีการวางแผนล่วงหน้ามากเกินไป
- ขาดการสื่อสารและความร่วมมือระหว่างทีม: หากมีขาดการสื่อสารหรือความร่วมมือระหว่างสมาชิกในทีมหรือระหว่างทีมและ PO อาจทำให้ข้อมูลที่สำคัญไม่ถูกแชร์หรือไม่ถูกส่งต่อในทันที ซึ่งทำให้ทีมไม่สามารถปรับตัวได้อย่างรวดเร็ว
- การทำ Sprint Review หรือ Sprint Retrospective ที่ไม่มีการปรับปรุง: หากทีมไม่ได้ใช้เวลาในการทำ Sprint Review หรือ Sprint Retrospective เพื่อทำการปรับปรุงกระบวนการทำงานของตนเอง และยังคงทำตามแบบแผนเดิมๆ โดยไม่ทำการปรับปรุงตามข้อเสนอแนะ อาจแสดงถึงการทำงานแบบ "Mini waterfall" ที่ไม่คำนึงถึงการปรับปรุงตลอดเวลา
- ขาดความยืดหยุ่นในขั้นตอนการพัฒนา: ถ้าทีมไม่มีความยืดหยุ่นในการทำ Sprint หรือไม่สามารถปรับตัวตามความเปลี่ยนแปลงที่เกิดขึ้นได้ นั่นอาจทำให้มีลักษณะของ Waterfall ที่มีขั้นตอนแน่นอนและไม่ยืดหยุ่น
รูปแบบของ Mini Waterfall
จากที่พบเจอรูปแบบกการทำงานแบบ mini waterfall จะมีอยู่ 2 รูปแบบ คือ
Mini Waterfall - Testing at the end of the iteration - เอาการทดสอบไว้ในช่วงท้าย Sprint
ในสถานการณ์นี้ กิจกรรมการทดสอบจะถูกแยกออกจากการกระบวนพัฒนาและเลื่อนออกไปจนกว่าจะถึงขั้นตอนหลังสุดของ Iteration หรือ Sprint แทนที่จะเป็นส่วนหนึ่งของกระบวนการพัฒนาทั้งหมด
ซึ่งแนวทางนี้ ไม่ตรงกับหลักการของ Scrum ซึ่งเน้นการพัฒนาแบบ "Iterative development with continuous testing" ซึ่งจะส่งผลให้เกิด
- เพิ่มความเสี่ยงในการจังหวะ Integration: ยิ่งมีการเลื่อนการทดสอบไปจนถึงช่วงท้ายของ Sprint จะยิ่งมีความเสี่ยงที่สูงขึ้นเกี่ยวกับปัญหาการ Integration ถ้าส่วนต่าง ๆ ที่พัฒนาแยกกันไม่ได้ทดสอบตลอดเวลา และมีโอกาสที่จะพบปัญหาเกี่ยวกับความเข้ากันได้ในระหว่างขั้นตอนพัฒนาสูงขึ้น
- ความไม่ยืดหยุ่น: การทำงานแบบ Agile หรือ แม้กระทั่งใน Scrum จะให้ความสำคัญกับความยืดหยุ่นในการปรับตัวตามความเปลี่ยนแปลงของความต้องการ แต่เมื่อการทดสอบถูกเลื่อนไปจนถึงท้ายของ Sprint การกลับไปปรับเปลี่ยนอาจเป็นเรื่องที่ยากเนื่องจากมันอาจทำให้กระทบกับระยะเวลาการทดสอบ.
- การให้ Feedback ล่าช้า: ในกรณีของ Mini Waterfall, การทดสอบถูกเลื่อนไปจนถึงท้ายของ Sprint, ซึ่งหมายความว่า Feedback ที่จะได้จะล่าช้า ความล่าช้านี้ทำให้เกิดข้อผิดพลาดที่เยอะ และเป็นเรื่องยากและเสียเวลาในการแก้ไขมัน
- รอบ Feedback ยาว: เมื่อการทดสอบถูกเลื่อนไปจนถึงท้ายของ Sprint รอบ Feedback จะยาวขึ้น ทำให้มันยากที่จะระบุและแก้ไขปัญหาได้อย่างรวดเร็ว
Mini Waterfall - Testing in the next iteration - เอาทดสอบใน Sprint ถัดไป
กระบวนการทำงานแบบนี้จะเอาการงานจาก Sprint นี้ ไปทดสอบใน Sprint ถัดไป และในช่วงท้ายๆ ของโปรเจคจะมี Sprint ที่มีไว้เพื่อทดสอบและแก้บั๊คโดยเฉพาะ
AKA - Dev 1 Sprint, Test 1 Sprint
ซึ่งจะส่งผลให้เกิดอาการแบบเดียวกับ Mini waterfall แบบแรก แต่อาการหนักกว่า แถมเจอปัญหาเพิ่มเติมอีกด้วย เช่น
- โค๊ดที่ยังไม่ถูกทดสอบ: เมื่อจบการทำงานให้ Sprint และต้องทำงานใน Sprint ถัดไป ทีมพัฒนาจะนำเอาโค๊ดเดิมจาก Sprint ก่อนหน้าไปทำงานต่อ ซึ่งเป็นโค๊ดที่ยังไม่ผ่านการทดสอบ มันจะส่งผลให้เกิดบั๊กเพิ่มมากขึ้นกว่าเดิม และความซับซ้อนให้การทำงานก็จะเพิ่มขึ้นตามไปด้วย
- การร่วมมือที่ลดลง: ใน Scrum จะมีแค่ PO และ Development Team ซึ่ง Development Team คือ กลุ่มคนที่ทำงานร่วมกันตลอดกระบวนการพัฒนา แต่เมื่อทดสอบถูกเลื่อนไปเป็นอีก Sprint มีความเสี่ยงที่จะเกิดการร่วมมือที่ลดลงระหว่างบทบาทเหล่านี้ เพราะ Tester จะถูกผลักให้ไปทำงาน Sprint ก่อนหน้า แค่เคียงคนเดียวให้ขณะที่คนอื่นๆ ใน Development Team ทำงานใน Sprint ปัจจุบันอยู่
- มีผลกระทบกับงานใน Sprint: เป็นที่แน่นอนว่า เมื่อไม่ได้ทดสอบใน Sprint มีโอกาศสูงมาก (100%) ที่ทีมจะถูกขัดจังหวะและถูกดึงออกจากงานใน Sprint ปัจจุบันที่ทำอยู่ เพื่อมาแก้ไขงานใน Sprint ก่อนหน้า ส่งผลให้งานใน Sprint ปัจจุบันไม่สำเร็จตามเป้าที่วางไว้
- ใช้เวลานานขึ้น: การทำงานแบบนี้หากเจอ Bug การแก้ Bug จะถูกเอาไปทำใน Sprint นั้นเลย หรือ อาจจะเก็บไว้ไปแก้ใน Sprint ถัดไป ซึ่งหมายความว่า เราใช้เวลาพัฒนาและทดสอบรวมกันไม่แต่กว่า 3 Sprint ถึงจะเสร็จพร้อมขึ้น Production
- ยากต่อการเปลี่ยนแปลง: ยิ่งรอบของการพัฒนาและการได้รับ Feedback นาน ยิ่งยากต่อการแก้ไขเปลี่ยนแปลง เพราะจะมีผลกระทบกับงานก่อนหน้าที่รอทดสอบหรือยังแก้ไขไม่เรียบร้อย
- เพิ่มภาระงานในการทดสอบ: การทำงานแบบนี้ ยิ่งเพิ่มภาระงานให้แก่ QA Tester มากขึ้นกว่าเพิ่ม เนื่องจากการนำงานที่ยังไม่ได้ถูกทดสอบมาทำต่อ โดยไม่รอให้งานเสร็จเรียบร้อยก่อน เมื่อผ่านไปหลายๆ Sprint จะพบว่าปริมาณงานที่ต้องทดสอบจะสะสมเพิ่มมากขึ้น และอาจจะพบว่ามี Bug/Defect บางอย่างโผล่มาได้ ทั้งที่ทดสอบไปแล้วและยังไม่ได้ทดสอบ
- รอบ Feedback โคตรรรรรรยาววววว: เมื่อการทดสอบถูกเลื่อนไปจนถึงท้ายของ Sprint รอบ Feedback จะยาวขึ้นเหมือนกันกับ Mini Waterfall แบบแรก แต่แบบนี้จะยาวกว่ามากแทบจะเพิ่มขึ้นเป็นเท่าตัว ซึ่งการได้ Feedback ที่ช้า ก็จะยิ่งยากที่จะระบุและแก้ไขปัญหาได้อย่างรวดเร็ว
วิธีแก้ Mini Waterfall เบื้องต้น
ก่อนที่จะแนะนำวิธีการแก้ไขอาการ Mini Waterfall ที่เกิดขึ้น ขอทำความเข้าใจคำว่า "งานเสร็จ" กันก่อน
นิยามของ คำว่า "งานเสร็จ"
ในที่นี้ หมายถึง "งานที่ผ่านการทดสอบและสามารถใช้งานได้จริงบน Production หรือ เทียบเท่า Production"
เพราะฉนั้น จากอาการข้างต้นจะเห็นได้ว่างานที่ไม่เสร็จของทีมเป็นเพราะการทดสอบอยู่ในช่วงท้ายของ Sprint หรืออยู่ใน Sprint ถัดไป ทำให้เมื่อพบเจอ Bug ก็จะไม่สามารถแก้ให้จบใน Sprint นั้นๆ ได้
เขียนและทดสอบทั้งวัน
การเขียนโค๊ดและทดสอบเลย จะช่วยลดข้อผิดพลาดจากการทำงานของโค๊ดที่เขียนไปได้ และทำให้ไม่จำเป็นต้องรอทดสอบในตอนท้ายของ Sprint หรือยกไปใน Sprint ถัดไป การทดสอบที่กล่าวถึง คือ การทดสอบด้วยชุดการทดสอบที่ QA Tester เป็นคนออกแบบ Test Case ไว้ให้ นั่นหมายความว่า QA Tester จะต้องมีการเตรียมการทดสอบบางส่วนให้เรียบร้อยก่อนจะเข้า Sprint
โฟกัสไปที่การทดสอบของทั้งทีม
มุ่งเน้นให้ทีสนใจเรื่องของการทดสอบ โดยจะโกฟัสไปที่การป้องกันการเกิดข้อผิดพลาด แทนการหาข้อผิดพลาด อย่างที่เคยทำกัน เพราะเฉพาะทีมจะต้องช่วยกันพูดคุย ช่วยหาจุดที่มีโอกาศเกิดข้อผิดพลาด แล้วทำการปิดจุดนั้นก่อนเริ่มการเขียนโค๊ด
จำกัดการหยิบงานมาทำ
พยายามจำกัดการหยิบงานมาทำของคนในทีมให้ทำงานทีละชิ้น โดยทำชิ้นใดชิ้นหนึ่งให้เรียบร้อยก่อนที่จะหยิบงานชิ้นใหม่มาทำ เช่น ถ้างานที่ทำอยู่ยังไม่ถูกทำการทดสอบ อย่าพึ่งกระโดดไปทำงานชิ้นใหม่ จะช่วยให้มีโฟกัสไปที่การทำงานให้เสร็จเป็นชิ้นๆ ไป
ขนาดของ Story ไม่ใหญ่เกินไป
พยายามเลือก Story ที่ไม่ขนาดไม่ใหญ่เกินไป ทีมสามารถทำเสร็จได้ภายใน 2-3 วัน สำหรับรอบการทำงาน 10 วัน ต่อ Sprint
Story จะเสร็จ เมื่อทดสอบเรียบร้อยแล้ว
ปัญหาหนึ่งของการทำงานแบบ Mini waterfall คือ จะมีงานแก้ bug จาก sprint ก่อนหน้า ทำให้แทนที่เราจะหยิบงานมาทำแค่ 1 sprint มันจะถูกลากยาวไป sprint อื่นๆ ด้วย เพราะฉนั้น เมื่อเราหยิบ Story ไหนเข้ามาทำ เราต้องทำการทดสอบให้เสร็จพร้อมใช้งานก่อน ถึงจะบอกว่างานนั้นเสร็จแล้วจริงๆ
Under Commit
การหยิบงานเข้ามาใน Sprint เท่าที่ทีทีมทำไหว อย่าพยายามยัดงานเข้ามาเพื่อให้มีงานเต็ม Sprint ซึ่งในข้อนี้ทีมจะต้องมีการเก็บสถิติการทำงานของทีมไว้ด้วยว่าสามารถรับงานได้มากน้อยแค่ไหน