ไม่นานมานี้ผมเพิ่งจบโปรเจกต์กับลูกค้าที่สร้าง product ด้วยกันมานานเกือบสองปี มีหลายเรื่องที่อยากมาแชร์ให้ฟังครับ ระหว่างทางมีโอกาสได้ลองวิธีการทำงานหลายแบบ ทั้งแบบ Iterative ด้วย Scrum หรือแบบ Continuous ด้วย Kanban เพื่อปรับตัวเข้ากับ challenge ต่างๆ และ priority ที่ไม่แน่นอน รวมถึงทีมที่มีการเปลี่ยนแปลงตลอดเวลา
Scrum ถือว่าเป็นหนึ่งใน framework ที่นิยมที่สุดสำหรับ Agile และมักจะถูกใช้โดยหลายบริษัทที่อยากทำงานแบบ Agile ในช่วงแรกเริ่มของโปรเจกต์ เราเริ่มต้นได้ดีด้วย Scrum แต่พอโปรเจกต์เดินหน้าไปเรื่อยๆ ก็เริ่มพบปัญหาต่างๆ ที่ต้องปรับให้เหมาะกับสถานการณ์
องค์กรขนาดใหญ่มักมีกระบวนการต่างๆ เช่น การจัดการทรัพยากร ความปลอดภัย การปฏิบัติตามข้อกำหนด และกระบวนการทำงานหลายขั้นตอน ที่อาจทำให้รู้สึกน่าหงุดหงิด แต่ทั้งหมดนี้ก็มีเหตุผลของมันอยู่ เพื่อสร้างความมั่นคง ปกป้องข้อมูลสำคัญ และทำให้องค์กรสามารถทำงานได้อย่างมีประสิทธิภาพ
สำหรับทีม Agile ข้อจำกัดเหล่านี้บางครั้งอาจดูขัดแย้งกับหลักการสำคัญของความยืดหยุ่นและการส่งมอบงานอย่างรวดเร็ว ยกตัวอย่างเช่น:
เป็นธรรมดาที่เราจะรู้สึกขัดใจกับหลายๆ สิ่งที่มันอยู่เหนือการควบคุมของเรา แต่การเข้าใจว่า “ทำไม” ขั้นตอนหรือกฎเหล่านี้ถึงเกิดขึ้น จะช่วยปรับความคาดหวังให้ตรงกัน และหาวิธีทำงานให้มีประสิทธิภาพในระบบนั้นได้ ท้ายที่สุดแล้ว โครงสร้างเหล่านี้คือสิ่งที่ทำให้บริษัทเหล่านี้เติบโตและประสบความสำเร็จ พร้อมสร้างความมั่นคงและความเชื่อมั่นในระดับใหญ่ การบาลานซ์ระหว่างความคล่องตัวกับกระบวนการที่มีอยู่ไม่ใช่แค่เป็นไปได้ แต่เป็นสิ่งสำคัญสำหรับการทำงานพัฒนาในบริบทขององค์กร
เพื่อปรับตัวให้เข้าความท้าทายเหล่านี้ PALO IT ได้ปรับวิธีการทำงานของเราผ่าน 3 ช่วงหลักๆ โดยปรับเปลี่ยนโมเดลการทำงานให้ตอบโจทย์ความท้าทายต่าง ๆ รับฟัง feedback และตอบสนองต่อความต้องการในขณะนั้น
Phase 1 — เริ่มต้นด้วย Scrum
เราเริ่มโปรเจกต์ด้วยการทำงานแบบ Scrum ตามปกติ โดยใช้ sprint สองสัปดาห์ แต่ไม่กี่เดือนหลังเริ่มพัฒนา เราเจอปัญหาใหญ่ นั่นก็คือเราไม่สามารถดึงผู้ใช้งานจากฝั่ง business มาเข้าร่วมในกระบวนการพัฒนาได้ การขาดการมีส่วนร่วมนี้กลายเป็นต้นเหตุของ expectation ที่ไม่ตรงกัน และสุดท้ายเราจำเป็นต้องปรับวิธีการทำงานในช่วงถัดไป
แม้จะไม่ได้ลงลึกในรายละเอียดปัญหานี้ แต่ข้อคิดสำคัญคือ ความยืดหยุ่นเมื่อเจอความท้าทาย การปรับเปลี่ยนวิธีการทำงานเป็นสิ่งจำเป็น เพื่อให้ตอบโจทย์ความต้องการของโปรเจกต์และความคาดหวังของลูกค้าได้อย่างมีประสิทธิภาพ
Phase 2 — ลดช่องว่างด้วย sprint หนึ่งสัปดาห์
เมื่อเข้าสู่ช่วง User Acceptance Testing (UAT) ช่องว่างระหว่างความคาดหวังของผู้ใช้งานฝั่ง business และ product ที่เราพัฒนาก็เริ่มชัดเจน ช่องว่างเหล่านี้ที่มักถูกเรียกว่า “Bug” สะท้อนถึงความเข้าใจผิดที่สะสมมา เราจึงตัดสินใจให้ความสำคัญกับ feedback loops ที่รวดเร็วยิ่งขึ้น โดยปรับลด sprint ให้เหลือหนึ่งสัปดาห์
การเปลี่ยนแปลงนี้ช่วยให้ทีมสามารถโฟกัสทั้งการพัฒนา feature ใหม่และการแก้ไขปัญหาที่พบ ด้วยลำดับความสำคัญที่เปลี่ยนแปลงอย่างต่อเนื่องในช่วงนี้ ที่มาจาก feedback ของผู้ใช้และความต้องการที่เปลี่ยนไป ลูกค้าจึงพบว่าการวางแผนล่วงหน้าเกินกว่าหนึ่งสัปดาห์เป็นเรื่องยาก การใช้ sprint ที่สั้นลงช่วยให้เราปรับเป้าหมายได้เร็ว และส่งมอบงานเป็นขั้นตอนได้อย่างมีประสิทธิภาพมากขึ้น
Phase 3 — เตรียม Release ด้วย Kanban
เมื่อใกล้ถึงช่วงปล่อย product ให้ผู้ใช้งานจริง ลักษณะของงานก็เปลี่ยนไปอีกครั้ง ขั้นตอนสำหรับการ release เช่นการทดสอบความปลอดภัย การทดสอบเจาะระบบ และการอนุมัติหลายขั้นตอน ทำให้เกิดงานเฉพาะหน้าจำนวนมากที่ต้องได้รับการจัดการทันที นอกจากนี้ ทีมยังต้องทำ feature เล็กๆ ไปพร้อมกันด้วย
เพื่อจัดการกับงานที่ทั้งวางแผนไว้ล่วงหน้าและเกิดขึ้นเฉพาะหน้า เราเปลี่ยนมาใช้ Kanban เพื่อที่จะยกเลิกข้อจำกัดของ sprint ที่มีกรอบเวลา การเปลี่ยนแปลงนี้ช่วยให้ทีมสามารถโฟกัสที่การทำงานให้เสร็จลุล่วงตามความต้องการที่เกิดขึ้น ช่วยให้กระบวนการปล่อยงานราบรื่นยิ่งขึ้น ในขณะที่ยังสนับสนุนความต้องการสำคัญของโปรเจกต์ได้อย่างเต็มที่
หลังจากผ่านทั้งสามช่วงของโปรเจกต์ เราได้เรียนรู้ว่า การเลือกระหว่างการพัฒนาแบบ Iterative และ Continuous Flow ขึ้นอยู่กับลักษณะของโปรเจกต์นั้นๆ ในช่วงแรก sprint ของ Scrum นั้นเหมาะกับการทำงานของเรา เนื่องจากมีโครงสร้างชัดเจนและมี milestone ให้ติดตาม แต่เมื่อเจอความท้าทายใหม่ๆ เราต้องการความยืดหยุ่นมากขึ้น Continuous Flow development จึงเหมาะสมกว่าในช่วงที่เราต้องปรับตัวเข้ากับลำดับความสำคัญที่เปลี่ยนแปลงและข้อจำกัดจากภายนอก
ข้อดีของ Iterative Development
การพัฒนาแบบ Iterative เหมาะสำหรับโปรเจกต์ที่ได้ประโยชน์จากการมี checkpoint เป็นระยะ ๆ และความรู้สึกของการทำงานที่เสร็จเป็นรอบๆ
เมื่อไหร่ที่ควรใช้ Continuous Flow Development
สุดท้ายแล้ว ข้อคิดสำคัญคือ Agile เป็น mindset ที่ยืดหยุ่น ไม่ใช่กรอบการทำงานที่ตายตัว ตลอดสามช่วงของโปรเจกต์ เราได้เรียนรู้ว่า การปรับ Agile ให้เหมาะกับความต้องการของโปรเจกต์ รวมถึงข้อจำกัดในองค์กรขนาดใหญ่ไม่ใช่แค่เรื่องจำเป็น แต่เป็นกุญแจสำคัญของความสำเร็จ ไม่ว่าจะเป็นการพัฒนาแบบ Iterative หรือ Continuous Flow ความสามารถในการปรับเปลี่ยนและพัฒนาวิธีการทำงานตามความต้องการของโปรเจกต์ คือสิ่งที่ช่วยให้เราทำงานได้อย่างมีประสิทธิภาพที่สุด
พร้อมที่จะมาร่วมประสบการณ์การทำงานแบบ Agile กับเราหรือยัง?
หากองค์ของคุณต้องการที่จะเริ่ม หรือรู้สึกว่ายังปรับใช้การทำงานแบบ Agile ได้ไม่ค่อยมีประสิทธิภาพ สามารถมาปรึกษากับทาง PALO IT ได้ครับ เรามีผู้เชี่ยวชาญด้าน Agile ที่ได้รับ ICAglie Certified Professional พร้อมที่จะช่วยสร้างกระบวนการพัฒนาที่มีความยืดหยุ่น และมีประสิทธิภาพมากขึ้นได้ครับ