พัฒนา Software Product อย่างไรให้ได้ Feedback รวดเร็ว
หลังจากจบ Class LeSS in Action ของ Terry ที่ได้เรียนมา 5 วันเต็ม ช่วงนี้ผมก็กำลังพยายาม Reflect สิ่งสำคัญต่าง ๆ ที่ได้เรียนรู้มาอย่างมากมายจากคลาสนี้ และพยายามจะกลั่นออกมาเป็นบทความเพื่อที่จะได้เก็บไว้ย้อนอ่าน และแชร์ความรู้ให้กับทุกคน เผื่อว่าจะเป็นประโยชน์ไม่มากก็น้อย
โดยบทความนี้จะเล่าถึงแนวคิดต่าง ๆ ของโลกการพัฒนา Software ที่มีอยู่ ว่าสามารถนำมา Apply กับการทำงานของเราได้อย่างไรบ้าง เพื่อให้การพัฒนา Software นั้นได้ประสิทธิภาพและสามารถนำไปรับ Feedback ได้อย่างเร็วที่สุด
การที่เราจะรู้ให้ได้เร็วที่สุดว่า Product ที่เราพัฒนาอยู่นั้นมันถูกต้อง มีประโยชน์ และสอดคล้องกับความต้องการของ User มากแค่ไหน นั่นก็คือ Feedback จาก User นั่นเอง
เพราะฉะนั้น สิ่งที่ทีมพัฒนาจะต้องโฟกัสและให้ความสำคัญมากที่สุดนั่นคือการนำสิ่งที่กำลังพัฒนาอยู่นั้นทยอยออกไปรับ Feedback แล้วนำกลับมาปรับให้เร็วที่สุด
แล้วทำยังไงถึงจะได้ Feedback เร็ว ๆ ล่ะ?
ย้อนกลับไปในช่วงที่เราใช้โมเดล Waterfall การที่จะรับ Feedback จาก User ได้นั้นมักใช้เวลานานมาก เนื่องจากในการพัฒนา Software อาจใช้เวลาหลายปี กว่าจะรู้ว่าผลลัพธ์ที่ได้ไม่ตรงตามความต้องการของ User บางครั้งก็อาจสายเกินไปที่จะแก้ไขปัญหานั้น อย่างไรก็ตาม การใช้ Waterfall ก็ไม่ได้เลวร้ายเสียทุกอย่าง ถ้าหากเรากำลังพัฒนา Software ที่เป็น Mass Product (ของที่ไม่ได้มีความซับซ้อนและเป็นของที่มีฟีเจอร์การใช้งานทั่วไป) ก็อาจไม่ต้องให้ความสำคัญกับ Feedback ของผู้ใช้งานมากนัก เพราะข้อกำหนดมักจะชัดเจนตั้งแต่ต้นก่อนเริ่มพัฒนาอยู่แล้ว
แต่โลกสมัยนี้ทุกอย่างรอบตัวเปลี่ยนแปลงกันรวดเร็วเหลือเกิน ความต้องการของผู้บริโภคที่เปลี่ยนไปอยู่ตลอด ธุรกิจที่ต้องปรับตัวและเปลี่ยนแปลงตลอดเวลา ถ้าเรายังคงเชื่องช้า ก็คงจะตามคู่แข่งเขาไม่ทัน
ต่อมาพอผมได้เข้ามาในโลกของ Scrum ตอนที่ผมเริ่มมีการได้รับ Feedback จากผู้ใช้งานเป็น Sprint ผมก็คิดว่าสิ่งนี้ก็เป็นอะไรที่ค่อนข้างเร็วมากแล้วสำหรับการพัฒนา Product ที่เราจะได้รับ Feedback จากผู้ใช้งานและมาปรับปรุงพัฒนาต่อ
และใน Class นี้ Terry ยิ่งทำให้ผมได้เห็นเข้าไปอีกว่าเราไม่จำเป็นต้องรอ Feedback แค่ตอน Sprint Review เลยด้วยซ้ำ เราสามารถรับ Feedback ได้ตลอดเวลา แม้กระทั่งในตอนที่เรากำลังเขียนโค้ดอยู่ก็ตาม
เราลองมาดูกันว่าสามารถทำให้เกิดสิ่งนี้ในการทำงานได้อย่างไร
เริ่มตั้งแต่จังหวะที่เราทำ Product Backlog Refinement ในขั้นตอนของ Detailing เราสามารถใช้ SBE (Specification by Examples) ในการเขียนข้อกำหนดและแนวทางการทดสอบ โดยให้ตัวอย่างที่ชัดเจน เพื่อให้ทั้งผู้ให้และผู้เก็บ Requirement เข้าใจตรงกัน โดยหลักการคือการสร้างตัวอย่างและให้ Product Owner ยืนยันเพื่อความถูกต้อง เพื่อให้ทีมพัฒนาทั้งหมดเข้าใจตรงกัน
หลังจากที่เรานำ PBI (Product Backlog Item) เข้ามาใน Sprint และแบ่ง PBI นี้ออกเป็น 3 Task ย่อยเป็น Scenario ได้แก่
- Scenario 1
- Scenario 2
- Scenario 3
โดยแต่ละ Scenario จะมีองค์ประกอบงานหลัก ๆ ที่ต้องทำคือ
- E2E Testing (Feature File)
- Front-end
- Back-end
จากภาพนี้เราลองมาดูกันว่าแนวทางการพัฒนาของทีมว่ากระบวนการการพัฒนาจะมี step อย่างไรบ้างเพื่อที่จะโฟกัสในเรื่องของ Feedback
ขั้นตอนแรก (1) เริ่มต้นด้วยการเขียน Feature File
- โดยอันดับแรกสุดเลยสมาชิกทั้งหมดของทีมอาจจะ Mob Programming กันเพื่อที่จะเขียน Feature File สำหรับการทดสอบ End-to-End (E2E Test) ตามใน SBE โดยอาจจะเลือก scenario ที่ simple ที่สุดก่อน เช่น “กดปุ่มแล้วแสดงรายการข้อมูลลูกค้าเป็นรายการว่าง ๆ แบบที่ยังไม่มีข้อมูลจริง” ก่อน
- จากนั้นเมื่อเรา push code ไป (เพื่อไปรอ integrate กับ Front-end) ในจังหวะนี้เราจะเห็นว่า CI Workflow ของเราจะแดง (ไม่ผ่าน) เนื่องจากว่าสิ่งที่ Feature File เราทดสอบมันเป็นหน้าจอ (UI) ที่ยังไม่มีอยู่จริง
ขั้นตอนที่สอง (2)
- สร้างหน้าจอ UI ให้ตรงกับ Feature File ที่เขียนไว้ โดยยังไม่เชื่อมต่อกับ API ของ Back-end
- ทำการทดสอบ E2E ในเครื่องเราจนผ่านแล้ว push code และทดสอบ E2E อีกครั้งบน CI Workflow และถ้าผ่านก็จะเป็นสีเขียว
ขั้นตอนที่สาม (3)
- เราจะเห็นว่า CI Workflow เราเขียว (ผ่าน) ซึ่งในจังหวะนี้ เราสามารถเอา Software Product ของเราไปรับ Feedback เบื้องต้นจาก PO ได้แล้วว่าเราเข้าใจถูกต้องตรงกันไหม
- จากนั้นเราก็จะกลับไปทำเหมือนเดิม คือเพิ่ม scenario ใหม่จากใน SBE เข้าไปที่ Feature file เช่น “กดปุ่มแล้วแสดง List จะแสดงข้อมูลลูกค้า 1 รายโดยระบุชื่อและนามสกุล”
- จากนั้นเมื่อเราทดสอบ E2E และ push code ไป เราจะเห็นว่า CI Workflow ของเราจะแดง เพราะไม่สามารถเห็นรายการลูกค้าของจริงได้ เนื่องจากเรายังไม่ได้เชื่อมต่อและ implement API เลย
- คราวนี้เราจะเริ่มเห็นแล้วว่า จังหวะนี้เราต้องเริ่มไป implement API แล้ว
ขั้นตอนที่สี่ (4)
- เราเริ่ม implement API เพื่อให้ Feature File รันผ่าน โดยอาจเริ่มด้วยการสร้าง API ที่มีเพียง layer Controller และ return ข้อมูลตัวอย่าง (Fix Data) ตามที่ระบุใน Feature File (ในกระบวนการตรงนี้เราสามารถเป็น TDD ได้และในระหว่างนี้ก็อาจจะเกิดการลูปทำขั้นตอน (1) ถึง (3) ไปพร้อมกันด้วย)
- เมื่อทดสอบ E2E ผ่านเรียบร้อย เรา push code เหมือนเดิม
ขั้นตอนที่ห้า (5)
- เมื่อเรามาถึงในจุดนี้ที่เราสามารถเริ่มแบ่งกันออกเพื่อไป Implement ส่วนต่าง ๆ เองได้แล้ว เราก็จะเริ่มแบ่งกันออกไปทำตาม Task
ขั้นตอนที่หก (6)
- ในขั้นตอนนี้ที่แยกกันออกไปทำตาม Task อาจจะเป็น Pair Programming ในจังหวะนี้ในแต่ละ Pair ก็จะมีการเขียน Feature File เพิ่ม scenario ใหม่ ๆ จาก SBE เข้าไป พร้อมทั้ง Refactor code เดิมด้วย และอาจจะมีฝั่ง Pair ที่ทำไปถึง Front-end และ Back-end แล้ว ก็กลับไปทำตาม Step TDD เหมือนเดิม โดยแต่ละ Pair ก็ยังคงมีการ commit และ push code อยู่บ่อย ๆ อย่างต่อเนื่องเพื่อ Continuous Integration กันตลอด ตรงแถว ๆ นี้เราเรียกว่า Concurrent Programming
- แบ่งทีมออกไปทำงานตาม Task โดยอาจจะเป็น Pair Programming สำหรับการพัฒนา Front-end และ Back-end โดยแต่ละทีมก็จะยังคงเขียน Feature File เพิ่มเติม, Refactor code เดิม และทดสอบ E2E โดยยังคงทำ Continuous Integration (commit และ push code บ่อยๆ)
สุดท้าย (7)
- เมื่อทุกอย่าง integrate กันได้เรียบร้อยและ CI Workflow เป็นสีเขียว แสดงว่าทุกอย่างราบรื่น โค้ดทำงานได้ตามที่ต้องการ
- ทีมพิจารณาว่า PBI เสร็จสิ้นตาม Definition of Done (DoD) และปิด Task นั้น
ซึ่งลูปใหญ่ ๆ ทั้งหมดนี้ก็คือ Acceptance test-driven development (ATDD) นั่นเอง หรือ อาจจะเรียกเป็น SBE หรือ BDD ก็ได้นั่นเองครับ
ซึ่งเราจะเห็นแล้วว่าพวก TDD หรือ ATDD สามารถนำมาปรับใช้กับ Agile หรือการพัฒนา Software Product ในยุคนี้ได้จริง ๆ แต่ก็ต้องขอบอกก่อนว่าสิ่งนี้ช่วยให้เราได้รับ Feedback ได้เร็วขึ้น ไม่ได้หมายถึงจะทำให้เราพัฒนา Software ได้เร็วขึ้น
Spillover คืออะไร? ถ้าเราอ่านมาจนถึงตอนนี้ เราจะเห็นคำว่า Spillover อยู่ตรงมุมซ้ายล่างของกระดาษ ถ้ามีโอกาสจะมาเขียนบทความเพิ่มในครั้งถัดไปครับ
(เนื้อหาที่ได้จาก LeSS in Action #2)
